RSSAC Meeting, Minneapolis
RSSAC, 17 March 1999, Minneapolis, USA
|Daniel Karrenberg||RIPE NCC||K|
|Mirjam Kuehne||RIPE NCC|
|Mark Bohannon||US DoC|
|Ray Plzak||DDN NIC||G|
|Mark Kosters||NSI||A, J|
|Piet Barber||DDN NIC||G|
|Gerry Sneeringer||University of Maryland||D|
|Bill Manning||ISI||B , L|
|*Attended part of the meeting|
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.
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 membershipFormal 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
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.
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.
should be sent to email@example.com.