Re: Specific Questions about Registration details for IETF 108

Carsten Bormann <> Tue, 09 June 2020 18:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D2023A0CD5 for <>; Tue, 9 Jun 2020 11:23:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g5yJmmdvpp6b for <>; Tue, 9 Jun 2020 11:23:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE3C43A0CD4 for <>; Tue, 9 Jun 2020 11:23:54 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 49hJRC39PTzyXp; Tue, 9 Jun 2020 20:23:51 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Subject: Re: Specific Questions about Registration details for IETF 108
From: Carsten Bormann <>
In-Reply-To: <ED0D140CAE95FA7851E7389C@PSB>
Date: Tue, 9 Jun 2020 20:23:50 +0200
Cc: IETF <>
X-Mao-Original-Outgoing-Id: 613419830.914197-1436929922c9c0a53cbfceb906a5c4d2
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <FB3BDBCABF6F5FE86E54BF6D@PSB> <> <> <ED0D140CAE95FA7851E7389C@PSB>
To: John C Klensin <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Jun 2020 18:23:58 -0000

On 2020-06-08, at 21:11, John C Klensin <> 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