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

On 6/25/2008 2:41 PM, Brian E Carpenter wrote:
> 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.

But, surely the WG consensus counts as part of the overall IETF 
consensus process, doesn't it?  Please see the example in my response to 
Jari.  The shepherding AD (or at least the document shepherd) has an 
idea of the WG consensus as well as the IETF consensus.  We cannot 
simply weigh the latest opinions more than all the discussions that have 
happened as part of the WG consensus.

> 
> 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.

I am suggesting that we make further progress along the lines of the 
definition of the role of the document shepherd and reassert (or clearly 
define and state the expectations) on the roles of the document shepherd 
and shepherding AD.

regards,
Lakshminath

> 
>     Brian
> 
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf