Re: [rtcweb] revisiting MTI

John Leslie <john@jlc.net> Mon, 15 December 2014 22:24 UTC

Return-Path: <john@jlc.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8AC1A0461 for <rtcweb@ietfa.amsl.com>; Mon, 15 Dec 2014 14:24:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level:
X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 lQx30daS02pY for <rtcweb@ietfa.amsl.com>; Mon, 15 Dec 2014 14:24:30 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 89E981A0252 for <rtcweb@ietf.org>; Mon, 15 Dec 2014 14:24:30 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id A49CFC94BD; Mon, 15 Dec 2014 17:24:27 -0500 (EST)
Date: Mon, 15 Dec 2014 17:24:27 -0500
From: John Leslie <john@jlc.net>
To: Peter Saint-Andre - &yet <peter@andyet.net>
Message-ID: <20141215222427.GO47023@verdi>
References: <CALiegfmH6hWp6nuArv8YyPcgq6SCd9x-dU0cxAaKJLrmb0hc_g@mail.gmail.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> <CALiegfkMUzQVOKk433d4TZtvenQWQwChYF2vc7HMED2s2wHZ5Q@mail.gmail.com> <B52D8E91-5D96-4960-8DDE-DD970014DE5D@ieca.com> <CALiegfnRvgDK4EnDBSn76YKktWLMjShsQRP6byCRqZC07WaVqw@mail.gmail.com> <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <548F54A5.2060105@andyet.net>
User-Agent: Mutt/1.4.1i
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WLvwMrfOUaPU4qzDiayva8P30aY
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] revisiting MTI
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Dec 2014 22:24:32 -0000

Peter Saint-Andre - &yet <peter@andyet.net> wrote:
> On 12/15/14, 12:24 PM, John Leslie wrote:
>><snip>
>>
>> But we don't obsolete a MTI because "we have much better options":
>> we obsolete a MTI because "nobody's using it anymore".
> 
> Actually we can obsolete an MTI for any reason we please, at long as 
> there's IETF consensus to do so.

   Technically, we "can"...

   In actual practice, though, as long as someone pipes up during
Last-Call saying "These folks are still using that!", we generally
back down from declaring things "Obsolete".

>> We are all trusting, I hope, that VP9, H.265, etc. will "just be
>> used in preference" as soon as two endpoints support them.
>>
>> I don't expect to revisit the MTI selection...
> 
> I do. It's a question of when.

   Well, Peter _is_ younger than me... ;^)

   But this is a sign of a pretty serious disconnect between "old-fogies"
and "young-turks" that I'd like to call attention to:

   Young-Turks want to "do it right" and have a standard ensure the
best possible outcome; old-fogies have been-there, done-that, and
gotten-the-T-shirt -- and things never ended up the way we expected.

   Old-fogies view the world as a continuum where small changes add up
to big progress over time, but too-large changes get mired and wander
in the weeds, tiring everybody and usually leave misguided folks as
the last-men-standing.

   A wise friend once told me that the true problem with democracy is
that the results are unstable: when the electorate wants a change,
the resultant changes goes too far; and walking it back to the middle
"stable-ground" takes too long.

   This is a big part of why I "just don't get the hint" when the
majority disagrees with me -- and I prize the IETF consensus-process
whenever we can get it to work. And it's why I would have been perfectly
happy with H.261 as the Mandatory-To-Implement codec.

   We cannot be effective if we have to turn around next month and say
that VP9 must replace VP8 as MTI or H.265 must replace H.264. Market
forces _really_can_ be trusted to get the better codec(s) used in
preference to whatever we designate as MTI.

>> (That is what we want, right?)
> 
> Not as far as I can see.

   I honestly believe this "compromise" is getting majority approval
because folks are _really_ tired of the MTI discussions.

   But there _are_ young-turks who believe the MTI question is _so_
important that we have to discuss it every IETF-week until we reach
consensus-by-exhaustion.

   "Are we there yet?"

--
John Leslie <john@jlc.net>