Re: Registration details for IETF 108

Brian E Carpenter <> Sun, 31 May 2020 22:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0D9F3A0400 for <>; Sun, 31 May 2020 15:33:38 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pY2URC8pIixp for <>; Sun, 31 May 2020 15:33:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 44BCD3A03F6 for <>; Sun, 31 May 2020 15:33:37 -0700 (PDT)
Received: by with SMTP id i12so4103pju.3 for <>; Sun, 31 May 2020 15:33:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=SpATy/QPYco8kxKV+qICJKK/O3+LWaXUafVtSYWl+6I=; b=nNr54xTlR/lTNTKnduvvKkLhyVqUw+07YkNwfyAG8FeT/Fx2Z/62WDVoDmJ40WhxuN YqYYS1sxra+qhH+3yKjCsR7U8c2mq/RzPT+F+XRAvslQsmBngUa10UNGDuXOPqWBVl2a R/8FwHa9P1+4g09HZTD2uZYuhFV0nIIxzb9f+W/9lQXNuOLCGH32MzX54Urs4p95EWM7 w2axkwP+ftbbsmT/xg0UQM5fQcH/tPveNsF/IFzvgQ9OBxaL2wqzV6IsscM1DaloOaqW IKX7LOEBiHPWrfKOPB1tns2rKLgPuo/uFRIk41F4h6r/6++Xk37NNWd22uMKQB/Ew5F+ wS1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SpATy/QPYco8kxKV+qICJKK/O3+LWaXUafVtSYWl+6I=; b=hkUT9DMHU5KQ+Kai7Imbu+NHMOIk/5m4zbVGq8vwan/mXUFsz05PsnHfOBpLIqr1lZ RsYBN+SKAybz+gbWZ2pCb8ORol/Mk5VOP0Ptu8MHQf0YxYJ9q0iqytwMQ7/JlqJM8/qH O2GGgn/SmW637lZT1tsSH2ZPki7ysgR6ijivTcNWDuhdOXS1AwgNM2N5SF+w8auPDTQN KQRqhU/KFbhsg+F3fRuhyOs9TzuF8um/YCkkCC8bGG14BBGBxIQNJ3sBDLR+v79ynuie UvgrfOBUqdYwibO1TpBIoTUPf3cZ3ZoSahfhNMpEhESLSbNItRxWehSYGM+YVTIuBgUV t5jg==
X-Gm-Message-State: AOAM530Apy4TbfHySUV7/TRo3IqmVKD+/9Sm1hMqtONS/oEoVlnGbFhT ghJg839GN4r9hOtabalwHrDDzHh1wWQ=
X-Google-Smtp-Source: ABdhPJwllwwNOrngtE7Kg4bUCFYiHAaz2r0oyZEdfuPdG4f9EO+y2x9DPzS/7f6IFXBHe8efkJszRQ==
X-Received: by 2002:a17:90b:ed5:: with SMTP id gz21mr3179336pjb.214.1590964415256; Sun, 31 May 2020 15:33:35 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id v13sm11136366pff.27.2020. for <> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 May 2020 15:33:34 -0700 (PDT)
Subject: Re: Registration details for IETF 108
References: <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Mon, 1 Jun 2020 10:33:31 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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: Sun, 31 May 2020 22:33:39 -0000

On 01-Jun-20 09:44, Melinda Shore wrote:
> On 5/31/20 1:13 PM, Eric Rescorla wrote:
>> I don't think the characterization of this as "pay-to-play" is accurate. You
>> are certainly free to participate in mailing lists, github, etc.
> I'm somewhat troubled by this, as well, tbh.  

What troubles me is the lack of a debate in the community before this
was announced with about a week's notice.

For my own part, I have no idea whether I would have to pay this out
of my own pocket or not, and determining that would take more rounds of
email than can happen before registration opens. Since this isn't a
travel-related fee, the procedures many of us are used to for meeting
fees don't apply. I'm very much aware that this is the new normal,
but it's going to take a while for employers' approval procedures to
catch up. How many people will be excluded for that reason?

It probably doesn't matter in my case since the announced timezone
for the meeting rules it out anyway, but as a matter of principle,
we haven't had a debate about the principle, and that seems wrong.
For example, 

1) Is listen-only attendance charged the same fee as listen-and-speak?
If so, is that right or wrong?

2) Why is there a late fee? It's not as if extra cookies have to
be bought at the last minute.

And I'm sure there are other questions.


> To the extent that
> the IETF has gradually and effectively moved to having decisions
> made in meetings it would be unfortunate indeed to exclude
> people based on financial circumstances.  I'd like to see the
> decision-making situation fixed but given the history of that
> discussion I think we are where we are, and free remote participation
> provides at least some mitigation.  I also tend to think that
> saying that meeting participation isn't necessary because {mailing
> lists,Github,whatever} is incompatible with the insistence that
> the IETF continue to meet because it's not really possible to
> progress work without real-time discussion.  I'll also note that
> for as long as there's been a remote participation option available
> it's been free.  We're now in the odd position of having all-remote
> meetings absorb what used to be "remote participants" into the
> group of "participants," with some consequential side-effects
> (although arguably there are no such things as side-effects, just
> effects).
> I do think this decision has some unintended consequences.
> Scholarships or other subsidy might provide some mitigation
> but would potentially be messy/awkward.  The organization
> is long overdue for some navel-gazing about working methods.
> It's unreasonable to expect perfect consistency but I think
> things have gotten a little more incoherent than they should
> be.
> Melinda