RSSAC Meeting, Minneapolis, MN

Date: 
6 March, 2005

Minneapolis, Minnesota

RSSAC - 21st Meeting

Attendees:

Present: John Crain Present via
telephone:
Mark Kosters Fredrico Neves Daniel Karrenberg
Brian Coppela Abram Thielke
Jessica Little
Nevil Brownlee Johan Ihren Mark Schleifer
Mike Green Kenjura Cho Kim Claffy
Jim Cassel Jun Marui Regrets:
Rex Hayes Akira Kato Gerry Sneeringer
Andrei Robachevsky Yuji Sekia Dave Swager
Steve Crocker Lars Liman  
Geor Michaelson Suzanne Woolf  
Cathy Murphy Bill Manning  
Steve Conte Joao Damas  

Agenda:

Root Operational Changes
- G. Anycast etc.

ICANN liaison report

ICANN nomcom

SSAC report

V6 status/issues

DNSSEC

Measurement

PR - web/presetnations/disclosure languages

publicity/press officer

Future

31jul2005 Paris

Agenda Correction:
SSAC removed.

Root Changes:

G will move in topology & change administrative management.

It is moving
from the WDC area to Ohio and from SAIC to the US

DISA as the
operational team. Welcome to Mike and Jim from DISA.

A t the time of the topology move, the nodes will be upgraded. timeframe
for the physical move is estimated to be June-October. The Ohio node will
be physically much more secure than the old node. Will keep the same AS
if possible. May see AS path changethat removes AS 568 and injects AS
721.

Adding more processing power and bandwidth so "G" should be
seen as a better participant than in the past. Otherwise, externally,
there should be no visable changes.

D has delayed its
renumbering plan.

H has no current plans for restructuring.

Anycast Updates:

the root-servers.org public page ... it needs to be updated to

reflect WIDE/M links. Are there other updates required? Since

there is no common root-server operator organization, some

server operators are not keeping info on this page current. Once

such an organization exists, it will be prudent to have a common

site for publishing root server information.

ICANN liaison - Suzanne
had accepted the assignment. This is her report.

A few items worthy of mention:

  1. WSIS process &
    WGIG - a political effort - not a real root server issue ... we've done
    some good communications - need to do more.
  2. New TLDs - again
    not root ops.
  3. .NET rebid is underway.
    Schedule calls for EOM-March to announce award - mid June for transition.
    Still confusion over what we do. Process of root zone creation vs. server
    operations.

    Steve Crocker: Its been a good thing to have an RSSAC liasion and Suzanne
    Woolf is a good fit.

    Suzanne Woolf: would like help in reviewing materials, etc.

    Daniel Karrenberg: willing to help in my neighborhood. The ISOC briefings
    may be useful.

NOMCOM Suzanne Woolf:


we need to send a non-voting member. She did it last year and need to
send someone else. Lars Liman has been asked to volunteer but needs more
info.

Jun Murai: it seems a good idea to have someone other than Suzanne Woolf
take this on. Steve Crocker: almost more of a recruiting drive than a
vetting of a large candidate pool, Jun Murai might be the best choice.


Bill Manning: are we asking for a larger candidate pool?

Jun Murai: Yes, and will like to have an answer this week.


V6 Bill Manning:

S ummary of history - additional testing done; need to publish the results.
need to identify the communities impacted.

Issue: if an IMR
generates a priming query with at least one failure condition, it could
have severe impact on that caching server.



Jessica Little and Bill Manning did some testing. VeriSign did some work
and reported last the NANOG. Bill Manning will finish his testing, write
up the results and merge/compare results with the VeriSign data.

This will help identify the impacted IMR servers at that given

point in time.

Has potential for
a pervasive and hard to detect, externally, negative impact on individual
IMRs if turn on v6 glue for root servers.

Steve Crocker: Didn't
SSAC discuss this?

Fredrico Neaves: No, only discussed packet size issues and it was only
with regard to the impact on TLDs.

Johan Ihren: Discussed doing an inventory of old, broken software out
there that will get broken in new ways if add v6 to the root. What to
do about that broken software is a different matter. Know there is a problem,
don't know the scope or what to do about it?

Bill Manning: Before
RSSAC can make a recommendation, should do research to identify what the
problems will be. Will make ICANN more comfortable about when/how to proceed.
Will try to compile info in time to review before the Luxemborg mtg. but
only a portion of testing has been done. We need to compare data from
each server instance against the failure modes

Steve Crocker: This
is of critical importance.



DNSSEC Lars Liman:

deployment status - several facets. asking about

software status - there is much more - distribution et.al.

this is s/w only... update matches the last update as to timeline

A,J: 6-12 mos unless
pressure from last time

B: during first half of 2005, servers will run s/w

C: already has s/w

D: not repre

E: not repre

F: already running s/w

G: infrastructure upgrade and move takes priority; dnssec prep in planning?
no

H: runs diff s/w on diff servers; one already running s/w, other could
be made to within a week

I: less than 3 months if s/w is there and available

K: less than 6 months, cd be expedited if necessary

L: 6-9 months, cd be expedited if necessary

M: depends on performance; depends on release of BIND 9.4

Lars Liman: If want
to publish that, also need to address ability to handle dnssec

Steve Crocker: active
dnssec-deployment activity, would like to formalize this type of survey
and work on next steps, add as part of the dnssec-deployment roadmap -
online @ dnssec-deployment.org. Would it be possible to have responses
by the MDP-ICANN meeting in a few weeks?

Room: doubtfull,
too little time.

Steve Crocker: Would
like to build positive pressure.

Note that the USG
has selected ECC as approved algorithm. DNSSEC resolvers/validators will
need to have this support added.

Bill Manning: what
to do w/ old instances? upgrade? turn off? what? There is still significant
traffic. They are no longer in the authoritative servers lists. Little
said about upgrading systems to meet future needs when approval to renumber
was given. This IP address is the last remaining from the original root
servers. We have an obligation for stable operations. Bill Manning will
make inquiries with USDoC for guidance. Options seem to fall into two
general choices, shut down the server/service on the old address or continue
to upgrade the service on the old addresses for undetermined periods.
Further discussion should occur on the mailing list and a recommendation
should be forthcoming.

Measurement:

cho. - not much progress. save Yuji has PhD... 5th WIDE/CAIDA next week.

Randy Bush was invited
to workshop at APNIC, and he had some comments about anycast DNS. Daniel
Karrenberg has not been able to replicate what he has observed, but it
could be because of where on the net it is happening. It's really mostly
about routing, not dns. Still get answers, but get

them from rapidly changing instances. There may be more data presented
at the CAIDA/WIDE workshop.

k.c. - OARC - next
rssac - rpt on 1918 @ root

dkf. - dnsmon data for the caida/wide mtg.



Public Relations


root ops vs rssac pages. clean up both. John Crain: SSAC has better structure
- can we learn from this? Steve Crocker: SSAC wants to produce better
reports. Looking for a "fellow" to track this. Considering some
candidates to track these efforts/changes

Jun Murai: Would like to promote what is happening, clear up misunderstandings;
more of an education role. Perhaps start with publication, starting with
the organized meetings.

The offical ICANN
page does not have most RSSAC minutes i.e. Minutes are not being published.

Is a step just to
publish minutes? Last time discussed, Bill Manning IS publishing raw minutes.
ICANN was supposed to clean up these and post them.

Bill Manning knows
someone who might be a good candidate to do it.

Suzanne Woolf would
also like a contact person, someone to monitor things said about the roots.
Roots don't have time to check for these, but if found, maybe could respond.
This person can initiate contact, maybe dispute some low level findings.

Conclusion: So, yes,
it would be helpful to have someone support the work of the group.

Jun Murai will write
up a job description and send to the list for review. Once that is done,
we'll work out how to fund that person.

Future

31jul2005 - Paris - 15:00-17:00

venue & room to be announced.

--scribes

Bill Manning

Cathy Murphy