On 2008-06-26 06:30, Jari Arkko wrote:
> Lakshminath,
>
> Better understanding of the type of behaviors in this space would
> certainly be useful. And I don't want to disagree with your assessment
> of the behaviors; many of them sound like something that appears in
> practice. In particular, the shepherds are far less involved in the
> Discuss resolutions than the authors. And we do not involve the WGs as
> much as we should. I think writing guidelines on what the role of the
> various persons in the process is would be very useful. And obviously we
> should start by better following of the existing documents, like the
> Proto Shepherd RFC or the Discuss criteria document.
>
> However, with regards to blocking consensus of a WG, please remember
> that the WG is not necessarily the only place where consensus is tested.
> I recently had a case which had significant IETF Last Call discussion. I
> held a Discuss to ensure that the (fairly clear, IMO) conclusion from
> the discussion would be taken into the document. It did eventually, but
> only after significant back-and-forth with the authors. Overriding the
> original WG consensus? Yes. Right thing to do? I think so, not only was
> it right technically but it was something backed up by the Last Call.
> Did we get the details right, did the text go too far or did it fall
> short? I don't know, its a judgment call. The end result was somewhere
> between the LC guidance and authors' opinions. Painful for the WG? Sure.
>
> On text that comes from the IESG: this is more common in recent years
> than it was before. I am one of the ADs who tends to do that, both for
> the documents that I sponsor and for resolving my Discusses. But I would
> rather not do it. But I often end up doing it if there is no progress
> otherwise; I want to get my sponsored documents approved and I want to
> reduce the list of my outstanding Discusses. If I can help my authors by
> proposing text, I will do it. But I would really like to see the
> document shepherds in active role here. Or at least the authors. The
> general guidance for authors whose document gets a Discuss is to first
> confirm whether the raised issue is a real one or not. If it is not, ask
> the Discuss to be cleared. Fight if needed! If it is real, work with
> your shepherd and WG to develop a proposal to fix the problem. Mail the
> proposal to the Discussing ADs in a timely manner. Address explicitly
> all components raised in a Discuss, either by explaining how they are
> not issues or providing a solution to resolve the issue.
Our fundamental collective job is defined in RFC 3935:
The mission of the IETF is to produce high quality, relevant
technical and engineering documents that influence the way people
design, use, and manage the Internet in such a way as to make the
Internet work better.
That means that it is *not* our collective job to ensure that a WG
consensus survives critical review by the IETF as a whole and by
the IESG, if there's reason to believe that the IETF as a whole
doesn't agree with the WG consensus. And it's clearly the IESG's
job to ensure that the critical review and final consensus (or lack
of consensus) occur.
That, IMHO, is the proper role of a DISCUSS and the proper reason
for delays in document approval. And if we see fluctuation in
these delays, and fluctuation in the amount of active intervention
by the ADs, it does not follow that the IESG is to blame. Maybe
there are external factors, maybe there are WGs that are forgetting
the IETF's mission, maybe our technology is getting harder and
more complex. So I'm very dubious about using either quantitative
*or* qualitative observations to point the finger at the IESG, or
at process issues in general, without digging much deeper.
Of course, the IESG needs to pay attention to delays,
so Jari's data (like the earlier data that Bill Fenner used to
produce) are very valuable. And of course, individual ADs
have to think carefully whether a given issue is or is not
worthy of a DISCUSS, and sometimes they get it wrong. But
that will always be true, however we tune the process and
procedures.
Brian
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf