Subject: [codec] WGLC of draft-ietf-codec-opus-07

From: Cullen Jennings <[email-masked]>
Date: Fri, 8 Jul 2011 21:38:22 -0600

The authors believe the draft is pretty much done other than editorial stuff so we would like to initiate a working group last call on draft-ietf-codec-opus-07 to help gather any remaining issues. 

The draft can be found at  http://www.ietf.org/id/draft-ietf-codec-opus-07.txt

I would like to note that even if no issues are raised during this WGLC, the chairs will delay requesting publication at the end of the WGLC to make sure there is time for appropriate communications with other SDOs. 

Please send comment by the end of the day on July 23. 

Thank you, Cullen & Jonathan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 20 Jul 2011 07:02:59 -0400

A reminder that there are three days remaining in this working group 
last call.

Please send comments by the end of day on July 23.

Thanks,
Jonathan R.

On 7/8/2011 11:38 PM, Cullen Jennings wrote:
> Thank you, Cullen&  Jonathan
>
>

-- 
Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
Skype Chief Technology Strategist
[email-masked]                              http://www.skype.com
[email-masked]                            http://www.jdrosen.net

---

From: Jehan Pagès <[email-masked]>
Date: Fri, 22 Jul 2011 03:27:54 +0900

Hi,

I know that we are not supposed to discuss patents issues on this list
(according to an email on 25th of May by Cullen Jennings).
But considering that Opus is closing last call, and I have no idea
where else I could get the information (Cullen's email mentioned
possibility of creating a new list for this, but it seems it never get
created, or else not announced here), I am sorry by advance for
asking. But what is the status of the IPR claims of patents which were
issued on previous drafts?
Thanks.

Jehan

On Wed, Jul 20, 2011 at 8:02 PM, Jonathan Rosenberg <[email-masked]> wrote:
> A reminder that there are three days remaining in this working group last
> call.
>
>> The authors believe the draft is pretty much done other than editorial
>> stuff so we would like to initiate a working group last call on
>> draft-ietf-codec-opus-07 to help gather any remaining issues.
>>
>> The draft can be found at
>>  http://www.ietf.org/id/draft-ietf-codec-opus-07.txt
>>
>> I would like to note that even if no issues are raised during this WGLC,
>> the chairs will delay requesting publication at the end of the WGLC to make
>> sure there is time for appropriate communications with other SDOs.
>>
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 21 Jul 2011 20:39:11 -0600

[no hats]

> issued on previous drafts?

Hi Jehan,

As I understand it (IANAL etc.), in general the IETF and its working 
groups do not take any official position on the validity or 
appropriateness of IPR claims made with regard to IETF specifications 
(including Internet-Drafts under discussion by a working group), nor on 
the licensing terms associated with such IPR claims.

According to IETF rules, individuals who are aware of IPR claims related 
to work in which they are participating (e.g., as document editors or 
list discussants) are required to state that they are aware of the 
existence of such claims (which might even be claims made by third 
parties not involved in the work) -- not necessarily to disclose the 
nature of the IPR itself, but at least to state awareness of the 
existence of such claims.

Also according to IETF rules, the working group chairs are required to 
make the group aware of notifications and disclosures that are submitted 
in relation to the work happening in the group. The purpose of drawing 
this information to the attention of the working group participants is 
to allow each person to make their own determination of the validity of 
the IPR claims, and to assess the license terms that
are presented.

I hope that this message helps to clarify the role of the working group, 
and the responsibilities of each working group participant, in relation 
to IPR claims.

Peter

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

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 21 Jul 2011 23:47:25 -0700

Hi Peter,
I believe you phrased the disclosure obligations a tad to broad:

On 7.21.2011 19:39 , "Peter Saint-Andre" <[email-masked]> wrote:

>[...]

An individual is *required* to disclose "own" IPR against "own" drafts and
someone else's drafts the individual is commenting on.  See sections 6.1.1
and 6.1.2 of RFC3979.

The disclosure obligation under 6.1.1 and 6.1.2 against a given document
or contribution is triggered when (amongst others) three conditions are
fulfilled: the individual has "reasonable and personal" knowledge (and not
only a suspicion) that a patent claim applies to a patent, that patent
claim is under control (from an assertion/licensing viewpoint) of the
individual's employer or the individual himself/herself, and the
individual contributes to the document or contribution.  It's quite common
that individuals participate in certain activities of a WG, and do not
trigger a disclosure obligation against other documents of the WG.  For
example, I have personally contributed quite heavily to the operational
practices of the codec WG, but not to the codec specification draft.
Accordingly, I do not have a disclosure obligation against the
specification draft.  In many patent-savvy companies, this feature of the
IETF's patent policy is well understood by the individuals working for
those companies, and exploited to the advantage of the company.

Beyond that, an individual is only *encouraged* to make a third-party
disclosure, i.e. a disclosure related to patent claims not under control
by themselves or their employers.  Section 6.1.3 of RFC3979.  While this
has been done on occasion, it is, AFAIK and IMO, not common practice.  For
example, I work on patent matters for a living and had jobs that included
IPR portfolio management, and therefore had to study the scope of
protection of quite a few patents, quite possibly to the extent that would
pass the "reasonable and personal" knowledge test.  However, I have never
made a third party disclosure.

There are certain legal risks, as well as (sometimes) economical
disadvantages associated with third party disclosures. OTOH, sometimes
there are also economical advantages in making a third party disclosure,
that can outweigh the legal risk.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 22 Jul 2011 06:56:57 -0700

Christian (CC'd) set up a mailing list for people to discuss the patents. I forget the exact location but perhaps he can send a pointer to the list.

The conversation I want us to avoid is discussing if the IPR is claims are valid or not - it's not a topic the IETF takes on but clearly the IETF does want people to be aware that the claims exist and that people have to make their own decisions about claims. I imagine people feeling about the claims will factor into their opinions about if they think the draft is worth publishing as an RFC or not. Stephan is our IPR advisor for this group so hopefully if I said something wrong here he can correct me - he understands all of this better than I do.

Cullen

> >> Thank you, Cullen&  Jonathan

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Christian Hoene" <[email-masked]>
Date: Sat, 23 Jul 2011 12:07:05 +0200

Hi,

I went through the draft and parts of the source code and it seems that WGLC
is quite too early. 

Some text in the draft is hardly understandable if at all, the source code
has some (minor) bugs, and the codec supports things that should be done in
the payload such as frame and a feature called "padding".

Does anybody beside me review the drafts or the code at all (I mean beside
the authors)?

More emails are to come or shall I use the track again. Hopefully, it would
take a year again to get the issues fixed.

Christian

----------------------------------------------------------------------------
-----
Dr.-Ing. Christian Hoene, University of Tübingen, Computer Science, Chair of
Communication Networks, Research Group Interactive Communication Systems
(ICS)
Sand 13, 72076 Tübingen, Germany, Tel +49 7071 2970532,
www.net.uni-tuebingen.de

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jonathan Rosenberg
> Sent: Wednesday, July 20, 2011 1:03 PM
> To: Cullen Jennings
> Cc: [email-masked]
> Subject: Re: [codec] WGLC of draft-ietf-codec-opus-07
> 
stuff
> so we would like to initiate a working group last call on
draft-ietf-codec-opus-
> 07 to help gather any remaining issues.
> >
the
> chairs will delay requesting publication at the end of the WGLC to make
sure
> there is time for appropriate communications with other SDOs.
> >

---

From: "Christian Hoene" <[email-masked]>
Date: Sun, 24 Jul 2011 03:44:12 +0200

> More emails are to come or shall I use the track again. Hopefully, it
would
[Christian Hoene] not - really not -

---

From: Jehan Pagès <[email-masked]>
Date: Sun, 24 Jul 2011 21:25:34 +0900

Hi,

> The conversation I want us to avoid is discussing if the IPR is claims are valid or not - it's not a topic the IETF takes on but clearly the IETF does want people to be aware that the claims exist…

I understand that IETF does not want to take a position. But for
individuals (like I), it is hard to make one's "own decision" on the
patents topic, as it is a pretty difficult subject, especially when
one is not part of a big company with lawyers or patent experts. So
that's had to evaluate any risk here. Hence that's why I am looking
for expertise of knowledgeable people on patents in the IETF's mls.
Anyway I'll see this mailing list that Christian linked me.

Thanks all, for the various answers.

Jehan

---

From: "Christian Hoene" <[email-masked]>
Date: Sun, 24 Jul 2011 16:34:14 +0200

> > The conversation I want us to avoid is discussing if the IPR is claims
are valid
> or not - it's not a topic the IETF takes on but clearly the IETF does want
people
> to be aware that the claims exist and that people have to make their own
> decisions about claims. I imagine people feeling about the claims will
factor
> into their opinions about if they think the draft is worth publishing as
an RFC
> or not. Stephan is our IPR advisor for this group so hopefully if I said
> something wrong here he can correct me - he understands all of this better
> than I do.
> >
> 

[Christian Hoene] After having an open-source codec, we might need to have a
legal analysis about IPR claims that is under creative commons...
Otherwise, the first time cost sof using the codec would still be
substantial (beside cost of IPR risks that will remain anyhow).

CH

---

From: Jehan Pagès <[email-masked]>
Date: Mon, 25 Jul 2011 01:32:22 +0900

Hi,

>> I went through the draft and parts of the source code and it seems that

I skimmed through the draft, mainly because it is a complicated one
and am not really knowledgeable on codecs, especially when it came to
the encoding/decoding part with formulas and complicated algorithms
(thus I read the codec modes part more carefully, but the rest, I
would need dedicated days, that I don't have just now). So pardon me
for giving only very superficial bugs that I noticed. I figure that's
better than nothing.

* Section "3. Codec Modes" (page 11):
« For code 2 packets, the TOC byte is followed by a one or two byte
   sequence indicating the the length of the first frame (marked N1 in
   the figure below), followed by N1 bytes of compressed data for the
   first frame. »
=> there is a "the the" repetition.

* Just below, in the same paragraph:
«
The
   length of the first frame, N1, MUST be no larger than the size of the
   payload remaining after decoding that length for all code 2 packets.
»
=> I am not sure what it means? Aren't we simply telling that the
advertised length must not be larger than the actual length (which
appears logical to be by "definition" of "length")?

* At the beginning of section "4. Opus decoder", the little graph has
a block which says "SILK encoder". I think it was supposed to say
"SILK decoder", no?

>> the payload such as frame and a feature called "padding".

Also probably a stupid question for someone new here, but I wondered:
what is exactly the role of padding? Is there an interest to have a
fixed size of packets on some platform for instance?

>> take a year again to get the issues fixed.

That's all from me. Sorry for not being more helpful.

Jehan

---

From: Jean-Marc Valin <[email-masked]>
Date: Sun, 24 Jul 2011 12:59:03 -0400

Hi Jehan,

Thanks for the feedback. See below.

> => there is a "the the" repetition.

Will fix.

> appears logical to be by "definition" of "length")?

Pretty much. It means that if a packet contains two frames, then the  
first can't be bigger than the packet.

> a block which says "SILK encoder". I think it was supposed to say

Will fix.

> fixed size of packets on some platform for instance?

There's many potential uses. One example is that in some cases, it may  
be desirable to take an existing VBR stream and turn it into a CBR  
stream. For example, this can be done to prevent information leakage  
over SRTP as suggested in  
http://tools.ietf.org/html/draft-perkins-avt-srtp-vbr-audio . Now,  
this could be done via RTP padding *except* that the RTP padding bit  
is not encrypted. So if we wanted to use RTP padding, we'd have to pad  
*every* frame to avoid leaking information. Keep in mind that the  
padding feature is also using a single bit that would otherwise be  
unused.

> That's all from me. Sorry for not being more helpful.

Any review is useful.

Cheers,

       Jean-Marc

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Sun, 24 Jul 2011 10:04:41 -0700

> I skimmed through the draft, mainly because it is a complicated one

Thanks for the review. Any specific feedback is appreciated.

> appears logical to be by "definition" of "length")?

Yes, or equivalently, that the implied length of the second frame in 
that packet cannot be negative. The MUST requirement is mainly to ensure 
that packets which describe such a situation are properly rejected (cf. 
"A receiver MUST NOT process packets which violate these rules as normal 
Opus packets," above).

> fixed size of packets on some platform for instance?

The variation in packet lengths can be used to recover some of the 
information (up to, in low-vocabulary situations, complete spoken 
words), even if the content is encrypted. See the wright08 reference in 
http://tools.ietf.org/html/draft-ietf-codec-requirements-04 or the more 
recent http://www.ieee-security.org/TC/SP2011/PAPERS/2011/paper001.pdf

A padding mechanism ensures that this information leak can be 
eliminated. It is explicitly done at the codec layer because the 
presence and/or size of padding may be visible at the transport layer. 
For example, SRTP does not encrypt the RTP header, meaning that the 
RTP-level padding bit is sent in the clear.

I've addressed your other comments in my local version of the draft. 
I'll make sure those edits make it into the next revision.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 26 Jul 2011 08:41:15 -0400

Thanks for the clarifications. Folks might also want to read RFC 3669
("Guidelines for Working Groups on Intellectual Property Issues"):

https://datatracker.ietf.org/doc/rfc3669/