Subject: [Fwd: I-D ACTION:draft-iesg-info-exp-00.txt]

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 May 2005 11:24:29 +0200

Comments welcome (here, or on the ietf list if you think that is
more appropriate).

     Brian

-------- Original Message --------
Subject: I-D ACTION:draft-iesg-info-exp-00.txt
Date: Mon, 23 May 2005 15:42:02 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Engineering Steering Group Working Group of the IETF.

	Title		: Choosing between Informational and Experimental Status
	Author(s)	: B. Carpenter
	Filename	: draft-iesg-info-exp-00.txt
	Pages		: 6
	Date		: 2005-5-23
	
This document reproduces the rules for classifying documents as
    Informational and Experimental from RFC 2026, and amplifies those
    rules with guidelines relevant to ongoing IESG evaluations.  It is
    not intended to change any of the underlying principles.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-iesg-info-exp-00.txt

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: Fred Baker <[email-masked]>
Date: Tue, 24 May 2005 11:39:08 -0700

>    o  A similar case is work that could be practiced, was developed in
>       the IETF, has been dropped for some reason, but is being 
> published
>       for the record.  That's Informational.  Case in point: "A Delay
>       Bound alternative revision of RFC 2598" (RFC 3248).

IMHO, these should be historical.

A comparison point might be RFCs 1716 and 1812. 1716 is the text I 
edited to form 1812; the requested edit was to add CIDR concepts and 
change the language throughout to reflect them, to move any routing 
protocol that couldn't handle arbitrary prefixes (RIP) to an appendix 
due to their historical nature, and generally clean up the text. 1716 
was published as historical, and in today's verbiage 1812 might have 
been a BCP.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 May 2005 09:50:23 +0200

Fred Baker wrote:
>>       the IETF, has been dropped for some reason, but is being published

Seems to me that things like this could be moved later to
Historic, but as I read 2026 section 4.2.4, an RFC can't
start life as Historic. The example given was published at the
same time as the PS RFC 3246.

> was published as historical, and in today's verbiage 1812 might have 

1716 is listed as Informational in the index, and as obseleted by 1812.

     Brian

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 25 May 2005 10:53:25 -0400

I have a related question:  RFC 2119 says that the keywords "MUST" and 
so forth are for standards track use.  In fact 2119 is very succinct 
(which is generally good, but I think 2119 is perhaps too succinct).  It 
starts out with an Abstract:

"In many standards track documents several words are used to signify the requirements in the specification ...", There is nothing else in
the main text: the document starts out with what appears to be a numbered list, which in fact are section numbers.  I would like to see 
some additional text in an Introduction section with detailed guidance on proper use of the keywords.

Specifically, I would like to see it address whether RFC 2119 words are "allowed" in documents of other category.  To me it makes 
sense to use them in Experimental track, but not in informational.  In RFC 4046 that I co-wrote  (MSEC group), we were forced to 
make all our MUSTs lowercase (i.e., they are the English language must, not the 2119 keyword).  A quick search in a few 
crypto-related informational RFCs reveals that the keywords are in fact used quite frequently in non-standards track documents.

I am looking for some guidance.  As I note above, perhaps the guidance 
should be documented in BCP 14.

(If it makes sense to use the keywords in Experimental RFCs, then the 
info-exp I-D might discuss that.)

thanks and regards,
Lakshminath

Brian E Carpenter wrote:

>------------------------------------------------------------------------
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 25 May 2005 10:18:28 -0700

imho, a requirements document is never standards track, and the words  
in 2119 only belong in documents that say what an implementation or  
solution must or must not do.

On May 25, 2005, at 7:53 AM, Lakshminath Dondeti wrote:

> (which is generally good, but I think 2119 is perhaps too succinct).   
> It starts out with an Abstract:
>
> "In many standards track documents several words are used to signify  
> the requirements in the specification ...", There is nothing else in
> the main text: the document starts out with what appears to be a  
> numbered list, which in fact are section numbers.  I would like to see  
> Specifically, I would like to see it address whether RFC 2119 words  
> are "allowed" in documents of other category.  To me it makes sense to  
> use them in Experimental track, but not in informational.  In RFC 4046  
> that I co-wrote  (MSEC group), we were forced to make all our MUSTs  
> lowercase (i.e., they are the English language must, not the 2119  
> keyword).  A quick search in a few crypto-related informational RFCs  
> reveals that the keywords are in fact used quite frequently in  
> non-standards track documents.
>
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 25 May 2005 13:19:58 -0400

On Wednesday, May 25, 2005 10:53:25 AM -0400 Lakshminath Dondeti 
<[email-masked]> wrote:

> I have a related question:  RFC 2119 says that the keywords "MUST" and so
> forth are for standards track use.  In fact 2119 is very succinct (which
> is generally good, but I think 2119 is perhaps too succinct).  It starts
> out with an Abstract:
>
> "In many standards track documents several words are used to signify the
> requirements in the specification ...", There is nothing else in
> the main text: the document starts out with what appears to be a numbered
> list, which in fact are section numbers.  I would like to see some
> additional text in an Introduction section with detailed guidance on
> proper use of the keywords.
>
> Specifically, I would like to see it address whether RFC 2119 words are
> "allowed" in documents of other category.  To me it makes sense to use
> them in Experimental track, but not in informational.  In RFC 4046 that I
> co-wrote  (MSEC group), we were forced to make all our MUSTs lowercase
> (i.e., they are the English language must, not the 2119 keyword).  A
> quick search in a few crypto-related informational RFCs reveals that the
> keywords are in fact used quite frequently in non-standards track
> documents.

It seems to me that RFC2119 makes the wrong distinction about when it is 
appropriate to use requirements language.  In my mind, it is appropriate 
for anything which specifies a protocol, algorithm, or procedure to specify 
what parts are REQUIRED, RECOMMENDED, or OPTIONAL.  It doesn't matter 
whether the specification itself is standards-track or not; an 
Informational document specifiying a non-standard extension to some IETF 
protocol is still a protocol specification, and it's still appropriate to 
use well-defined terms to describe what is necessary to be compliant with 
that specification and to interoperate with other implementations.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Fred Baker <[email-masked]>
Date: Wed, 25 May 2005 10:17:02 -0700

interesting. I was told that the IESG at the time was making it 
historic. I guess I never verified that.

---

From: Ned Freed <[email-masked]>
Date: Wed, 25 May 2005 11:25:54 -0700 (PDT)

> solution must or must not do.

Repeating what I recently said on the ietf-smtp list, I completely disagree
with this. RFC 2119 words are a useful tool, nothing more and nothing less.
Whether or not the tool is useful in a given context has nothing to do with the
status of the document. There are places where it makes sense to use these
terms in requirement documents or other informational specifications.
Similarly, there are plenty of contexts where the use of these terms is
inappropriate in standards-tack specifications.

				Ned

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 May 2005 22:54:10 -0400

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:

    Brian> Fred Baker wrote:
    >>> o A similar case is work that could be practiced, was
    >>> developed in the IETF, has been dropped for some reason, but
    >>> is being published for the record.  That's Informational.
    >>> Case in point: "A Delay Bound alternative revision of RFC
    >>> 2598" (RFC 3248).

    Brian> Seems to me that things like this could be moved later to
    Brian> Historic, but as I read 2026 section 4.2.4, an RFC can't
    Brian> start life as Historic. The example given was published at
    Brian> the same time as the PS RFC 3246.

We've published documents at historic this year.  See some of the URL
schemes.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 May 2005 10:41:37 +0200

> We've published documents at historic this year.  See some of the URL

Interesting. Another little point where 2026 is either ambiguous or
deviates from reality.

I'll update the text with something like "unless the IESG determines
that Historic is more appropriate."

Any other comments on the draft itself, or are we done?

     Brian

---

From: Fred Baker <[email-masked]>
Date: Fri, 27 May 2005 08:01:17 -0700

> Any other comments on the draft itself, or are we done?

For my part, we're done.