Subject: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge?

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 Nov 2013 15:19:53 +0100

Hi,

I would like to draw your attention to the following two alternative:

10. All entities SHOULD support both H.264 and VP8. All entities MUST
    at least implement one of those. Entities that do not support both
    H.264 and VP8 MUST implement H.261.

11. MUST implement at least two of {VP8, H.264 CBP, H.263}

I would note that 10 and 11 are equivalent on the MUST level. The only
thing that separates 10 out is the SHOULD implement both H.264 and VP8.

Thus my question to the WG and especially the ones proposing 10 and 11.
Would anyone disagree with removing alternative 10. in favor of 11.?

Just trying to avoid having two alternatives that are extremely close to
each other. My thinking is that if we manage to select any MTI, i.e.
MUST statements, we can discuss what SHOULDs and RECOMMENDATIONs that we
want to make in addition.

Cheers

Magnus Westerlund
(As WG chair)

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 25 Nov 2013 15:29:49 +0100

>thing that separates 10 out is the SHOULD implement both H.264 and VP8.

No, 10 has H.261 as a MUST in a certain circumstance, 11 does not.

>want to make in addition.

If the Working Group decides to conduct a vote on this matter, I think
questions about "SHOULD"-level requirements should be left out of it.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Leon Geyser <[email-masked]>
Date: Mon, 25 Nov 2013 16:30:10 +0200

Hi Magnus,

Was H.263 a typo?
I agree that 10 can be changed to:
10. MUST implement at least two of {VP8, H.264 CBP, H.261}

On 25 November 2013 16:19, Magnus Westerlund <[email-masked]
> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Nov 2013 14:30:49 +0000

Hi,

I guess it's a spelling error, but based on your text below another thing that separates 10 and 11 is that 10 talks about H.261 while 11 talks about H.263.

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: 25. marraskuuta 2013 16:20
To: [email-masked]
Subject: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge?

Hi,

I would note that 10 and 11 are equivalent on the MUST level. The only thing that separates 10 out is the SHOULD implement both H.264 and VP8.

Just trying to avoid having two alternatives that are extremely close to each other. My thinking is that if we manage to select any MTI, i.e.
MUST statements, we can discuss what SHOULDs and RECOMMENDATIONs that we want to make in addition.

Cheers

Magnus Westerlund
(As WG chair)

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 Nov 2013 15:43:19 +0100

> 10. MUST implement at least two of {VP8, H.264 CBP, H.261}

Sorry,

I did a mistake in this call. I missed that 10 and 11 talked about H.261
and H.263 respectively.

I think the above question of writing 10 in the above proposed format is
then the relevant question to the WG.

Cheers

Magnus

> 
> 
> 
> On 25 November 2013 16:19, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>     Hi,
> 
>     <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 

Magnus Westerlund

---

From: John Leslie <[email-masked]>
Date: Mon, 25 Nov 2013 14:22:03 -0500

Magnus Westerlund <[email-masked]> wrote:
>>... 

   To me, that wording is void for vagueness... Per

http://en.wikipedia.org/wiki/CPB
] 
] CPB may refer to:
] Companies[edit]
] 
] Campbell Soup Company, stock symbol CPB
] Campbell Brothers, an Australian laboratory and manufacturing company
] Crispin Porter + Bogusky, an advertising agency
] Corporate Express (airline), a defunct Canadian airline
] Organizations[edit]
] 
] The Corporation for Public Broadcasting, a publicly funded non-profit corporation in the United States
] The CPB (Netherlands), a government agency in the Netherlands
] The Crown Property Bureau, a quasi-government agency in Thailand
] The École nationale supérieure de chimie et de physique de Bordeaux, one of the French grandes écoles
] Political parties[edit]
] 
] Communist Party of Bangladesh
] Communist Party of Britain
] Communist Party of Burma
] Technology[edit]
] 
] Cardiopulmonary bypass, also known as a "heart-lung machine"
] Charged particle beam of electrically charged particles
] CREB-binding protein, a transcription coregulator
] Cycles per byte, a unit of measurement related to microprocessors
] Coded Picture Buffer, a buffer for encoded video frames used in video decoding
] Other[edit]
] 
] The Citizens Protection Bureau, a fictional police organization in the Total Recall 2070 television series
] Camilla Parker Bowles
] Central Planning Board, term used in market socialism theory
] Crippled Black Phoenix, a British post-rock supergroup

   (10) as it stands is quite clear: I don't think it deserves to be changed
at all.

   (And if we are to start changing entries, what is the process? Does
someone call consensus for the change?)

--
John Leslie <[email-masked]>

---

From: <[email-masked]>
Date: Mon, 25 Nov 2013 19:51:41 +0000

Hi,

[email-masked] wrote:
> I did a mistake in this call. I missed that 10 and 11 talked about H.261 and
> H.263 respectively.
> 
> I think the above question of writing 10 in the above proposed format is then
> the relevant question to the WG.
> 

I agree that alternatives 10. and 11. are better to be written in the same format:

10. MUST implement at least two of {VP8, H.264 CBP, H.261}
11. MUST implement at least two of {VP8, H.264, H.263}

I assume H.264 CBP = Constrained Baseline Profile as proposed in draft-burman-rtcweb-h264-proposal.

For H.263 we would need to define if it means H.263 Baseline or something beyond that. I have seen at least Stephan Wenger arguing that H.263 Baseline is not suitable for WebRTC. 

Markus

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Tue, 26 Nov 2013 02:16:27 +0000

Hi

>From: rtcweb [mailto:[email-masked]] On Behalf Of
>[email-masked]
>Sent: Tuesday, November 26, 2013 3:52 AM
>To: [email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge?
>
>Hi,
>

[Xin]I forget who proposed 10 first, but there are differences between new 10 and origin 10. 
In origin 10, H.261 has little chance be implemented. I don't think it is possible that one browser do not implement both H.264 and vp8, but implement H.261. even it is possible, only implement H.261 will not be helpful for interoperation. 
In alternatives 10, H.261 has much more possible be used, which is designed for interoperation purpose. 

So I agree to change alternatives 10. to

>For H.263 we would need to define if it means H.263 Baseline or something
>beyond that. I have seen at least Stephan Wenger arguing that H.263 Baseline is
>not suitable for WebRTC.

[xin]It is good we could get consensus on H.263 profile before the voting, which will be a argument if we miss it now.

---

From: cowwoc <[email-masked]>
Date: Tue, 26 Nov 2013 03:13:07 -0500

On 25/11/2013 9:16 PM, Chenxin (Xin) wrote:
> [Xin]I forget who proposed 10 first, but there are differences between 
> new 10 and origin 10. In origin 10, H.261 has little chance be 
> implemented. I don't think it is possible that one browser do not 
> implement both H.264 and vp8, but implement H.261. even it is 
> possible, only implement H.261 will not be helpful for interoperation. 
> In alternatives 10, H.261 has much more possible be used, which is 
> designed for interoperation purpose. So I agree to change alternatives 
> 10. to 10. MUST implement at least two of {VP8, H.264 CBP, H.261}

You're missing the point of MTI. If H.261 is MTI, nothing prevents you 
from supporting VP8 and H.264 anyway. It is possible for mobile 
applications that interact with web clients to only need 
lower-resolution videos (think: accessibility applications). It is quite 
reasonable for them to only implement H.261 and no one will be harmed 
because specialized applications are not meant to act as generic web 
browsers.

Gili

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 27 Nov 2013 09:50:59 +0100

On 2013-11-25 20:51, [email-masked] wrote:
> MUST implement at least two of {VP8, H.264 CBP, H.261}

I have now updated the list to read:

10. All entities MUST implement at least two of {VP8, H.264 CBP, H.261}
11. All entities MUST implement at least two of {VP8, H.264 CBP, H.263}

Cheers

Magnus Westerlund

---

From: Thomas Reisinger <[email-masked]>
Date: Wed, 27 Nov 2013 14:16:57 +0100

Magnus,

Could you please share the latest list and how the voting will be conducted/what's required to vote.

Cheers,

Thomas Reisinger

> On 27.11.2013, at 09:50, Magnus Westerlund <[email-masked]> wrote:
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 27 Nov 2013 14:43:52 +0100

> Could you please share the latest list and how the voting will be conducted/what's required to vote.

For the proposed voting process see our previous message
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html

As I stated, we chairs will need to update this based on the discussion.

For the current list of alternatives is on the WG's wiki:
http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart

Reproduced here:
 The following alternatives has been proposed:

 1. All entities MUST support H.264
 2. All entities MUST support VP8
 3. All entities MUST support both H.264 and VP8
 4. Browsers MUST support both H.264 and VP8, other entities MUST
    support at least one of H.264 and VP8
 5. All entities MUST support at least one of H.264 and VP8
 6. All entities MUST support H.261
 7. There is no MTI video codec
 8. 5+6, i.e. All entities MUST support H.261 and all entities MUST
    support at least one of H.264 and VP8
 9. All entities MUST support Theora
10. All entities MUST implement at least two of {VP8, H.264, H.261}
11. All entities MUST implement at least two of {VP8, H.264, H.263}
12. All entities MUST support decoding using both H.264 and VP8, and
    MUST support encoding using at least one of H.264 or VP8

H.264 is a reference to the proposal in ​
https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/

VP8 is a reference to the proposal in ​
https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/

-- 

Magnus Westerlund

---

From: Leon Geyser <[email-masked]>
Date: Wed, 27 Nov 2013 17:21:45 +0200

Why don't we keep CBP on each H.264 entry? It will be more clear for the
voter for what they are actually voting for,

My opinions on some of the options:
Personally I feel there are too many options :)
1 and 2: Was already debated so I don't know why we should list them again.
3: Might be too difficult to follow resulting in people breaking the spec
anyway.
5: Actually implies 7.
7: Fail
8: I know I suggested this one, but 10 is actually nearly the same and is a
better option. Votes might get split between the two resulting in another
option taking lead. Is my thinking wrong?
11: Is H.263 really safe?
12: Do we know if you only implement a decoder that royalties won't apply?

On 27 November 2013 15:43, Magnus Westerlund <[email-masked]

> H.264 is a reference to the proposal in 
> VP8 is a reference to the proposal in

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 27 Nov 2013 16:30:53 +0100

> voter for what they are actually voting for,

Because, the H.264 proposal draft defines it to be CBP, and no one to my
understanding has made another proposal. Thus, I think a general
clarification through the reference is clearer.

/Magnus

> 3: Might be too difficult to follow resulting in people breaking the
> spec anyway.
> 5: Actually implies 7.
> 7: Fail
> 8: I know I suggested this one, but 10 is actually nearly the same and
> is a better option. Votes might get split between the two resulting in
> another option taking lead. Is my thinking wrong?
> On 27 November 2013 15:43, Magnus Westerlund
>     >> On 27.11.2013, at 09:50, Magnus Westerlund
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>
>     >>> On 2013-11-25 20:51, [email-masked]
>     <mailto:[email-masked]> wrote:
>     >> SE-164 80 Stockholm, Sweden| mailto:
>     [email-masked] <mailto:[email-masked]>
>     >>
>     <tel:%2B46%2010%207148287>
>     <tel:%2B46%2073%200949079>

-- 

Magnus Westerlund

---

From: "Mishra, Sanjay" <[email-masked]>
Date: Wed, 27 Nov 2013 11:33:41 -0500

Magnus -- To confirm, the voting period is be two weeks, so I am assuming starting tomorrow (Nov 28) and lasting for two weeks (Dec 12?).

Thanks
Sanjay
-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Wednesday, November 27, 2013 8:44 AM
To: Thomas Reisinger
Cc: [email-masked]
Subject: Re: [rtcweb] Video Codec Selection Alternatives 10 and 11: Merge?

> Could you please share the latest list and how the voting will be conducted/what's required to vote.

For the proposed voting process see our previous message http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html

Reproduced here:

 1. All entities MUST support H.264
 2. All entities MUST support VP8
 3. All entities MUST support both H.264 and VP8  4. Browsers MUST support both H.264 and VP8, other entities MUST
    support at least one of H.264 and VP8  5. All entities MUST support at least one of H.264 and VP8  6. All entities MUST support H.261  7. There is no MTI video codec  8. 5+6, i.e. All entities MUST support H.261 and all entities MUST
    support at least one of H.264 and VP8  9. All entities MUST support Theora 10. All entities MUST implement at least two of {VP8, H.264, H.261} 11. All entities MUST implement at least two of {VP8, H.264, H.263} 12. All entities MUST support decoding using both H.264 and VP8, and
    MUST support encoding using at least one of H.264 or VP8

H.264 is a reference to the proposal in ​ https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/

>> 10. All entities MUST implement at least two of {VP8, H.264 CBP, 
>> H.261} 11. All entities MUST implement at least two of {VP8, H.264 
>> CBP, H.263}
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ---------------------------------------------------------------------
>> - Multimedia Technologies, Ericsson Research EAB/TVM

-- 

Magnus Westerlund

---

From: Derek Pang <[email-masked]>
Date: Wed, 27 Nov 2013 09:53:24 -0800

Also, is there information on the voting process and instruction ?

On Wed, Nov 27, 2013 at 8:33 AM, Mishra, Sanjay
<[email-masked]>wrote:

> Magnus -- To confirm, the voting period is be two weeks, so I am assuming
> starting tomorrow (Nov 28) and lasting for two weeks (Dec 12?).
>
> Thanks
> Sanjay
>     support at least one of H.264 and VP8  5. All entities MUST support at
> least one of H.264 and VP8  6. All entities MUST support H.261  7. There is
> no MTI video codec  8. 5+6, i.e. All entities MUST support H.261 and all
> entities MUST
>     support at least one of H.264 and VP8  9. All entities MUST support
> Theora 10. All entities MUST implement at least two of {VP8, H.264, H.261}
> 11. All entities MUST implement at least two of {VP8, H.264, H.263} 12. All
> entities MUST support decoding using both H.264 and VP8, and
> >> -

---

From: John Leslie <[email-masked]>
Date: Wed, 27 Nov 2013 12:54:14 -0500

> As I stated, we chairs will need to update this based on the discussion.

   I gather the WGCs intend to update that tomorrow.

   While I would _much_ prefer not to mix discussion of the process
with discussion of the alternatives, there are some really serious
problems with this proposal.

   First:
] 
] The method we propose is based on Instant-runoff voting,
] http://en.wikipedia.org/wiki/Instant-runoff_voting, with the
] understanding that the choice will be the winner according to the
] Instant-runoff voting process.

   Fail!

   A reference to wikipedia is completely unstable unless it refers
to the webpage retrieved at a particular time.

   It is the _intent_ of Wikipedia that the webpage may be modified
at any time by any person: thus people retrieving the page on
different days may receive different text. Those differences may be
obvious or they may be subtle.

   Second:
] 
] 2) Establish those eligible to vote.

   What follows doesn't do that. It instead establishes rules for
determining at some later time _whether_ an individual is eligible.

] Any participant in the working group process either electronically
] or in-person as of yesterday (20th of November).

   (That's where Magnus broke the sentence. Don't blame me...)

   I merely raise the question of whether the process Magnus outlined
is likely to match that goal.

] Who has participated in the Working group process will be anyone
] that can be identified from:
] - The Blue Sheets for any RTCWEB WG session during an IETF meeting or
]   an interim meeting since the WG's creation.
] - posting of at least one email to the RTCWEB mailing list

   Obviously missing from this list is persons subscribed to the
mailing-list during some period. Those would ordinarily be considered
participants.

] The voter must at time of voting prove their eligibility, by pointing
] to the mail archive or a particular blue sheet/meeting. Please verify
] your own eligibility.

   "Voter" is vague here. I take it to mean any person sending a ballot.

   Thus there is no way of challenging a right to vote before the
ballot itself is opened. I believe that is unheard-of.

   It is, IMHO, strange to have no list of eligible voters to enable
challenging eligibility (or absence from the list) before a vote is
cast.

] 3) Start the the voting period. Those eligible and willing to vote send
] their ballot to a vote collector (Matt Lepinski, former Nomcom chair)
] within two weeks using email. The vote collector will check when
] receiving a ballot the that the voter is eligible and send a
] confirmation email on receiving the ballot. During the balloting period
] the vote collector will keep all ballots secret.

   (Just to prove I'm not leaving anything out.)

] Balloting:
] - The voter MUST rank ALL alternatives in their ballot from the most
]   preferred, marked with rank 1, the second most with 2, all the way
]   to the least preferred marked with rank N.

   This is very unusual in Instant Runoff. There are always choices
that a voter would vote _against_ regardless of the alternatives.
This requires that a voter may be counted as in favor of something
s/he completely opposes.

   (Further, it leaves open the "or else" question: what happens if
a ballot doesn't exactly match that requirement?)

] 4) When the voting period is over the ballot collector will publish the
] results as well as all ballots, including the voters name to the RTCWEB
] WG mailing list. This enables all voting individuals to verify that
] their ballot is unmodified. And allows anyone to verify the result of
] the vote.

   Thus every detail of preference becomes public. Inevitably there will
be some persons who are nervous about publishing so much detail. (I
don't mean to imply that employers _would_ punish employees, merely
that employees could understandably be nervous.)

] 5) The selection is recorded in the drafts.

   Even when we get that wikipedia page "retrieved at a particular time,"
it will contain half a dozen different rules for how the counting
proceeds. I strongly recommend extracting the actual rules the WGCs
intend to follow on this list (which will be archival).

   Further, some person needs to be designated to interpret the rules
during counting.

====

   There are many other things I could mention from the email quoted;
but I think it would only detract from the discussion to do so.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Nov 2013 10:02:14 -0800

> Also, is there information on the voting process and instruction ?

https://www.ietf.org/tao.html#rfc.section.2  ... um,
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html

---

From: tim panton <[email-masked]>
Date: Wed, 27 Nov 2013 18:02:25 +0000

> problems with this proposal.

In the spirit of sheer mischief, I’d like to propose that individuals who
work for organisations that would directly profit from the gathering of license fees
should be requested to recuse themselves from the votes involving those fees, due to conflict of interest.

- This is the norm in voting for local government here in the UK.

Whilst I’m not entirely serious, I am raising this to indicate what happens when you start
to make up process on the fly.

Tim.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 27 Nov 2013 13:13:35 -0500

I am not sure about the rest of the group but from my point of view the
proposed process clearly shows that IETF in general and this group in
particular is not equipped to vote. I also strongly disagree that voting
would produce a MTI video codec decision which would meaningful in any way.
We need a way to find consensus regarding the MTI or drop the whole MTI
idea (which would also require consensus).
_____________
Roman Shpount

---

From: Ron <[email-masked]>
Date: Thu, 28 Nov 2013 05:08:03 +1030

On Wed, Nov 27, 2013 at 06:02:25PM +0000, tim panton wrote:
> work for organisations that would directly profit from the gathering of
> license fees should be requested to recuse themselves from the votes
> involving those fees, due to conflict of interest.
> 
> Whilst I’m not entirely serious, I am raising this to indicate what
> happens when you start to make up process on the fly.

Clearly we need an electoral collage to vote on whose vote counts
as a vote.
    ___
   /. .\
 m---U---m

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 27 Nov 2013 18:38:09 +0000

Sanjay, the first step will be to ask if there is consensus to use the process. Right now we have been collecting comments on the process then Magnus will send out a revised process and a consensus call to use that process. I'd expect that consensus call to and revised process to go out tomorrow at the earliest and possibly a bit later. That consensus call would last roughly 2 weeks. If there is consensus to use that process then the voting period would start and be at least a few weeks long but adjusted to be longer if it ran over a significant holiday.

---

From: cowwoc <[email-masked]>
Date: Wed, 27 Nov 2013 14:07:53 -0500

If you could come up with an alternative that works, great. The only 
reason we are voting is because all other options have failed.

It is my understanding that we have the following options (from best to 
worst):

 1. Come up with a better mechanism for establishing MTI, or
 2. Vote for MTI, or
 3. Give up and declare No MTI

Gili

On 27/11/2013 1:13 PM, Roman Shpount wrote:
>
> I am not sure about the rest of the group but from my point of view 
> the proposed process clearly shows that IETF in general and this group 
> in particular is not equipped to vote. I also strongly disagree that 
> voting would produce a MTI video codec decision which would meaningful 
> in any way. We need a way to find consensus regarding the MTI or drop 
> the whole MTI idea (which would also require consensus).
> _____________
> Roman Shpount
>
>
>

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Wed, 27 Nov 2013 20:30:51 +0000

On the process:

Could we try to reach a consensus by involving a multiple steps process?
Could we structure the MTI question into three questions, with consensus being declared on one before moving onto the next?
This way the question is structured as to find the last point at which a consensus can be achieved.

This would look like:

First step: determine the consensus for an MTI or not:
7. There is no MTI video codec

Step two: determine the consensus for the "last resort" codec
6. All entities MUST support H.261
6. All entities MUST support H.263
9. All entities MUST support Theora

Step three: determine if there is any further consensus on a better MTI proposition:
1. All entities MUST support H.264
2. All entities MUST support VP8
3. All entities MUST support both H.264 and VP8
4. Browsers MUST support both H.264 and VP8, other entities MUST
    support at least one of H.264 and VP8
5. All entities MUST support at least one of H.264 and VP8
8. 5+$last_resort, i.e. All entities MUST support $last_resort and
    all entities MUST support at least one of H.264 and VP8
10. All entities MUST implement at least two of {VP8, H.264, $last_resort}
12. All entities MUST support decoding using both H.264 and VP8, and
    MUST support encoding using at least one of H.264 or VP8

If there is no consensus at step 3, then use the consensus reached at step 2.
If a consensus for an MTI is reached at step 1, but there is no consensus at step 2, then  no MTI would be defined.

Sincerely,
Gaëlle

From: rtcweb [mailto:[email-masked]] On Behalf Of cowwoc
Sent: Wednesday, November 27, 2013 2:08 PM
To: [email-masked]
Subject: Re: [rtcweb] The Voting Process

If you could come up with an alternative that works, great. The only reason we are voting is because all other options have failed.

It is my understanding that we have the following options (from best to worst):

Gili

I am not sure about the rest of the group but from my point of view the proposed process clearly shows that IETF in general and this group in particular is not equipped to vote. I also strongly disagree that voting would produce a MTI video codec decision which would meaningful in any way. We need a way to find consensus regarding the MTI or drop the whole MTI idea (which would also require consensus).
_____________
Roman Shpount

rtcweb mailing list

[email-masked]<mailto:[email-masked]>

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: "Mishra, Sanjay" <[email-masked]>
Date: Wed, 27 Nov 2013 15:57:42 -0500

Cullen -- Got it. Thanks for clarifying.

Herve -- Thank you for your e-mail on the same as well.

Thank you
Sanjay

---

From: Silvia Pfeiffer <[email-masked]>
Date: Thu, 28 Nov 2013 08:54:29 +1100

That begs the question whether when voting one is allowed to click
multiple boxes or just one.

Silvia.

On Thu, Nov 28, 2013 at 7:30 AM, Gaelle Martin-Cocher
<[email-masked]> wrote:
> Could we structure the MTI question into three questions, with consensus
> being declared on one before moving onto the next?
>
> If you could come up with an alternative that works, great. The only reason
> we are voting is because all other options have failed.
>
> Come up with a better mechanism for establishing MTI, or
> Vote for MTI, or
> Give up and declare No MTI
>
> Gili
>
> We need a way to find consensus regarding the MTI or drop the whole MTI idea
> (which would also require consensus).
>
> _____________
> Roman Shpount
>
>
>
>
>
>
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from your
> system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Wed, 27 Nov 2013 22:49:23 +0000

Hi Hervé

-----Original Message-----
From: Hervé [mailto:[email-masked]] 
Sent: Wednesday, November 27, 2013 5:16 PM
To: Gaelle Martin-Cocher; [email-masked]
Cc: Magnus Westerlund; John Leslie; tim panton; Roman Shpount; Ron; cowwoc; Silvia Pfeiffer
Subject: RE: [rtcweb] The Voting Process

________________________________
> From: [email-masked]
> To: [email-masked]
> Date: Wed, 27 Nov 2013 20:30:51 +0000
> Could we structure the MTI question into three questions, with 
> consensus being declared on one before moving onto the next?
>
> Step three: determine if there is any further consensus on a better 
> MTI
> proposition:
>

> If a consensus for an MTI is reached at step 1, but there is no 
> consensus at step 2, then  no MTI would be defined.

At that point, they just agreed there should be an MTI.
[Gaelle] at that point we would have agreed that it would be ideal to have an MTI but as we can't reach a consensus on any of them, then the conclusion is "while it would have been ideal, the group is unable to make a recommendation, hence no MTI is defined".

Is the "we won't get to your high quality codec unless you first agree about these older ones" part to encourage people to reach consensus?
[Gaelle] Those last_resort codecs are indeed far to be ideal but seems more favorable to a consensus (from my perception of the discussions on the list and of previous consensus calls). If we can't reach a consensus even on those, then we don't move to step 3 as at that point it seem highly probable that we would not reach a consensus at step 3 either. It should be noted that some of the least controversial options in step 3 do not replace step 2 but are enhancing it. (e.g. option 8 and 10).
At the contrary, if we reach a consensus at step 2, then at step 3, we may either have enough desire to reach a consensus on one of the step 3 options, or that would clearly indicate that the consensus reached at step 2 is "good enough". 

Since they're looking for consensus, they could agree to have any number even no $last_resort in step 2, right? and then still proceed to step 3.
Is that intentional?
[gaelle] as proposed at the beginning, a consensus needs to be reached at each step to proceed to the next.

> Gaëlle

Looks like it could be a long process, with many opportunities to come to the default state, no MTI.

I think the voting process proposed by the WG Chairs could give about the same information faster, especially if modified to use a condorcet method.
But as far as consensus based processes go, I think Gaëlle's is preferable to going straight to no MTI.

- Hervé

> solicitor-client or other applicable privileges), or constitute 
> non-public information. Any use of this information by anyone other 
> than the intended recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender and 
> delete this information from your system. Use, dissemination, 
> distribution, or reproduction of this transmission by unintended 
> recipients is not authorized and may be unlawful.
>
> _______________________________________________ rtcweb mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Wed, 27 Nov 2013 22:56:53 +0000

Hi Silvia,

If there is a consensus on the 3 steps approach then we should start talking about consensus call more than vote.
If we reach step 2, as there is much less options in step 2 than in step 3, we may be able to reach a consensus as per the usual IETF process.
If we reach step 3 there might be an opportunity given to the group to refine the list of options in step 3 to make the consensus call easier. 

Sincerely,
Gaëlle

-----Original Message-----
From: Silvia Pfeiffer [mailto:[email-masked]] 
Sent: Wednesday, November 27, 2013 4:54 PM
To: Gaelle Martin-Cocher
Cc: [email-masked]
Subject: Re: [rtcweb] The Voting Process

That begs the question whether when voting one is allowed to click multiple boxes or just one.

Silvia.

On Thu, Nov 28, 2013 at 7:30 AM, Gaelle Martin-Cocher <[email-masked]> wrote:
> Come up with a better mechanism for establishing MTI, or Vote for MTI, 
> or Give up and declare No MTI
>
> Gili
>
> voting would produce a MTI video codec decision which would meaningful in any way.
> We need a way to find consensus regarding the MTI or drop the whole 
> MTI idea (which would also require consensus).
>
> _____________
> Roman Shpount
>
>
>
>
>
>
> distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 28 Nov 2013 11:21:41 +0100

Hi John,

> to the webpage retrieved at a particular time.

Yes, we will update our proposal to reference a particular date. The one
currently available.

> determining at some later time _whether_ an individual is eligible.

Yes, and the reason is that we realized what amount of work it would be
to gather a list of all that would be eligible in an list and publish
that ahead of time. Including the failure of the jabber log to capture
JIDs and no mapping to Full name and email address. The later problem
also exist for blue sheets. Thus, the workable approach was to let
people to provide the pointer that prove their eligibility.

> mailing-list during some period. Those would ordinarily be considered

Still our proposal in the updated version will be participants that
considered active in the WG. Thus the ones that been to a meeting, IRL
or electronically in the jabber room, or have sent an email to the list.

>    "Voter" is vague here. I take it to mean any person sending a ballot.

Yes, the balloting individual.

> ballot itself is opened. I believe that is unheard-of.

The point was to have clear cut criteria for who are eligible.

> challenging eligibility (or absence from the list) before a vote is

You as an individual can already now verify that you can provide such a
pointer or not.

I agree that it is not possible to challenge another persons eligibility
prior to the balloting having completed and the list of who voted
becomes available.

> This requires that a voter may be counted as in favor of something

My understanding this was one of the few options in Instant Runoff
voting. We have selected full ranked to ensure that the voting will
provide a winner. If one doesn't mark all the option then that can't be
guaranteed. We wanted a voting process that would yield a winner.

I would note that No MTI at least can be used to indicate the options
that the balloter considered better or worse than no MTI. Although
nothing in the IVR process prevents the ranking below "no MTI" to be
used to determine the outcome of the voting.

> a ballot doesn't exactly match that requirement?)

Then we propose the ballot will be discarded. The vote collector if he
notice the issue when ballot is submitted shall contact the balloting
individual and notify them of the issue. If not corrected ballot is
available by end of balloting period then it will be discarded.

> that employees could understandably be nervous.)

Yes, we understand that as a potential issue. However, without making
the ballots public we don't see how we reasonably can ensure the voting
is done correctly and in a verifiable way.

>    Further, some person needs to be designated to interpret the rules

Noted, we chairs propose the vote collector will be arbiter. And the
normal IETF venues of appeal will be available for the arbiter's decision.

Cheers

Magnus Westerlund

---

From: John Leslie <[email-masked]>
Date: Thu, 28 Nov 2013 08:53:10 -0500

Note: I'm not trying to be contentious here; I'm merely offering my
expertise on voting. I have supervised Hale Preferential Transferrable
Voting, and have served as Assistant Moderator during Town voting.

> Yes, we will update our proposal to reference a particular date. The one

   :^)

   (May I suggest picking a particular time available from The Wayback
Machine?)

> that ahead of time.

   Agreed.

   Usually there is a registration process where potential voters declare
an intent to vote, and their eligibility is verified and published.

> or electronically in the jabber room, or have sent an email to the list.

   "Sent an email to the list" may prove subject to argument. Many folks
use and abandon multiple email addresses. Also, I frequently see "On
behalf of <name>" emails...

> Yes, the balloting individual.

   Thanks.

> The point was to have clear cut criteria for who are eligible.

   Someone must evaluate against those criteria. This, IMHO, should
be done in plain view.

> You as an individual can already now verify that you can provide such a

   Someone must evaluate any pointer I provide. This, IMHO, should
be done in plain view.

> prior to the balloting having completed and the list of who voted

   :^(

> voting.

   (There are quite a few options during counting...)

> We have selected full ranked to ensure that the voting will provide
> a winner. If one doesn't mark all the option then that can't be

   This is a misunderstanding.

   All versions can guarantee a winner. None of them can avoid the
need for tie-breaking.

   It is my understanding that Australians use mandatory marking,
apparently to increase the apparent vote totals. It doesn't work IMHO,
because folks cast intentionally invalid ballots.

> used to determine the outcome of the voting.

   Noted.

> available by end of balloting period then it will be discarded.

   This appears to say it is up to the vote collector to "notice" the
discrepancy. There is also the possibility that the discrepancy will
be found during counting...

> is done correctly and in a verifiable way.

   The usual practice is to fully verify the voter before the actual
ballot is visible; then count the ballot (or declare it invalid or blank).
Votes-needed-to-win is determined after subtracting invalid and blank
counts.

> normal IETF venues of appeal will be available for the arbiter's decision.

   Thank you.

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Thu, 28 Nov 2013 14:11:37 +0000

Hi Magnus,

Is the proposal to reach consensus via a 3 steps approach disregarded?
Sincerely,
Gaëlle

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Thursday, November 28, 2013 5:22 AM
To: John Leslie
Cc: [email-masked]
Subject: Re: [rtcweb] The Voting Process

Hi John,

On 2013-11-27 18:54, John Leslie wrote:
> ] The method we propose is based on Instant-runoff voting, ] 
> http://en.wikipedia.org/wiki/Instant-runoff_voting, with the ] 
> understanding that the choice will be the winner according to the ] 
> Instant-runoff voting process.
> 
>    Fail!
> 
>    A reference to wikipedia is completely unstable unless it refers to 
> the webpage retrieved at a particular time.

Yes, we will update our proposal to reference a particular date. The one currently available.

> 
>    It is the _intent_ of Wikipedia that the webpage may be modified at 
> any time by any person: thus people retrieving the page on different 
> days may receive different text. Those differences may be obvious or 
> they may be subtle.
> 
>    Second:
> ]

Yes, and the reason is that we realized what amount of work it would be to gather a list of all that would be eligible in an list and publish that ahead of time. Including the failure of the jabber log to capture JIDs and no mapping to Full name and email address. The later problem also exist for blue sheets. Thus, the workable approach was to let people to provide the pointer that prove their eligibility.

> 
> ] Any participant in the working group process either electronically ] 
> or in-person as of yesterday (20th of November).
> 
> ] Who has participated in the Working group process will be anyone ] 
> that can be identified from:

Still our proposal in the updated version will be participants that considered active in the WG. Thus the ones that been to a meeting, IRL or electronically in the jabber room, or have sent an email to the list.

> 
> ] The voter must at time of voting prove their eligibility, by 
> pointing ] to the mail archive or a particular blue sheet/meeting. 
> Please verify ] your own eligibility.
> 

> challenging eligibility (or absence from the list) before a vote is 

You as an individual can already now verify that you can provide such a pointer or not.

I agree that it is not possible to challenge another persons eligibility prior to the balloting having completed and the list of who voted becomes available.

> 
> ] 3) Start the the voting period. Those eligible and willing to vote 
> send ] their ballot to a vote collector (Matt Lepinski, former Nomcom 
> chair) ] within two weeks using email. The vote collector will check 
> when ] receiving a ballot the that the voter is eligible and send a ] 
> confirmation email on receiving the ballot. During the balloting 
> period ] the vote collector will keep all ballots secret.
> 

My understanding this was one of the few options in Instant Runoff voting. We have selected full ranked to ensure that the voting will provide a winner. If one doesn't mark all the option then that can't be guaranteed. We wanted a voting process that would yield a winner.

I would note that No MTI at least can be used to indicate the options that the balloter considered better or worse than no MTI. Although nothing in the IVR process prevents the ranking below "no MTI" to be used to determine the outcome of the voting.

> 
>    (Further, it leaves open the "or else" question: what happens if a 
> ballot doesn't exactly match that requirement?)

Then we propose the ballot will be discarded. The vote collector if he notice the issue when ballot is submitted shall contact the balloting individual and notify them of the issue. If not corrected ballot is available by end of balloting period then it will be discarded.

> 
> ] 4) When the voting period is over the ballot collector will publish 
> the ] results as well as all ballots, including the voters name to the 
> RTCWEB ] WG mailing list. This enables all voting individuals to 
> verify that ] their ballot is unmodified. And allows anyone to verify 
> the result of ] the vote.
> 
>    Thus every detail of preference becomes public. Inevitably there 
> will be some persons who are nervous about publishing so much detail. 
> (I don't mean to imply that employers _would_ punish employees, merely 

Yes, we understand that as a potential issue. However, without making the ballots public we don't see how we reasonably can ensure the voting is done correctly and in a verifiable way.

>    Further, some person needs to be designated to interpret the rules 

Noted, we chairs propose the vote collector will be arbiter. And the normal IETF venues of appeal will be available for the arbiter's decision.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 28 Nov 2013 15:24:35 +0100

> Is the proposal to reach consensus via a 3 steps approach disregarded?

Gaelle,

It is less than 24 hours since you provided your feedback. Today is
Thanksgiving in US.

The chairs did prepare to start the consensus call with an updated
procedure. However, based on the last 24 hours feedback I think we will
have to evaluate the latest feedback and determine what we see as the
next step.

Cheers

Magnus Westerlund

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Thu, 28 Nov 2013 14:27:44 +0000

Thank you.
The proposal to drop some of the options would also fit nicely in the step 3, the list could be refined immediately or only if we reach that step.

Cheers,
Gaëlle

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Thursday, November 28, 2013 9:25 AM
To: Gaelle Martin-Cocher; John Leslie
Cc: [email-masked]
Subject: Re: [rtcweb] The Voting Process

Gaelle,

It is less than 24 hours since you provided your feedback. Today is Thanksgiving in US.

The chairs did prepare to start the consensus call with an updated procedure. However, based on the last 24 hours feedback I think we will have to evaluate the latest feedback and determine what we see as the next step.

Cheers

Magnus Westerlund

---

From: John Leslie <[email-masked]>
Date: Fri, 29 Nov 2013 11:40:50 -0500

> have to evaluate the latest feedback and determine what we see as the

   This seems like a good time to expand on the "Condorcet" issue.

   Condorcet methods set out to solve a real issue. (There is a lot of
discussion available on the web about what other problems they cause
while doing so -- if you care about that, go look.)

   In most versions of "Instant Runoff" voting, one option can be
everybody's second choice but nobody's first choice -- and be
eliminated as a possible winner at the first round of transfers.

   That is a plausible problem here. :^(

   It's arguably possible that "no MTI" could be everybody's second
choice but nobody's first choice; and thus be eliminated.

   This is not necessarily a killer problem; but intelligent voters
would have to take that into account, and enough of them would have to
list no-MTI as their first choice with their actual first choice
listed second.

   (I am not asking for any particular change here: merely hoping to
help folks understand why several posters seem to be hung-up on using
Condorcet rules instead.)