[rssac-caucus] FOR REVIEW: Elements of Potential Root Operators

[Wessels, Duane]

> On Sep 6, 2016, at 8:45 PM, Shane Kerr <shane at time-travellers.org> wrote:
> 
> Andrew,
> 
> At 2016-09-06 20:42:07 +0000
> Andrew Mcconachie <andrew.mcconachie at icann.org> wrote:
> 
>> The work party invites you to review this document and provide your
>> feedback by close of business 4 October 2016.
>> 
>> Feedback should be sent to the RSSAC Caucus list directly.
> 
> Interesting document. A bit strange but basically reasonable.
> 
> ----
> 
> One thing that I would like to see is a request that all of the
> information in this document be public. For example, descriptions of
> zone distribution architecture. As someone without access to this for
> current root server operators I have to infer this - I often don't
> know whether something is broken in the root server system or whether
> they are merely acting in ways that I didn't expect because I don't
> know what's going on "under the hood".
> 
> I realize that this may be out of scope for a technical requirements
> document, but on the other hand having details available for wider
> review can result in higher quality service, so I can possibly justify
> it in a hand-waving way. ;)

Shane,

This feels to me out of scope, but I want to make sure I understand
your suggestion.  Are you suggesting that the information provided
by a candidate operator should be made public during the evaluation
process, or afterwards?  Responses from all candidates would be made
public, or just the ones actually chosen?

Again I think its out of scope but if you can provide text that fits
within the scope of this document perhaps it can be included.



> 
> ----
> 
> One minor point about addressing:
> 
>    3.3.3 Addressing Resources
> 
>    The candidate operator MUST have its own AS number(s) and IPv4 and
>    IPv6 address allocations. It is assumed that IP anycast will be
>    used. If IP anycast will not be used, a technology providing
>    similar or better service levels SHOULD be specified. Provider
>    address space or addresses that cannot be used with anycast are
>    undesirable. The expected production IPv4 and IPv6 address blocks
>    MUST be severable from the candidate’s organization to facilitate
>    emergency or planned transfers.
> 
> Some RIRs have policies to allocate addresses for "critical use":
> 
> https://www.nro.net/rir-comparative-policy-overview/rir-comparative-policy-overview-2016-02#2-4-2
> 
> This means that potential root server operators probably do not need to
> have address space in advance of being approved for being a root server
> operator.

I'm not sure the current text is in contradiction with the idea that an
org can get root service address space later.  Could you please suggest
additions or edits if you feel they are necessary?

If I put myself in the place of the (not yet existing) committee that would
evaluate a potential operator, I would very much like to know if said
operator already has the addressing resources, or says they'll figure out
how to get them later if chosen.


> 
> ----
> 
> In the section on diversity (3.4), I am a little confused. The
> introduction states:
> 
>    Diversity _within_ a given operator is of benefit, but the candidate
>    will also be evaluated in terms of increased diversity among operators.
> 
> But within each sub-section it is not at all clear which are intended
> to apply for a specific operator and which are intended to be used to
> analyze the root server system as a whole.

In working on this document we spend a lot of time finding the fine line
between specifying what the elements are and saying how they should be
applied.

For some of these sub-sections I think the advice is pretty clear.  For
example, geographic diversity: "Ideally, the candidate operator will provide
service in regions not already well-served by other root operators." Or
human diversity: "The candidate operator SHOULD demonstrate or document
that it does not rely on any single individual for technical operations."
For other sub-sections there is no "SHOULD" for the candidate operator and
these can be taken to apply to the system as a whole.

> 
> My concern is that this will naturally lead to "diversity inflation"
> where each root server operator runs multiple versions of everything
> without any real benefit, and in fact a potential reduction in
> reliability of the overall system. (For example, if many root servers
> run a given DNS software to maximize diversity and there is an
> unpublished exploit, then it is possible that more root servers are
> compromised rather than fewer.)
> 
> Nit: Unbound is a recursive resolver and would be unlikely to be run by
> a root server operator. :)

Yeah, thanks, we'll fix that.

> 
> ----
> 
> Nit: "triannual" is easily confused with "triennial", so probably it
> should just be stated that the root server operator meetings are three
> times a year.
> 
> https://en.wiktionary.org/wiki/triannual#Usage_notes

My personal feeling is that we should not be afraid to use these terms correctly.  It
brings a smile to my face imagining a candidate operator was selected, believing that
root operators meet only once every 3 years, later learning its really 3 times per year,
and then changing their mind.

DW



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20160908/fa532d41/signature.asc>