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

[Cullen Jennings]

On Dec 19, 2008, at 3:30 AM, Olaf Kolkman wrote:
>
>
> While rfc3932bis gets rid of the mandatory IESG note _because_ of  
> the definition in this document
> http://tools.ietf.org/html/draft-housley-iesg-rfc3932bis-06.html  
> reads:
>
> "In exceptional cases, when the relationship of the document to the  
> IETF standards process might be unclear, the IESG response may be  
> accompanied by a clarifying IESG note and a request that the RFC     
> Editor include the IESG note in the document if the document is  
> published."
>
> This is where Cullen can clarify: What kind of IESG note would you  
> think would appear, under which circumstances, and with what  
> frequency.

The understanding of some people, me included, when talking about  
3932bis was that the H-B draft was going to have material to cover  
roughly the important contents of the current note phrased in a  
somewhat nicer way. If it does not, I suspect some people (not all)  
would want to move back to more or less what we have today which is:


This RFC is not a candidate for any level of Internet Standard. The  
IETF disclaims any knowledge of the fitness of this RFC for any  
purpose and in particular notes that the decision to publish is not  
based on IETF review for such things as security, congestion control,  
or inappropriate interaction with deployed protocols. The RFC Editor  
has chosen to publish this document at its discretion. Readers of this  
document should exercise caution in evaluating its value for  
implementation and deployment. See RFC 3932 for more information.

Clearly the H-B draft and 3932bis document are somewhat tied together.  
The 3932bis proceeded under assumptions about the H-B draft which all  
now seem to be possibly somewhat mistaken assumptions. We may need to  
step back, look at both of these drafts together as they are clearly  
intertwined on this note subject, and get this conversation moved to a  
forum more appropriate for discussion of rfc3932.
I'm not a fan of the current wording so I certainly don't want to see  
lack of ability to get to consensus on something better result in  
staying with the status quo.
Cullen