Re: A quick poll about RFC 7221

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 13 September 2020 15:44 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85FC3A09FB for <wgchairs@ietfa.amsl.com>; Sun, 13 Sep 2020 08:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.048
X-Spam-Level:
X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NruPq8iLOuvk for <wgchairs@ietfa.amsl.com>; Sun, 13 Sep 2020 08:44:51 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A4B3A09DB for <wgchairs@ietf.org>; Sun, 13 Sep 2020 08:44:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BqDMQ62Srz6GQjD; Sun, 13 Sep 2020 08:44:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1600011890; bh=+hmA0eaNhM5m1MeoclsYppHfcDGLaeN+MNaUfhxf4fU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=DajKPsrqdqbBlVsZgqRCtefN+PAmkxmCBjEf3Snrx7fvs9HNziWuJ8KzRmz8Ymay1 Nh9kDj08o7dTa1yaCkfB7DsGO/aoP1X2fNKKszImebhuUs/lceXf8SMN2sCfZVo5TN J9Jo51M/62qh/7emCapJbfrEDGAtfoIxU0w2BylE=
X-Quarantine-ID: <ItkgOg_r9gaN>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4BqDMQ2RPGz6GQj9; Sun, 13 Sep 2020 08:44:50 -0700 (PDT)
Subject: Re: A quick poll about RFC 7221
To: David Noveck <davenoveck@gmail.com>
Cc: WG Chairs <wgchairs@ietf.org>
References: <00e001d68940$bc73db70$355b9250$@olddog.co.uk> <7EFF456C-7DAA-4B1B-966F-DFADEC1EC0ED@tzi.org> <92710ea0-ae26-c59b-79a5-d7e5b1d89b18@joelhalpern.com> <CAAedzxrCF6KBVbjbb18FLnLKx__YOF5_gtHYnuu_MA5XvUygEA@mail.gmail.com> <CADaq8jeqjdJkVxEQ0qQSgvRBjYwmWAJz7qYq9cfWTh8AUXE1rg@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <c1c39cce-d6fa-f6b3-dfec-ff01c83a358f@joelhalpern.com>
Date: Sun, 13 Sep 2020 11:44:48 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <CADaq8jeqjdJkVxEQ0qQSgvRBjYwmWAJz7qYq9cfWTh8AUXE1rg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/FpA56axz6ksQaijPUxJnXpWINrU>
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Working Group Chairs <wgchairs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wgchairs/>
List-Post: <mailto:wgchairs@ietf.org>
List-Help: <mailto:wgchairs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Sep 2020 15:44:53 -0000

Without trying to revisit ancient history, what you describe is not the 
case.

The IESG never owns the document.  One can argue that the IETF owns it 
during and after IETF last call.  If events transpired as you say, I 
would have said that the chairs were obliged to notify the WG of the 
changes.  If they were indeed of that magnitude, a new WG LC could well 
have been appropriate.  In some cases, I have seen a new IETF LC as well 
when the changes were sufficiently large.

Yours,
Joel

On 9/13/2020 8:50 AM, David Noveck wrote:
> I haven't seen this be a major problem in recent years, although it is 
> an illustration of the fact that, once WGLC has happened, its ownership 
> of the document has effectively lapsed and only the authors have a role 
> in dealing with potential changes that would interfere with the wg 
> consensus.
> 
> Way back in 2003, the internationalization section of rfc3530 was 
> essentially rewritten at IESG direction.  The fact that the wg was not 
> aware of the change meant that nobody implemented it.  As a result, all 
> nfsv4 implementations followed the WGLC document rather than the iesg's 
> revision. The wg had the last word since they were the implementers as 
> well.  This was all corrected for nfsv4.0 by rfc7530
> 
> I'm not sure what would have happened if the wg had been made aware of 
> this change but the process would probably have been quite contentious. 
> It almost certainly would have prevented rfc5661 internationalization 
> from following the unimplemented rfc3530 one. We now have to deal with 
> this as part of rfc5661bis.  Sigh!
> 
> On Sat, Sep 12, 2020, 5:49 PM Erik Kline <ek@loon.com 
> <mailto:ek@loon.com>> wrote:
> 
> 
> 
>     On Sat, Sep 12, 2020 at 2:40 PM Joel M. Halpern <jmh@joelhalpern.com
>     <mailto:jmh@joelhalpern.com>> wrote:
> 
>         Actually Carsten, I would phrase your comment differently.
> 
>         We allow the editors of documents to make changes during the
>         process.
>         We expect them to tell the WG what they are doing.
>         The important part is that if the WG disagrees, the editors are
>         required
>         (not merely expected, required) to make the changes to conform
>         with the
>         WG rough consensus.
> 
>         Many years ago I fired a WG document editor for refusing to do so.
>         I have come close to doing so more than once since.
> 
>         The document belongs to the WG, not to the editor.
>         For practical reasons, we allow the editors a lot of room to
>         work on the
>         document.
> 
>         The WG LC should, if things are going right, serve as a final
>         confirmation that nothing has gone wrong.  That does not mean it is
>         unnecessary.
> 
> 
>     Sadly changes can also creep in during IETF LC and IESG eval (and
>     during AUTH48), without much awareness by the working group(s).  :-/
> 
>         Yours,
>         Joel
> 
>         On 9/12/2020 4:50 PM, Carsten Bormann wrote:
>          > Interesting.  I didn’t actively know about this document.
>          > (I might have heard about it in 2014, but have since
>         forgotten about it.)
>          >
>          > The title is misleading:
>          >
>          >             Handling of Internet-Drafts by IETF Working Groups
>          >
>          > Instead, it mostly is about adoption of WG documents (and the
>         selection of authors for that segment of its life), except for
>         the introduction where it states in passing that a WG document
>         is (at least substantively) always representing the WG rough
>         consensus.
>          >
>          > This is the second time I need to use the term “process
>         confabulation” today.  While having this statement in an (albeit
>         informational) document is a great stick with which WG chairs
>         can beat up errant authors, it does not reflect reality (even if
>         it does more so in the times of development by github than it
>         used to be), not even an actually always desired process.  (If
>         it actually were true, we wouldn’t need a WGLC.)
>          >
>          > The reality is that in many WGs, authors have pretty wide
>         authority [sic!] to generate new I-Ds that they believe will
>         bring the process forward, and obtain feedback [that could be
>         (but most often is not) judged by the WG chairs to represent WG
>         consensus] only after publishing the new I-D.  Very large WGs
>         may have more elaborate processes that might be closer to
>         mini-WGLCs before accepting changes (in particular with github’s
>         help), but as a universal process requirement, requiring
>         consensus before publishing each update would really impede
>         progress.  The WG needs something concrete to discuss, and I-Ds
>         are that concrete writeup that is input, not output of the
>         current discussion.
>          >
>          > Grüße, Carsten
>          >
>