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

Lars Eggert <lars@eggert.org> Sat, 18 September 2021 07:25 UTC

Return-Path: <lars@eggert.org>
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 0B7AE3A0EF0; Sat, 18 Sep 2021 00:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
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 hzJDPLKtWTqo; Sat, 18 Sep 2021 00:25:15 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 5D0283A0EEB; Sat, 18 Sep 2021 00:25:15 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:7478:e25:9629:a3ae]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 798FB600639; Sat, 18 Sep 2021 10:25:00 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1631949900; bh=CtxbIZr/cF2ru16CYrGLw8ts/lbcKqfrMiPg4s2l8rw=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=eJ9qEcKq46FBcP9PTr9n8kvDu5iOXA1SvxOpcMUUlgDfnMT3Rxt+1Zfh5IGO+MzzE awp19v7HKJn1LR2LddhqfakTpZOdE+52vgS1SD50haawn+9FE6k9TO8juwSGR7m9nm qW+y2fOJ/5egnftORg60XcQOwkWquFosfiJgXO4M=
From: Lars Eggert <lars@eggert.org>
Message-Id: <F3E0166F-1ABC-445C-A269-54BB523BA5FA@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_31F02B09-C519-43BE-9587-FDC63B16295B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Sat, 18 Sep 2021 10:24:59 +0300
In-Reply-To: <A1F6409C-97AA-42A9-AAFD-C1AED39559E9@yahoo.co.uk>
Cc: "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>, GENDISPATCH List <gendispatch@ietf.org>, Barry Leiba <barryleiba@computer.org>, draft-eggert-bcp45bis.all@ietf.org
To: Lloyd W <lloyd.wood=40yahoo.co.uk@dmarc.ietf.org>
References: <DM4PR11MB543899B05B3BD7AD92459B3FB5DB9@DM4PR11MB5438.namprd11.prod.outlook.com> <A1F6409C-97AA-42A9-AAFD-C1AED39559E9@yahoo.co.uk>
X-MailScanner-ID: 798FB600639.A3A81
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/A26JBeA9qUFsAFybufKfWcZ9CEI>
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, 18 Sep 2021 07:25:22 -0000

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>rg>; 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