Re: [RAI] RAI processes for handling work effectively

[Hadriel Kaplan <[e-mail]>]

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