Re: [Ietf108planning] Registration open for IETF 108

tom petch <daedulus@btconnect.com> Thu, 11 June 2020 16:37 UTC

Return-Path: <daedulus@btconnect.com>
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 30E0C3A0A8F; Thu, 11 Jun 2020 09:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-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=btconnect.onmicrosoft.com
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 wC-145iTSeIX; Thu, 11 Jun 2020 09:37:47 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70098.outbound.protection.outlook.com [40.107.7.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD203A0A92; Thu, 11 Jun 2020 09:37:47 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ebdK4m61RBfh6Di3bdFHWjodwKhWwGBcCX6+AInlz9P4eGP7Bz3y4TVag+IYMOk0cNFaTDTa9tBF74Py4yoyhP9elxu0A5ooCooUkmUR/loyozjCqf3Nrsejy8QknXkKyRFajDDMGk4mg03Wm0Iu4lbX4M1nWs4ru7K6i3pNXjuGj/GLwv+2Mfu6JJhb8X06s/Xv6D231DmIDRKwfXzHzeRgb5NEvx8FfeVPKkxkzczJ7dQTieJQAkHvWF6i3V/NfvvMysaHz8Jd4Nqnh/mxMYo1ahANkLe0uCz/b7Y4q+iOJvs6K9s2szbnKufXofqetBZYCA7lKmAeh4TiA3i0FA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SO/QoeQBM/uk39UVzW3ufvi8E8gKnR2+UjToeoJUNiw=; b=DUFVZASw8dLUkjKB/5m6QObgbC43lB14YTjih1DjQfswEbFmW6ypxu2qCdmpdCqUp+GnDn26FX+076sqwCqYka+6h2IPW1H49ZwAPJeNDIxCpMbr2D3G/wHWLSX1dtG86AFVctUGCQWEikrIDchPpXBRx1r3IhPOJLMtlUkTkcgES3tHR0ms8k6EL4rnubc9DlP1FhgPweGza38JTqn8n0BCHG6duLXEZG3Q4H0x183s8KwX/sxriHo8E4USVatgGhi43e7qG3H5yW5K6ap2ji+OJdm+UaD6LGFdLV6c17bmiD3tqWSNobq8TYdeJJT7MfLp89O1yOuMBeMcS3tC5A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SO/QoeQBM/uk39UVzW3ufvi8E8gKnR2+UjToeoJUNiw=; b=CWgi9yKVVhVyM5HxDY6Zt4b/kaWvINWkzSjGGnNXR34abZ1LWBARJPyGaVV+LfJjGbSagYA7xcu7onlN2SjhfQLCAgj3VLVrmFCZFnzpbmBE6RA/WmnjVLal3D+I9tOQfSxQx5Xl+n1FHSvoGYU8Ik5z50vEYAGJHfJNmsvSdA4=
Authentication-Results: cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=btconnect.com;
Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16) by VI1PR07MB5774.eurprd07.prod.outlook.com (2603:10a6:803:cb::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.7; Thu, 11 Jun 2020 16:37:44 +0000
Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com ([fe80::3474:b82e:e75a:b176]) by VI1PR0701MB2480.eurprd07.prod.outlook.com ([fe80::3474:b82e:e75a:b176%11]) with mapi id 15.20.3109.007; Thu, 11 Jun 2020 16:37:43 +0000
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
References: <159166311543.4506.736406779378278905@ietfa.amsl.com> <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> <c1b11160-c50b-9434-6ba8-9ec587a17743@cs.tcd.ie>
Date: Thu, 11 Jun 2020 17:37:28 +0100
Message-ID: <1UWB5RhEL2.1bMPW5hKaR9@pc8xp>
In-Reply-To: <c1b11160-c50b-9434-6ba8-9ec587a17743@cs.tcd.ie>
From: tom petch <daedulus@btconnect.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Jay Daley <jay@ietf.org>
Cc: ietf <ietf@ietf.org>, "ietf108planning@ietf.org" <ietf108planning@ietf.org>
Subject: Re: [Ietf108planning] Registration open for IETF 108
User-Agent: OEClassic/3.0 (WinXP.2600; F; 2019-11-28)
X-ClientProxiedBy: LO2P123CA0007.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:a6::19) To VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from pc8xp (86.139.211.47) by LO2P123CA0007.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:a6::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19 via Frontend Transport; Thu, 11 Jun 2020 16:37:42 +0000
X-Originating-IP: [86.139.211.47]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 8c24b90b-79b7-4c3c-799d-08d80e25c3bd
X-MS-TrafficTypeDiagnostic: VI1PR07MB5774:
X-Microsoft-Antispam-PRVS: <VI1PR07MB57748C15CFC1F78787580CD7C6800@VI1PR07MB5774.eurprd07.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-Forefront-PRVS: 0431F981D8
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: DURoqef6uj2aYa0UeUflksC5n7seG4ejlKIGMbrzNHLOs2V5OMkYnaSQTPpsczPY2KGJVh0n/vATdyeZ35epdFnpz2p5NW7uvFm1oyyxNmD2W32j53AU6RyEv+lu6vGzRupy551KbA8uc9yOy5aoAwQkNOuGQAJF9k+R71HP3su9/LpqIHuF0rdu8SA4UeCTr7JK6sSFmIpySyAaFvNUVvZhGBWnMPxh/t2HK2Cuj6nsVLmvH5tib2eT+4MRy9FMUzZ9KpvoabN74NSIHUiAbKRpz1KJQaQbHtzyFzKY0pjaH/Q0ecjySOT+BRoOsODNS8Ty2VNzvanlCg/jRxwPyYN8Uyn15B61BZoTKKtKS+7yxsf21ZET3OBgyAbl2O9MdI3l50p4U4ZHifGnEm/zsw==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0701MB2480.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(39860400002)(136003)(396003)(376002)(346002)(9576002)(110136005)(6496006)(8936002)(52116002)(86362001)(83380400001)(55016002)(296002)(4326008)(316002)(54906003)(16526019)(9686003)(26005)(52230400001)(478600001)(6666004)(966005)(186003)(45080400002)(5660300002)(8676002)(956004)(53546011)(66556008)(33716001)(66476007)(2906002)(66946007); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: cL5OvNyGpLdjUy0KMihEoogAUjhUgbc4KHqGmQsHcYlPhmD/RDPShUNobip+GSKdd4zILij6FFLiR4N+xwO7qv6PvyKJORuaY7FC/QygqLO5K9zpkgu2rOq341J+8djSc4zlonWPC/G+ze/LYEwZeVzXk7egSZUhPmjCHSr+NngIicGW29I5cseyqJ/vkdm0RB8JOxwjoiE94RdtxdbUTy7HOEGAZpjHJFhOoM3RoSBFdbeLD+aOlB9nEMyCVp8RE7mX5Rt6TqzuA4kuC0jtGVDZwA28gpQO520eS+VGwFAw54/pxTMx3Kz/Zpv4qOI41psk0Q6hF+vUtww8LA9Ig2m7HYAfxg+bO0pK9lR0v7GmAP7NRRWepTeGpH8GGFHL3BeeL3t+1t6BxVVCXoxuMpVnCjIN2Lfm3tMLrSzvWkiW+jR0IBx6oS/ZJJyupEHidXSvTQ0GsPeTOc2dWaBF1iZKX+y17BQraImrAs1DC/0=
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8c24b90b-79b7-4c3c-799d-08d80e25c3bd
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2020 16:37:43.8556 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: L0a1+PqmC+hcCYv7kPjn/FkY2yfGyWDBMTtKuq/nQVVoHNYPA6F/d3KRPTyj3GVv8IiEKyx+AIlYl4JPJ8ijrQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5774
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/XbgXOT-oUunLlv750LcSnJv7qhg>
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 16:37:50 -0000

----- Original Message -----
From: Stephen Farrell stephen.farrell@cs.tcd.ie
Sent: 11/06/2020 11:39:03

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.

<tp>
Looking at RFC8711 I see

"7.5. IETF Meeting Revenues
Meeting revenues are another important source of funding that
supports the IETF, coming mainly from the fees paid by IETF meeting
participants. The IETF Executive Director sets those meeting fees,
in consultation with other IETF LLC staff and the IETF community,
with approval by the IETF LLC Board. Setting these fees and
projecting the number of participants at future meetings is a key
part of the annual budget process."

Elsewhere in that cluster of RFC that came out in February, in the context of venue, it explicitly calls out the need for consensus as declared by the IETF Chair.  Here there is no call for consensus.  If the IETF had wanted more control then it should not have approved RFC8711:-)  I think that Jay was well within his rights to take the actions he did.
Tom Petch


---
New Outlook Express and Windows Live Mail replacement - get it here:
https://www.oeclassic.com/


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