[rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs)

[Adam Roach <[e-mail]>]

This thread has been going on for quite some time now, and I wouldn't be 
surprised if there is some pressure for the chairs to call consensus in 
the next week or two.

I know it's tempting to think they might simply grab the relevant 
messages and tally the support for each position, calling the issue for 
those with the larger number of proponents. In short, simple majority 
voting. Many bodies work this way -- governments, corporations, and 
other SDOs, just to name a few.

We don't.

As Dave Crocker[1] is fond of pointing out, it is possible to have 99 
people in support of a position and one standing against, and still fail 
to meet the IETF's standard for "rough consensus." All it takes is the 
failure of those 99 people to engage the arguments put forth by the one 
outlier. Correspondingly, you can have 50 people on one side of an 
issue, 50 on the other, and still have a clear consensus if one side is 
merely stating a position, while the other is offering up unanswered 
arguments.

To be clear, I'm not saying that "+1" is never a valid response when 
attempting to reach consensus. However, it does not, in and of itself, 
comprise a counter-argument to points raised by supporters of the 
opposing position.

To the issue at hand: roughly grouping those proponents of option 1 into 
one voice (A), and those boosting option 2 in to another (B), the 
conversation so far can be roughly summarized as:

A: We'd like to see SHOULD-level support for codecs x, y, and/or z 
because gee, wouldn't it be nice?
B: "Wouldn't it be nice" doesn't meet the criteria for RFC 2119 SHOULD.
A: *crickets*

[time passes]

A: We'd like to see SHOULD-level support for codecs x, y, and/or z 
because gee, wouldn't it be nice?
B: "Wouldn't it be nice" doesn't meet the criteria for RFC 2119 SHOULD.
A: *crickets*

That's the _exact_ kind of failure to engage that I would expect would 
cause experienced chairs to call clear consensus for supporters of option 2.

This isn't a vote, it's a discussion, and discussions need to go beyond 
blindly repeating your opening arguments. If you have any interest in 
option 1 being considered further, you need to listen and respond to the 
opposing position.

/a


[1] For those of you unfamiliar with Dave Crocker's tenure in the IETF, 
I call your attention to the date and attendee list on the following 
proceedings: http://www.ietf.org/proceedings/04.pdf


On 1/14/13 02:21, [e-mail] wrote:
> I also support Stephane's proposal.
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: [e-mail] [mailto:[e-mail]]
>> Im Auftrag von Shida Schubert
>> Gesendet: Sonntag, 13. Januar 2013 22:35
>> An: Paul Coverdale
>> Cc: [e-mail]
>> Betreff: Re: [rtcweb] Call for Consensus Regarding Selecting
>> Recommended Audio Codecs
>>
>>
>> +1
>>
>> On Jan 11, 2013, at 5:56 AM, Paul Coverdale wrote:
>>
>>> I support Stephane's proposal for option 1. It makes good sense,
>>> particularly for the case where AMR and AMR-WB are already
>> implemented
>>> in mobile devices - there are no additional licensing issues and it
>>> simplifies interoperability.
>>>
>>> ...Paul
>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of [e-mail]
>>>> Sent: Friday, January 11, 2013 7:33 AM
>>>> To: Magnus Westerlund; [e-mail]
>>>> Subject: Re: [rtcweb] Call for Consensus Regarding Selecting
>>>> Recommended Audio Codecs
>>>>
>>>> It is clear from the discussions on the rtcweb e-mail
>> reflector that
>>>> the only additional codecs to be considered are limited to the
>>>> following very small subset of 3 codecs: AMR, AMR-WB and G.722.
>>>> In addition to G.711, these 3 codecs cover almost all
>> legacy devices
>>>> dedicated to voice services. They are consequently needed and
>>>> sufficient to be supported by WebRTC to make it an attractive and
>>>> future proof technology for usage in all environments including
>>>> mobile and for interoperability use cases with most of all
>> legacy voice terminals.
>>>> AMR and AMR-WB are indeed the most widely supported voice
>> codecs in
>>>> hundreds of millions of legacy mobile devices.
>>>> G.722 is royalty free (including a Packet Loss Concealment
>> solution
>>>> provided in ITU-T Software Tool Library) and is the codec
>> used for HD
>>>> Voice / DECT-Cat IQ fixed devices
>>>>
>>>> Furthermore, considering that the reason for excluding AMR
>> and AMR-WB
>>>> from WebRTC was the licensing issue, there is no reason to NOT
>>>> support AMR-WB and AMR at WebRTC level if these codecs are already
>>>> implemented on the device.
>>>>
>>>> Therefore I support option 1 and propose the following
>> specification
>>>> according this:
>>>> AMR-WB, AMR and G.722 are RECOMMENDED TO IMPLEMENT by WebRTC
>>>> end-points AMR and AMR-WB MUST BE supported at WebRTC
>> level by WebRTC
>>>> end-points on 3GPP mobile devices already implementing AMR
>> and AMR-WB
>>>> (*)
>>>>
>>>> (*) note that the way these codecs are supported at RTC
>> Web level is
>>>> left open to implementors: either by a WebRTC specific software
>>>> implementation of these codecs or by using APIs to access hardward
>>>> implementation.
>>>>
>>>>
>>>> -----Message d'origine-----
>>>> De : [e-mail]
>> [mailto:[e-mail]] De la
>>>> part de Magnus Westerlund Envoyé : jeudi 20 décembre 2012 09:30 À :
>>>> [e-mail] Objet : [rtcweb] Call for Consensus Regarding
>>>> Selecting Recommended Audio Codecs
>>>>
>>>> WG,
>>>>
>>>> As an outcome of the Vancouver IETF meeting codec
>> discussions we did
>>>> promise to run a call for consensus regarding if the WG was
>>>> interested in specifying a small set of recommended audio
>> codecs. We
>>>> are sorry this has been delayed until now.
>>>>
>>>> The question for the call of consensus is between two options.
>>>>
>>>> 1) Run a process in the WG to select and specify a small set of
>>>> audio/speech codecs that would be RECOMMNEDED to implement by a
>>>> WebRTC end-points
>>>>
>>>> 2) Do nothing and let the already specified Mandatory to Implement
>>>> Audio codecs be the only audio codecs mentioned in the
>> WebRTC specification.
>>>> Please indicate your position by January 16th 2013.
>>>>
>>>> Regards
>>>>
>>>> Magnus Westerlund
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> - Multimedia Technologies, Ericsson Research EAB/TVM
>>>>
>> ----------------------------------------------------------------------
>>>> Ericsson AB                | Phone  [phone]
>>>> Färögatan 6                | Mobile [phone]
>>>> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
>>>>
>> ---------------------------------------------------------------------
>>>> -
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>>
>> _____________________________________________________________________
>>>> ___ _________________________________________________
>>>>
>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas
>> etre diffuses,
>>>> exploites ou copies sans autorisation. Si vous avez recu
>> ce message
>>>> par erreur, veuillez le signaler a l'expediteur et le
>> detruire ainsi
>>>> que les pieces jointes. Les messages electroniques etant
>> susceptibles
>>>> d'alteration, France Telecom - Orange decline toute
>> responsabilite si
>>>> ce message a ete altere, deforme ou falsifie. Merci.
>>>>
>>>> This message and its attachments may contain confidential or
>>>> privileged information that may be protected by law; they
>> should not
>>>> be distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender
>>>> and delete this message and its attachments.
>>>> As emails may be altered, France Telecom - Orange is not
>> liable for
>>>> messages that have been modified, changed or falsified.
>>>> Thank you.
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb