RSSAC Meeting, Oslo, Norway
Date:
12 July, 1999
Agenda for RSSAC Meeting, OSLO
- Public information of RSSAC (SZ)
- Primary Server Transition Issues (SZ)
- Change control: Review/Suggestion/Decision structure overview (JM)
- Change control: details (BM, DE, MK)
- Zone operation (RP, DK)
- Contractual procedure (MK, DK, DC, JM)
- Y2K (DC, AK, BM)
- Study/Investigation on the distribution (location) issues (EN, MK, JM)
- 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.
