Re: New functionality in PR - priority

On Fri, May 22, 2015 at 9:13 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

>  On 05/22/2015 05:34 PM, Eric Rescorla wrote:
>
> I'm having a little trouble squaring this with my understanding of the
> proposed decision policy. Isn't this a situation where "editors bring
> technical solutions in the specifications that have not been reviewed by
> the group"?
>
>
> It is a case where a contributor brings a technical solution to the
> attention of the editors, and asks for its inclusion.
>
> The reason for my mail was to bring it to the attention of the group.
>

Well, my point here is that Michael seemed concerned that people believed 'that
the WebRTC editors had been operating in the “defining specs on their own
unless someone complains” mode. ' And that seems to require more than just
bringing it to the attention of the group and actual determination of
consensus. So that's precisely the procedural question I am trying to
understand.



>
>  With this as an example, can someone explain to me what they believe the
> procedure for integrating a PR like this into the spec is supposed to be?
>
>
> The chairs determine whether the PR represents one of:
>
> - Previously established group consensus (say, from a discussion at a
> previous meeting)
> - Editorial changes that don't change anything that anyone cares much about
> - A contribution that has a significant change where it is not certain
> that it represents group consensus.
>
> If the third condition exists, the chairs (or the contributors) need to
> bring it to the attention of the mailing list to see whether it's in
> alignment with the consensus or not; this is why I sent the mail.
>
> If the chairs determine that group consensus supports its inclusion, we
> will ask the editors to merge it.
>
> If we determine that the group consensus does not support its inclusion,
> we won't; based on group discussion, we will ask for changes to the
> contribution, ask for a contribution that reflects an alternate approach,
> or refuse the contribution.
>
> Doesn't seem much different from what we have been doing.
>

I don't have a problem with any of this, but then I'm lost about how it
fits into
"these solutions are annotated to reflect their status."

Thanks,
-Ekr


>
>
>
>  -Ekr
>
>  On Fri, May 22, 2015 at 5:52 AM, Harald Alvestrand <harald@alvestrand.no>
> wrote:
>
>> Hi,
>>
>> just a heads-up (or something like that):
>>
>> There's a pull request in the queue for adding a "priority" field to
>> RTPSender and to DataChannels:
>>
>> https://github.com/w3c/webrtc-pc/pull/228
>>
>> This is to support the priority mechanism specified here:
>>
>> draft-ietf-rtcweb-transport section 4
>> draft-ietf-rtcweb-rtp-usage section 12.1.3
>> draft-ietf-tsvwg-rtcweb-qos
>>
>> I don't think there's anything controversial in it, but it's nice that
>> the WG is aware of what's happening when we add new functionality into
>> the spec (even when it's been talked about for a long time).
>>
>> Harald
>>
>>
>
>
> --
> Surveillance is pervasive. Go Dark.
>
>