- tld-wg - mailman.ripe.net

Notes to Agenda for RIPE 32 TLD-WG
by Niall.oReilly＠ucd.ie 20 Jan '99

20 Jan '99

The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: TLDsum29.txt Date: 20 Jan 1999, 17:16 Size: 1162 bytes. Type: Text

1 0

Notes to Agenda for RIPE 32 TLD-WG
by Niall.oReilly＠ucd.ie 20 Jan '99

20 Jan '99

The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: TLDmin31.txt Date: 20 Jan 1999, 17:04 Size: 6652 bytes. Type: Text

1 0

Proposed Agenda for RIPE 32 TLD-WG
by Niall.oReilly＠ucd.ie 20 Jan '99

20 Jan '99

A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1697 bytes Desc: not available URL: <https://www.ripe.net/ripe/mail/archives/tld-wg/attachments/19990120/820d3cf…>

1 0

Maintainer creation policy
by Havard.Eidnes＠runit.sintef.no 29 Dec '98

29 Dec '98

> the RIPE NCC is considering relaxing the requirements for obtaining a > maintainer. This has certain consequences that we would like people > to consider and then put forward comments either supporting or > rejecting this proposal. > > We propose the following new policy: > > - The RIPE NCC will create maintainers for all users whose person/role > object is mentioned in any object in the RIPE database except if it is > only mentioned in other person or role objects. > - If the person/role is not mentioned in any other object, the > maintainer will not be created. > > This should allow all users to protect their data but prevent the > database from becoming some sort of "phone book". Maybe I'm getting out of touch with things, but frankly, I do not see how this solves the "phone book" problem or any other problem for that matter. Instead I see it creating a few new problems... I also do not really understand from the description above what exactly is going to happen. Some interpretations: o All "person" objects referenced from other objects (except "role" objects) will result in the creation of a new maintainer object for that user, and the user's maintainer will be added as a mnt-by: attribute of the objects where the person was referenced earlier. If the total size of the database is a problem (and I think it is), this will not help one little bit, as this will add new objects corresponding to a *large* percentage of the person objects in the database. Furthermore, it is not necessarily true that users referenced as admin-c, tech-c or zone-c *own* the information registered, although there may be consensus that this is so for the Internet registry part of the RIPE database. For the other "subparts" of the database there may be policy implications of updating the information, a prime example could be information from the domain registry side. o The RIPE NCC will add mnt-by: attributes on all person objects referenced from other objects (except "role" objects). Which maintainer is to be used is not exactly stellar clear. I consider this to be an unlikely interpretation, although I must say that the statements above are sufficiently unclear that I do not clearly understand what is going to happen. I do not understand at all how this will reduce the "phone book" problem of the RIPE database, as this will not prevent the creation of "free- standing" objects in the RIPE database (?). I furthre presume that the "phone book" problem is exactly this -- free-standing, un-referenced person objects? Another alternative to the "phone book" problem could be that a large part of the RIPE database is indeed objects resulting from it making double duty as a domain registry information repository, although I still seem to remember statements by the RIPE NCC to the effect that this is not regarded as a problem. Why not just permit maintainer object creation by anyone satisfying the above requirements ("reference exists"), but not create the maintainer objects themselves or the mnt-by: attributes? I cannot see that there have been any comments to this proposal, so am I the only one who does not understand what is going to happen, and what the rationale for it is? I do however think that the effective time between announcement and implementation is way too short -- with IETF and Christmas and New Year holdays in-between it comes down to 1-2 weeks only. Regards, - H?vard -------- Logged at Wed Dec 30 12:08:06 CET 1998 ---------

3 2

FYI: .il Rules change
by hank＠ibm.net.il 09 Dec '98

09 Dec '98

After 18 months of work, the .il ccTLD will be changing its rules as of Jan 1, 1999. To review the new rules, FAQ, ACP fee schedule, etc. see: http://www.isoc.org.il/domains Regards, Hank -------- Logged at Tue Dec 29 15:45:40 CET 1998 ---------

1 0

Maintainer creation policy
by joao＠ripe.net 07 Dec '98

07 Dec '98

Dear all, the RIPE NCC is considering relaxing the requirements for obtaining a maintainer. This has certain consequences that we would like people to consider and then put forward comments either supporting or rejecting this proposal. We propose the following new policy: - The RIPE NCC will create maintainers for all users whose person/role object is mentioned in any object in the RIPE database except if it is only mentioned in other person or role objects. - If the person/role is not mentioned in any other object, the maintainer will not be created. This should allow all users to protect their data but prevent the database from becoming some sort of "phone book". Some consequences of this would be: - The RIPE NCC would no longer do any identity checks on the requester (compliance with the policy will be, of course, checked). - Users may wish to protect objects that already have (soft) maitainers. A clear example would be a user protecting a domain object with a soft maintainer (eg: auth: NONE) with their own maintainer (which may have PGP on it). - Users with inetnum,route,etc objects are strongly encouraged to protect their objects with a strong maintainer to prevent accidental or malicious "protection" by other users. Note: Any object can have more than one maintainer. To modify/delete an object only one maintainer authentication needs to be matched. In order to add a maintainer to an object that already has one (or more) the user will need cooperation from one of the previous maintainers. Waiting for your comments, Joao Damas RIPE DB Group RIPE NCC -------- Logged at Wed Dec 9 14:38:43 MET 1998 ---------

1 0

Ripe change to whois
by hank＠ibm.net.il 03 Dec '98

03 Dec '98

At 04:00 PM 11/30/98 +0100, Joao Luis Silva Damas wrote: Just check http://www.checkdomain.com with some nonexistant domain housed at RIPE and tell me if something isn't wrong here. -Hank >Hello. > >I am including the tld-wg into this discussion so as to make sure all involved >parties are aware of the discussion. > > Alexander Koch <akoch at sgh-net.de> writes: > * Hello. > * > * > The design of this feature was specified some time ago by Carol Orange and > * > * > Wilfried Woeber (please see http://www.ripe.net/meetings/ripe/ripe-27/pres > * /rout > * > e/referral/) and discussed in the RIPE db-wg mailing list (please see > * > http://www.ripe.net/mail-archives/db-wg/19970501-19970601/threads.html) > * > * Oh. Fine. Do I get it right that this was discussed and agreed on > * more than a year ago? Argh. > * > >Yes, indeed. We had a period where we have been late with developments. That >period is now behind us. > > * This change breaks too many things, imnsho, and it seems again that if > * you are not able to make it to the RIPE meetings, you have lost. A > * special announce would have been most helpful (an explicit one, stating > * this). > * > >But, we did... or so I thought. We'll look into more ways of getting this >announcements across while trying to minimize the mails sent to people who >don't care about this. > >This particular feature has been actively asked for by the ccTLD >adninistrators and seen as a good thing by everyone I have had a chance to >speak with. These are actually the first complaints about it we have got so >far. > > * > As a side note I would like to stress that the RIPE Database is NOT the so > * urce > * > of authoritative data for domain objects (although we are happy to provide > * a > * > repository for TLD administrators). > * > This is UNLIKE the internic whose business is to sell names. > * > * Oh. Fine. whois.nic.de *cough* barely ever working... Weak argument. > * And If I wanted to know the data about the domain one level higher, > * I can do so myself, I don't need to get it told to me by whois, I > * want to know whether crab.de (bad example, it really exists) is in > * the DB already or not. > >I am sorry but I can't talk about the availability of services we don't >operate. > >I am sure you can look up domains yourself but this was actually seen as >providing the users (specially the ones less familiar with the RIPE DB) with >help on where to find the correct information. > >It seems to me that over time people have developed a sense that the RIPE DB >is the authoritative source of information regarding domain names in Europe. >May be this issue should be up for debate now. > >As a matter of fact the referral mechanism was seen as a way for ccTLD >administrators to include information in the Database pointing to their own >authoritative sources of information. > > * > * > The RIPE NCC is therefore acting according to users directives that were > * > discussed and agreed on an open way. > * > * Hitchhiker's Guide, anyone? *sigh* > >??? > > * > * This was a not-so-nice change, really. Consider this a statement of > * disagreement with the way the change took place. Ok, one more mailling > * list to follow... Time to sell. > >Will do so. As I said before, we will keep modifying and developing the RIPE >DB software and in particular this feature if users feel that is what they >want. We will also provide our point view. >I would like to have the input of the community. > >Regards, >Joao > > * > * Regards, > * Alexander Koch > * > * -- > * SGH Internet Division, Alexander Koch, Systems Administration > * Hannover, Germany, Phone +49 511 909198 0, Fax +49 511 391307 > * > > > -------- Logged at Mon Nov 30 16:28:47 MET 1998 ---------

4 4

Ripe change to whois
by hank＠ibm.net.il 02 Dec '98

02 Dec '98

At 06:35 PM 12/1/98 +0000, Niall O'Reilly wrote: >On 30 Nov 98, at 17:14, Hank Nussbacher quoted someone >who had written: > >> > >> >As a matter of fact the referral mechanism was seen as a way for ccTLD >> >administrators to include information in the Database pointing to their own >> >authoritative sources of information. > >I can confirm that this was indeed the intention when this was first proposed in >the RIPE (25, I think) DNS-WG meeting. > >> > * > The RIPE NCC is therefore acting according to users directives that were >> > * > discussed and agreed on an open way. >> > * >> > >Yes and no, I have to say. > >At RIPE 31, the functionality proposed certainly appeared to me to be what had >been sought. I am no longer certain that this is indeed the case. In particular, >the following surprises have arisen. > >First, the key notion of making the referral function available per TLD at the >option of the TLD registry concerned seems to have been lost. This is a >fundamental element of the original concept of over two years ago. > >Second, the "feature" of returning the data relating to the parent domain in the >case that the specified domain cannot be found seems to me to have nothing >to do with referral. The referral concept has to do with re-directing the query to >an authoritative whois server, not with second-guessing the intent behind the >query and substituting other data which is available locally. I suggest that this >"feature" be declared a bug and removed. > >I am sure that these technical problems are based on misunderstandings which >can easily be resolved. > >A more significant surprise is that TLD registries, who have had no specific >prior notification, now find that data about their domains is being returned in >response to a class of query for which this was not formerly the case, and that >they have to deal with the unexpected fallout. Niall, Thank you for bringing sanity to this! I am sure now that this can all be cleared up and we can all go back to what we are all doing and let RIPE continue working the way it has always done - with no hiccups, technical excellence and 3 years ahead of the USA. -Hank > > >Niall O'Reilly > >IE Domain Registry at UCD >Chair, RIPE TLD-WG > > -------- Logged at Thu Dec 3 16:20:11 MET 1998 ---------

1 0

Ripe change to whois
by joao＠ripe.net 01 Dec '98

01 Dec '98

Hi, Michael van Elst <mlelstv at xlink.net> writes: * * I'm not sure what needs to be 'rectified'. But if you silently change * the semantics of a public database more than a year after a discussion * that wasn't attended by its current users, then you shouldn't wonder * about complaints. Well, Hank is hardly a new user. And yes, we took too long to deploy this feature, however, I can't see that the issues would have been different a year ago (maybe I am wrong). I am not having an exercise on defending against changing this. I am more than glad to make changes if the community asks for them (and to propose new ones that we think make sense). I want to see what the rest of the people think since the previous consensus was different to what I am seeing now. * * But complaining alone doesn't achieve anything. As it appears * the database lacks the feature of an exact-match query and I * kindly propose to add such a feature. * Well the purpose of the design is to give the user information about the parent domain if a certain domain is missing. That's also how the rest of the lookups in the RIPE DB work and is also what you do when looking in the DNS for contact info for a domain and you can't find it. May be people now see the need for an exact matching option (there is already one to disable referral: -R). However if you make this the default behaviour then the purpose of the referral mechanism is defeated. Joao * * Regards, * -- * i.A. Michael van Elst / phone: +49 721 6635 330 * Xlink - Network Information Centre \/ fax: +49 721 6635 349 * Vincenz-Priessnitz-Str. 3 /\ link http://nic.xlink.net/ * D-76131 Karlsruhe, Germany /_______ email: hostmaster at xlink.net * [ Xlink Internet Consulting GmbH, Sitz Koeln ] * [ Amtsgericht Koeln HRB 3526, Geschaeftsfuehrer: Michael Rotert ] * * -------- Logged at Tue Dec 1 12:43:46 MET 1998 ---------

3 4

Ripe change to whois
by joao＠ripe.net 30 Nov '98

30 Nov '98

Hello. I am including the tld-wg into this discussion so as to make sure all involved parties are aware of the discussion. Alexander Koch <akoch at sgh-net.de> writes: * Hello. * * > The design of this feature was specified some time ago by Carol Orange and * * > Wilfried Woeber (please see http://www.ripe.net/meetings/ripe/ripe-27/pres * /rout * > e/referral/) and discussed in the RIPE db-wg mailing list (please see * > http://www.ripe.net/mail-archives/db-wg/19970501-19970601/threads.html) * * Oh. Fine. Do I get it right that this was discussed and agreed on * more than a year ago? Argh. * Yes, indeed. We had a period where we have been late with developments. That period is now behind us. * This change breaks too many things, imnsho, and it seems again that if * you are not able to make it to the RIPE meetings, you have lost. A * special announce would have been most helpful (an explicit one, stating * this). * But, we did... or so I thought. We'll look into more ways of getting this announcements across while trying to minimize the mails sent to people who don't care about this. This particular feature has been actively asked for by the ccTLD adninistrators and seen as a good thing by everyone I have had a chance to speak with. These are actually the first complaints about it we have got so far. * > As a side note I would like to stress that the RIPE Database is NOT the so * urce * > of authoritative data for domain objects (although we are happy to provide * a * > repository for TLD administrators). * > This is UNLIKE the internic whose business is to sell names. * * Oh. Fine. whois.nic.de *cough* barely ever working... Weak argument. * And If I wanted to know the data about the domain one level higher, * I can do so myself, I don't need to get it told to me by whois, I * want to know whether crab.de (bad example, it really exists) is in * the DB already or not. I am sorry but I can't talk about the availability of services we don't operate. I am sure you can look up domains yourself but this was actually seen as providing the users (specially the ones less familiar with the RIPE DB) with help on where to find the correct information. It seems to me that over time people have developed a sense that the RIPE DB is the authoritative source of information regarding domain names in Europe. May be this issue should be up for debate now. As a matter of fact the referral mechanism was seen as a way for ccTLD administrators to include information in the Database pointing to their own authoritative sources of information. * * > The RIPE NCC is therefore acting according to users directives that were * > discussed and agreed on an open way. * * Hitchhiker's Guide, anyone? *sigh* ??? * * This was a not-so-nice change, really. Consider this a statement of * disagreement with the way the change took place. Ok, one more mailling * list to follow... Time to sell. Will do so. As I said before, we will keep modifying and developing the RIPE DB software and in particular this feature if users feel that is what they want. We will also provide our point view. I would like to have the input of the community. Regards, Joao * * Regards, * Alexander Koch * * -- * SGH Internet Division, Alexander Koch, Systems Administration * Hannover, Germany, Phone +49 511 909198 0, Fax +49 511 391307 * -------- Logged at Mon Nov 30 16:15:12 MET 1998 ---------

1 0

EC ready for domain name reform
by Sean＠Jackson.TC 06 Nov '98

06 Nov '98

http://www.news.com/News/Item/0,4,28395,00.html?owv God Bless You, Sean Sean Jackson, 3 Adams Road, Cambridge, CB3 9AD, United Kingdom. Tel: 01223 464 800 Fax: 0171 681 1268 -------- Logged at Mon Nov 30 16:01:46 MET 1998 ---------

1 0

rfc 1591
by Sean＠Jackson.TC 20 Oct '98

20 Oct '98

The managers of MS. VG, & TC consider its only reasonable that the terms of RFC 1591 are adhered to. It was the basis on which top level domains were founded. Any attempt by the United States government to alter this would need international agreement. God Bless You, Sean Sean Jackson, 3 Adams Road, Cambridge, CB3 9AD, United Kingdom. Tel: 01223 464 800 Fax: 0171 681 1268 -------- Logged at Fri Nov 6 08:56:56 MET 1998 ---------

1 0

Fw: 3:242 ES (SPAIN)
by JimFleming＠unety.net 07 Oct '98

07 Oct '98

Adam, If the TLDs are grouped into 4s then the strong ones, as for example .ES below, can take care of the other 3 "seats" at the table. If there is no TLD authority for that, they can help to select a different label (TLD) or just mark it as not used. If someone comes to inquire whether the seat is taken, they can say, "No...welcome, have a seat...glad to know you..." This group of 32 is just one example...they should be able to self-organize on their own, given enough time... >http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > > >3:224 MA (MOROCCO) >3:225 BERLIN >3:226 FLAX >3:227 WATCH >3:228 LU (LUXEMBOURG) >3:229 LIT >3:230 FLOOR >3:231 LT (LITHUANIA) >3:232 FX (FRANCE-METROPOLITAN) >3:233 GBR (UNITED-KINGDOM) >3:234 FILE >3:235 WASTE >3:236 BERN >3:237 FLUID >3:238 SK (SLOVAKIA-(Slovak-Republic)) >3:239 UNDERNET >3:240 FAQ >3:241 IRC >3:242 ES (SPAIN) > 1. Javier SOLA <jsola at aui.es> > http://www.gtld-mou.org/pab/mail-archive/00303.html 3:243 FOAM >3:244 VA (HOLY-SEE-(VATICAN-CITY-STATE)) >3:245 SPEECH >3:246 DUBLIN >3:247 FOODS >3:248 CHE (SWITZERLAND) >3:249 EE (ESTONIA) >3:250 FRA (FRANCE) >3:251 MAR (MOROCCO) >3:252 FOOT >3:253 BIH (BOSNIA-AND-HERZEGOWINA) >3:254 FI (FINLAND) >3:255 MENS > >@@@@@@@@@@@@@ Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)---C+ at ---<IPv8>---C+ at ---(Java)VPC http://www.ddj.com/index/author/idx10133.htm -------- Logged at Mon Sep 21 17:15:46 MET DST 1998 ---------

3 3

Joke from Jim Fleming (was: 0:201 COM News)
by JimFleming＠unir.com 07 Oct '98

07 Oct '98

-----Original Message----- From: John Charles Broomfield <jbroom at manta.outremer.com> To: Jim Fleming <JimFleming at unir.com> Cc: richard at vrx.net <richard at vrx.net>; bhelfant at globecomm.com <bhelfant at globecomm.com>; bobr at dprc.net <bobr at dprc.net>; at at ah.net <at at ah.net>; orobles at nic.mx <orobles at nic.mx>; tld-wg at ripe.net <tld-wg at ripe.net>; jnh at skyscape.net <jnh at skyscape.net>; phil at CHARON.MILEPOST.COM <phil at CHARON.MILEPOST.COM>; erony at marin.k12.ca.us <erony at marin.k12.ca.us>; Daniel.Karrenberg at ripe.net <Daniel.Karrenberg at ripe.net>; pgp at pgmedia.net <pgp at pgmedia.net>; jc.praud at ludexpress.com <jc.praud at ludexpress.com>; MarshM at diebold.com <MarshM at diebold.com>; DOMAIN-POLICY at LISTS.INTERNIC.NET <DOMAIN-POLICY at LISTS.INTERNIC.NET>; djrogers at enterprise.net <djrogers at enterprise.net>; dstein at TRAVEL-NET.COM <dstein at TRAVEL-NET.COM>; cgomes at internic.net <cgomes at internic.net>; chrisc at NETSOL.COM <chrisc at NETSOL.COM>; amr at chaos.com <amr at chaos.com>; Jay at Iperdome.com <Jay at Iperdome.com>; ivan at NETNAMES.COM <ivan at NETNAMES.COM>; usdh at mailhub2.ncal.verio.com <usdh at mailhub2.ncal.verio.com>; commerce at mail.house.gov <commerce at mail.house.gov>; com-priv at lists.psi.com <com-priv at lists.psi.com>; lessig at law.harvard.edu <lessig at law.harvard.edu>; mike.norris at heanet.ie <mike.norris at heanet.ie>; mueller at syr.edu <mueller at syr.edu>; domain-policy at open-rsc.org <domain-policy at open-rsc.org> Date: Tuesday, October 06, 1998 2:17 PM Subject: Joke from Jim Fleming (was: 0:201 COM News) > >Hey, nice joke there Jim... >So now YOU and Richard Sexton are the contacts for ".com" in your IPv8 >pipedream? >(...) >> 0:201 COM >> 1. Jim Fleming - JimFleming at unir.com >> 2. Richard Sexton - richard at vrx.net > John, As you should be aware, but apparently are not, the IPv8 Plan calls for 8 Trustees for each TLD. Only the top 2 Trustees are listed. The Trustees are arranged in a 2+2+4 structure. There are two leaders, 2 backup leaders and 4 support people. This helps to provide continuity. The 8 people decide who the 2 leaders are. We are trying to get the 8 leaders organized for .COM. If you are interested in that activity, let us know. Here is the form, that helps to show how the 8 people are structured in relation to each other. Keep in mind that these 8 people may not have anything to do with the registry operation or the registrars. They are the public oversight body for deciding what company is designated to do that, on behalf of the SLD owners who hopefully help to select the 8 Trustees. 5. ____________________ 3. ____________________ 6. ____________________ 1. ____________________ 2. ____________________ 7. ____________________ 4. ____________________ 8. ____________________ If you recall, you have consistently said that you do not want anyone looking over your shoulder as the Registry operator for the .MQ and .GP TLDs. You have also not been able to name 7 other people that help to provide public oversight for those TLDs. The Country of France has now announced that they want to end the "exploitation" of those TLDs. This may be because there is no public oversight. You might want to explain to everyone how you are governed by public oversight. Some people seem to miss it and you are always deflecting attention to other activities that are attempting to provide the oversight that people think is prudent. Why is that ? Jim Fleming Unir Corporation - http://www.unir.com 0:201 .COM http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt -------- Logged at Wed Oct 7 12:16:34 MET DST 1998 ---------

1 0

0:201 COM News
by JimFleming＠unir.com 07 Oct '98

07 Oct '98

Richard, As people can see, the .COM TLD is no different from the other TLDs. Changes are made from time to time. Hopefully, these changes will continue and .COM will become free of the legacy Root Name Servers in the IPv4 address space. It looks like Network Solutions is starting to make some of the recommended changes. I think that we all knew that adult supervision would play more and more of a role in the management of TLDs. It is great to see that NSI is playing a leadership role and moving away from the legacy root "playground". While on the subject of .COM, it seems useful to review the .COM neighborhood or "neighbor net" from an IPv8 point of view. As you can see below, .COM is between a vacant seat 0:200 and the .ISLAND TLD 0:202. I have not been able to locate any Trustees for .ISLAND, but I have a feeling they are out there. The Trustees for 0:199, .LTD have been in communication so the neighborhood is taking shape. Hopefully, we can find a group to pick up the 0:200 seat and things will start to fill in and the base of contacts will grow. This will help to keep people informed about what the status is of the various TLDs (including .COM). http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt 0:199 LTD 1. David Rogers - djrogers at enterprise.net 2. Jason Hendeles - jnh at skyscape.net 0:200 <<<<<< AVAILABLE >>>>> 1. __________________________ 2. __________________________ 0:201 COM 1. Jim Fleming - JimFleming at unir.com 2. Richard Sexton - richard at vrx.net 0:202 ISLAND 1. __________________________ 2. __________________________ Hopefully, the RSCs and the GRS people will pick up on the changes that NSI has described below. Also, I hope that NSI continues to make more changes. It is good to see that the .COM TLD is moving away from the legacy roots and taking shape. If we all work together using the neighbor net approach, we can keep each other informed of these changes. Then, if someone has a question, people can go to the people that have been providing stewardship for a particular TLD. We should keep in mind that root server operators (RSCs) do not generally pay much attention to the day to day issues of a particular TLD. They have to look at all of the TLDs. People should not be surprised that RSCs may not be the best source of info about a particular TLD. Jim Fleming Unir Corporation - http://www.unir.com 0:201 .COM http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt >>To: dholtz at internic.net ("David H. Holtzman") >>cc: nanog at merit.edu >>Subject: open letter (Re: NSI Bulletin 098-013 | gtld server) >>From: Paul Vixie <paul at vix.com> >>Date: 05 Oct 1998 22:25:50 -0700 >>Lines: 28 >>Sender: owner-nanog at merit.edu >> >>I have three questions about: >> >>dholtz at internic.net ("David H. Holtzman") writes: >> >>> In a continuing effort to enhance service to the community, Network >>> Solutions has added another gTLD server, f.gtld-servers.net (207.159.77.18) >>> at PAIX, Palo Alto, CA. The server will be operation in the next couple of >>> days. This server will serve the .com, .net and .org domains only. >>> _____________________________________ >>> David H. Holtzman (dholtz at internic.net) >>> Sr Vice President of Engineering >>> Network Solutions, Inc. >> >>1. As the operator of F.ROOT-SERVERS.NET, which is also at PAIX, I'm >>curious to know whether your reselection of the letter "F" in your host's >>name indicates a relationship between your "F" and my "F"? >> >>2. In the past, changes in the COM delegation have been made via IANA. >>Since IANA was not involved in this announcement, should I interpret this >>as a unilateral move on NSI's part? >> >>3. Does NSI still think of COM, NET, and ORG as its intellectual property? >>And is this belief bolstered in some way by the ICANN announcements? >>-- >>Paul Vixie >>La Honda, CA "Many NANOG members have been around >><paul at vix.com> longer than most." --Jim Fleming >>pacbell!vixie!paul (An H.323 GateKeeper for the IPv8 Network) >-- -------- Logged at Wed Oct 7 01:07:40 MET DST 1998 ---------

2 1

Default behaviour for referred domain queries
by mike.norris＠heanet.ie 06 Oct '98

06 Oct '98

In coincidence with your input, the db-wg also found that whenever the server shows data from a remote server instead of the local data in response to a query, the response should be preceded by a notice clearly informing the user that the information being displayed is coming from another server that contains the authoritative data. Right. It was also noted that the original proposal did not provide a way to look at the "local" object if it contained a refer attribute. In order to avoid potential confusion from a mode of operation where two objects are displayed, it would be better to provide a whois flag (-R was agreed) that would disable the referral and show the local object. Bear in mind that there could be multiple referrals involved i.e. the process is recursive. Suppose the query is for a third-level domain, that the second-level domain is referred from the RIPE DB to a TLD registry server, and that the target domain is referred onward from the TLD server to an ISP's whois server. Now what will the -R flag deliver - the local object in the RIPE DB? That'll give you the coordinates of the TLD server, which you again query with -R to get the ISP 'local' object. Regards. Mike -------- Logged at Tue Oct 6 16:28:05 MET DST 1998 ---------

1 0

1:250 MQ (MARTINIQUE)
by JimFleming＠unety.net 05 Oct '98

05 Oct '98

-----Original Message----- From: Jay Fenello <Jay at IPERDOME.COM> To: DOMAIN-POLICY at LISTS.INTERNIC.NET <DOMAIN-POLICY at LISTS.INTERNIC.NET> Date: Friday, October 02, 1998 5:20 PM Subject: Re: the free market decides (was Re: Registrars) >At 11:43 AM 10/2/98 , John Charles Broomfield wrote: >>Would Jay Fenello accept to have Iperdome run by registrants of ".per" (ie, >>that ".per" registrants would be the shareholders of Iperdome and vote for >>the board etc...) Would IOD accept to be run by registrants of ".web"? No, >>didn't think so... > > >Hi John, > >Given the number of times you've been proven wrong >in this debate, don't you think you should at least >give people a chance to answer the questions you ask? > >As usual, you are WRONG again! > >I would certainly consider transforming Iperdome into >a membership organization for ".per" registrants. > Not only that...Jay has provide a list of 8 Trustees for the .PER TLD under the IPv8 Plan. Those Trustees are like the trustees of a public library. They make the decision about what "registry" operates the TLD for the SLD.TLD owners. Think of them as a POC for the TLD. John Broomfield has NOT done this for the .MQ or .GP TLDs. John Broomfield has stated that he does not want anyone looking over his shoulder for those TLDs. Now, he has the country of France publishing a paper that says those TLDs are being exploited. Why does a country think that .MQ and .GP are being exploited ? It is ironic that .MQ and .GP do not qualify for the IPv8 Plan because they do not have proper PUBLIC OVERSIGHT. John Broomfield claims that he wants TLDs to have public oversight. Why not appoint 8 Trustees for .GP and 8 for .MQ ? Maybe Annie Renard can be a Trustee for each of them. Maybe someone from the French government can be named. How about some more people from .MQ and .GP. Why is John Broomfield the only person pursuing the .MQ and .GP TLDs ?....and he does not even use those TLDs for e-mail and such. Hopefully, people in the G1 and G2 Regions will look into this. I am busy with G0, especially 0:201 .COM. http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt 1:250 MQ (MARTINIQUE) 2:82 GP (GUADELOUPE) Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)--<IPv4>--C+ at ---<IPv8>---C+ at --<IPv4>--(Java)VPC http://www.ddj.com/index/author/idx10133.htm -------- Logged at Mon Oct 5 15:15:00 MET DST 1998 ---------

2 1

Default behaviour for referred domain queries
by Niall.oReilly＠ucd.ie 05 Oct '98

05 Oct '98

I'ld like to give input as requested on this topic. For the TLD people who may have missed the DB session, here is first a brief description of how the referral feature works. I don't know the details at this stage. When a request is received by the "central" server for a domain object marked (locally) for referral, the query is referred to the authoritative server and the data from the authoritative server is returned to the client. If the domain object requested is not found on the "central" server, the specified domain name is truncated (successively, if necessary ?) until a higher-level domain is found to be marked for referral, and the query is then referred to the authoritative server for that (higher-level) domain. The following suggestions seem to be almost agreed, but need to be written down. By default, the response returned to the client for a referred query should include the following elements: Alert that referral has been used Response from authoritative server I expect that the authoritative response will include a copyright and/or AUP banner from the authoritative server, but this is the responsibility of the authoritative registry, and not of the registry providing the referring server. I expect that a 'verbose mode' will provide a response including the following elements: Response from referring server as if no referral was used, including referring registry's standard (C)/AUP banner Alert that referral is spin effect for the domain in question Response from authoritative server Whichever of the modes described above is used, it should be possible to specify whether recursive lookup and display of related person/role (and in future, nameserver) objects is to be done. IHTH, Niall -------- Logged at Mon Sep 28 12:12:46 MET DST 1998 ---------

2 2

the free market decides (was Re: Registrars)
by JimFleming＠unety.net 01 Oct '98

01 Oct '98

-----Original Message----- From: Kent Crispin <kent at SONGBIRD.COM> <snip> > >> When you start a business, you may choose from >> one of many TLDs. You can choose a ccTLD (which, I might note, >> nobody is calling monopolies. Funny, that). > >ccTLDs *are* monopolies, but they are controlled by governments. >[In fact, a reasonable definition of a government is an entity with a >monopoly on force.] > Kent, It might be useful if you refresh everyone's memory about who your employer is. Are you still employed by the U.S. Government ? As for the so-called ccTLDs. Numerous examples have been cited to show that your above statement is not true. Two of the more high-profile examples are the .MQ and .GP TLDs, as well as the .FR TLD. It is now becoming clear that France does not control those TLDs. Sure, the French government wrote a paper about them, but people are thumbing their noses at the French government. Those TLDs remain. The flip side of this is the U.S. Government is trying to control .COM. People are thumbing their noses at that. If you had not noticed, there is a pattern here. TLDs are TLDs are TLDs. The people that control them all act the same way. Governments seem to have little or no impact. What use is it to continue to try to continue the myth that governments have control of the ccTLDs ? Jim Fleming Unir Corporation - http://www.unir.com 0:201 .COM http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt End-2-End: VPC(Java)--<IPv4>--C+ at ---<IPv8>---C+ at --<IPv4>--(Java)VPC http://www.ddj.com/index/author/idx10133.htm -------- Logged at Fri Oct 2 22:12:57 MET DST 1998 ---------

1 0

Public trust & IANA? - monopolistic rule-making
by nlockett＠Sidley.com 01 Oct '98

01 Oct '98

QUOTE: Section 3. NOTICE AND COMMENT PROVISIONS (b) Prior to adoption of any policies that substantially affect the operation of the Internet or third parties, the Board will: (i) provide public notice on the Web Site explaining what policies are being considered for adoption and why; (ii) provide a reasonable opportunity for parties to comment on the adoption of the proposed policies, to see the comments of others, and to reply to those comments; and (iii) after a reasonable comment period, take action on the proposed policies, establishing an effective date, and publishing the reasons for the action taken. UNQUOTE Which appears to mean: (i)We will tell you what we intend to do (ii) We will seek your comments (iii) after a reasonable comment period, we will do as we choose - regardless of our obligation to act in public trust function, your comments and our pre-existing obligations. Shouldn't iii) have something built in about requiring a majority of Registrars to expressly consent or not more than 5 registrars to object or similar. IANA still appear to be ignoring the fact that their authority to act is only by consensus and constrained by public trust functions. Where pre-existing rules have operated they appear to have obtained the status of contractual terms and those terms could only be changed by consent. Nick Lockett E-Mail: <mailto:NLOCKETT at sidley.com> Private E-mail: <mailto:netlaw at netlaw.co.uk> This message is the personal opinion of Nick Lockett -no liability is accepted -------- Logged at Fri Oct 2 14:59:37 MET DST 1998 ---------

1 0

FW: Public trust & IANA?
by nlockett＠Sidley.com 01 Oct '98

01 Oct '98

> -----Original Message----- > Sent: 01 October 1998 13:17 > To: 'govt-role at worldnames.net' > Subject: RE: Public trust & IANA? > > > > If IANA has made secret rule changes without going through the same > process of rule-making consensus as 1591 did, then whoever makes these > secret rule changes is working in breach of the public trust. > > > If acting in breach of trust the actions are probably void, I wonder > whether the public trust status may mean that the beneficiaries can > enforce local law? > > Does that breach also mean that IANA are open to a challenge that they are > unfit under RFC 1591?? <grin> > > Does that breach carry over with the obligations and liabilities > transferred to IANA2?? > <deep in thought> > > Regards > Nick Lockett > E-Mail: <mailto:NLOCKETT at sidley.com> > Private E-mail: <mailto:netlaw at netlaw.co.uk> > This message is the personal opinion of Nick Lockett. Where this message > contains legal issues, then no liability is accepted. -------- Logged at Thu Oct 1 17:13:09 MET DST 1998 ---------

1 0

Public trust & IANA?
by Sean＠Jackson.TC 30 Sep '98

30 Sep '98

Domain naming is subject to the public trust, says RFC1591. Given the all inclusive language in '1591 this must apply to the operation of the dot (root) domain as well as the gTLDS and ccTLDs. If IANA has made secret rule changes without going through the same process of rule-making consensus as 1591 did, then whoever makes these secret rule changes is working in breach of the public trust. Therefore introducing a rule which was dreamed up 'since RFC1591 was published' cannot be valid, and therefore Postel/IANA would be in breach of the public trust if they do anything except follow published RFC1591, and not any secretly amended versions God Bless You, Sean Sean Jackson, 3 Adams Road, Cambridge, CB3 9AD, United Kingdom. Tel: 01223 464 800 Fax: 0171 681 1268 -------- Logged at Thu Oct 1 17:13:50 MET DST 1998 ---------

1 0

The New IANA Needs Fiscal Controls
by bsemich＠mail.nu 30 Sep '98

30 Sep '98

The New IANA Bylaws: Who Controls the Money? By J. William Semich President and CFO .NU Domain Ltd http://whats.nu bsemich at mail.nu The latest set of proposed bylaws (version 5) for the New IANA Corporation (Internet Assigned Numbers Authority), released on September 29 at IANA's Web Site at http://www.iana.org/bylaws5.html, is seriously flawed by its lack of fiscal accountability to all of us who will use its services and pay its fees. If the bylaws are approved unchanged by the White House as the basis for the Internet's first independent governance mechanism, the new Internet Authority would be able to set a wide range of Internet-related fees of any amount without constraint, float bonds of any amount which must be funded by future revenues, as well as collect additional fees of any amount to invest for undefined possible future needs, all such to be paid for by you, me and our children, the Internet's users of today and tomorrow, without their review, approval or control. The new version of the proposed bylaws for the new Internet Authority will likely be submitted today to Ira Magaziner of the White House, under the terms of the White House "White Paper" released last January, to create the replacement for the US Government's current contractual arrangement for management of the Internet, which is set to expire today ( Sept. 30, 1998). But the new bylaws are completely devoid of any provisions to create any type of fiscal accountability for this, the Internet's first all-powerful, government-sanctioned independent Authority. Although the new bylaws make it clear that the source of the new Internet Authority's revenues will be the Internet's end users and service providers, it leaves all spending, borrowing, investment and other financial decision-making solely in the hands of the Corporation's board of directors, who's members specifically "have the duty to act in ... the best interests of the Corporation and not as representatives of their Supporting Organizations, employers or any other organizations or constituencies." (Article V, Section 8) Nowhere in the bylaws is the Board of Directors required to consult with any outside groups, experts, or other interested parties on how best to set its fees or plan its budget. Nowhere in the bylaws is there any provision for any kind of independent budget review or hearing mechanism or approval process for the budget, borrowing, or any other fiscal decisions; And nowhere in the bylaws is there any provision for any kind of independent fee-setting review process or approval mechanism, either by those who must pay the fees (the Supporting Organizations, who represent the consumers of the services to be provided by the new Corporation) or by any independent body of fiscal experts. All these fiscal decisions are made solely by the new Internet Authority's own Board of Directors. The relevant language in the proposed new bylaws makes this absolute power of the Board clear: FIRST, it gives the board absolute control over any spending or borrowing decisions: "Article IV, Section 1 (a) "the powers of the Corporation will be exercised, its property controlled and its business and affairs conducted by or under the direction of the Board." SECOND, it gives the board absolute control over the fee setting decisions: "Article IV, Section 2. FEES AND CHARGES The Board shall set fees and charges for the services, rights and benefits provided by the Corporation to the Supporting Organizations and others, with the goal of fully recovering the reasonable costs of the operation of the Corporation and establishing reasonable reserves for future expenses and contingencies reasonably related to the legitimate activities of the Corporation." And THIRD, it gives the Board the sole authority and absolute control over setting its annual budget, with no requirement that it actually meet that budget or that the budget pass any kind of review process, all this in one simple line of the new Bylaws: "Article V, Section 25. ANNUAL BUDGET The Board shall prepare an annual budget, which shall be published on the Web Site." These three phrases are the total extent of any language in the new bylaws that might be construed as setting ANY spending, fee setting and raising, budgeting, borrowing, investing or any other fiscal constraints on the board of the new Internet Authority which will be the primary manager of the single most important communications resource in the world. Such an all-powerful and fiscally unaccountable organization as would be created by the new bylaws is a classic textbook "Public Authority" in its structure, and that is the crux of my problem with the fifth set of IANA bylaws released on Sept. 29. Look closely at any publicly-funded independent Authority in the US and you will find a self-perpetuating, quasi-governmental organization whose spending decisions cannot be challenged, who spends the public's money like water, who has absolute power over its particular area of activity, but no accountability to the public. In the present case of the bylaws for the new Internet Authority, there is minimal accountability for its policy decisions, and that is cause enough for concern. But there is NO accountability for its borrowing, spending and fee-setting structure. There needs to be some kind of mechanism in the new entity that will create a counter-force to the typical Public Authority's inevitable desire to grow and to spend more and more money and increase its sway in the world. The counter-force to spending increases could be a Budget Review Committee solely comprised of the groups that will fund the new Internet Authority. Or it could be a Finance Committee made up of independent, world-renowned fiscal experts who have no vested interest in the new Internet Authority or the Internet per se. Or it could be a committee of government finance experts with experience bringing public spending into line. Or it could be some combination of the above. It would be a real tragedy if, in its first efforts at self-government, the Internet community were to hand over management of the Internet to yet another quasi-public Authority, who's essence is perhaps best defined in an article I co-authored nearly ten years ago: "Authorities constitute a permanent, expansionist government, collecting and spending more and more public money, running up more and more public debt, and making more and more critical decisions on the public's behalf with each passing day. And because authorities do all this out of site - and beyond the control - of the general public, they constitute, finally, a Shadow Government." "Inside the Shadow Government," by John Strahinich and J. William Semich, cover article, Boston Magazine, November, 1989. About J. William Semich: Currently: President and Chief Financial Officer .NU Domain Ltd http://whats.nu "One of the top 20 Top Level Domain Name Registries in the World" (Source: Http://www.domainstats.com/iso.cfm) Formerly: - Director of Financial Analysis for the City of Boston - Chairman, Finance Committee, Massachusetts Bay Transit Authority Advisory Board (The MBTA's Budget Review and Approval body) - Financial Adviser to the Mayor of Boston for Tax Policy and Planning - Assistant to Collector-Treasurer, City of Boston - Deputy Director and Executive Secretary to the Board, Boston Economic Development and Industrial Commission Achievements: - Co-author, "Inside the Shadow Government," Boston Magazine, November, 1989, selected as one of the "Top 10 Magazine Investigations of 1989," by Investigative Reporters and Editors, Inc. (IRE); - Lead investigator and financial consultant, WBZ-TV Boston's "I-Team," in-depth 1995 investigative report on the Mass. Turnpike Authority's actions over a ten year period to extend it's life using fiscal manipulations; - Co-author, "The Money Pit," Boston Magazine, September, 1986, investigative article on abuses by the Mass. Convention Center Authority in its redevelopment of the Hynes Convention Center -------- Logged at Thu Oct 1 17:12:56 MET DST 1998 ---------

1 0

3:63 NL (NETHERLANDS)
by JimFleming＠unety.net 29 Sep '98

29 Sep '98

It looks like we can file this under G3 S63 for future reference... 3:63 NL (NETHERLANDS) http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)--<IPv4>--C+ at ---<IPv8>---C+ at --<IPv4>--(Java)VPC http://www.ddj.com/index/author/idx10133.htm -----Original Message----- From: name.space <pgp at pgmedia.net> To: IFWP Discussion List <list at ifwp.org> Cc: postel at isi.edu <postel at isi.edu> Date: Tuesday, September 29, 1998 2:50 PM Subject: [ifwp] Nomination: M.J. van der Peijl >Nomination: Marcel J. van der Peijl <m.j.van.der.peijl at eurorscg.nl> >Country: Netherlands >Region: European Union > > >ir. M.J. van der Peijl (ir is for 'ingenieur' = engineer = university >degree which you get after finishing your 4-year program but without >having the additional 4 years of writing a dissertation) > >Short history: > >Eindhoven University of Technology degree in compter sciences >('information systems') > >6 years digicash, of which 3 years as ecash team leader >author of ISpy WebCam software > >heavy into programming _anything_ (windows, dos, unix, smartcards, >embedded systems) in most languages > >current position: head of system architecture at EuroRSCG interactive, a >40-people internet development/design company which is part of a large >international organization of advertising agencies 'EuroRSCG' which >operates in 60 countries. > >http://www.eurorscg-interactive.com/ > > > >__________________________________________________ >To view the archive of this list, go to: >http://lists.interactivehq.org/scripts/lyris.pl?enter=ifwp > >To receive the digest version instead, send a >blank email to ifwp-digest at lists.interactivehq.org > >To SUBSCRIBE forward this message to: >subscribe-IFWP at lists.interactivehq.org > >To UNSUBSCRIBE, forward this message to: >unsubscribe-ifwp at lists.interactivehq.org > >Problems/suggestions regarding this list? Email andy at interactivehq.org. >___END____________________________________________ > > -------- Logged at Wed Sep 30 16:55:24 MET DST 1998 ---------

1 0

Fw: minutes RIPE31
by JimFleming＠unety.net 29 Sep '98

29 Sep '98

Bob, Your IFWP group may want to review these meeting notes. David Kessens is from USC/ISI which is in the U.S. despite the fact that RIPE is mostly in Europe. You might note that the "assumption" is made that RIPE, ARIN and APNIC will be the monopoly distributors with no pricing changes. The IANA is assumed to be at the top of the MLM structure. While people are focused on domain name debates, the "land" in cyberspace is being divided up for sale or lease. IANA supporters never seem to be concerned about these monopoly arrangements. Why is that ? Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)--<IPv4>--C+ at ---<IPv8>---C+ at --<IPv4>--(Java)VPC http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://www.ddj.com/index/author/idx10133.htm -----Original Message----- From: David Kessens <davidk at ISI.EDU> To: ipv6-wg at ripe.net <ipv6-wg at ripe.net> Date: Tuesday, September 29, 1998 1:36 PM Subject: minutes RIPE31 > >Hi, > >Below follow the preliminary minutes of the IPv6 wg. > >I would like to thank Sabrina Waschke of the RIPE NCC for taking the >minutes. > >The minutes will be regarded final and I will forward them to the RIPE >NCC if I don't receive comments within one week from now. > >Thank you all for attending the meeting, > >David K. >--- > >Minutes of IPv6 Working Group, 24th of Sept. 1998 > >1. Administrative stuff: > >Chair: David Kessens (Thomas Trede apologised) >Minutes: Sabrina Waschke ># Attendees: 81 > >2. Reports > >Report - 6Bone by David Kessens >- Status report > there are now about 300 IPv6 connected sites on the 6bone > the trend is to connect natively instead of using tunnels > (slides will be available at http://www.ripe.net/meeting/ripe/ripe31/pres/) >- Information on the 6bone can be found at: > see <http://www.6bone.net> > >3. Current status of RIPE regarding address assignments in IPv6 by >Paula Caslav > >- RIPE NCC is in process of discussing the documentation, finding > guidelines and procedures, by taking the IETF draft, looking at the > criteria, what documentation will we need, working on details with > other regional registries and will have a meeting with them, send than > a draft to the relevant working groups and the RIPE community, final > version will be published - Hopefully ready in January 1999 > >Question by: David Kessens: >Could you give more detail in the time scale ? > >Paula Caslav: >November 1998: first draft of procedures document ready to be discussed >among the regional registries and RIPE >January 1999: start allocating IPv6 addresses >(depends on IANA to be ready to allocate to the regional registries >and on the registries to get their databases and procedures compliant) >All regional registries will start allocating at the same time. > >There will be no change in the fee structure for the next year. > >Question by David Kessens: >Do you have any comments what will be different in the assignment >guidelines for the TLA's in the IETF draft and yours ? > >Paula Caslav: >We might do a slow start mechanism in meaning of allocating a sub TLA >first. > >Mirjam Kuehne: >We also need to define still how to determine if an organisation is a >transit provider. Many details are still under discussion. > >Comment by the audience: >It might be useful to have a document in this Working Group as soon as >possible. > >Mirjam Kuehne: >We are in the process of collecting input and will discuss it with the >other Working Groups. >We receive requests for IPv6 addresses, some are detailed, some are >just general. >We will see how we can implement this in the operations and >procedures. > >Paula Caslav: >If you have any ideas send them to us or the mailing list of this >Working Group. > > >2.3. News about manufacturers implementation >- input from the audience > >Bernhard Tuy showed an overview of all vendors and what they >currently support. For details see: >http://www.phoebe.urec.fr/G6 >http://www.ipv6.urec.fr/G6 > > >4. General Input from other Working Groups > >Routing WG presented by Joachim Schmitz >(slides will be available at http://www.ripe.net/meeting/ripe/ripe31/pres/) > >Do we need an IRR for IPv6 ? > >Need for an IPv6 IRR: >- due to the benefits: YES >- plus: manage interface ipv4 _> ipv6 >- time to early: NO > >We need an IPv6 routing registry ! > ><general acceptence without taking over any concrete initiative by >the audience> > >Joachim Schmitz: >Call for participation. >He expects a gradual move over, requirements in the beginning are not >very high, so one registry might be enough to start with. > >David Kessens: >The regional registries also need to think about assignment policies >for AS numbers, they might be different. > >David K: >There are several ways to go to a IPv6 routing registry: >1. just replace IPv4 with IPv6 addresses in RPSL, > and add IPv6 specific support later on >2. a special RPSLv6 draft with all bells and whistles that are > required to do IPv6 routing registries > >What is better ? > >Joachim Schmitz: >Both are needed, because RPSL took some time to be developed and we >need something running soon. >That's not sufficient but better than nothing. > > >David Kessens: >Coming out with an RPSL IPv6 version would make sense. > > >5. AOB: > >David Kessens: Keep this Working Group and move on because of the >large interest (81 attendees). Discuss the allocation and assignment >process in more detail. > >Action points: > >31.1 RIPE NCC will start allocating IPv6 addresses by the next RIPE > meeting in January. > -------- Logged at Wed Sep 30 16:53:10 MET DST 1998 ---------

1 0

RIPE statement on new IANA draft 4 bylaws
by k13＠nikhef.nl 28 Sep '98

28 Sep '98

RIPE Statement on the Draft Articles and Bylaws for the new IANA as published on September 17th 1998 Edinburgh, 25 September 1998 RIPE is the organisation which has provided the framework for Internet co-operation in Europe since 1989. At the 31st RIPE meeting, held in Edinburgh from 23 until 25 September 1998, 253 participants from the European Internet industry discussed the fourth draft of the Bylaws of the New IANA, published on 17 September by IANA, and decided unanimously to express the following concerns. - We find it inappropriate that provision is made in the Bylaws (Article IV, Section 1.d) which binds the new IANA to agreements to be made between third parties, whose terms are not yet announced. - We need to understand and consider the material consequences of Article IV, Section 1.e in order to determine whether we can accept this section. - We are concerned about the room for interpretation in Article V, Section 6 and would like to see a stronger requirement of diversity than to allow 50% of the board to be from one region. - We are concerned about the far-reaching repercussions of codifying, at this stage, aspects of a possible membership structure that previously were left for the Initial Board to define and implement. We do not understand the reason for the fact that the board members nominated by the supporting organisations have no say at all in how the membership structure is implemented (V.4.a.iv, V.9.c). - We need to understand the reasons for and the material consequences of the weakening of the language in Section VI.1.c which now speaks of recommendations by the supporting organisations to the board. - It appears that the change in wording of Article III.2 may now imply that minutes of supporting organisation bodies have to be approved by the Board of the new IANA. We find this inappropriate. - We are anxious about the possible consequences of the changes made to the requirements for supporting organisations, especially in Article VI, Sections 2 and 3.b. In the area of the address supporting organisation the participation of individuals and individual organisations currently happens at the local and regional levels. Many European ccTLD registries already operate similar processes; others have begun working along these lines. We need to understand whether the Bylaws allow for this practice to continue or if they constrain the supporting organisations sufficiently to require changes in these structures. We stress that we have no difficulty with the added openness requirements. We are willing to work to resolve the remaining issues with all parties concerned as soon as possible, and hope that this statement, expressing our concerns, will be received as a helpful contribution to the process. We urge all concerned not to proceed with the current proposal before our concerns are addressed. In the meantime the current IANA should continue to function and provide its services to us. Rob Blokzijl Chairman RIPE -------- Logged at Wed Sep 30 16:51:42 MET DST 1998 ---------

1 0

"You have 0 day(s) remaining to provide comments."
by JimFleming＠unety.net 28 Sep '98

28 Sep '98

This sort of says it all... @@@@ http://www4.nas.edu/webcr.nsf/CommitteeDisplay/CSTB-L-97-05-A?OpenDocument "You have 0 day(s) remaining to provide comments." @@@@@@@@@@@@@@@@@@@@@@@ Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)--<IPv4>--C+ at ---<IPv8>---C+ at --<IPv4>--(Java)VPC http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://www.ddj.com/index/author/idx10133.htm -------- Logged at Mon Sep 28 12:16:26 MET DST 1998 ---------

1 0

regarding potential new IANA initial board members
by JimFleming＠unety.net 27 Sep '98

27 Sep '98

-----Original Message----- From: Jon Postel <postel at ISI.EDU> To: ietf at ietf.org <ietf at ietf.org> Date: Sunday, September 27, 1998 1:30 PM Subject: regarding potential new IANA initial board members > >Hello. > >There has been some discussion of candidates for the initial board for >the new IANA organization. While the current suggestions being >circulated are appreciated, i don't think they provide the kind of >board that would be most desireable. > >A key responsibility of the new IANA board is to see that policies and >procedures are developed in a fair and open manner, not to rehash all >the arguments and positions that go into developing those policies and >procedures. > Greetings from ::83C9:209.224.171.1 I assume that you are referring to the IPv4 (0:0) address space and therefore the .ARPA TLD. Obviously, other people on Earth will be managing address spaces and TLDs with different criteria and value systems from you and your high-school friends and ISOC associates. 0:0 .ARPA http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt Assuming that the Board is bounded by .ARPA and 0:0.X.X.X.X I suggest that the current Internet Architecture BOARD (IAB) http://www.iab.org/iab/ be used to create an interim Board to get your U.S. corporation started. That will allow you to easily meet the U.S. Government deadlines. It will also provide the IAB with a legal structure, similar to the ISOC. As for the other address spaces and TLDs, in my opinion the exit of the U.S. Government on October 1st and availability of new TLDs and IPv8 address spaces will pave the way for privatization to rapidly occur. This expansion will depend for some period of time on the .ARPA 0:0.X.X.X.X legacy transport network. How that network is governed on a day to day basis does not have to impact the rest of the free world, from a long-term point of view. As with most aspects of the Internet, people can now route around the legacy 0:0 Internet if they so desire. The technology is readily available (http://www.bsdi.com) and the will of the "everday people" on planet Earth is still strong. I look forward to working with those people in the future. Good luck with .ARPA and 0:0.X.X.X.X, it is just one of many... Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)--<IPv4>--C+ at ---<IPv8>---C+ at --<IPv4>--(Java)VPC http://www.ddj.com/index/author/idx10133.htm -------- Logged at Mon Sep 28 12:27:18 MET DST 1998 ---------

1 0

Why we are looking at a fait accompli with the new IANA
by JimFleming＠unety.net 27 Sep '98

27 Sep '98

-----Original Message----- From: Dave Crocker <dcrocker at brandenburg.com> <snip> > >One would think that, by now, the difference between ccTLDs which align >naturally with national borders (or the equivalent) and gTLDs which do not >align with any natural organization, would be quite clear. > How many "flavors" of TLDs are there ? .IO - Indian Ocean Territory - Based in England ? .CD - Audio CDs ? .IS - http://this.is .TV - Television ? .TM - http://www.nic.tm - Trademarks ? .FM - http://www.dot.fm - FM Radio Stations .TO - http://www.nic.to - "Second Chance for the Domain Name You Want" Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)--<IPv4>--C+ at ---<IPv8>---C+ at --<IPv4>--(Java)VPC http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://www.ddj.com/index/author/idx10133.htm -------- Logged at Mon Sep 28 12:14:37 MET DST 1998 ---------

1 0

"strong request by CENTRE"
by JimFleming＠unety.net 27 Sep '98

27 Sep '98

Bill, What is this "strong request by CENTRE" ? @@@@ http://www.gtld-mou.org/pab/mail-archive/00313.html "But it is *not* clear "that a DNSO must be formed very quickly," in light of the recent strong request by CENTRE that the process be slowed down, and I do not agree with that part of the statement." @@@@@@@@@@@@@@@@@@@@@@ Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)--<IPv4>--C+ at ---<IPv8>---C+ at --<IPv4>--(Java)VPC http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://www.ddj.com/index/author/idx10133.htm -------- Logged at Mon Sep 28 12:14:38 MET DST 1998 ---------

1 0

[dnsproc-en] 1.3 IANA-2 Board Nominees
by JimFleming＠unety.net 26 Sep '98

26 Sep '98

-----Original Message----- From: toru <toru at tokyonet.ad.jp> To: Bob Allisat <bob at FCN.NET>; DOMAIN-POLICY at LISTS.INTERNIC.NET <DOMAIN-POLICY at LISTS.INTERNIC.NET> Cc: ietf at ietf.org <ietf at ietf.org>; dnsproc-en at wipo2.wipo.int <dnsproc-en at wipo2.wipo.int> Date: Saturday, September 26, 1998 5:10 AM Subject: RE: [dnsproc-en] 1.3 IANA-2 Board Nominees No Asian, no African, maybe. Big discrimination! Toru Takahashi @@@@@@@@@@@@@@@@@@ That is not the case in the IPv8 Plan. There are 8 Regions. G4 and G5 still need help. You could help. G0, G1, G3 and G6 are in good shape. G2 is still lagging behind. With 8 Regions and 2 people representing each Region elected from the people in that Region, we can have a fair distribution. It has to start with the Grass Roots to be from the bottom up. If people keep following those that want top-down solutions, they will get top-down answers. Some people will accept those top-down answers and others obviously have other plans. The choice is yours. Each person has a choice. Each person has a voice...in the IPv8 Plan... http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)--<IPv4>--C+ at ---<IPv8>---C+ at --<IPv4>--(Java)VPC http://www.ddj.com/index/author/idx10133.htm -------- Logged at Mon Sep 28 12:13:42 MET DST 1998 ---------

1 0

Why not suggest MORE registries ?
by JimFleming＠unety.net 26 Sep '98

26 Sep '98

Keith Mitchell, Chairman (KM) Wilfried Woeber, Secretary (WW) Kees Neggers, Member (KN) Daniel Karrenberg, RIPE NCC manager (DK) Frode Greisen, Member (FG) Wim Vink, Treasurer (WV) Rob Blokzijl (RB) Kees van Draanen (KvD) Paul Rendek (PR) @@@@ http://www.ripe.net/meetings/board/six.html "5. Hiring Policy DK informs the Board about the recruitment problems RIPE-NCC has recently been having.... However, in recent months we have been experiencing more and more immigration difficulties when recruiting staff from outside the EU. The authorities have increased their scrutiny of applications for working permits for new staff from outside the EU." @@@@@@@@@@@@@@@@@@@@ The obvious solution seems to be to create MORE registries closer to where the people live. Why isn't that listed as an option ? Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)--<IPv4>--C+ at ---<IPv8>---C+ at --<IPv4>--(Java)VPC http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://www.ddj.com/index/author/idx10133.htm -------- Logged at Mon Sep 28 13:24:27 MET DST 1998 ---------

1 0

Legal action?
by Sean＠Jackson.TC 25 Sep '98

25 Sep '98

We have today heard rumors about a multi-million dollar lawsuit that might be about to be served on NSI, the University of Southern California regarding the re least one TLD delegation. We understand this might relate to IANAs failure to follow its own published rules (presumably RFC1591.) Since IANA doesn't have statutory authority, it seems to us that must open up its officers to unlimited personal liability for damages. It also raised the question that if the threatened lawsuit does come to pass, then would seem that the main person concerned in drawing up the model for the future IANA hasn't been following their own existing rules! What sort of message is this going to send to the world at large? It will seriously damage everything we've all be working so hard to achieve over the last 2 or 3 months. And whoever it is who decided to start revoking TLD registrations at this most sensitive time will be the sole party responsible for it. So what is going on? Surely it is in the interest of everyone involved that the only published terms of delegation (RFC1591) be followed and, as we said, only the other day, RFC1591 must be our starting point for the future. Maybe there should be a class action on behalf of all TLD managers to make sure this is kept to? P. S Won't IANA Mk2 as the successor to IANA be liable for any resulting damages from any lawsuit? God Bless You, Sean Sean Jackson, 3 Adams Road, Cambridge, CB3 9AD, United Kingdom. Tel: 01223 464 800 Fax: 0171 681 1268 -------- Logged at Fri Sep 25 10:06:26 MET DST 1998 ---------

2 1

CENTR Statement on Fourth Draft Definition of the New IANA
by gihan＠cse.mrt.ac.lk 23 Sep '98

23 Sep '98

>CENTR Statement on Fourth Draft Definition of the New IANA In principle, I agree with the CENTR position. While the effect of some of the provisions are not clear to me, the process of creating the document seems to be flawed. I also agree that we should not pre-suppose any deadlines. Anything done in a hurry is likely to disadvantage weaker parties. Gihan Dias LK Domain Registrar -------- Logged at Thu Sep 24 19:11:33 MET DST 1998 ---------

1 0

It's been posted -- Boston Working Group
by domainz＠ibm.net 23 Sep '98

23 Sep '98

Dear ccTLD members, Here is the URL of the outcome of our meeting in Boston on Saturday last. My regards, PAtrick, .nz -----Original Message----- From: Karl Auerbach [SMTP:karl at cavebear.com] Sent: Wednesday, September 23, 1998 8:50 AM To: dc at mama-tech.com; Ellen Rony; Eric Weisberg; Jorge Contreras; Mikki Barry; Milton Mueller; Patrick O'Brien; pdthrush at chambers.gen.nz; Peter R. Rony Subject: It's been posted -- Boston Working Group I just posted the following to the IANA comments list, ifwp, ifwp-law, and domain name policy... So we are live. --karl-- A group of IFWP participants gathered at an open meeting on the weekend of September 19 and 20th, 1998 to see whether it was possible to reconcile the NSI/IANA draft with the IFWP consensus points. We believe that we succeeded. For the results, see http://www.cavebear.com/bwg/ Summary of Changes - Added Preamble and statement of purpose. - Removed text that established the purpose of the corporation to be solely for "lessening the burdens of government". - Mandated that the Initial board create a membership structure, without exception. - Defined "fundamental" assets expected to be received from the US and added constraints upon what the corporation can do with those assets. - Removed President from the Board of Directors. - Re-cast Supporting Organizations to be essentially permanent advisory committees with very strong role in initiating and defining corporation policies. - Eliminated Supporting Organizations' ability to appoint Directors to either the Initial or the final Board. - Clarified that individuals may be members of Supporting Organizations. - Added on-the-record, roll-call voting on matters before the Board. - Added additional public access. - Broadened rights to Board Reconsideration. - Eliminated special and unique recognition of contracts between the US and NSI and between the US and University of Southern California. - Added a more robust business planning and cost-recovery model. - Required that conflict-of-interest statements be made public subject to reasonable privacy limitations. - Required that conflict-of-interest provisions be applied to officers as well as to members of the Board. - Recommended the reduction in the number of officers to the legal minimum. - Other minor matters of clarification of language and structure. -------- Logged at Thu Sep 24 19:10:56 MET DST 1998 ---------

1 0

CENTR Statement on Fourth Draft Definition of the New IANA
by Niall.oReilly＠ucd.ie 22 Sep '98

22 Sep '98

CENTR Statement on Fourth Draft Definition of the New IANA Edinburgh, 22 September 1998 Scope of this Document CENTR is in a position to speak on behalf of the European ccTLD Domain Registries and has already (March, July 1998) made known: its position concerning the future governance of the Internet; its requirements of the organisation which will be the successor (the "New IANA) to the present IANA; and its readiness to participate in the definition of, and to support the funding of this New IANA. This document comments on the fourth draft definition (Postel, Battista, September 1998) of the Bylaws of the New IANA in the light of CENTR's clearly expressed position and requirements. Process leading to the Fourth Draft Definition We have understood that the diverging opinions expressed at the Singapore IFWP meeting were taken into account by Jon Postel in preparing the third draft definition (Postel, August 1998) of the New IANA. We find that this draft represents a reasonable consensus which CENTR can support. We find it surprising that, in the process of preparing the fourth draft definition, a position paper from a particular stakeholder has apparently been given equal recognition to that accorded to Jon Postel's documentation, as we understood it, of a consensus process. This is a matter of global public interest and we believe that it is inappropriate that a private company should be allowed to have such influence in the process. Particular objections to the Fourth Draft Definition Section IV.1.d of the draft appears to have the intent of binding the New IANA to the terms of agreements yet to be made between third parties. It is our view that such a provision is entirely inappropriate. We cannot accept that the New IANA be bound in this way. The intent of Section IV.1.e is unclear. If the intent of this section is to ensure stability in the short-to-medium term, so that existing contracts and relationships, in particular delegation of TLD's, between IANA and involved parties are protected, the language of the section ought to make this clear. If the intent is rather to copper-fasten existing positions indefinitely and to offer protection against the introduction of competition, we find the section unacceptable. We fear that the headline set by sections IV.1.d and .e will lead to a situation where the process for establishing the proposed Domain Naming Supporting Organisation will also be dominated by similar private interests. We find that the terms of Section V.6 do not ensure a sufficiently broad spread of international representation, but rather allow a majority of members of the Board to come from a single region. We require instead that no more than one board member be elected from any support organization from each region. References CENTR, March 1998 "RIPE CENTR Position Paper on Future Governance of the Internet" <http://www.ripe.net/centr/docs/governance.html> CENTR, July 1998, "CENTR Position on the New IANA structure" <http://www.ripe.net/centr/docs/response-white.html> Postel, August 1998, "New Proposed Bylaws - Third Iteration" <http://www.iana.org/bylaws3.html> Postel, Battista, September 1998, "A Brief Explanation of the Joint IANA and NSI Documents ..." <http://www.iana.org/intro-coop.html> Postel, Battista, September 1998, "DRAFT BYLAWS FOR INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS" <http://www.iana.org/bylaws-coop.html> Postel, Battista, September 1998, "ARTICLES OF INCORPORATION OF INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS" <http://www.iana.org/articles-coop.html> For Boudewijn Nederkoorn, CENTR Policy Group Chair, Niall O'Reilly -------- Logged at Wed Sep 23 11:07:52 MET DST 1998 ---------

2 1

Fw: Fw: 3:242 ES (SPAIN)
by richard＠vrx.net 21 Sep '98

21 Sep '98

>>>The legacy TLD holders are mostly structued to make PROFIT. THe new TLD >>>holders are structued to banish to profits of those Legacy Holders. >>> >> >> legacy TLD holders was there for public interest. New candidates for >>holding new TLDs are for profit. C'mon, in this sort of TLD-gold rush new >>companies are entering bussiness for the money they can do, no for the >>public interest. Of course, hoist the freedom flag is the usual way to get >>the resource to exploit, fooling people. NObody needs ESP, neither AUS, >>IRC, GBR ... but to make money out of it. There are two possabilities. Either people who want to run new tlds want to do sosoly to make money, or they do not. If they are prevented from every being able to run tlds, then it is very easy to say "see, we stopped those bad people" and you have, in effect, a self fulfullng prophecy and the current monoply makes one company more wealthy. If on the other hand, new tlds are not being run solely to make egregious profits (and frankly, given there are more than 50 or so, no regisry should make a huge amount of money, the registrar business is much more lucritive) then by preventing them from exising, you have caused, a priori, a massive injustice. How can you be so sure you are right ? -- richard at culture.getty.edu "It's all just marketing" -------- Logged at Tue Sep 22 19:35:35 MET DST 1998 ---------

1 0

RIPE NCC comments on new IANA drafts published on September 17th
by Daniel.Karrenberg＠ripe.net 20 Sep '98

20 Sep '98

RIPE NCC Statement on the Draft Articles and Bylaws for the new IANA as published on September 17th 1998 Amsterdam, September 18th 1998 The RIPE NCC executive board,representing the RIPE NCC membership, has considered the draft articles and bylaws for the new IANA published jointly by NSI and the IANA on September 17th. We note that there are a considerable number of substantive changes from those previous draft documents published by the IANA which we publicly supported as the basis for further development. Given the number and the substance of the changes there has been insufficient time for due consideration and consultation. Yet the authors of the latest drafts indicate that they wish to proceed 'within a day or two'. With this in mind we have to state now that at this time the RIPE NCC cannot support the current drafts or commit to participate in a new IANA constituted by them. We need sufficient time to consider all the changes and in particular: - Codifying in the bylaws that the new IANA will a-priori respect arrangements between third parties without any knowledge of them. This requires careful consideration because of the far reaching implications such arrangements may have on the new IANA. (IV/1d) - We need to understand and consider the material consequences of art IV/1e in order to determine whether it is acceptable. - We are still concerned about the room for interpretation in art V/6 and would like to see a stronger requirement of diversity than allowing 50% of the board to be from one region. - We need to understand and consider the far-reaching repercussions of codifying, at this stage, aspects of a possible membership structure that previously were left for the Initial Board to define and implement. In this context we also need to re-evaluate the fact that the board members nominated by the supporting organisations have no say at all in how it is implemented (V/4b/iv V/9c). - We need to understand the reasons and the material consequences of the weakening of the language in VI/c which now speaks of recommendations by the supporting organisations to the board. - We need to get clarification that the change in wording of art III/2 does not now imply that minutes of supporting organisation bodies have to be approved by the Board of the new IANA. - We need to fully understand and consider the consequences of the changes made to the requirements for supporting organisations, especially VI/2 and VI/3b. In the area of the address supporting organisation the participation of individuals and individual organisations currently happens at the local and regional levels. We need to understand whether the bylaws allow for this practice to continue or if they constrain the supporting organisations sufficiently to require changes in these structures. We stress that we have no issue with the added openness requirements. We will work to resolve the remaining issues with all parties concerned as soon as possible. The upcoming series of RIPE and related meetings in Edinburgh between September 21st and 25th will provide a good opportunity to make progress in our geographical area. We urge all concerned not to proceed with the current proposal before these concerns are addressed and we have had the opportunity to ensure that the RIPE NCC can participate fully in the new IANA. In the meantime the current IANA should continue to function and provide its services to us. We are willing to immediately and unilaterally contribute US$ 50k towards the operational costs of the current IANA after September 30th. -------- Logged at Mon Sep 21 16:47:40 MET DST 1998 ---------

1 0

Martinique in 1999 ?
by JimFleming＠unety.net 19 Sep '98

19 Sep '98

John, Maybe your group should host the next IETF meeting ? This might help to show France that you are organized and intend to try to protect your .MQ and .GP TLDs. http://www.ietf.org/meetings/0mtg-sites.txt @@@@ http://www.wwtld.org/lactld.txt os at atina.ar (Argentina AR - Oscar Sznajder) demi at agestado.com.br (Brazil BR - Demi Getschko) ppoblete at DCC.UCHILE.CL (Chile CL - Patricio Poblete) hsin at UNIANDES.EDU.CO (Columbia CO - Hugo Sin Triana) edgarn at geocities.com (Dominican Republic DO - Juan Edgar) jmiranda at ecnet.ec (Ecuador EC - Juan Miranda) ribarra at di.uca.edu.sv (El Salvador SV - Rafael Ibarra) jan.david at proximus.be (French Guiana GF - Jan David) jbroom at manta.outremer.com (Guadeloupe GP - John Broomfield) furlan at uvg.edu.gt (Guatemala GT - Luis R. Furlan) erlin at sdnhon.org.hn (Honduras HN - Erlin Palma) jbroom at manta.outremer.com (Martinique MQ - John Broomfield) orobles at nic.mx (Mexico MX - Oscar Robles Garay) Sean at Jackson.TC (Montserrat MS - Sean Jackson) ymena at gbm.net (Nicaragua NI - Yadira Mena) js at rcp.net.pe (Peru PE - Jose Soriano) Sean at Jackson.TC (South Georgia and Sandwich Isl. GS - Sean Jackson) danielsah at msn.com (Saint Lucia LC - Albert H. Daniels) P.Hosein at att.com (Trinidad and Tobago TT - Patrick Hosein) Sean at Jackson.TC (Turks and Ciacos Islands TC - Sean Jackson) holz at seciu.uy (Uruguay UY - Ida Holz) oaguirre at reacciun.ve (Venezuela VE - Oswaldo E.Aguirre) Sean at Jackson.TC (Virgin Islands [British] VG - Sean Jackson) pdeblanc at usvi.net (Virgin Islands [U.S.] VI - Peter de Blanc) @@@@@@@@@@@@@@@@@@@@@@@@@@ Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)---C+ at ---<IPv8>---C+ at ---(Java)VPC http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://www.ddj.com/index/author/idx10133.htm -------- Logged at Mon Sep 21 17:14:51 MET DST 1998 ---------

1 0

Four TLDs
by JimFleming＠unety.net 18 Sep '98

18 Sep '98

Sean, I see that you have 4 TLDs. How did you obtain so many ? @@@@ http://www.wwtld.org/lactld.txt Sean at Jackson.TC (Montserrat MS - Sean Jackson) Sean at Jackson.TC (South Georgia and Sandwich Isl. GS - Sean Jackson) Sean at Jackson.TC (Turks and Ciacos Islands TC - Sean Jackson) Sean at Jackson.TC (Virgin Islands [British] VG - Sean Jackson) @@@@@@@@@@@@@@@@@@ Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)---C+ at ---<IPv8>---C+ at ---(Java)VPC http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://www.ddj.com/index/author/idx10133.htm -------- Logged at Mon Sep 21 17:14:08 MET DST 1998 ---------

1 0

.US and the USPS
by JimFleming＠unety.net 17 Sep '98

17 Sep '98

@@@@@ http://www.ntia.doc.gov/ntiahome/domainname/usrfc/comments/8-17-98.htm "In response to the "Request for Public Comment on the Enhancement of the .us Domain Space," the United States Postal Service is prepared to coordinate the administration of the .us Country Code Top Level Domain (ccTLD) with direct input and participation from Internet stakeholders." @@@@@@@@@@@@@@@@@@@@@ Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)---C+ at ---<IPv8>---C+ at ---(Java)VPC http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://www.ddj.com/index/author/idx10133.htm -------- Logged at Sun Sep 20 23:00:57 MET DST 1998 ---------

1 0

.GP, .TM, .TV and .MQ to be Removed ?
by richard＠sexton.com 16 Sep '98

16 Sep '98

At 10:27 AM 9/16/98 -0400, John Charles Broomfield wrote: >Hi Richard, > I agree that the current system is less than perfect, but how would >YOU select what is or not a country. Based on historical facts, not what some company in Europe (ISO) thinks for revisionist politial reasonings. Tibet *used* to be a country, I have Tibetan stamps and all, but China says it's not a country any more. Tough. Tibet is still a country to the Tibetans and to most of the rest of the world >Even further, are you sure it's a good >idea to actually have a body responsible for technical matters draw a list >of what is or not a country? Yes. >I feel that the creation of such a list is a >HIGHLY political affair (Is Palestine a country or not?) Ask the people who were born there. >Say you don't like the name of your street, and you don't like the fact that >your postman brings mail addressed to your street-name. Do you bash your >postman or the post-office? It's not the post-office that decides names for >streets, and to be honest it's not their business either. You take up the >issue of street names with whoever is in charge of naming them (say your >local town-hall for example). You don't start a national campaign >complaining about the way that the postal service designates streets >(basically because it's NOT the PS designating them). You're right, I didn't start a national campaign. Here's what I did: My current address is Box 2, RR #1 Eldorado, Ontario, K0K 1Y0, CANADA It would he hard to think of a more ugly address for a charming 200 year old hotel that is now my residence. Moreso, Eldorado is 10km south of here. Bannockburn actually does exist. We have a big government installed sign, and everything. You can see it here, if you want: http://hastings-county.vrx.net/centre/bannockburn/rd05.jpg So, looking back through the history books I noticed this place used to be called "The Maitland Hotel, Bannockburn, Ontario" So, I simply use the address Maitland House Bannockburn, Ontario, K0K 1Y0, CANADA and that works just fine. I didn't even have to tell Lois, the mail lady. She's bright enough to figure it out. I've never had a problem with people saying "your snail mail bounced". Now, UPS and Fed-Ex can't deliver to *either* of those two addresses. They get all FAW with rural addresses, so, for them our address is 17245 Hiway #62 Ontario, Canada. Include the postal code and it messes them up, all they go by is the 911 emergency markers on the road. >IANA doesn't choose to consider Tuvalu a country and not Scotland. IANA does >however choose to use the ISO-3166 country code list. Do you have any other >suggestion of a list which has the countries that you personally consider >countries with a nice list of two-letter codes (or whatever) that could be >used instead? Didn't think so. Was there a list of .com/net/org/mil/gov/intarpa/edu ? Didn't think so. They were simply created, and the same canbe done for rational country codes. This whole discussion is .moot anyway, because as soon as there is a procedure in place to create new tlds, people will simply deploy three letter country codes as "generic" TLDs (I suppose toretaliate for the "psuedo-generic" two letter contry codes like .to and .nu) which toa great extent is already happening: .pol, .bul, .usa, .aus already exist, and there is nothing that can prevent .tbt or .tibet, .sct or .scotland and so forth. The ISO2 codes are capricous and arbitrary and in a few years will seem as antiquated as .com; both falling into disuse as an obscure relic and a perfect exsmple of state-of-the-art 1986 ISO Internet taxonomoy. -- "I think it is important to understand that distribution of authority is better than dictatorship, and that the governance of TLDs and domains in general should be distributed rather than centralized." - Paul Mockapetris -------- Logged at Thu Sep 17 12:50:19 MET DST 1998 ---------

1 0

(Fwd) Proposed Agenda TLD-WG RIPE 31
by Niall.oReilly＠ucd.ie 16 Sep '98

16 Sep '98

Dear colleagues, I've had no suggestions for changes to this proposed agenda. Of course, we'll review it at the beginning of the meeting. Could the meeting secretariate please make the proposed TLD-WG agenda available on the Web ? Niall O'Reilly Chair, TLD-WG ------- Forwarded Message Follows ------- Date sent: Fri, 04 Sep 1998 10:47:56 +0100 From: Niall O'Reilly <Niall.oReilly at ucd.ie> Subject: Proposed Agenda TLD-WG RIPE 31 To: tld-wg at ripe.net Copies to: wg-chairs at ripe.net Send reply to: Niall.oReilly at ucd.ie Organization: University College Dublin Priority: normal RIPE 31 TLD-WG (Edinburgh, 23 September 1998) -- Proposed Agenda 1. Administrivia (14:00, 10 mins) 1.1 recognition of Scribe 1.2 agreement of Agenda 2. Matters arising from RIPE 30 TLD-WG meeting (14:10, 10 mins) 2.1 adoption of minutes (RIPE 29) 2.2 adoption of minutes (RIPE 30) 2.3 review of action list 3. Review Workplan (14:20, 10 mins) Workplan is due for formal review at each WG meeting. Many workplan items have received attention from RIPE-CENTR. Proposals for change and/or (re-) prioritization should be submitted before the meeting, please. 4. Liaison with other Working Groups (15:00, 30 mins) DB-WG re whois referral (following RIPE 30 TLD-WG) DNS-WG re best practice 5. RIPE-CENTR Progress (14:30, 30 mins) Presentation (Fay Howard) and discussion -- Break (15:30) -- 6. New IANA and Supporting Organisations (16:00, 60 mins) Additional participants will be welcome to join at this point! 7. AOB (17:00, 5 mins) 8. Conclusions (17:05, 20 mins) 11.1 revisit workplan priorities 11.2 summarize action list -- Close (17:25) -- -------- Logged at Wed Sep 16 19:06:42 MET DST 1998 ---------

1 0

.GP, .TM, .TV and .MQ to be Removed ?
by richard＠sexton.com 16 Sep '98

16 Sep '98

At 12:20 PM 9/16/98 +1000, you wrote: >Lets get some facts straight first. > Tuvalu (.TV) is probably not a 'countire', but according to > the CIA World Factbook (http://umsl.edu/services/govdocs/wofact96/254.htm) > it is indeed a country. > > The CoCos (Keeling) Islands (.CC) is probably not a 'countire' either, > whatever that may be, but according to the CIA World Factbook > (http://umsl.edu/services/govdocs/wofact96/63.htm) it is indeed a country, > currently administered as a territory by the Commonwealth of Australia. Ans "Scotland" is a country administered as a territory by England and has no country code. I suggest a forensic analysis of the "county code" tlds is in order. This point was raised by a dozen or so folks in Geneva. A sincere "thank you" for your input and a heartfelt "bite me" for the way it was presented. -- "I think it is important to understand that distribution of authority is better than dictatorship, and that the governance of TLDs and domains in general should be distributed rather than centralized." - Paul Mockapetris -------- Logged at Wed Sep 16 16:19:13 MET DST 1998 ---------

2 1

branch structure in ccTLD domainname space.
by artur＠zoo.pl 16 Sep '98

16 Sep '98

Hallo, I'm working on a project of branch structurization of ccTLD domain name space. Can you, please, write me what do you thing about that kind of solving some trademarks problems, self governing, lowering prices for domains year by year etc. What kind of problems can you see in it? Project: I've got 100+ domains in pl. such like sport.pl, prasa.pl (press) etc. I've all macroreginal domains like www.tatry.pl (geografical parts of Poland) and some city domains (for instance www.warszawa.pl) In my project when you register a domain through my partner (every ISP can be my partner and every partner have 50% discount for regist. end user: X$, partner 0.5X$ a year, every partner can take any of my domain in administration, but it's not a must), informations about your firm (ex. www.sport-daily.mag.pl for Sport magazine which names Sport-daily) is propagating in magazines' branch server - www.mag.pl, sport server www.sport.pl, regional server and city server (if it's local magazine - region and cities in this region). If someone is claiming, that he has rights to the name sport-daily title, he can only sue the man which uses it in domains for press and magazines (which is in some way correlated with trademark class), not in .pl domain or .music.pl. I'm giving my domains for ISP if he can guarantee that he will be a part of project, and will keep the rules of registariation. I'm giving regional domains to regional ISP, city to city etc. Because domains are given to ISP, cost of managment are "bluring" and can be lower and lower.... till a simbolic payment which can help us in checking which domains are in use and which can be removed. Kind regards, Artur Grzymala -------- Logged at Wed Sep 16 15:38:59 MET DST 1998 ---------

1 0

.GP, .TM, .TV and .MQ to be Removed ?
by richard＠sexton.com 16 Sep '98

16 Sep '98

At 05:41 PM 9/14/98 +0200, Daniel Karrenberg wrote: > > > "Richard J. Sexton" <richard at sexton.com> writes: > > At 03:39 PM 9/14/98 +0200, Hakan Hansson wrote: > > >At 14:50 1998-09-14 , Richard J. Sexton wrote: > > > > > >>.FX is the country code for Metropolitan France. This is not a country. > > >>Neither is Tuvala any more. Or the Cocos Islands (.CC). > > > > > >FYI: Faroe Islands (.fo) and Greenland (.gl) are parts of Denmark (.dk) an > > d > > >they have _never_ been independant countries. Why did they get their own > > >ccTLD in the first place? > > > > I have no idea. Ask Jon Postel. > >No, read rfc1591. The possible ccTLDs are defined by the United Nations and >published by ISO as ISO standard 3166. The IANA has -very wiselty- decided >to use that list and not get involved in arguments exemplified by this >thread. 2. The Top Level Structure of the Domain Names In the Domain Name System (DNS) naming of computers there is a hierarchy of names. The root of system is unnamed. There are a set of what are called "top-level domain names" (TLDs). These are the generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two letter country codes from ISO-3166. [...] In the country TLDs, there is a wide variation in the structure, in some countries the structure is very flat, in others there is substantial structural organization. In some country domains the second levels are generic categories (such as, AC, CO, GO, and RE), in others they are based on political geography, and in still others, organization names are listed directly under the country code. The organization for the US country domain is described in RFC 1480 [1]. Postel [Page 1] RFC 1591 Domain Name System Structure and Delegation March 1994 Each of the generic TLDs was created for a general category of organizations. The country code domains (for example, FR, NL, KR, US) are each organized by an administrator for that country. These administrators may further delegate the management of portions of the naming tree. These administrators are performing a public service on behalf of the Internet community. Descriptions of the generic domains and the US country domain follow. The problem seems to stem from the fact that "IANA is not in the business of determining what is and what isn't a country". This is a factual statementmade by IANA. The ISO3661 list containts codes that are not countries. This is a fact. IANA has mad entired in the root zone for two letter domains that are not countries. This is also a fact. So, are all two letter domains supposed to be countires, in which case .TV and .CC should be re-assessed, or, can any ISO code be made into a TLD, in which case .FX could be created. Given that IANA claims to not be inthe business of determining what a country is and instead uses a list that contains country code and non country codes, I would say this is a bit of a mess. -- "I think it is important to understand that distribution of authority is better than dictatorship, and that the governance of TLDs and domains in general should be distributed rather than centralized." - Paul Mockapetris -------- Logged at Tue Sep 15 16:45:36 MET DST 1998 ---------

2 1

.GP, .TM, .TV and .MQ to be Removed ?
by JimFleming＠unety.net 15 Sep '98

15 Sep '98

-----Original Message----- From: Richard J. Sexton <richard at SEXTON.COM> To: DOMAIN-POLICY at LISTS.INTERNIC.NET <DOMAIN-POLICY at LISTS.INTERNIC.NET> Date: Sunday, September 13, 1998 11:05 AM Subject: Re: .GP, .TM, .TV and .MQ to be Removed ? >At 09:05 AM 9/13/98 +0800, Dave Crocker wrote: >>At 02:49 PM 9/12/98 -0400, Richard J. Sexton wrote: >>>I also note that Jon Postel wants to see .TV and .TM removed >>>from the root zone, but NSI/NSF prevented that. >> >>please provide documentation for both of these assertions. > >Knock it off Dave, you were in the room in Singapore >when Don Telage announced this. Why didn't you ask him >for documentation? > > Again, I think that we need to look at the more global issue. What TLDs would Jon Postel (aka IANA) be proposing to remove from the legacy Root Name Server Cluster if the U.S. Government turns control over to him ? Does that list contain ? .GP .MQ .TV .TM .CC .NATO In my opinion registries and consumers have a right to know this well in advance. The other RSCs also need to socialize these proposed DELETIONS. Just because France tells Jon Postel to delete .MQ and .GP and to take away someone's IP addresses, I am not sure that he should do that. There has to be some checks and balances in the system. Where does the IAB and IETF enter this discussion ? It is one thing for the IETF to stand and cheer and endorse Jon Postel. It is another thing to be responsible for potential changes to the DNS that could impact companies, countries, etc. Jon Postel has delegated TLDs to people that clearly do not have the local support that some people claim. Now governments like France are going to try to have those TLDs removed. This is not stability. Stability can only come from open, fair hearings on these matters. In my opinion, the major RSCs should prepare a public response to France that indicates that they can NOT remove a TLD just because France says to do that. I think that the current operators of the TLD(s) should have some opportunity to have some say about the past, present and future plans for the TLD. This is the only way we can have some stability in the system. Just in case someone walked in late... @@@@ http://www.gtld-mou.org/pab/mail-archive/00298.html "Lastly, it is necessary to end rapidly the exploitation, by private operators having received no mandate from the French authorities, of the management of top level domains corresponding to French overseas departments (.gp for Guadeloupe, .mq for Martinique,...). IANA effectively considers that these are "national" domains. The French government must therefore request IANA to refuse to recognize these operators or to allocate them IP addresses." @@@@@@@@@@@@@@@@@@@@@@ Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)---C+ at ---<IPv8>---C+ at ---(Java)VPC http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://www.ddj.com/index/author/idx10133.htm -------- Logged at Mon Sep 14 11:34:21 MET DST 1998 ---------

4 4

.GP, .TM, .TV and .MQ to be Removed ?
by JimFleming＠unety.net 15 Sep '98

15 Sep '98

-----Original Message----- From: Einar Stefferud <Stef at nma.com> <snip> > >If you don't believe me, just ask the President of France;-)... > What about the thousands of people that could lose their .MQ or .GP domain names ? Don't they get any say ? Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)---C+ at ---<IPv8>---C+ at ---(Java)VPC http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://www.ddj.com/index/author/idx10133.htm -------- Logged at Tue Sep 15 16:47:29 MET DST 1998 ---------

1 0

An IPv8 View of .MQ (Martinique)
by JimFleming＠unety.net 14 Sep '98

14 Sep '98

The IPv4 people have largely been funded by governments around the world. It should not be surprising that they have tied their future to the wishes of those governments. The recent news that the French Government wishes to take control of some of the TLDs for regions it controls, geographically, is not a surprise. There is more info on the .FR TLD and the people behind that TLD which is apparently the one that France wants to move .MQ and .GP under. In the IPv8 Plan, TLDs (and other Internet resources) are placed freely into the hands of the people. The TLDs are all equal. They are divided into 8 regions to allow people to more easily coordinate. The 8 regions are all equal. The TLDs have INTENTIONALLY been radomly placed within the regions to try to make sure that TLDs can stand on their own and not be captured by groups that want them to be "under them". http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt To illustrate how the IPv8 Plan is intended to work, we can look at the real world situation where some people want the .MQ TLD deleted. In the IPv8 Plan a concept called "neighbor nets" is used to allow TLDs to benefit from the self-governance of the other TLDs that are in their neighborhood. In the case of Martinique, one might look at the neighborhood from Grenada (.GD) to the British Virgin Islands (.VG). 1:247 GD (GRENADA) 1:248 B (Single Letter TLD) 1:249 MINNEAPOLIS 1:250 MQ (MARTINIQUE) <----------- TO BE DELETED ? 1:251 PRINCETON 1:252 TCA (TURKS-AND-CAICOS-ISLANDS) 1:253 IDAHO 1:254 VG (VIRGIN-ISLANDS-(BRITISH)) If a super power is attempting to delete a small TLD like Martinique, then the other TLD managers in the "neighborhood" can come to Martinique's defense. Not only would this include the TLDs shown above but also all of the TLDs in the G1 Region. Even though people might find it strange for people in the .MINNEAPOLIS TLD or the .PRINCETON TLD to help Marinique, we have to realize that this is better than having the people in the .FR (France) TLD coming to the rescue because those people might be the very people that are trying to make .MQ go away. They may have financial reasons why they do not think .MQ should be allowed to exist. If it turns out that people are successful in convincing the RSCs to delete .MQ, then the 1:250 seat will be freed up to add a new TLD. The IPv8 address space 1:250.X.X.X.X would remain. Delegations under IN-ADDR.S250.G1 could remain, despite France's request for people's IP address allocations to be refused. In my opinion, it is not right to try to use the leverage of IP allocations to control the domain name industry. The IPv8 Plan attempts to prevent this. Hopefully, the RSCs around the world will come to some conclusion on how they intend to handle the .MQ TLD. Even though France carries a lot of political and economic weight, there still needs to be an element of the local decision making in both the real world and in cyberspace. I am confident that the collective reasoning of a broad group of people willl do the right thing about the .MQ TLD and the other TLDs that France wants removed. @@@@@@@@@@@@@@@@@@@@@@@@@@ France top-level domain (FR-DOM) AFNIC (NIC France) c/o INRIA, Domaine de Voluceau Le Chesnay CEDEX, 78153 FRANCE Domain Name: FR Administrative Contact: Renard, Annie (AR41) Annie.Renard at INRIA.FR +33 01 39 63 55 92 (FAX) +33 01 39 63 55 34 Technical Contact, Zone Contact: Lubrano, Philippe (PL613) Philippe.Lubrano at INRIA.FR +33 1 39 63 56 82 (FAX) +33 1 39 63 55 34 @@@@@@ "La cellule du "NIC-France", relevant de l'Institut National de la Recherche en Informatique et en Automatismes (INRIA), a assuri la mise en place du domaine ".fr" par diligation de l'IANA. Depuis le 1er janvier 1998, cette gestion a iti transfirie ` une association dinommie "AFNIC" (Association Frangaise pour le Nommage Internet en Coopiration). Ses adhirents sont essentiellement des prestataires techniques (fournisseurs d'acchs et d'hibergement) et des utilisateurs. Il existe aujourd'hui un peu plus de 16.000 sites enregistris sous le ".fr". La redevance d'enregistrement est actuellement, en fonction de l'option choisie, d'environ 400 F, ` laquelle s'ajoute depuis cette annie une redevance annuelle de 100 F." @@@@@@ Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)---C+ at ---<IPv8>---C+ at ---(Java)VPC http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://www.ddj.com/index/author/idx10133.htm -------- Logged at Tue Sep 15 16:46:48 MET DST 1998 ---------

1 0

.GP, .TM, .TV and .MQ to be Removed ?
by richard＠sexton.com 14 Sep '98

14 Sep '98

At 12:13 PM 9/14/98 +0100, Berislav Todorovic wrote: >>> I also note that Jon Postel wants to see .TV and .TM removed >>> from the root zone, but NSI/NSF prevented that. Perhaps the >>> other RSCs around the world should honor the IANA request. >>> >>> I'd be particularly interested in knowing the WWTLD's position >>> on this. Do we follow IANA directive and remove .TV, .TM or do >>> we go with NSI polict and leave them there. > >First off, let's see what RFC 1591 says about that: > > 2) Country Codes > > The IANA is not in the business of deciding what is and what is > not a country. .FX is the country code for Metropolitan France. This is not a country. Neither is Tuvala any more. Or the Cocos Islands (.CC). -- "I think it is important to understand that distribution of authority is better than dictatorship, and that the governance of TLDs and domains in general should be distributed rather than centralized." - Paul Mockapetris -------- Logged at Mon Sep 14 15:39:33 MET DST 1998 ---------

5 5