Thank you Brian - another review that spotted important issues. Thanks all for taking care of this. I have placed a no-obj recommendation for the document in this week's telechat.
Jari On Nov 13, 2013, at 1:44 AM, Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > 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" <brian.e.carpen...@gmail.com> >> 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 > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art