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

Cullen Jennings fluffy at cisco.com
Wed Dec 17 23:24:25 PST 2008


We are talking about document quality and a brand reflection of that.  
I would be the first to agree that there are awful documents that came  
through the IETF stream and that many good documents have come though  
other streams. However, what people are looking for is the  
understanding of the process that leads to quality that is in the IETF  
stream -  I'm not saying better or worse, just a consistency of the  
quality. The quality control process of this stream is widely  
understood and very transparent. It's hard to say this about the other  
streams. It would be bad to muddle the processes together in our  
representation of them. For better or worse the IETF stream has a much  
heaver weight process than the others. The others need to remain the  
flexibility of a lighter weight process.

I am not for a second suggesting that the other streams don't produce  
good and important documents - If I believed that, I would argue to  
kill the stream. I'm just saying their goals are not the same as the  
IEFT stream and this does impact the review process they use.


On Dec 17, 2008, at 6:26 PM, Rob Sayre wrote:

> On 12/17/08 7:37 PM, Joe Touch wrote:
> > I agree there is utility in stating whether a doc is standards  
> track or
> > not standards track.
> >
>
> Agree. The standards track implies a level of consensus (distinct from
> quality) that is important to differentiate.
>
> > I don't agree that there is utility in explaining how each  
> document has
> > been vetted - or not. Many independent-stream docs have been  
> reviewed
> > more throughly and competently than some in the IETF stream.
> >
> > Cullen Jennings wrote:
> >>
> >> I understand the desire not to put such negative sounding  
> language on
> >> everything, and I understand the total insanity of clamming that a
> >> document from the "Internet Congestion Control Research Group"
> >> authored by Sally Floyd would have a note on that indicates it  
> was not
> >> reviewed for congestion control. But that said, I do think that on
> >> many documents we need to be clear about the limitations if they  
> are
> >> going to be RFC.
>
> What limitations?
>
> The IETF approves documents of wildly varying quality and  
> applicability.
> Some documents get lots of review, and it makes them worse. The way to
> make the IETF process count for something is to produce better
> documents, not slap negative text on documents originating  
> elsewhere. I
> agree with Joe.
>
> - Rob



More information about the rfc-interest mailing list