Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-ospf-rfc6506bis-01.txt

From: Jari Arkko <[email-masked]>
Date: Tue, 3 Dec 2013 08:08:25 +0200

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 <[email-masked]> 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" <[email-masked]>
>> 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-masked]
> https://www.ietf.org/mailman/listinfo/gen-art