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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71FB012D806 for <>; Mon, 4 Apr 2016 12:15:50 -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 gfPBJP_D6Tg2 for <>; Mon, 4 Apr 2016 12:15:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6670012D80E for <>; Mon, 4 Apr 2016 12:15:48 -0700 (PDT)
Received: from [] ( by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1an9yS-000KYU-Go; Mon, 04 Apr 2016 15:15:44 -0400
Date: Mon, 04 Apr 2016 15:15:39 -0400
From: John C Klensin <>
To: Gonzalo Camarillo <>, Jari Arkko <>, IETF <>
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: <>
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 19:15:50 -0000

--On Wednesday, March 30, 2016 18:49 +0300 Gonzalo Camarillo
<> wrote:

>>       Without limiting the generality of the
>>       foregoing, acting as a working group chair or Area
>>       Director constitutes "Participating" in all activities
>>       of the relevant working group or area.
> The AD of a large area may not get to read all individual I-Ds
> or all email messages sent in all the WGs of the area. We may
> want to define this a bit more explicitly.


This seems to be the most useful recent comment to which to
respond, after which I'm going back to lurking...

Following up on my response to Michael, I'd like to suggest
drawing the line in a different place and, if necessary, doing
it very explicitly.   While, as you point out, the AD in a large
area may not read every document, I think it is reasonable for
the community to assume that every AD reads every draft charter.
I think it is reasonable for an AD to be expected to have a
general sense of when a particular set a tasks or work area
might interact with work, and actual or potential IPR claims,
about which he or she is at least generally aware, at charter
time.  I think it is entirely appropriate for such an AD to take
a role in focusing a charter to explicitly include or exclude
particular work that might be relevant in either IPR or more
general conflict of interest terms.  But then I think the
community should want such ADs, if they are not in a position to
disclose should such IPR claims actually arise, to be completely
and formally isolated from the relevant work.  I'd prefer, but
not require, that the reasons for such an isolation decision be
explicitly disclosed to the community.   From one point of view,
this is why we have a moderately large IESG and more than one AD
in most areas.

FWIW, I note that undisclosed IPR is only one of the reasons for
such an isolation principle.  If an AD works for an organization
that has not announced, but is about to release, a product that
would interact with a WG's proposed work and could not disclose
the planned product (even if no IPR claims were intended and
whether the WG ultimately produced a standard that aligned with
the product or not), I'd want that AD isolated from influence
over decisions about that WG too.  In a way, that makes the rule
for ADs just like that for ordinary WG participants: the price
of contributing or otherwise participating in a way that could
influence decisions is disclosure.

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. 

FWIW, that view is very much influenced by Sam Hartman's
comments a week or two ago in which he focused, it seemed to me,
on what he as a participant wants or needs to know rather than
on conformance to specific legalistic rules.  It certainly did
not occur to me when 3668 and 3979 were being developed, but,
especially in the context of our current collection of rules for
good behavior (and prohibitions on various sorts of bad
behavior), concentrating on defining and encouraging ethical
behavior seems a better approach now.