Re: Normatively referenced specifications

John C Klensin <john-ietf@jck.com> Thu, 19 December 2013 02:06 UTC

Return-Path: <john-ietf@jck.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 8D3A61ADF5F for <ipr-wg@ietfa.amsl.com>; Wed, 18 Dec 2013 18:06:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.138
X-Spam-Level:
X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] 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 vidpds7ZkKe3 for <ipr-wg@ietfa.amsl.com>; Wed, 18 Dec 2013 18:06:55 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 747921ADF4D for <ipr-wg@ietf.org>; Wed, 18 Dec 2013 18:06:55 -0800 (PST)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1VtT0i-000DyH-MK; Wed, 18 Dec 2013 21:06:48 -0500
Date: Wed, 18 Dec 2013 21:06:43 -0500
From: John C Klensin <john-ietf@jck.com>
To: "Dale Mohlenhoff (dmohlenh)" <dmohlenh@cisco.com>, Michael Cameron <michael.cameron@ericsson.com>, dcrocker@bbiw.net, ipr-wg@ietf.org
Subject: Re: Normatively referenced specifications
Message-ID: <B19B61301C2BD730F51998B5@JcK-HP8200.jck.com>
In-Reply-To: <CED72CDA.11A3B%dmohlenh@cisco.com>
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> <36BAA6A693139D4BBCB37CCCA660E08A02B87FCC@eusaamb101.ericsson.se> <52B1E830.30001@dcrocker.net> <36BAA6A693139D4BBCB37CCCA660E08A02B88190@eusaamb101.ericsson.se> <993E6E5E6EA5F13E50293C74@JcK-HP8200.jck.com> <CED72CDA.11A3B%dmohlenh@cisco.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
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: Thu, 19 Dec 2013 02:06:58 -0000

--On Wednesday, December 18, 2013 18:46 +0000 "Dale Mohlenhoff
(dmohlenh)" <dmohlenh@cisco.com> wrote:

> I agree John.  However, this is an area that has caused some
> issues to arise already and I think will continue to do so.

Yes, although many of those issues arise from misunderstanding,
confusion, or similar factors, as evidenced by the observation
that we seem to have small variations on this discussion every
six or nine months, sometimes more often.

> This is not just an IETF issue,

Of course it isn't.  But the IETF has made two, very carefully
considered, decisions.  Whether they are optimal or not given
the various tradeoffs, or even viable, is something that could
be debated endlessly (and has been) but the IETF keeps making
very nearly the same decisions after those debates.

They can be stated in different ways, but are:

(1)  We are not going to do "membership", including
	avoiding any sort of "apply and formally sign off and
	acknowledge a set of rules as a condition for
	membership/ participation", especially a set for which
	the organizations for which people work can be asked to
	sign off and held accountable.   This differs from many
	SDOs who have precisely those sorts of formalized
	application and membership policies.
(2) Our IPR policies focus entirely on disclosure of
	anything a participant knows, or reasonably should know,
	is encumbered or otherwise IPR-complicated.  This
	differs from those SDOs who focus more on licensing
	terms.

> however, would it make sense
> to consider language to address this issue or just state that
> a declarant must put these constraints in their declaration.

I am not certain I understand the question.  From my naïve
perspective (and, fwiw, I'm not a huge fan of the current policy
stance), it seems that everything that needs to be said has been
said, i.e., that if one knows of encumbrances or restrictions to
a relevant technology, one should disclose and if one is
involved with those encumbrances or restrictions, one must
disclose.  Since that is bound to what one knows and not what
appears in documents or how they are structured, questions about
references versus inline text seem irrelevant unless one is
trying to find a way to split hairs to evade the rules (and
perhaps then, but I make no claim to being an expert).

If you think more language is needed, it much help explain the
issue as you see it if you would suggest some sample text.

> I am thinking out loud here, but I understand your point that
> the current IETF IPR Policy does not address this.   

It is important to stress that "does not address this" was the
result of a very conscious decision, not some possibly-unhappy
accident or omission.

I wanted to repeat that because "I don't think the policy is
appropriate" and "I don't think the policy, as stated, is what
the IETF intended" are two very different positions.

best,
   john