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

[Jari Arkko]

Leslie,

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

Jari