Subject: Re: [rtcweb] non-standard codecs

From: Bernard Aboba <[email-masked]>
Date: Mon, 30 Jul 2012 06:57:46 -0700

There are several reasons why it would be imprudent to seriously consider a non-standard codec as mandatory-to-implement:

A. Change control. Normatively referencing a document not under IETF change control as mandatory-to-implement means that a core aspect of the standard would be subject to change without IETF review.

B. FRAND status. SDO IPR policies (and legal precedents) confer important benefits to documents that have gone through a standards process. Without this, potential IPR claims have no upper bound.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 30 Jul 2012 08:05:30 -0700

> A. Change control. Normatively referencing a document not under IETF change control as mandatory-to-implement means that a core aspect of the standard would be subject to change without IETF review.
The last point is also true for any standard maintained by another 
standards body, but we tend to trust that those will not change arbitrarily.
> B. FRAND status. SDO IPR policies (and legal precedents) confer important benefits to documents that have gone through a standards process. Without this, potential IPR claims have no upper bound.
To be precise, the SDO IPR policies confer important benefits in 
relation to the companies or individuals that were part of that SDO at 
the time of the standardization procedure.
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 30 Jul 2012 17:07:45 +0200

There are several things here in this mail that many other standards organizations would find objectionable, if the statement "not under IETF change control" is meant to apply to anything not produced by IETF. 

There is nothing special about an RFC or indeed IETF in this respect.

1)	The drafting rules for all standards organizations I know of make provision for references to be of two types, of a reference to a specific version or publication date, or of a reference to a more generic standard number. As a result of this, prior versions of standards continue to be available, sometimes with a better history of preservation that some of the earlier IETF RFCs.

Therefore if IETF makes a reference to one of these specific versions, they have complete control over change. They can either decide to update the reference at some point in the future or decide not to. It is the reference that provides the change control, not the referenced document.

This is exactly the same process they will have to go through if a referenced RFC gets updated with improvements or corrections. The later version of an RFC does not automatically apply.

2)	While the IPR disclosure rules for IETF may be worded differently, they are in general no different to any other standards organizations. IETF rules do not guarantee FRAND availability, nor do those of any other standards organizations.

IETF in making the reference needs to identity any known IPR and decide whether that is a barrier to progressing the RFC with that reference or not. It has to do that whether it is an IETF reference or a reference elsewhere.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Bernard Aboba
> Sent: 30 July 2012 14:58
> To: [email-masked]
> Subject: Re: [rtcweb] non-standard codecs
> 
> There are several reasons why it would be imprudent to seriously consider
> a non-standard codec as mandatory-to-implement:
> 
> A. Change control. Normatively referencing a document not under IETF
> change control as mandatory-to-implement means that a core aspect of the
> standard would be subject to change without IETF review.
> 
> B. FRAND status. SDO IPR policies (and legal precedents) confer important
> benefits to documents that have gone through a standards process. Without
> this, potential IPR claims have no upper bound.

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 30 Jul 2012 16:27:49 +0000

Hi Harald,

On 7.30.2012 08:05 , "Harald Alvestrand" <[email-masked]> wrote:

>>
>> B. FRAND status. SDO IPR policies (and legal precedents) confer
>>important benefits to documents that have gone through a standards
>>process. Without this, potential IPR claims have no upper bound.

I would go even further: most SDO IPR policies confer important benefits
in relation to patents and patent applications under control of a member
of the SDO at the time of the standardization procedure.

(It's, I believe, generally assumed now that FRAND commitments travel with
the patent, just like a license.   Meaning that a troll cannot expect
non-FRAND licensing terms for a patent that, at some point in time, was
owned by a legit SDO member.  Many SDOs have updated their policy
documents to ensure this, and there is also case law addressing this
issue.)

It's also worth noting that in video coding, most major industry players
are actively involved in the FRAND-bearing standardization effort.  That
doesn't mean that there can't be any non-FRAND pledged patents reading on
a video coding standard, but the likelihood is low compared to other areas
of technology.

All that doesn't help the open source industry, but it helps the rest of
us.

Stephan

---

From: Silvia Pfeiffer <[email-masked]>
Date: Tue, 31 Jul 2012 07:54:06 +1000

I assume this is a discussion about VP8. :-)

> A. Change control. Normatively referencing a document not under IETF change control as mandatory-to-implement means that a core aspect of the standard would be subject to change without IETF review.

How about this one? http://tools.ietf.org/html/rfc6386

It's an IETF document and therefore not subject to change without IETF review.

> B. FRAND status. SDO IPR policies (and legal precedents) confer important benefits to documents that have gone through a standards process. Without this, potential IPR claims have no upper bound.

MPEG-LA has been working on its patent pool for VP8 for more than 18
months now [1] - does anyone know when this will conclude?

[1] http://www.mpegla.com/main/pid/vp8/default.aspx

Regards,
Silvia.

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 30 Jul 2012 22:08:13 +0000

Hi Silvia,

>It's an IETF document and therefore not subject to change without IETF

While an RFC is static, this RFC is NOT an IETF document.  It's the end
result of an independent submission to the RFC editor.  It's not an IETF
product, and it's not under IETF "change control".  Btw., wikipedia got
that doc status wrong as well; you are not alone :-)

>[1] http://www.mpegla.com/main/pid/vp8/default.aspx

Those who know are not allow to talk about it.

Regards,
Stephan

---

From: Silvia Pfeiffer <[email-masked]>
Date: Tue, 31 Jul 2012 08:18:51 +1000

> that doc status wrong as well; you are not alone :-)

Oh, I'm fully aware of the informal state of this document. However,
IETF still has change control - they can still stop any further
submissions / updates of that document. After all, they are the
publisher.

While it's not a document that was created by an IETF group, it's
still a specification document with fixed content.

It would be possible to re-do this document through a working group
with group input and going through the formal IETF process. Maybe that
is something that this WG should consider doing.

> Those who know are not allow to talk about it.

What a shame! Let's hope it's soon so we get some clarification.

Cheers,
Silvia.

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 30 Jul 2012 23:01:44 +0000

Hi Silvia,

>submissions / updates of that document. After all, they are the

It's an independent submission to the RFC editor, and not an IETF
document.  This page explains what those independent submissions are:
http://www.rfc-editor.org/indsubs.html
It is not an IETF document, and the IETF has no change control.  The IETF
cannot stop any further submissions or updates unless the IESG finds that
the doc is harmful to the Internet, and AFAIK, the IETF is not the
publisher of the doc.

>still a specification document with fixed content.

Fixed content, yes.  Spec doc: depends on whom you ask :-)

Stephan

---

From: Silvia Pfeiffer <[email-masked]>
Date: Tue, 31 Jul 2012 11:18:25 +1000

> the doc is harmful to the Internet, and AFAIK, the IETF is not the

Depends on what you understand by "the IETF". The RFC editor and the
IESG can stop it and they are part of IETF processes.

Also, the document is published on a ietf.org domain and has the
following copyright statement:
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors.  All rights reserved.
As I read it, the IETF is the publisher for all intents and purposes.

Regards,
Silvia.