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

Jari Arkko <jari.arkko@piuha.net> Sun, 29 June 2008 23:51 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E458A3A69DC; Sun, 29 Jun 2008 16:51:43 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616163A62D1 for <ietf@core3.amsl.com>; Sun, 29 Jun 2008 16:51:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3HR7VSO0QNk for <ietf@core3.amsl.com>; Sun, 29 Jun 2008 16:51:38 -0700 (PDT)
Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id A039F3A69DC for <ietf@ietf.org>; Sun, 29 Jun 2008 16:50:45 -0700 (PDT)
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id D0BBB1986FA; Mon, 30 Jun 2008 02:50:56 +0300 (EEST)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 40FD6198671; Mon, 30 Jun 2008 02:50:56 +0300 (EEST)
Message-ID: <4868202B.5050408@piuha.net>
Date: Mon, 30 Jun 2008 02:52:11 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
MIME-Version: 1.0
To: Lakshminath Dondeti <ldondeti@qualcomm.com>
Subject: Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)
References: <20080624203548.D3A8D3A67FD@core3.amsl.com> <48622DEB.7060403@piuha.net> <486267E0.8080704@qualcomm.com> <48628ED6.1000800@piuha.net> <4862BB84.4070401@gmail.com> <486380C4.6000607@qualcomm.com> <48642503.2000805@gmail.com> <4864F4A4.20103@qualcomm.com>
In-Reply-To: <4864F4A4.20103@qualcomm.com>
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Laksminath,

> My point was this: if a WG actually missed anything substantial and 
> that comes out during an IETF last call, and the shepherding AD 
> agrees, the document gets sent back to the WG.  If the shepherding AD 
> also misses or misjudges, any member of the IESG can send it back to 
> the WG for resolution.  What I think is not acceptable is for the 
> author and one or more DISCUSS ADs to hack up the document and publish it.

I think it would be useful to separate this discussion into different parts:

- what issues can be raised as a Discuss
- balancing the IETF opinion vs. WG opinion when there is a conflict
- how text proposals and draft revisions get created
- the role of shepherds, authors, and sponsors during this process
- how WGs become involved in changes from IETF Last Call and IESG reviews

The Discuss criteria document says quite a bit of the first topic. 
Earlier in this thread we talked about the second topic.

But I wanted to say a few words about changing text to resolve an issue. 
I said earlier that I would rather not be sending text proposals. I 
didn't want to imply that text coming from the IESG would be 
inappropriate. And certainly text coming from the author would not be 
inappropriate either. In fact, it is quite typical that the Discussing 
AD, possible directorate experts (if involved), and the author are the 
most likely suspects to come up with a way to resolve an issue. And most 
motived to get to a resolution. For instance, some of my documents have 
recently had issues with PMTU, and I asked the Discussing transport ADs 
to work with the authors to design a solution; this worked well.  In 
this sense "hacking the document" is not just OK but it may actually be 
the right thing.

The problems with the Discussing AD proposing text are more in the area 
of scalability. I prefer seeing the authors (or shepherds) be active and 
propose ways to resolve an issue. Or at least the initial proposal, 
review and suggestions from both sides may be needed to converge.

The big problem with any of the key players (author, Discussing AD, 
sponsoring AD) making changes relates mostly to the fifth item on my 
list. We are not very good at keeping the WGs in the loop. This is often 
done right, but far from always. I know I have problems in this area. 
One of the consequences is less control on the WG's side on 
controversial topics. Another one is reduced review of new text; errors 
might creep in. While the hacking part may have been OK, the publication 
is the problem.

I don't want to make excuses, but it may be helpful to understand some 
of the reasons behind this:

- Some issues are too small or obvious to warrant engaging the WG; 
getting the document approved on the given telechat day is seen as a 
higher priority. A fairly large number of Discusses get resolved on the 
day of the telechat, having been filed just days or hours before.

- The author - AD team works at a much faster pace in many cases than, 
say, the shepherd or the entire WG.

- Discussing AD is not on the WG list, does not know status of the 
document in other respects than his or hers own Discuss.

- Things falling in the cracks, e.g., Discussing AD thinks that the 
shepherd or the sponsoring AD is responsible for talking to the WG.

- No guidelines or processes relating to how the WG is actually involved 
in the discussion. In some cases we inform the WG what the Discusses are 
and what is being done about them. In other cases we actually run 
something resembling a WGLC or a consensus call. In yet other cases the 
new draft version announcement goes to the list as the sole 
announcement, and people are expected to look at the tracker for the 
Discusses.

- Desire to avoid lengthy discussions.

- Sponsoring AD trusts that the Discussing AD and author have made the 
right choices.

- WGs that for some reason have stopped caring about anything else than 
getting the document published. Not care about the particular hoop that 
they have to jump through to resolve a Discuss. (And by the same token, 
not care about Comment level review issues at all).

Some of these issues could be improved with a clearer definition of 
roles, and some additional guidelines on how to involve the WG.

Jari

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf