RSSAC Meeting, Minneapolis
Data:
17 Março, 1999
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 availableet.) 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
