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

Stewart Bryant <> Wed, 18 January 2017 15:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35B1E12940B; Wed, 18 Jan 2017 07:26:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1rCqix0KsF10; Wed, 18 Jan 2017 07:26:01 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 977A412896F; Wed, 18 Jan 2017 07:26:00 -0800 (PST)
Received: by with SMTP id k86so14587745lfi.0; Wed, 18 Jan 2017 07:26:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=c4NMh7LUE/Ve3QQdyKzMQ1vS/ES2ADDw3bEv+yfIzIw=; b=RUzvPhT/QDBqeEba0aRApURwofbn+APfwcovYF/i03zZANm8iqZqrNCbnktGkJGfAT P9h4yBOvO8iQkOlrdWir0GOK8EH9OLIf8Zmy7qjmkV98BLSAxlMidn7t7iylMlPmhh8J 7t6xQG0nk+/Ynj9DQ0cBeRaMmmg14cxxqdn6r4Un8h2QHqtihrwyRSvwa8efmWN7o++2 RbwM6k90dmPjKIrekNx3RrFnbH7lUAiJIKQtwTZbY+e3Z9wHJycoqjaJ1y9AGAQVA0Mf 9qtvVPpqETGxe7/gqRpm5mbRZJBa/qXGwz1h2MABdyJ/hVrsuysfqSCnfWroXBDGEHAg Oe/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=c4NMh7LUE/Ve3QQdyKzMQ1vS/ES2ADDw3bEv+yfIzIw=; b=eB0f8PnHRxKWSB2mfg6vRFGOvqYkPT/8PnnkEHvcDqs2gX9QSEfv+GJAhKMrr/FZyz avDs57d3tHRxsSIKLwqbKpTA5dt0GqUpyERV9Js4BvnEFgXWijJov+wDKPy8D99E0ttn vGqgVPcMan8iOPHeAMhet7XXG6GuosjYwhaUChERPTnfXSK9mSJSviyIEbq8DDGIhxiT CN1q+uZboui65X1Jz3JetlNR2QDepWdXqFpNxLN5+cFhV1F8HZRFA1HNkgy3UmMX7iSU VThYRfyg43CnoZjD/w6m/dRFWG6NF+dQwWmy/L7J0Fr+QIr+5F+e0Gcrd8+pGVYyfLTR WyaQ==
X-Gm-Message-State: AIkVDXKYfEGUczc5d991uCLZEznc4nyO+16Y1+NhlTyMXmoTcq5UVpEhohUFBlLZsIgSrw==
X-Received: by with SMTP id s133mr1832030lja.56.1484753158627; Wed, 18 Jan 2017 07:25:58 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id 96sm390002lfp.18.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jan 2017 07:25:57 -0800 (PST)
Subject: Re: Last Call: <draft-bradner-rfc3979bis-10.txt> (Intellectual Property Rights in IETF Technology) to Best Current Practice
References: <>
From: Stewart Bryant <>
Message-ID: <>
Date: Wed, 18 Jan 2017 15:25:52 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
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, 18 Jan 2017 15:26:07 -0000


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

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.

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.

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.

- Stewart

On 18/01/2017 14:18, The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Intellectual Property Rights in IETF Technology'
>    <draft-bradner-rfc3979bis-10.txt> as Best Current Practice
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> mailing lists by 2017-02-15. Exceptionally, comments may be
> sent to instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> Abstract
>     The IETF policies about Intellectual Property Rights (IPR), such as
>     patent rights, relative to technologies developed in the IETF are
>     designed to ensure that IETF working groups and participants have as
>     much information as possible about any IPR constraints on a technical
>     proposal as early as possible in the development process. The
>     policies are intended to benefit the Internet community and the
>     public at large, while respecting the legitimate rights of IPR
>     holders.  This memo sets out the IETF policies concerning IPR related
>     to technology worked on within the IETF.  It also describes the
>     objectives that the policies are designed to meet.  This memo
>     replaces section 10 of RFC 2026 and obsoletes RFC 3979 and RFC 4879.
> The file can be obtained via
> IESG discussion can be tracked via
> No IPR declarations have been submitted directly on this I-D.
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>      rfc6701: Sanctions Available for Application to Violators of IETF IPR Policy (Informational - IETF stream)
>      rfc4844: The RFC Series and RFC Editor (Informational - IAB stream)
>      rfc6401: RSVP Extensions for Admission Priority (Proposed Standard - IETF stream)
> Note that some of these references may already be listed in the acceptable Downref Registry.