ICANN ICANN Email List Archives

[rssac-report]


<<< Chronological Index >>>    <<< Thread Index >>>

initial comments on the rssace review report

  • To: rssac-report@xxxxxxxxx
  • Subject: initial comments on the rssace review report
  • From: Daniel Karrenberg <daniel@xxxxxxxxxxxxxx>
  • Date: Wed, 4 Mar 2009 14:59:31 +0100


[The text below is a slightly edited summary of comments I made on
the RSSAC mailing list]

This is an excellent piece of work.  While I have a number of detailed
nits, I am very impressed with the analysis and the clear and
carefully reasoned recommendations.  Well done!  I especially enjoyed
the reasoning behind the recommendation to keep the name "RSSAC".  ;-)

I like the idea to re-invent RSSAC explicitly as a body of both ICANN and root name server operators. This is very useful both as a conduit between the two and as a vehicle to communicate matters "root name server system"
to the Internet community and beyond.

However, the proposed implementation appears to be significantly biased
in ICANN's favour and will need to be developed further. Just a few examples
of what immediately came to mind in this area:

1) Meeting at *every* ICANN meeting and from time-to-time at IETF *will*
significantly change attendance away from root name server operators.
This cannot be a desired outcome.  The report also fails to explain what
the specific desired interactions with other parts of ICANN are, that
would be facilitated by this mode of operation.  If such specific
interactions were made clear, a modus could be found where
*some* meetings would be in conjunction with ICANN meetings and *some*
in conjunction with meetings suitable for the root name server
operators.  In the absence of such specific requirements I would argue
for a meeting schedule that suits the root name server operators.  In
any case a requirement to meet at *every* ICANN meeting feels very much
like a way to create a committee that invents unnecessary business just
because it is forced to meet more often than required for necessary
business.

2) The proposal to have an IANA representative at RSSAC is a sound one.
However designing this as the "neutral" vote that would break a possible
deadlock in the committee is wrong.  Firstly IANA is currently operated
by ICANN under contract.  So an IANA representative would be ICANN staff
and therefore under the authority of ICANN board and CEO,  hardly a
neutral position.  Secondly a "paralysis" by deadlock in the proposed
new RSSAC need not be avoided at all.  It will have no immediate
material consequences for the operation and evoloution of the DNS root
name servers.  Rather, such a paralysis would signal clearly that there
is a serious issue that needs to be addressed and resolved.  There will
always be sufficient time to address and resolve any such issues.
Therefore I believe that a much more suitable mode of decision making
would be to require "rough consensus" or a 2/3 majority for any
significant actions of RSSAC.

3) Staff and travel resources.  Experience tells me that committees of
time-poor volunteers tend to be significantly influenced by any staff
resources that support their actions.  Also in many people I observe a
more or less conscious bias towards whoever pays one's way to an event,
justified or not.  I am not so much arguing against staff and travel
support from ICANN here.  The challenge will be for the root name server
operators to counter-balance this with staff resources organised by
them, either specifically funded positions or commitments for individual
resources necessary to suport RSSAC work.  This will be difficult
because of the root name server operators' well founded reluctance to
organise themselves formally.

So far my initial reactions.

Daniel


-----


Incomplete list of minor nits on the report:

The root name server operators *did* extensively consult the Internet
community on the introduction of anycast.  They did not consult ICANN
but kept ICANN well informed throughout using RSSAC as a vehicle.
Some of the consultations of the Internet community that I
was personally involved with are well documented in the proceedings of
the RIPE DNS WG.  We would not have gone ahead with introduction of
anycast for k.root-servers.net if the guidance from RIPE would have not
been in support.  Someone may well have said "they did not ask anyone"
but that does not reflect the facts.

I distincly recall that in its early days RSSAC did indeed consider the
number and placement of DNS root name servers.  At one point RSSAC
endorsed and analysis of the limitations of the DNS wire
format and.  If I recall correctly the analysis was done by ISC, but I
may be mistaken.  RSSAC also discussed the placement question.  I recall
vividly a presentation by kc claffy about the subject and her exasperation about the difficulty of coming up with rational placement recommendations
inside the pre-anycast set of constraints.  RSSAC may never
have made a recommendation on the subject since it was intractable initially and overtaken by anycast later. But RSSAC discussed it in public meetings.


One more nit from memory:

Somewhere it says that RSSAC did not communicate with the GAC.
I distincly remember briefing the GAC myself at least twice on the
substance of RSSAC business and others did so at other occastions;
certainly both Liman and our chair did at least once and I believe our
liaison did at least once, but I may be mistaken.  Sometimes these
briefings were combined with briefings I did as operator of
k.root-servers.net.  But I certainly referenced RSSAC discussions in
those briefings if only as a convenient means to avoid the appearance of
speaking for all root name server operators.  ;-) So de-jure maybe the
statement is true, but de-facto it is perpetuating a non-truth.


<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy