Re: Last Call on draft-bradner-rfc3979bis-08.txt ("Intellectual Property Rights in IETF Technology")

John C Klensin <> Mon, 04 April 2016 23:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5576412D724 for <>; Mon, 4 Apr 2016 16:23:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ym4cbGjnCOVI for <>; Mon, 4 Apr 2016 16:23:20 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9501812D126 for <>; Mon, 4 Apr 2016 16:23:20 -0700 (PDT)
Received: from [] ( by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1anDpy-000L9C-01; Mon, 04 Apr 2016 19:23:14 -0400
Date: Mon, 04 Apr 2016 19:23:08 -0400
From: John C Klensin <>
To: Brian E Carpenter <>
Subject: Re: Last Call on draft-bradner-rfc3979bis-08.txt ("Intellectual Property Rights in IETF Technology")
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <>
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-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Cc: IETF <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Apr 2016 23:23:22 -0000

--On Tuesday, April 05, 2016 08:16 +1200 Brian E Carpenter
<> wrote:

>> Another aspect of my reaction to Barry's comment is that,
>> given other changes in the IETF in the last 11 years, I'd
>> really like to see 3979bis recast as a matter of ethical
>> obligations to the IETF and fellow participants, with
>> specific legal (or other) requirements stated as corollaries
>> to those ethical principles rather than as standalone rules.
> I'm sympathetic with that idea, but not being a lawyer I don't
> know if it's feasible to truly separate them.


I suggest that every legislator or minister in the world who has
had to write an introduction that justifies what a particular
law or regulation is about (or to get it passed), and every
lawyer who has started a sentence with the word "Whereas..." (or
its equivalent in other languages) understands how to do that.

In our case, the Abstract and Introduction to 3979bis say some
nice words about design and intentions, but it is hard to
understand the relationships between those statements and the
actual rules.  It would require a massive reorganization
/rewrite to the document and I'm not at all sure the community
(much less Scott and Jorge) are up to it, but I think we would
be better off if we outlined expectations for disclosure of IPR
(and other involvements that might complicate IETF actions) as a
professional and ethical matter.  I'd think it could be linked
to RFC 7154 and similar discussions and clearly focused on what
people need to know to develop good-quality standards and
related documents in an environment requiring a lot of trust in
colleagues.  With that set of principles in place, it could then
say that some specific rules exist in support of those
principles but that other behavior that would violate the
principles isn't allowed either.  Then it could go on to lay out
the rule themselves, in as much legalese as is needed and more
or less copying what is now in 3979bis-08, modified to reflect
the two weeks of discussions since it was posted.

I believe that would have at least two advantages: (i) it would
reduce the need to split every last possible hair and cover
every possible edge case because badly-intentioned behavior
would be considered bad (and sanction-able) in the IETF whether
some particular rule clearly applied or not and (ii) it _might_
permit us to have more focused discussions in the future by
differentiating disagreement with the principles from
disagreement about how particular rules were specified, or
whether those specifications adequately reflected, those

IMO, the document needs a change of organization and tone, and a
way to deal with the edge cases without having to try to
identify and specify the handling for each one, much more than
it needs major conceptual reform.   But changing organization
and tone would still represent a significant effort and, again,
it isn't clear to me that folks are up to it.