ICANN participation

The following agenda was presented:

ccTLD mtg report

CRADA report

Contrract process

CAIDA/WIDE measurement

IPv6

Members (RSSAC list) -discuss list?� Openness?

Schedule

Jun Murai asked whether there were any additions or adjustments to the agenda.� Bill Manning suggested�some discussion about openness, etc. perhaps an rssac-discuss mailing list?

Note takers: Bill Manning, Cathy Murphy, George Michaelson, Louis Touton, Johan Ihren

Attendees

Ray Plzak, ARIN

Joao Dumas, RIPE NCC, K

Frederico Neves, LACNIC

Louis Touton, ICANN

Don Wilder, ARIN

George Michaelson, APNIC

John Crain, ICANN, L

Suzanne Woolf, L,F

Bill Manning, B

Nevil Brownlee, CAIDA

David Conrad, Nominum

Paul Vixie, C, F

Randy Runkles, G

Cathy Murphy, ARIN

Akira Kato, M

Jun Murai, Chair & M

Lars Liman, I

Johan Ihren, I

Paul Wilson, APNIC

Brad Verd, A, J

Kenjiro Cho, SONY

Yuji Sekiya, WIDE

Jerry Sneeringer� � phone

kc Claffy - phone

ccTLD Bucharest report: - Crain

http://www.wwtld.org/~wwtld/livescribe/
contains copies of the presentations given to ccTLD managers in Bucharest.� The overall theme of these presentations was:� Who are we and what do we do? They included a short introduction/update for ccTLD managers. They obviously feel the need for some sort of contact mechanisms to reach us in contingencies.

RSSAC making presentations to ccTLD managers and talking about what we do fills a real hole and alleviates some worries/doubts that they may have had. They would like RSSAC to better document its process, recommendations, and proceedings.

CRADA report:

Extended goal to 30 June 2002 �Paul Vixie reported that a rough draft was circulating and that additional text is being worked on.� Nonetheless the editorial team needs more raw material (substance) to complete the draft for wider circulation.�

The schedule for getting draft to DoC was discussed.� Louis Touton reported that ICANN received a letter from DoC, expressing concern over the fact that the report had not yet been received.� A good target would be to get a draft to DoC by mid-August.� To achieve that, comments on the draft should be sent to the list once it is circulated. Johan Ihren asked whether it was feasible to get a draft to the list by mid-July, so that it was stable by mid-August.

Jun Murai noted that the existing draft had some missing parts.� In particular, he noted that material from the presentation at the November 2001 ICANN meeting on root-server security should be added. Louis Touton noted that a draft covering that material would be very useful, particularly if it could be completed in July.��About 20-30 pages of material would be good.

Jun Murai asked whether monetary support is available from ICANN to support this effort. Louis Touton responded that monetary support would be possible, provided it were limited in extent.

Jun Murai commented that the draft report could use broader circulation, earlier.� Perhaps a first pass this weekend.� Need much more help. He noted that everyone needs to do their part to meet the deadline.

Contractual Process:

At the time of the last RSSAC meeting there was a decision to assemble a list of representatives of the root-operator organizations that can sign contracts.� In many cases, the individual operators are not able to �bind their organizations legally.� So, at the time of the last meeting Jun Murai requested names of those who could legally bind the hosting organizations.� We now have a list, but it may not be accurate�it is simply
�a first pass. It does serve as a tentative list, however, and we can start discussion with this group and then evolve it.� The papers/MOU�s have been circulated to this group,� This signers� group might have as input, for example, things on ICANN reform.

Bill Manning asked whether there is there any interaction between this policy group and RSSAC.� Jun Murai asked for opinions of the committee on this point.� Louis Touton stated that, perhaps, the RSSAC might be used to ensure the policy folks understand the technical issues.� Paul Vixie noted that a reason for assembling the signers group is to explore the reasons why none of the organizations have entered MoUs.� Having a group facilitates communications between organizations on why they did not sign. Will meet between now and next RSSAC meeting.� Appears to have input into the CRADA report so could meet soon. The goal is to get to a point where a contract could be signed. An issue is the difficulty in finding the individuals with signing authority.

Measurement:

Nevil Brownlee presented his slides, which are available at http://www.caida.org/.� The CAIDA work involves three types of analyses:

• passive measurements
• bind log file� analysis� from (F)� - now RFC1918 servers
• skitter � (all are deployed now)�� - simulation of the impact of server removal� (presumption of� heterogenous resolver code)

He stated that CAIDA is looking for direction on how/where to go from here?� Ggw asked whether more measurement siteswere needed?� Nevil stated that four more are needed. Louis Touton asked whether that will this give meaningful data? Nevil was not sure that it would.

Paul Vixie showed some MRTG data for Hazel (the RFC1918 server used above � anycast).� He pointed out the interesting spikesm, which reflect human activity, human factors theories: small networks, no sysadmin, misconfigured.� The data also show accumulated behaviours of lots of small things.� It was thought to be the result simply of a microsoft bug, but this has been reasonably disproved. Looking at hosts sending the requests� and 1/3 identified as M$ (at most)� or misconfiguration, or causal synch of some other effect
eg DHCP lease renew.

http://www.as112.net

Kato: more servers in Tokyo.� Interesting TCP data.� TKEY exchange is statistically significant. Looks like all Microsoft requests.

Bill: can make old 1918 server logs available.

Kenjiro Cho presented some slides, which are posted at http://mawi.wide.ad.jp/mawi/dnsprobe/results

Good data on the resolvers server selection algorithms as a driver on server placement. The question is how to get that information back to developers.� Paul Vixie noted that the surest way to get developers to
correct their code is to submit patches to them.�

Louis Touton noted that the method of analysis of root-server placement described in Kenjiro Cho�s presentation is based on assumptions about resolver strategies.�Prediction of resolver strategies, and how developers may change them in the future, is speculative.� He suggested announcing what the assumptions were when placement occurred, so that developers could factor the assumption into their resolvers.�

Paul Vixie, while agreeing that the resolver strategies are important, pointed out is the analysis of placement being discussed involves less than 1000 servers (roots/cctlds).� The impact on resolver performance is more affected by other DNS topology considerations, such as where Yahoo places its nameservers.� We are very much in the minority in terms of the number of DNS transactions handled.

Louis Touton asked whether the RSSAC understood why the different resolver strategies were selected.� In response, Paul Vixie indicated that the BIND 4/8 strategy was developed based on experience of sys-admins. BIND 9 was initially based on a more theoretical approach. He believed that other resolvers also lacked the benefit of sys-admin experience. He suggested that the issue of resolver strategies should be referred back into DNSext WG, since it is not an RSSAC issue.

Placement:

Anycast can mitigate the hole left by the temporary failure of any single machine or site. Anycast instances should be deployed at the Internet core for best benefit to the greatest number, not on congested links.

Akira Kato handed out the beginnings of a memorandum on providing for IPv6 responses by the root servers and asked where that memo should be discussed.� It was decided that it should be discussed on the root-ops list and then, when matured, fed back to RSSAC.

Louis Touton noted that the IPv6 approach proposed does have the potential for truncation, and needs justification for making the changes to ensure no enduser visability.� Paul Vixie, although noting that he likes to avoid �bit-twiddling� in RSSAC, suggested one possible approach.

Do we need to send queries back their response? He mentioned that a possible approach might be to omit the query section in root-server DNS responses, then adding the AAAA records for IPv6 support. Louis Touton: �environmental impact statement� would be nice.

Akira Kato quoted measurements showing that EDNS0 was not yet widely used in terms of overall load. The 512-byte limitation must be considered until EDNS0 is more broadly deployed.

RSSAC membership & better communication (Jun Murai):

Jun Murai mentioned that he had received requests for observer status.� The RSSAC had open/closed sessions in the past.�

He posed the questions for discussion:

Should the RSSAC have more open sessions to increase transparency? Better documentation/publication?� Louis Touton stated that one simple step to increase transparency would be to renew efforts to publish minutes.� After some discussion, it was decided that Bill Manning will summarize past meetings and send them out subject to 14-day last call.� He will target sending out one set per week.� Louis Touton will work with Bill, particularly to fill out the minutes in narrative-paragraph form.� The 14-day last call will simplify getting approval of the minutes from the RSSAC, so they can be posted as official minutes.

A discussion ensued about possible ways to increase community access to, and the transparency of, the RSSAC�s activities.� One positive measure would be to establish an official �open way in�, so that comments can be received. Louis Touton agreed to set up a formal mechanism so that submissions to the RSSAC are collected and submitted to the committee.

Another mechanism discussed was a moderated discussion list for RSSAC issues.� In discussion, the difficulties in moderating a list, including the possibility of controversy over the moderation, were discussed.� It was decided to implement the formal submission mechanism now, and review the situation at the next meeting (or earlier on the list, if appropriate) to decide whether also to implement a RSSAC discussion list.

Jun Murai asked whether RSSAC membership should be expanded or reevaluated.� He also suggested that public forums should be held (noting the success of the ccTLD presentation in Bucharest discussed at the beginning of the meeting).� There was some support for this, along the model of the ASO forums at ICANN meetings.� Most members felt, however, that IETF meetings should continue to be the main venue for RSSAC meetings, due to convenience factors.� Several members noted that having renewed IAB/IESG involvement would be helpful, and it was agreed that a renewed invitation to IAB/IESG to designate liaison members should be made.�

Jun Murai indicated that the next RSSAC meeting will be held in connection with the Atlanta IETF meeting, on the Sunday afternoon.