Re: [Ietf108planning] Registration open for IETF 108

Jay Daley <> Thu, 11 June 2020 05:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AFFAF3A16FE; Wed, 10 Jun 2020 22:52:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Nbj-Ia2b6gb1; Wed, 10 Jun 2020 22:52:05 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 2D90F3A16FB; Wed, 10 Jun 2020 22:52:05 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Jay Daley <>
Mime-Version: 1.0 (1.0)
Subject: Re: [Ietf108planning] Registration open for IETF 108
Date: Thu, 11 Jun 2020 17:52:03 +1200
Message-Id: <>
References: <CF0C5BE4B9992347185D3674@PSB>
Cc: Stephen Farrell <>,, Alissa Cooper <>, Colin Perkins <>,, ietf <>
In-Reply-To: <CF0C5BE4B9992347185D3674@PSB>
To: John C Klensin <>
X-Mailer: iPhone Mail (17E262)
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, 11 Jun 2020 05:52:08 -0000


I appreciate the effort you put into analysing my words for possible implications and the insights that sometimes brings but this time you are way off the mark. 

My aim was to understand if the position taken by Stephen has any path to resolution other than the specific outcome he seeks. 

I want to assure you that I understand there are significant concerns with the way this decision was presented, which remain  concerns independent of the mitigation of any specific issues. As Jason has noted, this will be discussed in detail at the LLC board meeting tomorrow. 


Jay Daley
IETF Executive Director

> On 11/06/2020, at 4:59 PM, John C Klensin <> wrote:
> --On Thursday, June 11, 2020 14:21 +1200 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.  Given that you and
>> some others firmly oppose this switch 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
> Jay,
> I have more and longer comments which I may not send, especially
> since others seem to be making some of the points, but I just
> want to point out how the above can be read in the light of
> traditional IETF assumptions about openness and community
> involvement.   I hope it is not what you intended, but the above
> paragraph can easily be interpreted as:
> (1) We [1] decided we wanted or needed to impose the
>    charge.
> (2) We realized that, if we announced our intentions and
>    engaged the community on the subject of a charge, there
>    would be a heated debate and that it was unlikely that
>    clear community consensus would emerge quickly.  Our
>    carefully explaining our reasoning and motivations
>    and/or different choices of how to present the question
>    would be unlikely to speed that process up
>    significantly.  
> (4) Therefore we decided to not ask but simply announced
>   our choices when we announced the final    registration 
>   plan and procedures.
> Now I really, really, hope that isn't what you are saying and
> isn't the process that got us here.
> That explanation and those steps could be repeated, even if some
> of the decisions were reversed or mitigated, to decisions about
> the fee waiver arrangements, the restrictions on retransmitting
> information from the sessions, the audio stream, the elimination
> of the real-time observer arrangements, and maybe a few things I
> have forgotten.   Again, I hope that is not what you are saying
> and the process that got us to any of those actions.
> best,
>   john
> p.s. I left (3) out of the above because I don't think even I am
> that pessimistic and cynical.  However, it would go something
> like:
>    (3) In spite of the fact that we because aware early on
>    that there would need to be some kind of charging
>    arrangements and other perturbations to how we have
>    traditionally done things, early enough that we could,
>    e.g., recruit a couple of companies to cover the cost of
>    fee waivers and engage in a fairly elaborate analysis of
>    possible fee levels, we decided to not give the
>    community even a heads-up at those points because doing
>    so would have likely started a discussion and we 
>  preferred to     wait long enough that we could say "no 
>  time for a community discussion and consensus".
> As I said, I'm not that pessimistic and cynical.  I can't speak
> for others.  And, no, I'm not underestimating the amount of time
> and effort the planning process has taken nor am I suggesting
> that there would have been time to prepare a detailed report
> that laid out plans, options, and tradeoffs.  But a "heads up"
> note that says "hey, we are thinking about these things, there
> will likely be a plan at some stage, and, if you think there are
> important principles that we might miss, this would be a good
> time to speak up" would not have taken a huge extra effort to
> write and send, especially in comparison to one that said "plans
> will be announced when possible" (or equivalent).
> I hope we can at least learn enough from this that we are not
> having the same quality of discussion before IETF 109, 110, or
> whenever it is next necessary to hold an all-online meeting,
> even if that is years from now.
> [1] I still don't know who, or what process, that refers to, but
> let's leave that for other messages.
> -- 
> Ietf108planning mailing list