Re: [Gen-art] Gen-ART review of draft-ietf-ospf-rfc2370bis-02.txt

[Lou Berger <[e-mail]>]

Miguel,

I don't think there is any real vulnerability here as if a reader 
misinterprets the informative "must" as a "MUST" all they will do to 
implement is follow the specific MUST directives in the next section...

Thank you again for the comments,
Lou

At 02:12 AM 3/26/2008, Miguel Garcia wrote:
>Hi Lou:
>
>I am Ok with your answers. The only thing, in Section 3, about the 
>"must" and "must not"... If the intention is to have an informative 
>description, you may consider the usage of different words than 
>"must" and "must not", because people sometimes do not realize if 
>these are an oversight or not. I would suggest:
>                                                                  The
>     receiver always store a valid received Opaque LSA in its link-
>     state database.  The receiver does not accept Opaque LSAs that
>     violate the flooding scope (e.g., a type-11 (domain-wide) Opaque LSA
>
>/Miguel
>
>Lou Berger wrote:
>>Miguel,
>>         Thank you very much for the comments.  Please see in-line 
>> responses below.
>>At 04:51 PM 3/24/2008, Miguel Garcia wrote:
>>>I have been selected as the General Area Review Team (Gen-ART)
>>>reviewer for this draft (for background on Gen-ART, please see
>>>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>>
>>>Please wait for direction from your document shepherd
>>>or AD before posting a new version of the draft.
>>>
>>>Document: draft-ietf-ospf-rfc2370bis-02.txt
>>>Reviewer: Miguel Garcia <[e-mail]>
>>>Review Date: 2008-03-25
>>>IETF LC End Date: 2008-03-26
>>>
>>>Summary: The document is ready for publication as a proposed standard RFC.
>>>
>>>Comments:
>>>
>>>- Section 2.2. The document mentions an expired Internet-Draft 
>>>without a reference. Since this is not critical for the document, 
>>>and since this document is going to be published as an RFC, I 
>>>would suggest to delete the draft name, perhaps even the second 
>>>complete sentence.
>>Section 2.2 is an Acknowledgments section.  As such, it is 
>>legitimate for the authors to indicate the source of this 
>>work.  The draft name is not formally referenced intentionally, and 
>>is listed to represent a factual past event.
>>I recommend against any change to this section.
>>
>>>- Section 3, 7th paragraph says:
>>>
>>>                                                                 The
>>>    receiver must always store a valid received Opaque LSA in its link-
>>>    state database.  The receiver must not accept Opaque LSAs that
>>>    violate the flooding scope (e.g., a type-11 (domain-wide) Opaque LSA
>>>
>>>I think the "must" and "must not" should be normative (capitalized).
>>These paragraph is descriptive in a general fashion and 2119 
>>capitalization is not appropriate.  The corresponding prescriptive 
>>text is in section 3.1 and uses 2119 key words (capitalization).
>>No change should be made to this section.
>>
>>>- References [OSPF-MT] and [OSPFv3] do not list the version number 
>>>of the draft. Actually, OSPF-MT has been published as RFC 4915.
>>We can either update & reissue or have the RFC editor fix...
>>
>>>/Miguel
>>Much thanks again,
>>Lou
>>
>>
>>>--
>>>Miguel A. Garcia           tel:[phone]
>>>Nokia Siemens Networks     Espoo, Finland
>>>
>
>--
>Miguel A. Garcia           tel:[phone]
>Nokia Siemens Networks     Espoo, Finland
>
>

_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art