On Sat, Nov 30, 2013 at 10:54 AM, Melinda Shore <melinda.shore@xxxxxxxxx> wrote:
On 11/30/13 4:45 AM, Roger Jørgensen wrote:Not for failure to gain consensus, by any means. "No consensus,
> And if the problem is that bad, that it's impossible to reach
> consensus in the WG, what about replacing the chairs? ...
do nothing" is a legitimate (if frustrating) outcome. I think
they showed really questionable judgment in calling for a vote
and laying out eligibility criteria, and for me that's a huge issue
(congratulations, guys - just like that you changed us into a
member organization) but failure to gain consensus is a valid
outcome.
There are some cases where having a vote would be appropriate, this is not one of them.
It is far from clear to me that having licensed a patent through the H.264 pool to practice H.264 that one has a license to practice VP8. My experience of patent lawsuits is that this represents a major litigation risk.
The issue is not whether the CODEC is 'probably' unencumbered, the issue is whether it is likely to result in a lawsuit. The typical cost of bringing a defense to trial is $2million plus expert fees and court costs. If it goes to a full trial then the cost is double.
If you are an open source not for profit organization, the stakes are rather different. Patent trolls don't usually bring spurious cases against people who can't pay. The litigation risk is minimal.
Trimming the patent pool does make a lot of sense and VP8 will be out of patent first so it does make a lot of sense to consider VP8 as must implement once it is clear of all patent claims. But that has not yet happened.
And note that the VP8 patent holders may hold some longer patents on H.264. So they are quite likely to bring suit to prevent a CODEC becoming established that would truncate the value of their patent claims.
The cases where voting would be a better, more appropriate decision making technique is when the status quo is a specification that has been found to be unimplementable or undeployable or insecure. According to the PKIX specification name constraints MUST be marked critical, which makes them incompatible with part of the deployed code base. The industry has decided to proceed with its own standard that allows name constraints to be marked non-critical because that allows us to make the Web more secure.
Having a vote in that circumstance seems rather better than having the decision on consensus made by a WG chair. At least then the position is clear. A 51% majority is not necessarily enough to make a change but if 80% of a WG votes to make a change and the WG chair is one of the 20% who voted the other way and declares that the decision lacks consensus then we know the fix is in and people will ignore it if it stands in their way.
But no decision making process is going to help in this case because the issues are commercial and involve a potential billion dollar litigation risk.
Besides this, there are problems with the way the 'vote' was proposed. The eligibility requirements were not specified in advance. I see a litigation risk for the IETF there.
There is only one way out of this mess in the short term and that is to choose a MTI CODEC that is widely supported AND is out of patent. At the moment there is no such CODEC but MPEG2 is out of patent in 2017. MPEG2 is not as performant but that is not the criteria for MTI, interoperability is the criteria.
I really regret that we didn't make raw audio without compression a standard part of the Web back in 1992 when we had the chance. It would have been grossly inefficient but the availability of a free and unencumbered codec that every browser supported would have greatly limited the value of audio CODECs to the amount of bandwidth they saved rather than being the value of providing audio.
Website: http://hallambaker.com/