Re: [Ietf108planning] Registration open for IETF 108

Ole Jacobsen <> Thu, 11 June 2020 00:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C8B93A0CA6 for <>; Wed, 10 Jun 2020 17:18:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mNpkg9NknydY for <>; Wed, 10 Jun 2020 17:18:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D48CE3A158D for <>; Wed, 10 Jun 2020 17:18:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=1a1hai; t=1591834715; bh=K3hKaTJDtxBxn6q0Y36OXbGxeblXvKlV9I9vqFd0+HM=; h=Content-Type:Subject:From:Date:Message-Id:To; b=j29ZA3mQOBNF7DANOPkR+g9gXWzYshkp3P74HRo0AOMS9Abla7zpp50hZZ0tTTSp6 V/Y7mEVD4aGaKP0wjSF2eOPIM+nTwChWzK+mkA9K8oPAnYmKy/7wPIp3kZNXhEY/0E YI+9Rzdqh9HMrZgbuM5XgbX8UBOqXvE8nWbzP++/PvMngfEIce9GaCxalZv19km8X8 wigq0t5sOmrBx3RYUNeDccsuMjsjt0nApoTaCV6EoiiIISKVH3s54FLmf59wE/Tfeu iRTctjRAtfgGsIZqs3q2ks7aSS4isHayrB+LF/DaK3VdcLWQucz+Nh5sb7CtK0uOW3 Tcv7SiiG/IzdQ==
Received: from [] ( []) by (Postfix) with ESMTPSA id 49C2940078B; Thu, 11 Jun 2020 00:18:35 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: [Ietf108planning] Registration open for IETF 108
From: Ole Jacobsen <>
In-Reply-To: <>
Date: Wed, 10 Jun 2020 17:18:34 -0700
Cc: Ole Jacobsen <>, "" <>, ietf <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: George Michaelson <>
X-Mailer: Apple Mail (2.3124)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-10_13:2020-06-10, 2020-06-10 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2004280000 definitions=main-2006110000
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 00:18:37 -0000

I agree 100% with George and would just add NANOG to the list of meetings
that went from f2f to online. NANOG used a cute “enter coupon FREE at
at checkout” approach which then discounted the fee to $0.00.

Most of all, it seems to me that the timing aspect of this decision
is all wrong. It really doesn’t seem that long ago that we had IETF 107
go online followed shortly thereafter by various lockdowns all over the world.
I agree that the issue is not so much the actual fee as it is a change
in model and the perception of our open process. Those active dedicated
participants who would normally attend in person will probably still
brave the timezone challenge and attend, while “lurkers” and observers
who are otherwise unable to attend might just not bother if they have
to pay. At the end of the day, I do not think that is good for our community.

One datapoint: The RIPE meeting which went “virtual” in May had *record*
attendance (and no fee).


> On 10 Jun 2020, at 17:01, George Michaelson <> wrote:
> It would be entirely normal for a body which is not primarily about
> earning revenue, to incur the risk of LOSING revenue in a significant
> change from f2f -> online, in order to understand the nature of the
> problem. This would not be incorrect. Its a decision an LLC can take:
> incur some costs, to understand your problem. Its a capped risk. It
> cannot exceed the loss of revenue of the total number of IETF
> participants.  (that is btw a loss of income, not necessarily a loss
> running the meeting. So it could arguably be called an opportunty cost
> more than a loss)
> So, I would actually expect an un-capped fee waiver to be available
> and to base the worst-case risk side of 'how many waivers do we need
> to fund' on how many people elect to take the option.
> I haven't yet seen a cost model which explains how the free
> participants remotely represent a cost to the IETF to run. Is there a
> volume based charge in Meetcho? Is there a volume based cost to the
> infrastructure to run the web-casting?
> I note that every meeting I have attended online this year (RIPE, DNS
> OARC32 (I am on the board) and the up-coming ICANN RoW) have been
> entirely free. Two of the three examples would normally charge.
> I simply don't understand how either the LLC or any other body decided
> there had to be a limit on "free" noting that many of us expect to
> pay, but an uncounted number of us might suffer financial hardship
> which in previous times, was unassessed and hidden in 'remote
> participation is free' models.
> I think this is a huge departure from our norms. I would have expected
> this to be discussed.
> -G

Ole J. Jacobsen
Editor and Publisher
The Internet Protocol Journal
Office: +1 415-550-9433
Cell:   +1 415-370-4628
Skype: organdemo