Re: [Ietf108planning] Registration open for IETF 108

John C Klensin <john-ietf@jck.com> Thu, 11 June 2020 04:59 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf108planning@ietfa.amsl.com
Delivered-To: ietf108planning@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095843A16CA; Wed, 10 Jun 2020 21:59:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 rk00wHM5bkrn; Wed, 10 Jun 2020 21:59:36 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C5A3A16C3; Wed, 10 Jun 2020 21:59:35 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1jjFJM-0004Im-CF; Thu, 11 Jun 2020 00:59:32 -0400
Date: Thu, 11 Jun 2020 00:59:25 -0400
From: John C Klensin <john-ietf@jck.com>
To: Jay Daley <jay@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
cc: Colin Perkins <csp@csperkins.org>, Alissa Cooper <alissa@cooperw.in>, ietf <ietf@ietf.org>, ietf108planning@ietf.org, exec-director@ietf.org
Message-ID: <CF0C5BE4B9992347185D3674@PSB>
In-Reply-To: <8C935847-70C8-439B-8F4C-83DB9A43E4DF@ietf.org>
References: <159166311543.4506.736406779378278905@ietfa.amsl.com> <CAFgnS4WOjmNOf_MRfms1RD0e15xYP-xcfNiyqS7p5ofYBEQPdw@mail.gmail.com> <d65a8aeffc61b6d069afa87f3c91b10496c4d5b2.camel@lsl.digital> <5FCC8656386268B41681E1DE@PSB> <B4293B17-6F83-4B9E-89BF-C0B1388F346F@cable.comcast.com> <CABmDk8=gxXiQ60hpdCNB6jK0EG_ssAQnzjgJp=c9yXNKabHKeA@mail.gmail.com> <CABmDk8mwVfWZQmBwZ9c4xaoStwv7CeRRceihTR846iq_LYPFFw@mail.gmail.c om> <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>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf108planning/HW87bqyYWhSV52y_II9En-nvxhg>
Subject: Re: [Ietf108planning] Registration open for IETF 108
X-BeenThere: ietf108planning@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ietf108planning.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf108planning>, <mailto:ietf108planning-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf108planning/>
List-Post: <mailto:ietf108planning@ietf.org>
List-Help: <mailto:ietf108planning-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf108planning>, <mailto:ietf108planning-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2020 04:59:38 -0000


--On Thursday, June 11, 2020 14:21 +1200 Jay Daley
<jay@ietf.org> 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.