[rfc-i] Fwd: Comment on headers-and-boilerplates
jari.arkko at piuha.net
Tue Dec 9 03:51:19 PST 2008
> The piece I am, therefore, still missing is: how are you not simply
> asking for every non-IETF Stream document to say "this is not a
> product of the IETF Stream"?
I am asking for consistency and clarity.
Current text in my view is not consistent, because one of the two
clearly non-IETF streams has "It is not a product of the IETF and is
therefore not a candidate for any level of Internet Standard" and the
other has "It is therefore not a candidate for any level of Internet
Standard". And I already mentioned the other issue about non-standards
track RFCs in my previous mail.
Clarity is harder to explain. What is clear enough? All of us want to
make it obvious who made the RFC. The text that has gone into current
RFCs is problematic in various ways, e.g., very negative sounding IESG
notes. This is why we are publishing headers-and-boilerplates and
housley-iesg-rfc3932bis. In the new boilerplate, personally, I would
rather err on the side of being too clear than the opposite. I'm sure we
all on this list understand what the different entities do and what the
different streams mean. We don't need the boilerplate because we
probably even remember who produced RFC nnnn and the issues that were
raised in the last call discussion :-) The boilerplate text is really
for someone else out there, looking at documents without a lot of context.
BOTH problems above can be solved by the change that I suggested, i.e.,
alignment of the IRTF and Independent texts. I acknowledge the fact that
the boilerplate texts already say quite a bit, some explicitly, some
implicitly. In particular, the case for standards track work is already
very clear. However, I'm mostly concerned about the remaining
non-standards track case and being able to clearly indicate what an RFC
is or is not. Some of you have asked why it is necessary to indicate
"not Y" in addition to saying "X". Given the large number of IETF RFCs
vs. any other RFCs I think it is reasonable to state "not a product of
the IETF" in those other RFCs.
More information about the rfc-interest