Re: Specific Questions about Registration details for IETF 108

Andrew Sullivan <ajs@anvilwalrusden.com> Sat, 06 June 2020 03:01 UTC

Return-Path: <ajs@anvilwalrusden.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 DD8AC3A08D1 for <ietf@ietfa.amsl.com>; Fri, 5 Jun 2020 20:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=yitter.info header.b=E+FqSWPy; dkim=pass (1024-bit key) header.d=yitter.info header.b=R6+ozgss
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 yKFIcHPLsvFx for <ietf@ietfa.amsl.com>; Fri, 5 Jun 2020 20:01:50 -0700 (PDT)
Received: from mx5.yitter.info (mx5.yitter.info [159.203.31.152]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4883A08CD for <ietf@ietf.org>; Fri, 5 Jun 2020 20:01:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx5.yitter.info (Postfix) with ESMTP id A3B29BD518 for <ietf@ietf.org>; Sat, 6 Jun 2020 03:01:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1591412509; bh=f8hF9Hv77os6s7Sb2ENs+KTSlexbjwQ2llEezXMyPmk=; h=Date:From:To:Subject:References:In-Reply-To:From; b=E+FqSWPy2i5Fi8TCElWpKwoKhRZSSnbrvhO+wgTDjSKJhuHqTlx6Pi7sL6nZodJRs A5tfl6eZFBbBq2luhVnV8S7TrvHiLUm/VBItWJnP44k8FXPum1j+fsN64eWgkwA/aq rOfO/jclNpjybx5uIg2D1Sn3RQzPGyb1q0EhEb4Q=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx5.yitter.info ([127.0.0.1]) by localhost (mx5.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCS4eZjZSffW for <ietf@ietf.org>; Sat, 6 Jun 2020 03:01:48 +0000 (UTC)
Date: Fri, 5 Jun 2020 23:01:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1591412508; bh=f8hF9Hv77os6s7Sb2ENs+KTSlexbjwQ2llEezXMyPmk=; h=Date:From:To:Subject:References:In-Reply-To:From; b=R6+ozgssw0GBfXmh7nBFR8npgXuqbC/oMvH61HgvG98YiqGQvPFDNkJHun33IEIYH 0sLLCWEn30LfSa1VS2rwUFeDnO+L2wh7ZwVwJAOb9Ju4OObsibkrAp6XGbO+xaQ3mN s6iHSClvnEBh54AjaU8eeVU0LTz5NONrq+jXcjUo=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: IETF <ietf@ietf.org>
Subject: Re: Specific Questions about Registration details for IETF 108
Message-ID: <20200606030147.jx4cyox7j5wn7a24@crankycanuck.ca>
Mail-Followup-To: IETF <ietf@ietf.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <FB3BDBCABF6F5FE86E54BF6D@PSB>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Yj7RYitSfq8H4_3kj2PtCtPt4bY>
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: Sat, 06 Jun 2020 03:01:53 -0000

Hi,

[ObDisclaimer: employed by ISOC as CEO.  Not their/an official
opinion, just mine.]

On Fri, Jun 05, 2020 at 09:35:57PM -0400, John C Klensin wrote:

>in ordinary ways.  I also don't believe there is anything in the
>LLC documents that permits the LLC, or its contractors or
>appointees, to say "this is an emergency and hence we get to
>make changes to the standards process especially if those are
>just consequences of other decisions".

I think we are in complete agreement about that.  To be clear, my
remarks about managing the LLC had much more to do with observations
about how t-shirts should be allocated or delivered or even made,
whether there should be early/standard/late registration, and so on.
I thought we had agreement as part of IASA2 that these are just things
the staff are supposed to decide.  Checking with the community is
correct.  Debates with the Executive Director on the IETF list are
not, if I understood the consensus then (noting that I was not then
judging and do not now wish to judge it).

>(1) The IETF has had a practice (I'd claim a principle) that
>people are allowed to observe sessions in real time, without
>identifying themselves or paying a fee, since "observe" meant
>audio-only and multicast.

In this case, we may be running up against realities of history and
what was feasible.  I was certainly not around at the time of the
earliest IETFs (my first was 64), but are you really asserting that
the IETF _always_ allowed anyone to go into any meeting without
"joining" in some sense?  I thought the point of the "decisions on the
mailing list" was to avoid this problem?  This is not to discount the
issue that continues to plague the IETF about how decisions are
actually made.  Still: a more-asynchronous and more-distributed form
of work such as is being forced again on the IETF might actually be
salubrious.  It encourages the mode of decision-making that includes
people not actually in the room at a moment, even if mailing lists are
not the ultimate mode by which such decisions ought to be made.  (I
think those are separate questions, much as I personally like mailing
lists as a mode of operation.)

>(2) The IETF has never charged for active remote participation,
>even when someone remote was asking questions via Jabber (or its
>predecessors) or having audio (and sometimes video) piped into
>the room so they could present.

But this way of describing the topic requires "the [real] room" and
"the remote" as distinct entities, with one of them the preferred one
and one a degenerate case.  One might just as easily cast this case
as, "Remote participation as a degenerate case is, for exigent
reasons, over: everyone gets the same experience."  In that case, it's
not that "remote participants" are losing something, but that there is
no class, "remote participants".  In other words, the flattening of
the participation space into a single class means that everyone has to
pay the same ticket, or not be in.  (Again, to be clear, I don't
personally have an opinion about how this ought to go -- I'm not
really a useful attendee in any case.  These are just my personal
observations.)

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com