Subject: [codec] Last Call: <draft-ietf-codec-guidelines-05.txt> (Guidelines for the Codec Development Within the IETF) to Informational RFC

From: The IESG <[email-masked]>
Date: Wed, 05 Oct 2011 09:12:47 -0700

The IESG has received a request from the Internet Wideband Audio Codec WG
(codec) to consider the following document:
- 'Guidelines for the Codec Development Within the IETF'
  <draft-ietf-codec-guidelines-05.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2011-10-19. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document provides general guidelines for work on developing and
   specifying a codec within the IETF.  These guidelines cover the
   development process, evaluation, requirements conformance, and
   intellectual property issues.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-codec-guidelines/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-codec-guidelines/

No IPR declarations have been submitted directly on this I-D.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 5 Oct 2011 16:25:29 -0400

I have some issues with the way that the section on IPR is written.
While I agree with most of the statements there. I don't see my two
biggest IPR concerns listed.

1) Specific to this document, we already have unencumbered CODECs that
permit encoding of audio and video with acceptable fidelity and
adequate compression for 95% of all purposes. Thus it is essential
that the IPR regime for any future CODEC strictly limits the cost of
using that technique to some portion of the cost savings from
reduction in bandwidth use.

2) The principal concern I have with IPR licensing in general is not
the cost of licensing but the difficulty of licensing. I have on
several occasions been in negotiations with an IPR holder who is
completely unable to decide how much money they want or on what terms
they are willing to offer their IPR.

3) Linked to that is the problem of uncertainty. A purported rights
holder can only grant a license for the rights they hold, they cannot
and will not provide a warranty with respect to any other rights.
While due to the lingering effects of submarine patents it is
impossible to know if any CODEC is completely unencumbered, it is a
very safe bet that the audio codecs used for cinema sound in the mid
1980s are now unencumbered. It is not possible to be confident that
any new audio codec is unencumbered.

Taken in combination, I cannot imagine any reason to use any audio
codec other than MP3 or AC2 (or some other similar legacy scheme) once
we can be assured that the corresponding patents have expired. I
really could not care less what fidelity or other benefits might be
claimed for them. Bandwidth and storage are much cheaper than the
financial benefits offered by the technology held by the rights
holders.

The situation is very slightly different for video codecs, but not by
a great deal.

So the overall experience has been that it is like trying to negotiate
the purchase of some fancy-schmancy kitchen cabinets from some guy who
hasn't a clue about business but is desperate to make sure that they
don't leave a penny on the table even if his dithering about is likely
to cost him the business. Meanwhile you can get a perfectly
serviceable set of cabinets from Home Depot and Lowes where they will
give you price on the page ordering. In this case there is a free
alternative in almost every application worth bothering about.

On Wed, Oct 5, 2011 at 12:12 PM, The IESG <[email-masked]> wrote:
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

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

---

From: Ralph Giles <[email-masked]>
Date: Wed, 5 Oct 2011 14:44:32 -0700

On 5 October 2011 13:25, Phillip Hallam-Baker <[email-masked]> wrote:

> we can be assured that the corresponding patents have expired.

I'm not familiar with AC2, but if you mean traditional audio codecs
like MP3, AC3, and Vorbis, these all have a high encoding (and
decoding) latency which makes them unsuitable for interactive
applications.

Addressing that, as much as the (almost 4-fold!) bandwidth reduction
over legacy codecs, is what we're trying achieve with this working
group. This is reflected in the requirements document published as RFC
6366 where low coding latency is a primary attribute of each use case.

That doesn't have much to do with your comments on the other IPR
issues, but I hope it explains why we can't just use mp3.

Separately, mp3 is in fact still covered by patents, at least
according to wikipedia[2], so that is not an IPR free solution for
some years yet, even if it were technically suitable.

 -r

[1] http://tools.ietf.org/html/rfc6366
[2] http://en.wikipedia.org/wiki/MP3#Licensing_and_patent_issues

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 05 Oct 2011 15:16:18 -0700

Phillip,
Please see inline. 

>reduction in bandwidth use.

I disagree for technical reasons that have already been pointed out by
others.  I would also suggest that something like AAC, according to your
theory, should have never happened (as it covers essentially the same
application space as MP3, with moderate gains in the quality/bitrate
tradeoff), but it a) was standardized--in the same body as MP3, and b) was
and is a commercial success, despite being quite expensive.

>they are willing to offer their IPR.

The IETF is certainly not in the business of regulating how licensing
discussions are to be arranged :-)  (Never mind that they can be quite
frustrating, as, apparently, both of us know).

>any new audio codec is unencumbered.

All what you write above is true.

>we can be assured that the corresponding patents have expired.

Well, many folks actually do license, under sometimes expensive terms,
protected technology, and use them to their benefit.

>I

That your position.  It's a position many of the opus proponents would
probably share, even if you were broadening the technical features to
include other alleged goodies of "opus".  However, it's not the only
reasonable position.  Depending on your business model, and the business
model of the rights holders, there are many situations where picking a
licensing, and paying for it, is to the advantage of a rights taker.

>alternative in almost every application worth bothering about.

Your email ends here.  Now I'm at loss.

Is your position that
A) the section on IPR be modified with an explanation of the commercial
constraints you have described,
B) the section be modified to gate the issue of an RFC defining an IETF
codec on terms compatible with YOUR commercial constraints you have
described, or
C) something else?

If your choice is B), would you care describing how your request is
supported by the IETF's patent policy?

Stephan

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 5 Oct 2011 21:41:16 -0400

> and is a commercial success, despite being quite expensive.

I said that adopting a new encumbered algorithm would be stupid. At no
time did I say that stupid did not happen. For evidence to the
contrary see Planet:Earth

Frequently IPR holders will attempt to prolong the validity of their
patents by making minor tweaks of dubious technical value.

What I said was that if any new CODEC is going to be accepted, the
cost of using that CODEC must be strictly limited to the value that is
provided in terms of limiting the number of bits required. In other
words, I do not want to be paying for the patent that enables me to do
Internet telephony since that can be achieved quite acceptably with no
compression whatsoever. I may be willing to pay $X for a patent that
allows savings significantly greater than $X.

Unfortunately the current draft seems to me to be saying 'free is good
but we might have to pay'. I think the presumption should be that
there will be no payment for this particular application for reasons
that go beyond the general preference for free.

> frustrating, as, apparently, both of us know).

Again, mu law is seriously out of patent. No conversations with wolves
or lawyers required.

> protected technology, and use them to their benefit.

MP3 became the standard for audio because it was the only widely
supported option. Dolby Digital offered somewhat better fidelity and
multi-tracks.

But those technologies are close to twenty years old and the patents
should be nearing expiry or have already expired.

> codec on terms compatible with YOUR commercial constraints you have

I was arguing for A.

If we are talking about IPR we are inevitably talking about commercial
terms. I would like IPR holders in this space to understand that this
is not going to be the normal patent beauty contest that has been the
norm in this space for the past 20 odd years.

I am quite aware of the licensing schemes employed in the MPEG world
and really don't have much good to say about it.

---

From: Gregory Maxwell <[email-masked]>
Date: Wed, 5 Oct 2011 22:03:22 -0700

Phillip Hallam-Baker [[email-masked]]:
[snip]
> that go beyond the general preference for free.

I believe you're reading meaning into the draft that isn't there.

To my eyes the draft affirms and elaborates on the kind of trade-offs
your mentioning here— that it acknowledges that RF status plays
an important role in actually getting a codec adopted on the Internet.

It then leaves it to the working group participants to drive for a solution
that meets their needs on an overall basis: If the working group is
going in a direction that doesn't meet your needs then propose fixes.

draft-ietf-codec-guidelines-05.txt - section 5 states:
>Therefore, a codec that can be widely implemented and easily
>distributed among application developers, service operators, and end
>users is preferred.[...]Because such encumbrances have made it difficult to
>widely implement and easily distribute high-quality codecs across the
>entire Internet community, the working group prefers unencumbered
>technologies in a way that is consistent with BCP 78 and BCP 79.  In
>particular, the working group shall heed the preference stated in BCP
>79: "In general, IETF working groups prefer technologies with no
>known IPR claims or, for technologies with claims against them, an
>offer of royalty-free licensing."  Although this preference cannot
>guarantee that the working group will produce an unencumbered codec,
>the working group shall follow BCP 79, and adhere to the spirit of
>BCP 79.  The working group cannot explicitly rule out the possibility
>of adopting encumbered technologies; however, the working group will
>try to avoid encumbered technologies that require royalties or other
>encumbrances that would prevent such technologies from being easy to
>redistribute and use.

I might have liked it better if we could have drafted different language
or wrote into the charter different requirements, but there are practical,
political, and legal complications with writing hard requirements related
to IPR.

You already raised the practical point:

Practically, we have the issue that non-infringement is non-computable.

It is generally uneconomical to convince someone that it is _proven_
that something is absent any possible infringement, especially if they
benefit from being unconvinced.  (Though submarine patents don't exist
anymore, fwiw)   This means that any requirement would always require
the execution of judgment:  "based on what you know, will the result
meet your needs?"   Anything that was a harder rule than that would
be highly vulnerable to sabotage by parties with conflicting interests.

You can't even say that _old_ technology is okay with complete certainty,
because new (and from your perspective) trivial applications of old tech
can be patentable.  Also, patents are presumed to be valid so if someone
manages to get a patent on something old through the system (which
appears to be pretty easy to do) you still have a large burden to get
the patent invalidated— for many business models, OSS developers,
etc. even the most frivolous of patent litigation is just as deadly as
the most solid.   Likewise, for many parties the interesting IPR risk isn't 
the cost of losing, it's the cost of having the fight.

Certainly using older techniques is persuasive, has a large benefit
in terms of practical IPR attack resistance, and is a technique used
in the development of the codec draft. But it is not _proof_.

Politically, the subject of IPR requirements in the IETF is a complicated
one with a long history.  While some would love to continue the debate
about IETF policy in yet another forum— but the people gathered here
actually want to address a codec need, rehashing IETF IPR policy is
not a good way to get actual work done.  The IETF IPR policy doesn't
actually or in practice prohibit royalty free work even when it fails to
mandate it, which is sufficient for actually getting the work done.

Legally, it's believed by some that it would actually be unlawful for
the working group to have a hard royalty free requirement. I, personally,
think this is an unreasonable concern in this context where we have
the actual developers of codecs who prefer RF (and who will happily
and aggressively remove, design around, etc any IPR they become
aware of which can't be made available RF).  But it's an earnestly
held concern, and a law breaking working group isn't something anyone
would want to be involved in.

So the language in the guidelines (and the approved WG charter)
is a best effort attempt to navigate around those issues.  Part of
the compromise is that it leaves open some of what I (and probably
you) would consider failure modes.   Realistically, I think if we
were to fail that way we couldn't have been successful regardless
of the language in the guidelines. ("The working group is not
permitted to fail" would be a lovely but sadly unrealistic rule too :) )

Most importantly it replaces the highly political IPR issue with one
that we're more competent to deal with here:   As practitioners
of internet technology the people around the WG and the IETF
have far more expertise about what people will and won't deploy
on the internet then we have about the nuanced legal technicalities.
And by stating our requirement in terms of a consensus about
the practical usability also addressing what matters most.

If I've horribly misunderstood your position it may be helpful to me
to drill it down to the specific language in the draft that is
the source of the contention and attach specific examples about
how that language will lead to outcomes which are not productive
for the internet community.

Cheers,