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

"Joel M. Halpern" <> Tue, 02 June 2020 23:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB3413A10FF for <>; Tue, 2 Jun 2020 16:26:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ymQXTNVfc6RO for <>; Tue, 2 Jun 2020 16:26:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8629A3A10FE for <>; Tue, 2 Jun 2020 16:26:25 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49c7TY3CqBz1nybK; Tue, 2 Jun 2020 16:26:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1591140385; bh=+r9SZq+bVlz1o0UAdlUtch0od+ojvKA0OzNy19TYZ2Y=; h=Subject:To:References:From:Date:In-Reply-To:From; b=KA6v5jOGdM37/qm7Lmwz/paX3lQacaxp+Uc8/Yvt5p5iSfXQ4/jnIe5TmB9/GIqV8 QLbZ6GS7zk+GErmXlzm+qiXKGg3W6wTHCboZHKehLAFEH4ZMm6I3w9ywscjVJ3QTD6 w2ftItSAS37ASH6NIAT8DZMcRDm3RY4Z9LdBPEiI=
X-Virus-Scanned: Debian amavisd-new at
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 49c7TX6S9bz1nsxv; Tue, 2 Jun 2020 16:26:24 -0700 (PDT)
Subject: Re: Fees after IETF 108 [Registration details for IETF 108]
To: Brian E Carpenter <>,
References: <> <> <> <> <D3BA93CD3D2D101946F35024@PSB> <> <01d701d638ca$c096b5e0$41c421a0$> <> <> <> <> <> <> <> <> <> <> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Tue, 2 Jun 2020 19:26:24 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
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: Tue, 02 Jun 2020 23:26:27 -0000

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.


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