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

[Brian E Carpenter <[e-mail]>]

On 20-Aug-21 01:44, Reed, Jon wrote:
> Hi Lars,
> 
> Did you have a chance to review any of the discussion from the list archives around the initial feedback on this draft?  Many of the points you take issue with are those which we added explicitly after clear feedback from the WG that we needed to address them.  Similarly, much of what you say is in scope financially are points the WG decided were not in scope.  
  In short, if we make the bulk of your edits as proposed in your initial 
AD review, we'd be right back where we were several months ago. 

Possibly, but I think the consensus for where the document is now was very rough. FWIW I think Lars echoes many of my own concerns. Nobody offers free lunch without some restrictions in the small print.
  
> Specific comments inline below.

Ditto.

> 
>> On Aug 19, 2021, at 7:10 AM, Lars Eggert <[e-mail]> wrote:
>>
>> Hi,
>>
>> On 2021-8-19, at 13:31, Mirja Kuehlewind <[e-mail]> 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."
> 
> And this does determine the fee for fully online meetings.  It _also_ offers guidance for meetings with a significant online-only component.   Back when shmoo was chartered, we had had one online IETF and were planning a second.   We're now about to have our 6th.   So as I see it, we can do two things:
> 
> - Severely scope this back to apply to ONLY online meetings, rendering this moot when we all start going back in person, and requiring us to be rechartered to handle meetings with a significant -- but not exclusive -- 
online componet
> - Recognize that the past 18 months has drastically changed both work environments, travel budgets, travel abilities, and people's appetites for 
in-person social interactions, and that if/when we all assemble in person, it will likely look more like an online meeting with an in-person component, than an in-person meeting that happens to include video and audio streams
> 
> The latter is my preferred choice.

I think that's true. And if the WG charter is a problem, it can easily be 
fixed.

>>>> 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?
> 
> This was actively discussed on the list.   The hackathon is one clear related event.

The draft needs to clarify this.

>>
>>>> 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.

Not quite. This is a basic principle that got rough consensus among the ~120 people on the manycouches mailing list. I support that consensus but only if there is a caveat to avoid the assumption that there will always be a money tree available.

>> 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.
> 
> Isn't that what we're saying in the doc?

No, the statement of principle doesn't say anything about striving. It states an absolute requirement.

>> 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.
> 
> You note further down we could obsolete this BCP in the event that happens.

Who's "we"? The IETF is the only body that can obsolete a BCP, and the IETF doesn't have a bank account. It's the body with a bank account, the IETF LLC, that needs to take operational decisions if there's ever a financial crisis. The draft needs to give them that option.

>>>> 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?
> 
> And if that happens, so be it.  Would you like us to explicitly call out that this BCP can be obsoleted if necessary?

No, because that's obvious. See above: we need to give the LLC the ability to deal with a financial crisis without waiting for the IETF, in its wisdom, to obsolete a BCP.

>>> 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.

It remains unrealistic to assume an infinite budget to support free registrations for ever.

>> 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.
> 
> There will always be such theoretical situations.    Tuesday was the 1 year anniversary of the initial draft of this document, and Sunday will be the 6 month anniversary of the WG adopted version.  If there are specific situations you're worried about, can you enumerate them?  Otherwise, the longer we wait, the more time we'll have to imagine hypothetical situations which could complicate the adoption of these principles.
> 

We don't need to do that. We just need to add about one sentence in section 3 empowering the LLC to take emergency decisions in an emergency situation. They will do so anyway, so we might as well write it down.

>> 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.
> 
> Can you specifically state how section 3 does not take this into account?

It ducks the question: what does the LLC do if the money supply dries up (or if companies are manifestly freeriding)?

>>>> 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?
> 
> We discussed this extensively on the mailing list, and arrived at (I believe) the conclusion that while anyone can join mailing lists or watch the youtube videos, that's not meaningful participation.   Meaningful participation requires full-duplex communication mediums, and those require a 
registration fee.

Hang on, you mean "a fee or a fee waiver".

> 
>>
>>>> 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.
> 
> I haven't seen such guidance (but I also haven't looked particularly hard).  But if such guidance exists, that seems ridiculous.  Documents ALWAYS benefit from understanding the context in which they were written.

It's a small point, but I disagree. Reading this 10 years in the future, a reference to a specific ancient WG would just confuse the reader.

Regards
   Brian