ICANN participation

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

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