Re: Fees after IETF 108 [Registration details for IETF 108]

tom petch <daedulus@btconnect.com> Wed, 03 June 2020 16:29 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 EF6183A08D1 for <ietf@ietfa.amsl.com>; Wed, 3 Jun 2020 09:29:03 -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 dw4XKzeQEiDv for <ietf@ietfa.amsl.com>; Wed, 3 Jun 2020 09:29:00 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70139.outbound.protection.outlook.com [40.107.7.139]) (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 650793A08DA for <ietf@ietf.org>; Wed, 3 Jun 2020 09:28:58 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Gu2eFSCo87LipBX5SBbz0weAyRO7+wfr/9ShM04xPLXSk9APbF1lsju0XjMZdyoAqdZJk0K0mmu60++GmJZkyMYd9NxYtHzKeQW7isbX5XjNvQo4Zci8BVNyBLCi8UjhCIhLb3JrEwgF8dE5+573F5eQ7ZwAzBrKJyyvv5t9xODkyHVr6+cP6ZHf6rPIeBTERbNfq99G8HaMTcXRUyZbyDn1+r6/Dju7NoZft4iAP43JWNI7MKu8l6fRJIXuEA2bqqqUUmRoKjfCcGfVMDv1vGfRjuIXVING1u6ZmVEADjukdAniniAermUl3K014nHwt9dJ1qO7fjJh6G6HrgjwJg==
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=xFir4/idfSpx6qOyorIxmKu4ybS+py2HToVbYnGo82I=; b=Wo7iFg1IrnWWN5fNTs9jMIQX8i1FKq6vEmlUitmm7QfiIuikhVd+dYfxHphuQ5qFnSQcif43MfYyxQhWa+C1aU8cc34a+hrEdZW3PnvYpkiKTQQup0EnMOJUVLT3vpR0o52VsR8QYLQ0GT+w62Gg2G6Jd4QNMTePPUDMGPGU+r39YkAQteMUbIn7KV1yYQFblyQFZueA7Kac3oz8n8na2FBzqH7KhXxCAw22Aenb6iyvAdClcD1tSrM0w6c5B8BcH7Cwu+Sq0mghz2Aptn/+zO1HBo65oK/TuThIah0u8lDjhRQdyfT2i+OgAqzj8zfD4N3uD57Rmf3unPYKb3WGwQ==
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=xFir4/idfSpx6qOyorIxmKu4ybS+py2HToVbYnGo82I=; b=uQ1LNwSqxQn5sLH6+qg/xw7DfJdTWEPpPELPXvAL2RFzTMrkR4d1o8Y6/iZPHlCHOEIDeO6w4thdbHElBX2Z1mIvWcRzo9/hjjwzUl5avefbikY7+0ou0fKnCboHiMJro45GIzPCoYoHLFEIBz0ppRsWrZPD5Y78caQjWrhQWeA=
Authentication-Results: hallambaker.com; dkim=none (message not signed) header.d=none;hallambaker.com; dmarc=none action=none header.from=btconnect.com;
Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16) by VI1PR0701MB2751.eurprd07.prod.outlook.com (2603:10a6:801:6::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.11; Wed, 3 Jun 2020 16:28:56 +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.3066.016; Wed, 3 Jun 2020 16:28:55 +0000
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
References: <159062833754.6110.5826748635235943562@ietfa.amsl.com> <CA+9kkMC8ZWHaCBg=WzwtriVf-3bq=egupVgAH-J7dSqspwLoFw@mail.gmail.com> <a19c3066-bfa7-ded2-d98f-b5e367645451@cs.tcd.ie> <CA+9kkMDrsRoCPFyzU7HJWoFqgg3jQ4rszQvNRMzUAAhVwn=k0w@mail.gmail.com> <583a2e86-260a-4156-2a72-dd21e789cf97@cs.tcd.ie> <CA+9kkMD+7CLeTQ2npmWeeu58A94a5DBAzfm+SVUCgn8fwxh0pQ@mail.gmail.com> <35a9b588-f8a5-89c8-8801-e3cd80d11d58@gmail.com> <7b865305-b307-9834-5467-d27835e1b5b6@gmail.com> <58619861-b7bb-03fd-6bfb-ef901a6cda19@joelhalpern.com> <CAMm+LwiaOnkLjGzdo2+e5WDjPGYER4HCF20ZztU_FJKD66kpmQ@mail.gmail.com>
Date: Wed, 3 Jun 2020 17:28:43 +0100
Message-ID: <1UWAwiEKdH.1bqKxk7vSLv@pc8xp>
In-Reply-To: <CAMm+LwiaOnkLjGzdo2+e5WDjPGYER4HCF20ZztU_FJKD66kpmQ@mail.gmail.com>
From: "tom petch" <daedulus@btconnect.com>
To: "Phillip Hallam-Baker" <phill@hallambaker.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: "IETF Discussion Mailing List" <ietf@ietf.org>
Subject: Re: Fees after IETF 108 [Registration details for IETF 108]
User-Agent: OEClassic/3.0 (WinXP.2600; F; 2019-11-28)
X-ClientProxiedBy: LNXP265CA0093.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:76::33) 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.104) by LNXP265CA0093.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:76::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Wed, 3 Jun 2020 16:28:54 +0000
X-Originating-IP: [86.139.211.104]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 883ec0fa-2127-4ba3-fe3d-08d807db35b8
X-MS-TrafficTypeDiagnostic: VI1PR0701MB2751:
X-Microsoft-Antispam-PRVS: <VI1PR0701MB2751DB166EAB8DB2CAE19697C6880@VI1PR0701MB2751.eurprd07.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-Forefront-PRVS: 04238CD941
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: mZrlA7N7WULjF15tNwtuUkLPIvwMYUGnZ66Q9FB3LU2yTiuq0fQcfMfi4iHsircW1kymx3hgO26Om2A6SJoqj8jxFYHn8a4enn18ADTbHf1opLihEg+ZIv45IgPzGkuAcsR3q8YbNTbh2uGW4f8w2Xvgb/3weJOnKtiNejPXiLCjf4/bL8iJgoyZsH627mMtCu44S7VrQi2fAx5REr8hVyafxBXVmE4rmANSgkL8CrgAiplkAGAX8DPM/1zgb4Tz2RNXR+Mwnn+do5ccgFOoXTWIrzcIizI1UlTOIUg4f2zk5MamO6X7iMfIv0wKJtmuDoX6hYgsom6/70Lm7MRl8t2uai/I8zjMlWwxhBiWXW+sYxJolowake3sL1bQLlc0ka9T9poWIU15r3YPIU28/g==
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:(376002)(396003)(346002)(39860400002)(136003)(366004)(4326008)(9576002)(956004)(8936002)(8676002)(5660300002)(6666004)(52116002)(6496006)(33716001)(53546011)(316002)(110136005)(26005)(86362001)(83380400001)(45080400002)(2906002)(66476007)(478600001)(66556008)(66574014)(16526019)(52230400001)(66946007)(966005)(186003)(55016002)(9686003); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: iQCgo9Z1+qrgBga/zy6jIYbsEsFmEcZ+rovM8swmJ74G3mjKLndvl2U2rPiOsOs/BWe5Wd+yyFvF29/v/PBn20091pbIZ6vEzM4Ikvk3Hingfoz7FudVo/cvHeTc7a0GFlw98fD2xL9YK/tnQrK7Te8CwtXlang87UfCIYXtSGTkXRjrtYJhZvFLA5yMA+IlHh+qcjh7gwOhJA0kncdrwmPN15toBD5/wP9fiZ8lgALHomxqnT0/YOcHhPxHJ6X+7jg9rrjrrrBu2iGCkBziXG2d6L++njRj0peq7Blo3Pj6NCCimkcVU5YNT1OxZ8pLftqTMcNeS3p5wfM9ZSNLtR6Lp+dwZ3TSMG0DCVHzHyehwWgUTvPoVITsyPAcGezBGFyhjw3eoUc0D7Y6Mu/setRzAfFpugGegKlmmS54clWqhbOloHVRTC1APOBVHklFpFgWABS42wpLC70F34jylGKLg9YoCDU9tc9PWJqTqRE=
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 883ec0fa-2127-4ba3-fe3d-08d807db35b8
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2020 16:28:55.8911 (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: 2YMpzWFyxylDb+r7oNTYqq9n1+IBGJcejpyA/2lY161/lRH1fqbQaaiIyUt4Yo9iL4yPdHjz1JdPzklb5mB+ZQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2751
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/hYdfReNVCL3wPuzmgxgH517Jsww>
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: Wed, 03 Jun 2020 16:29:04 -0000

----- Original Message -----
From: Phillip Hallam-Baker phill@hallambaker.com
Sent: 03/06/2020 15:59:39

This discussion is showing the limits of consensus based decision making in the IETF.


There are two discussions we could be having, only one of which actually involves a choice. We are currently having a discussion of the short term issue where there is no real choice and not the long term issue where we do.


Charging for the lost in-person meetings is water under the bridge. What we should be discussing is where we want to be in the future.

While the IETF is all about the Internet, its fundamental structures and business model were established before the Internet. It is at root a 1980s institution. By which I mean not that it is typical of the institutions of the 1980s but it is a product of the thinking about institutions at that time. There are innovative aspects of the IETF that represent experiments in organization. But not necessarily experiments that worked.
<tp>
I have only been involved with the IETF for 25 years, post IESG, pre IAxx, LLC etc, and  not back to the 1980s, but even in that short time it has changed out of recognition IMHO, becoming more structured, more formal, more procedural in the non-technical aspects of the work and I think that that is a good thing.  The pandemic is undermining the assumptions on which many businesses are currently based and that could be happening with the IETF.  Meeting in person is a likely candidate.  I agree that we should focus on what we can change and accept what we cannot but I think too that the psychology of participants in a group is little changed so far and so some discussions we have had on this list before, we will have again and they will likely be as unproductive as they have been in the past.   Interestingly, academic journals, which you also mention

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

, is something I now seem to use only for looking up the history of developments.
Tom Petch




There are very similar problems in the world of academic journals. The business model that was established by the publishers in the 1960s makes no sense from the point of view of the agencies that fund the research. That has been apparent for what, 30 years? There is a law of gravity at work here but one that takes generations to take effect.

On Tue, Jun 2, 2020 at 7:27 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:

I assume that the to determine the long term policy on charging for 
remote participation at various kinds of meetings, rough consensus would 
be gathered on the SHMO list, and then confirmed on the IETF list with 
the IETF Chair judging rough consensus.  Then, in line with Jay's 
frequent description of the LLC operation, the LLC will follow the 
community guidance.

I do not see how the LLC could reasonably have asked for input for this 
meeting in time to be useful.  As someone else mentioned, asking for 
input and then saying "sorry, we know the discussion is still going on 
but we have to act" would probably have been even worse.

Yours,
Joel

On 6/2/2020 7:06 PM, Brian E Carpenter wrote:
> Another point. Ted wrote:
> 
>> I think the LLC can call consensus on a matter within their remit (just as
>> the IAOC evaluated the feedback on the registration date change policy that
>> I referenced many messages ago)
> 
> The IAOC was a community-appointed body. The IETF ExecD is not. When it comes to evaluating community consensus, that's a big difference of principle.
> 
> Regards
>     Brian
> 
> On 03-Jun-20 10:56, Brian E Carpenter wrote:
>> On 03-Jun-20 10:11, Ted Hardie wrote:
>>> On Tue, Jun 2, 2020 at 2:56 PM Stephen Farrell <stephen.farrell@cs.tcd.ie <mailto:stephen.farrell@cs.tcd.ie>> wrote:
>>>
>>>
>>>
>>>      On 02/06/2020 22:41, Ted Hardie wrote:
>>>      > And you are convincing me that attempting to settle it on the IETF list
>>>      > will require somebody to judge consensus, since there look to be a minimum
>>>      > of two people with the time and keyboards available to disagree.  We
>>>      > apparently, however, disagree on who that should be.
>>>
>>>      Perhaps not! If you do agree that consensus calling is
>>>      required that seems to imply the LLC is not the one to
>>>      do that. We have a bunch of 14 victims already setup
>>>      to do just that:-)
>>>
>>>
>>> I think the LLC can call consensus on a matter within their remit (just as the IAOC evaluated the feedback on the registration date change policy that I referenced many messages ago).  So, I think they are the victims set up to do that in this case.
>>
>> It's a change to the openness of the standards process, unprecedented since we first started multicasting the audio for free back in the early 1990s. BCP101 defines the LLC's scope:
>>
>> "The IETF LLC is established to provide administrative support to the IETF. It has no authority over the standards development activities of the IETF."
>>
>> There's no doubt that the IETF Executive Director *sets* the fees, but IMHO that isn't the point at issue. In this text:
>> "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."
>> I don't see any indication of how the ExecD knows the result of consulting the community when there is disagreement. The mechanism we have for that is the IESG determining the rough consensus. I can see nothing in BCP101 that gives the ExecD the power to determine IETF
>> consensus, although it does require the LLC to respect IETF consensus. Those are two different things.
>>
>> Maybe this is a tiny gap in RFC8711, where Ted and (Stephen + I) have different interpretations.
>>
>> Regards
>>     Brian
>>
>>> Since you referenced the magic number 14, I conclude we still disagree.
>>>
>>> I think we do agree that there should be public discussion.  I think we do agree that the LLC and IESG should talk to each other about the implications of different strategies to both the ongoing work of the IETF and its financial future.  I think we do agree that any conclusion would be revisited in the light of evidence of how it ends up working.
>>>
>>> But our disagreement on on who the stuckee is remains.
>>>
>>> regards,
>>>
>>> Ted
>>>   
>>>
>>>      Cheers,
>>>      S.
>>>
>>
>