Re: Proposed Charter Changes

I understand where you are coming from, but it would be good to have an
example of something specific that we don't want to have to support in the
future.

SDP munging is a clumsy API surface, but I am not sure it imposes any
additional constraints on the lower layers.

On Wed, Apr 29, 2015 at 9:41 AM, Michael Champion (MS OPEN TECH) <
Michael.Champion@microsoft.com> wrote:

>   Justin wrote:
>
>  > As mentioned yesterday, I think we have a better idea now of what 1.1
> is going to be than what 1.0 was
>  > going to be when we started 1.0. IOW, I don't think you can really
> argue that we are signing a blank check here.
>
>  So what language might be appropriate in a 1.0 charter to put some
> discussion of 1.1 in scope?    I think everyone supports the goal of a
> smooth transition for app developers, especially if they can re-use the
> high level APIs unchanged in many scenarios.  Or as you put it in another
> message, if the constraint is "PeerConnection can be implemented atop the
> 1.1 objects” I suspect everyone could live with that.   But as Tim Panton
> notes in this thread “The reality of the current API is that everyone has
> to mess with the SDP to get what they want, and frankly there is nothing
> lower level than regexps on SDP.” That’s not a “compatibility" we want to
> inflict on posterity!
>
>
>   From: Justin Uberti
> Date: Wednesday, April 29, 2015 at 9:12 AM
> To: Michael Champion
> Cc: "public-webrtc@w3.org"
> Subject: Re: Proposed Charter Changes
>
>
>
> On Tue, Apr 28, 2015 at 10:24 PM, Michael Champion (MS OPEN TECH) <
> Michael.Champion@microsoft.com> wrote:
>
>>  Cullen Jennings <fluffy@cisco.com
>> <fluffy@cisco.com?Subject=Re%3A%20Proposed%20Charter%20Changes&In-Reply-To=%3CAF740A35-9FB8-4F56-A0BB-A4864880BC8E%40cisco.com%3E&References=%3CAF740A35-9FB8-4F56-A0BB-A4864880BC8E%40cisco.com%3E>>
>> wrote:
>> > I put a diff at
>> > https://github.com/fluffy/webrtc-charter/compare/gh-pages...fluffy:ekr
>>
>>   That appears to compare EKR’s proposal with the original charter that
>> triggered formal objections.  Comparing Dom’s revised  charter proposal
>> which addresses the objections in
>> https://lists.w3.org/Archives/Public/public-webrtc/2015Mar/att-0046/webrtc-charter.html to
>> EKRs in https://github.com/ekr/webrtc-charter/tree/ekr_revision  I see a
>> number of significant changes.  EKR’s proposal:
>>
>>
>>
>> - Adds a 3rd year to the lifetime of the WG, saying that once 1.0 is
>> stable, “the group will reevaluate its deliverables and milestones, and may
>> reconsider its scope.”
>>
>> - Adds language to the Deliverables section constraining future versions
>> of the WebRTC spec to be backward compatible with 1.0
>>
>> - Drops the formal liaison with the ORTC Community Group
>>
>> - Drops language from the Decision Policy section saying that editors are
>> responsible for reflecting the consensus in the WG and that those sections
>> that haven’t been reviewed by the WG should visibly reflect that fact
>>
>>
>>  These changes are not likely to build bridges between the RTC
>> communities, and are problematic for a number of reasons.  In particular
>> the idea that a WG “may reconsider its scope” without going through a
>> formal chartering process is incompatible with the W3C process and patent
>> policy.  The scope statement is a key part of the WG’s “contract” with the
>> AC and what drives members IPR commitments when they join a WG.  If we have
>> to go thru another rechartering exercise to put 1.1/NG deliverables in
>> scope, let’s have that discussion when we have stable specs and real
>> world experience to discuss, not pencil it in now and change it later.
>>
>>
>>
>> I strongly object to changing the Decision Policy section in Dom’s draft,
>> which was negotiated as a way around the 2 formal objections. If there are
>> substantive objections to the proposed decision policy, let’s discuss.
>>
>>
>>
>> On the ORTC liaison,the CG is a group with many of the same members as
>> the WebRTC WG, and implementation experience with ORTC is exposing many
>> questions about the underlying IETF specs and protocols that affect 1.0 as
>> well.  No one is asking for joint decision making or a veto power, and it
>> seems to be in the WebRTC WG’s best interest to maintain open and
>> respectful communications with the ORTC CG.
>>
>
>  This proposal from Eric was an attempt to sketch out the general idea of
> what a 1.1 charter would look like, not to nail down all the details. It's
> good to raise these points but I think most of them are just oversights.
>
>>
>>
>> On constraining a future WebRTC standard to be backward compatible with
>> 1.0, that seems reasonable in principle and Justin has sketched out an
>> approach to keeping apps built for 1.0 working on in a future version. BUT
>> there is a very big devil in the details: There is no stable version of 1.0
>> yet, so it’s essentially signing a “blank check”, promising to support
>> whatever the WG eventually fills in, irrespective of how it works in the
>> real world.
>>
>
>  As mentioned yesterday, I think we have a better idea now of what 1.1 is
> going to be than what 1.0 was going to be when we started 1.0. IOW, I don't
> think you can really argue that we are signing a blank check here.
>
>>
>>
>> The way forward Dom’s charter sketches out seems less confrontational:
>> The WG focuses on getting 1.0 stabilized, the ORTC CG works to see if it’s
>> ideas actually work for implementers and app developers. When 1.0 gets to
>> CR we all look at the evidence of what works, what else is needed, and
>> figure out a 1.1/NG charter that everyone can sign up to.  I don’t
>> particularly care whether the current WG charter is extended or Dom’s
>> charter approved, but it’s premature to draft a 1.1 charter while 1.0 is in
>> flux and ORTC is still learning from  implementation experience.  For those
>> who disagree, let's start with Dom’s draft and see if there are tweaks
>> to satisfy both those who want to have NG work in scope, and those who want
>> to see the WG prove it can build  consensus on a 1.0 spec before claiming
>> ownership of  the next generation.
>>
>>
>>
>
>
>
>
>