Subject: Re: STD series of documents

From: Bob Braden <[email-masked]>
Date: Tue, 1 Jun 2004 11:31:16 -0700 (PDT)

Michael Richardson wrote:

  *>   The reason is that I want to encourage government RFPs to refer to
  *> STDxxx rather than RFCxxx as part of a system of educating the people
  *> involved as to what is a standard, and what isn't.
  *> 

Good objective.  It is the purpose of the "Official Internet Protocol
Standards" document, which is periodically published by the RFC Editor
and exists as a living document online at:

	http://www.rfc-editor.org/rfcxx00.html

Note that STD numbers are only applied to specifications in
the Standard category.  When people say "standards", they often mean
specifications in the Proposed Standard or Draft Standard category.
Few specs make it to Standard, for a variety of real-world reasons.

Perhaps STD numbers should be applied all levels of the standards track
(but before we did that, we would need to think carefully about the
consequences).

Bob Braden

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Jun 2004 21:16:48 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Bob" == Bob Braden <[email-masked]> writes:
    Bob> Good objective.  It is the purpose of the "Official Internet
    Bob> Protocol Standards" document, which is periodically published
    Bob> by the RFC Editor and exists as a living document online at:

    Bob> 	http://www.rfc-editor.org/rfcxx00.html

    Bob> Note that STD numbers are only applied to specifications in the
    Bob> Standard category.  When people say "standards", they often
    Bob> mean specifications in the Proposed Standard or Draft Standard
    Bob> category.  Few specs make it to Standard, for a variety of
    Bob> real-world reasons.

  Yes, that's fine.
  The key thing is for the right thing to show up in an RFP.

  I have seen RFC1180 specified, when RFC791/792/793 was intended.
  Upon challenging this, a completely different RFC was
specified... (can't find that in my notes)

    Bob> Perhaps STD numbers should be applied all levels of the
    Bob> standards track (but before we did that, we would need to think
    Bob> carefully about the consequences).

  It might be worth doing this. Yes, some thought is necessary.

  One thing to consider, is having a web server which, when asked for:
      http://www.ietf.org/ref/rfc0791.txt

  redirects to:
      http://www.ietf.org/std/std005.txt

  The point being to change people's habits a little bit.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Joe Touch <[email-masked]>
Date: Thu, 03 Jun 2004 11:04:06 -0700

>       http://www.ietf.org/std/std005.txt

STD-5 is a nice choice - it actually refers to 6 different RFCs.

So which one redirects to STD005.txt, and what is in it?

(To see this noted in the RFCs themselves, see STD-62, which refers to a 
set of 8 different RFCs.)

And what happens when a STD is updated/revised?

Joe

---

From: [email-masked]
Date: Thu, 03 Jun 2004 16:21:23 -0400

> And what happens when a STD is updated/revised?

This is the IETF, we believe in rough consensus and running code.  Note
carefully that RFC2119 and RFC2026 are both BCP rather than Standard,
indicating that even the meta-standard of how we produce standards is "running
code" rather than an actual standard itself... ;)

But anyhow,  if we ever update STD005, we'll just do the obvious - create
STD079 or whatever we're up to, stick an "Obsoletes: STD005" on it, and stick
an "Obsoleted By: STD079" on STD005, and the RFC Editor will turn the crank and
make sure all the appropriate indexes and webpages are updated to match.
Again, this is all "running code" - we know how to issue an RFC that updates or
obsoletes one (modulo the occasional corner case that crops up), and there's no
obvious reason that the scheme that works for I-D, Draft, Proposed shouldn't
work for a full Standard...

---

From: Dean Anderson <[email-masked]>
Date: Thu, 3 Jun 2004 20:23:09 -0400 (EDT)

I disagree with Valdis' description.  I actually worked for a standards
organization that used a codebase as part of the definition of the
standards it produced.  The concept of "Running code" is good, but where
are the IETF reference implementations?  If "running code" is the actual
standard, then you have to have some code to run.  This is not the way the
IETF has ever done things.  The IETF references to "Running code"  simply
mean that there have been (or must be) demonstrations that the standard
works, and is not a hypothetical document awaiting implementation. But
"running code" is not the actual IETF standard, as Valdis seems to be
claiming.  The actual standard is the text of the RFC in the "standard"  
state.  The status of each RFC is given in the current "Internet Offical
Protocol Standards"  which is updated every hundred RFC's, and is
currently RFC 3600.  Reviewing the RFC's with this title (or rather the
changes between each)  will give you an idea of the process the IETF goes
through. Compare this to RFC 2026 and other documents.

Also, it was my understanding that 2119 and 2026 were "BCP" status because
they didn't refer to computer protocols but rather the rules of the
organization, and can't be properly classifed as "standards". They reflect
the current practice of the organization.  However, it is not the case
that they were meant ONLY to be vaguely 'generally useful' ideas that
could be ignored by the IETF. Although under the current leadership, the
rules haven't been followed very closely. This is a failure of the current
leadership, not a failure of the organization to adopt rules.  An
organization can't run without rules. Otherwise, it isn't an organization,
its a Cluster-bleep.

Rules that aren't really rules, aren't rules at all. A standards
organization that has no rules can't be open, transparent and fair.  If it
is not open, transparent, and fair, then it is closed, opaque, and
proprietary. And if its not open, transparent, and fair, then it isn't
really a standards organization, but a good-old-boy/chums network
operating to the advantage of that group, attempting to create defacto
standards just like other proprietary groups such as Microsoft.  While
this might have been OK many years ago, now far too many people have a
stake in the Internet and in Internet Protocols to let the Internet be
specified by a closed, opaque, proprietary good-old-boy operation.

Your goal of having government RFP's refer to STDxxx's is good. It has
been pointed out that relatively few documents ever reach this stage, but
the most important ones do.  If the IETF were to attend more to the
administrative procedures it has adopted, then more RFC's would either
reach the "mature"  STD or BCP or INFORMATIONAL level or be dropped after
development stops and interest fades.  I suspect that some old RFCs' are
kept around as a way for the leadership to promote bad ideas that never
caught on, but that the leadership still favors and hopes someday will
catch on, even though interest in further development was lost long ago.

		--Dean

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Jun 2004 21:28:10 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Valdis" == Valdis Kletnieks <[email-masked]> writes:
    Valdis> But anyhow, if we ever update STD005, we'll just do the
    Valdis> obvious - create STD079 or whatever we're up to, stick an
    Valdis> "Obsoletes: STD005" on it, and stick an "Obsoleted By:
    Valdis> STD079" on STD005, and the RFC Editor will turn the crank

  That is not my understanding.
  What you describe would occur to the RFCxxxx document.

  However, "STD005" is just a pointer, and it can be changed to point at
the new RFC that defined STD005.

- --

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Jun 2004 20:28:00 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Joe" == Joe Touch <[email-masked]> writes:
    >> One thing to consider, is having a web server which, when asked
    >> for: http://www.ietf.org/ref/rfc0791.txt redirects to:

    Joe> STD-5 is a nice choice - it actually refers to 6 different
    Joe> RFCs.

  You mean that there are 5 documents in the set. 
  Hmm. I didn't realize that this occured.

    Joe> So which one redirects to STD005.txt, and what is in it?

    Joe> (To see this noted in the RFCs themselves, see STD-62, which
    Joe> refers to a set of 8 different RFCs.)

  Hmm. okay, so what I want to do doesn't entirely work.

    Joe> And what happens when a STD is updated/revised?

  I had hoped that all the RFCs that have become STDs would direct to
the STD. The specific version would be available via another URL (such
as the /rfc/rfcXXXX.txt that we have now).
  The idea was that it would always refer to the most recent one.

  But, if we have multiple documents as part of STD-5, then that won't
work at all.

- --

---

From: Joe Touch <[email-masked]>
Date: Fri, 04 Jun 2004 10:49:34 -0700

> the new RFC that defined STD005.

Right now that's not always what happens.

See: http://www.rfc-editor.org/rfcxx00.html

e.g., STD34 is replaced by STD56

I don't have an example of a STD for which the RFC changed. Some STDs 
point to RFCs that obsolete other RFCs, but the info as to whether the 
STD ever pointed to that obsoleted RFC isn't captured anywhere I saw...

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 04 Jun 2004 10:54:03 -0700

>   You mean that there are 5 documents in the set. 

IP 	Internet Protocol 	791	 5
ICMP 	Internet Control Message Protocol 	792	5
--------- 	Broadcasting Internet Datagrams 	919	5
--------- 	Broadcasting Internet datagrams in the presence of subnets 	922	5
-------- 	Internet Standard Subnetting Procedure 	950	5
IGMP 	Host extensions for IP multicasting 	1112	5

I rechecked, and still count 6 there... ;-)

>   Hmm. I didn't realize that this occured.

See http://www.rfc-editor.org/rfcxx00.html

It affects STDs: 3,5,8,10,13,16,19,51,58 and 62 (I may have missed 
some), or on average 1 in 6, and some of the most likely to be cited 
(host requirements, DNS, IP, telnet, SMTP, PPP, SNMP)

Joe

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Jun 2004 10:15:53 -0400

Folks, 

This confusion about what STDs mean and what they might do for
us finally convinced me to turn an idea that has been kicked
around a few times into an I-D.  It is in the hands of the
posting queue and should, I assume, be announced today or
tomorrow.  Watch for an announcement for
draft-klensin-std-repurposing-00.txt or something like that.

High points...

	* STDs become a separate document series, independent of
	the underlying RFCs.
	
	* Their content is a function of IESG protocol actions
	or the equivalent, so that they define exactly what a
	particular standard "means" and what its content is at
	some point in time.  They are also a place to put
	comments and suggestions about usability and context to
	the extent to which the IETF wishes to make such
	statements.
	
	* They get activated at "Proposed", not "Internet
	Standard".
	
	* They contain explicit change history and tracking info.

It may not be right (and will need work even if it is), but the
document may at least help focus this, and some closely related,
discussions.

I expect discussion to occur on the Newtrk list.

    john

---

From: Donald Eastlake III <[email-masked]>
Date: Sat, 12 Jun 2004 16:37:33 -0400 (EDT)

I have long thought that the other document designations (STD, FYI, ...) 
are bound to continue to be confusing minor labels without much mind 
share as long as there documents are also RFCs. The only hope to get 
people to REALLY switch to using these new disgnations in general is to 
make those documents NOT be RFCs.

Thanks,
Donald
======================================================================
 Donald E. Eastlake 3rd                       [email-masked]
 155 Beaver Street              +1-508-634-2066(h) +1-508-786-7554(w)
 Milford, MA 01757 USA                   [email-masked]

On Mon, 7 Jun 2004, John C Klensin wrote:

> Date: Mon, 07 Jun 2004 10:15:53 -0400
> From: John C Klensin <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: STD series of documents
> 
> Folks, 
>

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 14 Jun 2004 16:49:28 +0200

John, Donald,
might the common sense experience from a non-internut bring some external 
suggestion? I accept it is not welcome in special environements: IETF is a 
special environment, in particular with its proven records in consensus 
building - let not harm something which works. Anyway I will try this.

If one does not intend to become an IETF specialized geek but to stay an 
IETF deliverables global user, interested in quality control, what seems 
very odd is the lack of network modelization as a common reference. Since 
it goes this way since 1986, may be it is fundamental to the process? But 
John talks of changing part of the operative model: his change might also 
have an impact. So, why not to consider this lack (?) too?

What I mean is when I purchase something, I get a documentation book. In 
that book everything is described or linked: table of content, executive 
summary, annexes, technical parts, etc. and I know that I can sign an NDA 
and dig down to the bottom of the documentation tree to get structured 
information, support, etc. (or it means that the manufacturer is no good - 
good test: who would buy if the boiler plate is poor?). So, if I want to 
change or to add something, I know where to look, what to update, what to 
add. So I know that what I bought will be compatible with future releases 
(and simplify architecture changes). Even on Windows I have such a tree.

This is possible because there is a model acting as a tree structure. Would 
it not be possible to start with a simple entry point "What is the 
Internet", and then to proceed, according to a table. I feel that to some 
extent the WG list provides that - but more as FAQ. This would tell where 
a  STD, an RFC, etc. is expected? May be this "Internet Book/Manual" idea 
is too cartesian? But if something is unclear to the reader, it is often 
because it is unclear to the author.

Another way could be to study what would imply an IETF ISO 9000 
certification. And if there could be ideas to get from that?
jfc

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Jun 2004 12:26:17 -0400

Donald,

I can't tell whether we are in agreement or not.  Would a
separate set of real documents (separate pieces of paper) that
reference RFCs but 

	* are not RFCs and 
	* have content that is not in the RFCs

meet your criteria?

best,
       john

--On Saturday, 12 June, 2004 16:37 -0400 Donald Eastlake III
<[email-masked]> wrote:

> I have long thought that the other document designations (STD,
> FYI, ...)  are bound to continue to be confusing minor labels
> without much mind  share as long as there documents are also
> RFCs. The only hope to get  people to REALLY switch to using
> these new disgnations in general is to  make those documents
> NOT be RFCs.
> 
> Thanks,
> Donald
> ==============================================================
> ========  Donald E. Eastlake 3rd
> [email-masked]  155 Beaver Street
> +1-508-634-2066(h) +1-508-786-7554(w)  Milford, MA 01757 USA
> [email-masked]
> 
>> It may not be right (and will need work even if it is), but
>> the document may at least help focus this, and some closely
>> related, discussions.
>>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Jun 2004 20:42:02 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Donald" == Donald Eastlake <[email-masked]> writes:
    Donald> I have long thought that the other document designations
    Donald> (STD, FYI, ...) are bound to continue to be confusing minor
    Donald> labels without much mind share as long as there documents
    Donald> are also RFCs. The only hope to get people to REALLY switch
    Donald> to using these new disgnations in general is to make those
    Donald> documents NOT be RFCs.

  I concur.

- --