Re: A quick poll about RFC 7221

Erik Kline <ek@loon.com> Sat, 12 September 2020 21:49 UTC

Return-Path: <ek@google.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 6F13F3A09EC for <wgchairs@ietfa.amsl.com>; Sat, 12 Sep 2020 14:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.249
X-Spam-Level:
X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=loon.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 1hCZ9V1Us3Zp for <wgchairs@ietfa.amsl.com>; Sat, 12 Sep 2020 14:49:43 -0700 (PDT)
Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8E53A09E9 for <wgchairs@ietf.org>; Sat, 12 Sep 2020 14:49:42 -0700 (PDT)
Received: by mail-ua1-x92c.google.com with SMTP id g16so4238336uan.5 for <wgchairs@ietf.org>; Sat, 12 Sep 2020 14:49:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loon.com; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=v5NbmHH9oVtunw8YDu7bPqNVIl4n3fvw2cI3qI6pOKo=; b=f9+rbEGnzK5vIJIr8NIPGaSZ7lnwZ5Edsm0m4G6YM+HgbeSJqNC5ESVtFq6/U/wMXU DBZSxeXcjeSylzP1hKvKuFeeq3eJIXmafQOSb3Fq0JcA1h6bvh+R9IjQArPbVbQFVpcp NJj3cKspKvM0YfAg/NAtp+046s7JH/LcyzkXs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=v5NbmHH9oVtunw8YDu7bPqNVIl4n3fvw2cI3qI6pOKo=; b=OiA/rQjAYoZ0myK9/TEzJ67eQzSqCVt0nY+pCM1GK/QEtk0IFkvJvQpMXQQmsoczYD l/sgKn0q6AMp/TARS6AAdJBlmL16L9rBN+lPpUOmzONfhkgO87vZEPvVbuyvSOW0C1XO /Uf6oSVkSjGSOgKio7eyL0AvdoZ65vzXoKLEWDUjzuC5a+1pwlun1y+WOGCHq+IIdwFJ Lk7GYgH4v/rcK2APgcDe87F6CbmRsVvkmhRBpsIFxhmxvgydJ4kD2c41By6RfDJCyZNB hlhOBpbxkp8Ty5H/4/1x28afCfozUP/qioPLuhDfQwdvOiMTU9K2A3HjDAHcrrG8JZYz jTWg==
X-Gm-Message-State: AOAM532WA32JsHm/bTiGC3ZYBxAKixug0k60pieACnEZ6XF48NjSOMiX oh6mS8wy4o55rz2gQRWUZBmt66fzimLoc0IDMrs4eA06RWqgaw==
X-Google-Smtp-Source: ABdhPJzZxE7WeiEjyRxmHnOE1+w/A1iL/OBts8W8X0NS0bZtkYQT4uJAo1cWnhFlTp30oHGGR6ouTLvarTgZlF2ee+4=
X-Received: by 2002:ab0:5905:: with SMTP id n5mr4003424uad.90.1599947381524; Sat, 12 Sep 2020 14:49:41 -0700 (PDT)
MIME-Version: 1.0
References: <00e001d68940$bc73db70$355b9250$@olddog.co.uk> <7EFF456C-7DAA-4B1B-966F-DFADEC1EC0ED@tzi.org> <92710ea0-ae26-c59b-79a5-d7e5b1d89b18@joelhalpern.com>
In-Reply-To: <92710ea0-ae26-c59b-79a5-d7e5b1d89b18@joelhalpern.com>
Reply-To: ek@loon.com
From: Erik Kline <ek@loon.com>
Date: Sat, 12 Sep 2020 14:49:30 -0700
Message-ID: <CAAedzxrCF6KBVbjbb18FLnLKx__YOF5_gtHYnuu_MA5XvUygEA@mail.gmail.com>
Subject: Re: A quick poll about RFC 7221
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Carsten Bormann <cabo@tzi.org>, adrian@olddog.co.uk, wgchairs@ietf.org
Content-Type: multipart/alternative; boundary="00000000000056258c05af24c7c3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/wq_TL1aU_kDBJZogBi5dM6ZjnLE>
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: Sat, 12 Sep 2020 21:49:45 -0000

On Sat, Sep 12, 2020 at 2:40 PM Joel M. Halpern <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
> >
>
>