RE: [Ietf108planning] Registration open for IETF 108

John C Klensin <> Fri, 12 June 2020 02:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5233F3A0E49 for <>; Thu, 11 Jun 2020 19:45:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4qxAFqo-lLcc for <>; Thu, 11 Jun 2020 19:45:42 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA4673A0F31 for <>; Thu, 11 Jun 2020 19:45:13 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1jjZgu-0006xX-8j for; Thu, 11 Jun 2020 22:45:12 -0400
Date: Thu, 11 Jun 2020 22:45:05 -0400
From: John C Klensin <>
To: "''" <>
Subject: RE: [Ietf108planning] Registration open for IETF 108
Message-ID: <57A8DFEE1187BEA153479578@PSB>
In-Reply-To: <>
References: <> <> <> <5FCC8656386268B41681E1DE@PSB> <> <> < om> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
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: Fri, 12 Jun 2020 02:45:43 -0000

Responding to the thread since Barbara made her proposal (and a
few messages before that) rather than to any individual

(1) I really like Barbara's model.   I think we could put a lot
of time and energy into adding details and options and
fine-tuning, but I suggest that we would be better off using it
for IETF 106 in relatively simple form -- more or less the form
in which she first proposed it-- and viewing it as an experiment
from which we can try to learn.

(2) Be really cautious about moving in the direction of annual
membership fees -- especially if you have any concerns at all
about corporate bean counters.  For the reasons Joel gave, as
well as what they are used to from working with other
organizations (including other standards developers in the
Internet and telecommunications spaces), requests to them for an
annual membership fee for multiple participants are almost
certain to morph into demands from them for corporate
memberships so they can determine who to send to a given meeting
at the reduced rate.   For organizations large and well-off
enough to have such bean counters, if they get the corporate
memberships, it won't be long before they insist on seats on our
financial management board or its nearest equivalent to be sure
their money is being spent well.  Those kinds of issues rarely
come up with registration fees but, as soon it starts being an
annual membership fee, it is out on the slippery slope.  Also
keep in mind that several of the companies who are sponsoring or
authorizing enough employee participation in the IETF for an
annual membership fee to add up to significant money are also
making significant contributions to the IETF now in the form of
donations and meeting sponsorships. Behaving in a way that the
same bean counters might see as trying to squeeze them for fee
revenue could easily lead to the sort of internal conversations
that would cut those contributions off -- not a wise fiscal

(3) Even if we arrive at a satisfactory conclusion about this, I
hope we don't lose sight of the underlying question of how far
Jay's authority, or that of the LLC more generally, extends when
it comes to changes that can affect the standards process rather
than, e.g., determining the amount of fees that already exist.