On Sep 6, 2016, at 8:45 PM, Shane Kerr <shane@time-travellers.org> wrote:
Andrew,
At 2016-09-06 20:42:07 +0000 Andrew Mcconachie <andrew.mcconachie@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-o...
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.
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