Re: [rtcweb] Video Codec Selection Plan

[Ted Hardie <[e-mail]>]

Howdy,

I've now had lunch and nice coffee, and I take electrons in hand to answer
your missive, sent earlier today.

On Fri, Sep 13, 2013 at 11:50 AM, Pete Resnick <[e-mail]>wrote:

> Big caveat as I post this: I am speaking strictly as an IETF participant.
> In particular:
>
>
<SNIP>


> All that said, I am concerned about the path being proposed, and I agree
> with Matthew's concern (though I feel somewhat less defeatist than his
> assessment sounds):
>
>
> On 9/13/13 11:59 AM, Matthew Kaufman wrote:
>
>> 2. Should I expect "room-packing" for this "show of hands" (which I don't
>> believe is the typical "hum" process for the IETF, either) as happened
>> during the SDES discussion last time, and therefore need to bring as many
>> people who've not participated in RTCWEB previously but who want my codec
>> to succeed as I can afford to fly to Vancouver?
>>
>
> I think this is a valid concern. Asking "who wants or can live with VP8?"
> and "who wants or can live with H.264?" might be a good start to the
> discussion, but at that point, I'm going to want to hear *why* people
> *can't* live with one or the other.


That discussion is supposed to happen before this, not after, so that if
there are issues which might be resolved, they can be.  During the course
of the effort to find a solution here, there have been several such
resolutions (Cisco, for example, graciously agreed to provide an open
source H.264 implementation should it be selected, in order to handle
objections that none were available).  If there are issues which cannot be
resolved, having a second discussion on what they are amounts to re-hashing
and doesn't do anything to move things forward.


> What I would *not* be interested in is yet another presentation from the
> proponents of either of these to tell me why one is better;


One might surmise that this is because you do not intend to actually build,
deploy, or operate a service that relates to this.  If someone puts forward
a codec that is better (in human assessment, lines of code, or operating
requirements) and meets the other criteria for deployment, why wouldn't you
want to hear about it?


> I want to hear from *opponents* of the proposal to hear why the proposal
> would fail.  Only then would I want to hear from proponents responding to
> those objections. And then I'd like to see a summary of those objections
> and those responses by the chairs


Pete, my dear mangel-wurzel and apple of my eye, that's the most process
wonky thing you've said in a long while, which is saying something.  The
working group is trying to identify a common codec that can be used to
avoid negotiation failure.  If there is no common video codec, the network
effect of this system is much less.
If there are people who have stated *they cannot live with this*, they are
not going to build, deploy, or operate services which use the common
codec.  The actual system we are trying to build will suffer.  Judging
consensus is not here an end in itself, it's a way of working out whether
or not the system we're building does or does not have a way to avoid the
negotiation failure.

We would not have spent the amount of time we have unless that were
important, and we would not be considering using RFC 3929 unless we thought
it was worth getting to a resolution.  I implore you to stop treating this
as an academic exercise in consensus theory, and remind yourself that we're
trying to do some engineering here.


>
> With that summary, the chairs can make a call of whether there is any hope
> of consensus. I think much of that work can and should take place on the
> mailing list *before* the face-to-face meeting.
>
>
But asking for a show of hands in the room for people who "can live with"
> one or the other and deciding whether or not consensus exists based on that
> show of hands is simply taking a vote, it's not judging consensus.


That rather presumes you know the count.  In several of our recent calls,
we have had unanimity, which is generally held to be a strong indicator of
consensus.

The last time we had a straw poll which used similar language, we also had
absolutely no question that we had not achieved consensus.

Sometimes signals are strong.


> You cannot know from that result whether the reason that some people could
> not "live with" a proposal was simply because "my Aunt Gertrude told me
> that I should say that I can't live with it." To ask for the show of hands
> and then not find out what it means is not calling the consensus. And I
> think moving to a 3929 alternative on the basis of that show of hands would
> be improper.
>
> If you re-read RFC 3929, you will discover that it requires that you make
an explicit call for its use; the consensus to use it standing in for the
consent on the technical matter.  The working group chairs have no
intention of skipping that step, should RFC 3929 be used.


> Put me down as one voice who objects to the proposed procedure.
>
>
So noted.

fondly,

Ted



> pr
>
>
>  On 9/13/2013 9:52 AM, Ted Hardie wrote:
>>
>>> WG,
>>>
>>> The chairs have created a plan for how to perform the Video Codec
>>> selection in our WG. The chairs are asking for review of our plan on
>>> how to undertake the mandatory-to-implement video codec selection.
>>> We'd much prefer to have comments on the mechanics before they begin,
>>> so please review now.  Proponents of a particular proposal should
>>> note both the actions required and the timelines proposed.
>>>
>>> The main goal of this plan is to hold a consensus call on which of
>>> the proposed alternatives we as a WG should select at one of the WG
>>> sessions in Vancouver. Such a consensus call will of course be
>>> verified on the mailing list for anyone who can't participate. The
>>> chairs will recuse themselves from judging this particular
>>> consensus.
>>>
>>> In the WG session each codec proposal will be allowed an equal amount
>>> of time to highlight the arguments for their proposal. After that a
>>> there will be a slot for discussion and clarifying questions.
>>>
>>> To enable the WG participants to get answers to any questions, the
>>> proposals in draft form and any supporting material MUST be made
>>> available by 6th of October. This is to ensure that the WG
>>> participants can verify or object to any claims or statements in
>>> the proposal material prior to the WG session. We chairs would really
>>> not like to see the proponents bring up new arguments at their
>>> presentation. Also the WG participants are expected to raise any
>>> arguments on the list ahead of time to enable the proponents to
>>> respond to such arguments.
>>>
>>> The proposed consensus questions will be of the following form:
>>>
>>> 1. If you support H.264 as the mandatory to implement codec or are
>>> willing to live with it as the MTI, please raise your hand now.
>>>
>>> 2. If you support VP8 as the mandatory to implement codec or are
>>> willing to live with it as the MTI, please raise your hand now.
>>>
>>> You may indicate support on both questions and we encourage you to do
>>> so if you can live with either, even if you have a preference for one
>>> over the other.
>>>
>>> Additional proposals than the previous ones are welcome, but must be
>>> submitted as draft and their proponents must notify the chairs no later
>>> than the 6th of October that they also have a candidate proposal.
>>>
>>> In case the WG fails to reach consensus we chairs propose that we use
>>> the alternative decision process as discussed in RFC3929. The method
>>> and its usage will be discussed on the list should the WG not
>>> establish consensus on a proposal for mandatory to implement video codec.
>>>
>>> regards,
>>>
>>> Magnus,  Cullen, and Ted
>>>
>>
> --
> Pete Resnick<http://www.qualcomm.**com/~presnick/<http://www.qualcomm.com/~presnick/>
> >
> Qualcomm Technologies, Inc. - [phone]
>
>
> ______________________________**_________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>