September 1998 - tld-wg - mailman.ripe.net

TLDs accepted
by JimFleming＠unety.net 08 Sep '98

08 Sep '98

The RSCs might want to pass this on to all of the various TLD managers. @@@@ http://www.apng.org/apcctld/minutes/sg-mtg.html "5. Membership Resolution: We accept any TLD which wants to participate as a member." @@@@@@@@@@@@@@@@@@ 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 8 19:04:07 MET DST 1998 ---------

1 0

[ifwp] Re: Start of a new Proposal. Was: It's been ...
by JimFleming＠unety.net 06 Sep '98

06 Sep '98

-----Original Message----- From: Christopher Ambler <cambler at iodesign.com> To: IFWP Discussion List <list at ifwp.org> Date: Sunday, September 06, 1998 1:58 PM Subject: [ifwp] Re: Start of a new Proposal. Was: It's been ... >>> I believe that Paul Garrin's event in New York city in mid-September is >still >>> on > >I find it impossible to support anything organized by a company that not >only is infringing on .web, but claims to be the clearing house for all TLDs >for that matter. > >Until name.space comes back down to Earth, I cannot support anything >that they do. > >Christopher > Chris, Will anyone from .WEB be attending this workshop ? @@@ http://www.ripe.net/centr/training/workshop-2.html "CENTR Workshop for Managers of TLDs" @@@@@@@@@@@@@@@ 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 7 13:45:00 MET DST 1998 ---------

1 0

RIPE CENTR Meeting - September 22, 1998
by JimFleming＠unety.net 06 Sep '98

06 Sep '98

While some people are focusing on cancelling meetings, we should note that the RIPE CENTR meeting will be held September 22, 1998. http://www.ripe.net/centr/meetings/centr-4/index.html RIPE is one of the more open (and fair) organizations on the Internet. Even though they are mostly focused on IPv4 allocations, they have discovered the merits of being involved with the evolution of TLDs. From an IPv8 point of view, this is a good thing. People tried to divide the world by claiming that IP addresses and domain names have nothing to do with each other. That may be true from a technical sense but is not the case from a business and industry point of view. It is costly to have IP-only registries and those costs are passed on to ISPs and the consumers. In my opinion, it is better to have each of the TLD registries handle a small part of the IP allocation load. This helps to keep the cost down, to spread the resources around in a more fair and equitable manner and helps facilitate the transition from IPv4 to IPv6. This is essentially what IPv8 helps do. Again, I suggest the real issues are with IP address allocations. The TLD issues fall out once the IP resources are allocated fairly. IP addresses are like land and domain names are like billboards. The farmers that control the land along the information superhighway ultimately control the billboards on the highway. 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 8 19:03:18 MET DST 1998 ---------

1 0

Proposed Agenda TLD-WG RIPE 31
by Niall.oReilly＠ucd.ie 04 Sep '98

04 Sep '98

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 Mon Sep 7 13:44:04 MET DST 1998 ---------

1 0

[ifwp] Oh, bother.
by JimFleming＠unety.net 03 Sep '98

03 Sep '98

-----Original Message----- From: Carl Malamud <carl at media.org> To: David R. Conrad <David_Conrad at isc.org> Cc: JimFleming at unety.net <JimFleming at unety.net>; list at ifwp.org <list at ifwp.org>; ietf at ietf.org <ietf at ietf.org> Date: Thursday, September 03, 1998 2:52 PM Subject: Re: [ifwp] Oh, bother. > >> Another "yes" vote for Anti-Flem filters on the IETF mailing list. > >> Regards, >> -drc > >I agree. Can't our IESG at least convene a working group >to figure out how to properly filter this mailing list? >I know this is a radical idea, but perhaps a sequence of >draft a charter, appoint a chair, circulate a draft, >check out any working code, meet at the next IETF, >and send it up to the IESG as a proposed standard? > >Our leaders don't seem to be able to moderate the direction >of the list, so perhaps a mechanical means such as >Noel suggested is in order. Otherwise, a once-valuable >resource will continue to degenerate beyond the current >low level of pretty-much-useless. > >Carl > > Carl, Are you still in charge of the ISC ? Has ISC finished converting from a non-profit company to for-profit company ? Are you and David Conrad trying to avoid answering about what you plan to do at the end of this month ? Again... What does ISC plan to do at the end of this month as part of the legacy Root Name Server Cluster ? Have you developed your policies on that yet ? Do you plan to just pull whatever root zone that Network Solutions provides ? 1. A - Network Solutions, Inc. (A) 2. B - University of Southern California (ISI2) 3. C - Performance Systems International Inc. (C-NYSER) 4. D - University of Maryland (UMD-TERP) 5. E - NASA Ames Research Center (NS-NASA) 6. F - Internet Software Consortium (ISC) 7. G - DOD Network Information Center (DIIS-NS) 8. H - Army Research Laboratory (B) 9. I - [No name] (NORDU) (Sweden) 10. J - Network Solutions, Inc. (J) 11. K - European Regional Internet Registry/RIPE NCC (K) 12. L - University of Southern California (L) 13. M - WIDE Project (M) (JAPAN) Jim Fleming Unir Corporation - http://www.unir.com -------- Logged at Fri Sep 4 11:48:11 MET DST 1998 ---------

1 0

Fw: (ngtrans) AAAA Record Transition Strategy
by JimFleming＠unety.net 03 Sep '98

03 Sep '98

In my opinion, people following the IFWP and White Paper discussions should make sure that they also closely follow the IPv6 evolution. The following note from Jim Bound of DEC is a very important message. Since some of you people are not technical, I would like to point out that IPv8 is not impacted by the situation below. IPv8 uses the IPv4 DNS, as-is, without requiring revolutionary change. IPv8 is able to use IPv6 for basic transport features. Those have nothing to do with the serious IPv6 DNS issues discussed below. We are tracking the IPv6 evolution (or revolution). I will try to continue to keep people informed when major points are raised by people working on IPv6. Besides the points below, Jim Bound made some other excellent points at the IETF meeting last week in Chicago. It was sort of a shame that they have been lost in some of the noise about the new IANA Inc. bylaws. One of Jim's points was about the IETF now having the talent needed to work effectively in certain areas. As more people from the IFWP process make their way to the IETF, they might be able to supply some of the needed talent. The expanding Internet will require a diverse collection of people to make it go. It may be somewhat of a challenge to convince groups like the IETF that they need to be more diverse. Hopefully, gotchas like those described below will help make them realize that they do not have all of the answers. No one has all of the answers. We have to all work together to put the pieces of the puzzle together one piece at a time. Jim Fleming Unir Corporation - http://www.unir.com -----Original Message----- From: bound at zk3.dec.com <bound at zk3.dec.com> To: ngtrans at sunroof.Eng.Sun.COM <ngtrans at sunroof.Eng.Sun.COM> Date: Wednesday, September 02, 1998 3:31 PM Subject: (ngtrans) AAAA Record Transition Strategy >Folks, > >I spoke with the chairs of ngtrans, ipng, and Thomas Narten IESG AD. > >It appears the isssue of moving from the existing AAAA record to the new >AAAA record (e.g. dname, bit-boundaries, edns) will not get done until after >IPv6 has been deployed and in many cases shipped by vendors. > >Hence, we need a plan. After talking to Paul Vixie and a few others >here is a suggestion. > >Assumptions: > a) New AAAA record support should be in the ISC BIND releases > around the summer of 1999 and edns. > b) The integrating drafts for this New AAAA record should be PS > in the IETF and have DNSIND consensus too by summer of 1999. > >A plan: > > a) Deploy IPv6 in the market using the existing AAAA records, > and keep them on the 6bone nodes. > b) Vendors make sure your stub resolvers can accomodate the > i) query for dame records and the reverse. > ii) keep it transparent to the dns apis upon return of > hostent like structure. > c) We should not add an AAAA-Type New or OLD flag to the IPv6 > API (basic or advanced) as we don't want to expose this > to the ISV community building IPv6 apps. > d) Use the eventual edns dns metaquery to be done in BIND too > with the new AAAA records to request AAAA records for > the new type - Note this implies we have a new type rec > for the new AAAA record. > e) Tell users to use the existing AAAA records and when the > new AAAA record is ready then they can also distribute their > name space as approiate to with the updates to AAAA and to > DNS in general (e.g. edns, TSIG, DNSSEC). > f) Vendors this will affect how dynamic updates to dns works > at the server and I am hoping not at the client (this is > a question for Matt). But we need to think about this. > Esp if you have this done which most of us do. > >Other ideas or enhancments or replacements, we need to discuss... > >/jim > > > > -------- Logged at Thu Sep 3 17:02:51 MET DST 1998 ---------

2 1

Internet Administration in the RIPE Area
by veni＠isoc.bg 03 Sep '98

03 Sep '98

DEAR Daniel, [quote] In the RIPE area the administration of ccTLDs is at widely varying stages of development. However I'd like to emphasize that the structures are quite well developed in those countries with a relatively long Internet history. Typically ccTLDs in those countries are administered by a not-for-profit foundation or association created for that purpose. These bodies are established such that all the stakeholders can be represented. These bodies are typically watched very closely by a number of interest groups, the legislature and the government. [end quote] WHAT do you consider long Internet history? daniel kalchev (daniel at digsys.bg) claims he provides internet since 1989. And he's the ccTLD since 1991. Is this long? If it's long, why the .bg is still a private company, yet an ISP, which is an obvious example of unfair competition? [quote] It is important to point out that not all ccTLDs in the RIPE area have yet reached the sophistication the oldest ones have. Some of the more recently established ccTLDs are still administered by single individuals or academic institutions. However they are all developing and the trend towards open non-for-profit self-regulating structures is quite strong. [end quote] DO YOU mean Bulgaria is inlcuded in this list, too? Because the .bg tlda is definitely not doing any of the things you've mentioned above. regards, Veni Markovski, Chairmain, the Internet Society - Bulgaria, http://www.isoc.bg, http://www.bulgaria.com/isoc/, http://www.bol.bg/isoc/ phone: (+359-2) 9809666, phone/fax (+359-2) 9806431 mailing address: p.o.box 71, Sofia 1164, Bulgaria -------- Logged at Thu Sep 3 15:56:54 MET DST 1998 ---------

1 0

[ifwp] Re: Membership organization
by JimFleming＠unety.net 03 Sep '98

03 Sep '98

-----Original Message----- From: mueller <mueller at syr.edu> To: IFWP Discussion List <list at ifwp.org> Date: Thursday, September 03, 1998 1:11 AM Subject: [ifwp] Re: Membership organization >ISOC's leadership has made some terrible and costly mistakes in the past two >years. My idea was by no means intended to be a vote of support for them or >even for ISOC as it now exists. > >The point was that it is the only organization with an international >membership apparatus in place. If we're serious about a membership >organization that is *individually* based, the question of how membership is >established, verified, votes tallied, etc. becomes extremely important. I >think some of us are not thinking about the practical implications of >implementing that. > I disagree. Some of "us" have been thinking about this for a long time. In my particular case, the IPv8 Plan is the structure that I am assuming will handle most of the needs in this area. The IPv8 Plan is based on individuals that join small trusteeships which I call 2+2+4 because 2 of the people rise to the leadership roles, they each have a back-up and then there are 4 people that help to fill out the group for continuity and eventual rise to leadership roles. In the IPv8 Plan, 2,048 TLDs each have a 2+2+4 trusteeship. That is 16,000+ people. Those 16,000 people are organized into 8 regions with 256 TLDs in each region. The regions are a mix of geocentric TLDs and generic TLDs. People can be a trustee of a TLD and not have anything to do with the registry or registrar operations. The trustees determine what companies get to do those jobs. The trustees represent the people. They are like a mini-IANA for each of the TLDs. With 8 regions, there can be some simple process for having 2 delegates from each region to be selected to work periodically in a 16 person global round table to deal with any global issues that should be rare. The idea is to encourage problems to be solved inside each region and local to what is affectionately called a "neighbor net". That is simply the sum of one trusteeship and the two trusteeships on either side of the TLD. Various schemes can be worked out. Some might prefer that the 2+2 part of the center trusteeship be joined by the 2 leaders from the neighboring trusteeships when problems can not be solved inside of a TLD trusteeship. As an example, recently people were debating some issues with the .PL TLD for Poland. In the IPv8 Plan the trusteeship for the .PL TLD would try to resolve the problem. If they can not, then they could ask for help from the .SALT and .ROME TLD trustees. If necessary, maybe the .GR and .CANVAS trustees would be asked to help. http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt 3:174 GR (GREECE) 3:175 SALT 3:176 PL (POLAND) <---------- Dispute 3:177 ROME 3:178 CANVAS All the IPv8 Plan takes is an agreement that TLDs are a public resource that should have some small number of people acting as trustees. Then those trustees can be grouped in regions and encouraged to organize themselves. People could become trustees of as many TLDs that will allow them to join. By building upon individual people and using the TLDs as focal points for trusteeships then we can have a structure that allows many people to participate, is immune from capture and encourages people to think global but act local. Jim Fleming Unir Corporation - http://www.unir.com -------- Logged at Thu Sep 3 11:03:33 MET DST 1998 ---------

1 0

replace .tw with .rc
by wchao＠post.uni-bielefeld.de 02 Sep '98

02 Sep '98

> >> could any alternate root server help us to do this? > >> An entry in ISO 3166 like > >> China, Republic of RC ROC 158 > >> would be right and better. > Using an alternate root server, you can do whatever you want, except: > (1) You won't change the root zone maintained by the IANA. > (2) You cannot change the ISO 3166 table (at all!). > To solve (1), you'll have to contact IANA, but they strictly follow > the ISO 3166 table. So, you must solve (2) first and that requires an > official contact with the ISO 3166 authority from your government. As > far as I heard, the authority which has to be contacted is located at > DIN offices in Berlin. Because there is no member of ISO in the Republic of China(Taiwan), (I don't know why, althought we do have such an Institute.) so I write a letter to DIN (postmaster at din.de) and wait for an answer.... Wei-Lun Chao -------- Logged at Thu Sep 3 10:50:13 MET DST 1998 ---------

1 0

Internet Administration in the RIPE Area
by Daniel＠karrenberg.net 02 Sep '98

02 Sep '98

Hello, I have written a few personal notes on Internet administration in the RIPE area. Those following the current debate around the issue of establishing a new IANA may find them interesting to read. I'll be happy to receive comments by e-mail. A HTML version can be found at http://www.ripe.net/home/daniel/euro-notes.html A text only version at http://www.ripe.net/home/daniel/euro-notes.txt Daniel -------- Logged at Thu Sep 3 10:54:15 MET DST 1998 ---------

1 0