[rfc-i] Fwd: Comment on headers-and-boilerplates

John C Klensin john+rfc at jck.com
Thu Dec 25 20:46:46 PST 2008

--On Fri, 19 Dec 2008 14:42:55 -0700, Cullen Jennings
<fluffy at cisco.com> wrote:

> The understanding of some people, me included, when talking
> about   3932bis was that the H-B draft was going to have
> material to cover   roughly the important contents of the
> current note phrased in a   somewhat nicer way. If it does
> not, I suspect some people (not all)   would want to move back
> to more or less what we have today which is:

> This RFC is not a candidate for any level of Internet
> Standard. The IETF disclaims any knowledge of the fitness of
> this RFC for any purpose and in particular notes that the
> decision to publish is not based on IETF review for such
> things as security, congestion control, or inappropriate
> interaction with deployed protocols. The RFC Editor has
> chosen to publish this document at its discretion. Readers of
> this document should exercise caution in evaluating its
> value for implementation and deployment. See RFC 3932 for
> more information.
> Clearly the H-B draft and 3932bis document are somewhat tied
> together.   The 3932bis proceeded under assumptions about the
> H-B draft which all   now seem to be possibly somewhat
> mistaken assumptions. We may need to   step back, look at both
> of these drafts together as they are clearly   intertwined on
> this note subject, and get this conversation moved to a  
> forum more appropriate for discussion of rfc3932.
> I'm not a fan of the current wording so I certainly don't want
> to see   lack of ability to get to consensus on something
> better result in   staying with the status quo.


I thought this process was moving along the right track, but
agree with you that the two documents should be considered
together.  Indeed, IMO, the two of them should be considered
together with the RFC Editor model and RFI documents -- for
independent submissions, the four are inexorably intertwined and
it is quite dangerous to proceed on any of them without a clear
understanding of the others.

Independent of that, let me reiterate what I believe to be an
important principle (and one with which I think you at least
partially agree): it is bad for the IETF and bad for the broader
community if the IESG puts itself into the position of telling
intentional lies (or of being put into that position by others).

Some, perhaps even many, independent submission documents are
extensively reviewed in the IETF community.  Some even originate
in IETF WGs.   Others are extensively reviewed by experts who
are not visibly IETF participants.  For the IETF to "disclaim
any knowledge" requires that no participant in the IETF has
actually read the document, much less that they have studied it
and discussed it with colleagues.   Similarly, the IESG has no
business saying "not based on IETF review" unless it knows that
to be true.  And, while readers should probably exercise caution
when evaluating these documents, they should also exercise
caution about every Proposed Standard: the "no known technical
deficiencies" criterion of 2026 is a rather weak one, there is
no requirement for proof that a Proposed Standard be either
implementable or deployable, and, in my experience, the RFC
Editor is no more likely to publish a document with known
deficiencies than the IESG.  Yet I don't hear the IESG calling
for a "readers should exercise caution" note on Proposed
Standards and IETF-produced Experimental specifications.

To imply that anything that does not come out of the IETF stream
is inferior as a consequence is, at best, a fairly extreme form
of hubris.  We also know that 

My understanding has been that both the headers and boilerplate
document and 3932bis were trying to make sure that the
relationship to the IETF was clear and, in the process, to clear
up this mess in which the IESG makes statements on behalf of the
IETF without consensus calls and, in the worst situations, are
known by everyone who is paying attention to be false.   The
following statements are true about all independent submissions:

	(1) They are not standards of any type.
	(2) They are not recommended for publication via the
	IETF stream.

   (3) They are not final products of an IETF process.
	(4) There is no demonstrated IETF consensus, either for
	their publication or about their content.

While I hope we don't need to belabor the point, I could happily
live with statements equivalent to any or all of the above.  But
I'm very unhappy if the IESG goes much beyond that without
making a case-by-case determination that there is evidence of a
problem, either of technical quality or of lack of review...
and, under our normal procedures, that determination requires a
Last Call and evidence of community consensus.

FWIW, I would feel more sympathetic to your argument about
branding if it were the case that the quality of review of
IETF-produced documents (standards track and otherwise) was
uniformly high and so was the quality of those documents.  But I
think we know that even review quality varies widely even for
standards track documents -- and even more widely for
Informational and Experimental documents published at AD request
(sometimes without even a pro forma IETF Last Call) -- and that
technical quality may be even more variable.

What "IETF Product" or even "IETF Standard" ultimately means is
that a document got through a particular style and process of
consensus-determination.   We hope that process guarantees
documents of high quality, but we also know that sometimes is
not the case.   Let's not throw stones at things that come
through other processes just because of how they arrived.  And
let's try to remember, as RFC 4846 and other documents point
out, that the RFC Series was around long before the IETF.   We
could, I suppose, have a discussion as to whether the technical
quality of the average RFC has gone up or down since the IETF
came into existence and started using the RFC series as the
publication of record for its standards and other documents, but
I don't think anyone really wants to go there.


More information about the rfc-interest mailing list