RSSAC Meeting, London
Data:
5 Agosto, 2001
ICANN RSSAC meeting 10
Hilton Metropole Hotel, London
Attendees:
| Akira Kato M | Bill Manning B |
| Yuji Sekiya M | Mark Kosters A,J |
| Joao Damas K | Mirjam Kuhne RIPE |
| Lars-Johan Liman I | Paul Wilson APNIC |
| Ray Plzak ARIN | Jessica Little G |
| Cathy Murphy ARIN | Louis Touton ICANN |
| George Michaelson APNIC | Via telephone: |
| Johan Ihren I | Paul Vixie F |
| Mike Hughes K | Kim Claffy CAIDA |
| John Crain L | Gerry Schniering D |
| Jun Murai M | Karen Rose US DoC |
| Chris Fletcher K |
Consolidated notes from Bill Manning, Chris Fletcher, Cathy Murphy, Yuji Sekiya, and Johan Ihren
Meeting started at 17:00.
Jun chairs the meeting:
Proposed Agenda:
- Contract between OPS/ICANN (Louis)
- Transition status (mark/bill)
- general architecture
- root server migration
- shifting including whois etc
- scheduling
- maintenance procedure
- IN-ADDR.arpa zone file (ray)
- Stats (kc/kato)
- Add/Delete process (Jun)
- New TLD review committee (jun/drc)
- New TLD status timeline (louis)
- IPv6 (johan/kato)
- DNSSEC (bill)
- Housekeeping (jun)
Introduction of new attendees:
- George Michelson APNIC
- Mike Hughes LINX
ICANN-Operator MoU(louis)
- Last draft circulated – 17 March 2001
- Comments received April/May
- Goal:
- Discuss here
- Finalize by 15 August 2001
- Begin signing
Comments on 17 March Draft
- VeriSign (A/J)
- U. Md. (D)
- US Gov’t (E/G/H) (by Commerce Dep’t)
- NORDUnet (I)
- CAIDA
- Also: ISC (F) may have comments
Summary of Comments (1)
kc: Should be a clear requirement to participate in measurement programs.
Proposed edit: add D.9 as follows:
Performance measurements. Operator will take reasonable steps to participate in performance measurement programs developed by ICANN through the RSSAC process set forth in Section E of this MOU.
Summary of Comments(2)
NORDUnet: Provision about Operator providing 7/24 contact (D.6) should be clarified.
Proposal: clarify D.6 to state that 7/24 requirement is for knowledgeable (but not necessarily
expert) contact who can reach expert personnel. Requirements for timely emergency maintenance/repair to be worked out later (if needed) through RSSAC (see Section E process). Conform Appendix A item 25.
Summary of Comments (3)
NORDUnet: Risk of Operator liability for RSSAC actions should be addressed.
Proposal: add no partnership/joint venture provision.
NORDUnet: Miscellaneous language in G.4 and G.5 should be clarified.
Proposal: make clarifying changes.
Summary of Comments (4)
U Md: Requirement for turnover of IP block on termination of Root Server (sec. G.5) creates difficulties where root server in large aggregated block.
Proposal: revise G.5 so that nonaggregated blocks of /24 or smaller would be turned over; otherwise the /24 would be put into disuse for 5 years.
Summary of Comments (5)
USG: Clarify that Section F on Root Nameserver ownership remaining with operator applies to hardware/software only, and not status as Root
Nameserver.
Proposal: clarify Section F.
USG: Remove “authoritative” in recitals A.2 and A3; suggested minor wording change in C.1 to refer to IANA function.
Proposal: comply.
Summary of Comments (6)
VeriSign:
- Clarify that various means are currently used to make root-zone file available. (OK)
- Various stylistic changes to agreement. (Mostly OK)
- Update: com/net/org already off root servers. (OK)
- Enhance logging in initial requirements. (Discuss)
Revised Root-Zone Generation/Distribution
Sequence:
1 MoUs between ICANN and Operators
2 Root-zone registry system and IANA (also to be used for int/arpa)
3 Documentation:
4 General architecture (hidden master--based on Jun’s presentation)
5 Plan for shifting (based on Suzanne’s 1999 draft)
6 Schedule (extrapolate from plan for shifting
7 Edit/maintenance procedures (draft developed based on 2 above)
8 USG Approval of #3
9 Implementation
Discusssion: Separate path for root-zone Whois
Two info sources for TLD data.
URL @ ICANN
NSI stored data
Bill - pull the data & add forwarding pointers to "real" data
Jun - on #4, what is the timeline?
Louie - got a 9mon extentioN till 31 dec 2001.
for items 1-3, finish #5 by 31jun2002
Kato - who will do this? (IANA contractors)
Markk – when approached by random individuals, what to do?
Louie - See John Crain for ICANN directions.
Status on in-addr.arpa(Ray/Cathy -).
- The in-addr.arpa zone contains delegations longer than a /8
- Many registration records are not maintained in the appropriate RIR database
- Many organizations
–
have to interact with more than one RIR to modify their registration records
– have difficulty making efficient and timely in-addr.arpa updates
Project Goals
- In-addr.arpa zone will contain only /8 delegations
- Registration records will be maintained in the appropriate RIR database
- Organizations will be able to:
– interact with a single RIR
– make more efficient and timely in-addr.arpa updates
Project Tasks
Establish process for maintaining in-addr.arpa sub-domains
Update the in-addr.arpa zone file to contain only /8 delegations
RIRs maintain /8 zone files
Transfer IPv4 registrations from ARIN to the appropriate RIR DB
Maintaining in-addr.arpa
• Each RIR will maintain a suite of in-addr.arpa servers
– APNIC & RIPE NCC have already deployed this solution
– ARIN will establish a suite of in-addr.arpa
sub-domain servers
• Non-shared /8s maintained by appropriate RIR
• Shared /8s maintained by majority record holder
– RIR having majority of network space for a /8 will have
primary responsibility
– Other RIRs must be able to provide updates to zones maintained by other registry
• WHO SHOULD MAINTAIN THE .ARPA ZONE?
In-addr.arpa /8 Categories
• Blackhole /8 (RFC 1918)
• IANA Reserve /8s
• RIR allocations
• Legacy /8s
– Class A
– Class B
– Class C
Delegation & Transfer Actions
• Blackhole /8 (RFC 1918) - no action required
• IANA Reserve /8s – no action required
• RIR allocations
– APNIC & RIPE NCC - aggregated
– ARIN – unaggregated
• Legacy /8s
– Class A - no action required
– Class B – aggregated & unaggregated
– Class C – unaggregated
Progress to Date
• Notification to IP community (Q2/2001)
– Implement data consistency rules based on DNS rules
– Data cleanup
• Preliminary Steps (Ongoing since Q2/2000)
– Purchase equipment
– Contract with vendors
– Host ARIN.NET domain in a more robust environment
• Test Phase (June 2001)
– Generated zone, but did not delegate out of in-addr.arpa
– Configured nameservers and loaded zone
– Ran test queries
• Implementation phase (Ongoing since July 2001)
– Delegate /8 subdomains out from in-addr.arpa domain
– Ran test queries
– No negative impact observed or reported.
Next Steps
• /8 delegation from in-addr.arpa
– 31 Aug 2001 – ARIN /8s delegated
– 21 Sep 2001 – Legacy /8s delegated
• Finalize update procedure
• Customer notification
• Transfer /16s & /24s
Status on measurement/skitter(KC)
D has hardware now.
G, H, do not now have hardware, blocked on Caida
C, B, ??
STIGs issues for G & H. Jessica does not have any more detail yet. Scripts & router
upgrade are required.
I root is configure but not reachable.
Nevill has some data that was presented at IEPG.
kc: Does RSSAC have any future plans to use Skitter? Skitter has no funding as of July2001. Well, has a single two month extension through Sep. 2001. What is RSSAC interested in?
Jun - we need a formal request to CAIDA to do work. So we need to know what we want before we
can ask CAIDA to do any a additional work.
RSSAC/ICANN should raise the funds. Need a project plan.
Actions:
KC/Louis/Jun - Monies/Contracts
Bill/Evi/Kato- Build requirements.
Review KC options
Jun - Add/Delete (see the previous point for basic data on which to make judgment)
- New TLD committee // avoid new semantics in the first pass. For future passes, need consideration from the first point. Add an RSSAC member for designing the review process - DRC is the selected candidate
Louis - the TLD timeline
biz & info done
name is coming
more coming in sept/oct 2001
ZR is gone
GB is leaving
Markk - why to ICANN first & then transfer to operator?
Louie: Based on contracts
IPv6 (Johan)
In the last mtg, we agreed to add v6 glue but which type? Ground to a halt waiting on resolution. Portioning of the Internet space a concern. Could we build a "bridge"? Very highly charged. No forward momentum.
Limited testing.
Papers written and shelved due to considerations on officially sanctioning alternate spaces.
Bill - we are in suspense, pending IETF outcome. What is the
capability of RIRs et.al. in supporting v6 only requests e.g. host records?
Jun - we need to report on accumulated experience & need more.
Johan - then we need a testing space.
Markk - can we have an ICANN authoritative "alternate"
Paul V - Its not robust enough. Coherency is mandated. If we can do this, it will be too easy - allowing a "thousand weeds" to bloom. We need DNSSec. Although this still does the same thing, allowing many parties to compete. Blows coherency out the water. No tagging of data identifying origin. In a word, NO.
Liman - what is the way forward?
Paul - it is supposed to be able to evolve, let it out and see what happens? Chances are remote
the system will fail. flag-days are fine. One or more of the roots fails on a regular basis and the system covers the error.
Johan - if the IETF selects A6, will there be a problem for v8 servers?
Paul - it is possible to use A6 with bind 8. will need code changes. 9.2rc1 may be fast enough.
Check into it next week or so.
I can make a patch to 8.2.4 & will release 8.2.5 if needed.
Johan - Don’t see 9.2 as a solution just to test A6.
George M. - Don’t count on IETF to decide this session.
Jun - is there a way forward?
Liman - we don't push, we facilitate.
Bill - talk to the IESG/IAB/Chairs specifically about our concerns as operators.
DNSSEC (bill)
The testbed is being used for key rollover & parent/child key mgmt. FreeSwan is interested
in using the testbed.
House keeping (Jun)
Next meeting will be on December 9th in Salt Lake City
