Re: Specific Questions about Registration details for IETF 108

Samuel Weiler <> Thu, 11 June 2020 19:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AE0B3A07DB for <>; Thu, 11 Jun 2020 12:36:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.232
X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OUV5DFtvOa5d for <>; Thu, 11 Jun 2020 12:36:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 14F833A07D1 for <>; Thu, 11 Jun 2020 12:36:19 -0700 (PDT)
Received: from celebrae2015mbp ( []) by (Postfix) with ESMTPSA id 105DD62C5D; Thu, 11 Jun 2020 19:36:19 +0000 (UTC)
Date: Thu, 11 Jun 2020 15:36:16 -0400 (EDT)
From: Samuel Weiler <>
To: Carsten Bormann <>
cc: John C Klensin <>, IETF <>
Subject: Re: Specific Questions about Registration details for IETF 108
In-Reply-To: <>
Message-ID: <alpine.OSX.2.20.2006111455350.20223@celebrae2015mbp>
References: <> <> <> <> <> <FB3BDBCABF6F5FE86E54BF6D@PSB> <> <> <ED0D140CAE95FA7851E7389C@PSB> <>
User-Agent: Alpine 2.20 (OSX 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
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: Thu, 11 Jun 2020 19:36:23 -0000

On Tue, 9 Jun 2020, Carsten Bormann wrote:

> 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.

I also remember badge checks being a only-one-time thing, though 
there might be some confusion about the history.

A code was needed for network access at TWO meetings, and (IIRC) that 
code was printed on our badges.  We tested that system at IETF78 in 
Maastricht in July 2010 then used it at IETF79 in Beijing.

Badge checks happened at only one meeting - IETF79 in Beijing.  The 
IAOC explained that they were imposed by the host and/or hotel, not 
the IETF.  (We got different answers about who imposed it, and, as far 
as I recall, never a definitive one.)  As John observes, this checking 
was indeed implemented with little discussion - the IAOC implied and 
perhaps said that even they were not consulted, and the community was 
certainly not consulted.  And at least some of us were not complacent 
about it.  I raised it in the plenary, and I and others raised it on 
this list.

In any case, I think the Beijing debacle does not set precedent, since 
that requirement was imposed by someone other than ourselves.  Badge 
checking is not normal practice at a normal IETF meeting.  And the 
Beijing meeting was not normal.

Excerpts from the archives:

As for the present discussion, I am deeply concerned about the 
process, also.  My first instinct is that we should not charge a fee 
for this meeting, but, if we do, we need community consensus around 
it first.

-- Sam Weiler