[DNSOP] Comments on draft-rssac-dnsop-rfc2870bis-04.txt
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
Re: [DNSOP] Comments on draft-rssac-dnsop-rfc2870bis-04.txt
Hello Paul. First off, this is an RSSAC document so it is not clear why you think someone from the root opserator community should do the copy editing. 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). IETF tools complains when that text is removed. Will see if there is a clean way around it. 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. Going back to the document to see which parts you quoted and which were your suggested changes. Will fold in the intent of your suggestion. 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. or ... update the text to describe secure NTP - which is not uniformly used. or the use of local clocks. 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!) again, this is an RSSAC work product, not just root-operators. and the URL listed is not uniformly used by all operators. so will likely just leave it as RSSAC. That said, if URLs are accepted in author references (and I have to admit not seeing that used previously) then a link to the RSSAC page might be in order. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments on draft-rssac-dnsop-rfc2870bis-04.txt
On Feb 6, 2012, at 5:19 PM, bmann...@vacation.karoshi.com wrote: First off, this is an RSSAC document so it is not clear why you think someone from the root opserator community should do the copy editing. There is a large/complete overlap between the RSSAC and the root server operators. Many of the companies that operate root servers have staff doing many things, such as technical writing. Some have copy editors. The fact that ICANN has not done a copy edit pass on the document after five rounds says that maybe you should look to others. Waiting for ICANN to do this might be futile, given that it doesn't involve making policy. 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). IETF tools complains when that text is removed. Will see if there is a clean way around it. The tool might complain, but it should not prevent submission. You are now not using 2119 language, so you shouldn't need to put in the not-really-2119 preamble. 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. or ... update the text to describe secure NTP - which is not uniformly used. or the use of local clocks. You can't say can use NTP and in as secure manner as possible: they don't match. 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!) again, this is an RSSAC work product, not just root-operators. and the URL listed is not uniformly used by all operators. so will likely just leave it as RSSAC. That said, if URLs are accepted in author references (and I have to admit not seeing that used previously) then a link to the RSSAC page might be in order. You can use URLs in author references. However, the RSSAC web page is mostly worthless unless you like bureaucratic history. The root-servers.org page is useful. If you don't want to provide a useful URL, that's fine. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments on draft-rssac-dnsop-rfc2870bis-04.txt
On Mon, Feb 06, 2012 at 05:52:12PM -0500, Paul Hoffman wrote: On Feb 6, 2012, at 5:19 PM, bmann...@vacation.karoshi.com wrote: First off, this is an RSSAC document so it is not clear why you think someone from the root opserator community should do the copy editing. There is a large/complete overlap between the RSSAC and the root server operators. Many of the companies that operate root servers have staff doing many things, such as technical writing. Some have copy editors. The fact that ICANN has not done a copy edit pass on the document after five rounds says that maybe you should look to others. Waiting for ICANN to do this might be futile, given that it doesn't involve making policy. You are mistaken. while all root server operators are part of RSSAC, RSSAC is a much larger community with membership from all the RIRs, ISOC, Research Facilities, and Governments. I'll note that ISOC, through the IAB has a presence on RSSAC. Perhaps we could have ISOC provide copy editing? 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. or ... update the text to describe secure NTP - which is not uniformly used. or the use of local clocks. You can't say can use NTP and in as secure manner as possible: they don't match. then you recommend we strike SNTP from the document? There are ways to harden and NTP only system without going completely to a secured NTP (SNTP) system. And from my experience, if one takes proper precautions and prudent design choices one can deploy a resistant NTP strucuture without the crypto overhead on the SNTP datagrams or channels. So I am confident that we can, in fact, say with a straight face say that servers should use NTP or SNTP in as secure a mnner as practical/possible. Its being done. You can use URLs in author references. However, the RSSAC web page is mostly worthless unless you like bureaucratic history. The root-servers.org page is useful. If you don't want to provide a useful URL, that's fine. again, RSSAC is not just the root operators. If you want us to include a tangentially related URL, we could just as easily use www.ietf.org as www.root-servers.org in as far as the RSSAC represents either of those groups. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
