Skip to main content

RSSAC Meeting, Minneapolis


RSSAC, 18 March 2001, Minneapolis, USA


Jun Murai WIDE/RSSAC chair m
Havard Eidnes NORDUNET i
Suzanne Woolf ICANN/MFN l
Mirjam Kuehne RIPE NCC k
Joao Damas RIPE NCC k
John Crain ICANN l
Mark Kosters Verisign a, j
Brad Verd Verisign a, j
Akira Kato WIDE/ISI m
Bill Manning USC/ISI b
Ashley Kitto Nominum e, f
Chris Yarnell Nominum e, f
Gerry Sneeringer U. Maryland d
Johan Ihren Autonomica AB i
Louis Touton ICANN -
Nevil Brownlee CAIDA -
kc claffy CAIDA -
Paul Wilson APNIC -
Ray Plzak ARIN/IETF DNSOPS co-chair -
Cathy Murphy ARIN -


1. Contracts status between operators and ICANN (louis)
2. Transition status (mark)
     DM rolltout status
     gTLD migration
3. New TLD addition timeline (louis)
4. Add and delete process (jun)
5. Stats and measurements (kc)
6. IPv6 (johan, kato)
7. DNSSEC (bill)
8. International names impact (mark)
9. Reporting to public (jun)
10. Scheduling, housekeeping, web site (jun)

1. contracts (louis)

Louis distributed a new version of the contract (now an MoU) during the last couple of days to the root ops, trying to include comments he received on the previous version.

ACTION on everyone to send comments on MoU to Louis before 16 April 2001.

ICANN will seek to extend the agreement with the USG for 6 months. This will include getting the contracts (MoUs) signed and getting the distribution master set up.

(Next RSSAC is going to be in August 2001 in London. This is 4 - 5 months from now one. In the light of this, ICANN will seek extension of the agreement for 6 more months.)

2. Transition status

2.1. Distribution Master roll out (Louis)

Behind schedule. John currently busy setting up a new location for the root servers and other high volume servers. Also busy improving logging and security mechanisms at ICANN.

Four documents need to be written by ICANN:

  • General architecture
  • procedural plan for shifting to new distribution system
  • schedule>
  • a root zone file maintenance procedures

2.2. gTLDs are taken off the root (Brad)

Bill: thinks it would be useful to have a mechanism for continuous updates in place.

MarkK: gov and edu starts to create operational problems. Louis will follow up on that with the gov/edu operators.

3. New TLD addition timeline (Louis)

ICANN currently discussing contracts with the new gTLDs. Intermediate set up for .info, .biz, .name, and .pro. The other ones will follow over the next few months.

Two likely deletions

  • zr (has been transitioned into cd)
  • Discussion with Willi Black to get gb out (only one entry left right now)

Jun explains that the first round of new gTLDs have been selected under the basis that they would not attempt to overload the DNS or other TLDs. There will be other rounds of selections, do the root operators have an opinion about that.

MarkK: purely from a technical point of view from the root ops, does not see a problem, overloading semantics is not our problem. One has to watch out for things like the idea to use CNAMES to go from one to the other zone. You would always to go through the root to get the data.

Unless there is hack that would affect the root servers, the root server operators do not have an opinion about new gTLDs.

Jun: thinks the RSSAC should still review the proposals.

Louis: Suggested policy or other related proposals are usually send to the SOs for double check and feed back. He suggests to send proposals concerning new TLDs also to RSSAC.

Jun: yes, please do so.

4. Add and delete process (Louis)

Bill and MarkK have earlier worked on a draft on how to re-distribute root servers.

Jun: would like to get something on this matter decided soon.

Louis: ICANN gets volunteers from time to time to run a root server. Response so far was that this will be decided based on technical criteria. Would be nice if they had some document they can point to.

MarkK: RFC2870

Louis: not enough

ACTION on Bill and MarkK to re-visit and re-circulate the document they wrote earlier (minimum requirements for running a root server) before the August IETF.

This could then also serve as guidelines for whoever is going to decide about new locations or operators.

Jun: we will also need an administrator for deciding the location (RSSAC or a sub-group).

Louis: can we add two more root servers without breaking the UDP packet restriction?

Bill, MarkK: not really yet, still needs to be tested better.

People agree that it is not a good idea to add new root servers. There are a few existing ones that might need to be re-distributed though.

5. Stats and measurements (kc)

Only m has added a skitter box since the last meeting.

KC welcomes everyone to work with the data and to cooperate with her.

Kato: if one root server would be moved to a very far from the others, would that effect the other root servers?

Bill: yes, it does. All servers need to be distributed as far as possible, but stay as far as possible within the horizon of the Internet.

KC would like to have some more commitment, at the moment the process is too vague

Jun: would like to coordinate a structure for measurement works.

6. IPv6

Root ops needs to describe what is needed to be tested

Johan volunteers to work with Alain to present something in DNSOP.

Bill: only talk about IPv6 proposals, something like: we are developing an IPv6 implementation plan and we are going to circulate that before we start to implement them.

7. DNSSEC (bill)

There are still many open issues with DNSSEC

Things like key management, key creating, validation periods need to be tested. All these seem to be operational issued rather than technological. Will probably not be able to deployed this year.

Bill, Mark and Suzanne volunteered to draft a document how root operators can use TSIG to protect root server transfers.

8. IDN impact on root servers (MarkK)

MarkK believes there should not be any impact

Johann believes IDN should be avoided for the roots

People agree that the root server operators need to be informed in time, ideally before the final decision is made, so that the root servers can have input, can issue warnings, can test etc. People believe that test/experience for at least six month period prior for the entire root server system to introduce a new technology anyway.

How much influence do we have on the IETF? Concerns that a lot of the development is actually done outside the IETF. What can ICANN do to avoid confusion?

9. Public reporting (jun)

Our web needs to be improved.

ACTION on Jun to send previous minutes to ICANN (John) to update the web site.

10. scheduling, housekeeping (jun)

next RSSAC meeting: 5 August 2001, London, UK

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."