Subject: [rtcweb] Fwd: A few thoughts on processes WAS (Re: Alternative decision process in RTCWeb)

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 6 Dec 2013 12:58:12 +0200

FYI.

Gonzalo

-------- Original Message --------
Subject: A few thoughts on processes WAS (Re: Alternative decision
process in RTCWeb)
Date: Fri, 6 Dec 2013 12:57:11 +0200
From: Gonzalo Camarillo <[email-masked]>
To: IETF Discussion <[email-masked]>
CC: <[email-masked]>

Hi,

I want to thank everybody for all the input on this issue. Let me
address a few of the points that have been brought up during the
discussions.

People seem to have different views on which processes MUST be used at
the IETF when developing documents, which ones MAY be used, and which
ones MUST NOT be used.

Given the strong disagreements we have seen, it may be useful to agree
on a set of guidelines and document them at some point. In the mean
time, let me clarify how the RTCWeb WG (or at least some people in that
community) interpret the IETF process.

The view a part of the RTCWeb community shares is the following:

Documents MUST go through both a WGLC and an IETF LC where the community
needs to reach rough consensus on them. That is, per standard IETF
processes, documents that reach rough consensus at those stages are
progressed while documents that don't reach rough consensus are *not*
progressed.

In summary: proposals are evaluated first by the WG and then by the IETF
community as a whole using a consensus mechanism.

Where people seem to disagree, often strongly, is on how proposals that
will be put forward for such evaluation by the WG and the IETF community
can be generated.

Some people think that processes that are somewhat related to voting
MUST NOT be used within a WG at all. Other people think that using
processes such as straw polls or some types of voting can help the WG
understand better the situation at hand and help build consensus, which
will be *ultimately* evaluated in the WGLC and IETF LCs on the document.

In short, some people think that the important fact is that documents
need to reach consensus at the WGLC and IETF LC stages. Before that, one
could use different processes if they are likely to help building that
consensus. Other people disagree.

My personal opinion is that both interpretations above have some merit
and should be discussed within the IETF community, which will sure face
difficult situations like this one in the future again. Future WG chairs
will benefit from more clarity on these issues.

On a related note, there have been some comments about the RTCWeb chairs
effectively attacking the IETF principles. I think those comments are
unfair. We are talking about three former ADs in different areas all of
whom have made significant contributions to the IETF community along
many years. They understand the situation at hand and are trying to
actively propose alternatives to resolve a difficult and important
issue. Let's discuss which interpretation of the IETF process the
community agrees more with (per the points above) instead of judging
people for interpreting the rules differently in an area that is,
arguably, not completely clear.

With respect to the decision about the MTI video codec at the RTCWeb WG,
the chairs will be proposing a way forward (taking into account all the
input received) shortly.

Cheers,

Gonzalo

On 28/11/2013 11:17 AM, Gonzalo Camarillo wrote:
> Folks,
> 
> as you may know, the RTCWeb WG is trying to select a
> mandatory-to-implement video codec. So far, the WG has been unable to
> reach consensus using traditional consensus calls. Now, the WG is
> considering alternative options to make that decision.
> 
> If you are interested in following that discussion on the RTCWeb list,
> this would be a good place to start:
> 
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html
> 
> Cheers,
> 
> Gonzalo
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 06 Dec 2013 14:50:35 +0000

Gonzalo,

Thanks for this really well written and good summary.  Again, the chairs
– and the area directors – as well as the whole RTCWeb group have been
working really hard on what many of us think will be critical
technology.  As one of the whiners about voting, let me say first that
*do* believe that strictly speaking the rules can be interpreted to
allow voting.  That doesn't make it a wise choice or a *substitute* for
rough consensus.   Therefore I subscribe to the following interpretation:

On 12/6/13 10:57 AM, Gonzalo Camarillo wrote:
> Other people think that using
And I would go further, and suggest that RFC 2418 provides working group
chairs with very broad latitude to declare what rough consensus is in
such circumstances.  The document merely points out that it is > 51% and
it needn't be 99%.  That large range should be fair warning that the
ruff in this case could be quite rough.  The ultimate point, as Jari
mentioned in his note of 2 Dec 2013 is to aim for broad interoperability.

And again, as one of the whiners, I probably have a responsibility to
put forward some thoughts on how one might proceed.  I state this as an
outsider to the WG, and so perhaps these ideas have been already tried
or considered and discarded.

You've created a rather long list of options.  It seems to me that it
would be good to know what we are talking about in terms of "rough".  It
might be useful still for participants to be polled on whether or not
they could live with each of those options.  That is - have a positive
signal.  This can be used to establish a front runner or group of
popular choices.  Recalling Jari's message again that interoperability
is what we are aiming for, it might also inform the working group to
understand what user bases and implementations are impacted, at the same
time.  Stating which implementation one is developing or is planning to
deploy will hopefully provide some feel for interoperability.  This does
weight near term over long term, but I think that's a good approach (you
don't get to long term if you can't satisfy near term).

I offer these purely as suggestions to be discarded if they are not
found to be useful.

Again, I wish the WG and the chairs the very best in trying to untie
this knot, and I offer to be whatever use I can to assist.

Eliot