Someone might want to point this out to the IESG then, as that has not been my recent experience. Not even for structures or definition of elements - it was suggested that the use of the terms mandatory and optional (which I thought was quite precise when defining data elements) needed to be reworded using 2119 language. Perhaps, I should have pushed back, but I did not think it was worth the effort.
Mary. On Thu, Aug 11, 2011 at 7:50 PM, Scott O. Bradner <[email protected]> wrote: > fwiw - the author of 2119 thinks that less is more when it comes to the use > of these terms > > see, as Cullen points out, Section 6 > > but there is a balance - for example, if you define a structure and say > that all fields are required, it is redundant to > use MUST with each example of using the structure > > Scott > > On Aug 11, 2011, at 8:43 PM, Cullen Jennings wrote: > > > > > Thanks for the detailed review - you caught some good stuff. Most of this > makes essence but we should probably talk about usage of 2119 language. > > > > On Aug 9, 2011, at 16:05 , Mary Barnes wrote: > >> simple > >> ======================================================================= > >> > >> Document: draft-ietf-p2psip-base-17 > >> Reviewer: Mary Barnes > >> Review Date: 9 August 2011 > >> IETF LC End Date: 22 July 2011 > >> > >> Summary: Not Ready. > >> > >> Comments: > >> ---------------- > >> The document is very a dense (with detailed technical information) and > long (150 page) specification for a Peer-to-peer signaling protocol. While > the overall technical functionality seems fairly correct and thoroughly > specified, the primary issue is a tremendous lack of normative language in > the main body of the document. Non-inclusive details of such are included > below. > > > > The 2119 MUST/SHOULD/MAY terms are simply abbreviations for some words > defined in 2119, and different WGs have different styles about how > extensively they should be used. P2PSIP has obviously been on the more > sparing side of that spectrum. This isn't to say that there aren't any > places where it would be useful to add such language, but rather that our > policy has been to add it principally where there is likely ambiguity, > rather than everywhere where behavior is defined. I'll work thought these > and see where they might help reduce the chance of a an implementers doing > the wrong thing but in generally when we define a structure in something > like ASN.1 or ABNF, if the structure always has a field X, we just use the > language like ASN.1 or ABNF to indicate it always has that. We don't also > say it MUST be there. > > > > > > > > > >
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
