--On Monday, June 01, 2009 17:47 +0300 Jari Arkko
<jari.ar...@piuha.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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
