Re: [xrblock] Handling of IPR within the XRBLOCK WG and draft-ietf-xrblock-rtcp-xr-video-lc-06.txt

Alissa Cooper <> Thu, 31 March 2016 22:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 121D312D8BA for <>; Thu, 31 Mar 2016 15:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.69
X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=cgtfb7IP; dkim=pass (1024-bit key) header.b=chZR6Fbp
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wyv7RdczV9MG for <>; Thu, 31 Mar 2016 15:35:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BEFAC12D0AB for <>; Thu, 31 Mar 2016 15:35:09 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 36D9A22124 for <>; Thu, 31 Mar 2016 18:35:09 -0400 (EDT)
Received: from frontend1 ([]) by compute4.internal (MEProxy); Thu, 31 Mar 2016 18:35:09 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=gkQpa Qto/ADG5fR7dBHo7sOd3t8=; b=cgtfb7IPPtWCBBP9nlnS2FXv7Vj3F11oxj4gn UkQSPidkJvNux9bdpDe8+yuDmXLe2hNh8DUWdQWC59rKdYHon57yjrgiktzaZL5Z Zw5WQEfn406Hmigz+BONAooAW48SafGqMNF35L4KOV5Qp66PL6jY5bVY5RR3KGdD DAsx08=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=gkQpaQto/ADG5fR7dBHo7sOd3t8=; b=chZR6 FbpMnF8YcrCl3zEkKc46mH76+UJZBln8HiiGDOztgBCDexWuYyD346CUiCok8ewQ 4LShsgFyMo+Z6UU4Vh64Yu+Fz/qSOZFaxKm27cjBWJ1zyIC/zLWJ/SJx73oIJp4O yJoCBJC44jXCKIJxJXY/viFsC239o6BzBDqGDg=
X-Sasl-enc: WiGAbbLg8IKITR1d+1eL4UvQg4Pc3rGRjacq2WDBGdId 1459463708
Received: from ( []) by (Postfix) with ESMTPA id 7121AC00016; Thu, 31 Mar 2016 18:35:08 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_9E5E7414-D708-44E6-9B34-238C7C80DFEA"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Alissa Cooper <>
In-Reply-To: <>
Date: Thu, 31 Mar 2016 15:35:53 -0700
Message-Id: <>
References: <> <>
To: "Drage, Keith (Nokia - GB)" <>
X-Mailer: Apple Mail (2.3112)
Archived-At: <>
Cc: "" <>
Subject: Re: [xrblock] Handling of IPR within the XRBLOCK WG and draft-ietf-xrblock-rtcp-xr-video-lc-06.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Mar 2016 22:35:12 -0000

RFC 3669 is useful, but just wanted to point out BCP 79 Sec. 7 which I take to be the prevailing guidance on these matters. 

In this particular case it seems more like what the WG was discussing was applicability, not validity. And in any event there was not an attempt to reach consensus about either applicability or validity, which is the key bit from BCP 79 in this case I think.


> On Mar 31, 2016, at 9:33 AM, Drage, Keith (Nokia - GB) <> wrote:
> I agree.
> I also think this is a two step process, and the next step is to ask the IPR claimant whether they believe their declaration is still applicable. Their response can be either to withdraw it, modify it or keep it, and we can come back to the discussion at that point.
> I believe this is consistent with RFC 3669.
> Keith
> From: xrblock [ <>] On Behalf Of EXT Alan Clark
> Sent: 31 March 2016 17:15
> To: <>; Romascanu, Dan (Dan)
> Subject: [xrblock] Handling of IPR within the XRBLOCK WG and draft-ietf-xrblock-rtcp-xr-video-lc-06.txt
> Dan,
> It is good that the WG has found a way forward with the video-lc draft. Bearing in mind the difficulty in getting a response from the company that made the patent disclosure, I think that the WG should not progress the draft until the IPR disclosure is actually withdrawn. 
> There were a number of statements made within the XRBLOCK WG during the last months about what the IETF and the WG could and could not do with regard to patent disclosures, and some XRBLOCK participants were presenting the view that we should not even discuss whether or how a patent may apply to a draft. The IETF IPR WG appear to have considered this and if we look at the guidelines for WG's provided in RFC 3669:
> "The IETF as a whole, and a working group as a whole, takes no stance on the validity of any IPR claim.  It would be inappropriate for a working group chair to declare that consensus had been reached that, for example, a company's patent was invalid.  Individual participants will need to use whatever legal advice resources they have access to in order to form their own individual opinions.  Discussions about the validity of IPR may take place under the auspices of the working group, in particular about relative risks of technology choices.  Individual participants may take these discussions into account.  The working group as a body may not take a stance on validity, but it may make choices based on perceived risk."
> So - this essentially states that the IETF and the WG should not take a position on the validity of a patent however that individuals may form opinions on the validity of patents, WG may discuss these opinions and they may affect the choices made by the WG.  As a WG we have followed the letter and spirit of the IETF guidelines in considering the applicability of the disclosed patent to the draft.
> I asked to be removed as an author from this draft as text that was inserted into the draft by another author caused the draft to be subject to a patent disclosure by that author's company, however the IPR was not disclosed at the time and the inserted text was non-essential and not directly relevant to the purpose of the document. 
> The inserted example text described a specific video loss concealment algorithm, claimed in a patent, whereas the draft only defines metrics for reporting the proportion of video that was loss concealed, duration of frame freezes and similar measurements. The patent described a specific algorithm for video loss concealment and contained no text or claims that related to metrics or performance measurement.  If the patent was required in order to implement the draft then the removal of the offending text would change the operation of the protocol or the value of the metrics reported, whereas the removal of the text will in fact make no difference at all. 
> So - hopefully Huawei withdraw their IPR disclosure and the draft moves forward to become an RFC.
> Best Regards
> Alan Clark
> _______________________________________________
> xrblock mailing list
> <>
> <>