[rfc-i] RFC 5000 on Internet Official Protocol Standards

Olaf Kolkman olaf at NLnetLabs.nl
Thu May 15 10:42:07 PDT 2008

Bob, Paul, Colleagues,

On May 9, 2008, at 6:59 PM, Bob Braden wrote:
> *> - It says that it's Informational, while all previous versions of  
> *> 1 have been Standards Track. In specific, RFC 5000 obsoletes RFC
> *> 3700. RFC 3700 and its predecessors were on standards track; RFC  
> 5000
> *> is Informational.  It's hard to see how a document can both be
> *> Informational and STD. This seems like a glaring error.
> *>
> The error, in this case, belongs in the IAB and IESG.  We asked to
> circumvent 2026 and publish 5000 as a Standard, but the IETF has to
> follow its own rules strictly, I guess, so we were told that we can
> publish it only as Informational.  The RFC Editor certainly agrees
> with you on this one.

The RFC Editor brought up the issue with the IAB. The RFC Editor  
should expect the IAB to follow the IETF processes. The IAB argues, in  
its oversight role, as follows:

The premise is that the RFC Editor is not in the business of directly  
publishing Standards Track documents. In fact, only IETF Stream  
documents can be published as Standards Track documents. Therefore  
these index documents, published as part of the Independent Stream,  
should be published as Informational documents, and the RFCs that were  
previously published as Standard Track documents should be obsoleted  
or made Historic. Since obsoleting Standard Track documents is an IESG  
action the pragmatic approach of adding an IESG note was followed.

Leaving the inconsistency of an informational document being published  
as STD1. RFC2026 specifically mentions this practice:

  The "Official Protocol Standards" RFC (STD1) lists a general
  requirement level for each TS, using the nomenclature defined in this
  section. This RFC is updated periodically.

This text allows a (pragmatic) exception to the convention that  
documents with STD numbers should be Standard Track documents.

That the RFC Editor wants to go on record as not agreeing with this  
argument is fine, but calling it an error goes too far.


Paul Hoffman argued:
> *> - The "author" is an organization, not a person, breaking with
> *> decades of practice. This could lead to companies using only the
> *> company's name without a responsible individual's name for
> *> Informational RFCs that describe their protocols; that would be a  
> bad
> *> change from the current policy.

BCP78 uses the term "Contributor": an individual submitting a  
Contribution. From an IPR perspective an RFC should list individuals  
as authors of documents created by functional entities (such as the  
IAB or the RFC Editor).

For IAB Stream documents we usually list the editors and "the IAB" as  

Paul Hoffman also argued,

> *> All of these problems (other than the slowness) could have been
> *> avoided if the authors had published an Internet Draft and asked  
> for
> *> comments, as is normal for documents that will become RFCs (other
> *> than April 1 RFCs). I'm sure people on this list would have been
> *> happy to review the draft and make suggestions.

It seems good practice to follow documented practices of RFC4846,  
which include, as a first step, publication of an Internet-Draft. And  
although the documented steps may occur in rapid progression there is  
still some time for an open and transparent process.

For the IAB,

--Olaf Kolkman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 235 bytes
Desc: This is a digitally signed message part
Url : http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20080515/4587c232/PGP.bin

More information about the rfc-interest mailing list