Re: Registration details for IETF 108

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 02 June 2020 16:03 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 C3E023A0C3C for <ietf@ietfa.amsl.com>; Tue, 2 Jun 2020 09:03:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Level:
X-Spam-Status: No, score=-1.397 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_H3=0.001, RCVD_IN_MSPIKE_WL=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 kxVI1Qvh5fOk for <ietf@ietfa.amsl.com>; Tue, 2 Jun 2020 09:03:51 -0700 (PDT)
Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) (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 350753A0C1B for <ietf@ietf.org>; Tue, 2 Jun 2020 09:03:51 -0700 (PDT)
Received: by mail-ot1-f42.google.com with SMTP id g25so11269395otp.13 for <ietf@ietf.org>; Tue, 02 Jun 2020 09:03:51 -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=8FlLpSKAH+7kAted0MpBhusWcSurGC3j+OQYYczWYyQ=; b=FS1YM0/niLPsKOyRyPzMNeg/c8qJp6K26cQDrns35uT9YLMS97Z4Wmsv4wai5hIs/T jQmoNdfvhvHqNS/PkNrgeeTJr+nkvvRU2OAXf5eA18Ix7JvpulPWM0Ru8GgMsF711YKa a43EnF0qyBVZkNf9XePxEqM1EWooNOwewFV7xTE4n+PWsawcAjJgViXl23uNCysrN2Cm q80VxbgiSGxWZpRT1NMGh2Gf73lq+kvAjYiOTaa3XRqz7kexKH5o9haIVPanmWmZeL2r sdpjoOZXuNuKCFiVw8v7uzd0+Wgo3bDsqTVJIi0A4kynpsb8L/F1D4o3glnrKZW4OL2N t7ng==
X-Gm-Message-State: AOAM531EWEuTUnBmfdzNz9OWuU6j0WGiZBrSlw0b4hO9GDQJRVfkl52V om/DtlB6GIVOms/LroNRAmxkUeD0DHuRRPrK1odDUqJV
X-Google-Smtp-Source: ABdhPJzYyFFCqr+Ya5ghqx4woyCKHa8z8mydY6LG4FxKMjEZobV2g6NXcKpFQd0N4ytuubFvhD/8UmAtSh6Z6sUVN7s=
X-Received: by 2002:a9d:220c:: with SMTP id o12mr6421ota.155.1591113830414; Tue, 02 Jun 2020 09:03:50 -0700 (PDT)
MIME-Version: 1.0
References: <159062833754.6110.5826748635235943562@ietfa.amsl.com> <6.2.5.6.2.20200531121457.0b249858@elandnews.com> <CABcZeBOzVHaSZa0A3eDz12RwNuCiHtiJL8wqvAhhLPN6YEQOkQ@mail.gmail.com> <3f9a0e50-c01b-01c6-ad52-95f370baeb8d@joelhalpern.com> <B71999A2-3EC6-4649-864F-674BA494B511@gmail.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> <0da9f8f0-867e-cd18-3fd9-39cabe0208a0@foobar.org> <CABcZeBM2CNHcC0UxLZdkQ3xbtpsnWkUqeSuCyFjCFeEENNKnrg@mail.gmail.com>
In-Reply-To: <CABcZeBM2CNHcC0UxLZdkQ3xbtpsnWkUqeSuCyFjCFeEENNKnrg@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 2 Jun 2020 12:03:39 -0400
Message-ID: <CAMm+Lwife0w5conrdBgz+3YAWQ1bZg1_EjHXaEVbzmxp0rH1Tg@mail.gmail.com>
Subject: Re: Registration details for IETF 108
To: Eric Rescorla <ekr@rtfm.com>
Cc: Nick Hilliard <nick@foobar.org>, ietf <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a8be3305a71c0e0c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/vJme0hlNvzTgPEESDbqgJuXqjmA>
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: Tue, 02 Jun 2020 16:03:53 -0000

On Tue, Jun 2, 2020 at 9:29 AM Eric Rescorla <ekr@rtfm.com> wrote:

>
> On Tue, Jun 2, 2020 at 6:16 AM Nick Hilliard <nick@foobar.org> wrote:
>
>> Eric Rescorla wrote on 02/06/2020 13:57:
>> > This seems like entirely appropriate practice on short notice.
>>
>> neither side's position seems unreasonable from their own point of view:
>> the LLC needs to make executive decisions and sometimes these will be
>> problematic. Conversely, the IETF community has an expectation that
>> there's engagement about policy changes before they happen.
>>
>
> Hmm... This doesn't seem like the right framing to me in several respects:
>
> First, I think everyone agrees that some kinds of policy changes would
> need consultation. For instance, if the LLC were to decide that in
> perpetuity we were not to havemeetings or that we were to have 6 a year,
> that would clearly need consultation. On the other hand, I (would hope)
> that everyone agrees that some changes could be made by executive
> decision. For instance, moving the refund date forward or back by a day
> would I hope not require community consultation. So the question at hand is
> what kind of decision this is.
>

Indeed in this particular case, there are no alternative choices available
and thus no decision to be made.

I have spent far too much time over the past four years explaining to my
former Oxford friends that reality isn't something you decide by
referendum. Reality isn't subject to consensus calls either.

The brute facts we face are that international travel is certain to be
infeasible for the remainder of the year and quite likely for some time
beyond, that the IETF business model is predicated on income from in-person
meetings that can't now take place and this leaves few options on the table.

Making standards is fundamentally a process of making the choices that
don't matter - except to the extent it matters that we all do the same
thing. In this case they aren't even really choices.

Second, as you can see from the thread above, it's not correct that "the
> iETF community" has an expectation they should have been consulted about
> this in advance. Rather, part of the IETF community does and some of it
> thinks this was fine.
>

Rather than 'fine', I would use the word 'unavoidable'.