Re: Specific Questions about Registration details for IETF 108

John C Klensin <john-ietf@jck.com> Tue, 09 June 2020 19:06 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 71DF63A0D68 for <ietf@ietfa.amsl.com>; Tue, 9 Jun 2020 12:06:41 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 lS4LyD33cDpp for <ietf@ietfa.amsl.com>; Tue, 9 Jun 2020 12:06:38 -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 6476F3A0D65 for <ietf@ietf.org>; Tue, 9 Jun 2020 12:06:38 -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 1jija0-0000oo-TV; Tue, 09 Jun 2020 15:06:36 -0400
Date: Tue, 09 Jun 2020 15:06:30 -0400
From: John C Klensin <john-ietf@jck.com>
To: Carsten Bormann <cabo@tzi.org>
cc: IETF <ietf@ietf.org>
Subject: Re: Specific Questions about Registration details for IETF 108
Message-ID: <431DBBD2442A1A8236C638D7@PSB>
In-Reply-To: <5A6C6F55-0FCD-4925-AB99-F8A5432ADA98@tzi.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> <20200606030147.jx4cyox7j5wn7a24@crankycanuck.ca> <3aa1a619-904d-d699-52b3-32590b4093b9@labn.net> <ED0D140CAE95FA7851E7389C@PSB> <5A6C6F55-0FCD-4925-AB99-F8A5432ADA98@tzi.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
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/gKtjdB2eqiZ_j7mcjAkMHFteKr0>
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, 09 Jun 2020 19:06:48 -0000

Carsten,

I was at both meetings and concurred with the decisions.  "Blow
off" was probably too strong, but, as best, those examples
demonstrate that we have been willing to be flexible and
pragmatic about those principles.  However, that pragmatism
takes us back to the underlying questions about scope and
authority.  If the principles are treated as firm (or we review
the decision-making in those cases and discover that there was
strong consensus about the exceptions and that they were
one-time events), then, for example, deciding to charge for
remote participation is a binary decision on which the community
should (or maybe MUST) be consulted.   It the principles are
flexible given special conditions, then, as long as is is a
one-time decision that does not set precedents or mark a
permanent change, it is perfectly appropriate for Jay, or the
LLC generally, to say "unusual situation, no time for adequate
consideration, let's impose the charge and watch to see if there
are ill effects from which we should learn".  To a first-order
approximation, that is what has been said.

YMMD.
    john


--On Tuesday, June 9, 2020 20:23 +0200 Carsten Bormann
<cabo@tzi.org> wrote:

> On 2020-06-08, at 21:11, John C Klensin <john-ietf@jck.com>
> wrote:
>> 
>>> FWIW I think the principle went beyond just observation.  I
>>> remember Phil Gross saying, when he was IETF Chair, that the
>>> IETF didn't check badges at meeting room doors since it was
>>> more important to have good technical contribution than to
>>> block those who couldn't pay.  Of course, this didn't mean
>>> allowing anonymous contributions or that those that payed
>>> weren't subsidizing those who didn't.
>> 
>> We of course blew that principle off when we had a few
>> meetings in which where badge checks at meeting room doors
>> and we tried experiments about badge readers at microphones.
>> And, IIR, we instituted the former with a lot less discussion
>> and fuss than the current changes have caused. 
> 
> Badge readers always were optional (I never managed to
> properly operate one).
> 
> Badge checks were a one-time thing needed for a meeting in a
> country that made this a prerequisite for Internet access.  I
> think we accepted that regression as the one-time thing it was
> because Internet access is something very unusual in that
> country and we were very happy to be able to meet there.
> 
> No, we did not "blow that principle off".
> 
> Grüße, Carsten
>