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(_at_)ietf(_dot_)org
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 list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf