Re: [RAI] RAI processes for handling work effectively

Hadriel Kaplan <hadriel.kaplan@oracle.com> Thu, 18 July 2013 14:59 UTC

Return-Path: <hadriel.kaplan@oracle.com>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A2521F9E52 for <rai@ietfa.amsl.com>; Thu, 18 Jul 2013 07:59:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.489
X-Spam-Level:
X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjy+B8Mecnqk for <rai@ietfa.amsl.com>; Thu, 18 Jul 2013 07:59:02 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD6021F9E44 for <rai@ietf.org>; Thu, 18 Jul 2013 07:58:15 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6IEwAOJ020974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Jul 2013 14:58:10 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6IEw92Z016584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jul 2013 14:58:09 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6IEw8ah024805; Thu, 18 Jul 2013 14:58:08 GMT
Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Jul 2013 07:58:08 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
In-Reply-To: <51E7D81A.5000008@alvestrand.no>
Date: Thu, 18 Jul 2013 10:58:07 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <E6F3929E-ABD0-40D0-AAED-95C44B258BCB@oracle.com>
References: <51C157BA.70509@ericsson.com> <51E7D81A.5000008@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: rai@ietf.org
Subject: Re: [RAI] RAI processes for handling work effectively
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jul 2013 14:59:09 -0000

In many ways you're right of course - at least for the "long-term" Working Groups.  I find that many of the newly-created ones do perform real work at the beginning, though.

But I strongly disagree with what's really driving your angst: the problems in MMUSIC with making SDP changes.

The real problem you have is you'd like to have *your* changes "rubber-stamped" quickly.  And I don't mean that in a negative way - I mean the problem is you'd like WebRTC usage for SDP to follow a faster get-to-publication process, because WebRTC has a greenfield deployment model and few vendor implementations involved and is in an early phase of life.  So you see the problem as: "we've got two vendors wanting to do X, and if X isn't broken for our needs then publish the damn thing".

But SDP isn't just WebRTC's playground to try new stuff in.  It's not even simply a client-server encoding schema.  Instead, it's a *protocol*, with a complicated multi-point offer/answer model and state.  One that's decades-old, widely-deployed, multi-usage/market, and widely-implemented by a crap-load of vendors.  Sadly, it's also used, implemented and deployed in ways that are not well documented in RFCs, but are known by the participants in MMUSIC.  Because of all that, it's arguably actually *inappropriate* to make changes to it quickly, or for specific use-cases/markets.  Having two vendors implement something and agree on it simply isn't a sufficient bar for publication to RFC, for SDP uses.

Part of that slow-change-process also has to do with what the expectations are for published RFCs.  Despite the distinctions made in RFC 2026/6410, the fact of the matter is once a document is published as an RFC, it's essentially set in stone and treated like gospel - for RFCs updating/extending mature protocols, which SDP is.  At least from the perspective of how the rest of the world treats it.  It's not like just saying: "here's version 1.0, please keep checking back for new versions which might change this thing completely".

That's one of the reasons I argued so much a couple years ago that RTCWEB/WebRTC should *NOT* use SDP for its API.  I tried to warn you guys this would happen.  It was #1 on my "reasons not to use SDP" argument list:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg01256.html

Tying WebRTC to SDP is going to hurt your ability to make changes quickly... FOREVER.

-hadriel