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
- Normatively referenced specifications SM
- RE: Normatively referenced specifications Black, David
- RE: Normatively referenced specifications SM
- Re: Normatively referenced specifications Dale Mohlenhoff (dmohlenh)
- Re: Normatively referenced specifications Joel M. Halpern
- Re: Normatively referenced specifications Dale Mohlenhoff (dmohlenh)
- RE: Normatively referenced specifications Lawrence Rosen
- Re: Normatively referenced specifications Dave Crocker
- RE: Normatively referenced specifications Michael Cameron
- RE: Normatively referenced specifications Michael Cameron
- Re: Normatively referenced specifications John C Klensin
- Re: Normatively referenced specifications Joel M. Halpern
- Re: Normatively referenced specifications Dave Crocker
- Re: Normatively referenced specifications Dave Crocker
- RE: Normatively referenced specifications Michael Cameron
- RE: Normatively referenced specifications Michael Cameron
- Re: Normatively referenced specifications Dale Mohlenhoff (dmohlenh)
- Re: Normatively referenced specifications Joel M. Halpern
- RE: Normatively referenced specifications John C Klensin
- Re: Normatively referenced specifications Joel M. Halpern
- Re: Normatively referenced specifications Joel M. Halpern
- Re: Normatively referenced specifications Dale Mohlenhoff (dmohlenh)
- RE: Normatively referenced specifications Michael Cameron
- Re: Normatively referenced specifications todd glassey
- Re: Normatively referenced specifications John C Klensin
- RE: Normatively referenced specifications Black, David
- RE: Normatively referenced specifications SM
- Re: Normatively referenced specifications SM