Subject: [codec] [Fwd: I-D Action:draft-valin-codec-guidelines-00.txt]

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 04 Sep 2009 12:40:28 -0600

FYI.

/psa

- -------- Original Message --------
Subject: I-D Action:draft-valin-codec-guidelines-00.txt
Date: Fri,  4 Sep 2009 11:00:01 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Guidelines for proposed CODEC working group
	Author(s)       : J. Valin, et al.
	Filename        : draft-valin-codec-guidelines-00.txt
	Pages           : 17
	Date            : 2009-09-04

This document provides general guidelines for specifying audio codecs
within the IETF.  These guidelines cover the development process, as
well as the evaluation and intellectual property issues.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-valin-codec-guidelines-00.txt

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 04 Sep 2009 21:41:11 -0400

Folks,
I read through this draft and found it, all in all, a well written document
covering a lot of (to me) agreeable aspects.  However, as you may expect, I
have a number of comments, mostly on certain language aspects :-)  If this
were a working group effort, I would phrase some of my suggestion below in
stronger terms.  As things stand, you are, of course, free to ignore them...
Regards,
Stephan

1. Section 1 speaks in several places of "freely available".  I would
recommend to be more precise.  There are just too many definitions, some of
which contradicting, of what constitutes "freedom" in our business.
2. Section 1: the above remark also goes for the definition of "open".  A
very large part of the standardization people (perhaps a majority)
associates "open" exclusively with "open process in the SDO" and not with
what the draft implicitly assumes ("open" use, whatever that, in turn, may
be).
3. Section 1, first bullet, "has inhibited": really?  I don't believe this
claim is true---certainly not in the form as made.  At least, I have not
seen a prove for this rather assertive statement.  Suggest softening the
language.
4. Section 1, final bullet: suggest replacing "will be freely available"
with "may be available without royalties or other undue burden", as none of
us has the means to guaranty something like "freely available".

5. Section 2.2, "preferably in the form of I-Ds".  I'm not aware of any
other form of input but I-Ds on which a WG or a group of people without WG
status in the IETF could act on (and that would allow documenting the
complexity undoubtly involved).  Therefore, I would suggest to remove
"preferably".  Also, publishing an I-D undoubtly triggers the BCP79
disclosure requirements---unspecified input may not.
6. Section 2.3: I read this section as a license to re-tune the requirements
document based on results obtained by tests (or even theoretical analysis)
of input proposals.  It may be necessary to do this.  However, you are
certainly aware of that such a procedure can lead to gaming and other evil
things (including unfair exclusion of proposals with IPR properties that are
within the scope of the IETF's IPR policy).  If this were a working group
charter, I would voice strong concerns over this vagueness.  For an informal
activity outside a WG, I only appeal to you to be careful in what you are
doing.
7. Section 2.6: to add something positive, I'm thrilled that people will at
least attempt to work cooperatively on codecs from very early on: this is
IMHO one of the really weak spots traditional codec standardization has had
in most of its instances.  I'm also very happy to see the "no
rubberstamping" sentence.
8. Section 2.7: developments of RTP payload formats happen in AVT.  No need
to word around that.
9. Section 3: I'm missing a statement on what happens if it turns out that
the requirements are NOT met.  I think there should be an end criteria of
some sort.
10: I can see value in a strategy of not requiring a bit-exact encoder (as I
see a value in having such a requirement---in classic telco applications,
for example).  However, I fail to see a value in not requiring bit-exact
decoding.  Is this a fixed/floating point issue?
The can of worms one the IPR side one is opening by not strictly defining
conformance cannot be overestimated.  Almost every IPR statement in the IETF
(and elsewhere) promises or grants licenses (or makes a non-assert covenant)
only for conformant implementations.  I would strongly recommend to require
bit-exact decoding, for that reason alone.  If you truly think that a soft
definition of conformance is necessary from a technical viewpoint, then I
would strongly recommend to at least define your version of conformance in a
normative, permanent document (standard's track RFC) which includes the
source code of the testing tool, and the test vectors against which soft
conformance is tested.
11: Section 5, first bullet, "open", see remark #2
12: Section 5, first bullet, "conspicuous gap", see remark #3
13: Section 5, second bullet "freely", see remark #1
14: Section 5, fourth bullet, "free" , see remark #1
15: Section 5, "BSD license": it's not a BSD license.  It's *currently* a
BSD-style license.  However, the IETF trust currently has control over this
thing and could, in theory, change it.  Recommend to read the relevant
documents and come up with a precise and future-proof formulation.  At this
time of writing I do not have access to the documents in question (writing
on a plane), but I can help in this.
16: Section 5, "royalty-free".  Finally, this reasonably precise term is
used.  Why not earlier?  However, just before that, the subject of open
source compatibility is mentioned as well (though not in this formulation).
Please note that it is very easy to draft a patent license that is
royalty-free and NOT open source compatible.  Similarly, I would argue that
a good percentage of the RF licensing covenants in IETF IPR disclosures (in
contrast to most non-assert covenants) are not compatible with the majority
of the open source licenses in practical use.  If you wish to express a
desire for compatibility with open source models, then you may want to
express this early on, in precise terms, and not with ambiguous language
such as "free" and "open".
17: Section 5, "20 years": as I have mentioned a number of times before: a
novel combination of 20year+ old tools may be patentable in its own right.
You may wish to add a sentence in this regard.
18: "infringing": it is in most cases unwise to use the term "infringement"
unless you truly know what you are doing---even in combination with
"unknowingly".  Suggest to replace "infringe" with "incur encumbrance" or
something like this.
19: Section 6: I would suggest to remove this section in its entirety.  Some
information presented may be seen differently in the cited SDOs.  For
example, arguably, the low delay AAC effort is intended towards interactive
work, and not storage.  Also, there may be SDOs not mentioned here which
have (or have had) viable speech/audio coding efforts that may feel insulted
by not being mentioned (3GPP2 come to mind, and some others).  As the very
minimum, I would strongly suggest to "characterize" the other SDOs efforts
using only their own (liaison-)statements or publications as a basis, and
not your interpretation.

On 9/4/09 2:40 PM, "Peter Saint-Andre" <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> FYI.
> 
> /psa
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkqhXxwACgkQNL8k5A2w/vw3KQCbBDmV7SZPXLaiHIDKN4UW1sZO
> ZssAoJMDkNDNGGOXXscj4PoaB0HFWhtG
> =Al+W
> -----END PGP SIGNATURE-----
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 5 Sep 2009 07:05:44 -0400

> disclosure requirements---unspecified input may not.

There is no way to publish an IETF stream RFC without beginning as an  
Internet-draft and
without the contributors agreeing to the IETF IPR rules. This is true  
of AD sponsored drafts
as well as WG sponsored drafts. The disclosure rules definitely apply  
to all IETF contributions.

> thing and could, in theory, change it.

That is correct. Of course, licenses are granted to published text. I  
am not a lawyer, but my understanding is that these licenses, once  
granted, could not be made more restrictive retroactively.

>  Recommend to read the relevant

BCP 78 and 79 apply to IETF contributions and IETF publications. Note  
that IETF licenses
explicitly and only refer to copyright, not patent - RFC5378 :

5.5. No Patent License The licenses granted in Section 5.3 shall not  
be deemed to grant any right under any patent, patent application, or  
other similar intellectual property right disclosed by the Contributor  
under BCP 79 [RFC3979] or otherwise.
---
So, in the statement :
In accordance with BCP 78 [RFC5378], the source code for the reference  
implementation should be available under the BSD license.
I would take out "In accordance with BCP 78 [RFC5378],". If the  
reference implementation is published in an RFC, then IETF IPR rules  
will apply. If it is not, they will not.
Regards
Marshall