Re: Proposed IESG Statement on IPR Declarations

John C Klensin <john-ietf@jck.com> Wed, 13 July 2016 12:24 UTC

Return-Path: <john-ietf@jck.com>
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 B70B712DF13 for <ietf@ietfa.amsl.com>; Wed, 13 Jul 2016 05:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level:
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
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 EziHqiWegQey for <ietf@ietfa.amsl.com>; Wed, 13 Jul 2016 05:24:52 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0338312D0F9 for <ietf@ietf.org>; Wed, 13 Jul 2016 05:24:52 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1bNJDb-000COQ-D7; Wed, 13 Jul 2016 08:24:47 -0400
Date: Wed, 13 Jul 2016 08:24:42 -0400
From: John C Klensin <john-ietf@jck.com>
To: Jari Arkko <jari.arkko@piuha.net>, Barry Leiba <barryleiba@computer.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: Proposed IESG Statement on IPR Declarations
Message-ID: <B76F082313F94DC342AF0F7F@JcK-HP8200>
In-Reply-To: <9B54CC46-5A15-4996-B771-EB0E8AC22AFE@piuha.net>
References: <20160707202122.23634.18168.idtracker@ietfa.amsl.com> <CAC4RtVAEQfWN-xgtrDS0kKg6EV22hdskJKL++vsp80vi0XOjUA@mail.gmail.com> <9B54CC46-5A15-4996-B771-EB0E8AC22AFE@piuha.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/u4czxv-XJgGtvtjoufeFWRM532w>
Cc: IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 13 Jul 2016 12:24:55 -0000


--On Wednesday, July 13, 2016 00:38 +0200 Jari Arkko
<jari.arkko@piuha.net> wrote:

>...
> However, I wanted to say that we received advise from IETF
> lawyers that highlighting that we do not check or endorse
> statements in the IPR declarations more visibly would be
> useful, even if the material is already presented in the RFCs.

Are these the same lawyers who, IIR, warned us some years ago
that making the Note Well look comprehensive could leave us in a
situation in which the BCP documents themselves were
unenforceable, especially if there was anything that could be
interpreted as a discrepancy between the two?  IANAL, but it
seems to me that more documents/statements increases that risk.

It seems to me that, if anything additional is needed, we should
be either fixing the Note Well or putting the additional
explanation on the IPR page (as Brian suggests).   I do have two
concerns about the latter: (i) More documents and hence more
basis for people defending themselves against non-compliance by
saying "too many places to look; missed that one" and (ii)
anyone who is already on the IPR page probably doesn't need
additional advice, especially advice to either look there or to
read BCP 79

>...
>> RFC 6701 explicitly puts WG Chairs and the IESG into the
>> enforcement business
> 
> RFC 6701 is about the responsibility of contributors to make
> declarations. And actions if that doesn't happen. It is *not*
> about the content of those declarations, however.

In reality, neither is BCP 79.  It attempts to describe
circumstances under which one SHOULD or MUST disclose.  But its
Section 6.4 actually says remarkably little, especially for
third party (and therefore "SHOULD") disclosures.  Again, IANAL,
but I believe that a lawyer for EvilCorp could look at BCP 79
and say "our IETF participants are required by BCP 79 to
disclose, so we will do that rather than getting involved with
later claims about patent enforceability, but we will devise a
way to do so that actually exposes almost no information and is
belligerent about it".  I think it is clear that the intent of
BCP 79 is to discourage that sort of behavior and even to lay
the foundation for challenges (outside the IETF) to patent
enforcement.  But it is also an edge case and I don't think it
would be desirable for there to be any statements floating
around that could be construed as preventing the community
(including the IESG) from saying, "your disclosure, which
basically says 'nah, nah, nah' violates the intent of BCP 79 by
not providing any information a WG can evaluate and we are going
to invoke RFC 6701 unless you clean up your act".  I don't
suggest the IESG should do that, but it would be an "evaluation"
of the content of the disclosure and I'd rather see a
case-by-case judgment call than the IESG boxing itself (and the
community) into a corner by creating a constraint that BCP 79
does not create.

>...
> Does bcp79bis (draft-bradner-rfc3979bis) cover your issue? If
> not, please submit an issue to Scott and Jorge.
> 
> That document is on our plate to complete (and mostly on my
> plate, Scott and Jorge are awaiting me for the next steps).

I believe I have submitted issues and gotten no applicable
response.

    john