WG,

The WebRTC ecosystem needs to avoid interoperability failure to grow
optimally.  The RTCWEB working group took on the task of establish Audio
and Video MTI codecs as part of meeting that need. We have not succeeded
in finishing that task for video using normal IETF process, but it is
still important.

We (WG chairs) are proposing that the working group consent to a method
that will establish an MTI, even if the MTI chosen does not have rough
consensus.  We would far prefer the normal IETF process, but it is not
proving workable for this selection.

We initially proposed a method from RFC 3929 (external review team), but
now believe that the working group would not consent to that method.
Instead we are proposing a method that leaves the decision in the hands
of the WG.

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.

The steps in the proposed process are these (1-5):

1) Establish a final list of alternatives, based on the WG's input to
Gonzalo's email on the 13th of November that requires any additions to
provided by end of the 27th of November.

2) Establish those eligible to vote.  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:
 - 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

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.

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.

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.


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.

5) The selection is recorded in the drafts.


--- End of Process Proposal ---

This message initiates the first step in the working group consensus
call process. Namely a one week comment and discussion period for the
above process.

After that week the WG chairs will update, if necessary, the proposal.
Then using the normal IETF process in which anyone is eligible to
participate, the chairs will ask for (rough) consensus to adopt this
extraordinary process to achieve the working group's stated goals.  The
end date for this consensus call is 2-weeks after the announcement of
the consensus call.

If the working group does not consent to using this extraordinary
process, we will hold a consensus call if the WG can accept
"WebRTC entities MUST support at least one of H.264 or VP8.".

If there is failure to establish consensus even for this statement, the
chairs conclude that the WG can't establish what to say about a MTI
video codec.

The WG Chairs

Magnus Westerlund
Cullen Jennings
Ted Hardie