Re: LC ISSUE: OUTGOING Sections 2 and 3: Editorial [Re: WG LAST CALL on the -outgoing document]

[John C Klensin <john-ietf at jck.com>]

--On Thursday, 12 July, 2007 13:47 -0400 Scott Brim
<sbrim at cisco.com> wrote:

> On 07/12/2007 03:59 AM, Brian E Carpenter allegedly wrote:
>> It's inappropriate to use RFC 2119 terminology in this
>> document. Section 2 should be deleted and any use of the
>> capitalized words should become lower case.
>> (draft-peterson-informational-normativity-00.txt will tell
>> you why.)
> 
> The problem that Jon points to is that requirements documents
> aren't normative but standards track RFCs reference them as
> normative because they have what he (not 2026 or 2119) has
> decided to call "normative" terminology.  Here we have a
> rather different problem, which is that the definitions of
> must, should etc. in 2119 refer to "specifications".  The
> spirit of use it the same -- this document is a requirements
> document (just don't ask me to define that) and clearly
> defining the use of must, should, etc. is a good idea, but the
> definitions in 2119 make assumptions.  If you want to do it
> completely correctly, you might copy the definitions from 2119
> but removing references to "the specification".

Scott,

Thanks for bringing this up, but I think the problem runs a
little deeper.  As you point out, we are in danger of playing
word games here, ones in which terminology is given a specific
(and retroactive and individual) definition and that definition
is then used in lieu of thinking and common sense.   In addition
to the fact that we continue to confuse protocol specifications
and administrative and editorial ones in ways that do not serve
the community well, I see three separate issues in this
"normative" discussion.

(1)  When we have talked about normative references in the RFC
series, our definition has been principally tied to the notion
of "you need to understand that one in order to correctly
understand this one" and not to any notion of requirement
levels.  The latter tie is, I believe, original with Jon's
document.  Prior discussions and rules about normative
references and content (see, e.g., RFC 4897) have been
associated with maturity levels and stability, not requirement
levels.

(2) Historically, MUST/ SHOULD/ MAY language has been used
around the IETF with two separate, subtly different,
interpretations.  One interpretation has to do with standards
and conformance to them: these terms are used to express strong
and weaker conformance requirements.  The other has to do with
the practice of the protocol and risks to interoperability: if
one violates a MUST statement, one will almost certainly not
interoperate, while violation of a SHOULD poses some risks to
interoperability.   The first definition was used in RFC 1122
and RFC 1123; something close to the second appears to have been
intended in RFC 2119.

RFC 2119 was approved only after a fairly strong agreement that
it represented one set of definitions that could be used and
referenced, not that its definitions were mandatory.  If the
IESG now believe that they should be mandatory, I believe we
need to have the debate that we avoided a decade ago, keeping in
mind that at least one strict reading of 2119 implies that every
MUST statement in a protocol specification is required to be
justified by an interoperability analysis.

(3) I continue to believe, perhaps naively, that when a member
of the community, even an AD, posts an I-D, that is a proposal
and the beginning of a discussion, not a statement that is
sufficiently normative (sic) that it immediately imposes
requirement on how other documents are written.   If that is no
longer the case, we have far more serious problems than any
debate about an IPR specification.   The fact is that we have
extensive precedents for the use of "RFC 2119 language", or at
least uses of the words for which RFC 2119 offers a definition,
in administrative and procedural documents.  We can stop doing
that, but it seems to me that making elimination of that usage
into a hard requirement requires community consensus, not just
posting of an I-D.

      john


_______________________________________________
Ipr-wg mailing list
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg