[rfc-i] RFC 5000 on Internet Official Protocol Standards
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
> *> 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
> *> 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
> *> 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,
-------------- next part --------------
A non-text attachment was scrubbed...
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