RSSAC Meeting, Minneapolis
Notes
RSSAC, 18 March 2001, Minneapolis, USA
Present:
| 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 |
- |
| Cathy Murphy | ARIN | - |
Agenda:
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