Skip to main content
Resources

RSSAC Meeting, Oslo, Norway

Agenda for RSSAC Meeting, OSLO

  1. Public information of RSSAC (SZ)
  2. Primary Server Transition Issues (SZ)
  3. Change control: Review/Suggestion/Decision structure overview (JM)
  4. Change control: details (BM, DE, MK)
  5. Zone operation (RP, DK)
  6. Contractual procedure (MK, DK, DC, JM)
  7. Y2K (DC, AK, BM)
  8. Study/Investigation on the distribution (location) issues (EN, MK, JM)
  9. STATUS of MOP - A and J will wait on DoC directives in two parts
Attendees:
DK Daniel Karrenberg, RIPE (server K) MB Mark Bohannon, US DoC * Called in
MK Mirjam Kuehne, RIPE (server K) RP Ray Plzak, DDN NIC (server G)
LL Lars-Johan Liman, KTH (server I) DC David Conrad, Internet Software Consortium (server F)
MK Mark Kosters, NSI (server A, J) PB Piet Barber, DDN NIC (server G)
SZ Suzanne Woolf, IANA GH Geoff Huston, IAB
BM Bill Manning (server B, L) Havard Endeis (server I)
AK Akira Kato, WIDE (server M) Mark A.
EN Evi Nemeth, CAIDA Keith
JF James Fielding, ARL (server H) Nay Davis (ARIN)
GS Gerry Sneeringer, Univ.MD (server D) Ramin (ARIN)

1. ICANN requires public records:

Issue: These documents should include major issues, recommendations not needed to include security or sensitive topics Should be posted data on web server - soon after mtgs. SZ will send a timeline. Singapore notes by end of week.. Other meeting notes soon after. A suggestion was for two working weeks after a final notice for publication. Final notice should be at least two weeks after the meeting.

2. Transition plan:

Issue: Initial deadlines were naive, but progress is good, no plan can be executed w/o ops agreement. current scope is change in master & directly related procedures. issues are primarily political not operational nature.

EN: when do you think it will be done?

MB: - hope that the document will be in the form of a recommendation that DoC can use. This will be a recommendation to ICANN. ICANN can use in recommendation to DoC). Done two iterations, may take more than three. #3 may be out this week, (Friday).

EN: can this be concluded on the list?

principles are ok, details can be worked out on the list & sent on... may not need to wait for new RSSAC meeting for promotion.

Y2K. Working draft posted to site.

Has some revision forthcoming. Minor changes, adds a date to the document. Executive Summary: The root servers will work. Main dependency is Telecom grid. MB. wants to compare notes week from today. Statement released at end of week. Telecom to brief US Gov. folks prior to end of month meeting is desired. Feedback to the list please.

3. Change control - ICANN roots & operators role.

create a request for change
request received
political & technical evaluation
decision
change order.
change statement
update root name server administrative procedure(s)
the last half to be executed by root server operators.
the first half – need DoC and ICANN approval on the process

PB, political & technical evaluation is an "and" not an "or"

MK, what are the criteria? should it be outside our charter

marka, even to the point of NS change

SZ: The process should accommodate both NS changes & RS moves

JM:do we need to do both front & back halves?

RP: what is the scope of change that this will be applied to?

BM: We should list total scope of work wrt change control and then detail specifics for the RSSAC, a taxonomy. RSSAC must have a part in the technical review in the first phase.

GH: lightweight/heavyweight process. What can we not use this process for?

EN: RSSAC ought to be peer reviewed every time.

RP: must be unanimous or deadlocked?

All: Need "3ring binder" from the Taxonomy for SOP.

4. Change control: details

BM: from the 20jun draft, can ICANN operate a root server?

MK, BM to move forward. may need to touch base with MB and Karen Rose (DoC) next week.

6. Contract issues:

MK has something from his legal. It will take time to digest. based on drafts of gTLD servers. DK offers a view from a different legal system, from a general point of view. JM will do the same. Very general from an operational perspective.

Obligations & commitments to/from ICANN/Operators.

BM:- MOP derivatives?

Need to be proactive and give ICANN our "demands".

Distribution Measurement:
measurements - use skitter, RTT & PATH, install "next" to roots
uses target data sets from CAIDA & root server query logs.
logging - can root servers log queries?
for how long
how much data/hour (MK, A does in 2min intervals,
not to server hardware, patches to bind )

questionnaire –

#peers
#transit providers
# qps/d
# what else
# which zones
# % of "good" queries
status - sent one to "F", its -lost-... :(

will servers support CAIDA measurement nodes?

a - yes
b - yes
c - n/a
d -
e -
f - yes
g - yes (space constrained)
h - yes
i - yes
j - yes
k - yes
l - yes
m - yes

DK, PINGS yes? what about the RIPE measurement activities?

9. MOP issues.

MK: Can the two items be segregated?
MB: Guess that we can talk about it.

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