Re: [Manycouches] Francesca Palombini's Discuss on draft-ietf-shmoo-remote-fee-05: (with DISCUSS)

Mirja Kuehlewind <ietf@kuehlewind.net> Mon, 06 March 2023 10:49 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: manycouches@ietfa.amsl.com
Delivered-To: manycouches@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C3AC151B00; Mon, 6 Mar 2023 02:49:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evjYAn_gERCD; Mon, 6 Mar 2023 02:49:13 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [80.237.130.35]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68DF1C151AE6; Mon, 6 Mar 2023 02:49:13 -0800 (PST)
Received: from dslb-002-206-011-009.002.206.pools.vodafone-ip.de ([2.206.11.9] helo=smtpclient.apple); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1pZ8P0-000829-7H; Mon, 06 Mar 2023 11:49:10 +0100
From: Mirja Kuehlewind <ietf@kuehlewind.net>
Message-Id: <1D7E085A-DF71-46AA-A72F-9E021938C252@kuehlewind.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_042B3CEC-98AA-411D-B812-2F986E87A2D2"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\))
Date: Mon, 06 Mar 2023 11:48:59 +0100
In-Reply-To: <244E95B1EEFABFB1619CEC57@PSB>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>, The IESG <iesg@ietf.org>, manycouches@ietf.org
To: John C Klensin <john-ietf@jck.com>
References: <167534311969.58668.2191435841328718618@ietfa.amsl.com> <70B77F56-7A0D-4FBF-8BC5-55973C5ED6B1@ericsson.com> <AS1PR07MB8616C6521DFB37E53E8B6D0E98B29@AS1PR07MB8616.eurprd07.prod.outlook.com> <5fd815c5-bdfa-fc9f-76ec-1964c4294790@cs.tcd.ie> <C4C0C40532EEE180B26361A1@PSB> <0E5EE7E7-2CE4-4872-9B28-116E800506F4@kuehlewind.net> <244E95B1EEFABFB1619CEC57@PSB>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1678099753;31e4fa9b;
X-HE-SMSGID: 1pZ8P0-000829-7H
Archived-At: <https://mailarchive.ietf.org/arch/msg/manycouches/ZpsTNL31F_wfMDSszynWdRLX03w>
Subject: Re: [Manycouches] Francesca Palombini's Discuss on draft-ietf-shmoo-remote-fee-05: (with DISCUSS)
X-BeenThere: manycouches@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "List for discussion of remote meeting attendance and virtual IETF meetings, as well as for SHMOO working group" <manycouches.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manycouches>, <mailto:manycouches-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manycouches/>
List-Post: <mailto:manycouches@ietf.org>
List-Help: <mailto:manycouches-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manycouches>, <mailto:manycouches-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Mar 2023 10:49:18 -0000

Hi John,

I don’t think any principles we set up as a community are just recommendations but in the end they can be binding if they’re e.g. financially not viable.

This is what RFC8711 says:

It is the job of the
   IETF LLC to meet the administrative needs of the IETF and to ensure
   that the IETF LLC meets the needs of the IETF community.

Responsiveness to the community.  The IETF LLC is expected to act
      consistently with the documented consensus of the IETF community,
      to be responsive to the community's needs, and to adapt its
      decisions in response to consensus-based community feedback.

The role of the Board is to ensure that the strategy and conduct of
   the IETF LLC is consistent with the IETF's needs -- both its concrete
   needs and its needs for transparency and accountability.  The Board
   is not intended to directly define the IETF's needs; to the extent
   that is required, the IETF community should document its needs in
   consensus-based RFCs (e.g., as the community did in [RFC8718]) and
   provide more detailed input via consultations with the Board (such as
   takes place on email discussion lists or at IETF meetings).

So yes The LLC is not tightly bind by the community consensus but I would say they have a commitment to follow it. Especially if there is a conflict where financial concerns limit community needs, I would expect the LLC to consult with the community, as RFC8711 also says:

Transparency.  The IETF LLC is expected to keep the IETF community
      informed about its work, subject to reasonable confidentiality
      concerns, and to engage with the community to obtain consensus-
      based community input on key issues and otherwise as needed.

To give a different example, I believe current community guidance is that we want to hold 3 meetings with an in-person component a year. If we can't effort those meetings financially anymore, I wouldn’t expect that the LLC just decides to cancel a meeting without consultation with the IESG and probably also the rest of the community.

Again, it anything here is not clear (which I don’t think) that is an issue for RFC8711 and not the meeting fee draft.

Also I think the original question was more if the should give the LLC more detailed guidance in what to do if they detect a problem (probably because of misuse). However, I don’t think we have consensus on what the right guidance is and I think that's because without knowing exactly what the problem is, it is also hard to give the right guidance. So I simply think RFC8711 applies here as well: if the LLC detects a problem they should consult with the community. Leaving the document on the principle level without details guidance, means also we can react appropriate if we detect a problem without having to change the RFC. I think that also a problem we had too often in the past and being careful to not go to deeply into implementation details of such a principle document seems to be the right approach.

Mirja



> On 3. Mar 2023, at 22:55, John C Klensin <john-ietf@jck.com> wrote:
> 
> 
> 
> --On Friday, March 3, 2023 22:33 +0100 Mirja Kuehlewind
> <ietf@kuehlewind.net> wrote:
> 
>> 
>> 
>>> On 2. Mar 2023, at 14:29, John C Klensin <john-ietf@jck.com>
>>> wrote:
>>> 
>>> My personal guess is that FOO would turn out to be that this
>>> is ultimately a financial matter on which the LLC makes the
>>> final decisions as it always does and, while the community
>>> should be consulted, any IETF opinions are ultimately just
>>> advisory.  But, if that is the reality, then why not just say
>>> it and move on?
>> 
>> Because this is the wrong document to say it. This is true for
>> any principle and I think that's what I would already read
>> in rfc8711. I tried to explain that in the PR: RFC8711 has the
>> last word here. If that is not clear in RFC8711, we need to
>> update RFC8711 but not codify these kind of things in this
>> document.
> 
> Mirja,
> 
> I have not studied the PR but, if you say there that any
> recommendations in this document are ultimately just advice and
> subject to RFC 8711, I'm happy (or at least satisfied that
> reality is being properly reflected).  
> 
> I think that is necessary precisely because I don't think even
> RFC 8711, the LLC bylaws and organizing documents, or almost
> anything equivalent to them, says that "any principle" is just
> advice to the LLC.  Any principle of some particular types may
> be and, in particular, it is not clear on what matters the IETF
> can actually give the LLC instructions.  That boundary still
> seems fuzzy.  That is probably a conversation best left to
> another time and certainly should not hold up this document.
> 
> thanks,
>   john
> 
>