Hi Bill, On 2012-02-06, at 14:12, <bmann...@vacation.karoshi.com> <bmann...@vacation.karoshi.com> wrote:
> Thanks to Warren, Ed, John D., David C. and Kato-san for their > comments/corrections. > Any more? I see you added some text based on our conversation in sunny Christchurch, thanks for that. As promised, here's a summary of that conversation for the list(s). I think the document requires some substantial copy-editing. I've avoided producing a list of spelling and grammar nits, since I think the clean-up would be easier to do as a single pass through rather than by correcting individual words and sentences. Substantive comments relating only to content follow. 1. Despite the definition of "server" in section 1, there are numerous examples of text in following sections that use the word server in its original 2870 sense (i.e. with an implication that we're talking about individual, discrete servers) despite the fact that architecture has moved on in the real root server system since then. I recommend re-casting the whole document to talk about the DNS service provided by root server operators as a service, and focussing on the way that service is delivered rather than how "servers" are operated. 2. I think this document should aim to provide recommendations and/or document best current practice, rather than declaring that it provides requirements. There is little or no contractual relationship between the organisations that manage the root zone and the root server operators that serve it, and setting requirements that by definition have no teeth seems out of sync with reality. Providing recommendations that root server operators can confirm that they follow seems entirely reasonable, however. Related, I don't understand why there is 2119 normative language in this document. 3. In many places I find the "requirements" far too detailed; in my view they impose specific architectural and operational choices on root server operators when diversity in the root server system is desirable, and more obviously achieved by a diversity of such choices. I think this document should limit itself to carefully specifying the service being provided, and the desired performance characteristics of that service. For example, specifying that TSIG be used to secure zone transfers is ill-advised, I think (I know that TSIG is used today). Specifying rather that new root zone serials be authenticated and made available promptly (and defining what promptly means) across each deployed root server service seems better. The former is an implementation detail of the service as a whole; the latter restricts the concern to what we actually care about, that changes propagate swiftly and that unauthenticated updates never make it to the query-answering edge. I would like to see this document specify key performance indicators and specify corresponding ranges of values that represent adequate service. I would also like to see a recommendation that root server operators commit to publish data corresponding to those KPIs, so that the community can gain confidence that the root server system as a whole is performing adequately. I guess I'm talking about something like a Service Level Agreement (although perhaps Service Level Commitment would be better language, given the lack of contractual relationships). 4. When it comes to security, different security policies would seem to fit different deployment approaches. I think it's better to specify that individual root server operators publish their security policy, and that this document should outline what that security policy should contain. I don't think it's useful to attempt to define a security policy that fits all deployed infrastructure. In summary, I think the document should be substantially reorganised. This makes it difficult to provide a meaningful line-by-line critique. However, I am very happy to put my money where my mouth is and copy-edit/reorganise along the lines I'm thinking if that seems like a useful way to explain myself. I don't think the -04 draft, even with copy-editing, is useful to publish as-is. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
