Re: Last Call: <draft-bradner-rfc3979bis-10.txt> (Intellectual Property Rights in IETF Technology) to Best Current Practice

Jari Arkko <> Wed, 25 January 2017 07:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 167AB129841; Tue, 24 Jan 2017 23:42:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cFChWnIyYncd; Tue, 24 Jan 2017 23:42:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 23E2F1297EF; Tue, 24 Jan 2017 23:42:55 -0800 (PST)
X-AuditID: c1b4fb25-1cbff700000036c9-3e-588856fdd3bd
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id A6.75.14025.DF658885; Wed, 25 Jan 2017 08:42:54 +0100 (CET)
Received: from ( by ( with Microsoft SMTP Server id 14.3.319.2; Wed, 25 Jan 2017 08:42:52 +0100
Received: from (localhost []) by (Postfix) with ESMTP id A527E4FDA9; Wed, 25 Jan 2017 09:43:43 +0200 (EET)
Received: from [IPv6:::1] (localhost []) by (Postfix) with ESMTP id 42E1A4EA90; Wed, 25 Jan 2017 09:43:42 +0200 (EET)
Content-Type: multipart/signed; boundary="Apple-Mail=_B5A5C97C-5F48-40C2-90B6-87B3D8559178"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Last Call: <draft-bradner-rfc3979bis-10.txt> (Intellectual Property Rights in IETF Technology) to Best Current Practice
From: Jari Arkko <>
In-Reply-To: <>
Date: Wed, 25 Jan 2017 09:42:38 +0200
Message-ID: <>
References: <> <>
To: Stewart Bryant <>
X-Mailer: Apple Mail (2.1878.6)
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7je6/sI4Ig/Pt/BZXn/YxWzzbOJ/F 4tSDRAdmj52z7rJ7LFnykymAKYrLJiU1J7MstUjfLoEro/3VWcaCDeYVP27bNDCeNOhi5OSQ EDCRaH9zj6mLkYtDSGAdo8TpCRuhnG2MEidPv2SGcNYCZbpaoZy5jBLPT21lBHGYBaYwSmy9 08IKMoxXwEDi+PefLCAJYYEWRolzLT+ZQBJsAloSG5cvYAOxOQVsJW7OXMIIYrMIqEqcmn+Z BcRmFrCQ2PthMTvEIHuJHWc+gvUKCdRJ3J2zFKxeREBXYs2v12wQl8tLfPhwnB3CVpO4em4T M0S9isStv2fZJjAKzUJ24CwkB84C26ctsWzha2YI20DiaecrVgjbVOL10Y+MELa1xIxfB9kg bEWJKd0P2Rcwsq9iFC1OLU7KTTcy1kstykwuLs7P08tLLdnECIycg1t+q+5gvPzG8RCjAAej Eg/vh+z2CCHWxLLiytxDjCpAcx5tWH2BUYolLz8vVUmEd25IR4QQb0piZVVqUX58UWlOavEh RmkOFiVxXrOV98OFBNITS1KzU1MLUotgskwcnFINjJVsex8qbTh5au7jXVO3cHosb7PJtCo7 e2BZwSsJs5TdercbP37h+XTa71j++d5jp98tOm4td3VZ9rG7petrZ2ontSSt2K7ue051muwH DuVmubNZ718c2ewrtfJ0YQvzVfvPN4W2m5ccXLf70yuFswKOjiGPzq+y/xIYd7NjcTXTB4Pw ecYOdpJKLMUZiYZazEXFiQBddixPpAIAAA==
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: Wed, 25 Jan 2017 07:42:58 -0000


Thanks again for your comments. Inline:

> In the body of this document you say:
> j. "Internet-Draft": a temporary document used in the IETF and RFC
>      Editor processes, as described in [RFC2026].
> RFC2026 states that the drafts are removed from the directory, implying
> that after that time they are not available. Whilst that never really
> reflected reality, the IETF through its tools system actively makes these
> documents available in perpetuity. Given the legal nature of this draft
> we ought to properly note the permanent availability of these temporary
> documents.

OK. Do you have a text suggestion, or would dropping “temporary” in this
context be sufficient?

> Section 5.3.3 specifically calls out ADs but there are many others who
> fall into the same category: the GEN_ART team, the directorates of
> other areas such as SEC and OPS, and of course regular contributors that
> only read an out of area RFC when they need to use its contents.

Fair point.

> If the text is specifically going to call out ADs it ought to also call
> out those that help ADs as part of their review process.
> The test says:
>   An IPR disclosure must list the numbers of any issued patents or
>   published patent applications or indicate that the disclosure is
>   based on unpublished patent applications.  The IPR disclosure must
>   also list the name(s) of the inventor(s) (with respect to issued
>   patents and published patent applications) and the specific IETF
>   Document(s) or activity affected.
> In some cases that is simply impractical. For example one might
> know that IPR was filed at a previous employer, for example
> because you were on the patent review panel, but of course
> would no longer have access to the documents to tease out the
> exact identity of the patent. All that we can expect by the first
> stage discloser, perhaps filing a third party disclosure, is as
> much information as they still have available.

Right. Is there a possibility to have a different rule for 3rd party and
“regular” declarations?

> In section 7 you state
>   When adopting new technologies, the participants in an IETF working
>   group are expected to evaluate all the relevant tradeoffs from their
>   perspective. Most of the time these considerations are based purely
>   on technical excellence, but IPR considerations may also affect the
>   evaluation and specific licensing terms may affect the participants'
>   opinion on the desirability of adopting a particular technology.
> There is a catch 22 problem with this text and later text in the section.
> The IPR situation may indeed affect an adoption decision, but the WG
> is not allowed to discuss the terms of the licence. In some cases the
> terms of an encumbered technology may be just fine, but
> contributors making an adoption decision cannot form a view
> on this as part of the IETF process. So you can end up with
> one partly saying yes because of IPR, another saying no
> because of IPR and neither allowed to explain their position as
> part of the IETF process.

Good point. But I see no way around that. There are plenty of
good reasons why negotiation about license is not a good
idea to do in IETF.

Also, end results matter. If a draft fails to be adopted,
I’ve seen companies post not just updated drafts but
also updated declarations that ultimately led to adoption.

That’s a fine mode of operation, and one way out of your