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

Cullen Jennings fluffy at cisco.com
Mon Jan 12 22:08:14 PST 2009


John, agree with most your points and certainly the point that all  
streams have produced both awful and excellent quality documents but  
one point inline.

On Dec 25, 2008, at 9:46 PM, John C Klensin wrote:

>
>
> --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.
>
> Cullen,
>
> 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...

But this sort of review is how we got into the IESG note mess in the  
first place. What percentage of the IESG time should be spent on these  
determinations? How much time should the community that reads IETF LC  
spend on it? How much should this slow down IETF stream work? How much  
should it be allowed to delay work from the other stream. I suspect  
theses were some of the problem that caused the IESG to move to trying  
to use default IESG statements that are in use today. I suspect no one  
really likes them - I'm sure the authors don't. Even today, the IESG  
does spend time trying to make sure the notes are not too inaccurate  
and has used non default notes in some cases.


>
> and, under our normal procedures, that determination requires a
> Last Call and evidence of community consensus.

Hmm, I often think about what the bulk of our IETF LC actually show  
evidence of. But that's a different topic.

>
>
> 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.
>
>    john
>
>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest



More information about the rfc-interest mailing list