Skip to main content

RSSAC Meeting, Pittsburgh, PA

RSSAC meeting 7 - Raw Notes

Pittsburgh, PA. - Washington Rm.


Jun Muri - chair & M Randall Hayes - G & H
Kato-san - M Gerry Sn. - D
Ray Pilzk - H & G Mark K. - advisor NSI
Louie Touton - ICANN Tom Newell - A & J
Geoff Houston - IEPG Evi - advisor
Havard - I Mirium - K & Ripe
DRC - E & F Karen Rose - DoC
Chris Yarnell - E & F Sz. - L
Chris F. - K Jessica L. - G & H


  1. ICANN process regarding RSSAC - jun
  2. Primary transition - drc
  3. Contractual process - markk/louis
  4. Locations of new servers - evi/bmanning
  5. DNSSEC status - bmanning
  6. IPv6 - kato
  7. IDN impact - bmanning
  8. Schedule

This mtg is by invitation only. No announced public portion.

If requested, at the end.

1. ICANN process regarding RSSAC - Jun

  • New arch. - dedicated primary for root zone (
  • technically discussed and prepared (apprved?)
  • When is a subject for discussion (contractual binding?)
  • what are the operational requirements?
  • Contract status?
  • formal agreement is the goal
  • crada - MoU for existing capabilities, not all
  • (USgov & PSI not signed up)
  • Formal draft circulated 27july2000 PDT.
  • Under review. DoC & ICANN want both.


Prior art. 2010, 2870, DNSOPS ---- more later.

  • 15July - ICANN board mtg. passed resolutions pertanent to RSSAC.
  • Apublic transition plan based on dedicated primary
  • We are working on implementation plan. plans available
  • By EOM aug.2000
  • President is authorized to request and wrk w/ DoC on
  • Transition plan including editiorial control of the zone.
  • Expend funds to make these things happen.
  • URL for the data on ICANN site.
  • Markk - not part of the RSSAC process. "railroaded"?
  • Louie - four drafts out in last call - no received comments.
  • Is the document ok? sure.
  • Ray - would be nice to see in final form prior to announcement.
  • Bill - possible mis-reading of the resolution statements.
  • Louie - resoultion 00.58 is the board acceptance of the transition plan.
  • (bill... which version?)
  • Ray - have a better process in future.

2. Primary transition - drc

drc - operational requirements of the transition.

  • Should refine things like 2870 for the DM.
  • What are the technical requirements for roviding the service
  • Rootops need to be comfortable.
  • Louie - what is the schedule.
  • drc - 15aug is a nice target for a first draft.
  • Louie - why do the root ops consider this important vs rssac.
  • drc - root-ops bear the brunt of failure in the user community.
  • RSSAC is an advisory
  • Louie - document should be guided by performance vs operations.
  • Bill - ops is a consideration.
  • drc - anything that affects operations is a concern.
  • Louie - only NSI publishes - will work with them
  • drc/bill - operational impact is real.
  • Rootops can advise rssac & rssac can advise ICANN.
  • (do to overlap how can rssac advise icann w/o rootops)
  • Markk - can icann publish expectaions (timeframes
  • Louie - schedule is important. (missing data) - don't want a
  • 7/8 month slip. Want this by 31aug2000.

1) Recommend an enhanced arch. - 00.58 approved.
2) Proceedural plan on transition. "shifting" - onestep plan approved by rssac
3) Implementation plan (concreate dates)
4) Document IANA proceedures (what drc holds?)
5) The contract for services.

  • MarkK - "here to help" -
  • Ray - does all this need to be in stone or can we have "jello" that can be ammenable to DoC approval?
  • Louie - ammenable.
  • Karen - stuff..... seems to echo Louis thoughts. Are we comfortable and avoiding delays?
  • Tom n. - ammendments to cooperative agreement pending?
  • Karen - yes, there will need to be. Need to include ICANN
  • (lots of discussion - generally we think these points are ok and we can try and meet the targets)
  • Ray - has any thought been given to operations?
  • Louie - run by staff.

3. Contractual process - MarkK/Louis

Major rewrite sent out "late". some comments received. more are desirable. DoC wants formal agreements for stablity. W/organizations not people. People are listed as ops. drawn from 2870 w/ modifications. RSSAC has an ongoing role in tweeking the specs. Something implementable now and can evolve to meet future needs. Exibit A needs careful review. The other document to our various legal staffing.

MarkK& Bill & Ray - what does it mean to "resign"?

Jun/Louie - two week turn time. (yeah right... :)

Missed getting notes for my stuff and Kato's


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