Re: [Gendispatch] New Version Notification - draft-eggert-bcp45bis-04.txt

Eric Rescorla <ekr@rtfm.com> Sat, 25 September 2021 02:19 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 152A63A0FF0 for <gendispatch@ietfa.amsl.com>; Fri, 24 Sep 2021 19:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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.20210112.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 C3k0Z1RZW1n6 for <gendispatch@ietfa.amsl.com>; Fri, 24 Sep 2021 19:19:10 -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 29C563A0FEE for <gendispatch@ietf.org>; Fri, 24 Sep 2021 19:19:10 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id m11so15097873ioo.6 for <gendispatch@ietf.org>; Fri, 24 Sep 2021 19:19:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t20mY6cTp5o9kT5chtVIhsg5D9+zxTgYAnYZH0PBOtY=; b=VSmAtzhl763mga+H0RXk2ldXQzh6J22C2pY3J1IIBMuMAUigfaCRFU4x3dZkJojkRy 7xa3i1zylJHDeNpFj7OqEXYecyQTlz+PKDNS9zCO4UK0BJoGRX6JtsNOIS9TNw/LA6R8 wUPaNalOxsQoTu/jDXJEttJxR58bp2WYaABOHOs0zhtpxcCQMOmgu2/U+l3xbXKeQZFJ a+r3sJ6BkspKWPqHtPWe76ZiraLnQ9SxI43p/U07TMT6kEybalwAzm8taC9FVauK2ux1 rhzhBe+x5eGIErS8EkVEvmTniGr9mfEDCJEpAVkDCq3BHeIDuYy3h1Iyklq6jN2Kauu/ 8iEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t20mY6cTp5o9kT5chtVIhsg5D9+zxTgYAnYZH0PBOtY=; b=IreAEAu94WvnlZqZJtXuyMixEOt5xjTiqQxbPP8YLddW7q/04NyktlGaGAWj4YAbCj rINuYHdcczl320+k6QVRzlxnc3jvFdMQqL+a6JddvEfVhVaA05u/Z7ODqmn1kWqV41u4 ixhy80cQ82dxwjxDe4q+qXadiBefHnsda+bj1Vn0AAW4vrAm5r2hXEim0WNkJIHWChQc fuMeeV3hjsoz/ovkZ+38PJKL3xHlK98vZ4+6UiYKyloITc57MRaHEIj0/Yj1HsGeXB2A 5BeLNBA7eLaDZ+zUOvPJIqpjbnyHfp/Fe/Nc6foYXwu3komnGbjvDLCi/S639epymIX9 mX9Q==
X-Gm-Message-State: AOAM533ux7OGX+ph63Kimv0axYAbP/XN2E6zzrIoSIlCg7O+6Etjr2b0 B6xqQ5nZIyaF0xAfpksZ7Ra48Mc8EeKYA2seumh8Bw==
X-Google-Smtp-Source: ABdhPJxQjkq5SuKpMKHZaz2YBGvUPscIgo62QRsR8A/UJLGbC/hYcWIKQsSQdeJRcWYlGZOIyg3vL18k8O59uyKVXfA=
X-Received: by 2002:a05:6602:1a:: with SMTP id b26mr11635721ioa.0.1632536348732; Fri, 24 Sep 2021 19:19:08 -0700 (PDT)
MIME-Version: 1.0
References: <DM4PR11MB543899B05B3BD7AD92459B3FB5DB9@DM4PR11MB5438.namprd11.prod.outlook.com> <A1F6409C-97AA-42A9-AAFD-C1AED39559E9@yahoo.co.uk> <F3E0166F-1ABC-445C-A269-54BB523BA5FA@eggert.org>
In-Reply-To: <F3E0166F-1ABC-445C-A269-54BB523BA5FA@eggert.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 24 Sep 2021 19:18:32 -0700
Message-ID: <CABcZeBOu-QMv6e00gOsZivjvzkKr1G3b+pS5R6=UGx2hMAv5Uw@mail.gmail.com>
To: Lars Eggert <lars@eggert.org>
Cc: Lloyd W <lloyd.wood=40yahoo.co.uk@dmarc.ietf.org>, draft-eggert-bcp45bis.all@ietf.org, Barry Leiba <barryleiba@computer.org>, GENDISPATCH List <gendispatch@ietf.org>, "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000026443205ccc87d69"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/_J-492rFXUBdLMiPt9pIdJAsunU>
Subject: Re: [Gendispatch] New Version Notification - draft-eggert-bcp45bis-04.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, 25 Sep 2021 02:19:15 -0000

I am in favor of publishing this document. Those who would prefer some more
global change to the SAA process should instead propose those changes in
the form of a draft.

-Ekr


On Sat, Sep 18, 2021 at 12:25 AM Lars Eggert <lars@eggert.org> wrote:

> Hi,
>
> On 2021-9-17, at 13:31, Lloyd W <lloyd.wood=40yahoo.co.uk@dmarc.ietf.org>
> wrote:
> > As a latecomer to this thread, and as someone with rather more recent
> > experience of the SAAs than most... section 4 says:
> >
> >    A sergeant-at-arms (SAA) is an officer appointed by a deliberative
> >    body to keep order during its meetings [SAA-WIKIPEDIA].  SAAs for the
> >    IETF discussion list are appointed by the IETF Chair
> >
> > The contradiction here is obvious. An SAA is appointed by a deliberative
> body,
> > during its meetings, and the IETF Chair is not a deliberative body.
>
> I added this quote from Wikipedia, because SAA is a pretty US/UK-centric
> term, and I received feedback that it is confusing to participants from
> other regions when they first encounter it.
>
> I'd be happy to point to a different explanatory definition. I'd also be
> happy to remove it again.
>
> > An SAA
> > should be appointed by the deliberative body itself, which is to say,
> the list
> > itself, by the list members.
>
> Maybe it should, but BCP45 didn't set it up this way and this draft is not
> intending to change that.
>
> > Furthermore, this draft is written by the current IETF Chair. So, this
> can
> > be seen as shoring up and reaffirming the Chair's power.
>
> If you compare this document to BCP45, you will find that it actually
> significantly reduces the power of the IETF Chair. First, BCP45 allows for
> the Chair to directly impose posting restrictions. This hasn't been the
> practice for quite a number of years, and this document hence removes that
> option, placing it entirely at the disposition of the SAAs. Second, it
> clarifies that the appeals process applies here, which BCP45 left somewhat
> unclear.
>
> > I strongly object to this. Documenting or redocumenting an existing
> process
> > doesn't make that process right, and this violates the basic concept of
> the
> > SAA as described.
>
> If you would like to propose changes to the BCP45 SAA process, please do
> so. Objecting to this document isn't going to result in such changes,
> because BCP45 would remain unchanged.
>
> Thanks,
> Lars
>
>
> >
> > Lloyd Wood
> > lloyd.wood@yahoo.co.uk
> >
> >> On 15 Sep 2021, at 18:48, Rob Wilton (rwilton) <rwilton=
> 40cisco.com@dmarc.ietf.org> wrote:
> >>
> >> 
> >> I’ve not seen any further comments on this thread since Saturday.
> >>
> >> My interpretation is that Lars and Barry are supportive of this change.
> >>
> >> Brian, my interpretation is that Lar’s proposed text is acceptable to
> you.  Please clarify if this is not the case.
> >>
> >> I would like to wait until Friday to see if there are any further
> comments on Lar’s proposed text.  If there are no strong objections then on
> Friday I’ll ask Lars to post a -05 with the change and I’ll kick off IETF
> LC.
> >>
> >> Regards,
> >> Rob
> >>
> >>
> >> From: Brian Carpenter <brian.e.carpenter@gmail.com>
> >> Sent: 11 September 2021 08:38
> >> To: Lars Eggert <lars@eggert.org>
> >> Cc: Barry Leiba <barryleiba@computer.org>rg>; GENDISPATCH List <
> gendispatch@ietf.org>gt;; draft-eggert-bcp45bis.all@ietf.org
> >> Subject: Re: [Gendispatch] New Version Notification -
> draft-eggert-bcp45bis-04.txt
> >>
> >> Hi Lars,
> >> Since 2026 doesn't mention conflict of interest, that's probably the
> procedure. Not entirely satisfactory, but we could live with it.
> >>
> >> Regards,
> >>     Brian Carpenter
> >>     (via tiny screen & keyboard)
> >>
> >> On Sat, 11 Sep 2021, 17:37 Lars Eggert, <lars@eggert.org> wrote:
> >> Hi Brian,
> >>
> >> Is that an option in your reading of 2026? They way I understand it is
> that if the AD is conflicted, the entire IESG is the next step?
> >>
> >> Thanks,
> >> Lars
> >>
> >> --
> >> Sent from a mobile device; please excuse typos.
> >>
> >> > On Sep 10, 2021, at 23:20, Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
> >> >
> >> > On 10-Sep-21 23:01, Barry Leiba wrote:
> >> >> That works for me, Lars, and thanks.
> >> >>
> >> >> I see Brian's point about Gen AD instead of IETF Chair, but I don't
> >> >> agree with it here, because the SAAs are explicitly appointed by the
> >> >> IETF Chair, not related to the Gen Area.
> >> >
> >> > You're correct. There's still the corner case where the IETF Chair is
> >> > conflicted - for example, if the message(s) objected to by the SAAs
> >> > made allegations about the IETF Chair themself. Probably another AD
> >> > should be the first recourse in that case.
> >> >
> >> >   Brian
> >> >
> >> >>
> >> >> Barry
> >> >>
> >> >>> On Fri, Sep 10, 2021 at 3:11 AM Lars Eggert <lars@eggert.org>
> wrote:
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> I have a proposed change to use the normal RFC2026 appeals process
> in https://github.com/larseggert/bcp45bis/pull/7/files. This is the
> current change:
> >> >>>
> >> >>> --- a/draft-eggert-bcp45bis.md
> >> >>> +++ b/draft-eggert-bcp45bis.md
> >> >>> @@ -192,8 +192,8 @@ manner.
> >> >>>
> >> >>> Because an SAA serves at the discretion of the IETF Chair - even if
> the IETF
> >> >>> Chair is not otherwise involved in the operation of the SAA team -
> any SAA
> >> >>> -decision could be appealed to the IAB. The IAB shall then review
> the situation
> >> >>> -and attempt to resolve it in a manner of its own choosing.
> >> >>> +decision can be appealed to the IETF Chair, per {{!RFC2026}}.
> Decisions by the
> >> >>> +IETF Chair can be appealed to the IESG as whole, again per
> {{!RFC2026}}.
> >> >>>
> >> >>> # Security Considerations
> >> >>>
> >> >>> Please let me know if this expresses what is desired?
> >> >>>
> >> >>> Thanks,
> >> >>> Lars
> >> >>>
> >> >
> >> > --
> >> > Gendispatch mailing list
> >> > Gendispatch@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/gendispatch
> >>
> >> --
> >> Gendispatch mailing list
> >> Gendispatch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/gendispatch
> > --
> > Gendispatch mailing list
> > Gendispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/gendispatch
>
> --
> Gendispatch mailing list
> Gendispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/gendispatch
>