Olaf,
Let me suggest tuning this a bit, with the understanding that
what I'm about to suggest lies well within current procedures,
RFC 5620, etc.
--On Wednesday, September 09, 2009 09:11 +0200 Olaf Kolkman
<olaf@xxxxxxxxxxxx> wrote:
>...
> But there is a nugget in the introduction of a last call: I
> think that the ISE has a very hard time explaining to the RSE
> that a note that has backing of IESG consensus will not be
> published. (I am assuming the use of the appeal procedure as
> described in RFC5620, which I think is appropriate for a
> difference of opinion between RFC entities such as the ISE and
> the IESG). If in such conflict the RSE would choose sides of
> the ISE then I am pretty sure something is severely broken and
> the appearance of a note is the least of our problems.
I would not assume that unless you assume that there is some
part of the model that somehow prevents the IESG from getting
out of control. If there is not, then, to be orderly, one has
to assume that it is fully as possible that the IESG (as the
IETF stream-approver) is out of control as it is that the ISE
(as the Independent Submission stream approver) is out of
control.
I also imagine that the IESG could, if so inclined, issue a Last
Call that would be so stated as to produce a confirming result,
especially if comments from those who do not believe that there
should be an Independent Stream were counted along with those
who actually understood the particular issues and confirmed the
importance of the note. Also remember that the IESG does the
counting and, to refer back to an earlier comment on the list,
figures out what the consensus is even when it is not obvious.
The particular case I would be most concerned about would
involve a document that was highly critical of an IETF Standard,
but that was extremely clear that it was a critique, that
documented the disagreement in a balanced way, etc. -- in other
words, where there was a dissent from an IETF standards-track
document and no possibility of confusion with one. I could
easily imagine the IESG disagreeing with such a document and
wanting to get the last word in with a "don't pay any attention
to this" note. If they are permitted to do that, with or
without a claim of IETF consensus, then there is no Independent
Stream, only an "independent as long as documents are reasonably
supportive of IETF views and political correctness" one.
Were that situation to arise, I would expect the RSE to do a
balanced evaluation and the IAB, if it got involved, to do so
too, with both paying a lot of attention to the differences
among "note needed to ensure clarity about what the document
is", "note to warn against a diagnosed danger to the Internet
posed by the suggestions in the document", and "IESG wants to
get the last word in". And, again, my personal view is that the
first two represent flaws in the document that ought to get
resolved, without add-on text, before the ISE agrees to publish
and that the third is not acceptable. Put differently, I think
we have a problem any time the ISE (or other stream entity)
chooses to ignore, or reject without good reason, input about
changes to a document to make its status, or issues with its
suggested technology, clear.
> So in other words what I am saying is don't invent process but
> follow existing pieces:
>
> - put a note in front of the ISE
> o if the ISE pushes back
> - last call the note in the IETF, to make sure the IESG
> actually represents IETF consensus --whereby the consensus is
> called by the IESG following normal process and appeal--, and
> go back to the ISE telling that the note has IETF backing.
> o if the ISE pushes back
> - consider this a disagreement between stream entities and
> follow RFC 5620 appeal process.
I think whether or not to do that Last Call should be up to the
IESG. Nothing prevents them from invoking the "disagreement
between stream entities" procedures on their own remit, although
their position would certainly be stronger with clear IETF
backing.
> o if the RSE chooses sides with the ISE the note gets
> published but the IAB, the IESG, and the RSE have some serious
> talking to do because something is severely broken elsewhere
> than just the note. The RFC will most probably be published
> without the note but the IESG has the possibility to publish a
> "This RFC sucks for this reason RFC" while the real problems
> are being addressed
And we should operate on the guideline that, if the IESG simply
wants to dissent from a particular document, the mechanism is
publication of such an RFC, not attachment of notes. But,
again, I believe that any situation in which a note is perceived
to be needed is a failure in the publication model _and_, if we
think notes are an appropriate way to resolve problems, that any
of the other streams should be able to ask the ISE to attach
notes of their choosing to IETF Stream documents, doing so as
soon as the Document Action or Protocol Action appears.
> Obviously publication of the document should be delayed on
> request from the IESG while the above is sorted out in a
> timely manner.
Yes, although the IESG (as well as the ISE and RSE) incur
considerably obligation to be timely if such issues arise. The
ISE should be able to treat, e.g., IESG failure to produce a
position statement within a very short time after a Last Call
ends as an indication that the IESG has abandoned its position.
john
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf