Thanks Acee. I will update the review when this comes up on the IESG agenda.
Brian On 13/11/2013 10:03, Acee Lindem wrote: > Hi Brian, > Thanks much for the review. I believe I've added all your comments - see > inline. > > On 11/12/13 11:16 AM, "Brian E Carpenter" <[email protected]> > wrote: > >> [Resending again with abject apologies for a typo in the To address.] >> >> [Resending with CC to the IETF list, since the ospf WG list >> automatically rejects non-subscriber messages.] >> >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> Please resolve these comments along with any other Last Call comments >> you may receive. >> >> Document: draft-ietf-ospf-rfc6506bis-01.txt >> Reviewer: Brian Carpenter >> Review Date: 2013-11-12 >> IETF LC End Date: 2013-11-26 >> IESG Telechat date: >> >> Summary: Ready with issues >> -------- >> >> Major issue: >> ------------ >> >> The listed changes from RFC 6506 include: >> >>> 2. Section 3 previously advocated usage of an expired key for >>> transmitted OSPFv3 packets when no valid keys existed. This >>> statement has been removed. >> I cannot see where this has been removed. In the last paragraph of >> Section 3, the text starting: >> >>> In the event that the last key associated with an interface expires,... >> has not been changed. Isn't that the text that should be removed? In fact, >> shouldn't it be explicitly contradicted, to ensure that implementations >> are changed to fail-secure rather than run-insecure? > > Sigh - good catch. We actually discussed the text on the list but I > neglected to update it in the final revision. This is how the paragraph > will read in the next revision. > > Key storage SHOULD persist across a system restart, warm or cold, to > avoid operational issues. In the event that the last key associated > with an interface expires, the network operator SHOULD be notified > and the OSPFv3 packet MUST NOT be transmitted unauthenticated. > > > > > > > > > >> >> Nits: >> ----- >> >> "errata" is a plural, often misused in this draft as a singular. The >> singular >> noun is "erratum". > > I replaced the 3 instances of "errata" with "erratum" in section 1.2. In > the acknowledgements, the instances of "errata" were correct. > > >> >>> This document may contain material from IETF Documents or IETF >>> Contributions published or made publicly available before November >>> 10, 2008. The person(s) controlling the copyright in some of this >> ... >> >> This disclaimer logically cannot be needed, since RFC6506 was published >> after Nov. 10, 2008. > > I've removed this by updating the xml ipr tag to simply "trust200902". > > >> >> >>> 6. Security Considerations >> ... >>> It addresses all the security >>> issues that have been identified in [RFC6039]. >> and in [RFC6506] (judging by section 1.2). > > Added the reference to RFC 6506. > > Thanks, > Acee > > > > >> > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
