Re: IPR Disclosures for draft-ietf-xrblock-rtcp-xr-qoe

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 16 September 2013 13:39 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE1E11E8257; Mon, 16 Sep 2013 06:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.568
X-Spam-Level:
X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfA7VSqWJGaJ; Mon, 16 Sep 2013 06:38:50 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 974EE11E824B; Mon, 16 Sep 2013 06:38:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5E2E0BE70; Mon, 16 Sep 2013 14:38:49 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIdDRtYhiG7K; Mon, 16 Sep 2013 14:38:49 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2066CBE62; Mon, 16 Sep 2013 14:38:49 +0100 (IST)
Message-ID: <523709E9.8050706@cs.tcd.ie>
Date: Mon, 16 Sep 2013 14:38:49 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Subject: Re: IPR Disclosures for draft-ietf-xrblock-rtcp-xr-qoe
References: <9904FB1B0159DA42B0B887B7FA8119CA128B4B92@AZ-FFEXMB04.global.avaya.com> <52331833.4070107@net-zen.net> <B8F9A780D330094D99AF023C5877DABA43C0221F@nkgeml501-mbs.china.huawei.com> <9904FB1B0159DA42B0B887B7FA8119CA128D936F@AZ-FFEXMB04.global.avaya.com> <5236FB0B.9070703@net-zen.net> <523701A8.5060704@ericsson.com> <9904FB1B0159DA42B0B887B7FA8119CA128DA114@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128DA114@AZ-FFEXMB04.global.avaya.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "rai-ads@tools.ietf.org" <rai-ads@tools.ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, Glen Zorn <gwz@net-zen.net>, "draft-ietf-xrblock-rtcp-xr-qoe.all@tools.ietf.org" <draft-ietf-xrblock-rtcp-xr-qoe.all@tools.ietf.org>, The IESG <iesg@ietf.org>, Shida Schubert <shida@ntt-at.com>, Qin Wu <bill.wu@huawei.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2013 13:39:21 -0000

On 09/16/2013 02:20 PM, Romascanu, Dan (Dan) wrote:
> I have doubts myself, doubts that I shared with the IESG that this
> question is really needed. Asking this question at the end of the
> process after the conformance with BCP 78 and BCP 79 was explicitly
> declared with each version of the I-D submitted seems redundant. 

It is redundant. Deliberately so though, since as stated earlier
we have seen cases where it did result in IPR declarations being
made by long-time IETFers who'd forgotten old filings. In at least
one such case we had to re-do an IETF LC, but it all did work out
to the satisfaction of the wg in the end. From memory, I think
we've seen about 3 IPR disclosures because of this question in the
last year. So its not solving a huge problem, but it does catch
a few things that'd be missed otherwise.

> It
> is probably intended to cover some corner cases where contributors
> forgot particular disclosures, or disclosures happened after the last
> I-D revision was submitted, or some of the authors on the authors
> list were not involved directly in the latest submitted revisions of
> the I-D. As WG chair however, as long as the question is formulated
> under its current format in the shepherd write-up form, I feel that I
> cannot responsibly answer to it without asking the authors.

As shepherd, you do have the option of saying "I didn't ask
Glen because I know it really annoys him and I know what his
answer will be" or "I asked the authors, and all's well but
Glen didn't respond but we know the question annoys him."

> To quote Gonzalo: Responding with a "yes, per the draft's
> boilerplate" should take only a few seconds

Yeah, I agree. But its inevitable that a redundant bit of
process stuff like this irritates someone, so we should all
(incl. irritated parties:-) live with that and not make a
deal of it.

And lastly a question for Glen: Say a co-author of yours
was prompted by this question to make a late IPR disclosure.
While that's a low probability event, (about a 1% chance
or so maybe), would that be better or worse than the
disclosure not happening or happening after the draft had
gone further in the process?

If it'd be better then I don't get why you think its a
problem that we double-check. (Or is there a better way
to double-check that would not be as annoying?)

If it'd be worse, (i.e. better to not know) then I don't
get that.

FWIW, much as I think most of the IPR we have to deal with
is nonsense, I still think its better for us to double-check
and get the IPR disclosures when we can easily do another
IETF-LC.

S.