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

Jari Arkko jari.arkko at piuha.net
Thu Jan 8 09:09:41 PST 2009


John,

Sorry for the delay in sending a response. I was on vacation, and am now 
returning to this topic as we also discuss the 3932bis case in the IESG 
call today.

> 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).
>   

Yes, indeed. I like to avoid that too.

> Some, perhaps even many, independent submission documents are
> extensively reviewed ...
>   

True, and I think our new two documents already are free from the 
problem of claiming otherwise.

> 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.
I think we can avoid going into that discussion. I do not see anyone 
asking for any statements to be put in any document that would imply 
inferiority or superiority. Lack of any such statements is also one of 
the many good things coming out of the publication the two docs.

> (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.
>   

Right.

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

Right. Me too.

> 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 
Again, lets no go into this part of the discussion. I think those of us 
who asked for clearer boilerplate text were not concerned about the lack 
of quality, we really were only concerned about clarity and whether 
different ways to express the text would have an impact on some random 
RFC reading person's ability to understand where a particular document 
comes from and what its status is.

Our debate is fundamentally about to what extent the boilerplate needs 
to be explicit. In particular:

1) Does the boilerplate explain the situation, refer to another RFC for 
the explanation, or just state the name of the stream and leave it at that?

2) Does the boilerplate explicitly call out that non stds track 
documents are not standards?

3) Does the boilerplate explicitly note that non-IETF documents are not 
the product of the IETF?

My opinion is still that for 1, the boilerplate text needs to be very 
short but still a bit informative (name of stream is not enough). For 2 
and 3 my opinion is yes. I've seen lots of other opinions, too...

In any case, putting my AD hat on, the main concern I have is moving 
forward with the document set. Obviously Olaf needs to find a way to 
express h&b in a way that is acceptable to the community. Similarly, I'm 
the sponsoring AD for the 3932bis, and I need to find a way to get the 
document approved in the IESG & acceptable to the community. No one 
likes a deadlock, because the current wording of the various boilerplate 
texts is not the greatest. Is there a proposal on the table that would 
allow at least the people on this thread to agree and move on?

Jari



More information about the rfc-interest mailing list