Re: [RAI] RAI processes for handling work effectively

[Harald Alvestrand <[e-mail]>]

On 07/18/2013 04:58 PM, Hadriel Kaplan wrote:
> 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.
Hadriel, what's driving this is a lot older than my involvement with SDP
(this round).
SDP is just my current whipping horse for a persistent, pernicious, and
prevalent problem.

>
> 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.

All of this points to a need for careful review. What it does not point
out is any need for a *slow*, *inconsistent* and *unpredictable* review
process - which is what I feel the "standing working groups" are giving
us now.

My flagship this week is the reviews of BUNDLE in MMUSIC: What I have
heard over the last six IETFs (2 years, since my August 2011 -one-rtp
draft) is advice wavering back and forth between "same port", "different
ports", "MMT", "an M-line is a channel", "an M-line is a stream", "an
M-line is a decorated 5-tuple" and variations thereof - sometimes the
same person giving opposite advice at successive IETF meetings. Every
time, new information comes up at meetings.

In between, the list discusses clock rates, RTSP, alt-ports, loopback,
and a ton of other stuff that *I* don't care much about, bu the people
discussing them certainly do.

With BUNDLE, Christer has been doing yeoman's work to sort through the
issues and figure out what matters, what doesn't, and what we just have
to live with - but it should not be *this* hard.

It's possible that the problem could be solved by a different management
style, without changing the current formal structure. But I doubt it;
I've seen this in too many contexts.
>
> 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 may be a reason why we need to publish more bad ideas as RFCs :-)

One of our fairy tale stories that we tell ourselves is that our
protocols are tools, can be adopted into different contexts, and
profiled appropriately for that context.


>
> 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.

At this time, I can't say that you're wrong.

But it is an orthogonal issue to my opinion that standing working groups
Just Don't Work.

Harald