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

Stewart Bryant <> Wed, 25 January 2017 10:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD44412989D; Wed, 25 Jan 2017 02:07:22 -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 n-nwvHxicAWi; Wed, 25 Jan 2017 02:07:20 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 28D7612989C; Wed, 25 Jan 2017 02:07:20 -0800 (PST)
Received: by with SMTP id c206so21656058wme.0; Wed, 25 Jan 2017 02:07:20 -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=t+X9wGuBzYgFNWBfEhBHWc2UJ28y3+f/Bt7GbxUXgvw=; b=EER5AJk9ArmQJHGRpi8cIs9LJH2UT49UkreBb0XBtHeawopfYw9YEzTCkaZLW4LsrF BtLiFj+UmuuI6i/OhgRBN8PIDpa16Upz7G90RCM2Y1Gu6V/HWgQvpeE0NfZ20guockHR W0RJ1g4MIn6RKe7VlSSMr3FwyxEbndRO8yf/gYP9pMyd0fFCp2jbJ6VDTtSIa7iFbw5J jqjXKh+jJ2t6Q7lpsNtiVOsOfCCXeU5Hd0pqh0cCanPiA21yOQqFBef87A8ih4FzoPEx zxIDDmM7q3jx2OyGaaEfm5aRIzJqeV1DcoM2PPaLdM88mYZlmearrarPfcsg9OPiotVI UYfg==
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=t+X9wGuBzYgFNWBfEhBHWc2UJ28y3+f/Bt7GbxUXgvw=; b=JLm5Ihz5vLeawwDGxOVBUwQALF6D4COL7ezDkWc2Xt087YyPJOHiH3ozhSaMtDZBVI 7x2XgzXh1r7jwloAp4M5P7UDkSxUVrsxl3k+lxtR+tk8ny0zuucTcoIC3qIm+a9nHdtI GxHSZYk5uYRAb1ZsXfG3XtFl6Yx/UiK/f9EQEJ+3fLrYuA57VHsJ79ESeyWzACiVPNlJ g3GQlLfuD+D4WhwwYwrggC4Twq/guI4n+Akj4iCrVGcicO7Got+lJ/MAcMDpXm+K3JYn Q2+Yobe9SjHZfKQUyPS4XbKM2A2yNQTY+loe1BOgLL9E9v8y8E049pZ4MBswFpbMF632 uaKA==
X-Gm-Message-State: AIkVDXJCRIJgwqA/Xxd5aYulz8nsd1GGa94jFnPv9rCm/0o1SnWTXh7V6y1RJdGs1pxcSw==
X-Received: by with SMTP id 93mr30911883wrr.13.1485338838440; Wed, 25 Jan 2017 02:07:18 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id 18sm24164582wrb.14.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 02:07:17 -0800 (PST)
Subject: Re: Last Call: <draft-bradner-rfc3979bis-10.txt> (Intellectual Property Rights in IETF Technology) to Best Current Practice
To: Jari Arkko <>
References: <> <> <>
From: Stewart Bryant <>
Message-ID: <>
Date: Wed, 25 Jan 2017 10:07:14 +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: 8bit
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 10:07:23 -0000

On 25/01/2017 07:42, Jari Arkko wrote:
> Stewart,
> 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?

Well we could tell the whole story: they are a temporary document for 
the purposes
of actively progressing our work, but are persistent and remain beyond 
the publication of any
RFC for the purposes of traceability.

>> 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?

The text has a must, whereas the discloser can only provide that information
as far as practical and with regard to the access to records they have 
to them at the time they identify the need to disclose.

>> 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
> catch-22.

I think our historic base is based on a more consistent range of acceptable
costs than we have today, with the introduction or IoT.
Whilst the floor of the IETF is not the place for license fee negotiations
at the moment we are not even allowed to say: "I know that A is better
than B, but a foo cannot afford the licence for A, but can afford it for B".
Instead we would have to say: "I don't want A, I want (inferior) C because
it has no IPR". In other words we currently do not have the ability to
articulate the reason why one approach should be adopted in preference
to another,  other than to express a preference for IPR free. I am 
that as the scope of the Internet increases this inability to properly
articulate the root issue becomes problematic.

- Stewart

> Jari