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

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 03 June 2020 14:59 UTC

Return-Path: <hallam@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 962953A08FD for <ietf@ietfa.amsl.com>; Wed, 3 Jun 2020 07:59:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 E_NkhOYDIxQ1 for <ietf@ietfa.amsl.com>; Wed, 3 Jun 2020 07:59:57 -0700 (PDT)
Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) (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 F40C93A08E9 for <ietf@ietf.org>; Wed, 3 Jun 2020 07:59:56 -0700 (PDT)
Received: by mail-oi1-f170.google.com with SMTP id a21so2048590oic.8 for <ietf@ietf.org>; Wed, 03 Jun 2020 07:59:56 -0700 (PDT)
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=5a0T/n7fjzS1Jk84qDkGQh162QjxWjgp99U2eFG6KY8=; b=cUDThQamLvnvLqzVRI6wQx5Q2xnDkN6Q65OgUvaEl/Z/OlzdLTYZUybN00RdrW9u/H PVvUc7xIcb08ICB+ac0SuAmBM1dgQbT5u0qRmgo7kqZWWr8JWrmq4Yin8Tm24eQ55ywc eiEbbWDfgEgKnVI2Inw64x/jKQf3s8JuJd52lCt5tdg1xrLo8EtoM+YS9lZlrb5UFPLR Uq3+IceSalDrpDp3KnsHKtHn4XOGbYKxDqHW4YGnKVVJqznVSsyFIyf5eubLu7HljX4H D5mqzJTUSOo0UPELtOX3zjXGutSh1GVw9pjPywMKvSeEh/tdK57YAuM6ssg/R1fZE5ZM K/mw==
X-Gm-Message-State: AOAM532gGWYDX/8au0OOuPUaCvoi1gN1s7wIPnkPOBeGzOeeXrk9B/0q zlAoE/5ny/kfTNheGfmUC1bcHULU+0kadGbjLAE=
X-Google-Smtp-Source: ABdhPJzFdhTZ5UllkqViN1uFOyY5dl7aGbbu9TiqeepRmefhknKcF3H0WcLybRwTQmEM+bYAmRpE5KDxa4mID5gwNBM=
X-Received: by 2002:aca:b8c5:: with SMTP id i188mr88876oif.166.1591196391429; Wed, 03 Jun 2020 07:59:51 -0700 (PDT)
MIME-Version: 1.0
References: <159062833754.6110.5826748635235943562@ietfa.amsl.com> <616FD1DE-C25F-44CE-9FA3-CC00943FC98B@cable.comcast.com> <A9DBD8B0-01B3-4C68-91B3-BD1E99E226BA@gmail.com> <70d1493c-4c00-f32e-8996-72d0a8369571@comcast.net> <D3BA93CD3D2D101946F35024@PSB> <9F71F116-D7B2-4ECE-9000-957A0C497404@ietf.org> <01d701d638ca$c096b5e0$41c421a0$@gmail.com> <CABcZeBOLAw_9s-gobFYB=5THu_Q70UmDLn_ZhVXhNRHN_nu_0w@mail.gmail.com> <607b7682-0a75-62b6-fd0e-5e2e1171a68b@cs.tcd.ie> <CA+9kkMBEqhn115ToB0SwOGavmXze4DdJdL941J4LeVMRrPngpQ@mail.gmail.com> <e1b804ae-4c2e-fdf3-8804-47820d35facf@cs.tcd.ie> <CA+9kkMC8ZWHaCBg=WzwtriVf-3bq=egupVgAH-J7dSqspwLoFw@mail.gmail.com> <a19c3066-bfa7-ded2-d98f-b5e367645451@cs.tcd.ie> <CA+9kkMDrsRoCPFyzU7HJWoFqgg3jQ4rszQvNRMzUAAhVwn=k0w@mail.gmail.com> <583a2e86-260a-4156-2a72-dd21e789cf97@cs.tcd.ie> <CA+9kkMD+7CLeTQ2npmWeeu58A94a5DBAzfm+SVUCgn8fwxh0pQ@mail.gmail.com> <35a9b588-f8a5-89c8-8801-e3cd80d11d58@gmail.com> <7b865305-b307-9834-5467-d27835e1b5b6@gmail.com> <58619861-b7bb-03fd-6bfb-ef901a6cda19@joelhalpern.com>
In-Reply-To: <58619861-b7bb-03fd-6bfb-ef901a6cda19@joelhalpern.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 3 Jun 2020 10:59:39 -0400
Message-ID: <CAMm+LwiaOnkLjGzdo2+e5WDjPGYER4HCF20ZztU_FJKD66kpmQ@mail.gmail.com>
Subject: Re: Fees after IETF 108 [Registration details for IETF 108]
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ade1f605a72f475f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/89Y_USRh4IaaZV0JZMCJ17ILmOg>
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: Wed, 03 Jun 2020 14:59:59 -0000

This discussion is showing the limits of consensus based decision making in
the IETF.

There are two discussions we could be having, only one of which actually
involves a choice. We are currently having a discussion of the short term
issue where there is no real choice and not the long term issue where we do.

Charging for the lost in-person meetings is water under the bridge. What we
should be discussing is where we want to be in the future.


While the IETF is all about the Internet, its fundamental structures and
business model were established before the Internet. It is at root a 1980s
institution. By which I mean not that it is typical of the institutions of
the 1980s but it is a product of the thinking about institutions at that
time. There are innovative aspects of the IETF that represent experiments
in organization. But not necessarily experiments that worked.

There are very similar problems in the world of academic journals. The
business model that was established by the publishers in the 1960s makes no
sense from the point of view of the agencies that fund the research. That
has been apparent for what, 30 years? There is a law of gravity at work
here but one that takes generations to take effect.




On Tue, Jun 2, 2020 at 7:27 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:

> 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.
>
> Yours,
> Joel
>
> 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 <
> stephen.farrell@cs.tcd.ie <mailto:stephen.farrell@cs.tcd.ie>> 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.
> >>>
> >>
> >
>
>