Skip to main content
Resources

RSSAC Meeting, Paris

new attendees are listed w/ affiliation

jeff baker,  ep.net
john crain
steve conte
suzanne woolf
joua dumas
rob austien
johan ihren
steve crocker
bill manning
jun murai
cathy murphy
russ mundy
lars liman
mark kosters
<new vsgn person>
matt larson
olaf kolkman
daniel karranberg
brett carr, ripe ncc
akira kato
yuji sekai
rob payne
andrei robacheski
jim cassells
mike green
rip loomis
george michaleson
kenjra cho
fredrico neaves
...

agenda

     dnssec impact on root
     ssac report
     anycast update
     IPv6
     measurement & simulation
     icann status
     policy status & root servers
     rssac btwn today & next meeting
     others

dnssec for root - Olaf K.

     slides <http://www.kolkman.org/dnssec/dpf.pdf> - summary: CPU impact
     is small, Memory can be calulated but bandwidth is harder to cacluate.
     for most zones this is a non-issue, the most important factor is the
     property of the queries.
     we may need to ask the IETF to remove cruft e.g. to move the DNSSEC
     response from additional section.

     check for DO bit enabled queries.  more than a million RRs will push
     the memory limit.
     tests not checking multiple keys or multiple algos... yet.

     readiness - root ops are on track. although at least one is out
     into 2006. there is a question about drivers to make the upgrade
     occur.  

     Crocker wants the readiness stuff documented - as part of the
     dnssec-deployment part of DHS... looking for tracking data
     into the roadmap. - he will revisit an older "yard-stick" and
     we will update.  -  at some point there are external factors that
     will not change.  and we are not speaking about the signing aspect.

SSAC report - Steve Crocker

     there is now a full time staff @ ICANN - Dave Piscatello
     as a person tracking and completing the work/reports.

     Suzanne Woolf - the rise in the number of request to ssac is potentially
     disurbing. RSSAC itself tends to not have an opinion unless asked by
     ICANN board. A few recommendations have emerged and a few more are
     forthcoming.

Anycast update - Matt Larson

     the update from ICANN-GAC - Luxumbourg
     Bill Manning - recent reports of unauthorized copies of anycast
     instances - they appear to exist.  Do we have good tools to detect
     and mitigate?
     Rob - IPv6 anycast has been fixed in the IETF.

IPv6 - Bill Manning

     studies have been completed and a proposed recommendation has
     been drafted. RSSAC will look at the proposed recommendation and
     if no further comments in 14 days - will ask Jun to recommend to
     ICANN for IPv6 glue for roots.  Need to get updates to "G" first
     and update test for Joao before the 14 day window starts.

Measurement    - Kenjura Cho

     nothing to report from caida or wide.
     Russ Mundy - DETER wants to build an accurate simulation of the
          root server system.
          Will root operators be willing to contribute/participate?
          Are there sensitivities with the root system?
     Matt Larson - yes there are, at least for VSGN.
     Bill Manning - concerned about viability of results/reports generated
          from "stale" information.
     Jun Murai - openended testing of routing systems is very difficult.
     Russ Mundy - intended to be a community resource.  testing for a system
          basis.
     Suzanne Woolf - what is the expected level of participation? 
          contributed traffic traces, configuration information, etc?         Russ Mundy - configuration data would be most helpful
     Suzanne Woolf - this is perhaps more sensitive than traffic.

     Liman/DFK - we will not give you anything we will not publicly publish.
     Matt - not sure we (VSGN) will be able or willing to participate.
     Jun - want to see detailed experiment plans first.

     So... the general feeling from the operators is "come ask".  
     for further detail, see http://www.isi.edu/deter

ICANN status & IANA status  -- John Crain / Suzanne Woolf

     A hot item is the status of agreements w/ ICANN & root ops
     RSSAC has stayed focused on its core issues.  Good meeting w/ GAC
     at the last ICANN meeting in Luxomberg
     Many now beleive that "no news is good news" from us.  A high
     level of trust that we do well and are focused  on stability.
     GAC and others want to see more statistical data - some was available.

     Jun Murai - historically was asked about root server deployment status.
           Anycast has solved most of those operational issues.  There
          are still political issues. - had also been asked about TLD
          creation and RSSAC/Root Opertor involvment  - is it still a
          concern?
     Suzanne Woolf - We have stated that we carry the data.

     Steve Crocker - At the CapeTown ICANN BoT meeting - discussed how big
          can the root zone be?  do the root servers care?  Where are
          the thresholds for the operations.
     In general, this is not an operational issue, its a backoffice
          management concern.

IANA - John Crain
    
     not much change .  there is a change in the IANA management.  The
     manager job is open.  The internal servers are being upgraded to
     support DNSSEC.

Policy -- Jun Murai
    
     The lack of visable, written documents on root server coordination
     and cooperation are a long standing concern, with current environment,
     much higher visability. what action items do we have do move forward
     on this issue? we need to do something on this...

     Suzanne Woolf -  WGIG report came out and pointed out that the roots
     are run by trust and not treaty/policy. this is perhaps an issue
     for the operators not rssac. 

     Steve Crocker - whats the distinction btwn rssac and ops.
     RSSAC is an advisory group to ICANN, contains many folks from
     other groups... root ops have access to the operational boxes.

     Jun Murai - root ops need to make progress on formalizing what they do,
     perhaps outside a contract ... as first steps.
     Would like to make progress before next meeting. 
    
     Rob Austein - we might consider referencing the USG/National Academies
     report.

     Bill Manning - One possible way forward is to take prior drafts from
     past years and look for common language.

     Jun Murai - It may not been required to have all root operators
     "sign-on" at the same time.  Any such agreements may be evolutionary
     in nature. 

 RSSAC - interim meetings & next face to face

     Vancouver - 06nov2005
     need interim meetings - how / where / when.
     will update the www.rssac.org pages - send for committe review -
     intent to overlay on icann pages - make sure there is
     clarity on the roll-relationship btwn rssac.org and icann.

     how to select a new chair - this task is in the bylaws.
     do we use the processes that have been used to select
     liasons in the past?  Bill Manning will write up a draft
      and present it for editorial markup to the committee.

AOB?

No?? ... thanks!

------
 

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