ietf
[Top] [All Lists]

Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)

2008-06-25 14:42:16
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>