Re: Registration details for IETF 108

John C Klensin <john-ietf@jck.com> Mon, 01 June 2020 16:45 UTC

Return-Path: <john-ietf@jck.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 0DBB53A0994 for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2020 09:45:01 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 ob5lF36CEZlX for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2020 09:44:59 -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 0EA513A0962 for <ietf@ietf.org>; Mon, 1 Jun 2020 09:44:59 -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 1jfnYX-0006vO-Pq for ietf@ietf.org; Mon, 01 Jun 2020 12:44:57 -0400
Date: Mon, 01 Jun 2020 12:44:52 -0400
From: John C Klensin <john-ietf@jck.com>
To: ietf@ietf.org
Subject: Re: Registration details for IETF 108
Message-ID: <D6AF5131729C554EA66DD64D@PSB>
In-Reply-To: <afa11959-3348-4054-409c-803824a2f332@gmail.com>
References: <159062833754.6110.5826748635235943562@ietfa.amsl.com> <6.2.5.6.2.20200531121457.0b249858@elandnews.com> <CABcZeBOzVHaSZa0A3eDz12RwNuCiHtiJL8wqvAhhLPN6YEQOkQ@mail.gmail.com> <afa11959-3348-4054-409c-803824a2f332@gmail.com>
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/ietf/gDhSP1PN8DvDMM8XTjXrLabIG2U>
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: Mon, 01 Jun 2020 16:45:01 -0000

Hi.

Having read the survey results and having been suggesting for
many years that remote participants (note participants, not
observers/lurkers) should be charged at least a nominal fee, I
agree with all of those who have said that charging something is
reasonable.   I have three concerns that are, in increasing
order of importance below.  While not trivial, I hope that
neither of the first two become a distraction.

(1) At least in retrospect and with the understanding that we
are all learning as we go along, if the IESG was aware at the
time of the 14 May "meeting will be online" announcement,
indicating that a fee was likely (or certain) and that details
would follow with the IETF LLC had them ready would have been
helpful (rather than just saying "Further details ...will be
shared as they become available").  That might have prevented
the surprise some people felt about an announcement that there
would be a fee and having that announcement appear less than a
month before the early-bird cutoff.  Let's not pretend there is
an impenetrable wall between the IESG and the IETF
Administration LLC, especially after the community explicitly
agreed that the IETF Chair should have a seat on the LLC Board
precisely to foster this type of communication and Alissa's
comment that the IESG had discussed the fee structure.

(2) While I appreciate the specific numbers and comparison in
the announcement and blog post, the conclusion reads a bit like
numbers were pulled out of a hat (even if people were selective
about the numbers that were put into the hat).   To the extent
to which the LLC's goal is increasingly data-driven and
evidence-based decision making, some of this seems to have the
ring of arbitrariness about it.   Why up to 100 waivers and not
75 or 125 or some other number?  Does the LLC believe that
setting an arbitrary target and then running a lottery for who
gets a waiver (and hence who gets to participate) is better than
criteria-based case-by-case decision making and, especially
since the community was not consulted on that change, why?
Why "about a third" rather than a number somewhat higher or
somewhat lower?  And, as someone else asked, is there enough
difference in meeting arrangement and set=up costs to justify a
distinction between Early-bird and Standard registrations and a
$50 difference in fees between them and, if so, why?

(3) While I note that almost every posting since Melinda's
comments excerpted below has concentrated on the fees, I think
she has identified the important issue.  We continue to claim
that decisions are made --not just checked or last-called -- on
mailing lists, but that seems factually to have become less true
in recent years.  Like her, I believe that the trend may be
irreversible at this point.  However, unless there is some plan
to try to at least partially mitigate the effects of that
change, I think it is important that we recognize and make
adjustments for, not only the incoherency and inconsistencies
she points out, but the changes that dilute the "decisions on
mailing lists" principle.  We should also recognize that
diluting that principle inevitably has negative effects on the
diversity of experience and expertise -- not just demographic
diversity although there might be effects there too-- that end
up being represented in IETF decision-making.

I hope the IETF never has to go down the path of identifying
participants with specific categories of interests and insisting
that participants from all categories be present whenever a
discussion occurs or a decision is made, partially because such
rules are a horribly blunt instrument.  However, other voluntary
(and supposedly open) standards bodies have adopted exactly such
rules when their assortment of barriers to participation and
entry have grown high enough to raise suspicion that they have
become big-player industry cabals and/or are in need of
regulatory oversight and scrutiny from competitiveness and
antitrust authorities.  As things evolve, let's at least be
aware of those risks and make adjustments to our path
accordingly.

    john




--On Sunday, May 31, 2020 13:44 -0800 Melinda Shore
<melinda.shore@gmail.com> wrote:

> On 5/31/20 1:13 PM, Eric Rescorla wrote:
>> I don't think the characterization of this as "pay-to-play"
>> is accurate. You are certainly free to participate in mailing
>> lists, github, etc.
> 
> I'm somewhat troubled by this, as well, tbh.  To the extent
> that the IETF has gradually and effectively moved to having
> decisions made in meetings it would be unfortunate indeed to
> exclude people based on financial circumstances.  I'd like to
> see the decision-making situation fixed but given the history
> of that discussion I think we are where we are, and free
> remote participation provides at least some mitigation.  I
> also tend to think that saying that meeting participation
> isn't necessary because {mailing lists,Github,whatever} is
> incompatible with the insistence that the IETF continue to
> meet because it's not really possible to progress work without
> real-time discussion.  I'll also note that for as long as
> there's been a remote participation option available it's been
> free.  We're now in the odd position of having all-remote
> meetings absorb what used to be "remote participants" into the
> group of "participants," with some consequential side-effects
> (although arguably there are no such things as side-effects,
> just effects).
> 
> I do think this decision has some unintended consequences.
> Scholarships or other subsidy might provide some mitigation
> but would potentially be messy/awkward.  The organization
> is long overdue for some navel-gazing about working methods.
> It's unreasonable to expect perfect consistency but I think
> things have gotten a little more incoherent than they should
> be.
> 
> Melinda