Re: Registration details for IETF 108

Nick Hilliard <> Thu, 04 June 2020 13:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2082F3A0A6C for <>; Thu, 4 Jun 2020 06:25:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n8wCycZMGDgy for <>; Thu, 4 Jun 2020 06:25:37 -0700 (PDT)
Received: from ( [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 391803A09D2 for <>; Thu, 4 Jun 2020 06:25:35 -0700 (PDT)
Received: from cupcake.local ( [] (may be forged)) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id 054DPRfp048180 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jun 2020 14:25:28 +0100 (IST) (envelope-from
X-Authentication-Warning: Host [] (may be forged) claimed to be cupcake.local
Subject: Re: Registration details for IETF 108
To: Phillip Hallam-Baker <>
Cc: ietf <>
References: <> <> <> <> <> <> <> <> <D3BA93CD3D2D101946F35024@PSB> <> <01d701d638ca$c096b5e0$41c421a0$> <> <> <> <>
From: Nick Hilliard <>
Message-ID: <>
Date: Thu, 4 Jun 2020 14:25:26 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.17
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Jun 2020 13:25:42 -0000

Phillip Hallam-Baker wrote on 02/06/2020 17:03:
> The brute facts we face are that international travel is certain to be 
> infeasible for the remainder of the year and quite likely for some time 
> beyond, that the IETF business model is predicated on income from 
> in-person meetings that can't now take place and this leaves few options 
> on the table.

there are a lot of ways of looking at this, but there is a human 
interaction issue here.  No-one denies the realities of international 
travel or the obligation of the LLC to implement realistic financial 
policies for the company. In an ecosystem like the ietf, if the decision 
had been handled as soliciting input + getting buy-in, and not as a 
unilateral imposition, I suspect peoples' hackles wouldn't have been 
raised nearly as much.  Downstream, it would have made discussion about 
meetings after 108 much easier.

It's easy to be wise after the fact and also when you're not in the hot 

My point was simply that we need to approach post-IETF108 meeting 
charges without prejudice to the IETF108 decision, and hopefully also 
learn from it.