Subject: Re: Alternative decision process in RTCWeb

From: Ted Hardie <[email-masked]>
Date: Sun, 1 Dec 2013 09:01:01 -0800

On Sat, Nov 30, 2013 at 7:54 AM, Melinda Shore <[email-masked]>wrote:

> On 11/30/13 4:45 AM, Roger Jørgensen wrote:
> > And if the problem is that bad, that it's impossible to reach
> > consensus in the WG, what about replacing the chairs? ...
>
> Not for failure to gain consensus, by any means.  "No consensus,
> 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.
>
>
For what it's worth, all the chairs agree that failure to get consensus is
a valid outcome and it may be where we end up.  The internal discussion
among the chairs and RAI ADs was extremely extensive and not at all fun;
think soul-searching, beating of breasts, tearing of sack cloth, and
wearing of ashes.   Trust us that we did not do this lightly; as one of us
put it in the internal discussion: "We're going to get an epic beat down
for this".

So why did we put ourselves forward for that?  Because we're charged as WG
to make the WebRTC ecosystem as complete and strong as we can.  if we don't
have a decision on this issue, we're creating a standard that will be
hobbled out of the gate.  Its baseline negotiation mechanism means it has
some freedom of movement, and it may eventually get up a good speed. But
this hurts it in ways that it is very hard for us to ignore.  We'd be going
out with a large likelihood of isolated WebRTC communities, especially in
mobile apps, instead of a unified ecosystem.  Balancing that pain against
this is not easy.

We would have preferred to get consensus; we would have preferred over this
to get an RFC 3929 decision.  And at no time did we propose imposing voting
unilateraly.  We have sought the consensus of the working group on it, to
see if this works as a last ditch effort to see if there is *any* way
forward.

So, three ex-ADs and two current ones agreed to go this far out on a limb
to get some way forward. It was sufficiently important for us to put this
out, _knowing we'd get an epic beat down for it_.  That's how much this
decision means.

There may not be any way forward, and we'll accept that if that is the
result of this discussion.  I personally continue to hope that this set of
exchanges will raise awareness among working group participants of the
importance of pushing to a common standard here, and that we may see some
common ground emerge.

regards,

Ted Hardie

> Melinda

---

From: Melinda Shore <[email-masked]>
Date: Sun, 01 Dec 2013 14:35:13 -0900

On 12/1/13 8:01 AM, Ted Hardie wrote:
> For what it's worth, all the chairs agree that failure to get consensus
> is a valid outcome and it may be where we end up.  The internal
> discussion among the chairs and RAI ADs was extremely extensive and not
> at all fun; think soul-searching, beating of breasts, tearing of sack
> cloth, and wearing of ashes.   Trust us that we did not do this lightly;
> as one of us put it in the internal discussion: "We're going to get an
> epic beat down for this".

You did not receive an "epic beat down" although I think you
probably should have (or something like one).  What you did
was huge and has impacts far outside the scope of one
decision in one working group.

Look, I've been feeling for some time that our decision-making
structures don't work for us anymore - that there are too many
people looking for optimal personal outcomes (as opposed to
optimal organizational, good-for-the-internet outcomes), there
aren't enough people invested in a healthy process, and that
it's become incredibly difficult - too difficult - to reach
decisions in a contested space.  However, changing decision-
making to a voting-based process assumes changes to the
organization that I think are devastating.  When we distinguish
between those who are eligible to vote and those who aren't
we create a membership, and when we vote and have a membership
we enter into the very nasty problem of balancing what I think
is our most important organizational characteristic - openness -
against the problem of ballot box stuffing.

We were quite successful in minimizing the impact of the EFF-
motivated mailing list deluge on the TLS authz patent, which
I don't think we could have done if we'd been using the
processes you've invented.  We certainly wouldn't have been
able to have a good outcome in nvo3.  Speaking of which, that
working group was deadlocked for quite awhile but managed their
way out of it without going to a voting model.

I think that we're not that far away from needing to take
a long, hard look at how we're structured with an eye towards
what we need to do to maintain our openness while remaining
effective.  I think the particular situation in WebRTC, with
a roll-your-own voting process, is absolutely the wrong
context for doing that - it needs to be done at the pace at
which it needs to be done and it needs to be done thoughtfully
and thoroughly, and not because one particular working group
can't figure out how to go forward but needs something now.

Melinda

---

From: Eric Burger <[email-masked]>
Date: Sun, 1 Dec 2013 19:07:03 -0500

No: this is what the sort of statement get *me* an epic beat down:
	Why do this sort of thing here when you can do it in 3GPP? ETSI has membership, voting, and the whole mobile and telco crowd.

If I cannot tell the difference between IETF and 3GPP and 3GPP procedures, it is time to go home.

On Dec 1, 2013, at 12:01 PM, Ted Hardie <[email-masked]> wrote:

> On Sat, Nov 30, 2013 at 7:54 AM, Melinda Shore <[email-masked]> wrote:
> For what it's worth, all the chairs agree that failure to get consensus is a valid outcome and it may be where we end up.  The internal discussion among the chairs and RAI ADs was extremely extensive and not at all fun; think soul-searching, beating of breasts, tearing of sack cloth, and wearing of ashes.   Trust us that we did not do this lightly; as one of us put it in the internal discussion: "We're going to get an epic beat down for this".
> 
> So why did we put ourselves forward for that?  Because we're charged as WG to make the WebRTC ecosystem as complete and strong as we can.  if we don't have a decision on this issue, we're creating a standard that will be hobbled out of the gate.  Its baseline negotiation mechanism means it has some freedom of movement, and it may eventually get up a good speed. But this hurts it in ways that it is very hard for us to ignore.  We'd be going out with a large likelihood of isolated WebRTC communities, especially in mobile apps, instead of a unified ecosystem.  Balancing that pain against this is not easy.  
> 
> We would have preferred to get consensus; we would have preferred over this to get an RFC 3929 decision.  And at no time did we propose imposing voting unilateraly.  We have sought the consensus of the working group on it, to see if this works as a last ditch effort to see if there is *any* way forward.  
> 
> So, three ex-ADs and two current ones agreed to go this far out on a limb to get some way forward. It was sufficiently important for us to put this out, _knowing we'd get an epic beat down for it_.  That's how much this decision means.
> 
> There may not be any way forward, and we'll accept that if that is the result of this discussion.  I personally continue to hope that this set of exchanges will raise awareness among working group participants of the importance of pushing to a common standard here, and that we may see some common ground emerge.  
> 
> regards,
> 
> Ted Hardie
> 
> 
>  
> Melinda
> 
>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 2 Dec 2013 07:49:45 -0800

On Sun, Dec 1, 2013 at 3:35 PM, Melinda Shore <[email-masked]>wrote:

> probably should have (or something like one).

Well, the week is young, and lots of Americans were off.

>  What you did
Just to get the tense structures right, we are currently in the "a proposal
has been made to the working group and will be revised" phase.  The next
step, should we get there, is a consensus call to use this alternative
process.
That is *explicitly* using our standard process for reaching consensus, as
Magnus's note to the working  group makes clear.

> against the problem of ballot box stuffing.
The chairs and ADs discussed this set of issues at great length and
proposed this despite those (with a great deal of queasiness and
and discomfort, I reiterate).  We did so because we think we will
_lose interoperability_ if we don't get a decision here.  I agree with you
that our greatest organizational characteristic is openness, but our
biggest focus as an engineering organization is interoperability.  If
we give that up because our process can't get us there, we have lost
something quite real.  Not just relevance, but an opportunity to make
the Internet better by enabling an ecosystem the really enhances what
we can do with the web.  That's an opportunity cost that cuts all of us
who have been working on this pretty hard.

I don't ask you to love this idea; I don't.  I do hope you understand the
hard place on the other side of the rock.

> effective.

I agree, but unfortunately the last few process changes have all
gone forward in ways that strongly indicate that the organization
is only willing to consider incremental change (and that mostly done
outside of working group processes).  What you describe may require
a little more punctuated equilibrium than we can currently muster.

>  I think the particular situation in WebRTC, with
"Wait for it" means "lose interoperability".  Whether that wait is
for the market to decide, for the IETF to find new processes, or for new
codecs without IPR to appear.

Just so we're clear.

Ted

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 29 Nov 2013 01:07:51 +0000

While I don't believe the WG would be positive on that, I do not believe that question has been put to a consensus call. So I would question the word specifically. 

If you still believe it so, please tell me when you think the WG decided this.

Keith 

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Ted Lemon
> Sent: 28 November 2013 17:03
> To: Dave Crocker
> Cc: [email-masked]; Eliot Lear; 
> [email-masked]; Eric Burger; IETF Discussion
> Subject: Re: [rtcweb] Alternative decision process in RTCWeb
> 
> On Nov 28, 2013, at 11:29 AM, Dave Crocker <[email-masked]> wrote:
> > As merely one obvious example, people can simply be tired of the 
> > impasse and eagerly seek progress and be willing to settle on any 
> > mechanism they think will fairly break it -- even if it 
> works against 
> > the outcome they prefer.
> 
> The one tidbit you may be missing is that the working group 
> specifically chose not to do a coin toss.   So "willing to 
> settle for any mechanism" clearly doesn't apply in this case.
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Mary Barnes <[email-masked]>
Date: Mon, 2 Dec 2013 09:34:41 -0600

On Thu, Nov 28, 2013 at 1:27 PM, Michael Richardson
<[email-masked]>wrote:

>
> Ted Lemon <[email-masked]> wrote:
>     >> mechanism they think will fairly break it -- even if it works
> against
>     >> the outcome they prefer.
>
>     > specifically chose not to do a coin toss.  So "willing to settle for
>     > any mechanism" clearly doesn't apply in this case.
>
> That tells me that the participants are not willing to live with losing and
> move on, and so no voting process will work either.
>
[MB] Exactly. [/MB]

>
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
>
>
>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 2 Dec 2013 16:08:01 +0000

> member organization) but failure to gain consensus is a valid

We have NOT called for a vote. We have NOT even sent out an consensus call to see if there is consensus to use an alternative process. We sent an email to discuss that possibility. I really wish people would actually look at what is going on. 

I would like to point out that this discussion has been going on for years and has had several consensus calls, and straw polls have already been taken on it.  The alternative consensus process being discussed included everyone that had previous been involved in any way whats so ever in the discussion or expressed any opinion on previous consensus calls on subject.  Its not totally unreasonable to think that most people that cared to be part of the decisions had already been involved in being part of the decision and this included all them. For folks that have been following this, yes updated proposal which includes the jabber folks but that has never been sent to list due to still waiting on other things. 

(Cullen - one of the co-chairs for rtcweb)

---

From: Ron <[email-masked]>
Date: Fri, 29 Nov 2013 16:39:36 +1030

On Thu, Nov 28, 2013 at 02:39:49PM -0800, Bernard Aboba wrote:
> > On Nov 28, 2013, at 2:27 PM, Michael Richardson <[email-masked]> wrote:
> [BA] The participants aren't willing to live with losing for business or
> legal reasons that aren't within the jurisdiction of an IETF WG.  As an
> example,  would an open source product that requires source code to be
> provided without a license fee put that aside because IETF RTCWEB has agreed
> upon H.264 as MTI?  Similarly, would a vendor who is concerned about
> potential liability from incorporating VP8 put that concern aside because the
> IETF RTCWEB WG has decided to make VP8 MTI?  

I think EKR said this more succinctly with:

 "it's important to understand that in in this case, many people more
  don't want X than do want Y."

And I think you both have clearly identified the problem, and why voting
is clearly not a solution to it.

The blocking issue is that many people have valid reasons why they _can't_
deploy one or more of the possible choices.  You can't possibly solve that
by taking a poll of what the majority of people would _prefer_, ignoring
all other people's blocking constraints.

However I think we can still resolve this by following normal consensus
procedures, and walking our way up from the least troublesome options to
the most, and seeing at what point consensus actually breaks down.

 1. Do we want an MTI codec?

   It's generally accepted there is consensus the answer to this is Yes.
   We also have a list of codecs that we could possibly choose from.
   It also seems generally accepted that IPR trouble is the least
   negotiable  problem that is at the heart of many objections.

 So let's start where that problem is the smallest, at the very bottom:

 2. Can anybody show a sustainable objection for why we _can't_ use H.261.

   If they can, we're probably doomed.  If they can't we have an initial
   choice for MTI.

 3. Can anybody show a sustainable objection for why <alternative>
    can't replace H.261 as the MTI codec?

   If they can, lather rinse repeat through the other alternatives.
   If they can't, we have a new baseline to ask this question of
   for the remaining alternatives.

Yes, this may take some time (but surely less than we've already spent),
but it clearly separates the question of what people _can't_ do, from
what they would prefer to do if they had their druthers.

We probably won't get the best possible codec as the MTI fallback,
but we probably will get a decision that isn't fundamentally doomed.
And that's fine, because people will still get their preferred codec
through runtime negotiation if they use an implementation which does
accept the risk of supporting it - and the safe interop fallback if
it doesn't.

Why would this one simple procedure not work to resolve the deadlock?

  Ron

---

From: Eric Burger <[email-masked]>
Date: Mon, 2 Dec 2013 12:10:56 -0500

If this is really the issue:

> codecs without IPR to appear.

then I would propose we charter the daughter of CODEC, focused on creating an IPR-cleared, IETF-standard, video codec. I thought CODEC could not be done, even though (or perhaps because?) I co-chaired the BOF, and I was pleasantly proven wrong. I have no problem learning from the past: if the REAL issue is IPR, the IETF now has a track record of fixing that.

CODEC got its #1 task, publishing the new Opus codec, done in record time. It was under three years from chartering CODEC to RFC publication.

I would offer RTCWEB punts on MTI, a bunch of motivated people get to work on Video-CODEC, and we can eventually have one codec to rule them all.

BTW, if this sounds like a Solomon Solution(tm), it is. It means that NEITHER VP8 NOR H.264 lives on as an official, IETF-sanctioned video codec.

Live by the sword, get cut in half by the sword.

---

From: "cb.list6" <[email-masked]>
Date: Mon, 2 Dec 2013 09:15:19 -0800

On Dec 2, 2013 9:11 AM, "Eric Burger" <[email-masked]> wrote:
> then I would propose we charter the daughter of CODEC, focused on
creating an IPR-cleared, IETF-standard, video codec. I thought CODEC could
not be done, even though (or perhaps because?) I co-chaired the BOF, and I
was pleasantly proven wrong. I have no problem learning from the past: if
the REAL issue is IPR, the IETF now has a track record of fixing that.
>
> CODEC got its #1 task, publishing the new Opus codec, done in record
time. It was under three years from chartering CODEC to RFC publication.
>
> I would offer RTCWEB punts on MTI, a bunch of motivated people get to
work on Video-CODEC, and we can eventually have one codec to rule them all.
>
> BTW, if this sounds like a Solomon Solution(tm), it is. It means that
NEITHER VP8 NOR H.264 lives on as an official, IETF-sanctioned video codec.
> Live by the sword, get cut in half by the sword.

+1. IPR *is* the issue and I would LOVE to see RTCWEB punt. This is the
obvious IETF answer, not a vote of members

CB

---

From: Mary Barnes <[email-masked]>
Date: Mon, 2 Dec 2013 11:15:59 -0600

We had a videocodec bof  @IETF-85 and the WG just never got chartered:
http://trac.tools.ietf.org/bof/trac/wiki/BofIETF85.   Perhaps the ADs can
fill in the gap as to why that didn't happen as I'm not sure whether a ball
was dropped or there was a reason not to charter.

Regards,
Mary.

On Mon, Dec 2, 2013 at 11:10 AM, Eric Burger <[email-masked]>wrote:

> then I would propose we charter the daughter of CODEC, focused on creating
> an IPR-cleared, IETF-standard, video codec. I thought CODEC could not be
> done, even though (or perhaps because?) I co-chaired the BOF, and I was
> pleasantly proven wrong. I have no problem learning from the past: if the
> REAL issue is IPR, the IETF now has a track record of fixing that.
>
> CODEC got its #1 task, publishing the new Opus codec, done in record time.
> It was under three years from chartering CODEC to RFC publication.
>
> I would offer RTCWEB punts on MTI, a bunch of motivated people get to work
> on Video-CODEC, and we can eventually have one codec to rule them all.
>

---

From: Dave Crocker <[email-masked]>
Date: Mon, 02 Dec 2013 09:18:02 -0800

> We have NOT called for a vote. We have NOT even sent out an consensus call to see if there is consensus to use an alternative process. We sent an email to discuss that possibility. I really wish pe…

Actually, the thread has been pretty good about focusing on what's being 
done.  What's being done is an effort to invent an IETF voting process, 
exactly contrary to established IETF principles and practice.

The pressures towards voting are constant and reasonable.  For the IETF, 
they are also wrong.

The premise of the IETF's decision process is that a strongly dominant 
community agreement is necessary for eventual success of a 
specification.  If you have that agreement, a mechanical measurement 
like voting isn't needed, because the dominant choice is obvious.  If 
you don't have that agreement, voting doesn't help because you won't 
have sufficient support for eventual market uptake.

The challenge, then, is to formulate a decision-sequence that does 
produce rough consensus, or to declare failure.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 2 Dec 2013 13:32:41 -0500

> was dropped or there was a reason not to charter.

How long is such a group likely to take and would it be developing a new
CODEC or selecting from existing unencumbered choices?

Is there an expectation that such a group would produce a CODEC better than
MPEG2 or report substantially earlier than the expiry of the last patents
in the MPEG2 pool (expected to be ~2017)?

Half the MPEG2 patents have expired already and it is possible that a
subset of the MPEG2 CODEC could be defined that avoided IPR encumbrances.
But it is hard to see such a CODEC gaining significant ground in the next 4
years.

MPEG2 is not as efficient as H.264 and it does not support all the same
modes. But it is almost certainly good enough for MTI.

The best approach to this problem looks to me to be to do what we did with
the Diffie Hellman and RSA patents and wait for them to expire. We did
start pushing DH and El Gamal based schemes between 1997 and 2000 when
those were out of patent but RSA was still covered. Doing the same with
H.264 makes sense.

The long tail patents on H.264 is very long, there is at least one in the
pool that does not expire till 2027

-- 
Website: http://hallambaker.com/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 02 Dec 2013 20:27:20 +0100

>   If they can, we're probably doomed.  If they can't we have an initial

I have not seen a convincing argument that H.261 performs well enough to
permit real-time video communication at reasonable quality and bitrates.

I have not seen recent statistics for Germany but I suspect it is common
that household members share a line with an upstream of around 640 kbps,
that would basically allow for two 320x240 H.264 CBP + Audio streams at
30 fps in good quality. Would H.261 permit at least one stream at the
same quality? If not, then nobody would use H.261-only WebRTC products,
and people are not going to appreciate if a VP8 product connecting with
a H.264 product falls back to H.261 to avoid negotiation failure.
-- 
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: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 2 Dec 2013 15:12:33 -0500

> permit real-time video communication at reasonable quality and bitrates.

That is irrelevant.

MTI does not need to be a good choice, it merely needs to achieve
interoperability.

If someone can support HD video over a 300 BAUD connection, the technology
is almost certain to be proprietary. That does not mean that the IETF has
to accept the proprietary technology as MTI because it is the only one that
supports the needs of 300 BAUD users, it means that that group of users may
not be supported by the MTI CODEC.

MPEG2 will come out of patent in the nearish future and it is a not
terrible choice. It is certainly not the best choice but it isn't a
horrible one.

> a H.264 product falls back to H.261 to avoid negotiation failure.

People would use H.261 if that is all the clients at either end supported.
The value of the H.264 patent pool would be reduced from the ability to
perform the application to a quality issue for some subset (a clear
minority) of the user base.

We knew that there were real security and performance problems with 3DES
when we made it MTI in TLS 1.0 but that was the best choice available at
the time.

If there was an optimal technical choice that had no other consideration
there would be no need for MTI clauses at all.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 2 Dec 2013 15:26:04 -0500

On Mon, Dec 2, 2013 at 12:18 PM, Dave Crocker <[email-masked]> wrote:

>> We have NOT called for a vote. We have NOT even sent out an consensus
>> call to see if there is consensus to use an alternative process. We sent an
>> email to discuss that possibility. I really wish people would actually look
>> at what is going on.
>>
>
>

Actually they are right, they just have the wrong process.

This is not a technical decision, if it was, the answer would be very easy
to decide, just run some tests.

The issue is a business decision and the question for browser and platform
providers is whether a proposed MTI CODEC is available to them on
acceptable terms. Here acceptable depends not on the state of patent law
but the state of patent gamesmanship and the cost of evaluating a proposal
for potential infringement liability, the cost of mounting a defense, the
risk of an adverse judgement, etc.

The people who decide such matters are not here at the table so argument is
superfluous. And simply asserting that a CODEC is MTI will not make it so,
it will only help interoperation if the stakeholders decide to recognize
the outcome.

Rather than having a vote for a particular CODEC, the only approach that
can arrive at a consensus is for the stakeholders to state which CODECs are
acceptable to them and define consensus as being a CODEC that is supported
by 90% or 95% or some overwhelming proportion of stakeholders by market
share.

That isn't IETF process either but it is the only approach that is going to
result in a decision that has buy in from all the necessary stakeholders.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 02 Dec 2013 13:04:49 -0800

On 11/29/2013 12:22 AM, Roberto Peon wrote:
> The only reason to specify a must-implement is to increase interop; if
> mandating a codec does not increase the amount of interop, why do it?

If the base specification does not provide enough information for basic 
interoperability, what is the benefit in standardizing it?

An alternative that I believe has already been mentioned is to 
standardize /both/, but separately.

Under two different names, which then lets the market decide on whether 
either will succeed.

Letting the market decide amongst competing choices used to be something 
the IETF did more commonly.  One of the more colorful examples was SNMP 
vs. CMOT.

d/

---

From: Eric Burger <[email-masked]>
Date: Mon, 2 Dec 2013 16:19:50 -0500

Funny, but by my math, MPEG2 patent expiry is roughly equal to the date a brand spanking new video codec RFC would be published. I see only two differences between a new codec and MPEG 2. In the brand spanking new video codec’s corner is I would expect it to run circles around MPEG2 from a performance perspective. and we would know there could be no royalties on MPEG2, but the brand spanking new video codec would have the identical cloud Opus has hanging over it. That is, we all know there must be IPR against it, but no one has raised their hand (yet) saying they have it.

[Is PHB & EWB agreeing on something the new version of Dave Crocker agreeing with jck?]

On Dec 2, 2013, at 1:32 PM, Phillip Hallam-Baker <[email-masked]> wrote:

> On Mon, Dec 2, 2013 at 12:15 PM, Mary Barnes <[email-masked]> wrote:
> We had a videocodec bof  @IETF-85 and the WG just never got chartered:  http://trac.tools.ietf.org/bof/trac/wiki/BofIETF85.   Perhaps the ADs can fill in the gap as to why that didn't happen as I'm not sure whether a ball was dropped or there was a reason not to charter.
> 
> Regards,
> Mary. 
> 
> How long is such a group likely to take and would it be developing a new CODEC or selecting from existing unencumbered choices?
> 
> Is there an expectation that such a group would produce a CODEC better than MPEG2 or report substantially earlier than the expiry of the last patents in the MPEG2 pool (expected to be ~2017)?
> 
> Half the MPEG2 patents have expired already and it is possible that a subset of the MPEG2 CODEC could be defined that avoided IPR encumbrances. But it is hard to see such a CODEC gaining significant ground in the next 4 years.
> 
> MPEG2 is not as efficient as H.264 and it does not support all the same modes. But it is almost certainly good enough for MTI.
> 
> 
> The best approach to this problem looks to me to be to do what we did with the Diffie Hellman and RSA patents and wait for them to expire. We did start pushing DH and El Gamal based schemes between 1997 and 2000 when those were out of patent but RSA was still covered. Doing the same with H.264 makes sense.
> 
> The long tail patents on H.264 is very long, there is at least one in the pool that does not expire till 2027 
> 
> 
> --

---

From: Sam Hartman <[email-masked]>
Date: Mon, 02 Dec 2013 17:11:27 -0500

>>>>> "Ron" == Ron  <[email-masked]> writes:

    Ron>  2. Can anybody show a sustainable objection for why we _can't_
    Ron> use H.261.

    Ron>    If they can, we're probably doomed.  If they can't we have
    Ron> an initial choice for MTI.

This is a fine approach, but you also need to get consensus that
least-objectionable-choice is a good decision mechanism.
That doesn't follow directly from we want an MTI codec.

If you think you can get consensus behind the process you propose then
go for it.
However don't skip important steps.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 02 Dec 2013 23:52:26 +0100

>MTI does not need to be a good choice, it merely needs to achieve

The Working Group seeks interoperability in the area of real-time video,
not in the area of slide shows or scaled animated icons. I suggested
earlier to compare H.261 to sending a series of JPEG images or sending
animated GIFs in terms of resolution, framerates, bitrates, and so on.
If H.261 is shown to be much closer to H.264 CBP than it is to those, I
would be willing to consider it.

>People would use H.261 if that is all the clients at either end supported.

If they were unable to use other clients and really need low-resolution
slide shows and there are no other factors to consider -- then perhaps.
I myself would not voluntarily watch low-framerate or extremely blurry
video if I do not have to.
-- 
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: Martin Thomson <[email-masked]>
Date: Mon, 2 Dec 2013 14:59:40 -0800

> video if I do not have to.

I love playing devil's advocate...  But you need to remind yourself
that a) you do the audio equivalent just about every time you make a
phone call on the PSTN (which I grant, you might not do, the world is
moving on), and b) those specific problems can be addressed with the
application of more bandwidth or by having teeny postage-stamp videos.

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 3 Dec 2013 02:36:19 +0000

Hi,

A few data point re video codecs (most of them were made already on the
rtcweb list):

1. A reasonably well tuned H.261 codec (including pre/post filters etc.)
will under almost any circumstance produce a better picture than MJPEG.
The intra coding tools of H.261 have a lot in common with JPEG, and H.261
offers inter picture prediction on top of that.

2. At 48 kbit/s, we (and anyone else who had products at the time) got
reasonably good looking video conferencing QCIF pictures (176x144 samples,
15 fps) on Pentium P54C hardware back in 1996.  The Pentium was also
loaded with an ISDN software stack, G.728 audio (which took the rest of
the 64 kbit/s of one ISDN B channel), rudimentary echo cancellation, and a
user interface based on Windows 95.

3. I¹m confident that a competent video coding engineer could clean-room
implement a complete, reasonably well tuned H.261 codec in less than a man
year.  If starting from the existing H.261 sources that can be found in
various software packages, it should take much less than that.

4. In pretty much all video coding algorithms, factors such as blurriness
and framerate are a function of the bitrate you allow the encoder to use.
Throw a megabit at H.261, and it will produce a good CIF picture.

5. The bitrate required per sample (for the typical picture sizes in use)
have approximately halved between each generation of video codecs.  That
is, to achieve the same visual quality, one needs approximately half the
bitrate when moving on one generation.  I wrote ³per sample² and ³for
typical picture sizes in use², because newer video codecs tend to be
optimized for larger picture sizes.  H.261 was clearly optimized for QCIF
and CIF, whereas H.265 shines at 1080p and above.

Many use the following generations in discussions like this:
1st (ca. 1989): H.261
2nd (ca. 1993): MPEG-1, MPEG-2,  (aka H.262)
3rd (ca. 1996): H.263, MPEG 4 part 2, VC1
4th (ca. 2003): H.264, VP8
5th (ca. 2013): H.265, VP9

5. Patent claims allegedly covering technologies in video coding according
to the 2nd and 4th generation standards are *today* actively litigated.

Stephan

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Dec 2013 07:46:15 -0500

On Mon, Dec 2, 2013 at 4:04 PM, Dave Crocker <[email-masked]> wrote:

> An alternative that I believe has already been mentioned is to standardize
> /both/, but separately.
>
> the IETF did more commonly.  One of the more colorful examples was SNMP vs.
> CMOT.

And twenty years later the market still hasn't decided between S/MIME and
PGP.

Or maybe it has decided none of the above.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 03 Dec 2013 14:00:14 +0100

On 12/02/2013 10:04 PM, Dave Crocker wrote:
> If the base specification does not provide enough information for 
> basic interoperability, what is the benefit in standardizing it?
>
> Under two different names, which then lets the market decide on 
> whether either will succeed.
>
> Letting the market decide amongst competing choices used to be 
> something the IETF did more commonly.  One of the more colorful 
> examples was SNMP vs. CMOT.

I prefer to remember (not fondly) SNMPv2U vs SNMPv2*.

What the market told us at that time, *very* loudly, was that there 
would be no massive deployment of a properly secured version of SNMP 
until the IETF reached a decision.

The IETF eventually reached a decision (SNMPv3). I don't know if it 
eventually mattered that much; SNMP's grand ambitions had been overtaken 
by events.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Dec 2013 09:50:54 -0500

On Dec 3, 2013, at 7:46 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> And twenty years later the market still hasn't decided between S/MIME and PGP.

S/MIME has wide implementation, but little deployment.   PGP has little implementation and little deployment.   I think the what the market has said is "we don't really care about this."

---

From: Eric Burger <[email-masked]>
Date: Tue, 3 Dec 2013 10:06:25 -0500

Agreed. The problem is not that people cannot choose between S/MIME or PGP. The problem is few people use anything.

---

From: Jim Gettys <[email-masked]>
Date: Tue, 3 Dec 2013 10:15:22 -0500

On Tue, Dec 3, 2013 at 10:06 AM, Eric Burger <[email-masked]>wrote:

> Agreed. The problem is not that people cannot choose between S/MIME or
> PGP. The problem is few people use anything.
>

Both fail the usability by mere mortals test, much less the usable by most
geeks test...  So the experiment is meaningless.
                      - Jim

> > S/MIME has wide implementation, but little deployment.   PGP has little
> implementation and little deployment.   I think the what the market has
> said is "we don't really care about this."
> >
>
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 03 Dec 2013 15:30:21 +0000

> And twenty years later the market still hasn't decided between S/MIME

I agree with Jim that having two standards in this space has mattered
not one bit.  There are many reasons why email simply isn't encrypted. 
First, it's hard to get a key.  Second, those who are in a position to
simply dole them out don't as it provides no value to them.  Third,
there is no deployed directory infrastructure to find someone else's
key.  Forth, if there was one, it would result in defeating of common
anti-spam/anti-malware tools.

Eliot

---

From: Hector Santos <[email-masked]>
Date: Tue, 03 Dec 2013 19:21:43 -0500

> S/MIME has wide implementation, but little deployment.   PGP has little implementation and little deployment.   I think the what the market has said is "we don't really care about this."

I never got it to work well and if I did, it didn't offer anything of 
incredible value.  Its also gives one the Cry Wolf syndrome -- what if 
that one time it failed, what does it mean?  Do you accept it? It is 
real? and so on.

Just consider DKIM itself.  I don't get the IETF here.

It just KILLED the #1 one protection layer for it - ADSP (making it 
historic, but to what?), that helped receivers with deterministic 
security guidance its long hard debated security considerations wanted 
to help protect domain owners and its (mail reading) users! Abandoned, 
in my strong business/engineering opinion, for no other reason but due 
to its competition with the trust/reputation framework entities.  I 
didn't get it because everyone can have a piece of the cake and eat it 
too!

Go figure.

The problem with RTCWEB, WebRTC, WebSockets (we need a dummies guide 
for this now), is that it is still a moving target.   We can use this 
technology in the BBS world (Application server/Intranet market) to 
help bring back a "terminal" A.K.A. now with the "Browser," full 
duplex communications back to backend servers.

We been looking at this (intelligent any device frontends) since the 
early 2000, but its all been moving too fast. RTCWEB/WebRTC/WebSockets 
(which is it?) looks promising to help with single sourcing this type 
of product lines.  I hope the IETF can help manage, lead and mature 
the technology with all the principle vendors and still do it with 
cooperative competition, public domain, and no conflict of interest in 
mind.

-- 
HLS

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Dec 2013 21:59:57 -0500

On Tue, Dec 3, 2013 at 10:30 AM, Eliot Lear <[email-masked]> wrote:

> I agree with Jim that having two standards in this space has mattered not
> one bit.  There are many reasons why email simply isn't encrypted.  First,
> it's hard to get a key.  Second, those who are in a position to simply dole
> them out don't as it provides no value to them.  Third, there is no
> deployed directory infrastructure to find someone else's key.  Forth, if
> there was one, it would result in defeating of common

All true.

But I think the reason neither camp has tried to address them is that they
think the real problem is that the other is confusing the market.

Comodo and another CA actually do dole the keys out (or at least sign them)
for free. But that isn't the real problem. The real problem is that it is a
complete pain to register for the key even if that is free and it only
lasts a year when you do. So for most people they spend fifteen minutes
setting up encryption, use it once or twice and the next time they want to
use it their certificate has expired.

There are a lot of problems here, but I think they can all be solved. In
fact I think I have already solved them.

1) The keygen tool I have written generates keys and will in the future
configure an email client to use them to decrypt mail.

2) Strong email addresses mean that it is easy to use the key since it
combines the fingerprint for verifying the public key and the location at
which to discover it. There is no need for any external infrastructure
except for the ability to publish the public key and policy blob on a Web
site.

3) The Web and .well-known is all we need for this.

If the strong email address is <fingerprint>?[email-masked], then the
public key blob can be found at http://example.com/.well-known/ni/
<fingerprint>

4) Spam, shmam. it really isn't as much as a problem as you might think
since we assume anyone who is going to send encrypted email is going to
have the means to sign it. If we can sign the email we can use their
reputation.

All that end to end encryption defeats is content analysis. Which is no
real loss because spam filtering hasn't relied on content analysis for a
very long time now.

<fingerprint> is the hash of a public key. It is best if this is a long
term key that is used to sign use keys with finite lifespans. This would
normally be an encryption keypair shared across all devices and a signature
keypair per device. The long term master key can also sign a policy
statement that specifies how the keys should be used. The policy can
include statements like 'always send encrypted mail if you can' to 'send
mail encrypted only after specific authorization'.

In the longer term I am expecting that we will establish an infrastructure
for key distribution that combines CA issued trust with peer endorsement
and has strong timestamping. With that infrastructure deployed I can have
policy statements of the form 'encrypted email preferred but only send
encrypted if you have a key older than at least a year.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Dec 2013 22:15:34 -0500

> geeks test...  So the experiment is meaningless.

+1

Basically S/MIME was implemented to gain checklist compliance and little
else. It didn't have to work well, it just had to satisfy the government
procurement requirement. PGP meanwhile suffered from an excess of
ideological commitment.

If we only had one standard it would have been harder for people to ignore
the problems.

I find the defeatism quite depressing. If we know the reason the previous
efforts have failed, all we need to do is to address them and try again.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 04 Dec 2013 02:14:13 -0700

On 12/2/13 10:15 AM, Mary Barnes wrote:
> We had a videocodec bof  @IETF-85 and the WG just never got
> chartered: http://trac.tools.ietf.org/bof/trac/wiki/BofIETF85.
> Perhaps the ADs can fill in the gap as to why that didn't happen as
> I'm not sure whether a ball was dropped or there was a reason not
> to charter.

Yes, it would be helpful to hear from the ADs about that.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Jari Arkko <[email-masked]>
Date: Wed, 4 Dec 2013 11:16:04 +0200

> I find the defeatism quite depressing. If we know the reason the previous efforts have failed, all we need to do is to address them and try again. 

FWIW, I agree with this. We should not believe we can make all projects succeed. Or that without a deep understanding of a field we can succeed. Or that we can succeed without understanding and getting the support of the world around us. But the Internet is evolving, the users have real needs and when we know what to do we should do it - you can succeed even in difficult situations.

And now back to your regularly scheduled RTCWeb discussion… (and I'm not claiming that I at least know what to do in the RTCWeb case.)

Jari

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 4 Dec 2013 11:20:02 +0200

Hi,

yes, we are monitoring this effort. The reason why it has not been
chartered yet is a lack of cycles in the main proponents, who are
fairly busy contributing to other aspects of RTCWeb (among other
things). Richard is the responsible AD for this effort.

Cheers,

Gonzalo

On 04/12/2013 11:14 AM, Peter Saint-Andre wrote:
>> Perhaps the ADs can fill in the gap as to why that didn't happen
>> as I'm not sure whether a ball was dropped or there was a reason
>> not to charter.
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 4 Dec 2013 07:32:36 -0500

Gonzalo has captured this accurately.  We have been keeping in touch with
the folks that had been driving things, back at the BoF stage.  Currently,
my understanding is that things are in a holding pattern.

Of course, if there's someone else who wants to take the lead on moving a
charter forward (and probably having a second BoF), please feel free to
contact Gonzalo or me.

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 Dec 2013 11:10:57 -0500

On Wed, Dec 4, 2013 at 4:16 AM, Jari Arkko <[email-masked]> wrote:

>
> > I find the defeatism quite depressing. If we know the reason the
> previous efforts have failed, all we need to do is to address them and try
> again.
>
> FWIW, I agree with this. We should not believe we can make all projects
> succeed. Or that without a deep understanding of a field we can succeed. Or
> that we can succeed without understanding and getting the support of the
> world around us. But the Internet is evolving, the users have real needs
> and when we know what to do we should do it - you can succeed even in
> difficult situations.
>

I agree except on the requirement for 'deep understanding'.

The only way that deep understanding can be reached in many of these cases
is to try repeatedly and learn from the failures. Or to be willing to 'make
a fool of yourself' by making a statement that might turn out to be false
or incomplete.

People who are worried about making a fool of themselves don't write crypto
protocols. It takes an enormous quantity of ignorance or ego or both to
propose a network crypto protocol. The chances are that someone will take
your beautiful creation and smash it up in front of your eyes and then
dance on all the little pieces.

In particular, I don't think the lectures of the form, 'who are we to
attempt this' are helpful in the slightest. But we always get one from at
least one of two individuals whenever we attempt something new. I don't
think we should abandon hope on S/MIME quite yet but I am quite ready to
dump SMTP just to be rid of the 'you are not worthy' lectures.

Nobody understands this stuff completely. There is no cavalry ready to ride
in with the answers. The academic field of security usability is not yet an
engineering field, it is barely managing to do science.

There are three inescapable lessons of Snowdonia:

1) The insider threat can bring down any organization.

2) Security controls that are too difficult to be used will not be used
even in the most security sensitive organizations.

3) We need usable data level security protections now.

I would certainly encourage people to read the security usability
literature just as I encourage people to read on semiotics, hermeneutics
and many other sources that are outside the narrow field of network
engineering. But don't expect those sources to provide the answers because
they won't. All that you can expect from deeper understanding is to perhaps
ask better questions.
-- 
Website: http://hallambaker.com/

---

From: David Singer <[email-masked]>
Date: Tue, 03 Dec 2013 17:25:24 -0800

> offers inter picture prediction on top of that.

That may be true, but everyone has a JPEG implementation, its status is clear, and it does convey pictures.  The RTP carriage is trivial, error resilience is excellent (all I pictures).  Yes, you get low frame rates or small pictures, but it’s a fallback.

Motion JPEG is not as bad a choice as all that.  Anyone could implement it, and we could terminate this endless discussion with a decision that could, in fact, be respected by implementations.

I still doubt whether people would consider it worthwhile spending engineer time and so on, on developing an H.261 solution, whereas JPEG (as a codec) is still in heavy use elsewhere.

Nonetheless, I still think H.263 deserves a more careful look.  I know Stephan is negative, but so far, he’s the only one.  For those who DON’T currently implement H.263, could/would you?

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 6 Dec 2013 14:44:01 +0000

On Dec 4, 2013, at 5:32 AM, Richard Barnes <[email-masked]> wrote:

> Gonzalo has captured this accurately.  We have been keeping in touch with the folks that had been driving things, back at the BoF stage.  Currently, my understanding is that things are in a holding pattern.  
> 
> Of course, if there's someone else who wants to take the lead on moving a charter forward (and probably having a second BoF), please feel free to contact Gonzalo or me. 
> 

And also ask the folks the Google folks that did VP8 if they are willing to do a video codec at IETF (currently Google is pursing standardization at MPEG which would be a good thing for VP8) and if they will give IETF change control. (AFAIC the answer when last asked was No). Ditto for the folks that did H.265. (Again AFAIC, answer is No). In the meantime, if you want to actually contribute to the research of figuring out how to design an IPR free video codec, go help the Daala guys. It's an excellent project at an early research stage and so far is the only concrete proposal that has been put forward of what might form input to an IETF video codec WG.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 06 Dec 2013 15:49:54 -0800

Cullen Jennings (fluffy) wrote:
>> Of course, if there's someone else who wants to take the lead on
>> moving a charter forward (and probably having a second BoF),
>> please feel free to contact Gonzalo or me.

I'm happy to take the lead on this. I guess the big question is who else 
is willing to help out here? If we want to organize a BoF, we have 
barely a month to get a proposal in.

> standardization at MPEG which would be a good thing for VP8) and if
> they will give IETF change control. (AFAIC the answer when last
> asked was No). Ditto for the folks that did H.265. (Again AFAIC,

I agree the answer is going to be no for VP8 and VP9, as those formats 
have been frozen. It still may be possible to get Google to contribute 
techniques from those codecs that they have patented under good terms to 
a (next-)next-generation format like we would be trying to design.

> answer is No). In the meantime, if you want to actually contribute
> to the research of figuring out how to design an IPR free video
> codec, go help the Daala guys. It's an excellent project at an
> early research stage and so far is the only concrete proposal that
> has been put forward of what might form input to an IETF video
> codec WG.

Thanks for the plug. We'd definitely appreciate any help.