- tld-wg - mailman.ripe.net

U.S. Goals, Global Values (was: Organization of...)
by JimFleming＠doorstep.unety.net 21 Apr '98

21 Apr '98

On Tuesday, April 21, 1998 11:25 AM, Jay Fenello[SMTP:Jay at IPERDOME.COM] wrote: <snip> @ @The way I see it, we face several possible outcomes under @the Green Paper process: @ 1) The GP garners the required consensus, and the root @ remains intact under a single authority structure. @ 2) The U.S. assumes the responsibility for a U.S. based @ root, and encourages Europe and others to do the same. @ Then, these independent roots can coordinate their @ activities as relative equals in the global Internet. @ 3) The Grass Root Servers are accepted, and each and @ every Netizen can choose for themselve. Jay, You might want to add #4. 4) Europe (mostly via RIPE) demonstrates that IP allocations and TLDs have something to do with each other and that people can work together without the DOD-centric IANA/ARIN approach. Then, U.S. companies realize the merits of this and move to this Round Table model. This is similar to #2 above but focuses on the fact that Europe and RIPE are in many ways ahead of the U.S. in this area. They have a healthier structure and do not seem to box themselves into corners like the IANA/ARIN people. For example, RIPE works on both IP and TLD issues. Join the discussion... http://www.ripe.net/mail-archives/tld-wg/current/index.html - Jim Fleming Unir Corporation IBC, Tortola, BVI -------- Logged at Tue Apr 21 19:21:41 MET DST 1998 ---------

1 0

FW: Structuring the Root
by JimFleming＠doorstep.unety.net 21 Apr '98

21 Apr '98

---------- From: Jim Fleming[SMTP:JimFleming] Sent: Tuesday, April 21, 1998 9:47 AM To: 'Valdis.Kletnieks at vt.edu' Cc: 'ARIN list' Subject: RE: Structuring the Root On Monday, April 20, 1998 3:56 PM, Valdis.Kletnieks at vt.edu wrote: @On Mon, 20 Apr 1998 14:15:50 CDT, Jim Fleming said: @ @> Based on the contents of the Root Zone file from the legacy @> Root Name Server Cluster operated by the U.S. Government, @> the following TLDs appear to be recognized: (only .ARPA is out of alpha order) @> @> 0 ARPA @> 1 AC @> 2 AD @ @> A simple way to do this is to use the number above to @> specify the value for bits in the fields labeled @> here as TTT.TTTTT. @> @> aaaaaTTT.TTTTTbbb.bbbbbbbb.bbbbbbbb @ @Hmm.. Jim's mail arrived from host doorstep.unety.net (207.32.128.1) @ @Applying his scheme here, we find he just delegated his address space @management to someplace in the *.UK domain. Could have been worse, they @could have been delegated to the .ZA or .ZR domains. At least there's entries @for those two - what about .WS or .WR who aren't even in the WHOIS yet. @ @But hey, it *does* have the advantage of screwing people equally at random. @-- Having the .UK people providing stewardship over the 207.32.X.X IPv4 address space would not be a problem. They appear to be stable. As I have mentioned, stewardship does not necessarily imply management and operations. They could delegate those tasks to make sure the clerical and operational jobs are handled. Who knows, maybe ARIN could handle the clerical tasks ? In the IPv8 Plan, the 207.32.X.X IPv4 address space is delegated to the TLD authority with the G:S slot numbered 7:32. This is currently assigned to the .ROOF Top Level Domain. The current list is at... http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt Here are all of the IPv4 blocks that would fall under the stewardship of the .ROOF TLD. This TLD authority would also be responsible for the 7:32.X.X.X.X IPv8 address space which is as large as the current Internet. This should provide enough resources to manage to help keep the .ROOF registries and registrars in business. -------- IPv4 Blocks Delegated to G:S = 7:32 -------------- 7.32.0.0 15.32.0.0 23.32.0.0 31.32.0.0 39.32.0.0 47.32.0.0 55.32.0.0 63.32.0.0 71.32.0.0 79.32.0.0 87.32.0.0 95.32.0.0 103.32.0.0 111.32.0.0 119.32.0.0 127.32.0.0 135.32.0.0 143.32.0.0 151.32.0.0 159.32.0.0 167.32.0.0 175.32.0.0 183.32.0.0 191.32.0.0 199.32.0.0 207.32.0.0 215.32.0.0 223.32.0.0 231.32.0.0 239.32.0.0 247.32.0.0 255.32.0.0 /* * * usage: ipv4list g:s * * Generates a list of IPv4 address blocks given an IPv8 G:S number * * Copyright 1998, Unir Corporation, All Rights Reserved * */ #include <stdio.h> main(argc,argv) int argc; char *argv[]; { int g; int s; int i; int k; int n; if((argv[1][0] >= '0') && (argv[1][0] <= '7')){ g = argv[1][0] - '0'; } else{ exit(-1); } if(argv[1][1] != ':'){ exit(-2); } s = atoi(&argv[1][2]); k = ((g<<24) + (s<<16)) & 0x07ff0000; for(i=0; i<32; i++){ n = (i<<27) + k; printf("%d.%d.%d.%d\n", (n>>24)&0xff, (n>>16)&0xff, (n>>8)&0xff, n&0xff); } } ====== - Jim Fleming Unir Corporation IBC, Tortola, BVI -------- Logged at Tue Apr 21 19:08:17 MET DST 1998 ---------

1 0

The Registry Industry
by JimFleming＠doorstep.unety.net 20 Apr '98

20 Apr '98

On Monday, April 20, 1998 5:45 PM, Berislav Todorovic[SMTP:BERI at etf.bg.ac.yu] wrote: <snip> @ @First off, the proposal tries to connect two administrative antipodes on @the Internet today: IP address space management (which is a pure technical @questin) and domain name delegations (which also have an inevitable legal @component). Let's try to stress out some facts, which describe the current @situation about reverse domain delegations: @ If you look at the Registry Industry as if it were the Banking Industry or the Health Care Industry, you might see that in all three of these industries there are "administrative antipodes". This is natural and I do not think that this means one has to take each antipode and separate it into a different business. In fact, if you do that, the business may fail. Examples: Can you have a bank with savings but no loans ? Can you have a hospital with no pharmacy ? In any young industry (like the Registry Industry) I think that it makes more sense to allow independent businesses to have a wide range of products and services instead of forcing (via regulation of social pressure) each service into a separate business. Also, you have to look at the industry and try to determine where you will get your experienced trustees or stewardship. In the Registry Industry it is best to turn to the registries. They are in the business and their businesses are most likely to have personnel who understand the industry and will be able to be around to support the customers. In my opinion, this makes better business sense than to force domain registries into one corner and IN-ADDR.ARPA registries into another corner when both are basically registries. Why not let the industry sort this out via natural evolution of the marketplace ? - Jim Fleming Unir Corporation IBC, Tortola, BVI -------- Logged at Tue Apr 21 10:23:55 MET DST 1998 ---------

1 0

Growing from 256 to 2048 TLDs
by JimFleming＠doorstep.unety.net 20 Apr '98

20 Apr '98

On Monday, April 20, 1998 6:00 PM, Marsh, Miles (Gene)[SMTP:MarshM at diebold.com] wrote: @Jim, @ @Is it worth considering a method by which there could be more flexible @expansion of the number of potential TLD's? I know the prevailing @thought is that we must put a stake in the ground, but any constraining @factor could have negative potential. @ I think that all proposals are worth considering...fire away... I have a feeling that there will be a flexible or at least variable growth pattern once some minimal structure is put in place. As an example, if you take the 256 TLDs and declare that all can create 7 more TLDs they may all do it at different rates. This will appear to the consumers as a market-driven growth pattern. In my opinion, people should not be too concerned about the growth getting out of control. If there has been one thing that has been surprising over the past few years, it has been the fact that very few companies are willing to make the investments to understand and prepare to participate in the Registry Industry. - Jim Fleming Unir Corporation IBC, Tortola, BVI -------- Logged at Tue Apr 21 02:20:02 MET DST 1998 ---------

1 0

Growing from 256 to 2048 TLDs
by MarshM＠diebold.com 20 Apr '98

20 Apr '98

Jim, Is it worth considering a method by which there could be more flexible expansion of the number of potential TLD's? I know the prevailing thought is that we must put a stake in the ground, but any constraining factor could have negative potential. Gene Marsh Diebold Incorporated -----Original Message----- From: Jim Fleming [mailto:JimFleming at doorstep.unety.net] Sent: Monday, April 20, 1998 5:51 PM To: 'Berislav Todorovic' Cc: arin-council at arin.net; BBURR at ntia.doc.gov; ietf at ietf.org; Ira_C._Magaziner at oa.eop.gov; tld-wg at ripe.net Subject: Growing from 256 to 2048 TLDs On Monday, April 20, 1998 5:45 PM, Berislav Todorovic[SMTP:BERI at etf.bg.ac.yu] wrote: <snip> @ @The scheme you proposed, on the other hand, has several deficiencies. @First (the minor one) - the table is constrained to 256 TLDs - how ca @you predict that it won't be more than 256 TLDs in the future? Like Brian @Carpenter said in the RFC 2058, "the principle of constant change is @perhaps the only principle of the Internet that should survive @indefinitely". @ Thanks for the well written response. I will try to reply to each of your points. As you note, the following accommodates 256 TLDs. aaaaaTTT.TTTTTbbb.bbbbbbbb.bbbbbbbb In the IPv8 Plan, we support 2,048 TLDs. That looks like... aaaaaTTT.TTTTTTTT.bbbbbbbb.bbbbbbbb The extra bits get added to the right of the TTTTs... Applying this to the scheme I suggested, each of the existing TLDs in the initial group of 256 would be allowed to ADD 7 more TLDs at some point in the future. This will bring the number to 2,048. Here is more information as well as a list of the current IPv8 TLDs. http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/03_23_98-2.htm http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt - Jim Fleming Unir Corporation IBC, Tortola, BVI -------- Logged at Tue Apr 21 01:10:38 MET DST 1998 ---------

1 0

FW: Structuring the Root
by BERI＠etf.bg.ac.yu 20 Apr '98

20 Apr '98

>> Date: Mon, 20 Apr 1998 15:15:49 -0500 >> From: Jim Fleming <JimFleming at doorstep.unety.net> >> Subject: FW: Structuring the Root >> To: "'tld-wg at ripe.net'" <tld-wg at ripe.net> >> To: 'arin-council at arin.net'; 'ARIN list' >> Cc: 'BBURR at ntia.doc.gov'; 'ietf at ns.ietf.org'; 'Ira_C._Magaziner at oa.eop.gov' >> Subject: Structuring the Root >> >> Structuring the Root for the IPv4 Internet can be as simple as >> assigning each of the TLD authorities a section of the IPv4 address >> space to "manage" (not route). The IN-ADDR.ARPA zone file could >> be cleaned up once delegations are made in a more distributed >> manner. It is important to note that this methodology does not "use" >> all of the IPv4 addresses, it just distributes them fairly for management >> purposes. Many thanks for the copy of this pretty interesting proposal! However, I'd like to place some comments on it. First off, the proposal tries to connect two administrative antipodes on the Internet today: IP address space management (which is a pure technical questin) and domain name delegations (which also have an inevitable legal component). Let's try to stress out some facts, which describe the current situation about reverse domain delegations: * IN-ADDR.ARPA delegations are (naturally) closely related to the IP address allocations/assignments, since reverse domains somewhat reflect usage of the address space, allocated to an ISP or assigned to a user. In other words, reverse domains are closely related to IP addresses used in the network - NOT to the domain names in any way! * IP address allocation/assignment process is totally independent of domain name delegations. IP address management hierarchy (IANA -> Regional IRs -> ISPs/LIRs -> End users) is a logical consequence of the hierarchy of the global routing system. At an extreme point - a ccTLD could be used for Web hosting and similar purposes only, where IP address space is not needed (take many small countries in Oceania, which sold their domains to other countries - see NU TLD, for example). * Currently, regional registries provide IN-ADDR.ARPA delegations for all IP blocks they allocate to the ISPs/LIRs. The ISPs are, apparently, responsible for proper visibility of the reverse domains for the IP address space assigned to their end users. The scheme you proposed, on the other hand, has several deficiencies. First (the minor one) - the table is constrained to 256 TLDs - how ca you predict that it won't be more than 256 TLDs in the future? Like Brian Carpenter said in the RFC 2058, "the principle of constant change is perhaps the only principle of the Internet that should survive indefinitely". The second one (more important) is the question of responsibility: an ISP, assigning an IP network to end user is responsible for its rouitng and reverse domain mapping. Why? Because the user pays for that service! Now, the regional IR, allocating an IP block to the ISP is responsible for its IN-ADDR.ARPA delegation. Why? Because the ISP pays to the regional IR for the service they receive (IP address allocations and reverse domain name delegations). Now, with the transition you proposed, a user would have to delegate their reverse domains to a regional registry of a country which does not have anything to do with them. The following situation might arise: an ISP receives three independent allocations from the IRs. Now, part of their users would have to delegate their addresses with, say, TLD of Fiji (FJ), the other will have to ask the TLD of Cyprus (CY), the third group will have to go to the Russian (RU) TLD. And - all ISPs are located, say, in the USA! Funny, isn't it? The other side of the medal: suppose that your company, some university or - even Whitehouse or United Nations, received address space which has to be delegated by the TLD registrar of Western Samoa, since the digits in the IP addresses point to that registrar. Suppose Western Samoa TLD DNS servers fail. Who are you going to blame? Western Samoa TLD NIC? Their government? The current bottom-up structure of IN-ADDR.ARPA delegation might not be the best solution achievable today! But that's all we have today ... which does not mean it cannot change tomorrow! ;-) Best regards, Beri .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI at etf.bg.ac.yu | /|\ Hostmaster of the YU TLD | |-(-+-)-| School of Electrical Engineering | Phone: (+381-11) 3221-419 | \|/ Bulevar Revolucije 73 | 3370-106 | --+-- | 11000 Belgrade SERBIA, YUGOSLAVIA | Fax: (+381-11) 3248-681 `-------' -------------------------------------------------------------------- -------- Logged at Mon Apr 20 23:57:34 MET DST 1998 ---------

1 0

Stewardship and Management vs. IN-ADDR.ARPA Service
by JimFleming＠doorstep.unety.net 20 Apr '98

20 Apr '98

On Monday, April 20, 1998 5:45 PM, Berislav Todorovic[SMTP:BERI at etf.bg.ac.yu] wrote: <snip> @ @Now, with the transition you proposed, a user would have to delegate their @reverse domains to a regional registry of a country which does not have @anything to do with them. I am sorry I was not more clear. In my opinion, you have at least three levels at play when you are looking at IP address management. They might be labeled as follows. 1. Stewardship - Traditional IANA-like Role 2. Management - RIPE-like Role 3. Operations - DNS, IN-ADDR.ARPA, etc. In my opinion, these three "levels" could be handled by different groups depending on the decisions made at the Stewardship level. The scheme I was suggesting distributes the Stewardship. It is like creating 256 IANAs. From there, you have to imagine that each of the 256 would evolve in their own way AND that evolution would depend on input from the stakeholders in the address space. This might result in the Stewardship being in Europe with the Management handed back to ARIN and the IN-ADDR.ARPA handled by the ISP/C. The goal here is NOT to delegate IP address space to people or companies with networks that fail. The goal is to delegate Stewardship (or what some call Trusteeship) and then to have those stewards/trustees work with the stakeholders to find the best management and operations. - Jim Fleming Unir Corporation IBC, Tortola, BVI -------- Logged at Tue Apr 21 00:56:49 MET DST 1998 ---------

1 0

Growing from 256 to 2048 TLDs
by JimFleming＠doorstep.unety.net 20 Apr '98

20 Apr '98

On Monday, April 20, 1998 5:45 PM, Berislav Todorovic[SMTP:BERI at etf.bg.ac.yu] wrote: <snip> @ @The scheme you proposed, on the other hand, has several deficiencies. @First (the minor one) - the table is constrained to 256 TLDs - how ca @you predict that it won't be more than 256 TLDs in the future? Like Brian @Carpenter said in the RFC 2058, "the principle of constant change is @perhaps the only principle of the Internet that should survive @indefinitely". @ Thanks for the well written response. I will try to reply to each of your points. As you note, the following accommodates 256 TLDs. aaaaaTTT.TTTTTbbb.bbbbbbbb.bbbbbbbb In the IPv8 Plan, we support 2,048 TLDs. That looks like... aaaaaTTT.TTTTTTTT.bbbbbbbb.bbbbbbbb The extra bits get added to the right of the TTTTs... Applying this to the scheme I suggested, each of the existing TLDs in the initial group of 256 would be allowed to ADD 7 more TLDs at some point in the future. This will bring the number to 2,048. Here is more information as well as a list of the current IPv8 TLDs. http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/03_23_98-2.htm http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt - Jim Fleming Unir Corporation IBC, Tortola, BVI -------- Logged at Tue Apr 21 00:08:14 MET DST 1998 ---------

1 0

FW: Structuring the Root
by JimFleming＠doorstep.unety.net 20 Apr '98

20 Apr '98

---------- From: Jim Fleming[SMTP:JimFleming] Sent: Monday, April 20, 1998 2:15 PM To: 'arin-council at arin.net'; 'ARIN list' Cc: 'BBURR at ntia.doc.gov'; 'ietf at ns.ietf.org'; 'Ira_C._Magaziner at oa.eop.gov' Subject: Structuring the Root Structuring the Root for the IPv4 Internet can be as simple as assigning each of the TLD authorities a section of the IPv4 address space to "manage" (not route). The IN-ADDR.ARPA zone file could be cleaned up once delegations are made in a more distributed manner. It is important to note that this methodology does not "use" all of the IPv4 addresses, it just distributes them fairly for management purposes. Based on the contents of the Root Zone file from the legacy Root Name Server Cluster operated by the U.S. Government, the following TLDs appear to be recognized: (only .ARPA is out of alpha order) 0 ARPA 1 AC 2 AD 3 AE 4 AF 5 AG 6 AI 7 AL 8 AM 9 AN 10 AO 11 AQ 12 AR 13 AS 14 AT 15 AU 16 AW 17 AZ 18 BA 19 BB 20 BE 21 BF 22 BG 23 BH 24 BI 25 BJ 26 BM 27 BN 28 BO 29 BR 30 BS 31 BT 32 BV 33 BW 34 BY 35 BZ 36 CA 37 CC 38 CD 39 CF 40 CG 41 CH 42 CI 43 CK 44 CL 45 CM 46 CN 47 CO 48 COM <------ See example below 49 CR 50 CU 51 CV 52 CX 53 CY 54 CZ 55 DE 56 DJ 57 DK 58 DM 59 DO 60 DZ 61 EC 62 EDU 63 EE 64 EG 65 ER 66 ES 67 ET 68 FI 69 FJ 70 FK 71 FM 72 FO 73 FR 74 GA 75 GB 76 GD 77 GE 78 GF 79 GG 80 GH 81 GI 82 GL 83 GM 84 GN 85 GOV 86 GP 87 GQ 88 GR 89 GS 90 GT 91 GU 92 GW 93 GY 94 HK 95 HM 96 HN 97 HR 98 HT 99 HU 100 ID 101 IE 102 IL 103 IM 104 IN 105 INT 106 IO 107 IQ 108 IR 109 IS 110 IT 111 JE 112 JM 113 JO 114 JP 115 KE 116 KG 117 KH 118 KI 119 KN 120 KR 121 KW 122 KY 123 KZ 124 LA 125 LB 126 LC 127 LI 128 LK 129 LR 130 LS 131 LT 132 LU 133 LV 134 LY 135 MA 136 MC 137 MD 138 MG 139 MH 140 MIL 141 MK 142 ML 143 MM 144 MN 145 MO 146 MP 147 MQ 148 MR 149 MS 150 MT 151 MU 152 MV 153 MW 154 MX 155 MY 156 MZ 157 NA 158 NC 159 NE 160 NET 161 NF 162 NG 163 NI 164 NL 165 NO 166 NP 167 NR 168 NU 169 NZ 170 OM 171 ORG 172 PA 173 PE 174 PF 175 PG 176 PH 177 PK 178 PL 179 PM 180 PN 181 PR 182 PT 183 PW 184 PY 185 QA 186 RE 187 RO 188 RU 189 RW 190 SA 191 SB 192 SC 193 SD 194 SE 195 SG 196 SH 197 SI 198 SJ 199 SK 200 SL 201 SM 202 SN 203 SO 204 SR 205 ST 206 SU 207 SV 208 SY 209 SZ 210 TC 211 TD 212 TF 213 TG 214 TH 215 TJ 216 TK 217 TM 218 TN 219 TO 220 TP 221 TR 222 TT 223 TV 224 TW 225 TZ 226 UA 227 UG 228 UK 229 UM 230 US 231 UY 232 UZ 233 VA 234 VC 235 VE 236 VG 237 VI 238 VN 239 VU 240 WF 241 WS 242 YE 243 YT 244 YU 245 ZA 246 ZM 247 ZR 248 ZW 249 <AVAILABLE> 250 <AVAILABLE> 251 <AVAILABLE> 252 <AVAILABLE> 253 <AVAILABLE> 254 <AVAILABLE> 255 <AVAILABLE> The last 7 slots could be used to add new TLDs as part of the transition described in the Department of Commerce's Green Paper. Once all 256 slots are filled the number on the left can be used to identify sections of the IPv4 Address Space that can be delegated to the various TLD authorities for "management" (and stewardship). A simple way to do this is to use the number above to specify the value for bits in the fields labeled here as TTT.TTTTT. aaaaaTTT.TTTTTbbb.bbbbbbbb.bbbbbbbb If the value of aaaaa is allowed to range from 0 to 31 for EACH of the values of TTT.TTTTT then prefixes can be identified for each of the TLD authorities to manage. This approach distributes the entire IPv4 address space to responsible parties for management and stewardship purposes. Using the value of 48 for the .COM TLD illustrates that the following IPv4 blocks would be placed in the hands of the InterNIC (NSF/NSI) for management. Since the NSF and NSI have delegated IPv4 numbering to ARIN, these 32 /13 blocks would be managed by ARIN. This would be all ARIN manages for revenue producing activities. The rest of the IPv4 space would be distributed to other TLD authorities to more fairly distribute the assets that produce revenue. 1.128-135.0.0 9.128-135.0.0 17.128-135.0.0 25.128-135.0.0 33.128-135.0.0 41.128-135.0.0 49.128-135.0.0 57.128-135.0.0 65.128-135.0.0 73.128-135.0.0 81.128-135.0.0 89.128-135.0.0 97.128-135.0.0 105.128-135.0.0 113.128-135.0.0 121.128-135.0.0 129.128-135.0.0 137.128-135.0.0 145.128-135.0.0 153.128-135.0.0 161.128-135.0.0 169.128-135.0.0 177.128-135.0.0 185.128-135.0.0 193.128-135.0.0 201.128-135.0.0 209.128-135.0.0 217.128-135.0.0 225.128-135.0.0 233.128-135.0.0 241.128-135.0.0 249.128-135.0.0 The following C program can be used to determine other ranges of blocks given a TLD index as shown above. /* * * gs n * * Generates a gs number based an 8 bit value * */ main(argc,argv) int argc; char *argv[]; { int i; int k; int n; k = ((atoi(argv[1]) << 19) & 0x07f80000); for(i=0; i<32; i++){ n = (i<<27) + k; printf("%d.%d-%d.%d.%d\n", (n>>24)&0xff, (n>>16)&0xff, ((n>>16)+7)&0xff, (n>>8)&0xff, n&0xff); } } ===== -------- Logged at Mon Apr 20 23:49:02 MET DST 1998 ---------

1 0

Fay Howard Appointed RIPE CENTR Project Manager
by Daniel.Karrenberg＠ripe.net 02 Apr '98

02 Apr '98

Dear Colleagues, I am pleased to announce that the RIPE NCC has found a very competent person for the RIPE CENTR project: Fay Howard has been appointed as RIPE CENTR Project Manager. In addition to providing support to the Policy Group of the (currently 34) participating NTLDs, she will manage the work carried out by RIPE NCC on behalf of the project. Until 1 May 1998, Fay will spend two thirds of her time on the CENTR project after which date she will work full time on RIPE CENTR issues. Some of you will recall Fay from her time at TERENA where she worked as Executive Officer for 16 months gaining an excellent understanding of the European networking community and the management of projects like RIPE CENTR. Her orignal background is in Insurance where she was a Senior Legal Liabilities Underwriter for many years. Fay will act as a focal point for all issues and queries regarding the RIPE CENTR project. If you have any questions, suggestions or specific needs, please do not hesitate to contact her. Daniel Karrenberg RIPE NCC General Manager -------- Logged at Thu Apr 2 16:20:38 MET DST 1998 ---------

2 1