Re: [Manycouches] AD review: draft-ietf-shmoo-remote-fee-01

Lars Eggert <lars@eggert.org> Thu, 19 August 2021 11:11 UTC

Return-Path: <lars@eggert.org>
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 BEA0D3A0AC3; Thu, 19 Aug 2021 04:11:02 -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=ham 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 QYJBVpdvf2wV; Thu, 19 Aug 2021 04:10:56 -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 58E5C3A0AB2; Thu, 19 Aug 2021 04:10:56 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:21f6:18fc:5ac9:4ac4]) (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 1013A600370; Thu, 19 Aug 2021 14:10:42 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1629371443; bh=BVesn7OWLy2TWk7XujgLsG20KgZ2Qgr2ERG/i05prbk=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=K6/GkDfhR66wbgd37pTDqNmvKSi4RjfkF1Xr6pzirXtIrnW149C8CiMZeZDK1VadF WUeiEPVyQOc9Z8o1Op4rKt//IpU36+4IqahVzXRmENURKu18Dls8PaRJc5hH6rPwpn h85TwJjvr+YJOBXySIqNkH1Vfawq54K/wwPwgW8U=
From: Lars Eggert <lars@eggert.org>
Message-Id: <769F2002-6B87-4629-B5E0-A2AA85AA0362@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_D59C01BE-3711-4ED3-A99F-4192D04BDFDF"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Thu, 19 Aug 2021 14:10:40 +0300
In-Reply-To: <1D5662C7-1F9D-479E-B75C-A5B1BB17B98B@kuehlewind.net>
Cc: shmoo-chairs@ietf.org, draft-ietf-shmoo-remote-fee@ietf.org, manycouches@ietf.org
To: Mirja Kühlewind <ietf@kuehlewind.net>
References: <D047A889-3721-4259-8105-421AF12D4C14@gmail.com> <E77594D8-DAE7-470A-92E8-C7EE1AD2F594@eggert.org> <1D5662C7-1F9D-479E-B75C-A5B1BB17B98B@kuehlewind.net>
X-MailScanner-ID: 1013A600370.A1FA2
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/manycouches/itvWi_bnLWZnrGqX5mMA0qGI79I>
Subject: Re: [Manycouches] AD review: draft-ietf-shmoo-remote-fee-01
X-BeenThere: manycouches@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 19 Aug 2021 11:11:03 -0000

Hi,

On 2021-8-19, at 13:31, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
>> Section 2. , paragraph 2, discuss:
>>>  The principle this document states is simple: there must always be an
>>>  option for free remote participation in any IETF meeting and related
>>>  events that are part of the IETF's open process [RFC3935], whether or
>>>  not that meeting has a physical presence.
>> 
>> SHMOO is chartered to provide guidelines for fully online meetings. This
>> document proposes a guideline for any meeting with a remote component, which
>> seems to go beyond the charter?
> 
> SHMOO is chartered to provide guidance that is needed to organise fully online meetings but I don’t think the charter necessarily prohibits to provide this guidance as a more general principle that is applicability beyond _only_ fully online meetings. The charter actually says:
> 
> "The SHMOO working group is therefore chartered
> to document high-level guidance and principles to the IESG and the IETF LLC.”

yes. But the charter item this document (I think) intends to deliver on says "Determinations about the meeting fee for fully online meetings."

>> Also, (minor issue) what "related events?" RFC3935 doesn't define any, so
>> what is meant here?
> 
> The reference to RFC3935 is related to “open process” (principle 1 in the mission statement). If that is not clear, maybe we need to rephrase that sentence…?

Could you then more clearly define what "related events" this guidance intends to apply to?

>> Section 3. , paragraph 4, discuss:
>>>  These and other operating costs of the IETF are also cross-financed
>>>  by income generated through meeting fees.  The intention of this
>>>  document and the principle stated herein is not to make participation
>>>  free for everyone but to always have a free option that can be used
>>>  without any barriers other than the registration procedure itself.
>>>  As long as there are still enough paying participants to cover the
>>>  base costs, additional participant can effectively be added without
>>>  increasing expenses.
>> 
>> I think this document should be much clearer about this important distinction,
>> i.e., that it requires that a free remote option be available *to some*
>> participants *if* a meeting offers remote participation (but see my point about
>> the charter above) *insofar* that is financially viable as (presumably) decided
>> by the LLC Board. The abstract and the document until now can be read to mean
>> "online participation must be free".
> 
> Yes, this is the principle in this document: “There must always be a free option for online participant”. This is a base principle the community agree to and from my point of view the LLC needs to consider this in their financial planning and not the other way around. See further below.

I question whether it's possible for the LLC Boards to always unconditionally plan for this, esp. for fully online meetings. If the ratio of paid to free registrations tilts (by a lot), this might at some point require us to raise registration fees, possibly increasing the imbalance. There are other ways to make up for this (ask sponsors for more money, rely on ISOC more, etc.) but all of them have downsides as well.

Note that I'm not questioning the aspiration to always offer unlimited fee waivers. We should definitely strive to do this. But we might end up in a situation where doing so may have financial and organizational downsides. I wouldn't want to constrain our options in the unlikely event this happens.

>> Section 4. , paragraph 5, discuss:
>>>  The LLC is responsible to ensure the financial stability of the IETF
>>>  and therefore should monitor trends in the use of the free
>>>  participation option that could endanger the viability of the IETF.
>> 
>> Because the LLC Board is responsible for the financial stability of the IETF, it
>> IMO must do more than "monitor trends" - it must be able to impose limits on the
>> use of the free participation option if that threatens the financial stability
>> of the IETF.
> 
> If the free participation option threatens the financial stability of the IETF, the LLC has done a poor job. Relying on registration fees is a risk anyway (given the many time we discussed impacts of decreasing registration numbers) and if the LLC sees that this path is not viable anymore to ensure financial stability, I think they need to consider a different model. However, so far this model works reasonable well, so I’m not requesting any change (and this discussion is out of scope for shmoo and this doc) but what we say in this document is that the LLC need to monitor so they can act in case the current model doesn’t seem viable anymore.

The problem is that the current text in my reading doesn't leave the LLC any leeway if "the current model doesn't seem viable anymore". We'd need to obsolete this BCP, no?

> We discussed this multiple time in the group and I believe there is consensus that having a limit on free registration is not thee right answer to this much more general problem. However, if other want to chime in, I’m happy to have more discussion about this point.

In practice, i.e., assuming that some fraction of the community would always choose a paid registration, we're OK, because the incremental cost of a remote participant is low. But I think there are maybe more theoretical situations in which we may run into issues. I'd hence prefer if this BCP described the aspiration and maybe required an explanation for the rare case where it couldn't be met.

>> -------------------------------------------------------------------------------
>> Minor comments
>> -------------------------------------------------------------------------------
...
>> Section 1. , paragraph 2, comment:
>>>  Remote participation for IETF in-person meetings has evolved over
>>>  time from email-only to live chat and audio streaming, and,
>>>  currently, to a full online meeting system that is tightly integrated
>>>  with the in-room session and enables interactive participation by
>>>  audio and video.  Due to this evolution, and because most in-person
>>>  attendees paid registration fees and this has been sufficient to
>>>  support the meeting, online participation has historically been free
>>>  for remote attendees.
>> 
>> The "Due to this evolution" part seems wrong, i.e., remote participation hasn't
>> historically been free because we had an evolution from email-only to Meetecho.
> 
> Is it okay to just remove the "Due to this evolution”?

WFM

>> Section 2. , paragraph 5, comment:
>>>  It should be noted that opennees as defined in [RFC3935] should be
>>>  seen as open and free.  While the principle in RFC3935 is explicitly
>>>  noting that this principle includes a requirement to open basically
>>>  all our documents and documentation and making them accessible over
>>>  the Internet, it was probably written with mainly having email
>>>  interactions in mind when talking about participation.  This document
>>>  extends this principle to explicitly cover online participation at
>>>  meetings.
>> 
>> This paragraph seems to reinterpret RFC3935 (i.e., "open" means "open and free")
>> in a way that would require this BCP to update RFC3935. I'm personally not
>> convinced that this reinterpretation is fully justified.
> 
> RFC3935 says:
> 
> "Open process - any interested person can participate in the work,
>      know what is being decided, and make his or her voice heard on the
>      issue.  Part of this principle is our commitment to making our
>      documents, our WG mailing lists, our attendance lists, and our
>      meeting minutes publicly available on the Internet.”
> 
> My interpretation was that “publicly available” actually implied free to access. Do you think that is an over-interpretation?

No, that I agree with. But I think the argument here rests on the "can participate in the work" bit of this text.

Rather than saying "RFC3935 should be understood so-and-so" (which IMO would require an "updates" relationship), it might be OK to say something like "we build on the openness principle in RFC3935 and expand on it by attempting to maximize participation in online meetings" or something like that. But maybe this is too nitty?

>> Section 2. , paragraph 5, comment:
>>>  Having said that, it is of course strongly anticipated that at least
>>>  all sessions of the main agenda of an IETF plenary meeting provide an
>>>  option for remote participation.
>> 
>> Is the "main agenda" just the agenda? Or is this supposed to mean something
>> else? (This sentence could also IMO just be removed.)
> 
> Yes, there are also a lot of other meetings e.g. in the lunch breaks, like the chairs training or the host talk which I didn’t consider as the main agenda. However, maybe that is not clear. Any better suggestion?

Can we just say something like "all parts of a meeting that are enabled for remote participation should offer a free participation option", and not talk about what is or isn't part of the agenda now or in the future? (Or remove the sentence.)

>> Section 3. , paragraph 3, comment:
>>>  It is not in scope for this document or the SHMOO working group to
>>>  make suggestions for changing the IETF's overall funding model.  This
>>>  is the responsibility of the IETF LLC Board taking agreed principles
>>>  like the one proposed in this document into account.
>> 
>> This paragraph should be removed or rephrased, given publication as a BCP.
> 
> I can rephrase but I don’t really see the problem. Even after publication this BCP is a product of the shmoo group and for this group it was/is out of scope; that explains the scope if this document.

I dimly recall some guidance (maybe from the RFC style guide?) that an RFC shouldn't talk about what happened during the WG phase (or even the WG that originated it). Maybe I'm misremembering.

> Section 4. , paragraph 5, comment:
>>>  Aggregated data on the number and percentage of free registrations
>>>  used should be published, as this will permit analysis of the use and
>>>  change in use over time of the free registration option without
>>>  revealing personal information.  However, as long as the number of
>>>  paid registrations stays stable and retains the projected needed
>>>  income, an increase in use of free registrations should not
>>>  necessarily be taken as a sign of misuse but rather a sign of
>>>  increased interest and success for the open participation principle.
>>>  If the number of paid registrations, however, decreases, this can
>>>  still also have various reasons other than misuse, such as
>>>  restrictions on travel to physical meetings due to cost savings or
>>>  environmental reasons, general cost savings and lesser focus on
>>>  standardization work, or simply lost of business interest.  These are
>>>  risks that can impact the sustainability of the IETF independent of
>>>  the free registration option due to its dependency on meetings fees
>>>  to cross-finance other costs.
>> 
>> The first part of this paragraph (data reporting) should be split out and
>> detailed, i.e., reported how and to whom?
> 
> Do we really need to specify this? Currently we get this number in the plenary report by the chair but if it would go an a webpage instead or an email or whatever that would be fine as well...

OK

>> The second part about what trends in
>> the reported data might mean seem out of scope for this documents.
> 
> I think the important part here is that this principle should be seen as a way to make it easy for interested people to listen-in, so many free registrations are a success (if these are new people). Why do you think that is out of scope?

I don't see how that part of the paragraph (the "However" and "If the" sentences) do what you say here they should be doing? I read them as presupposing certain rationales for how participation data might evolve.

>> The last bit
>> (about risks) seems a bit unclear to me.
> 
> What’s unclear to you? I think we added this after the discussion we already had two meetings ago about limiting the number of free registrations. As I said above, I think if there are not enough paid registrations anymore, limiting the number of free registrations is not the solution because the problem is to rely for running costs on registrations fees in the first place.

The sentence starts with "These are risks", which seems to refer to the preceding sentences, but those don't define any risks. It would make more sense if the text read "There are risks", but then I don't understand why that text would be at the end of this long paragraph.

Thanks,
Lars