Skip to main content
Resources

RSSAC : 2004 Conference Call

RSSAC conference call - 18th Meeting

Seoul, Rome, USA, Germany

Attendees:

Seoul: Rome: Other:
Jun Murai Bill Manning Daniel K.
Kenjiro Cho Cathy Handley Kim Claffy
Akira Kato Suzanne Woolf Jessica Little
Yuji Sekia Nico Jakobsson Paul Vixie
George Michaelson Johan Ihren Joao Damas
Frederico N.   Gerry S.
Ed Lewis    
John Crain    
Rob Austein    
     


Agenda:

0. Rollcall/Agenda 10 min

1. IPv6 status updates report and discussion 15 min
Root Zone issue
Root server's transport

2. Anycast status update report and discussion 15 min

3. Summary or plan of related meetings (external outreach) 45 min
ITU, WSIS, ICANN GAC

4. AOB 03 min
Measurement

5. Schedule of next meeting 02 min

-----------------------------------------------------

0. Welcome to Nico, a new member of the "I" team

1. IPv6 status updates report and discussion
Root Zone recommendation
Root server's transport

Root Zone recommendation:

IANA manager will be talking to the TLDs this week. Expect the proposal will be put to ICANN board soon for 30day approval. Wants to link existing recommendation with root server action. We do not have them linked for a reason. IANA/ICANN should proceed with what is ready.

This is taking too long. Wants to know the IANA position on how this is going to be run, with regard to the two models that have been made on making decisions, will it be autonomous, case by case, or will IANA use a strict algorithmic method?

We should ask the ICANN board of the status regarding our recommendation, including a query on the expected timeframe for implementation. Murai will do this. (The request for status update was sent to the Board)

IPv6 Transport on rootservers

There was an action item from our last meeting to have a few volunteers finish the evaluation of IPv6 to root servers. The testing has not been completed. To reiterate, the following organizations have agreed to evaluate the problem space:

Verisign, Ripe, Isc.

The problem may be characterized as the behaviour of the system when "incomplete glue" is presented. Johan has the most coherent statement of the problem and will send his version to the list. Once a clear statement of the problem is known, consistant testing may proceed.

Others have done some emperical work on IPv6. "M" had started work, which was suspended for a while as the principle investigator was diverted to complete his PhD. Congratulations to Akira Kato.
Work is expected to resume.

NLNET has been looking at traces to see percentage of servers are EDNS0 aware, e.g. capable of processing edns0 queries. Seems to be an increasing trend, in the range of 20-50% When the document is done it will be distributed.

Kato is doing similar measurement on one of the JP servers; 52% IPv4, almost 100% for v6

2. Anycast:

a. no status change reported
b. no status change reported, however B did renumber.
c. no status change reported
d. no status change reported
e. no status change reported
f. f root in 6 or 8 new places, care is needed in procedures etc.
g. equipment on order and waiting but have plans for one new site
h. no status change reported
i. takes longer than expected, monitoring takes work
j. no status change reported
k. proceeding diligently. no major snags except pre-planning
l. no status change reported
m. will be anycast in seoul (kix) possibly this week also in Paris (parix/sfinx). operations being extended beyond rack to cage.

In our last meeting, there was a request for getting clarification on IETF work in defining an accurate server identification process. Rob reports on his two action items:

serverID work. this is a two-prong effort. first is to work Suzanne in getting existing draft through IETF processes. second is to document a new mechanism using EDNS0 to place the serverID in the response. This has to go through the IETF processes. The draft is: draft-austein-nsid-/// A revised version of this document did not go out this IETF ID cycle, expect it to hit before the next meeting.
Suzanne indicates she is tasked with documenting existing practices.

ipv6 anycast addresses as distinct from common ipv4 anycast practice. rssac has asked for clarification from the IETF as to why ipv6 anycast is defined the way it is. inital informal IESG
discussion indicates that there is no good reason for this defined behaviour. further work will be needed to provide a answer as to why anycast should be different in IPv4 and IPv6. The current
specifications are for a kind of anycast that nobody knows how to use. Inital efforts stalled and will need to be rekindled to get this clarification through the IETF processes.


—External Relations
3. Summary or plan of related meetings
ITU, WSIS, GAC & others

ITU/WSIS

The ITU workshop was to collect input from subject matter experts into their process of what they would be saying at further WSIS activities. Not a workshop in the sense we are used to, mainly statements little discussion. Apparent goal is to answer questions raised in WSIS-1 by the time WSIS-2 meets in 2005. Not sure any of this was relevant to this committee. Bill gave a root-ops overview, essentially the same presentation given to previous GAC meetings. Three questions raised:

France:Q: Who pays for them
France:Q: How tsig generated and distributed:

Answer: The operator organizations pay the costs. TSIG keys are generated and distributed during our regular meetings.

Syria:Q: Is US DoC in control of the root zone?
Answer: Yes. But not the root servers.

Daniel suggests that there is a certain amount of miscommunication or misunderstanding of the relationship between the organizations of the operators and the way we interact with the editor of the root zone. We must be clear on the specific roles that each group has.

Cathy suggests that this is a common misunderstanding in governmental bodies and we need to ensure that we are clear on our specific roles every chance we have to present in larger venues... like the GAC. It would be helpful if we could provide concrete answers to specific issues that have been raised in this forum that relate to root DNS, such as regional root servers. Cathy also points out that the WSIS activity is much broader than the Internet but they are tasked with defining the term "Internet Governance". Jun recommends that we take the time, in various forums, to educate policy makers and government leaders on "Internet Realities".

Bill: I was asked if RSSAC members were available for other presentations. Many groups would like more outreach about how things actually work. There is a request to present later this week at the ICANN WSIS outreach.

Daniel is working with the Internet Society on documents of DNS 101 for non-experts. He is about to write one on the evolution of the root system, will pass that around for comment prior to publication.

One question we get asked and have had no coherent answer is, "What will the RSSAC do if a server operator "goes rogue" or is coerced and changes the contents of the root zone"? We have no public answer at this time, trusting people and governments to be rational. There has been some exploration of how to manage the case when an anycast instance is coerced or hijacked. That analysis might be useful in the larger context.

GAC:

RSSAC liaison Thomas Dehaan, Jun and Daniel agreed that Daniel would be a good local contact as they Daniel & Thomas share a country and a language

Talking to Thomas, Daniel realises that there are a lot of misconceptions till within the GAC. Daniel will give a short description of how things work in the GAC meeting this week. Will present as an individual root server operator and ask others to present their views. Not as an RSSAC representative. Jun asked if the issues were similar to the ITU/WSIS working group. Daniel refers to mail that Thomas sent to the RSSAC. Paul Vixie sent his personal views to the RSSAC list which were generally agreed on with the exception of the word/term "volunteer". Suzanne suggests that the word itself causes concern and the presumption of certain beahviour, which may not be true.

Cathy suggests that in some government circles, "volunteers" can walk away with impunity. Paul believes that people are worried that ICANN does not have contracts with the operators or their organizations. Daniel states that none of us even considers "walking away", which is the sense of the
participants in this call. Cathy suggests that we, RSSAC, have to assume a long-term educational mission. Bill thinks that we should continue the discussion on the list. Paul is concerned that root operators must always state that "we can not speak for others, but this is our feeling" (This is true when we speak as a root server operator but not when speaking on or for the RSSAC). Paul continues with the statement that we can say what others have publicly stated as their plans. Bill is concerned that the word "volunteer" has different meanings in different circles. Jessica suggests that we might use the term "active partners". Paul notes that the question of "volunteer" continues to be asked and that one operators management insists on calling all of us but themselves volunteers in their press releases.

Jun calls consensus that we are not volunteers but that we (RSSAC and as operators) have used that term in the past and it has caused some misunderstandings. He then asked if we could make a statement that we have used the term "volunteer" in the past but we now realize that this causes confusion. More debate ensues without resolution.

KC asks what term the IAB uses to describe the root ops. Rob does not believe the concern has ever been raised but does note that there is a similar set of concerns when considering the IESG.

The focus shifted to specific considerations for answering questions submitted by the GAC/IPv6 working group. This wg is fairly small, about five or six people. Cathy indicates that they are primarly interested in determining what is deployed and where. They are considering a survey to be sent to DNS operations staff. It is not clear that this type of work is a priority for the GAC as a whole. Jun states that for the root ops, we have proper answers and Bill can take this. Cathy beleives that the results of the survey may be inputs to what the GAC should do to track IPv6 deployment issues.

4. Measurement

WIDE has had little progress related to root server issues. Most effort has gone into IPv6 and DNS. CAIDA is developing an IPv6 measurement tool that will hopefully be able to use root servers as inital platforms. Longer term work may explore resolver behaviour. A CAIDA/WIDE workshop on DNS issues, sponsored by ISI will be held in April. RSSAC participation is encouraged.

5. Next Meeting

Jun suggests at least one conference call before our next meeting, currently planned to be in San Diego. With no objection, it was decided that if there is a need, calls will be scheduled.

Adjourn

Note takers: John Crain, George Michaelson, Bill Manning

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