RE: Should RFC 2119 be normative or informative?

[Andy Bierman <abierman@cisco.com>]

At 12:09 AM 9/11/2002 +0200, Wijnen, Bert (Bert) wrote:
>Scott Bradner tells me (tells the IESG) that he considers 2119
>a informative reference. Not sure all IESG members agree.
>But I believe we have already passed documents that have it
>either way. 

I have been citing 2119 as a normative reference in recent drafts.
I will change it to informative if needed, but I think this is not
a clear choice.  Consider the boilerplate text:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. [RFC2119]

The interpretation of these capitalized words affects the meaning of
any normative text that contains these words. If the normative text
used other keywords from other RFCs, that would be considered a 
normative reference.  Why is RFC 2119 a special case?


>Thanks,
>Bert 

Andy



>> -----Original Message-----
>> From: C. M. Heard [mailto:heard@pobox.com]
>> Sent: dinsdag 10 september 2002 21:29
>> To: mibs
>> Subject: Should RFC 2119 be normative or informative?
>> 
>> 
>> On Tue, 10 Sep 2002, Juergen Schoenwaelder wrote, in reference to
>> the newly-posted draft-ietf-ops-taddress-mib-04.txt:
>> > This revision just splits the references section into normative and
>> > informative references as requested by Bert Wijnen.
>> 
>> I notice that RFC 2119 is listed in the new draft as a 
>> normative reference.
>> While that's not unreasonable, I didn't do this on the standards-track
>> MIB document for which I was the lead editor because RFC 2119 is
>> BCP, not standards track, and I was under the impression that it could
>> not be a normative reference for that reason.  At least, 
>> that's how I read
>> the following note on page 16 of RFC 2026:
>> 
>>    Note: Standards track specifications normally must not depend on
>>    other standards track specifications which are at a lower maturity
>>    level or on non standards track specifications other than 
>> referenced
>>    specifications from other standards bodies.  (See Section 7.)
>> 
>> This is not a big deal, I'm perfectly happy to follow whatever ruling
>> is made, but I do think that all our standards track documents ought
>> to do the same thing about this.
>> 
>> Thanks,
>> 
>> Mike
>> 
>> 
>> 
>>