Re: [Tools-discuss] [Manycouches] Proposal to discontinue live mp3 audio streams at IETF meetings

John C Klensin <> Fri, 02 October 2020 01:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 892F73A0A84; Thu, 1 Oct 2020 18:03:49 -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 NqhcRYJxaVsX; Thu, 1 Oct 2020 18:03:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB2FB3A0A83; Thu, 1 Oct 2020 18:03:47 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1kO9U7-000Kbf-AT; Thu, 01 Oct 2020 21:03:43 -0400
Date: Thu, 01 Oct 2020 21:03:37 -0400
From: John C Klensin <>
To: Brian E Carpenter <>,
Message-ID: <14FC90BA1260E306F5DB4D31@PSB>
In-Reply-To: <>
References: <> <>
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: <>
Subject: Re: [Tools-discuss] [Manycouches] Proposal to discontinue live mp3 audio streams at IETF meetings
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Oct 2020 01:03:50 -0000

Out of a desire to stay out of this discussion, I sent a private
note to Robert earlier today that I will not try to reprise
here.  However...

--On Friday, October 2, 2020 08:42 +1300 Brian E Carpenter
<> wrote:

>> * This removes a mechanism that allowed people to listen to a
>> session in real-time without paying a registration fee.
>>     There will be ongoing discussion and tuning of the
>>     meeting registration structure. In the meantime, the fee
>>     waiver program is available and  being
>>     improved.
> I don't think that's a tools-discuss decision alone. It's been
> a significant point of principle discussed (e.g.) in SHMOO,
> hence the extra CC.

Right.  And I think there are some very broad principles about
who we are willing to disenfranchise, whether we are willing to
insist that people give up privacy to observe our meetings;
whether real-time observation is actually needed or whether
people who just want to observe can watch or listen later;
whether policies that require either registration fees that are
not tied to ability to pay or asking for fee waivers are
inherently discriminatory against, e.g., people from developing
areas; how many people have to be pushed out before it is an
issue (note the tie to Robert's "not many people are using the
mp3 feed); etc.  

To me, there is also a small elephant lurking around the corners
of the room having to do with just how serious we are about key
discussions and decisions occurring on the mailing lists.  My
recollection about what I heard when the IETF got started --long
before real-time remote participation was feasible for most
people -- was that there was not a lot of concern about these
issues, not because people were backward, but because it was
very clear that meetings were about discussion and getting a
shared understanding of the issues and how to explain them, not
about "deciding" or even "agreeing".   I suspect that a really
pure form of that approach may be somewhat mythological, but the
difference between even a watered-down version and the "decide
in meeting, ask on mailing list if there are any significant
objections" pattern we've seen frequently in recent years is
still significant.

However, I think my main point is similar to Brian's (if I
correctly understand him): it is time we have discussions about
principles and make decisions about them and then answer
questions (probably easily) about what services we need to offer
and how they should be arranged and/or delivered in terms of
those principles.   Making a decision about something like an
mp3 feed (and a variety of other things) in isolation is
unlikely to lead us to good places. 

> It seems to me that the principle of the fee waiver and when
> it's ethical to use it is still not clear, and we don't know
> whether it is financially viable in the medium to long term.
> Until that's settled, I'm a bit uneasy about dropping the mp3
> streams, precisely because they do not need pre-registration.

> (If meetecho had a "read only" or observer mode without
> pre-registration, this problem would go away instantly.)

Which, of course, Meetecho, in its IETF form, had in the
original distinction between joining as an observer and as a
participant until "we" decided to shut it off in the run-up to
IETF 108 (or IETF 107 if not using Meetecho at all for that
meeting counts).  The problem is not what mode(s) are available
but where we draw the dividing line about who gets a free ride.
Personally I have a lot of difficulty justifying free mp3 live
streaming but requiring that "read only" / observer Meetecho
users pay, but YMMD.

And I see parts of those things as both important but larger
parts as just another symptom.  We need to look at whether to
make a distinction between observers and participants and
whether the latter (at least) are pay to play... always, or only
when a meeting is all-remote.  We need to figure out if there is
any real justification for requiring that observers be able to
observe in real time and, if not, how much delay in getting
video (and audio?) posted is tolerable.  And so on.  I think
that, if we have answers to those sorts of questions of
principle, most of the questions about live audio feeds and even
fee waivers will largely fall out.