Re: [Ietf108planning] Registration open for IETF 108

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 11 June 2020 10:39 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876143A17F5; Thu, 11 Jun 2020 03:39:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=cs.tcd.ie
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 I8Ww6ONybhC2; Thu, 11 Jun 2020 03:39:10 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0434C3A17F1; Thu, 11 Jun 2020 03:39:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A4DF1BE47; Thu, 11 Jun 2020 11:39:06 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bc8bIMhzmLvc; Thu, 11 Jun 2020 11:39:04 +0100 (IST)
Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 643F2BE39; Thu, 11 Jun 2020 11:39:04 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1591871944; bh=cEGIim7SzPF94QQM50KPK/xhrkmWAcpAFPnfH7nnqBE=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=XDiBn1aI0vLX/6CuLOPQXStAHgzgaqrAdSYwLhe5sljaf404qt5r0c/OVh0L84Cop XXLM5aN9kVtKsoFYz80DvoGaj1aPnuVoDzBAS/GF/+41ejgJl+Wjm78besBSzvbmxM P1WvrYmWxys+eAlbdem5siQxZmDKpBKGWAEY1iOY=
To: Jay Daley <jay@ietf.org>
Cc: ietf <ietf@ietf.org>, "ietf108planning@ietf.org" <ietf108planning@ietf.org>
References: <159166311543.4506.736406779378278905@ietfa.amsl.com> <CAFgnS4WOjmNOf_MRfms1RD0e15xYP-xcfNiyqS7p5ofYBEQPdw@mail.gmail.com> <d65a8aeffc61b6d069afa87f3c91b10496c4d5b2.camel@lsl.digital> <5FCC8656386268B41681E1DE@PSB> <B4293B17-6F83-4B9E-89BF-C0B1388F346F@cable.comcast.com> <CABmDk8=gxXiQ60hpdCNB6jK0EG_ssAQnzjgJp=c9yXNKabHKeA@mail.gmail.com> <CABmDk8mwVfWZQmBwZ9c4xaoStwv7CeRRceihTR846iq_LYPFFw@mail.gmail.com> <F6BFB099-2526-4EEB-A267-F2A1D0A7DDFB@cooperw.in> <35fb0076-a240-096a-de7f-280d5e7ad1e3@cs.tcd.ie> <2F0FDD2B-03C8-4E76-9149-A2666147C66E@csperkins.org> <27875646-243d-8d03-b588-866b883fea7c@cs.tcd.ie> <8C935847-70C8-439B-8F4C-83DB9A43E4DF@ietf.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Subject: Re: [Ietf108planning] Registration open for IETF 108
Message-ID: <c1b11160-c50b-9434-6ba8-9ec587a17743@cs.tcd.ie>
Date: Thu, 11 Jun 2020 11:39:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <8C935847-70C8-439B-8F4C-83DB9A43E4DF@ietf.org>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="N2aeudtVA3i7FpjqBk0PrSASszLvyY5Wt"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/V1FzGEuuU31stZMe0i7iBUkg2EY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2020 10:39:13 -0000

Hiya,

On 11/06/2020 03:21, Jay Daley wrote:

> As well as stating that you see this a switch from a zero to non-zero
> fee, I think you’ve also stated that such a switch can only be made
> with community consensus. 

Rough consensus, yes. I doubt it could be other, in this
case. (Along the lines of rfc7282.) There are many reasons,
minimally because it affects the standards process in a
lot of ways.

> Given that you and some others firmly
> oppose this switch 

You may consider that you know what outcome I want. In
fact I do not think that I know the answer here, but I
do know it affects the standards process and so needs
a debate before a change is made, except in an emergency
as happened with IETF 107. (I will say that I'm fairly
convinced that charging to join tens of hours of calls
during one week a few times a year is not likely to be
sustainable.)

I just re-read your blog, and while that is convincing
that we need to change how the IETF is funded, it does
not make the case that we need to do that in emergency mode,
for IETF108, without community involvement.

The blog also does not say that policies about fees that
have an effect on the standards process need to be decided
by the community and not the LLC. I hope you do share that
last opinion. (You may notice that I haven't once mentioned
the numeric amounts that are proposed to be imposed here
for example, so I'm not trying to haggle for a cheaper phone
call experience:-)

> it would seem that community consensus could not
> be achieved within the necessary timeframe to make such as switch for
> IETF 108, if at all, no matter what process was used to try to find
> consensus.  That would then mean that if your initial premise is
> accepted, IETF 108 would have to have a zero fee for all, no choice
> in the matter.

If there is no emergency need to change the funding model
for IETF108, then the status quo ante is the right position
until there has been a debate at least. (I do agree that
we probably can't wait a full year for an outcome from that
debate. I do not agree that "we haven't time to talk" is a
sufficient excuse for imposing fees for remote registration.)

If there is an emergency for IETF108 then that needs to be
stated clearly and that the arrangements imposed will not
apply to future meetings before the community get to debate
matters. (Or similar.)

> Do you agree with that so far or is there a way, hypothetical of
> course, that you could see the switch happening in the face of some
> determined opposition?

Determined opposition is not how I would frame this. I
think you're again assuming you know what outcome I want.

> Starting from the same uncontentious statement that "in-person
> meetings have a non-zero fee for in-person participation while
> remote-only participation has a zero fee", the alternative view 

There are many alternatives to the historic funding model, not
just one, which is what's implied by "the alternative." That
flaw in the argument seems to affect most of the text below, so
I won't try blow-by-blow answers.

> is
> that moving to a fully online meeting does not simply delete the
> first clause of that statement to leave only the second clause and so
> conclude that as everyone is now remote-only, everyone should have a
> zero fee.  To put it another way, the alternative view says that
> there is no community consensus that tells us what to do with that
> statement in the event of moving to a fully online meeting.

There may be rough consensus in the community for something. We
do not know as people have not been asked to debate it. (A
survey does not count, though does provide some input.) The
"something" for which there may be consensus e.g. might not be
a specific billing model, but rather some principles that
could be met in various ways, and that could allow for various
experiments in adapting as the situation changes. I do think
it may be feasible to establish some such principles on which
we could reach rough consensus in a relatively short time.
Trying to reverse engineer such principles from an imposed or
proposed billing model seems like a bad plan to me.

> Again, a check-in - are we still on the same page in describing this
> alternative view so far?

No. Your assumption that you know what outcome I want is
incorrect and I don't agree that there is one singular
"alternative view."

> The next stage to the alternative view, is to interpret that
> uncontentious statement in the context of a fully online meeting as
> saying "there is a fee to participate in a meeting, with a mechanism
> for those that cannot afford it to still participate".  If one
> accepts that interpretation, as the IESG and LLC do, then it is
> possible to discuss what that fee should be, what the mechanism
> should be for supporting those who cannot afford it, etc.

In logic, false => anything, so I'm not sure that's a good
starting point.

> 
> Having said that, there are other interpretations out there, such as
> "there is a non-zero fee for fully featured participation, while
> reduced feature participation has a zero fee’.  While I don’t
> agree with that as an interpretation, it also allows for a debate on
> various aspects of the overall construct.
> 
> 
> A final question for you - if the IESG/LLC had had the time to open
> up a debate/discussion on this and the IESG/LLC had gone ahead with
> this despite your opposition, would we be anywhere different from
> where we are now?

Yes. (Bearing in mind that I don't accept your premises, but
won't repeat all that.)

S.

> 
> Jay
>