[rfc-i] Fwd: Comment on headers-and-boilerplates
jari.arkko at piuha.net
Thu Jan 8 09:09:41 PST 2009
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
> 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.
> 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?
More information about the rfc-interest