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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 01 October 2020 16:33 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC943A10EC for <tools-discuss@ietfa.amsl.com>; Thu, 1 Oct 2020 09:33:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wqh6T3cJ02qp for <tools-discuss@ietfa.amsl.com>; Thu, 1 Oct 2020 09:33:20 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A8E3A10E9 for <tools-discuss@ietf.org>; Thu, 1 Oct 2020 09:33:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id DFBA538A08 for <tools-discuss@ietf.org>; Thu, 1 Oct 2020 12:38:19 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WSFD5VYnE6PG for <tools-discuss@ietf.org>; Thu, 1 Oct 2020 12:38:19 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 38AA938A06 for <tools-discuss@ietf.org>; Thu, 1 Oct 2020 12:38:19 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 53233454 for <tools-discuss@ietf.org>; Thu, 1 Oct 2020 12:33:18 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "tools-discuss\@ietf.org" <tools-discuss@ietf.org>
In-Reply-To: <5a8ed7f4-b0a0-a5ab-5c81-a7af404e9d10@nostrum.com>
References: <5a8ed7f4-b0a0-a5ab-5c81-a7af404e9d10@nostrum.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Thu, 01 Oct 2020 12:33:18 -0400
Message-ID: <21861.1601569998@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/4l4AZ0GhfAXSvZvpi9bstZlRYkQ>
Subject: Re: [Tools-discuss] Proposal to discontinue live mp3 audio streams at IETF meetings
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2020 16:33:22 -0000

Robert Sparks <rjsparks@nostrum.com> wrote:
    > We propose to discontinue producing live mp3 audio streams for IETF
    > meetings, starting with IETF 109 and we want to hear from the community
    > before we do.

uhm, okay.

    > Now that we are holding more meetings online, we have a requirement to
    > allow meetings to run outside their scheduled times. Allowing the live
    > streams to run outside their scheduled times will require changing how
    > they are represented, to no longer be associated with "rooms" or
    > "tracks". The code refactor at both the datatracker and at meetecho to
    > support would not be a huge effort, but it also would not be
    > tiny. Instead, we feel that removing this complexity, recognizing that
    > the regular meetecho connection and recordings satisfy the need, is the
    > better use of our resources. That holds true even for future in-person
    > meetings.

I understand.
I would request that the mp4's that are produced and uploaded to youtube be
made available via some other site as well.

I'm okay if the site has no "player", and if it's just raw files, and I'm
okay if the bandwidth per connection is intentionally set such that I can't
stream it "live".
(That is, I'd have to start a transfer for the 1hr recording, and it may take
more than 1hr to download.  I'm not insisting that this be done, I'm
just saying that I'm okay if for reasons of cost-of-CPU-diskio-and-bandwidth
it works out that way.)

There is still a contingent that dislikes having to deal with Big Tech.
The audio recordings were publically available records that did not involve that.

I am interested in who those 10 uses in IETF108 are.
Is that one person for 10 sessions? Or 10 different users?
I can imagine that there are some people for whom a live video stream is too
bandwidth intensive.
Still, meetecho has some options to suppress video receiving I thought..

    > * Some participants (especially ADs) want to listen to more than one
    > meeting at   a time.

My record is three meetecho windows, and a lot of use the mute button my
audio mixer :-)

    > * Some participants may not have the bandwidth or a new enough computer
    > to run   meetecho.

    >     The use of the mp3 streams has been very low at the last several
    > meetings.      This population isn't using the mp3 streams to address
    > the posited     limitations.  If this is a     concern that some people
    > think they will     experience then we can look at asking Meetecho to
    > allow sending only     audio (muting all video).

I thought that we already had this.

    > * This removes a mechanism that allowed people to listen to a session
    > in   real-time without paying a registration fee.

I think that this will be the biggest hurdle.
Given how the waivers have been repositioned, perhaps this is much less of a hurdle.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide