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 <sob(_at_)harvard(_dot_)edu>
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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf