Re: Normatively referenced specifications

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 18 December 2013 18:42 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: ipr-wg@ietfa.amsl.com
Delivered-To: ipr-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2875A1AE134 for <ipr-wg@ietfa.amsl.com>; Wed, 18 Dec 2013 10:42:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJAe_BbE7YqL for <ipr-wg@ietfa.amsl.com>; Wed, 18 Dec 2013 10:41:59 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8741AE0A1 for <ipr-wg@ietf.org>; Wed, 18 Dec 2013 10:41:59 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 388FF783347; Wed, 18 Dec 2013 10:41:58 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (pool-70-106-135-17.clppva.east.verizon.net [70.106.135.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 3A654783345; Wed, 18 Dec 2013 10:41:55 -0800 (PST)
Message-ID: <52B1EC6F.7050206@joelhalpern.com>
Date: Wed, 18 Dec 2013 13:41:51 -0500
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: dcrocker@bbiw.net, "Joel M. Halpern" <jmh@joelhalpern.com>, "Dale Mohlenhoff (dmohlenh)" <dmohlenh@cisco.com>, SM <sm@resistor.net>, "Black, David" <david.black@emc.com>
Subject: Re: Normatively referenced specifications
References: <CED46C85.AC4EC%stewe@stewe.org> <6.2.5.6.2.20131217001052.0c5bff98@resistor.net> <8D3D17ACE214DC429325B2B98F3AE712026ECD3A9B@MX15A.corp.emc.com> <6.2.5.6.2.20131218001051.0c266ed0@resistor.net> <CED70C71.119D0%dmohlenh@cisco.com> <52B1CF27.3010905@joelhalpern.com> <52B1DE0C.8010201@dcrocker.net> <52B1E6F0.5060808@joelhalpern.com> <52B1E8C7.90400@dcrocker.net>
In-Reply-To: <52B1E8C7.90400@dcrocker.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "ipr-wg@ietf.org" <ipr-wg@ietf.org>
X-BeenThere: ipr-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPR-WG <ipr-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipr-wg>, <mailto:ipr-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipr-wg/>
List-Post: <mailto:ipr-wg@ietf.org>
List-Help: <mailto:ipr-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipr-wg>, <mailto:ipr-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Dec 2013 18:42:02 -0000

Now I see what you (and John) are getting at.  I am not sure exactly 
what our rules say, and this is likely an area that can be gamed.  But 
since our rules are that you have to disclose what is needed to 
implement the specification, it would seem reasonable (but really needs 
a lawyer, which Dale is and I am not) that this would apply to many 
normative references.  A normative reference that is needed to 
understand the spec but not to implement it might be an even more 
nuanced case.

And the disclosure rule in question is only incumbent upon someone 
participating in that work in the IETF.
A normative reference to a document in an IETF RFC or I-D does not mean 
that some non-participant in that work in the IETF who has IPR on that 
document needs to disclose the IPR.

Yours,
Joel

On 12/18/13 1:26 PM, Dave Crocker wrote:
> On 12/18/2013 10:18 AM, Joel M. Halpern wrote:
>> THe part that is relevant to this discussion are the IPR licensing terms
>> stated by folks in conjunction with our policy.
>> And yes, they can make broader grants about other specifications when
>> they provide those licenses, but from an IETF perspective what folks
>> look at, and what we are discussing, is the licensing terms for use in
>> the specification.
>
>
> Whereas I read the challenging part of this discussion as having to do
> with requirements for disclosure.  Certainly the assertions in the
> thread that gave me pause were ones that claimed clever, nuanced
> interpretations of our rules in order to avoid disclosure.
>
> Once IPR is disclosed, how the IETF chooses to deal with that
> information might indeed get complicated, nuanced or whatever.
>
> d/