Re: [Gendispatch] Large cluster [Re: I-D Action: draft-eggert-bcp45bis-01.txt]

Eric Rescorla <ekr@rtfm.com> Sat, 03 April 2021 19:47 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: gendispatch@ietfa.amsl.com
Delivered-To: gendispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7943A11F0 for <gendispatch@ietfa.amsl.com>; Sat, 3 Apr 2021 12:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 WNQlauCAVJRB for <gendispatch@ietfa.amsl.com>; Sat, 3 Apr 2021 12:47:24 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 3A26E3A11ED for <gendispatch@ietf.org>; Sat, 3 Apr 2021 12:47:24 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id k8so5968063iop.12 for <gendispatch@ietf.org>; Sat, 03 Apr 2021 12:47:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0XpI0HlKDBTqMmnvwwttmfsRCqYW57BRhAe6RnKWwC0=; b=DoUe+rJGRgD6qZRQTyTIS7vSbZ4gxhYQpXeAnvEC+5kOuNddNknYcWTcsv27BGibUj Jusm3PLcxtJHeE4GT4ZPikpG0tELM+gB2ZHCgoT0nqRQjP37ThI1rwJEk5VfDL6KkFCY oekxyuieJuyRHv7FzvspC8nppycBr1ofDgIpd8zw2jBxP2x4HXNK7vEAHs1FEAeSJI3m KSMvZfXmHYFgt9hb15+KBlg5JlMfPZnAH6Vb4EHBPQThfoaR4bwj1DsfabozFa+rQZkk 6tsgVhJJVaTobamgHohLCofenqHd0z55R3+Tnc/k5C0L3eNzsI1dvmwlXjTinA1tj+cG XSLw==
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:from:date :message-id:subject:to:cc; bh=0XpI0HlKDBTqMmnvwwttmfsRCqYW57BRhAe6RnKWwC0=; b=sVa7leUp+d4xO+GQ96h5c/3IxtShWncMSxTebBNuGWD3Pj+feQ/YLSCcrcJ3CS80xN 8tsCjCZAUXHJZhPuo369VxNutgmAQcW2OG72qOKEd004ByHqEkGtqYpC4ZMtL6UgufMU +IE24GdDh6CslSs4nDYbeAiG8T7YpwhFYPzc0TmEaHuEj5pKI7X9XehZNdNZ3auAGsGg vld8h03y+nCYSGe3JozNws9XxuNNpJVTNa3VzWFRNjVPIYmfB1dEXUjsPEC2GHgGcdZj Ri7KtpM7BX3rRWT+Ew0oadElgtuOOKO3RO7YoQ7rCthGf7j5TfIv4gip3ZkXTTkUtu6n LhPw==
X-Gm-Message-State: AOAM532+/O2KALrVwbJnBpUPguCv/0XGxW4Oc3ZfGOdiTEJGeeOyvgAJ Tf7+ULywYKN/xzSHRg0INV5tfhKqFtoMltoQt9UP3w==
X-Google-Smtp-Source: ABdhPJzf/sQnF5J5pUZOwKakrBBNXod3SysyW2YF4pU8KBPBBP0WjkH6JN3g2M8qite+5vEqMVal8w75u+sjkUEJT4s=
X-Received: by 2002:a05:6638:e93:: with SMTP id p19mr17627331jas.10.1617479243073; Sat, 03 Apr 2021 12:47:23 -0700 (PDT)
MIME-Version: 1.0
References: <161701910454.13044.908232164554537032@ietfa.amsl.com> <55b4e061-f25d-8958-1e75-868bec0c735e@gmail.com> <D277EB6F-FDB1-4588-A77B-FC29B0FB782F@eggert.org> <963ED8F3-712F-4E8D-BF29-A3E7735E4641@mnot.net> <53AB2142-8BC2-43AC-86E7-EC9F1E72D9D3@cisco.com> <71B14C3D-AF8C-4C7F-9C14-03686F499E4D@eggert.org> <0B3C59C9-5057-4DC2-AF1E-CA3216436996@cisco.com> <10400F6C-C9E3-4136-A4FE-D97B83E6F67C@eggert.org> <9134c6cc-8f44-e4e7-c4aa-8a0dd271adf9@gmail.com> <CABcZeBPwW-fqRhsF0LHhJutZ++emRL816+05BgntZEA2Ga0Lsg@mail.gmail.com> <7b5abd62-092a-69c4-f818-d8870a7324b7@gmail.com>
In-Reply-To: <7b5abd62-092a-69c4-f818-d8870a7324b7@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 3 Apr 2021 12:46:47 -0700
Message-ID: <CABcZeBPgjfa+Z1qGU24dOA+gOmCtrT3rPLG-AJ4KJPxAUqOBwg@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Lars Eggert <lars@eggert.org>, GENDISPATCH List <gendispatch@ietf.org>, Eliot Lear <lear=40cisco.com@dmarc.ietf.org>, Eliot Lear <lear@cisco.com>
Content-Type: multipart/alternative; boundary="000000000000b71b7905bf16bb8c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/jXbNoV7txSC2y-2MifguoiCsTlg>
Subject: Re: [Gendispatch] Large cluster [Re: I-D Action: draft-eggert-bcp45bis-01.txt]
X-BeenThere: gendispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Area Dispatch <gendispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gendispatch/>
List-Post: <mailto:gendispatch@ietf.org>
List-Help: <mailto:gendispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Apr 2021 19:47:29 -0000

On Tue, Mar 30, 2021 at 3:06 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> Off topic, but just to clarify my intention:
>
> On 31-Mar-21 09:20, Eric Rescorla wrote:
> >
> >
> > On Tue, Mar 30, 2021 at 1:13 PM Brian E Carpenter <
> brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> >
> ...
> >     > We can always revise it again, when there is consensus on more
> fundamental changes.
> >
> >     Agreed, and that needs a much deeper analysis. And IMNSHO there are
> many much more important process issues to resolve than the occasional
> unruly threads on ietf@. Just to pick one at random, what can we do to
> prevent something like Cluster 238 ever happening again?
> >
> >
> > This is a bit hard to answer without having a clearer statement
> > of what went wrong with C238.
>
> There's a partial analysis at https://www.ietf.org/blog/webrtc-pandemic/


Yes, I've read that. I agree it's right substantively, but it's not clear
to me what the ill effects people are most concerned with are.




> > I could imagine several objections here:
> >
> > - We shouldn't have projects which require changes to large
> >   chunks of the protocol suite.
> >
> > - We shouldn't have to publish all the documents in those
> >   projects simultaneously.
> >
> > - It's hard for the RPC to manage the simultaneous publication
> >   of all those documents.
> >
> > - Something else?
> >
> > It seems like each of these might have different solutions.
>
> Indeed, and some of them are related to the old question of how to
> dynamically document complex standards with components at different
> maturity levels. My real question is: are we going to duck the hard
> questions about the IETF standards process?
>

I'm not sure it's so much a matter of ducking the hard questions as having
deep disagreements about their nature and the constraints we are operating
under. For instance, ISTM that the primary source of this problem is the
insistence on immutability of the published documents and therefore of only
publishing document X when all its dependencies are published, rather than
when it is otherwise "ready" with the expectation that it might be
necessary to revise it if issues are found in the dependencies. However, I
am aware that many disagree strongly with that position. Hence, it is
difficult to make progress.

-Ekr