--On Monday, June 01, 2009 17:47 +0300 Jari Arkko
<jari(_dot_)arkko(_at_)piuha(_dot_)net> wrote:
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
...
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.
But there is one important interaction with what you write
below. The big change (from today's forms) in Headers and
Boilerplates isn't the identification of the stream. It is to
permit (very nearly require), statements about review and level
of consensus behind a document. Those statements are expected
to be factual and (except for the IETF stream) do not depend on
IESG judgments about protocol quality, relationships, etc.
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.
Not just the source, but the level and type of review and
consensus.
However, the issue brought up in the IESG review was that this
can be insufficient at times.
Insufficient if only the stream is identified? Or insufficient
even after a "kind of review and level of consensus" statement
is made?
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.
If the intent is to make them common, I think there is a
fundamental disconnect. If the intent is to not say
"exceptional" but to treat them that way, then see my earlier
response to you and Joel.
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
This discussion leads me to wonder whether the IESG has lost
sight of the descriptions of relationships, review, and
consensus for which H&B provides. Is that possible?
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.
As written, this violates provisions of RFC 4846 as well as some
of the language in the current RFC Editor Model draft. The IESG
may _request_ that notes or other language be added. The ISE
may respond to that by
-- adding the notes,
-- handing the document back to the authors with a
request to address the underlying issues,
-- adding some other note, presumably with the approval
of the author(s),
-- withdrawing the document, or
-- rejecting the IESG request.
In the last case, I would hope that the ISE would provide the
IESG with an explanation. But nothing we have now requires that
explanation or requires the ISE to engage in a dialogue with the
IESG on the subject. And, IMO, that is the right balance.
and Section 3:
...
The Section 3 change does not encounter that procedural
objection because it says "...the IESG may request...".
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf