Re: Registration details for IETF 108

Ted Hardie <> Tue, 02 June 2020 21:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 532843A100A for <>; Tue, 2 Jun 2020 14:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 fioLU9QS9ulW for <>; Tue, 2 Jun 2020 14:16:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D25BC3A1008 for <>; Tue, 2 Jun 2020 14:16:47 -0700 (PDT)
Received: by with SMTP id s13so102812otd.7 for <>; Tue, 02 Jun 2020 14:16:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MWu2OAtVIScZYqi/ZnFC1SqjFilPTm9gHR5wsY5IZbU=; b=JMQkK+sjlecL6AlkLJMVM+2+tnHtNn4HGmJoxB2K2/2qBQ0+1IxBSzy+p09W+HN/84 jY9MILO5653lH8UK4s95pyxeSkVlq9cJJe1Ri115ng2u1HSDgXDo/0Y2qqsGD/8Z9azV TJBko2sYtoRkZ3dlgzO0/gwn47v29aYS4RVJd8dsU66DVOEbcNNAZCkuGD22M3lWxPG5 XfdhwuSXxsALhNIIOaCfNeATUBJHqypk0YTa3FIvRqqRfdC0s56df7mF34K5kLylltkc l+SY2oQ6QCwJ0gf27ehBiSSPDzlUBc6h8GOhUesgxSQ18ymfA3zg38yKOknlXyphsG4U 6RTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MWu2OAtVIScZYqi/ZnFC1SqjFilPTm9gHR5wsY5IZbU=; b=eQhaPDpdIhbjNwh08HsmYZzLDMpJB2VIH7M1jqugIkiUJLDgI9ZDQmwpEamKoEOfgH hk4ku5i16r3UQK2gFd9t4QiF2uivaOFYYWBHiWTcNdEa3s60fkDHqf2Jz3cTuOYtKlnm PpswBTVGCin4tnGiZDIN3EL+beU3WWdTlxA9HQcVINvb5647hkSiYIMN8JQYwAF1NCg8 GFUUc6hfN78H6GbKmcqH4ZFgvIYutfZ9CfNEKjxI0Fa21QYOX3IO2zHaf78DMlz9ZsQa ZLolpFTr8QHwIfzqQ+7RdTpj2a572x7Px04BQb8X8OA+rMcGfzfEHAhomqLpgpws1hz4 12dA==
X-Gm-Message-State: AOAM533B6G3bEpREZYwUBAf8qIl7cXDvMJaLuh7ghr+4XPDS3/EvB8Pi 5o8xvLsqcrf1j6PUn7png407xQf34C1Bm/wxMUc=
X-Google-Smtp-Source: ABdhPJw2To4OyVJRg6sb3zAbAZygniKNZTCeZnYG4Jacf3XiZ5AAn0+Cgft3ao3Yem2mc2QBK2kDNGYfBCKJ84Uj26c=
X-Received: by 2002:a9d:aaa:: with SMTP id 39mr807340otq.269.1591132607114; Tue, 02 Jun 2020 14:16:47 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <D3BA93CD3D2D101946F35024@PSB> <> <01d701d638ca$c096b5e0$41c421a0$> <> <> <> <>
In-Reply-To: <>
From: Ted Hardie <>
Date: Tue, 2 Jun 2020 14:16:19 -0700
Message-ID: <>
Subject: Re: Registration details for IETF 108
To: Stephen Farrell <>
Cc: Eric Rescorla <>, Mehmet Ersue <>, ietf <>
Content-Type: multipart/alternative; boundary="000000000000d672d505a7206d59"
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, 02 Jun 2020 21:16:49 -0000


On Tue, Jun 2, 2020 at 1:56 PM Stephen Farrell <>

> Hiya,
> On 02/06/2020 21:44, Ted Hardie wrote:
> > You appear to be arguing that moving from zero to any number
> > for a particular class of participants effectively excludes some of those
> > participants from the standards process and because that would be a
> > standards process change, that would pull it from their bailiwick.
> No. I'm arguing that the move from zero to non-zero ought
> be an IESG decision, based on community discussion. That's
> not only because it might exclude people but also because
> such changes can have longer term and subtle effects. One
> already pointed out on the wg chairs list is that this
> may create an incentive to have virtual interims for WGs
> outside the IETF meeting week, as those don't have a fee.
> That could be good, bad or indifferent in terms of the
> standards process.

And the decision by the IESG on the timing of the interim will have an
impact on registration and thus on revenue; clearly the two groups (LLC and
IESG) should talk to each other (and the wisdom of having an IESG appointed
member to ensure that is pretty evident).

But somebody has to be the stuckee for the decision on the money side of
that, and at the moment it is the LLC.  Having been on the IESG before the
IASA process, when the IESG did all of that, I will personal object to any
effort to shove that level of decision back on the IESG plate.  The money
side moved onto a different set of plates for darn good reasons, and it
shouldn't move back.

Things were pretty plain on IETF 107:  the IESG decided to cancel the
meeting when it was no longer going to be an effective meeting (standards
issue), but the logistics of financing stayed with the LLC.

> To be clear: I'm not now arguing that remote participation
> ought not have a fee. I might make that argument later in a
> discussion about policy for IETF109 and beyond but my
> argument here is solely about who gets to set the policy. I
> do not believe that ought be the LLC. (But can live with
> IETF108 as an exception.)
The LLC is not a separate body from the IETF--it's the part of the
leadership with this set of responsibilities.  Like the rest of the IETF,
there are times when their role requires public consultation and an
assessment of consensus.   I hope you'll both trust them to do that right
and recognize that if we give them the responsibility for that job, we
ought to give them the relevant authority.



> Cheers,
> S.