From agatho at ucy.ac.cy Thu Apr 2 17:16:20 1998 From: agatho at ucy.ac.cy (Dr Agathoclis Stylianou) Date: Thu, 2 Apr 1998 17:16:20 +0200 (WET) Subject: Fay Howard Appointed RIPE CENTR Project Manager In-Reply-To: <199803301305.PAA24048@kantoor.ripe.net> Message-ID: Congratulations to Fay and to RIPE for having such a competent professional working for them Regards Agathoclis Stylianou -------------------------------------------------------------------- | | | Dr Agathoclis Stylianou Fax : (02)-756082 or 756198 | | Director Tel : (02)-756186 | | Computer Centre e-mail : agatho at zeus.cc.ucy.ac.cy | | University of Cyprus | | POBox 537 | | Nicosia | | CYPRUS | | | | | -------------------------------------------------------------------- -------- Logged at Fri Apr 3 13:01:37 MET DST 1998 --------- From agatho at ucy.ac.cy Thu Apr 2 17:16:20 1998 From: agatho at ucy.ac.cy (Dr Agathoclis Stylianou) Date: Thu, 2 Apr 1998 17:16:20 +0200 (WET) Subject: Fay Howard Appointed RIPE CENTR Project Manager In-Reply-To: <199803301305.PAA24048@kantoor.ripe.net> Message-ID: Congratulations to Fay and to RIPE for having such a competent professional working for them Regards Agathoclis Stylianou -------------------------------------------------------------------- | | | Dr Agathoclis Stylianou Fax : (02)-756082 or 756198 | | Director Tel : (02)-756186 | | Computer Centre e-mail : agatho at zeus.cc.ucy.ac.cy | | University of Cyprus | | POBox 537 | | Nicosia | | CYPRUS | | | | | -------------------------------------------------------------------- -------- Logged at Mon Apr 20 22:20:43 MET DST 1998 --------- From JimFleming at doorstep.unety.net Mon Apr 20 22:15:49 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Mon, 20 Apr 1998 15:15:49 -0500 Subject: FW: Structuring the Root Message-ID: <01BD6C6F.33B4D2A0@pc.unir.net> ---------- 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 250 251 252 253 254 255 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 --------- From BERI at etf.bg.ac.yu Tue Apr 21 00:45:00 1998 From: BERI at etf.bg.ac.yu (Berislav Todorovic) Date: Mon, 20 Apr 1998 23:45 +0100 Subject: FW: Structuring the Root Message-ID: <3EE68E4948001F1F@etf.bg.ac.yu> >> Date: Mon, 20 Apr 1998 15:15:49 -0500 >> From: Jim Fleming >> Subject: FW: Structuring the Root >> To: "'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 --------- From JimFleming at doorstep.unety.net Mon Apr 20 23:51:11 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Mon, 20 Apr 1998 16:51:11 -0500 Subject: Growing from 256 to 2048 TLDs Message-ID: <01BD6C7C.866EE140@pc.unir.net> On Monday, April 20, 1998 5:45 PM, Berislav Todorovic[SMTP:BERI at etf.bg.ac.yu] wrote: @ @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 --------- From JimFleming at doorstep.unety.net Tue Apr 21 00:01:56 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Mon, 20 Apr 1998 17:01:56 -0500 Subject: Stewardship and Management vs. IN-ADDR.ARPA Service Message-ID: <01BD6C7E.06E9B2E0@pc.unir.net> On Monday, April 20, 1998 5:45 PM, Berislav Todorovic[SMTP:BERI at etf.bg.ac.yu] wrote: @ @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 --------- From MarshM at diebold.com Tue Apr 21 01:00:13 1998 From: MarshM at diebold.com (Marsh, Miles (Gene)) Date: Mon, 20 Apr 1998 19:00:13 -0400 Subject: Growing from 256 to 2048 TLDs Message-ID: <7A4F246E1BA6D1119C780000832D8FD533E2AE@msexch02.diebold.com> 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: @ @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 --------- From JimFleming at doorstep.unety.net Tue Apr 21 01:05:12 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Mon, 20 Apr 1998 18:05:12 -0500 Subject: Growing from 256 to 2048 TLDs Message-ID: <01BD6C86.DDAC0E60@pc.unir.net> 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 --------- From JimFleming at doorstep.unety.net Tue Apr 21 02:14:50 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Mon, 20 Apr 1998 19:14:50 -0500 Subject: The Registry Industry Message-ID: <01BD6C90.98220A20@pc.unir.net> On Monday, April 20, 1998 5:45 PM, Berislav Todorovic[SMTP:BERI at etf.bg.ac.yu] wrote: @ @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 --------- From BERI at etf.bg.ac.yu Tue Apr 21 00:45:00 1998 From: BERI at etf.bg.ac.yu (Berislav Todorovic) Date: Mon, 20 Apr 1998 23:45 +0100 Subject: FW: Structuring the Root Message-ID: <3EE68E4948001F1F@etf.bg.ac.yu> >> Date: Mon, 20 Apr 1998 15:15:49 -0500 >> From: Jim Fleming >> Subject: FW: Structuring the Root >> To: "'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 Tue Apr 21 10:24:35 MET DST 1998 --------- From MarshM at diebold.com Tue Apr 21 01:00:13 1998 From: MarshM at diebold.com (Marsh, Miles (Gene)) Date: Mon, 20 Apr 1998 19:00:13 -0400 Subject: Growing from 256 to 2048 TLDs Message-ID: <7A4F246E1BA6D1119C780000832D8FD533E2AE@msexch02.diebold.com> 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: @ @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 18:54:41 MET DST 1998 --------- From JimFleming at doorstep.unety.net Tue Apr 21 18:49:43 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Tue, 21 Apr 1998 11:49:43 -0500 Subject: FW: Structuring the Root Message-ID: <01BD6D1B.93F20BE0@pc.unir.net> ---------- 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 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 --------- From JimFleming at doorstep.unety.net Tue Apr 21 19:03:23 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Tue, 21 Apr 1998 12:03:23 -0500 Subject: U.S. Goals, Global Values (was: Organization of...) Message-ID: <01BD6D1D.7CBA3860@pc.unir.net> On Tuesday, April 21, 1998 11:25 AM, Jay Fenello[SMTP:Jay at IPERDOME.COM] wrote: @ @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 --------- From JimFleming at doorstep.unety.net Tue Apr 21 19:16:42 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Tue, 21 Apr 1998 12:16:42 -0500 Subject: FW: Round Table vs. Hierarchy Message-ID: <01BD6D1F.587AD2A0@pc.unir.net> ---------- From: Jim Fleming[SMTP:JimFleming] Sent: Tuesday, April 21, 1998 7:23 AM To: 'arin-council at arin.net'; 'BBURR at ntia.doc.gov'; 'Ira_C._Magaziner at oa.eop.gov'; 'ARIN list' Cc: 'Tony Rutkowski'; 'Bala Pillai'; 'Christopher Ambler'; 'Gordon Cook'; 'Doug Humphrey'; 'John Gilmore'; 'Rey Blanco'; 'Jay at Iperdome.com'; 'John Charles Broomfield'; 'John Curran'; 'Jim Dixon'; 'Jeff Williams'; 'Karl Auerbach'; 'Karl Denninger'; 'KathrynKL'; 'Ken Fockler'; 'Kent Crispin'; 'Kim Hubbard'; 'John C Klensin'; 'Marc Hurst'; 'Michael Dillon'; 'Peter Deutsch'; 'Phil Howard'; 'Robert Raisch'; 'Richard J. Sexton'; 'Roeland M.J. Meyer'; 'Robert Shaw'; 'Robert L. Shearing'; 'Simon Higgs'; 'Scott Bradner'; 'Steve Wolff'; 'steve'; 'vinton g. cerf' Subject: Round Table vs. Hierarchy It appears that most parties involved in the planning of Internet Governance are more comfortable with evolving ARIN away from the IANA than using the ARIN structure as a basis to build the start of a Round Table structure with three "equal" partners, ARIANA, APNIC and RIPE. Surprisingly, even the people involved with ARIN appear to prefer the hierarchy structure. The two structures can be illustrated in the following crude stick diagrams. ==== Round Table Structure ===== ARIN / IANA \ / \ / \ APNIC-------------RIPE =========================== ==== Hierarchy Structure ======= IANA / | \ / | \ / | \ APNIC ARIN RIPE =========================== In the Round Table structure each participant at the table represents a historical collection of Internet resources (DNs, IPs, ASNs, etc.) and there is no central authority. More participants can be added to the Round Table as the Internet grows. When more than three participants are included a fully meshed commuication structure can be implemented via the Internet to help ensure that all participants are equals. This takes work, but in my opinion it is worth the effort. The Hierarchy takes less work. As shown above, the IANA (Inc.) plays a central coordination role and the regional registries are equals with each other, but not the IANA. The Hierarchy can be scaled by adding participants, but it is difficult to scale the IANA. This has been part of the problem with Internet Governance during the past few years. Despite the problems with the Hierarchy approach, it appears that most parties are more comfortable with that approach than the Round Table approach. Given that, the U.S. Government now has the difficult job of separating the ARIN and IANA tasks to allow ARIN to move to an arm's length position from the IANA Inc. It is unclear whether this will require the IANA to move away from ARIN or whether ARIN will move away from the IANA. They are currently intertwined, especially at the server, data base and operations level. Given that it appears that the ARIN Board and Advisory Council prefer to be part of the Hierarchy approach, it will be up to them to distance themselves from the IANA. This will require significant operational changes at ARIN. As a start, ARIN should deploy its own IN-ADDR.ARPA servers which can then be delegated parts of the IPv4 address space. This will distance ARIN from the legacy Root Name Servers operated by the U.S. Government and place it at arm's length. In the current situation, ARIN is using the USG roots for IN-ADDR.ARPA. The other two regional registries (RIPE and APNIC) are delegated parts of the IPv4 space. ARIN is not, because ARIN is tightly coupled with the IANA. This has to change. Since I am not an advocate of the Hierarchy approach, I will defer to other experts who seem to think that they can build a successful Internet using that centralized structure. I hope that they begin to enter these open forums to explain in detail how they intend to make this happen. It will be interesting to "watch" this metamorphosis take place. Note the emphasis on the word...watch... - Jim Fleming Unir Corporation IBC, Tortola, BVI -------- Logged at Thu Apr 23 00:04:40 MET DST 1998 --------- From Jay at Iperdome.com Thu Apr 23 00:04:04 1998 From: Jay at Iperdome.com (Jay Fenello) Date: Wed, 22 Apr 1998 18:04:04 -0400 Subject: FW: Structuring the Root In-Reply-To: <3EE4A2F408001F1F@etf.bg.ac.yu> Message-ID: <3.0.2.32.19980422180404.007429a4@mindspring.com> At 11:45 PM 4/20/98 +0100, Berislav Todorovic wrote: >* 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. Only a small fraction of the IP address space is allocated in this manner. Based on the limited information that I've seen, only about 30 /8s have been delegated to the regional IRs. A large portion of the IP address space has been allocated directly to some large, independent organizations, and a large portion remains available to the IANA for future allocations. Is this not accurate? Regards, Jay Fenello President, Iperdome, Inc. 404-250-3242 http://www.iperdome.com -------- Logged at Thu Apr 23 11:28:46 MET DST 1998 --------- From schneider at switch.ch Thu Apr 23 11:28:34 1998 From: schneider at switch.ch (Marcel Schneider) Date: Thu, 23 Apr 1998 11:28:34 +0200 Subject: Proposal for distribution of WHOIS data Message-ID: <9804230928.AA16646@ncc.ripe.net> Logistical and legal matters are intended to be covered by this proposal. A. Stage 1: Distribution to safe place ----------------------------------- The registries are encouraged to transfer entire WHOIS records to one or more places which are recognized as central repositories (REP). This could be RIPE/APNIC/ARIN, the new to be formed ccTLD organizations (like RIPE CENTR) and for gTLD's their corresponding organizations (e.g. CORE/InterNIC) or some other agreed upon sites. Transfer could either be from a registry to the REP's or vice versa, by means of file transfer, mirroring or other, but the entire process (storage at registry, transfer and storage at REP) should be reasonably well protected. B. Stage 2: Distribution to the public ----------------------------------- Contractors to the registries should be allowed to disseminate above WHOIS data to the public and to extract certain data from them according to their needs (e.g. to provide overviews, to watch the registration of marks etc.). Let's call these contractors DIST. The DIST should be required to a) agree on an AUP (Acceptable Use Policy) set up by the registries and to include the AUP with any data published by DIST. b) sign a contract with the REP's where use of data, access to data, responsibilities, price, origin of data, periodicity of gathering data, non-disclosed data etc. is stated. Any statistics extracted by DIST's are unofficial unless approved by the registries. The registries may derive stats by themselves through REP's which are then official. Above proposal should ensure distribution of WHOIS data in a well controlled manner and should protect registrants from misuse of their (personal) data. Use of WHOIS data for advertising or other commercial activities and/or for unsolicited mail is considered as abuse and should be avoided. In addition, the proposal may encourage the development of other technical facilities to present and distribute WHOIS data to the public (e.g. LDAP) and may have consequences to current and future WHOIS implementations (e.g. referral WHOIS data base, RWHOIS) and may lead to improved facilities for the public (e.g. fuzzy matches when only partial information is known like location and type of business). Examples: -------- Existing global WHOIS searches: http://www.netnames.com http://www.allwhois.com Existing AUP's: http://www.ripe.net/db/dbcopyright.html http://www.nic.ch/whois_readme.html Existing contracts: I'm only aware of 2: Nominet and SWITCH. The latter's contract is only available on paper. Marcel -------- Logged at Mon Apr 27 22:26:02 MET DST 1998 --------- From JimFleming at doorstep.unety.net Mon Apr 27 22:20:38 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Mon, 27 Apr 1998 15:20:38 -0500 Subject: Should Two Letter TLDs Be Immune ? Message-ID: <01BD71F0.09644D60@pc.unir.net> People seem to have no problem allowing the 2 letter TLDs to be grandfathered to have immunity from the Green Paper and the U.S. Government. The assumption appears to be that the 2 letter TLDs have been delegated to individuals, companies and in some cases governments with care. This is not necessarily the case. In my opinion, the 2 letter TLDs should be treated as generic tags and should not be given a pass when it comes to requirements for stable governance and operational excellence. If this is not done, consumers may be mislead that 2 letter TLDs have the same industry oversight via the IANA Inc. and self-regulation. Consumers may find that they are subjected to arbitrary policies, predatory price increases and shoddy operations unless they are warned that 2 letter TLDs are immune from IANA Inc. oversight. This will not be a good thing and may cause well-run 2 letter TLDs to suffer because of the unsatisfactory practices of a few, poorly managed 2 letter TLDs. Of course, part of the problem is defining what poorly managed means. In some parts of the world business practices may be tolerated that are not common in the U.S. For example, people may choose to discriminate based on a variety of reasons. One of the most obvious is that companies supporting the government obtain .TLD registrations and those that do not are excluded. Much of this assumes that the government is the current delegate of the 2 letter TLDs. As the domain name debates rage on we find more and more that governments do not have a clue what is happening with the 2 letter TLD that was supposedly delegated to them. Instead, we find that the 2 letter TLDs have been casually delegated to people and companies that gave the right impression of representing the government or local people but who actually use the TLD for their own business purposes. None of these things can be easily fixed and there may be no need to fix them IF the consumer is alerted to this situation. Unfortunately, the Green Paper and the IANA Inc. might end up sending the wrong message if they require generic TLDs to be held to one standard while 2 letter TLDs are immune. In my opinion, all of the TLDs should be held to the same high standards of business ethics and operational integrity as agreed upon by the Registry Industry. The question remains as to how to do this...? To date much of the focus has been on ADDING TLDs to the legacy Root Name Servers that the U.S. Government supports. Before TLDs are added, there may have to be a review of the existing TLDs to see where they stand from a business ethics and operational standards point of view. In some cases, 2 letter TLDs may need to be removed from the legacy Root Name Servers. How this should be handled needs to be debated by the people actively involved in the Registry Industry. - Jim Fleming Unir Corporation IBC, Tortola, BVI http://www.nic.vi -------- Logged at Mon Apr 27 22:47:06 MET DST 1998 --------- From jbroom at manta.outremer.com Mon Apr 27 22:57:46 1998 From: jbroom at manta.outremer.com (John Charles Broomfield) Date: Mon, 27 Apr 1998 16:57:46 -0400 (AST) Subject: Should Two Letter TLDs Be Immune ? In-Reply-To: <01BD71F0.09644D60@pc.unir.net> from "Jim Fleming" at Apr 27, 98 03:20:38 pm Message-ID: <199804272057.QAA07019@manta.outremer.com> Hi Jim, > People seem to have no problem allowing the 2 letter TLDs > to be grandfathered to have immunity from the Green Paper > and the U.S. Government. The assumption appears to be > that the 2 letter TLDs have been delegated to individuals, > companies and in some cases governments with care. This > is not necessarily the case. Resume of rest of message just to save space (If I've got it wrong, just say so): National TLDs should be regulated in the same way as gTLDs because not all of them are functioning correctly. I disagree VERY strongly. I think there are few areas where one can say there is high consensus (not just general or rough) in the DNS area, but one of these rare areas is that most people agree that 2 letter (or national) TLDs are a local matter, where local means the area described by the 2 letters in ISO-3166. The unwritten (is it not yet official?) addendum to RFC-1591 gives ultimate authority in 2 letter TLDs to the government of that area. This in fact means that the local government is sovereign for how any given 2 letter TLD is run. Oh, so you don't like how .cn is run? Do you think China would accept someone from outside telling them what to do with it? Maybe you dislike Tonga running ".to" as a "how-to" TLD? Trying to interfere with how separate 2 letter TLDs are run is like trying to impose how each country should run it's census or it's telephone system. However, drawing up a set of specifications which are DESIRABLE and RECOMENDABLE is probably a very good idea, and would go a long way in solving the problems you pointed out. I feel however that enforcement and/or regulation should be left out of it. Yours, John Broomfield. GP & MQ NIC -------- Logged at Mon Apr 27 23:07:02 MET DST 1998 --------- From JimFleming at doorstep.unety.net Mon Apr 27 22:48:06 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Mon, 27 Apr 1998 15:48:06 -0500 Subject: Should Two Letter TLDs Be Immune ? Message-ID: <01BD71F3.DF9AD5E0@pc.unir.net> On Monday, April 27, 1998 11:57 AM, John Charles Broomfield[SMTP:jbroom at manta.outremer.com] wrote: @ @Hi Jim, @ @> People seem to have no problem allowing the 2 letter TLDs @> to be grandfathered to have immunity from the Green Paper @> and the U.S. Government. The assumption appears to be @> that the 2 letter TLDs have been delegated to individuals, @> companies and in some cases governments with care. This @> is not necessarily the case. @ @The unwritten (is it not yet official?) addendum to RFC-1591 gives ultimate @authority in 2 letter TLDs to the government of that area. @This in fact means that the local government is sovereign for how any given @2 letter TLD is run. You seem to be making the assumption that the 2 letter TLDs are delegated to people endorsed/supervised by the government that the TLD supposedly is assigned to...is that the case ? - Jim Fleming Unir Corporation IBC, Tortola, BVI http://www.nic.vi -------- Logged at Mon Apr 27 23:18:35 MET DST 1998 --------- From steve at domainbank.net Mon Apr 27 23:17:57 1998 From: steve at domainbank.net (Steve Heflin) Date: Mon, 27 Apr 1998 17:17:57 -0400 (EDT) Subject: Should Two Letter TLDs Be Immune ? In-Reply-To: <199804272057.QAA07019@manta.outremer.com> Message-ID: In concept - I agree with you Jim. But in realistic application, I agree with you John:) It is a matter of "You can't tell me how to run the Registry for my country." - just wouldn't go over well in the very countries that may be mismanaging their registry. Now, making a statement of registry guidelines and recommendations, that is good idea. How do we proceed? > > However, drawing up a set of specifications which are DESIRABLE and > RECOMENDABLE is probably a very good idea, and would go a long way in > solving the problems you pointed out. I feel however that enforcement and/or > regulation should be left out of it. > > Yours, John Broomfield. > GP & MQ NIC > Regards Steve Heflin Domain Bank, Inc. IDomains, Inc. -------- Logged at Mon Apr 27 23:24:29 MET DST 1998 --------- From JimFleming at doorstep.unety.net Mon Apr 27 23:18:51 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Mon, 27 Apr 1998 16:18:51 -0500 Subject: Should Two Letter TLDs Be Immune ? Message-ID: <01BD71F8.2B81D900@pc.unir.net> On Monday, April 27, 1998 12:17 PM, Steve Heflin[SMTP:steve at domainbank.net] wrote: @ @Now, making a statement of registry guidelines and recommendations, that @is good idea. How do we proceed? @> For starters, I think that the contact information for the TLD should be an actual government contact. The problem that I see with this is that it may be very difficult to find anyone in some of the government agencies that knows anything about the TLD delegation or the Registry Industry. What would you do in that case ? Will there be two-letter TLDs that are non-government ? (i.e. privately held) - Jim Fleming Unir Corporation IBC, Tortola, BVI http://www.nic.vi -------- Logged at Mon Apr 27 23:38:19 MET DST 1998 --------- From steve at domainbank.net Mon Apr 27 23:37:54 1998 From: steve at domainbank.net (Steve Heflin) Date: Mon, 27 Apr 1998 17:37:54 -0400 (EDT) Subject: Should Two Letter TLDs Be Immune ? In-Reply-To: <01BD71F8.2B81D900@pc.unir.net> Message-ID: Why don't we establish a set of guidelines or purported guidelines we feel may be pertinent, *then* move forward with issues regarding each? [not purposely avoiding the question] ;) > > For starters, I think that the contact information > for the TLD should be an actual government contact. > > The problem that I see with this is that it may be very > difficult to find anyone in some of the government > agencies that knows anything about the TLD delegation > or the Registry Industry. > > What would you do in that case ? > > Will there be two-letter TLDs that are non-government ? (i.e. privately held) > > - > Jim Fleming > Unir Corporation > IBC, Tortola, BVI > > http://www.nic.vi > > Regards Steve Heflin Domain Bank, Inc. IDomains, Inc. -------- Logged at Mon Apr 27 23:55:07 MET DST 1998 --------- From jbroom at manta.outremer.com Tue Apr 28 00:04:25 1998 From: jbroom at manta.outremer.com (John Charles Broomfield) Date: Mon, 27 Apr 1998 18:04:25 -0400 (AST) Subject: Should Two Letter TLDs Be Immune ? In-Reply-To: <01BD71F3.DF9AD5E0@pc.unir.net> from "Jim Fleming" at Apr 27, 98 03:48:06 pm Message-ID: <199804272204.SAA08684@manta.outremer.com> Jim Fleming wrote: > On Monday, April 27, 1998 11:57 AM, John Charles Broomfield[SMTP:jbroom at manta.outremer.com] wrote: > @ > @Hi Jim, > @ > @> People seem to have no problem allowing the 2 letter TLDs > @> to be grandfathered to have immunity from the Green Paper > @> and the U.S. Government. The assumption appears to be > @> that the 2 letter TLDs have been delegated to individuals, > @> companies and in some cases governments with care. This > @> is not necessarily the case. > @ > > @The unwritten (is it not yet official?) addendum to RFC-1591 gives ultimate > @authority in 2 letter TLDs to the government of that area. > @This in fact means that the local government is sovereign for how any given > @2 letter TLD is run. > > You seem to be making the assumption that the 2 letter TLDs > are delegated to people endorsed/supervised by the government > that the TLD supposedly is assigned to...is that the case ? No, of course it's not the case in many TLD assignments. However, in ALL cases, the local government has the possibility of endorsing/supervising/reassigning their TLD. To do it or not is their choice. It is true that many countries are probably not aware that they can do this, so it would be up to the local users of that TLD to inform their own authority about this power, should it be needed... Note that correctly or badly managed depends on the view of each person. I think it would be correct to state that a badly managed TLD is one where the direct users are generally unhappy about how that TLD is being managed. If they ARE unhappy, then they WILL inform their government sooner rather than later. From that moment onwards, the government DOES know that it can do something. Should it choose to do nothing, then it's already exercising it's authority, so trying to argue that the government doesn't KNOW is in fact false... For you and me a mismanaged TLD is probably something important which should be dealt with. Some governments probably can't see the importance of it (yet?), but that doesn't give legitimacy to someone from outside trying to take it over. Yours, John Broomfield. GP & MQ NIC. -------- Logged at Tue Apr 28 00:33:05 MET DST 1998 --------- From JimFleming at doorstep.unety.net Tue Apr 28 00:27:34 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Mon, 27 Apr 1998 17:27:34 -0500 Subject: Should Two Letter TLDs Be Immune ? Message-ID: <01BD7201.C49254E0@pc.unir.net> On Monday, April 27, 1998 1:04 PM, John Charles Broomfield[SMTP:jbroom at manta.outremer.com] wrote: from "Jim Fleming" at Apr 27, 98 05:27:34 pm Message-ID: <199804272306.TAA10171@manta.outremer.com> Jim Fleming wrote: > On Monday, April 27, 1998 1:04 PM, John Charles Broomfield[SMTP:jbroom at manta.outremer.com] wrote: > For you and me a mismanaged TLD is probably something > @important which should be dealt with. Some governments probably can't see > @the importance of it (yet?), but that doesn't give legitimacy to someone > @from outside trying to take it over. > @ > > Just as the computer security experts will tell you.... > the people on the "outside" may not be nearly as big > a problem as the people on the "inside". :) > While I understand the history of the 2 letter TLDs, I am > not sure that you can enforce anything beyond what will > become common in the generic TLDs. Also, in the end > the Root Name Server Cluster operators make the decision > and they may not know who has the endorsement of the > government and who does not. Your idea about how DNS is going to evolve, and my idea about it are quite different. That could be a reason of why you have different views than me on how they should be managed. > Would you be in favor of requiring that some "official" > statement/letter/etc. from a real government official > be scanned and placed on the web site ? Who "requires" it? Note that now, nearly all 2 letter TLDs *are* delegated, so I presume you are saying that you would require it of the CURRENT TLDs. You want IANA to require it? And what if the administrators of the TLD either can't be bothered, or basically can't find anyone in the local government that can be bothered to give an official statement? Probably the same TLDs which you are trying to fix would be the ones who you wouldn't be able to get an "official" government statement from. So what do you do? You kick them out of the IANA root (or whatever root) for not getting that statement/letter/etc? Suddenly from having a (in you view) mismanaged TLD, you suddenly have a bunch of orphan SLDs... On the other hand if you had required many of the current country-code TLDs to get an official endorsement BEFORE being allowed to setup the TLD, probably half of them today wouldn't be running. No, I don't think it is a good idea to REQUIRE the statement. However, having the statement/letter/whatever would be a good recomendation, and I'm sure that most TLD admins would be very proud to produce something like that... Yours, John Broomfield. GP & MQ NIC -------- Logged at Tue Apr 28 01:36:37 MET DST 1998 --------- From JimFleming at doorstep.unety.net Tue Apr 28 01:26:13 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Mon, 27 Apr 1998 18:26:13 -0500 Subject: Should Two Letter TLDs Be Immune ? Message-ID: <01BD7209.F6122BA0@pc.unir.net> On Monday, April 27, 1998 12:37 PM, Steve Heflin[SMTP:steve at domainbank.net] wrote: @Why don't we establish a set of guidelines or purported guidelines we feel @may be pertinent, *then* move forward with issues regarding each? @ @[not purposely avoiding the question] ;) @ One of the things that I have advocated in the past is the 2+2+4 Trustee structure. This is a structure that allows 8 people to be identified as the delegates of a resource such as a TLD. 5_________ 3_________ 6_________ 1_________ 2_________ 7_________ 4_________ 8_________ With this structure the people in the #1 and #2 positions are viewed as the co-Trustees and share the job. They speak for the TLD when an official statement is needed. Each of them has an assistant (#3 and #4). Then each of those people has two people to help provide more community coverage and voices. I wonder if each of the 2 letter TLDs could publish such a list ? - Jim Fleming Unir Corporation IBC, Tortola, BVI http://www.nic.vi -------- Logged at Tue Apr 28 03:00:56 MET DST 1998 --------- From steve at domainbank.net Tue Apr 28 03:00:34 1998 From: steve at domainbank.net (Steve Heflin) Date: Mon, 27 Apr 1998 21:00:34 -0400 (EDT) Subject: Should Two Letter TLDs Be Immune ? In-Reply-To: <01BD7209.F6122BA0@pc.unir.net> Message-ID: It goes back to the original comment. Good idea, we can suggest it but we cannot force them to do it. On Mon, 27 Apr 1998, Jim Fleming wrote: > On Monday, April 27, 1998 12:37 PM, Steve Heflin[SMTP:steve at domainbank.net] wrote: > @Why don't we establish a set of guidelines or purported guidelines we feel > @may be pertinent, *then* move forward with issues regarding each? > @ > @[not purposely avoiding the question] ;) > @ > > One of the things that I have advocated in the past > is the 2+2+4 Trustee structure. This is a structure > that allows 8 people to be identified as the delegates > of a resource such as a TLD. > > 5_________ > 3_________ > 6_________ > 1_________ > 2_________ > 7_________ > 4_________ > 8_________ > > > With this structure the people in the #1 and #2 positions > are viewed as the co-Trustees and share the job. They > speak for the TLD when an official statement is needed. > Each of them has an assistant (#3 and #4). Then each > of those people has two people to help provide more > community coverage and voices. > > I wonder if each of the 2 letter TLDs could publish such > a list ? > > > - > Jim Fleming > Unir Corporation > IBC, Tortola, BVI > > http://www.nic.vi > > Regards Steve Heflin Domain Bank, Inc. IDomains, Inc. -------- Logged at Tue Apr 28 03:08:00 MET DST 1998 --------- From JimFleming at doorstep.unety.net Tue Apr 28 03:02:36 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Mon, 27 Apr 1998 20:02:36 -0500 Subject: Should Two Letter TLDs Be Immune ? Message-ID: <01BD7217.6D113360@pc.unir.net> Yes, voluntary participation is the best way to go, plus local "neighbor net" approaches. That is one of the ways that I propose to build CARIBNIC.NET. It will be a way to link all of the participants in the Internet in the Caribbean. This can help everyone understand how the Internet resources are being managed via a common pooling of information for the TLDs and IP allocations for the region. JF On Monday, April 27, 1998 4:00 PM, Steve Heflin[SMTP:steve at domainbank.net] wrote: @It goes back to the original comment. @ @Good idea, we can suggest it but we cannot force them to do it. @ @On Mon, 27 Apr 1998, Jim Fleming wrote: @ @> On Monday, April 27, 1998 12:37 PM, Steve Heflin[SMTP:steve at domainbank.net] wrote: @> @Why don't we establish a set of guidelines or purported guidelines we feel @> @may be pertinent, *then* move forward with issues regarding each? @> @ @> @[not purposely avoiding the question] ;) @> @ @> @> One of the things that I have advocated in the past @> is the 2+2+4 Trustee structure. This is a structure @> that allows 8 people to be identified as the delegates @> of a resource such as a TLD. @> @> 5_________ @> 3_________ @> 6_________ @> 1_________ @> 2_________ @> 7_________ @> 4_________ @> 8_________ @> @> @> With this structure the people in the #1 and #2 positions @> are viewed as the co-Trustees and share the job. They @> speak for the TLD when an official statement is needed. @> Each of them has an assistant (#3 and #4). Then each @> of those people has two people to help provide more @> community coverage and voices. @> @> I wonder if each of the 2 letter TLDs could publish such @> a list ? @> @> @> - @> Jim Fleming @> Unir Corporation @> IBC, Tortola, BVI @> @> http://www.nic.vi @> @> @ @Regards @ @Steve Heflin @Domain Bank, Inc. @IDomains, Inc. @ @ @ - Jim Fleming Unir Corporation IBC, Tortola, BVI http://www.nic.vi -------- Logged at Tue Apr 28 04:44:13 MET DST 1998 --------- From JimFleming at doorstep.unety.net Tue Apr 28 04:38:43 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Mon, 27 Apr 1998 21:38:43 -0500 Subject: Should Two Letter TLDs Be Immune ? Message-ID: <01BD7224.DA791780@pc.unir.net> On Monday, April 27, 1998 12:37 PM, Steve Heflin[SMTP:steve at domainbank.net] wrote: @Why don't we establish a set of guidelines or purported guidelines we feel @may be pertinent, *then* move forward with issues regarding each? @ You might want to "suggest" that 2 letter TLD registries get on-board with some whois technology. There are several choices out there. RIPE is Perl-based. NSI's offering is compiled C. I believe that NSI and Microsoft recently announced some sort of joint partnership in this area. If we look at the Internet as one huge object-oriented computer system, then many of the registry data base issues would fall out. Unfortunately, most of the emphasis in the Internet is still on "Protocols" vs. "Platforms". If we could change this, we might be able to help make it easier for the 2 letter TLD registries who likely just want something that is turn-key and works without requiring an Internet mechanic to be on call. - Jim Fleming Unir Corporation IBC, Tortola, BVI http://www.nic.vi -------- Logged at Tue Apr 28 08:48:17 MET DST 1998 --------- From hank at ibm.net.il Tue Apr 28 09:46:23 1998 From: hank at ibm.net.il (Hank Nussbacher) Date: Tue, 28 Apr 1998 09:46:23 +0200 Subject: Should Two Letter TLDs Be Immune ? Message-ID: <2.2.32.19980428074623.006c4a4c@max.ibm.net.il> At 03:20 PM 4/27/98 -0500, Jim Fleming wrote: In your opinion? Want to make a mess of nTLDs as has happened to gTLDs? RFC1591 defines specific rules as to what is allowed or not allowed. To quote: 3) The designated manager must be equitable to all groups in the domain that request domain names. This means that the same rules are applied to all requests, all requests must be processed in a non-discriminatory fashion, and academic and commercial (and other) users are treated on an equal basis. No bias shall be shown regarding requests that may come from customers of some other business related to the manager -- e.g., no preferential service for customers of a particular data network provider. There can be no requirement that a particular mail system (or other application), protocol, or product be used. 4) Significantly interested parties in the domain should agree that the designated manager is the appropriate party. The IANA tries to have any contending parties reach agreement among themselves, and generally takes no action to change things unless all the contending parties agree; only in cases where the designated manager has substantially mis-behaved would the IANA step in. However, it is also appropriate for interested parties to have some voice in selecting the designated manager. There are two cases where the IANA and the central IR may establish a new top-level domain and delegate only a portion of it: (1) there are contending parties that cannot agree, or (2) the applying party may not be able to represent or serve the whole country. The later case sometimes arises when a party outside a country is trying to be helpful in getting networking started in a country -- this is sometimes called a "proxy" DNS service. The Internet DNS Names Review Board (IDNB), a committee established by the IANA, will act as a review panel for cases in which the parties can not reach agreement among themselves. The IDNB's decisions will be binding. Believe me, if a gov't finds that some Unir organization has appropriated it's nTLD and is running it into the ground - they will find the way to take it over. Everyone, Jim has always been and always will be an "agent provocateur". Lets just ignore his ramblings and leave the matter alone. -hank > >People seem to have no problem allowing the 2 letter TLDs >to be grandfathered to have immunity from the Green Paper >and the U.S. Government. The assumption appears to be >that the 2 letter TLDs have been delegated to individuals, >companies and in some cases governments with care. This >is not necessarily the case. > >In my opinion, the 2 letter TLDs should be treated as generic >tags and should not be given a pass when it comes to requirements >for stable governance and operational excellence. If this is not >done, consumers may be mislead that 2 letter TLDs have the >same industry oversight via the IANA Inc. and self-regulation. >Consumers may find that they are subjected to arbitrary policies, >predatory price increases and shoddy operations unless they >are warned that 2 letter TLDs are immune from IANA Inc. oversight. >This will not be a good thing and may cause well-run 2 letter >TLDs to suffer because of the unsatisfactory practices of a few, >poorly managed 2 letter TLDs. > >Of course, part of the problem is defining what poorly managed >means. In some parts of the world business practices may be >tolerated that are not common in the U.S. For example, people >may choose to discriminate based on a variety of reasons. One >of the most obvious is that companies supporting the government >obtain .TLD registrations and those that do not are excluded. > >Much of this assumes that the government is the current delegate >of the 2 letter TLDs. As the domain name debates rage on we >find more and more that governments do not have a clue what is >happening with the 2 letter TLD that was supposedly delegated to >them. Instead, we find that the 2 letter TLDs have been casually >delegated to people and companies that gave the right impression >of representing the government or local people but who actually >use the TLD for their own business purposes. > >None of these things can be easily fixed and there may be no >need to fix them IF the consumer is alerted to this situation. >Unfortunately, the Green Paper and the IANA Inc. might end >up sending the wrong message if they require generic TLDs to >be held to one standard while 2 letter TLDs are immune. In my >opinion, all of the TLDs should be held to the same high standards >of business ethics and operational integrity as agreed upon >by the Registry Industry. The question remains as to how to do >this...? > >To date much of the focus has been on ADDING TLDs to the >legacy Root Name Servers that the U.S. Government supports. >Before TLDs are added, there may have to be a review of the >existing TLDs to see where they stand from a business ethics >and operational standards point of view. In some cases, 2 letter >TLDs may need to be removed from the legacy Root Name >Servers. How this should be handled needs to be debated by >the people actively involved in the Registry Industry. > > >- >Jim Fleming >Unir Corporation >IBC, Tortola, BVI > >http://www.nic.vi > > > > -------- Logged at Tue Apr 28 19:43:34 MET DST 1998 --------- From JimFleming at doorstep.unety.net Tue Apr 28 19:18:22 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Tue, 28 Apr 1998 12:18:22 -0500 Subject: Should Two Letter TLDs Be Immune ? Message-ID: <01BD729F.BD619F20@pc.unir.net> Dear Mr. Nussbacher, As a distinguished member of the Blue Ribbon IAHC panel that developed the ITU/ISOC/IAHC/CORE/POC/PAB proposal your comments carry a lot of weight. It is nice to see that you are still active in these forums. It is also nice that the European community supports these discussions via RIPE. As you know, there are many debates going on with respect to the management of Top Level Domains. The United States Government has decided to help bring an end to the confusion caused by the IAHC and the attempts to move the control of domains to Switzerland and the ITU. The U.S. Government, via the Department of Commerce has published its Green Paper outlining their proposals. Many people have commented in open forums like these. As the final plans for the U.S. Government's actions come together, there are many details that need to be worked out. As I have pointed out below, there could be problems in not addressing the 2 letter (so-called country code) TLDs more directly in the USG process. One of the main reasons is that 2 letter TLDs are quickly becoming generic. I offer and as only a couple of examples. One of the other major problems is the perception on the part of the consumers that government agencies "back" the operations of the 2 letter TLDs. We all know this is not the case, and in my opinion it would be wrong to have consumers mislead into thinking that a registration in a TLD will be MORE stable than so-called gTLDs. In looking for an example, the United States Government does not have to venture far from home. They can turn to the United States Virgin Islands (.VI) where Bill Clinton and his family regularly vacation. In looking at the .VI TLD several questions can be asked. Which government controls that TLD ? Is it the local USVI government or the United States Federal Government ? Also, the question should be raised about local stakeholder participation. If you happen to visit the Virgin Islands or some of the web sites, you might find that local people have a perception that the .VI TLD will be blown away with a hurricane and therefore the .COM/.NET/.ORG domains are preferred. Beyond this, there is another local issue and that is, does the .VI TLD cover the "Virgin Islands" or just the U.S. Virgin Islands ? Again, if you return to the local culture and you consult with truely local inhabitants, you will find that the term Virgin Islands for them implies BOTH the U.S. and British Virgin Islands. They view the government boundaries that have been imposed as legal but not cultural. This is EXACTLY the view that many Internet leaders try to claim should be the basis for domain boundaries. It seems inconsistent for people to be claiming that domains cover a group of stakeholders and do not stop at government and legal boundaries, and then turn around and claim that some TLDs (like the 2 letter ones) do have hard legal/government boundaries. It also seems inconsistent to have many 2 letter TLDs which are now truely generic, while people try to claim they are still tied to a government. In closing, I suggest that the United States Government use the United States Virgin Islands (.VI) TLD as an example to guide the rest of the world. As the U.S. rolls out its Department of Commerce rules, I would hope they make sure that ALL of the United States conforms to those rules. It would not be correct for the U.S. to be imposing rules on the rest of the world when they do not follow them themselves. Jim Fleming Unir Corporation P.S. With regard to your comments about Unir. You might be interested to know that Unir intends to help "build up" and beef up current TLD registries. and future TLD registries. With over 240 TLDs currently recognized by the U.S. Government there is need for everyone in the Registry Industry to try to help bring it to a higher level of operational excellence. Unir will continue to try to do that despite your viewpoint. On Tuesday, April 28, 1998 2:46 AM, Hank Nussbacher[SMTP:hank at ibm.net.il] wrote: @At 03:20 PM 4/27/98 -0500, Jim Fleming wrote: @ @In your opinion? Want to make a mess of nTLDs as has happened to gTLDs? @RFC1591 defines specific rules as to what is allowed or not allowed. @ @To quote: @ @3) The designated manager must be equitable to all groups in the @ domain that request domain names. @ @ This means that the same rules are applied to all requests, all @ requests must be processed in a non-discriminatory fashion, and @ academic and commercial (and other) users are treated on an equal @ basis. No bias shall be shown regarding requests that may come @ from customers of some other business related to the manager -- @ e.g., no preferential service for customers of a particular data @ network provider. There can be no requirement that a particular @ mail system (or other application), protocol, or product be used. @ @4) Significantly interested parties in the domain should agree that @ the designated manager is the appropriate party. @ @ The IANA tries to have any contending parties reach agreement @ among themselves, and generally takes no action to change things @ unless all the contending parties agree; only in cases where the @ designated manager has substantially mis-behaved would the IANA @ step in. @ @ However, it is also appropriate for interested parties to have @ some voice in selecting the designated manager. @ @ There are two cases where the IANA and the central IR may @ establish a new top-level domain and delegate only a portion of @ it: (1) there are contending parties that cannot agree, or (2) the @ applying party may not be able to represent or serve the whole @ country. The later case sometimes arises when a party outside a @ country is trying to be helpful in getting networking started in a @ country -- this is sometimes called a "proxy" DNS service. @ @ The Internet DNS Names Review Board (IDNB), a committee @ established by the IANA, will act as a review panel for cases in @ which the parties can not reach agreement among themselves. The @ IDNB's decisions will be binding. @ @Believe me, if a gov't finds that some Unir organization has appropriated @it's nTLD and is running it into the ground - they will find the way to take @it over. @ @Everyone, Jim has always been and always will be an "agent provocateur". @Lets just ignore his ramblings and leave the matter alone. @ @-hank @ @ @> @>People seem to have no problem allowing the 2 letter TLDs @>to be grandfathered to have immunity from the Green Paper @>and the U.S. Government. The assumption appears to be @>that the 2 letter TLDs have been delegated to individuals, @>companies and in some cases governments with care. This @>is not necessarily the case. @> @>In my opinion, the 2 letter TLDs should be treated as generic @>tags and should not be given a pass when it comes to requirements @>for stable governance and operational excellence. If this is not @>done, consumers may be mislead that 2 letter TLDs have the @>same industry oversight via the IANA Inc. and self-regulation. @>Consumers may find that they are subjected to arbitrary policies, @>predatory price increases and shoddy operations unless they @>are warned that 2 letter TLDs are immune from IANA Inc. oversight. @>This will not be a good thing and may cause well-run 2 letter @>TLDs to suffer because of the unsatisfactory practices of a few, @>poorly managed 2 letter TLDs. @> @>Of course, part of the problem is defining what poorly managed @>means. In some parts of the world business practices may be @>tolerated that are not common in the U.S. For example, people @>may choose to discriminate based on a variety of reasons. One @>of the most obvious is that companies supporting the government @>obtain .TLD registrations and those that do not are excluded. @> @>Much of this assumes that the government is the current delegate @>of the 2 letter TLDs. As the domain name debates rage on we @>find more and more that governments do not have a clue what is @>happening with the 2 letter TLD that was supposedly delegated to @>them. Instead, we find that the 2 letter TLDs have been casually @>delegated to people and companies that gave the right impression @>of representing the government or local people but who actually @>use the TLD for their own business purposes. @> @>None of these things can be easily fixed and there may be no @>need to fix them IF the consumer is alerted to this situation. @>Unfortunately, the Green Paper and the IANA Inc. might end @>up sending the wrong message if they require generic TLDs to @>be held to one standard while 2 letter TLDs are immune. In my @>opinion, all of the TLDs should be held to the same high standards @>of business ethics and operational integrity as agreed upon @>by the Registry Industry. The question remains as to how to do @>this...? @> @>To date much of the focus has been on ADDING TLDs to the @>legacy Root Name Servers that the U.S. Government supports. @>Before TLDs are added, there may have to be a review of the @>existing TLDs to see where they stand from a business ethics @>and operational standards point of view. In some cases, 2 letter @>TLDs may need to be removed from the legacy Root Name @>Servers. How this should be handled needs to be debated by @>the people actively involved in the Registry Industry. @> @> - Jim Fleming Unir Corporation IBC, Tortola, BVI http://vi.unir.net -------- Logged at Tue Apr 28 22:46:40 MET DST 1998 --------- From tor at wtv.net Tue Apr 28 23:45:55 1998 From: tor at wtv.net (Bob Allisat) Date: Tue, 28 Apr 1998 16:45:55 -0500 Subject: Small Name Services Providers In-Reply-To: <01BD729F.BD619F20@pc.unir.net> Message-ID: I will take this opportunity to address the assembled in regards to a small profit and not for profit domain name registries we are evolving. If you visit our Free Community Network WWW Site at you will see a working prototype of a free independant no profit Name Services Provider (NSP). The script works and we are already registering domains under *.FCN.NET. All we are waiting for is to drop the .NET part and to have our .FCN domains entered directly in the various root name servers. While .FCN is non-profit I intend to follow up with a for profit .WTV NSP in the future. While a commercial NSP will require a higher level of capitalization my estimates are no-where near the wildly exagerated models that have been hurled about in discussions past. Once again a role for small businesses as NSP's must be assured or you folks will force those who wish to peacefully and respectfully pursue their own modest goals as NSPs into very negative positions. What we have proven is that individuals taking on the loose, co-operative and helpful structure of the traditional internet *can* run a Name Services. Provider. Our place in the general scheme of Internet Governance must be safeguarded among other, similar small or independant NSPs. To attempt to monopolize the process or limit it to multinational corporate entities is rude and out of sych with the culture of the Net. Furthermore it will be unsucessful and we will be forced to unproductively fight for our rights. We expect to pursue our respectful, reasonable and fair activities in a manner equal to anyone else. To fail to support our legitimate role is unhealthy as it is unwise. Name Services Providers will come in many forms, with many flavours. There is room for the small as for the large. There is plenty of space for both profit NSPs and non-profit NSPs. Any and all exclusionary Internet Governance structures will be resisted and overthrown as they should be. And this will be accomplished not by duress or denial of service - though force us and it may be a last resort. Before we follow Eugene's path we will work simply to route around any silly restrictions by means of applied intelligence, overwhelming numbers and by simply ignoring rules that choke and inhibit our communications. As they say... one way or the other we shall overcome I thank Jim for this opportunity to share my views and encourage all reasonable minds to bend and include as wide a range of NSPs as possible. Peace and good fortune to you all. Bob Allisat Director, World TeleVirtual Network bob at wtv.net - (416) 534-1999 - http://www.wtv.net -------- Logged at Wed Apr 29 06:19:37 MET DST 1998 --------- From pdeblanc at usvi.net Wed Apr 29 05:19:15 1998 From: pdeblanc at usvi.net (Peter deBlanc) Date: Wed, 29 Apr 1998 00:19:15 -0300 Subject: Small Name Services Providers References: Message-ID: <35469C32.1E2E024E@usvi.net> Thanks Bob, for your comments on this interesting concept. I have always promoted public service internet access. In fact, my paper for the Internet Society conference in Hawaii in 1995 was about a funding model for public internet access in developing countries. After spending 5 years working for the United Nations in such countries in the Caribbean, It became clear that some method was needed to bridge the gap between "information haves" and information have-nots". I am all in favor of profitable enterprise. And I subscribe to the concept that pro bono service is a responsibility of the mature professional. You (all on the list) may be interested in reading my paper, "Networking the Caribbean via the VIP FreeNet" at http://www.usvi.net/cobex/inet95 As an update, there are now 3,000 plus registered FreeNet users, and the VIP FreeNet has served over 500,000 user sessions, average 45 minutes, since Sept 8, 1994! Regards to all Peter de Blanc (personal page at http://www.usvi.net/cobex/people/peter ) Bob Allisat wrote: > I will take this opportunity to address the > assembled in regards to a small profit and not > for profit domain name registries we are evolving. > If you visit our Free Community Network WWW Site > at you will see a working > prototype of a free independant no profit Name > Services Provider (NSP). -------- Logged at Wed Apr 29 06:40:17 MET DST 1998 --------- From JimFleming at doorstep.unety.net Wed Apr 29 06:30:47 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Tue, 28 Apr 1998 23:30:47 -0500 Subject: Small Name Services Providers Message-ID: <01BD72FD.AC8F3280@pc.unir.net> On Tuesday, April 28, 1998 10:19 PM, Peter deBlanc[SMTP:pdeblanc at usvi.net] wrote: @Thanks Bob, for your comments on this interesting concept. I have always @promoted public service internet access. In fact, my paper for the @Internet Society conference in Hawaii in 1995 was about a funding model @for public internet access in developing countries. After spending 5 @years working for the United Nations in such countries in the Caribbean, @It became clear that some method was needed to bridge the gap between @"information haves" and information have-nots". I am all in favor of @profitable enterprise. And I subscribe to the concept that pro bono @service is a responsibility of the mature professional. @ @You (all on the list) may be interested in reading my paper, "Networking @the Caribbean via the VIP FreeNet" @ @at http://www.usvi.net/cobex/inet95 @ People might also be interested in this lecture or other similar developments in the Virgin Islands and the Caribbean. @@@@ http://bviwelcome.com/limin/upcome.html May 8 - COLLEGE LECTURE SERIES - Lecture at 5:30 p.m) "Small Island Developing States in the Global Economy: Can the BVI Be a model for the development of other island economies?" by Pierre Encontre of the United Nations Conference on Trade and Development based in Switzerland. Information: 284-494-4994 (date tentative @@@@@@@@@@@@@@@@@@@@@@@@ - Jim Fleming Unir Corporation IBC, Tortola, BVI http://vi.unir.net -------- Logged at Wed Apr 29 12:36:47 MET DST 1998 --------- From tor at wtv.net Tue Apr 28 23:45:55 1998 From: tor at wtv.net (Bob Allisat) Date: Tue, 28 Apr 1998 16:45:55 -0500 Subject: Small Name Services Providers In-Reply-To: <01BD729F.BD619F20@pc.unir.net> Message-ID: I will take this opportunity to address the assembled in regards to a small profit and not for profit domain name registries we are evolving. If you visit our Free Community Network WWW Site at you will see a working prototype of a free independant no profit Name Services Provider (NSP). The script works and we are already registering domains under *.FCN.NET. All we are waiting for is to drop the .NET part and to have our .FCN domains entered directly in the various root name servers. While .FCN is non-profit I intend to follow up with a for profit .WTV NSP in the future. While a commercial NSP will require a higher level of capitalization my estimates are no-where near the wildly exagerated models that have been hurled about in discussions past. Once again a role for small businesses as NSP's must be assured or you folks will force those who wish to peacefully and respectfully pursue their own modest goals as NSPs into very negative positions. What we have proven is that individuals taking on the loose, co-operative and helpful structure of the traditional internet *can* run a Name Services. Provider. Our place in the general scheme of Internet Governance must be safeguarded among other, similar small or independant NSPs. To attempt to monopolize the process or limit it to multinational corporate entities is rude and out of sych with the culture of the Net. Furthermore it will be unsucessful and we will be forced to unproductively fight for our rights. We expect to pursue our respectful, reasonable and fair activities in a manner equal to anyone else. To fail to support our legitimate role is unhealthy as it is unwise. Name Services Providers will come in many forms, with many flavours. There is room for the small as for the large. There is plenty of space for both profit NSPs and non-profit NSPs. Any and all exclusionary Internet Governance structures will be resisted and overthrown as they should be. And this will be accomplished not by duress or denial of service - though force us and it may be a last resort. Before we follow Eugene's path we will work simply to route around any silly restrictions by means of applied intelligence, overwhelming numbers and by simply ignoring rules that choke and inhibit our communications. As they say... one way or the other we shall overcome I thank Jim for this opportunity to share my views and encourage all reasonable minds to bend and include as wide a range of NSPs as possible. Peace and good fortune to you all. Bob Allisat Director, World TeleVirtual Network bob at wtv.net - (416) 534-1999 - http://www.wtv.net -------- Logged at Wed Apr 29 12:37:57 MET DST 1998 --------- From pdeblanc at usvi.net Wed Apr 29 05:19:15 1998 From: pdeblanc at usvi.net (Peter deBlanc) Date: Wed, 29 Apr 1998 00:19:15 -0300 Subject: Small Name Services Providers References: Message-ID: <35469C32.1E2E024E@usvi.net> Thanks Bob, for your comments on this interesting concept. I have always promoted public service internet access. In fact, my paper for the Internet Society conference in Hawaii in 1995 was about a funding model for public internet access in developing countries. After spending 5 years working for the United Nations in such countries in the Caribbean, It became clear that some method was needed to bridge the gap between "information haves" and information have-nots". I am all in favor of profitable enterprise. And I subscribe to the concept that pro bono service is a responsibility of the mature professional. You (all on the list) may be interested in reading my paper, "Networking the Caribbean via the VIP FreeNet" at http://www.usvi.net/cobex/inet95 As an update, there are now 3,000 plus registered FreeNet users, and the VIP FreeNet has served over 500,000 user sessions, average 45 minutes, since Sept 8, 1994! Regards to all Peter de Blanc (personal page at http://www.usvi.net/cobex/people/peter ) Bob Allisat wrote: > I will take this opportunity to address the > assembled in regards to a small profit and not > for profit domain name registries we are evolving. > If you visit our Free Community Network WWW Site > at you will see a working > prototype of a free independant no profit Name > Services Provider (NSP). -------- Logged at Wed Apr 29 13:31:33 MET DST 1998 --------- From Niall.oReilly at ucd.ie Wed Apr 29 14:31:17 1998 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Wed, 29 Apr 1998 12:31:17 +0000 Subject: (Fwd) CENTR Technical Workshop Message-ID: <0ES60064JAO5O2@hermes.ucd.ie> I forward for information an interesting announcement from the RIPE CENTR Project co-ordinator. Please note the restrictions on size. Niall O'Reilly ------- Forwarded Message Follows ------- Date: Sun, 26 Apr 1998 19:14:07 +0200 From: Fay Howard Subject: CENTR Technical Workshop To: centr at ripe.net, Timo.Tuuli at thk.fi, Grete.Duna at uninett.no Dear CENTR participants/ccTLDs, Following the positive response at last week's CENTR meeting to the idea of TLD workshops, I am beginning arrangements for the first which will be: Technical Workshop for ccTLDs 25 - 26 June 1998 Venue: RIPE NCC Office, Singel 258, Amsterdam. It is proposed to hold the workshop over two days starting lunch time on Thursday, 25 June and finishing lunchtime on Friday, 26 June. Lunch will be provided on both days and dinner arranged for the Thursday evening. Transport and accommodation costs will be the responsibility of the workshop participants. Places will be limited to 18. If more than 18 applications are received, it will be necessary to limit attendance to one per TLD with preference given to TLDs who have committed to support RIPE CENTR in 1998(first come first served basis). If applications are well in excess of 18 it may be possible to run the workshop again at a later date. The workshop, which is aimed at staff involved in the operational side of running a TLD, will encourage discussion and exchange of experiences. Below are listed some topics to be covered but suggestions for other items are welcomed. Please contact me if you require any further information. If you would like to attend or to nominate suitable colleagues, please complete the application details given at the end of this mail and return to me. Fay Howard RIPE CENTR Project Manager Topics for the Workshop: Registry Databases Each TLD administrator keeps a database of registrations. The technical implementation of this database seems to be differing widely. Under this topic short case studies are presented and a general exchange of experiences follows. Aspects to be covered include - implementation of registry database - human interfaces - generation of DNS zone files - genertaing charging information - statistics Request Tracking TLD administrators process requests for additions, changes and deletions to the TLD registry. How are these requests received? How are they tracked while being processed? How are they documented for future reference? Experiences with request tracking systems. Aspects to be covered include - request origination e-mail / phone / bulk (registrars) - request tracking - human interfaces (external/internal) - request documentation / filing - statistics DNS Operations TLD administrators are responsible for the operation of TLD name servers. There are numerous technical aspects to this. We will look at operational experiences and get some technical presentations about developments in bind software. - zone file maintenance - primary nameserver - secondaries - software issues (bind) - security - load statistics - current developments of NS software (bind) Secure DNS Developments are under way to use public key cryptography to authenticate the origin of DNS zone information in a hierarchical manner. TLD administrators play a key role in its deployment because they are close to the root of the hierarchy. We will present an overview of this new technology and exchange views on its impact on operational procedures. - what ? - why ? - status - operational consequences ---------------------ooooooooOoooooooo--------------- APPLICATION Please complete the following and return to fay at ripe.net Name: Organization: Country: Job Function: Suggestions for Topics to be included other than those mentioned: If space permits or a repeat workshop is arranged, I would also like to nominate: Name: Organization: Country: Job Function: --------------------oooooooOooooooo---------- -------- Logged at Thu Apr 30 03:03:38 MET DST 1998 --------- From JimFleming at doorstep.unety.net Thu Apr 30 02:48:25 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Wed, 29 Apr 1998 19:48:25 -0500 Subject: Small Name Services Providers Message-ID: <01BD73A7.C6AE8260@pc.unir.net> On Tuesday, April 28, 1998 10:19 PM, Peter deBlanc[SMTP:pdeblanc at usvi.net] wrote: @Thanks Bob, for your comments on this interesting concept. I have always @promoted public service internet access. In fact, my paper for the @Internet Society conference in Hawaii in 1995 was about a funding model @for public internet access in developing countries. After spending 5 @years working for the United Nations in such countries in the Caribbean, @It became clear that some method was needed to bridge the gap between @"information haves" and information have-nots". I am all in favor of @profitable enterprise. And I subscribe to the concept that pro bono @service is a responsibility of the mature professional. @ Peter, Do you have any plans to evolve the .VI DNS system to a more production-oriented structure ? As you can see below there are various levels delegated in your TLD Name Servers. This makes it more difficult to have a volume interface similar to the InterNIC where all .COM entries look like the CO.VI entry below: $ORIGIN vi. co IN NS ns1.octagon.net. IN NS ns2.octagon.net. While entries like the following may make sense for a TLD registry that caters to a small number of domains that you are hosting or familiar with, this might be expensive to maintain in a volume (production) situation. ships IN A 208.200.189.167 In other words, one would expect that the name SHIPS.VI would cause an entry with a minimum of 2 name servers (as CO.VI has) and then the delegate for SHIPS.VI would be responsible for handling the traffic for that zone. At the present this is handled on the .VI "root" TLD Name Servers. I bring this up because now is the time to clean-up the .VI zone before it grows. It may be difficult or impossible to do that later. I am interested in your plans to bring the .VI TLD Name Servers to a point where it has a production-grade structure. I am also interested in the criteria for names being entered below the .VI TLD. I have heard the "Free Net" arguments that names are provided for worthy causes. I have also heard the argument that commercial companies should be under CO.VI. As shown below, there does not seem to be a consistent policy for the .VI TLD. What is the current policy for names directly under .VI. Can one assume that ALL names currently under .COM could also be registered under .VI, if those owners desired ? Free Nets seem to have a way of developing Free-Form policies that few people can articulate. Maybe you can work with Bob Allisat on articulating the policy for the .VI TLD. Thanks... Jim Fleming ============================== ; BIND version named 4.9.3-P1 Tue Jan 23 15:41:55 GMT 1996 ; BIND version polk at forge.BSDI.COM:/usr/src/usr.sbin/named/named ; zone 'vi' last serial 0 ; from 198.6.1.65 at Wed Apr 29 14:11:39 1998 $ORIGIN . vi IN SOA ns1.octagon.net. hostmaster.usvi.net. ( 1998042604 21600 1800 1728000 43200 ) IN NS auth00.ns.uu.net. IN NS auth01.ns.uu.net. IN NS ns.ripe.net. IN NS ns1.octagon.net. IN NS ns2.octagon.net. $ORIGIN vi. alexis IN A 208.200.189.133 $ORIGIN alexis.vi. www IN CNAME alexis.vi. $ORIGIN vi. marriott-fr IN A 208.200.189.171 IN MX 10 noc.usvi.net. $ORIGIN marriott-fr.vi. www IN A 208.200.189.171 $ORIGIN vi. tradewinds IN MX 10 noc.usvi.net. IN A 208.200.189.141 $ORIGIN tradewinds.vi. www IN A 208.200.189.141 $ORIGIN st-croix.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN vi. prisco IN MX 5 noc.usvi.net. IN A 208.200.189.156 $ORIGIN prisco.vi. www IN A 208.200.189.156 $ORIGIN vi. rotary IN MX 10 noc.usvi.net. IN A 208.200.189.139 $ORIGIN rotary.vi. www IN CNAME rotary.vi. $ORIGIN vi. imi IN MX 10 noc.usvi.net. ac IN NS ns1.octagon.net. IN NS ns2.octagon.net. pissarro IN A 208.200.189.164 IN MX 10 noc.usvi.net. $ORIGIN pissarro.vi. www IN A 208.200.189.164 $ORIGIN stjohn.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN vi. credit IN NS ns1.webservices.net. IN NS ns2.webservices.net. marriott IN A 208.200.189.170 IN MX 10 noc.usvi.net. $ORIGIN marriott.vi. www IN A 208.200.189.170 $ORIGIN vi. sanddollar IN MX 10 noc.usvi.net. IN A 208.200.189.190 $ORIGIN sanddollar.vi. www IN CNAME sanddollar.vi. $ORIGIN vi. ament IN A 208.200.189.165 IN MX 10 noc.usvi.net. $ORIGIN ament.vi. www IN A 208.200.189.165 $ORIGIN vi. bxicaribbean IN A 208.200.189.187 IN MX 10 noc.usvi.net. $ORIGIN bxicaribbean.vi. www IN CNAME bxicaribbean.vi. $ORIGIN st.thomas.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN vi. gov IN NS ns1.octagon.net. IN NS ns2.octagon.net. soccer-masters IN MX 10 noc.usvi.net. IN A 208.200.189.178 $ORIGIN soccer-masters.vi. www IN CNAME soccer-masters.vi. $ORIGIN vi. coconutcoaststudios IN MX 10 noc.usvi.net. rolexregatta IN MX 10 noc.usvi.net. IN A 208.200.189.173 $ORIGIN rolexregatta.vi. www IN CNAME rolexregatta.vi. $ORIGIN vi. islands IN NS ns1.octagon.net. IN NS ns2.octagon.net. wedus IN MX 10 noc.usvi.net. IN A 208.200.189.184 $ORIGIN wedus.vi. www IN CNAME wedus.vi. $ORIGIN vi. morrett IN MX 10 noc.usvi.net. $ORIGIN morrett.vi. chad IN A 204.199.0.98 $ORIGIN vi. co IN NS ns1.octagon.net. IN NS ns2.octagon.net. ships IN A 208.200.189.167 $ORIGIN ships.vi. www IN A 208.200.189.167 $ORIGIN vi. location IN MX 10 mail.location.vi. IN MX 20 noc.usvi.net. IN A 208.200.189.166 $ORIGIN location.vi. mail IN A 204.199.1.240 IN MX 10 mail.location.vi. IN MX 20 noc.usvi.net. www IN A 208.200.189.166 $ORIGIN vi. hotelboynes IN MX 10 noc.usvi.net. IN A 208.200.189.162 $ORIGIN hotelboynes.vi. www IN CNAME hotelboynes.vi. $ORIGIN vi. wsta IN A 208.200.189.144 IN MX 10 noc.usvi.net. $ORIGIN wsta.vi. www IN A 208.200.189.144 $ORIGIN vi. falcon IN MX 10 noc.usvi.net. CarolLee IN MX 5 noc.usvi.net. IN A 208.200.189.160 $ORIGIN CarolLee.vi. www IN A 208.200.189.160 $ORIGIN vi. octagon IN A 208.200.189.150 IN MX 10 octagon.usvi.net. IN MX 20 noc.usvi.net. $ORIGIN octagon.vi. www IN A 208.200.189.150 $ORIGIN vi. amcup IN MX 10 noc.usvi.net. IN A 208.200.189.179 $ORIGIN amcup.vi. www IN CNAME amcup.vi. $ORIGIN vi. armour IN MX 10 rutabaga.armour.vi. IN MX 20 noc.usvi.net. IN A 208.200.189.183 $ORIGIN armour.vi. impossibleapple IN A 204.199.0.92 peach IN A 204.199.0.95 chocolate IN A 204.199.0.94 cherry IN A 204.199.0.93 rutabaga IN A 204.199.0.90 www IN CNAME armour.vi. mincemeat IN A 204.199.0.97 pumpkin IN A 204.199.0.96 lemon IN A 204.199.0.91 $ORIGIN st.john.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN vi. yachts IN A 208.200.189.132 IN MX 10 noc.usvi.net. $ORIGIN yachts.vi. www IN A 208.200.189.132 $ORIGIN st-thomas.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN vi. marriott-ms IN A 208.200.189.172 IN MX 10 noc.usvi.net. $ORIGIN marriott-ms.vi. www IN A 208.200.189.172 $ORIGIN vi. zbvi IN A 208.200.189.169 IN MX 10 noc.usvi.net. $ORIGIN zbvi.vi. www IN A 208.200.189.169 $ORIGIN vi. davidjones IN MX 10 noc.usvi.net. IN A 208.200.189.191 $ORIGIN davidjones.vi. www IN CNAME davidjones.vi. $ORIGIN vi. k12 IN NS ns1.octagon.net. IN NS ns2.octagon.net. $ORIGIN stcroix.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN vi. royalcaribbean IN MX 10 noc.usvi.net. IN A 208.200.189.10 $ORIGIN royalcaribbean.vi. www IN CNAME royalcaribbean.vi. $ORIGIN st.croix.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN st-john.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN vi. gv IN NS ns1.octagon.net. IN NS ns2.octagon.net. islandvideo IN A 208.200.189.155 IN MX 0 noc.usvi.net. $ORIGIN islandvideo.vi. www IN CNAME islandvideo.vi. $ORIGIN vi. fantasia IN A 208.200.189.147 IN MX 10 noc.usvi.net. $ORIGIN fantasia.vi. www IN A 208.200.189.147 $ORIGIN vi. diusvi IN A 208.200.189.177 IN MX 10 noc.usvi.net. $ORIGIN diusvi.vi. www IN A 208.200.189.177 $ORIGIN vi. jnet IN A 146.226.2.198 IN HINFO "i80586" "FreeBSD" IN MX 0 jnet.vi. $ORIGIN jnet.vi. www IN CNAME jnet.vi. $ORIGIN visit.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN vi. tti IN MX 0 noc.usvi.net. org IN NS ns1.octagon.net. IN NS ns2.octagon.net. $ORIGIN stthomas.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN vi. aquaman IN MX 10 mail.islands.vi. IN A 208.200.189.186 $ORIGIN aquaman.vi. www IN CNAME aquaman.vi. $ORIGIN vi. www IN CNAME redirect.www.usvi.net. windsurfing IN A 208.200.189.157 IN MX 10 noc.usvi.net. $ORIGIN windsurfing.vi. www IN A 208.200.189.157 $ORIGIN vi. iyc IN A 208.200.189.168 IN MX 10 noc.usvi.net. $ORIGIN iyc.vi. www IN A 208.200.189.168 $ORIGIN vi. charterboat IN MX 10 noc.usvi.net. IN A 208.200.189.181 $ORIGIN charterboat.vi. www IN CNAME charterboat.vi. $ORIGIN vi. bcphoto IN A 208.200.189.176 IN MX 10 noc.usvi.net. $ORIGIN bcphoto.vi. www IN A 208.200.189.176 $ORIGIN vi. sunrealty IN MX 10 noc.usvi.net. IN A 208.200.189.182 $ORIGIN sunrealty.vi. www IN CNAME sunrealty.vi. $ORIGIN vi. vitelcom IN NS ns1.octagon.net. IN NS ns2.octagon.net. test IN NS ns1.octagon.net. IN NS ns2.octagon.net. bvimall IN A 208.200.189.135 IN MX 10 noc.usvi.net. $ORIGIN bvimall.vi. www IN A 208.200.189.135 $ORIGIN vi. bushtea IN A 208.200.189.148 IN MX 10 noc.usvi.net. $ORIGIN bushtea.vi. www IN A 208.200.189.148 ===================================== - Jim Fleming Unir Corporation IBC, Tortola, BVI http://vi.unir.net -------- Logged at Thu Apr 30 14:56:10 MET DST 1998 --------- From JimFleming at doorstep.unety.net Thu Apr 30 14:50:42 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Thu, 30 Apr 1998 07:50:42 -0500 Subject: The Many Faces of .VI Message-ID: <01BD740C.AD68D480@pc.unir.net> Shown below are the ~50 names active in the .VI TLD DNS. It is unclear if this is all of the names "registered" because some people could claim that unlisted names also exist. If we assume there are no unlisted names, then the "owners" of the 50 names below are the "stakeholders" for the .VI TLD. The .VI TLD is a good TLD to use for discussion purposes because people can get their hands around 50 stakeholders as opposed to 2,000,000+ owners in .COM. There are at least five known uses of the .VI TLD: 1. .VI - United States Virgin Islands 2. .VI - Virgin Islands 3. .VI Text Editor Users 4. .VI Roman Numeral for 6 5. .VI - Very Intelligent or Very Important (short for VIP) If you take all of the names below and apply .VI to the right side and a WWW to the left side, you can start to classify the names below into the above five categories. For example, WWW.ALEXIS.VI. Which of the above five categories does that fall into ?....and most importantly, does it matter ? ALEXIS AMCUP AMENT AQUAMAN ARMOUR BCPHOTO BUSHTEA BVIMALL BXICARIBBEAN CAROLLEE CHARTERBOAT CO CROIX DAVIDJONES DIUSVI FANTASIA HOTELBOYNES ISLANDVIDEO IYC JNET JOHN LOCATION MARRIOTT MARRIOTT-FR MARRIOTT-MS MORRETT OCTAGON PISSARRO PRISCO ROLEXREGATTA ROTARY ROYALCARIBBEAN SANDDOLLAR SHIPS SOCCER-MASTERS ST-CROIX ST-JOHN ST-THOMAS STCROIX STJOHN STTHOMAS SUNREALTY THOMAS TRADEWINDS VISIT WEDUS WINDSURFING WSTA YACHTS ZBVI ===== As the 2 letter TLDs begin to join the other generic TLDs or vice versa, the market and marketing forces will help to define what a TLD means to people. No matter what it means, the .TLD owners are the stakeholders and they have a right an responsibility to make sure that their TLD administration is handled in the manner they prefer. Their collective voice should be used to guide the direction the TLD takes. Let their voices be heard. Whomever they are... -------- Logged at Fri May 1 11:52:21 MET DST 1998 --------- From JimFleming at doorstep.unety.net Thu Apr 30 02:48:25 1998 From: JimFleming at doorstep.unety.net (Jim Fleming) Date: Wed, 29 Apr 1998 19:48:25 -0500 Subject: Small Name Services Providers Message-ID: <01BD73A7.C6AE8260@pc.unir.net> On Tuesday, April 28, 1998 10:19 PM, Peter deBlanc[SMTP:pdeblanc at usvi.net] wrote: @Thanks Bob, for your comments on this interesting concept. I have always @promoted public service internet access. In fact, my paper for the @Internet Society conference in Hawaii in 1995 was about a funding model @for public internet access in developing countries. After spending 5 @years working for the United Nations in such countries in the Caribbean, @It became clear that some method was needed to bridge the gap between @"information haves" and information have-nots". I am all in favor of @profitable enterprise. And I subscribe to the concept that pro bono @service is a responsibility of the mature professional. @ Peter, Do you have any plans to evolve the .VI DNS system to a more production-oriented structure ? As you can see below there are various levels delegated in your TLD Name Servers. This makes it more difficult to have a volume interface similar to the InterNIC where all .COM entries look like the CO.VI entry below: $ORIGIN vi. co IN NS ns1.octagon.net. IN NS ns2.octagon.net. While entries like the following may make sense for a TLD registry that caters to a small number of domains that you are hosting or familiar with, this might be expensive to maintain in a volume (production) situation. ships IN A 208.200.189.167 In other words, one would expect that the name SHIPS.VI would cause an entry with a minimum of 2 name servers (as CO.VI has) and then the delegate for SHIPS.VI would be responsible for handling the traffic for that zone. At the present this is handled on the .VI "root" TLD Name Servers. I bring this up because now is the time to clean-up the .VI zone before it grows. It may be difficult or impossible to do that later. I am interested in your plans to bring the .VI TLD Name Servers to a point where it has a production-grade structure. I am also interested in the criteria for names being entered below the .VI TLD. I have heard the "Free Net" arguments that names are provided for worthy causes. I have also heard the argument that commercial companies should be under CO.VI. As shown below, there does not seem to be a consistent policy for the .VI TLD. What is the current policy for names directly under .VI. Can one assume that ALL names currently under .COM could also be registered under .VI, if those owners desired ? Free Nets seem to have a way of developing Free-Form policies that few people can articulate. Maybe you can work with Bob Allisat on articulating the policy for the .VI TLD. Thanks... Jim Fleming ============================== ; BIND version named 4.9.3-P1 Tue Jan 23 15:41:55 GMT 1996 ; BIND version polk at forge.BSDI.COM:/usr/src/usr.sbin/named/named ; zone 'vi' last serial 0 ; from 198.6.1.65 at Wed Apr 29 14:11:39 1998 $ORIGIN . vi IN SOA ns1.octagon.net. hostmaster.usvi.net. ( 1998042604 21600 1800 1728000 43200 ) IN NS auth00.ns.uu.net. IN NS auth01.ns.uu.net. IN NS ns.ripe.net. IN NS ns1.octagon.net. IN NS ns2.octagon.net. $ORIGIN vi. alexis IN A 208.200.189.133 $ORIGIN alexis.vi. www IN CNAME alexis.vi. $ORIGIN vi. marriott-fr IN A 208.200.189.171 IN MX 10 noc.usvi.net. $ORIGIN marriott-fr.vi. www IN A 208.200.189.171 $ORIGIN vi. tradewinds IN MX 10 noc.usvi.net. IN A 208.200.189.141 $ORIGIN tradewinds.vi. www IN A 208.200.189.141 $ORIGIN st-croix.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN vi. prisco IN MX 5 noc.usvi.net. IN A 208.200.189.156 $ORIGIN prisco.vi. www IN A 208.200.189.156 $ORIGIN vi. rotary IN MX 10 noc.usvi.net. IN A 208.200.189.139 $ORIGIN rotary.vi. www IN CNAME rotary.vi. $ORIGIN vi. imi IN MX 10 noc.usvi.net. ac IN NS ns1.octagon.net. IN NS ns2.octagon.net. pissarro IN A 208.200.189.164 IN MX 10 noc.usvi.net. $ORIGIN pissarro.vi. www IN A 208.200.189.164 $ORIGIN stjohn.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN vi. credit IN NS ns1.webservices.net. IN NS ns2.webservices.net. marriott IN A 208.200.189.170 IN MX 10 noc.usvi.net. $ORIGIN marriott.vi. www IN A 208.200.189.170 $ORIGIN vi. sanddollar IN MX 10 noc.usvi.net. IN A 208.200.189.190 $ORIGIN sanddollar.vi. www IN CNAME sanddollar.vi. $ORIGIN vi. ament IN A 208.200.189.165 IN MX 10 noc.usvi.net. $ORIGIN ament.vi. www IN A 208.200.189.165 $ORIGIN vi. bxicaribbean IN A 208.200.189.187 IN MX 10 noc.usvi.net. $ORIGIN bxicaribbean.vi. www IN CNAME bxicaribbean.vi. $ORIGIN st.thomas.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN vi. gov IN NS ns1.octagon.net. IN NS ns2.octagon.net. soccer-masters IN MX 10 noc.usvi.net. IN A 208.200.189.178 $ORIGIN soccer-masters.vi. www IN CNAME soccer-masters.vi. $ORIGIN vi. coconutcoaststudios IN MX 10 noc.usvi.net. rolexregatta IN MX 10 noc.usvi.net. IN A 208.200.189.173 $ORIGIN rolexregatta.vi. www IN CNAME rolexregatta.vi. $ORIGIN vi. islands IN NS ns1.octagon.net. IN NS ns2.octagon.net. wedus IN MX 10 noc.usvi.net. IN A 208.200.189.184 $ORIGIN wedus.vi. www IN CNAME wedus.vi. $ORIGIN vi. morrett IN MX 10 noc.usvi.net. $ORIGIN morrett.vi. chad IN A 204.199.0.98 $ORIGIN vi. co IN NS ns1.octagon.net. IN NS ns2.octagon.net. ships IN A 208.200.189.167 $ORIGIN ships.vi. www IN A 208.200.189.167 $ORIGIN vi. location IN MX 10 mail.location.vi. IN MX 20 noc.usvi.net. IN A 208.200.189.166 $ORIGIN location.vi. mail IN A 204.199.1.240 IN MX 10 mail.location.vi. IN MX 20 noc.usvi.net. www IN A 208.200.189.166 $ORIGIN vi. hotelboynes IN MX 10 noc.usvi.net. IN A 208.200.189.162 $ORIGIN hotelboynes.vi. www IN CNAME hotelboynes.vi. $ORIGIN vi. wsta IN A 208.200.189.144 IN MX 10 noc.usvi.net. $ORIGIN wsta.vi. www IN A 208.200.189.144 $ORIGIN vi. falcon IN MX 10 noc.usvi.net. CarolLee IN MX 5 noc.usvi.net. IN A 208.200.189.160 $ORIGIN CarolLee.vi. www IN A 208.200.189.160 $ORIGIN vi. octagon IN A 208.200.189.150 IN MX 10 octagon.usvi.net. IN MX 20 noc.usvi.net. $ORIGIN octagon.vi. www IN A 208.200.189.150 $ORIGIN vi. amcup IN MX 10 noc.usvi.net. IN A 208.200.189.179 $ORIGIN amcup.vi. www IN CNAME amcup.vi. $ORIGIN vi. armour IN MX 10 rutabaga.armour.vi. IN MX 20 noc.usvi.net. IN A 208.200.189.183 $ORIGIN armour.vi. impossibleapple IN A 204.199.0.92 peach IN A 204.199.0.95 chocolate IN A 204.199.0.94 cherry IN A 204.199.0.93 rutabaga IN A 204.199.0.90 www IN CNAME armour.vi. mincemeat IN A 204.199.0.97 pumpkin IN A 204.199.0.96 lemon IN A 204.199.0.91 $ORIGIN st.john.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN vi. yachts IN A 208.200.189.132 IN MX 10 noc.usvi.net. $ORIGIN yachts.vi. www IN A 208.200.189.132 $ORIGIN st-thomas.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN vi. marriott-ms IN A 208.200.189.172 IN MX 10 noc.usvi.net. $ORIGIN marriott-ms.vi. www IN A 208.200.189.172 $ORIGIN vi. zbvi IN A 208.200.189.169 IN MX 10 noc.usvi.net. $ORIGIN zbvi.vi. www IN A 208.200.189.169 $ORIGIN vi. davidjones IN MX 10 noc.usvi.net. IN A 208.200.189.191 $ORIGIN davidjones.vi. www IN CNAME davidjones.vi. $ORIGIN vi. k12 IN NS ns1.octagon.net. IN NS ns2.octagon.net. $ORIGIN stcroix.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN vi. royalcaribbean IN MX 10 noc.usvi.net. IN A 208.200.189.10 $ORIGIN royalcaribbean.vi. www IN CNAME royalcaribbean.vi. $ORIGIN st.croix.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN st-john.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN vi. gv IN NS ns1.octagon.net. IN NS ns2.octagon.net. islandvideo IN A 208.200.189.155 IN MX 0 noc.usvi.net. $ORIGIN islandvideo.vi. www IN CNAME islandvideo.vi. $ORIGIN vi. fantasia IN A 208.200.189.147 IN MX 10 noc.usvi.net. $ORIGIN fantasia.vi. www IN A 208.200.189.147 $ORIGIN vi. diusvi IN A 208.200.189.177 IN MX 10 noc.usvi.net. $ORIGIN diusvi.vi. www IN A 208.200.189.177 $ORIGIN vi. jnet IN A 146.226.2.198 IN HINFO "i80586" "FreeBSD" IN MX 0 jnet.vi. $ORIGIN jnet.vi. www IN CNAME jnet.vi. $ORIGIN visit.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN vi. tti IN MX 0 noc.usvi.net. org IN NS ns1.octagon.net. IN NS ns2.octagon.net. $ORIGIN stthomas.vi. www IN CNAME redirect.www.usvi.net. $ORIGIN vi. aquaman IN MX 10 mail.islands.vi. IN A 208.200.189.186 $ORIGIN aquaman.vi. www IN CNAME aquaman.vi. $ORIGIN vi. www IN CNAME redirect.www.usvi.net. windsurfing IN A 208.200.189.157 IN MX 10 noc.usvi.net. $ORIGIN windsurfing.vi. www IN A 208.200.189.157 $ORIGIN vi. iyc IN A 208.200.189.168 IN MX 10 noc.usvi.net. $ORIGIN iyc.vi. www IN A 208.200.189.168 $ORIGIN vi. charterboat IN MX 10 noc.usvi.net. IN A 208.200.189.181 $ORIGIN charterboat.vi. www IN CNAME charterboat.vi. $ORIGIN vi. bcphoto IN A 208.200.189.176 IN MX 10 noc.usvi.net. $ORIGIN bcphoto.vi. www IN A 208.200.189.176 $ORIGIN vi. sunrealty IN MX 10 noc.usvi.net. IN A 208.200.189.182 $ORIGIN sunrealty.vi. www IN CNAME sunrealty.vi. $ORIGIN vi. vitelcom IN NS ns1.octagon.net. IN NS ns2.octagon.net. test IN NS ns1.octagon.net. IN NS ns2.octagon.net. bvimall IN A 208.200.189.135 IN MX 10 noc.usvi.net. $ORIGIN bvimall.vi. www IN A 208.200.189.135 $ORIGIN vi. bushtea IN A 208.200.189.148 IN MX 10 noc.usvi.net. $ORIGIN bushtea.vi. www IN A 208.200.189.148 ===================================== - Jim Fleming Unir Corporation IBC, Tortola, BVI http://vi.unir.net -------- Logged at Sun May 3 15:52:07 MET DST 1998 ---------