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 <[EMAIL PROTECTED]> >>>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:+358-50-4804586 >>>Nokia Siemens Networks Espoo, Finland >>> > >-- >Miguel A. Garcia tel:+358-50-4804586 >Nokia Siemens Networks Espoo, Finland > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
