Skip to main content

RSSAC Meeting, Minneapolis, MN

Minneapolis, Minnesota

RSSAC - 21st Meeting


Present: John Crain Present via telephone:
Mark Kosters Fredrico Neves Daniel Karrenberg
Brian Coppela Abram Thielke Jessica Little
Nevil Brownlee Johan Ihren Mark Schleifer
Mike Green Kenjura Cho Kim Claffy
Jim Cassel Jun Marui Regrets:
Rex Hayes Akira Kato Gerry Sneeringer
Andrei Robachevsky Yuji Sekia Dave Swager
Steve Crocker Lars Liman  
Geor Michaelson Suzanne Woolf  
Cathy Murphy Bill Manning  
Steve Conte Joao Damas  


Root Operational Changes - G. Anycast etc.
ICANN liaison report
ICANN nomcom
SSAC report
V6 status/issues
PR - web/presetnations/disclosure languages
publicity/press officer
31jul2005 Paris

Agenda Correction: SSAC removed.

Root Changes:
G will move in topology & change administrative management.
It is moving from the WDC area to Ohio and from SAIC to the US
DISA as the operational team. Welcome to Mike and Jim from DISA.
A t the time of the topology move, the nodes will be upgraded. timeframe for the physical move is estimated to be June-October. The Ohio node will be physically much more secure than the old node. Will keep the same AS if possible. May see AS path changethat removes AS 568 and injects AS 721.
Adding more processing power and bandwidth so "G" should be seen as a better participant than in the past. Otherwise, externally, there should be no visable changes.

D has delayed its renumbering plan.
H has no current plans for restructuring.

Anycast Updates:
the public page ... it needs to be updated to
reflect WIDE/M links. Are there other updates required? Since
there is no common root-server operator organization, some
server operators are not keeping info on this page current. Once
such an organization exists, it will be prudent to have a common
site for publishing root server information.

ICANN liaison - Suzanne had accepted the assignment. This is her report.
A few items worthy of mention:

  1. WSIS process & WGIG - a political effort - not a real root server issue ... we've done some good communications - need to do more.
  2. New TLDs - again not root ops.
  3. .NET rebid is underway. Schedule calls for EOM-March to announce award - mid June for transition. Still confusion over what we do. Process of root zone creation vs. server operations.
    Steve Crocker: Its been a good thing to have an RSSAC liasion and Suzanne Woolf is a good fit.
    Suzanne Woolf: would like help in reviewing materials, etc.
    Daniel Karrenberg: willing to help in my neighborhood. The ISOC briefings may be useful.

NOMCOM Suzanne Woolf:
we need to send a non-voting member. She did it last year and need to send someone else. Lars Liman has been asked to volunteer but needs more info.
Jun Murai: it seems a good idea to have someone other than Suzanne Woolf take this on. Steve Crocker: almost more of a recruiting drive than a vetting of a large candidate pool, Jun Murai might be the best choice.
Bill Manning: are we asking for a larger candidate pool?
Jun Murai: Yes, and will like to have an answer this week.

V6 Bill Manning:
S ummary of history - additional testing done; need to publish the results. need to identify the communities impacted.

Issue: if an IMR generates a priming query with at least one failure condition, it could have severe impact on that caching server.

Jessica Little and Bill Manning did some testing. VeriSign did some work and reported last the NANOG. Bill Manning will finish his testing, write up the results and merge/compare results with the VeriSign data.
This will help identify the impacted IMR servers at that given
point in time.

Has potential for a pervasive and hard to detect, externally, negative impact on individual IMRs if turn on v6 glue for root servers.

Steve Crocker: Didn't SSAC discuss this?
Fredrico Neaves: No, only discussed packet size issues and it was only with regard to the impact on TLDs.
Johan Ihren: Discussed doing an inventory of old, broken software out there that will get broken in new ways if add v6 to the root. What to do about that broken software is a different matter. Know there is a problem, don't know the scope or what to do about it?

Bill Manning: Before RSSAC can make a recommendation, should do research to identify what the problems will be. Will make ICANN more comfortable about when/how to proceed. Will try to compile info in time to review before the Luxemborg mtg. but only a portion of testing has been done. We need to compare data from each server instance against the failure modes

Steve Crocker: This is of critical importance.

DNSSEC Lars Liman:
deployment status - several facets. asking about
software status - there is much more - distribution
this is s/w only... update matches the last update as to timeline

A,J: 6-12 mos unless pressure from last time
B: during first half of 2005, servers will run s/w
C: already has s/w
D: not repre
E: not repre
F: already running s/w
G: infrastructure upgrade and move takes priority; dnssec prep in planning? no
H: runs diff s/w on diff servers; one already running s/w, other could be made to within a week
I: less than 3 months if s/w is there and available
K: less than 6 months, cd be expedited if necessary
L: 6-9 months, cd be expedited if necessary
M: depends on performance; depends on release of BIND 9.4

Lars Liman: If want to publish that, also need to address ability to handle dnssec

Steve Crocker: active dnssec-deployment activity, would like to formalize this type of survey and work on next steps, add as part of the dnssec-deployment roadmap - online @ Would it be possible to have responses by the MDP-ICANN meeting in a few weeks?

Room: doubtfull, too little time.

Steve Crocker: Would like to build positive pressure.

Note that the USG has selected ECC as approved algorithm. DNSSEC resolvers/validators will need to have this support added.

Bill Manning: what to do w/ old instances? upgrade? turn off? what? There is still significant traffic. They are no longer in the authoritative servers lists. Little said about upgrading systems to meet future needs when approval to renumber was given. This IP address is the last remaining from the original root servers. We have an obligation for stable operations. Bill Manning will make inquiries with USDoC for guidance. Options seem to fall into two general choices, shut down the server/service on the old address or continue to upgrade the service on the old addresses for undetermined periods. Further discussion should occur on the mailing list and a recommendation should be forthcoming.

cho. - not much progress. save Yuji has PhD... 5th WIDE/CAIDA next week.

Randy Bush was invited to workshop at APNIC, and he had some comments about anycast DNS. Daniel Karrenberg has not been able to replicate what he has observed, but it could be because of where on the net it is happening. It's really mostly about routing, not dns. Still get answers, but get
them from rapidly changing instances. There may be more data presented at the CAIDA/WIDE workshop.

k.c. - OARC - next rssac - rpt on 1918 @ root
dkf. - dnsmon data for the caida/wide mtg.

Public Relations

root ops vs rssac pages. clean up both. John Crain: SSAC has better structure - can we learn from this? Steve Crocker: SSAC wants to produce better reports. Looking for a "fellow" to track this. Considering some candidates to track these efforts/changes
Jun Murai: Would like to promote what is happening, clear up misunderstandings; more of an education role. Perhaps start with publication, starting with the organized meetings.

The offical ICANN page does not have most RSSAC minutes i.e. Minutes are not being published.

Is a step just to publish minutes? Last time discussed, Bill Manning IS publishing raw minutes. ICANN was supposed to clean up these and post them.

Bill Manning knows someone who might be a good candidate to do it.

Suzanne Woolf would also like a contact person, someone to monitor things said about the roots. Roots don't have time to check for these, but if found, maybe could respond. This person can initiate contact, maybe dispute some low level findings.

Conclusion: So, yes, it would be helpful to have someone support the work of the group.

Jun Murai will write up a job description and send to the list for review. Once that is done, we'll work out how to fund that person.

31jul2005 - Paris - 15:00-17:00
venue & room to be announced.

Bill Manning
Cathy Murphy

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