I am bringing this draft to its second last call. After the completion of the headers and boilerplates document and extensive discussions within the IESG, it has become clear that several ADs had an issue with the 3932bis draft. I have asked Russ to post a new version which I believe resolves the issue. However, the changes -- even if small -- relate to what information there exists about the status of RFCs in the RFCs themselves, so I felt that it this is an issue that needs to be taken to the community. I am formally asking for the community review of the new version of the draft, but I like to think about this last call as a way to find out what the IETF community is thinking about the topic. Once we know, I hope we can approve the draft version that matches that opinion. Comments should be sent to the ietf@xxxxxxxx mailing list. Note that there has been past discussion of what the header and boilerplates should say. This discussion happened on the rfc-interest list. 3932bis is about IESG notes and IESG processing, and the notes are of course very much related to what the boilerplates have already said. However, the boilerplates should be taken as given for the purposes of our discussion here. The rfc-interest list had consensus to publish the headers and boilerplates in its final form. Only changes to 3932bis are under consideration now. The core of the issue is what non-IETF RFCs say about their relationship to IETF. According to the new headers and boilerplates document, the source is clearly indicated. However, the issue brought up in the IESG review was that this can be insufficient at times. In general, additional information about the role of the relationship of the RFC to the IETF work would be useful for readers. The new version of the 3932bis draft suggests that the IESG may add a statement to a non-IETF RFC about its relationship to IETF work. Previous language indicated that such statements would be exceptional. The consensus view on the h&b document was that the front matter should say what the RFC is, as opposed to saying what the RFC is not. IESG's issue with the 3932bis notes under this situation was three-fold. First, there is an assumption that the readers are familiar with the different streams (what they are and what they're not) -- which many readers of RFCs might not be. Second, the relationship between some non-IETF RFC and IETF work is often more complex than is captured by just the stream and maturity level. Third, additional explanation (not boilerplate) specific to the situation could help putting the work in context The relevant changes from the previous version of the draft are in Section 1.1: OLD:The IAB and the RFC Editor have made updates to the formatting of the title page for all RFCs [N3]. With these changes, the upper left hand corner of the title page indicates the stream that produced the RFC. This label eliminates the need for a mandatory IESG note on all Independent Submission and IRTF Stream documents.NEW:The IAB and the RFC Editor have made updates to the formatting of the title page for all RFCs [N3]. With these changes, the upper left hand corner of the title page indicates the stream that produced the RFC. This label replaces some of the information that was previously provided in mandatory IESG notes on non-IETF-stream documents. The IESG may choose to add an IESG note to an Independent Submission or IRTF Stream document that explains the specific relationship, if any, to IETF work. and Section 3: OLD:Generally, the RFC headers and boilerplate clearly describe the relationship of the document to the IETF standards process [N3]. 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.NEW:The RFC headers and boilerplate is intended to describe the relationship of the document to the IETF standards process [N3]. In addition the IESG may request that the RFC Editor include the IESG note to clarify the relationship of the document to the IETF standards process, such as pointers to related IETF RFCs. A more detailed diff is available at http://tools.ietf.org/rfcdiff?url2=draft-housley-iesg-rfc3932bis-07.txt Jari _______________________________________________Ietf mailing listIetf@xxxxxxxxxxxxx://www.ietf.org/mailman/listinfo/ietf