Subject: Re: [codec] A slimmer specification

From: Erik Norvell <[email-masked]>
Date: Fri, 1 Apr 2011 10:58:00 +0200

Hi Gregory, 

I do not mean to discredit the work being done to reduce the IPR risk and I am glad to hear that this is being considered in the development. I would like to share your confidence that the risk is being managed, but I think the risk increases with the more technology is included. Locating potential patents is not trivial.

I am not asking to discuss specific IPRs, but when it comes to proving that technology is safe one could e.g. reference known technology in public domain.

Best regards,
Erik

> -----Original Message-----
> From: Gregory Maxwell [mailto:[email-masked]] 
> Sent: den 31 mars 2011 15:45
> To: Erik Norvell; [email-masked]
> Subject: RE: A slimmer specification
> 
> Erik Norvell [[email-masked]] wrote:
> > Thank you for the meeting today. Unfortunately the meeting 
> time ran fast and there was not enough time to cover the 
> technical status of Opus. Related to this, I think Stephan 
> Wenger raised an important point in his final slide 
> (http://tools.ietf.org/agenda/80/slides/codec-0.pptx). I see 
> that building a feature-rich codec may be beneficial for the 
> users, but it also comes with the risk of including IPRs. A 
> slimmer specification is safer from an IPR perspective and it 
> should also make the testing effort easier - a matter which 
> was also heavily debated in the meeting.
> 
> > Balancing technology benefit versus IPR risk is difficult. 
> I suggested earlier to test against the baseline codecs as a 
> measure of the benefit, but I admit that this might not be 
> the right tool. However, reducing the IPR risk is important 
> and we need some way to reach this goal.
> 
> 
> Greetings,   
> 
> What causes you to conclude that there hasn't already been 
> substantial effort put into exactly this sort of balance?   
> We've been asked not to discuss specific IPR issues on the 
> list,  so you should not expect to see too much detailed 
> debate on the fine points of this.   The importance of 
> producing a result without IPR problems is clearly stated in 
> the Working Group charter,  and I can say with confidence 
> that for many participants it has been considered an 
> engineering requirement of equal or greater importance to any 
> of the other requirements.
> 
> If you have any specific areas of concern where you believe 
> we could make an improvement I would be interested in hearing 
> about them off the list.
> 
>

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 01 Apr 2011 11:26:50 +0200

Hi,

my remark was targeted towards document structure, and not necessarily to
the codec design itself.  By farming out anything that is not necessary
for interoperability into a companion document, and maintaining a core
document specifying only bitstream and decoder operation, and assuming
(hoping) that companies would reinstate their IPR disclosures based on
this split document structure, we would get a clear picture (from the
rightholders side--which is the only side that matters from an IETF
disclosure viewpoint!) whether a right is unavoidable by any compliant
opus decoder. 

In practice that would mean (at least) two documents:
1. Normative (standards track) document includes a textual description and
a base64 decoder source stripped down to the bare minimum--no error
concealment, and no FEC, for example.
2. Informative (informational) document includes textual description of a
sensible encoder design (namely the one used to perform the requirements
tests), any non-normative decoder-side error control stuff.  Basically
what we have today.

I personally do not believe that even such a step would create a design
that fulfills the desire of the charter (free to practice), but that's
another story.

Stephan

On 3.31.2011 15:45 , "Gregory Maxwell" <[email-masked]> wrote:

>> Thank you for the meeting today. Unfortunately the meeting time ran
>>fast and there was not enough time to cover the technical status of
>>Opus. Related to this, I think Stephan Wenger raised an important point
>>in his final slide
>>(http://tools.ietf.org/agenda/80/slides/codec-0.pptx). I see that
>>building a feature-rich codec may be beneficial for the users, but it
>>also comes with the risk of including IPRs. A slimmer specification is
>>safer from an IPR perspective and it should also make the testing effort
>>easier - a matter which was also heavily debated in the meeting.
>
>> Balancing technology benefit versus IPR risk is difficult. I suggested
>>earlier to test against the baseline codecs as a measure of the benefit,
>>but I admit that this might not be the right tool. However, reducing the
>>IPR risk is important and we need some way to reach this goal.
>
>
>Greetings,   
>
>What causes you to conclude that there hasn't already been substantial
>effort put into exactly this sort of balance?   We've been asked not to
>discuss specific IPR issues on the list,  so you should not expect to see
>too much detailed debate on the fine points of this.   The importance of
>producing a result without IPR problems is clearly stated in the Working
>Group charter,  and I can say with confidence that for many participants
>it has been considered an engineering requirement of equal or greater
>importance to any of the other requirements.
>
>If you have any specific areas of concern where you believe we could make
>an improvement I would be interested in hearing about them off the list.
>
>_______________________________________________
>codec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/codec