Hi Harald,

First, let me remark that I believe you are avoiding a reply to my original comment, and instead open a somewhat new discussion.  My original comment was that asserting that there is no change in the disclosure situation between leaving VP8 as RFC 6386 "as is" versus discussion of VP8 in a WG does not change the obligations by policy.  I concurred, but stated that it will, in practice, swipe in additional contributors that have an obligation by policy to disclose.  I continue to believe that this is true, and have not seen any assertion to the contrary.

With respect to the new topic, disclosure obligation in the rtcweb WG--which merely discusses referencing the VP8 spec, rather than developing it or tinkering with it technically--please see inline.  I hope that my markings are acceptable.

Stephan


From: Harald Alvestrand <harald@alvestrand.no<mailto:harald@alvestrand.no>>
Date: Monday, 4 March, 2013 02:43
To: Stephan Wenger <stewe@stewe.org<mailto:stewe@stewe.org>>
Cc: "rtcweb@ietf.org<mailto:rtcweb@ietf.org>" <rtcweb@ietf.org<mailto:rtcweb@ietf.org>>
Subject: Re: [rtcweb] Input to Video Codec Selection

On 03/03/2013 05:52 PM, Stephan Wenger wrote:
Hi Harald,
Thanks for these candid answers.  I have a few comments, marked in blue and with StW:
Stephan
Speaking with my IETF-amateur-lawyer hat on (and as a former chair of the IPR WG): No, it does not change the rule. The rule depends on whether the technology in question is discussed in the IETF, not on the nature of the contribution. RFC 3979 section 6.1.2 refers to "Contribution", the definition of that term in RFC 3979 section 1 letter j makes it completely explicit that RFC Editor Contributions are covered by the term "Contribution".

---- below here is StW ---

StW; While this answer IMO correctly interprets the language of BCP79, you answer the question IMO to directly.  Therefore, the answer is somewhat misleading in it misses to mention an important point:

The main (sole?) purpose of an IETF WG is to facilitate consensus building, which necessarily involves more than one party, and those contributing to the discussions (belonging to more than one party) have a disclosure obligation.  To which extent there is real discussion and consensus building dependent from draft to draft and WG to WG, but there is at least some.

ISE submissions, like the draft that lead to RFC 6386, OTOH, are almost always NOT the result of a multiparty consensus building process.  Quite commonly, they involved only a small authors' group, often from the same company.  That's the case here.  No technical community input from IETF participants was received in an IETF context, no WG consensus was required, and the IESG "no conflict" statement is also no indication of IETF consensus.

Insofar, almost inevitably, the disclosure obligations for an ISE submission are different in practice.  In this case, it appears that only the authors (and perhaps the IESG members—I'm not clear on this point) had a disclosure obligation.  Which they fulfilled.
/StW


I don't know how much the blue survives, email formatting is still hit-and-miss, but I hope this makes sense still.... this is still from my IETF amateur lawyer perspective, and shouldn't be taken as a Google position in any way.

I've always worked on the assumption that the RFC 3979 disclosure rules applied only when I was part of the discussion - but that it applied to anything brought into the discussion, including RFCs that I had not heard about before.

Up until here, I'm mostly with you.  I'm not sure I would need to disclose just because, during the discussion of draft "foo", someone brought in the idea that RFC "bar" has some relationship with the subject matter discussed.  I would probably see to what extent I need to comment on the *technical* features of "bar" before making a decision.  If I were not to comment on those technical features, I would not disclose; otherwise, I would.


Thus, I don't believe the submission, editing and publication of RFC 6386 triggered a disclosure obligation on anyone except those involved in the submission and editing process

Agreed.

- but I believe that the moment a submission was made to the RTCWEB working group saying "VP8 should be a mandatory to implement codec for RTCWEB", participants who "reasonably and personally" knew of "IPR that is owned directly or indirectly, by the individual or his/her employer or sponsor (if any) or that such persons otherwise have the right to license or assert" (3979 section 6.6) were placed under the obligation of RFC 3979 section 6.1.2 (IPR in the contributions of others).

Perhaps.
Just assuming that your interpretation would hold water in a court, I'm not sure that there would be that much practical difference in terms of numbers of patents that would be held unenforcible due to policy violations through non-disclosure.  The group of people who can competently discuss things like data channel setup or trickle ICE in context of O/A, and the group of people who not only read the VP8 spec (which, I understand, is no-go-territory for quite a few individuals) but also have an understanding of video coding and a fair knowledge of their employer's video coding related patent portfolio, is rather limited.  That is probably why we have not seen all that many IPR disclosures against RFC6386.  Not any perceived or real policy violations.

But also: Perhaps not.
The Contributions folks make in the context of the rtcweb codec selection discussion is targeted towards the rtcweb I-Ds.  There is no IETF precedence that I'm aware of where a disclosure has been made against a spec that merely references an encumbered technology specified in an RFC, like VP8.  To the contrary, AFAIK, WGs like RMT or FECFRAME have been careful to distinguish the encumbered redundancy coding schemes from the non-encubered base spec.  (And these are IETF technologies, not just ISE RFCs—something that ought to be closer to the typical IETF participant's heart than such ISE RFCSs—though I already agreed with you that from a policy viewpoint, RFC is RFC, no matter the stream). The same ought to apply here.  Insofar, a disclosure obligation would be triggered only against the VP8 spec itself.

With respect to that, I don't believe that mere mentioning of essentially political arguments (like performance, commercial environment considerations etc.) in conjunction with a spec triggers a disclosure obligation.  Again, I think I can support this with the common practice in WGs commonly dealing with encumbered technologies, like (previously) AVT (and now) PAYLOAD.  For example, I contributed to the development of the I-D for the VP8 payload spec, knowing that I incur a disclosure obligation against this spec, and honoring that obligation by arranging a disclosure.  I was never asked, nor did I ever have a sense in the room of an expectation, that I would need to disclose what I may know of the VP8 spec itself and/or the relationship of our patent portfolio to it.  Nor did that ever happen in the discussion of other payload specs; see also below.   And that despite of the fact that AVT and PAYLOAD, in the context of discussing the finer features of media codecs, necessarily have to dig deep into some technical features of these codecs, leading to quite technical discussions well beyond those IMO political noise and meta arguments that are visible in rtcweb with respect to codec selection.


(In the same way, I believe the submission saying "H.264 should be a mandatory to implement codec for RTCWEB", detailed in draft-marjou-rtcweb-video-codec among others, triggered a requirement for similar disclosure of IPR in H.264 technology. I believe the chairs earlier stated which draft such IPR claims should be filed against, but I don't have that message in front of me at the moment.)

Here I absolutely disagree.  It would be against the tradition of the IETF to comment about IPR included in specs of other organizations.  I have not seen a single IPR disclosure pertaining to a media codec in the IETF IPR database, although there are tons of references to known-as-encumbered media coding specs in, for example, RTP payload formats; and those specs extensively comment on the technical features of these non-IETF media codec specs.. This is a discussion that, in other fori, is known as the "normative reference discussion": is there a need for a disclosure of rights pertaining to subject matter against a referencing spec that includes the subject matter by reference only.  Very few, if any, SDOs require such disclosures, mostly for practical reasons.  The same reasons seem to apply here as well.