Skip to main content

RSSAC Meeting, Minneapolis

RSSAC meeting 12


Brad Verd Paul Vixie Yuji Sekia
Bill Manning Don Wilder Jun Murai
Louis Touton Ray Plzak Joao
Karen Rose Gerry Schnieering Johan
Susan Wolf Cathy Murphy Lars Liman
John Crain George Michalson Via Phone:
Matt Larson David Conrad Jessica Little
Randy Runkles Akira Kato Howard Kash III
Neville Brownlee Kenjri Cho  

Note takers: Bill Manning; Cathy Murphy


  1. Statistics and measurements (kjc and nevil)
  2. IPv6 (kato, johan)
  3. tsig (bill)
  4. MoUs btwn Ops/ICANN (paul)
  5. Global interests (bill)
  6. CRADA report action (paul)
  7. Homeworks, scheduling,housekeepings(jun)

Nevil - slides on RTT. Measuered from a single point. Slides via

have added SJC to UCSD. // from Jan2002

-gap in graph=meter was dead

displayed examples and explained meaning of graphs

Q: (DRC) Is it mapping data for C-root?

A: Not from UCSD(?) but there is data from USC (?)

Q: (LT) How long does data go back?

A: about the 7th of January

bill - realtime?

Nev - no, 24hr.

bill - please dont

Joao - correlation w/ path?

Nev - not yet.

Kato - placement?

Nev - SJC is inside an ISP - will remove it when a better site hits.

KJC - (sent MJP slides)

Bill - important to have ICMP? e.g. why does L rate limit it?

(take to list)

Bill - path sensitive?

KJC - not explicitly

Sz - what effect of Load Balancing

LT - active vs Nevils passive

points out that AP uses US/WC, SA uses US/EC, NAfrica uses Euro... :)

like Nevil, wants more sites for measurement.

Bill - how can you tell a caching server is "mis-configured" or


Paul - you can't. Implementation dependent.

Bill - need better documentation on what is a correctly functioning cache.

Paul - an area of active research and documentation.

Jun - useful for the group in gaining emperical evidence for reporting.

Continue to fund? - Sz/Paul/Bill - yes...

DRC - what is the goal of collecting the data?

Jun - rehoming server reports.

2. v6... :)

Kato - report on packet size limits recommend two AAAA. Is there a formal

proceedure on how to modify the zone?

Louie - use the normal proceedure... Documentation might be different.

Jun - we will write an inital request for documentation on how to do this from


BM: Kato has a document that says this is what we can do without effecting bit

DRC: So testing has been done that effects tcp-bits

Kato: Need more testing

Kato - what address space to use? - provider independent is desirable.

can we get small, routable blocks for "critial infrastructure"?

BM: APNIC and ARIN have had these discussions.

Group: we will compile documentation by the end of the month.

Five candidates, M, B, A, F, K....

Johan - a question. The reason we have a problem is the hints file. Because

it is distributed and never changes... :) Can we have a new scheme

e.g. signed packet, temporal efficacy of hints etc?

Paul - No. Too much potential for abuse. Not in a Rush.


Should be done by apr2002 - dropped the ball for Jan2002 rollout.

Report will be circulated to RSSAC. May be used for CRADA.

All servers use AXFR and so are TSIG candidates.

Will start w/ SNS/B --- runs this btwn DM & SNS/A/J

4. MOU

Jun: Each operator has been working directly with icann to finalize mous; very close to signing; but on other hand, mou is not heavy contract; basically describes current situation; not yet looking toward the future.

One thing discussed this morning, that delayed the process, was that the person responsible for signing is not in this room. One action for that direction is to have that person that they understand what has to be done. and Two, to discuss the Stuart proposal. That's another process impacting this action.

MOU is important. Need to develop a suite of mtgs w/ policy makers as well as technocrats. Paul will set up list & est a venue for policy makers to discuss MOU.

5. Global Interest

Desire to get stats measruing tools to perceived underserved areas:

  • SaoPaulo
  • Johannesburg
  • Cairo
  • New Delhi
  • Singapore
  • Beijing

All agreed to host measuring instruments and be involved in determining how performance is measured, and have impirical data to back up assertions.

Also, APRICOT and Ghana, there is dirth of experience by ccTLD server operators; trying to writeup a BCP and would like to get RSSAC's expertise feedback, especially Centre people would like to work with RSSAC to find out how to run a root server.

Q: (Jun) Good to share, to interact with some part of us (rssac), then if we don't have transparent process b/w us, then its a problem

A: (BM) currently, ccTLDs go with the low cost bidders to run nameservers, and most are not motivated. Encourage people to do better architecture and second each other, get diversity in slaves

Jun: two issues:

Additional educational things wrt dns operators is separate, but good thing

Different issues.

LT: underscore Jun's point; in light of increased focus on scope and mission, it might be that the first and second things should be addressed in a different way.

BM: how so?

LT: not clear that second task is in rssac's mission

bm: perhaps not.

That's it on global interest.

Measurment nodes & correct operations are needed and wanted

We can do some outreach if we want. TLDops want ROOTops to sanity

check their expectations.

Two issues - outreach & training - Jun

What is the scope & mission? - Louie - Should be addressed in different ways. Is the second task part of RSSAC mission?

6. Report Action:

Jun - no report yet. We need to pull it together before next mtg.

Paul has the list:

On the report, Paul will be lead editor. Sz, Liman, Jao, Gerry, Manning, John C., Brad, Matt, Arthur will write stuff & Paul will hammer into coherency!

Bill - timeframes?

Paul - draft cirulation before next mtg.

Jun - End of April2002 would be better.

7. Next mtg. 14july (sunday) Yokohama -

(GMT +9) 3pm = 1am Monday ; do a conference bridge from US?

Ray: Offer that ARIN has conf bridge for ASO AC. Could call internaltional that don't want to call in

That's a thought...


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