[rfc-i] Review of: draft-peterson-informational-normativity-01

[jon.peterson at neustar.biz (Peterson, Jon)]

I appreciate the detailed feedback, though I would have warned that I'm
not sure line-by-line wordsmithing is warranted when this was a trial
balloon to gauge interest.

In the review below, there are a couple points I thought were worth
discussing, though. One is the thing I called "normative pseudo-keywords"
in the draft. Whether or not that is the most felicitous construction, I
do think that text in our specifications that mandates implementation
behavior without using RFC2119 language is an important component of the
question I was trying to raise - arguably as important as cases when
RFC2119 language is used without an intent to constrain implementation
behavior. When you review IETF specifications, you may see language like:

"Clients MUST set the fourth bit to 'yes' in this case."


or:


"Clients must set the fourth bit to 'yes' in this case." [lower-case
"must" is one of my "pseudo-keywords"]

or:


"Clients set the fourth bit to 'yes' in this case."

Now, if interoperability can only be achieved if the client sets the
fourth bit to "yes," then as a reviewer seeing the second formulation
above, you might well ask "is this 'must' supposed to be a 'MUST.'"
Whether or not a reviewer should raise similar concerns about the third
construction is a further question. Exploring these alternatives, and what
we think they mean, and why spec authors should use (and reviewers should
allow) one as opposed to others, is part of scope I was trying to address
with the document - so I wanted a term for that second case, yes. I don't
think this complicates the document any more than necessary, as
understanding when not to use normative keywords is just as important as
understanding when to use them.

The second point is whether the document status of a target document is
irrelevant to whether or not a specification lists that target document in
the Normative or Informational References section. Strictly speaking, the
target's status is immediately relevant if specifications can be prevented
from advancing on the standards track (including to PS) due to the status
of a normative reference. Do we review specs to ascertain whether or not a
target document should be listed as Informational or Normative, and if so,
how do we do it? Now do bear in mind that I submitted the -00 of this
document the same month that RFC4897 was published, that this was way
before RFC6410, and that all this text would need to be revisited to take
into account the course of events since. But I do maintain this is an
important question about how we author and review IETF specifications.

Jon Peterson
Neustar, Inc.

On 8/28/14, 11:45 AM, "Dave Crocker" <dhc at dcrocker.net> wrote:

>
>Review of:    Normative Language and References
>I-D:          draft-peterson-informational-normativity-01
>
>Review by:    D. Crocker
>Review date:  28 Aug 2014
>
>
>
>Summary:
>
>The document seeks to explore the proper and improper uses of RFC2119
>vocabulary.  Since there is continuing debate about the usage and since
>the usage often is problematic, a document of this sort could be very
>helpful.  Pursuing it at this time is a worthy exercise.
>
>The document definitely needs the fresh consideration now being
>contemplated, and it needs substantial revision.
>
>The document confuses document status with document substance and that
>normative vocabulary is relevant to the latter, not the former.
>
>In general, the document will benefit from an editorial pass to simplify
>its language.
>
>
>
>
>Detailed Comments:
>
>{ full document retained, to aid context. /d }
>
>
>> Abstract
>> 
>>    This document explores the use of normative language and references
>>    with a focus on reducing unnecessary normative references in IETF
>>    specifications.
>
>That's a particularly negative focus.  While possibly justified, I'd
>hope the document has a broader and more constructive goal.
>
>Perhaps:
>
>   Normative language works best when applied to specific technical
>protocol and format details or to specific operational practices.
>However it is sometimes used for other circumstances, such as guidance
>to programmers.  This document discusses different uses of normative
>language, with a focus on encouraging its use narrowly only for
>technical and operations details.
>
>
>
>
>> 1.  Introduction
>> 
>>    RFC2119 [1] provides a set of familiar directives to readers of IETF
>>    specifications, specifically the imperatives: "MUST", "MUST NOT",
>>    "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
>>    "RECOMMENDED", "MAY", and "OPTIONAL".  This set of normative
>>    keywords, as they shall be known in this document, consists of a
>
>    This set...this document, consists of
>    ->
>    These are termed 'normative' keywords and consist of
>
>
>>    number of grammatical variations which ultimately describe three
>>    degrees of normative compliance: mandatory, recommended, and
>
>  delete [normative].
>
>It's not needed here; there really isn't any other 'compliance' the
>reader will confuse things with.
>
>
>>    optional.  The first two degrees may be used in either prescriptive
>>    or proscriptive contexts (e.g.  "MUST" and "MUST NOT", "SHOULD" and
>>    "SHOULD NOT"), while for the third only prescriptive statements are
>>    permitted (there is a "MAY" but no "MAY NOT", something can be
>>    "OPTIONAL", but not "NOT OPTIONAL").
>> 
>>    The use of normative keywords is one of the defining characteristics
>
>Really?  Well, actually for /any/ specification, and hardly distinctive
>to the IETF.
>
>
>>    of IETF specifications.  Normative keywords remain an indispensable
>>    tool for evaluating interoperability as specifications advance on the
>>    standards track, and moreover for pruning unimplemented features as
>
>This sentence is interesting and important.
>
>The assertions should be followed by some elaboration about their basis;
>many readers will not automatically understand that basis nor the
>importance of what's just been said.
>
>
>>    protocols mature through deployment and usage.  The application of
>>    normative keywords to these functions is predicated largely on the
>>    text of RFC2026 [2].
>
>Small editorial suggestion: Since this is a discussion of such basic
>issues, extra attention to its pedagogy could be helpful:  Use RFC
>titles and put the rfc number into the citation.  For example:
>
>   text of The Internet Standards Process [RFC2026].
>
>It saves the less-informed readers an indirection to find out what the
>cited document is about.  That's not a small benefit, relative to the
>larger audience.
>
>
>> 
>>    RFC2119 does not, however, contain the word 'normative', and nor does
>
>However there now are some formal references in other IETF documents:
>
>   IESG Statement: Normative and Informative References
>   https://www.ietf.org/iesg/statement/normative-informative.html
>
>   Handling Normative References to Standards-Track Documents
>   http://tools.ietf.org/html/rfc4897
>
>   Normative References to RFC 2119
>   https://www.rfc-editor.org/policy.html#policy.2119ref
>
>
>>    RFC2026.  The idea that a statement or reference can be 'normative'
>>    or 'informational' (let alone the requirement that the References
>>    section of an Internet-Draft be divided between the two) dates from a
>>    much later time, as does the term 'normative language'.  The
>
>This seems to be caught up in the word normative rather than the concept
>it represents.
>
>The word is useful, but whether the word was used or not doesn't seem
>all that important to me.  On the other hand, careful vs. sloppy use of
>RFC2119 reserved words does.
>
>I suggest ignoring any discussion of the history of use of the word
>normative, instead focusing on the use of RFC2119 vocabulary.
>
>Indeed that's nicely the direction the text goes, getting into the
>varying uses of 2119 vocabulary and the benefits and problems of such
>usage.
>
>
>>    conditions that render a particular reference or statement
>>    'normative' have never been specified; although there is a good
>>    understanding in the community of the common distinctions, practices
>>    can be very erratic in corner-cases.
>> 
>>    An example of the resulting confusion is the use of normative
>>    keywords in requirements documents, which here are to be understood
>>    as Informational documents that apply constraints to future protocol
>>    specification work, as opposed to actual implementation work.
>
>It's worth noting the irony of the word 'requirements' for documents
>that are mostly guidance rather than real requirements.
>
>
>>    Authors of standards-track protocol specifications intended to
>>    satisfy these requirements sometimes include such requirements
>>    documents in their "Normative References" sections, precisely because
>>    they are referring to statements containing normative keywords.  This
>>    sort of downward reference is of course formally prohibited in
>
>How is that a downward reference?  An Informational doc referring to a
>Standards Track document?
>
>
>>    RFC2026, and thus must corrected, but the whole situation arises
>>    needlessly.  In the absence of some clarification, similar
>>    misconceptions will continue to arise.
>
>I'm not understanding what the misconception is.
>
>
>>    This document therefore attempts to provide a stronger account of the
>>    classification designated by the term 'normative', and to detail
>> 
>> 
>> 
>> Peterson                  Expires May 11, 2008                  [Page 3]
>> ?
>> Internet-Draft                 Normativity                 November 2007
>> 
>> 
>>    various conditions under which a reference need not be considered
>
>Replace sentence with:
>
>   This document clarifies use of normative vocabulary, including
>guidance for situations in which is should not be used.
>
>
>>    'normative'.  RFC3967 [3] wisely notes that normative references
>
>'wisely' is gratuitous and a bit odd; adulation is really out of place
>for most RFCs...
>
>
>>    resist definition, and the text in this memo does not claim to have
>
>It is not really the 'definition' of 'normative references' that is at
>issue.  It is when to make a reference or a portion of specification
>normative.
>
>RFC2119 and the current practice of distinguishing RFC citations between
>normative and non-normative leave no ambiguity about what is defined to
>be normative.
>
>The question is about the boundary for asserting that something is
>normative.
>
>
>>    articulated all of the associated subtleties and implications;
>>    however, in order to reduce overuse and misapplication of normative
>>    terms, a more substantive account of the term 'normative' appears
>>    here than has in RFC3967 or previous works.
>> 
>>    RFC3967 and more recently RFC4897 [4] have revised the guidance of
>>    RFC2026 regarding the advancement of standards-track documents which
>>    refer to documents at a lower maturity level (or those not on the
>>    standards track at all).  The present document is entirely compatible
>>    with the useful amendments introduced in those documents.
>> 
>> 
>> 2.  What is 'normative'?
>> 
>>    Normative keywords are 'normative' in so far as they establish the
>>    norms that are the foundation of interoperability.
>
>Using the word 'norm' 3 times in a sentence isn't very helpful.  Besides
>that, the word 'norm' has a somewhat different meaning than normative,
>as odd as that may seem, and tends towards merely statistical
>characterization, rather than the one of conformance needed here.
>
>Perhaps:
>
>   Normative keywords make explicit what is required, helpful, or
>ancillary to interoperability, and what works against it.
>
>
>>   Implementations
>>    of a particular specification can be considered to be a sort of
>>    community, and that community has practices that are mandatory and
>>    prohibited, recommended and counterrecommended, or simply optional -
>>    hence, they are norms.
>
>'Community' is an interesting word here.  And use of the word 'norm'
>seems to demonstrate the problem with including it in this discussion.
>This really isn't about community norms, in the social sense.  It is
>about technical mandates.
>
>Perhaps:
>
>   Internet specifications define an environment for achieving some set
>of functionality among (potentially) independent participants.  If a
>participants seeks interoperability, then the normative terms in
>specifications define the requirements for achieving it.
>
>(More loosely:  the specs define a sandbox; if you want to play in that
>sandbox, you have to conform to the rules of the specs.)
>
>
>>    'Normative language' or 'normative statements' are, broadly, passages
>>    of text in IETF documents which contain normative keywords that
>
>   'Normative language'...that direct implementers
>   ->
>   Normative language in specifications direct implementers
>
>
>>    direct implementers, with varying degrees of stringency, to
>>    incorporate particular features in order to foster interoperability.
>
>   foster -> achieve
>
>(it's not 'promoting' development or growth.)
>
>
>>    Normative language, as originally described in RFC2119, is tooled
>>    solely to describe how implementations are intended to behave.  As
>
>   how implementations are intended to behave
>   ->
>   how implementations must behave if they are to interoperate.
>
>
>>    RFC2119 Section 6 states, in reference to normative keywords:
>> 
>>      In particular, they MUST only be used where it is
>>      actually required for interoperation or to limit behavior which has
>>      potential for causing harm (e.g., limiting retransmissions)
>> 
>>    Ironically, this normative statement is not internally consistent.
>>    It urges authors of specifications to use normative keywords only in
>>    reference to matters of implementation, but in order to amplify its
>>    point from mere urging to absolute dictum, it relies on a normative
>>    keyword.  Therein lies the source of the confusion.  Normative
>>    keywords are used commonly, but incorrectly, in precisely this
>>    fashion: for emphasis, in passages of descriptive text that in no way
>>    could be construed to address implementations.
>
>I suspect it's worth physically highlighting the above last sentence,
>since it seems to me to be the essential concern.  If a reader sees only
>that sentence, they will probably glean the most important substance of
>the document.
>
>
>>    When authors of subsequent specifications see such normative keywords
>>    used in an purely descriptive passage in an RFC, they may assume that
>
>   may -> might
>
>(probably worth now noting: Non-Normative Synonyms in RFCs,
>draft-hansen-nonkeywords-non2119-02, possibly in the next section? --
>and we're going to pursue getting it published.)
>
>
>> 
>> 
>> 
>> Peterson                  Expires May 11, 2008                  [Page 4]
>> ?
>> Internet-Draft                 Normativity                 November 2007
>> 
>> 
>>    the document containing those normative keywords should be referenced
>>    normatively.  This can cause an unnecessary apparent need for a
>>    downward reference.
>> 
>>    Any statement that is non-normative is by definition purely
>>    informational.  Informational or descriptive statements play a large
>>    role in IETF documents, providing context that is useful to
>>    implementers or authors of future specifications but which does not,
>>    strictly speaking, detail implementation behavior that will
>>    subsequently be measured for compliance or interoperability.
>> 
>> 2.1.  Normative Pseudo-Keywords
>> 
>>    The use of the normative keywords has never been compulsory in the
>>    IETF.  Numerous documents, both before and after the publication of
>>    RFC2119, describe protocol behavior without relying on normative
>>    keywords.  Normative keywords are a way of explicitly designating the
>>    degree of compliance associated with a behavioral prescription for
>
>hmmm.  'degree of compliance' might be misleading, since it draws one to
>thoughts of percentages. And "compliance associated with a behavior
>prescription" certainly seems to exacerbate that possibility.
>
>Perhaps:
>
>   Normative keywords provide clear markings for what compliance is
>needed and what flexibilities are allowed.
>
>
>
>>    implementations.  It is equally possible, and sometimes more
>>    readable, to write precise text which is semantically identical to
>>    passages employing normative keywords.
>
>Huh?
>
>
>>         Constructions with that
>>    property are herein said to contain "normative pseudo-keywords":
>>    prescriptive behavioral keywords that could potentially be
>>    paraphrased with normative keywords.
>
>oh boy.  this seems an unfortunate line of commentary.
>
>
>>From later text here, it appears this is meant to discuss problematic
>usage.  I suggest leading with that, while avoiding introducing new
>terminology that isn't needed.
>
>Perhaps:
>
>   Some text has a style of directing normative behavior, without
>needing to use reserved vocabulary.
>
>
>
>But mostly I'm confused about the nature and purpose of this passage.
>It seems to be attempting to codify uses of normative language in
>non-normative text.  Adding a term like 'pseudo-keyword' just makes
>things more confusing.
>
>Once the nature and purpose of this section is clarified, and the
>language made simpler and more direct, it will be possible to comment on
>it further...
>
>
>
>>    In order for such a piece of text to qualify as normative, it must
>>    contain pseudo-keyword text which designates the degree of compliance
>>    levied on the behavior (i.e. terms that recognizably signify
>>    'mandatory', 'recommended', or 'optional)'.  Furthermore, following
>>    the definition of the RFC2119 keywords, these statements must pertain
>>    to implementation behavior.  Statements can be tested by paraphrase;
>>    for example:
>> 
>>      Messages are challenged using Digest authentication [RFC2617].
>> 
>>    The passage above uses a normative pseudo-keyword (in this case, the
>>    verb 'to be') which can be paraphrased using a normative keyword as
>>    follows:
>> 
>>      Messages MUST be challenged using Digest authentication [RFC2617].
>> 
>>    However, it is equally possible to generate behavioral statements
>>    which do not satisfy this test, for example:
>> 
>>      Messages might be challenged using Digest authentication [RFC2617]
>>      when a weaker form of authentication would be inappropriate.
>> 
>>    Is this a recommendation, a counterrecommendation, or what?  Without
>> 
>> 
>> 
>> Peterson                  Expires May 11, 2008                  [Page 5]
>> ?
>> Internet-Draft                 Normativity                 November 2007
>> 
>> 
>>    sufficient supporting text to suggest when weaker forms of
>>    authentication might be appropriate, one could even read this as a
>>    mandate for the use of Digest.  In the absence of a recognizable
>>    degree of compliance, this statement cannot be normative.  In the
>>    interests of promoting interoperability it would ideally be replaced
>>    with a clearer sentence containing a normative keyword.
>> 
>>    The use of pseudo-keywords to form normative statements is never
>>    completely unambiguous, and is therefore discouraged.  It is not at
>>    all uncommon today for reviewers, at the IESG review phase or
>>    earlier, to provide blocking comments on Internet-Drafts of the form
>>    "is this 'must' supposed to be a 'MUST'?"  The use of normative
>>    keywords, since they have accepted definitions within the community,
>>    are the most precise way of designating a degree of compliance.  That
>>    much said, authors of specifications must also recognize that
>>    normative keywords are not a panacea, and that gibberish can be
>>    written just as easily with uppercase words as with lowercase.  Some
>>    examples of this are given in Section 3.1.
>> 
>>    However, for the purposes of normative references and the evaluation
>>    of features and options, passages containing normative pseudo-
>>    keywords are treated as equivalent to passages containing normative
>>    keywords.  Without this allowance, it would be impossible for new
>>    documents to refer normatively to many, if not most, existing RFCs.
>>    It is the semantics, not the syntax, of statements that is crucial to
>>    determining their normative status.
>> 
>> 
>> 3.  Normative references
>> 
>>    This document follows the terminology of RFC4897 for a 'source
>>    document' (a document in which the reference to another document in
>>    embedded) and a 'target document' (the document so referenced).  It
>
>The first sentence can be simpler:
>
>    As defined in "Normative References" [RFC4897", a "source document"
>contains a reference and a "target document" is what is referenced.
>
>
>>    furthermore defines the 'referencing statement' as the statement in
>>    the source document which invokes the reference to the target
>
>I don't find that definition in the RFC.
>
>So just define it:
>
>   A 'referencing statement' is the text containing a reference.
>
>
>>    document.  A 'normative statement' is understood to be a statement
>
>delete [understood to be].  entirely gratuitous.
>
>
>>    which uses normative keywords (or pseudo-keywords) to associate a
>
>And /please/ drop this stuff about 'pseudo-keywords'.  Keep the document
>simple.
>
>
>>    specific degree of normative compliance with a particular
>>    implementation behavior.
>> 
>>    For the benefit of specification authors, the following is a list of
>
>You mean it doesn't have any benefit for other readers?
>
>I suggest dropping the initial clause.
>
>
>>    conditions in which a reference to a document need not be normative:
>>    1.  if the source document is itself Informational (not a standards-
>>        track document, BCP or an Experimental document).
>
>Bad advice.  If the source document is a specification, normative
>language is appropriate and close to obligatory.
>
>
>>    2.  if the referencing statement is not a normative statement; i.e.,
>>        does not prescribes some degree of normative compliance with the
>>        target document.
>> 
>> 
>> 
>> 
>> Peterson                  Expires May 11, 2008                  [Page 6]
>> ?
>> Internet-Draft                 Normativity                 November 2007
>> 
>> 
>>    3.  if the target document, and in particular any subset scope
>>        designated by the referencing statement (a section, or what have
>>        you), contains no normative statements.
>
>What does 'subset scope' mean?
>
>
>>    If any of the above conditions apply, then the reference in question
>>    need not be normative.  One additional possible condition, that the
>
>I think the problem is with casting this in terms of 'need' rather than
>'benefit' or 'reasonable':
>
>     Normative language is appropriate to details of protocol behavior
>or operational practice using protocols.  Its use for advice about other
>matters is typically problematic.
>
>
>>    target document have an equal or greater standards maturity level to
>>    the source document, is not strictly speaking a necessary condition
>
>In fact it is irrelevant.  "Not strictly speaking" classes it as
>possibly relevant and it /never/ is, for this topic.
>
>
>>    for a normative reference; however, normative references made when
>>    this condition prevails must successfully invoke the downref
>>    exception procedures defined in RFC3976 in order to advance on the
>>    IETF standards-track.
>> 
>>    One source of ambiguity in determining whether or not a reference is
>>    normative is the status of Best Current Practices (BCPs, as defined
>
>This line of thinking seems a mistake.  First, whether a reference is
>normative or not is determined by the document making the reference.
>Second the appropriateness of choosing to make it normative is
>determined by the substance of the referencing and referencing
>documents, not the status of either.
>
>
>>    in Section 5 of RFC2026).  The BCP designation is a bit of a catch-
>>    all in the IETF standards process.  A BCP can prescribe practices
>>    varying from operations, which are indeed critical to the
>>    interoperability of the Internet, to IETF process, which is of a non-
>>    technical nature.  As such, it is entirely appropriate, in some
>>    cases, to provide a normative reference to a BCP, and for a BCP to
>>    contain normative keywords.
>> 
>>    In the case of IETF process BCPs, it is less clear that they should
>>    be understood normatively, and moreover less clear that it is
>>    appropriate for process documents to employ normative keywords.  A
>>    precedent for using normative language in those documents was set by
>>    RFC2418 [5] (see especially the last paragraph of Section 1; this is
>>    also discussed further below in Section 4).  When process documents
>>    do employ normative keywords, as RFC2119 does in the citation above,
>>    it is almost always inconsistent with the definition of those terms
>>    in RFC2119 and their intended use in RFC2026.  This in turn further
>>    contributes to the perception that it is appropriate for non-
>>    technical documents in general (such as requirements documents) to
>>    employ normative keywords.  Unfortunately, this appropriateness of
>>    using normative language in BCPs must be assessed on a case-by-case
>>    basis.
>> 
>>    A good rule of thumb, and a corollary of the guidance in RFC3967, for
>>    whether a reference should be normative or not is the following: if
>>    the target document were lost, such that an implementer could not
>>    read, access or implement it, would implementations of the source
>>    document still interoperate for the functionality described in the
>>    statement?  If not, then the reference must be normative.
>
>  must -> needs to be
>
>but generally, yes, a good heuristic.
>
>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Peterson                  Expires May 11, 2008                  [Page 7]
>> ?
>> Internet-Draft                 Normativity                 November 2007
>> 
>> 
>> 3.1.  Examples and Ambiguities
>
>In the aggregate, this section is interesting and will be helpful.  At
>the least it should engender some debates about the examples and about
>boundary conditions for what is or is not a legitimate normative
>reference.
>'
>
>>    Even so strict an account of a normative reference cannot be entirely
>>    free from ambiguities that are grounded in the degrees of compliance
>>    themselves, especially regarding conditionals and conditional
>>    prohibitions (e.g.  "SHOULD NOT").  Ambiguities also arise when
>
>I probably haven't parsed this sentence properly, even after several
>tries.
>
>'so strict' as what?  what is this sentence referencing?
>
>'grounded in the degrees of compliance' is an example of why this
>sentence needs to be greatly simplified.
>
>
>>    degrees of compliance are associated with the use of a feature rather
>>    than its implementation.  Consider the following referencing
>>    statement:
>> 
>>      Implementations SHOULD NOT use 3DES [1].
>> 
>>    If this had said that implementations "MUST NOT" use 3DES, it would
>>    be unambiguous that implementations were not required to implement
>>    3DES, and thus the reference to 3DES would not be normative.  You
>
>Wow.  That's seems like bizarre logic.  The referenced spec is essential
>in order for the reader to know what not to do.
>
>In any event, the text here is treating "SHOULD" as somehow less
>normative than "MUST", which is not correct.  "SHOULD" means that the
>statement is asserting a requirement, but allowing for it to be relaxed
>iff the implementer/operator is highly knowledgeable about conditions
>that make it acceptable to relax the requirement.
>
>
>>    would never need to implement 3DES in order to be able to
>>    interoperate with another implementation of this specification.  But
>>    what about the conditional prohibition "SHOULD NOT use 3DES"?  Is it
>>    necessary to support a referenced specification in order to obey a
>>    conditional prohibition against using it?  This is difficult to
>>    answer on its own, but in fact, that referencing statement entails
>>    this one:
>> 
>>      Implementations MAY use 3DES [1].
>> 
>>    Should 3DES be considered a Normative or Informational reference if
>>    it is OPTIONAL?  Normative, clearly, by the litmus test.  Both this
>>    statement and the one above allow, but do not require,
>>    implementations to support 3DES.  And because this statement is
>>    entailed by the conditional prohibition above, both of these are
>>    making a normative reference to 3DES.  This may appear to be
>>    something of a paradox, since it seems intuitively that
>>    counterrecommended behavior shouldn't require a normative reference,
>>    but optional behavior should - one just needs to bear in mind that
>>    everything counterrecommended is necessarily optional.
>> 
>>    Given all that, better specmanship would make the exact
>
>   specmanship  -> specification writing
>
>
>>    implementation needs more clear.  A closely analogous but infinitely
>>    superior phrasing would be:
>> 
>>      While 3DES [1] is unsuitable for use in most environments,
>>      for backwards compatibility reasons implementations MUST
>>      support it.
>> 
>>    In this case it is clear that support for the 3DES protocol is
>>    mandatory, even though its use is discouraged (non-normatively).
>> 
>>    There are also classes of statements that employ normative keywords,
>> 
>> 
>> 
>> Peterson                  Expires May 11, 2008                  [Page 8]
>> ?
>> Internet-Draft                 Normativity                 November 2007
>> 
>> 
>>    and contains references, but do so in a way that does not actual form
>>    a normative referencing statement.  Consider this:
>> 
>>      The application MUST implement an underlying transport which
>>      can provide integrity and confidentiality properties, for
>>      example TLS [3].
>> 
>>    The citation of TLS above is merely exemplary; the referencing
>>    statement does not actually require application developers to
>>    implement TLS.  Rather, it requires that any underlying transport
>>    that is implemented have certain properties, though not terribly
>>    specific ones.  As such, this reference cannot be considered
>>    normative - it suggests no specific underlying transport to the
>>    implementation community.  Precisely for this reason, it is an
>>    example of weak specmanship.  Statements of this general form often
>>    seem attractive, however, to specification authors who hope to
>>    reference work-in-progress or Informational documents.  The fix for
>>    this sort of specmanship is not to require TLS to appear in the
>>    Normative references section of the document (it shouldn't on the
>>    strength of this statement), but rather to encourage the authors to
>>    make a stronger referencing statement, one actually conducive to
>>    establishing implementation norms.
>> 
>>    Another similar example is the use of disjunctive references like the
>>    following:
>> 
>>      Implementations MUST provide this capability by implementing
>>      either PGP [4] or S/MIME [6].
>> 
>>    Is this a normative reference to both PGP and S/MIME, or neither?  It
>
>dis- vs. con- is a distraction.
>
>"MUST implement foo" makes a citation to foo normative.  If foo is a
>list of any sort, all of its components are normative.
>
>
>>    seems to read that implementers would only need to implement one in
>>    order to be compliant, so perhaps only one of them is actually a
>>    normative reference... but if so, which one?  Ultimately, this is
>>    another instance of weak specmanship, in which the statement itself
>>    needs to be amended before its clear what the normative requirements
>>    are.
>> 
>>    These examples are hardly exhaustive, but they at least serve to
>>    motivate the need for a strict understanding of 'normative'.
>> 
>> 
>> 4.  Normative Language off the (Standards) Track
>
>Again, document status is irrelevant to whether normative language is
>appropriate.
>
>
>> 
>>    This section examines the use of normative keywords in Informational
>>    documents which are not protocol specifications.  Some Informational
>>    RFCs are in fact protocol specifications; this will be the subject of
>>    Section 4.1.
>> 
>> 
>> 
>> 
>> Peterson                  Expires May 11, 2008                  [Page 9]
>> ?
>> Internet-Draft                 Normativity                 November 2007
>> 
>> 
>>    Despite the text of RFC2119, it is commonplace for normative keywords
>>    to appear in Informational requirements documents today, in
>>    statements that are intended to constrain the authoring of future
>>    specifications.  The laudable intent of requirements documents is of
>>    course to establish consensus on the needs of the implementation
>>    community prior to the evaluation of candidate protocol
>>    specifications that might satisfy these needs.  The requirements
>>    document becomes a measuring stick of the 'compliance' of a candidate
>>    protocol.
>
>laudable intent.  problematic results.
>
>
>>    Undoubtedly some confusion arises from an accident of the language in
>>    RFC2119.  The Abstract of 2119 says that the normative keywords are
>>    "are used to signify the requirements in the specification", which
>>    could be read to suggest that Informational requirements that will be
>>    used to constrain further protocol specifications should use
>>    normative keywords.  In fact, that interpretation clearly contradicts
>>    the previously-cited dictum that normative keywords are to be used
>>    only when required for "interoperation or to limit [implementation]
>>    behavior."
>> 
>>    Text at the end of Section 1 of RFC2418 furthermore suggests that
>>    normative keywords might be applied by analogy to non-protocol
>>    operations, in that case IETF process, in order to "reduce the chance
>>    for confusion about the process", but it isn't clear how such an
>>    analogy would operate.  Were we to grant hypothetically that
>>    normative keywords apply to requirements by analogy, the
>>    interpretation of normative keywords in this context would remain
>>    problematic.  How are we to understand the "SHOULD" keyword for
>>    protocol requirements, as opposed to protocols.  What does it mean
>>    for a protocol that satisfies a given set of protocol requirements to
>>    be merely "conditionally compliant"?
>> 
>>    Along these lines, it might seem compelling to imagine that the
>>    selection of two protocols X and Y, which were invented to satisfy a
>>    set of requirements A, might be decided by a single "SHOULD"
>>    statement specified in A which is support by X but not Y. But of
>
>ANother challenging parsing exercise.  It seems to be saying "selection
>is decided by...".  What does that mean?  And the meaning of the second
>half of the sentence is even more opaque.
>
>
>>    course, if that "SHOULD" in A were instead a "MUST", the same
>>    selection would be made. 
>
>huh?
>
>
>>                  The true utility of a "SHOULD" emerges when
>>    we instead consider two protocol implementations, X and Y, which have
>>    been implemented to specification A and are attempting to
>>    interoperate.  In this case, if Y fails to implement a "MUST", a very
>>    different result can occur than if Y fails to implement a "SHOULD".
>>    In short, the normative keywords are designed to encourage
>>    cooperation, not decide competition.  Using them in the latter
>
>They /enable/ interoperability; they don't 'encourage' it.  This isn't a
>promotional exercise.  It's technical definition.
>
>As for the reference to competition, I don't see where that comes from
>in the text here.
>
>
>>    context is a strained analogy, and the resulting strain rests on the
>>    IETF's standards process.
>> 
>>    It is moreover critical to appreciate that the use of normative
>> 
>> 
>> 
>> Peterson                  Expires May 11, 2008                 [Page 10]
>> ?
>> Internet-Draft                 Normativity                 November 2007
>> 
>> 
>>    keywords is tied to the functions of 2026: that is, the pruning of
>
>It has nothing whatsoever to do with RFC 2026.
>
>It has to do with the substance of technical specification.  Not
>community approval of the specification.
>
>
>>    unused features of a protocol specification.  From the guidance in
>>    4.1.2 (where we understand 'features' to be at the mandatory degree
>>    of compliance, and 'options' to be at the recommended or optional
>>    degrees of compliance):
>> 
>>     The requirement for at least two independent and interoperable
>>     implementations applies to all of the options and features of the
>>     specification.  In cases in which one or more options or features
>>     have not been demonstrated in at least two interoperable
>>     implementations, the specification may advance to the Draft Standard
>>     level only if those options or features are removed.
>> 
>>    Normative keywords exist to ensure interoperability; by contrast, a
>>    requirements document will never be interoperable with anything.
>> 
>>    More rarely, normative keywords appear in Informational frameworks
>>    that describe high-level or abstract architectures.  In this context
>>    they are primarily used for rhetorical emphasis.  This practice can
>>    still lead authors of future specifications to improper referencing.
>> 
>>    Finally, it is also possible for an Informational document to
>>    redefine normative keywords in lieu of any reference to RFC2119.
>>    This practice only adds further misery to the confusion surrounding
>>    the use of normative keywords, and should be avoided.  If there is a
>>    genuine need for terminology to characterize adherence to a set of
>>    requirements in the context of specification authoring, those terms
>>    should be clearly defined and explicitly distinguished, semantically
>>    and syntactically, from the RFC2119 normative keywords.  A similar
>>    direction should be taken regarding the use of normative keywords in
>>    process statements.  Further consideration is left as a possible
>>    subject for future study.
>> 
>> 4.1.  Informational Publication of Protocols
>> 
>>    There are a variety of circumstances in which protocol specifications
>>    are published as Informational RFCs.  Sometimes authors request
>>    Informational publication of protocol specifications which were
>>    rejected as candidates in a working group process in order to
>>    preserve an historical record.  Parties who do not participate
>>    directly in the IETF may similarly request publication of their
>>    designs as an Informational RFC.  New ciphersuites designed outside
>>    the IETF are typically documented, in strict procedural language,
>>    within Informational RFCs as a convenient reference for protocol
>>    designers; these latter are frequently a target of legitimate
>>    downward references (see RFC3967).  Some exceptional IETF procedures,
>>    for example MIBs or the SIP change (RFC3427 [6]) process, may
>>    stipulate a lower bar of review and Informational publication for
>> 
>> 
>> 
>> Peterson                  Expires May 11, 2008                 [Page 11]
>> ?
>> Internet-Draft                 Normativity                 November 2007
>> 
>> 
>>    certain protocol work.
>> 
>>    These Informational documents often contain normative keywords, as
>>    their authors aspire to specify something that will yield
>>    interoperable implementations.  One need not anticipate, or even
>>    understand, the eventual intended status of a specification in order
>>    to invoke RFC2119 and use the normative keywords therein.  The
>>    distinctions between such Informational documents and standards-track
>>    documents lie more in the implications about the level of review and
>>    community consensus which the standards-track entails than in any
>>    consideration about the use of normative keywords.
>> 
>>    Because such documents exist, it is not reasonable to bar
>>    Informational specifications from containing RFC2119 normative
>>    keywords.  Indeed, the downref exception procedures of RFC3967 exist
>>    so that it is possible to refer to such documents, under the proper
>>    conditions and with the required oversight.
>> 
>>    Instead, we should prevent the casual or inappropriate use of
>>    normative keywords that to refer to matters other the proper
>>    implementation of protocols.
>> 
>> 
>> 5.  IANA Considerations
>> 
>>    This document contains no considerations for the IANA.
>> 
>> 
>> 6.  Security Considerations
>> 
>>    This is a IETF process document which does not impact the security of
>>    IETF protocols.
>> 
>> 
>> 7.  Acknowledgements
>> 
>>    Harald Alvestrand, Brian Carpenter, Scott Bradner and Jonathan
>>    Rosenberg have provided valuable input to this document.
>> 
>> 
>> 8.  Informational References
>> 
>>    [1]  Bradner, S., "Key words for use in RFCs to indicate requirement
>>         levels", RFC 2119, March 1997.
>> 
>>    [2]  Bradner, S., "The Internet Standards Process -- Revision 3",
>>         RFC 2026, October 1996.
>> 
>> 
>> 
>> 
>> Peterson                  Expires May 11, 2008                 [Page 12]
>> ?
>> Internet-Draft                 Normativity                 November 2007
>> 
>> 
>>    [3]  Bush, R. and T. Narten, "Clarifying when Standards Track
>>         Documents may Refer Normatively to Documents at a Lower Level",
>>         RFC 3967, December 2004.
>> 
>>    [4]  Klensin, J. and S. Hartman, "Handling Normative References to
>>         Standards-Track Documents", RFC 4897, June 2007.
>> 
>>    [5]  Bradner, S., "IETF Working Group Guidelines and Procedures",
>>         RFC 2418, September 1998.
>> 
>>    [6]  Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B.
>>         Rosen, "Change Process for the Session Initiation Protocol
>>         (SIP)", RFC 3427, December 2002.
>
>
>
>
>-- 
>Dave Crocker
>Brandenburg InternetWorking
>bbiw.net