Skip to main content

RSSAC Meeting, London

ICANN RSSAC meeting 10

Hilton Metropole Hotel, London


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:

  1. Contract between OPS/ICANN (Louis)
  2. Transition status (mark/bill)
  3. general architecture
  4. root server migration
  5. shifting including whois etc
  6. scheduling
  7. maintenance procedure
  8. zone file (ray)
  9. Stats (kc/kato)
  10. Add/Delete process (Jun)
  11. New TLD review committee (jun/drc)
  12. New TLD status timeline (louis)
  13. IPv6 (johan/kato)
  14. DNSSEC (bill)
  15. 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)
  • 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


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)


  1. Clarify that various means are currently used to make root-zone file available. (OK)
  2. Various stylistic changes to agreement. (Mostly OK)
  3. Update: com/net/org already off root servers. (OK)
  4. Enhance logging in initial requirements. (Discuss)

Revised Root-Zone Generation/Distribution


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.


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 Ray/Cathy -).

  • The 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 updates

Project Goals

  • 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 updates

Project Tasks

Establish process for maintaining sub-domains

Update the zone file to contain only /8 delegations

RIRs maintain /8 zone files

Transfer IPv4 registrations from ARIN to the appropriate RIR DB


• Each RIR will maintain a suite of servers

– APNIC & RIPE NCC have already deployed this solution

– ARIN will establish a suite of

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


• 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

– Configured nameservers and loaded zone

– Ran test queries

• Implementation phase (Ongoing since July 2001)

– Delegate /8 subdomains out from domain

– Ran test queries

– No negative impact observed or reported.

Next Steps

• /8 delegation from

– 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.


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 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

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"""" is not an IDN."