Greetings again. This looks much better than the -00, but still needs more effort.
The language in the text is still very rough (larger than "nits", not quite as bad as "confusing"). I believe that the amount of copy editing done by the RFC Editor depends on the stream through which you submit the document. If anyone in the root server operator community can spare <5 hours of an in-house copy editor, you should strongly consider it before turning the document in; otherwise, the AUTH48 comments will either be extensive enough to make finding newly-introduced mistakes difficult, or too few so as to make the document seem unprofessional (particularly when compared to RFC 2870). The paragraph at the end of section 1 (the "isn't really 2119 language" text) is quite cute and will cause you a world of pain and delay. You have de-capped everything, so remove the paragraph. (Unless you're just trying to make John Klensin even grumpier, which is also quite cute but will also cause you a world of pain and delay). The intro to section 3 says: The servers need both physical and protocol security as well as unambiguous authentication of their responses. Physical security focuses on the machines and their locations, Protocol security and response authentication are covered by Internet Protocol standards. However, there are three subsections, the middle being "network security". Further, much of the protocol security is covered by by transport layer security, not IP security. Proposed new wording: The servers need to be protected by physical and protocol security for their administration and communications. They also need to be protected by network security to reduce their vulnerability to attack. Physical security focuses on the machines and their locations, network security focuses on the way that the root servers are connected to the Internet, and protocol security focuses on administrative communication with the servers as well as integrity protection for the messages from the servers to the public. The text in 3.2.5 doesn't make sense. NTP can't be on the list if the operator is expected to get time updates "in as secure manner as possible". A proposed rewording would be to just remove that phrase because you describe what operationally is needed to use NTP in a non-crypto secure manner. Security Considerations are supposed to be just before references, so things are going to be reordered and renumbered by the RFC Editor unless you do it yourself sooner. Given the fact that you use sectional cross-references, doing this yourself is probably better than waiting for the RFC Editor to do it for you. Using numbers for reference instead of something useful is allowed and makes it hard to understand the document. Consider making the references more useful. For example, references 8, 9, and 10 are (soonesqe) going to be expanded to also include draft-ietf-dnsext-dnssec-bis and RFC 5011; this would be clearer if it was clear what you were referring to. For the author reference, consider adding the URL <http://www.root-servers.org/>, given that mail to the address listed will often be automatically lost. (Bonus points for updating that page to eliminate the decade-old presentations and just leave the news!) --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
