Re: Specific Questions about Registration details for IETF 108

Ted Hardie <ted.ietf@gmail.com> Mon, 08 June 2020 16:38 UTC

Return-Path: <ted.ietf@gmail.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 BA3BB3A0CFB for <ietf@ietfa.amsl.com>; Mon, 8 Jun 2020 09:38:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 6k9weEt1huiL for <ietf@ietfa.amsl.com>; Mon, 8 Jun 2020 09:38:46 -0700 (PDT)
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CDBD3A0CF1 for <ietf@ietf.org>; Mon, 8 Jun 2020 09:38:46 -0700 (PDT)
Received: by mail-ot1-x331.google.com with SMTP id t6so4937875otk.9 for <ietf@ietf.org>; Mon, 08 Jun 2020 09:38:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5Z/Hjj99HzjQ1N0jW5e89iMPJMmOiMUOJtQRQkuPG/0=; b=JPb0U4574T1Ns33ujCzmHGY31Ts89DsErGHB8ZPRORMLhDW5kKDzAUVLAoxSDLWdFV BoxlEASBvoqb8/pus6Jk8SjkfoLTNXUdopWRnbUpFwWf7ABscahUTfGyqU6jqv2T0mzy NQTD3zV/iZX7TbhNrkpF+GwykxA7Rw8MvufuA51fiOz99UjNK0eH73LRZmA1ENaPotPJ prLd7rakP88OPM3ewcNFLgX54EjP0c+G3R4hSbPmIUS/r6+WJgNv+cmgh9YLxqsSstm/ LpnnK8+4e8x9mb2So800eEKob/7dVV1ZwRbSDMDcJlBUvv48Ur9EYLKd9QV5wHdqXB1u /Zgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5Z/Hjj99HzjQ1N0jW5e89iMPJMmOiMUOJtQRQkuPG/0=; b=f7xdz591Tf2qxakA9Zvj5Qn4WSf8InsRYEjMMm9fYhbRa4WMjP5rPJNL5h9jojQcWQ dNf58NVrFfir+XPNyFUBAynYDl7V1pJ2p2NW7jXsqX/tXgVkU7CaEkRZrr+vxJrZAEyU k/er4oYsycpKfY3AL8JZuSFxrPEubMXl7UnJvNhGhkRqiuBIBlQ8XP7E9fOxzzH/1w0w ae0GigvXPds8NyEZY2ReHvBsrECjpIZ/oExBEb4giZtAoNmloWorMS/mLKvBLvBbTCF6 7BEciCqfODiNN3Z6wmnsjPGyn83zxi1Jx2DFYnsTsN/Wn9Zyp44CJnHMW3NlRoSGmRmW +BBQ==
X-Gm-Message-State: AOAM531mchQujkZu8wRRUoRJqlh+gbSWlMv3oRwuT7pwj+jasGzhvFG7 61jFTvTqnWZryi8hW9IRiXC/SNw1zXXqmmp+o2nLWQ==
X-Google-Smtp-Source: ABdhPJw1q5S84hKKN2qW/sRmR+pflfaF3QRj2ORnkbuxlGz2tR/Vj/xyv75ChuuD5Gl7iDoQdHlpigzm7UQD1HPXtgo=
X-Received: by 2002:a9d:664e:: with SMTP id q14mr19192402otm.49.1591634324695; Mon, 08 Jun 2020 09:38:44 -0700 (PDT)
MIME-Version: 1.0
References: <159062833754.6110.5826748635235943562@ietfa.amsl.com> <3B19A920-9D33-4E3D-8B8B-8134A5E55316@gmail.com> <86D7C39D-9778-4408-B7CA-CB74E9572B1B@ietf.org> <511A3EE0-976B-40FF-813A-58CC115E760A@gmail.com> <20200605153042.nospgcd7nku4luag@crankycanuck.ca> <FB3BDBCABF6F5FE86E54BF6D@PSB> <20200606030147.jx4cyox7j5wn7a24@crankycanuck.ca> <AC2C084E4B54AAFC224B6631@PSB> <7515fd5d-9004-ec66-def1-7708ae511eb3@cs.tcd.ie>
In-Reply-To: <7515fd5d-9004-ec66-def1-7708ae511eb3@cs.tcd.ie>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Mon, 8 Jun 2020 09:38:17 -0700
Message-ID: <CA+9kkMDnYCzAYu0FC+fdi4L7Sy38NOntDD4ng3qDJ5F9W-hUcQ@mail.gmail.com>
Subject: Re: Specific Questions about Registration details for IETF 108
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: John C Klensin <john-ietf@jck.com>, IETF <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000089309f05a7953e24"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/a5mg-X2fqxrmcMtu7L51fSU8iUQ>
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, 08 Jun 2020 16:38:48 -0000

On Sun, Jun 7, 2020 at 7:51 AM Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> Hiya,
>
> On 07/06/2020 02:54, John C Klensin wrote:
> >
> > That is tied to the reasons I think that the LLC does not need
> > permission to charge a registration fee for participation in
> > online meetings.  We have established the principle that
> > identification and registration of participants is required and
> > the principle that a fee may be charged for registration.
> > Applying such a fee to remote participants (and, incidentally to
> > remote participants in WG interim meetings) may violate
> > tradition and be a terrible idea (and that may be arguments
> > about where "pay to play" come in) but I don't think it breaks
> > any principles.
>
> While I agree with a lot of the rest of your email, I don't
> agree with the above. IMO, a move from zero to non-zero is
> a change that does require community consideration.


As noted earlier, I agree with John on this.  There are two things in
tension here:  a desire to make the IETF as open to participation as
possible and a desire to make the IETF a stable organization.  We've had a
"three-legged stool" version of our funding model for at least as long as
meetecho-style remote participation.  That model has some funding come from
ISOC, some from sponsors, and some from the participants.  If the
participants cease to be a source of funding, there are long-term
implications for how the organizations functions.  If you make up the
difference with increased sponsorship, the pay to play aspects become a
risk ("*Fastly presents the QUIC Multipath working group!  Fastly, we help
good companies do great things.*" being the NASCAR problem writ into our
world).  If you make up the difference from ISOC, you are dependent on both
ISOC's funding sources and continuing priorities.  Andrew has spoken at
length about the need to diversify the funding sources, so I won't go into
it more, but please page that in.  On priorities, I believe ISOC remains
committed to the IETF, but there is an agreement on how that support works;
if participants stopped contributing, I think that would have to get
discussed again.

Or, obviously, you can cut costs.  If we never meet in person, some of the
costs go down by themselves, but there are a bunch that don't:  the cost
per page of RFCs, the work on the datatracker, the work of the secretariat
in supporting the IESG, IAB, and WG chairs.  There's no principle involved
in keeping any of those, but the impact would be quite real and possibly
much more dramatic over time than changing the participation fee structure
in light of a change in participation model.

Achieving the right place among those risks remains an effort at striking a
balance.  If you don't want to see this as a point that continues to be in
contention when striking that balance, then the way forward for you is
clear:  write a document declaring that the fee for remote position should
remain zero for the life of the organization and laying out the principles
for it.  When you have rough consensus for that, you will have demonstrated
that this is a principle, not a consequence of previous tactical
decisions.  I don't, however, think you have demonstrated that now.  It's
certainly tradition, but so are giant buffets of cookies and snacks, and I
don't think public health practice will have them coming back any time soon.

regards,

Ted





> I don't
> think we need to try reconcile those opinions right now (as
> there's a putative WG in the offing that'll discuss that)
> but just wanted to note that there are, and likely always
> will be, grey areas where it's not clear whether or not a
> decision is within the LLC's remit. I think in such cases
> the LLC needs to consult the IESG and/or community and in
> most cases defer to the community consensus, as established
> via our usual processes. There are also many non-grey
> areas (e.g. t-shirt shipping) where the community ought
> not (but will:-) nit-pick, but it's important for the LLC
> to make sure to distinguish things where the community
> needs a debate before a decision can be made. As there's
> no magic rule that distinguishes those cases, this comes
> down to experience with this community and judgement.
>
> Cheers,
> S.
>
>
>