Skip to main content
Resources

RSSAC Meeting, Minneapolis

RSSAC, 17 March 1999, Minneapolis, USA

Present:

Daniel Karrenberg RIPE NCC K
Mirjam Kuehne RIPE NCC  
Paul Wilson APNIC  
Mark Bohannon US DoC  
Akira Kato WIDE M
Ray Plzak DDN NIC G
Lars-Johan Liman KTH I
Mark Kosters NSI A, J
Suzanne Woolf IANA  
David Conrad ISC F
Piet Barber DDN NIC G
Doug Engebretson DISA G
Maurizio Binello LINX K
James Fielding ARL H
Shane Kerr ARIN  
Kim Hubbard ARIN  
Gerry Sneeringer University of Maryland D
Josh Elliott IANA  
Mike Roberts ICANN  
Esther Dyson* ICANN  
Paul Vixie ISC F
Randy Bush* IESG  
Evi Nemeth CAIDA  
Bill Manning ISI B , L
*Attended part of the meeting    

Agenda:

1. Review previous minutes
2. Committee scope & membership
3. Work items-- discuss and assign


The first RSSAC meeting was for organizing what the tasks and issues are and who is invited by ICANN to participate in resolving them. This one will be to start getting down to business on breaking up the tasks.

Membership:

There is very limited guidance in the ICANN bylaws on the membership of the committee. The Board must be advised who the members are, but this is essentially at the chair's discretion. List for meetings so far: the current root server operators, the IANA staff, liaisons from the leadership of the IETF and ICANN Supporting Organizations, and recognized experts in various relevant technical areas.

Consensus points from the discussion:

Committee membership is the root server operators and the ICANN/IANA staff, with additional input and support from invited liaisons to other groups and experts in relevant technical areas like routing, topology, and performance measurement.

a. Form of membership

Formal membership is largely irrelevant because the committee is expected to function in the IETF style of consensus rather than voting. Work Items discussed:

b. Operational guidelines and requirements issues

RFC 2010 is in need of some updating. There is also a new root server operational requirements draft RFC. Concerns with 2010 include security and performance specifications. There is however some need recognized to avoid over-specifying so as to encourage diversity – we are *not* interested in specifying hardware, software, etc.

There is also discussion of how the work on specifying operational procedures does or doesn't overlap the DNSOps effort in IETF. The usual model and the one preferred here is that the IETF sets general principles and people will adapt and extend whatever IETF the does as necessary to solve their particular set of problems.

ICANN needs a statement from the operators that there are documented operational guidelines that the root server operators are committed to following. The consensus answer is that the Root Servers will treat RFC 2010 as the baseline operational standard for current guidance and will adjust to changes as specified by RSSAC. People expect that the DNSOps working group if any will significantly overlap RSSAC participation; we will work with the IETF on developments and add our own features.

A tentative deadline for an initial draft of this compliance statement is set for May, to have a published version available in June.

Leads: Ray Plzak, Daniel Karrenberg


2. Discussion on RFC 2010 and RFC 1591: operational authority

Most operators agree to follow what IANA directs. Some will only follow Amendment 11/DoC, but all agree that a joint direction or statement from DoC and ICANN/IANA is sufficient authority for them at this time.

DoC position per Mark Bohannon on operational authority over the root zone: The transition described in Amendment 11 is underway. DoC & IANA are working closely together, and it's unlikely that there will be disagreement because everyone knows what is operationally unacceptable.

Any discrepancies are an operational issue and will be dealt with as such. Operators will check with multiple sources to verify new instructions. (Note that with respect to certain changes the current state is frozen.)

At present historically off-the-shelf, cheap, generic machines work adequately.
New DNS features such as DNSSEC or records to supportIPv6 may change that.

There is some discussion of the potential to separate gTLDs from the old roots.
All agree this is a good idea. There are several possibilities for how to do this. It has to be handled with sensitivity because any significant change e.g. renumbering servers is going to need serious thought and buy-in by many people.

A draft document should codify existing practice. It should include the infrastructure zones carried on the root server machines (.in-addr.arpa, root-servers.net) at least for now.

Leads: Doug Engebretsen, Bill Manning, Mark Kosters


3. Discussion on deployment issue

The location, number, distribution and deployment of new servers (or redeployment of existing servers) are a separate issue from how to operate once deployed.

Number is bounded but we haven't yet made most effective use of all available slots, note that both J and L were initially deployed with the intention of finding a suitable place and redeploying them. Location and distribution are open items and will probably require participation by outside experts on topology and traffic. CAIDA has some thought and resources to start studying this.

Leads: Bill Manning, Evi Nemeth, Jun Murai


4. Discussion on drafting possible contract terms

There needs to be more formal understanding of the obligations towards and from the operators of root servers. Network Solutions has been attempting this with regard to the operation for the gTLDs. DoC and ICANN offer the help of their legal staffs on formulating these draft guidelines.

The draft will need to consider possible expansion of the number of gTLDs. It also needs to cover the case that off the shelf hardware may not always do the job. Paul Vixie offered to draft some general language.

It is also noted that the implications of the prospective contractual relationship between root server operators and ICANN include support and remuneration for expenses incurred and labor spent (Mike Roberts).

Leads: Jun Murai, David Conrad, Mark Kosters, Daniel Karrenberg


5. Y2K issues.

USG did formal evaluation on BIND 8.1.2, which passed. (Report not available yet.) Various informal tests have been performed (F & L at least) in which system clocks have tested the 0001 1/1/00 rollover with no problems found, but the USG is very eager to have a formal statement.
RIPE-NCC staff, David Conrad, Akira Kato, Mark Kosters and Bill Manning can make efforts to document/define a common statement.

The basic principle to emphasize is that "Diversity builds robustness" machines and supporting infrastructure are diverse enough that systemic failure seems unlikely. The statement will need to clearly indicate the span of control of the root servers, since there are many components and limited ability to certify others' pieces.

Mark Bohannon: we do have to specify Y2K compliance (which we note is an OS issue!) DoC is eager also to see the process work as an example they can use to demonstrate context for later discussion and decisions. The focus here needs to be on longer term stability and robustness for the system overall.


Next meeting set for Oslo IETF, with a working session that may or may not be a formal meeting expected sometime between Minneapolis and Oslo. "To Be Determined" probably May or early June.


Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.
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""icann.org"" is not an IDN."