Change in IPR policies

John C Klensin <> Tue, 09 June 2020 19:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41EBE3A0D5A; Tue, 9 Jun 2020 12:50:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PokZfogDhAcx; Tue, 9 Jun 2020 12:50:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C807E3A0D52; Tue, 9 Jun 2020 12:50:27 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1jikGQ-0000sv-A9; Tue, 09 Jun 2020 15:50:26 -0400
Date: Tue, 09 Jun 2020 15:50:19 -0400
From: John C Klensin <>
Subject: Change in IPR policies
Message-ID: <96A3BDFE6F7DC38D2366581F@PSB>
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.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Jun 2020 19:50:29 -0000


I was just reminded that, when I registered for IETF 108, I
noticed that I was asked to agree to two things that seemed new.
The first is probably unimportant but IANAL and it is still a
change.  The second seems problematic.

(1) If I recall (I was tired and might easily have been
confused), the language about the Note Well statement has
changed to require agreement to the statement itself, not just
that it was read and understood.  If so, I hope the new language
was cleared with counsel because I believe we were warned in the
past that we should treat that statement simply as a collection
of pointers, not an authority in itself.  That is the reason
why, e.g., we reference specific RFCs or BCPs in I-Ds and RFC
boilerplate rather than pointing to the Note Well.

(2) There is a very specific and, as far as I know, completely
new, prohibition against distribution or broadcasting of any
meeting-related discussion or events.  That seems like a giant
step away from the IETF's tradition of openness and free
availability of materials.  It also may run counter to existing
principles and rules, including the provisions about reuse of
Contributions for IETF purposes that appear in BCP 78.  In
addition to the general principle that we do not try to restrict
access to, reuse of, or reproduction of, our materials (as long
as they are reproduced intact), there are at least two
interesting operational edge-case questions about what the
requirement means.   As examples,

 (1) Suppose that, as part of a presentation, I read sections of
an Internet-Draft that I wrote.  Now, normally, the content of
an I-D is a Contribution to the IETF but one for which the
author(s) etain full rights to reuse the content for other
purposes.  By reading those sections aloud, do I forfeit the
right to distribute and broadcast them?

 (2) Perhaps I read from a published RFC, for example RFCs 2026
or 5378. Does that make it a requirement that whomever hears me
read it must then ask the IETF's permission before quoting from
it in a way that would constitute "distribution".

(3) Suppose I record a session for my personal use and then
discover what appears to be a discrepancy between what was said
at the meeting.  Am I allowed to quote from my recording on the
relevant mailing list to dispute the account in the minutes?
Or, if there is a later decision made based in part of what was
said at the meeting, am I allowed to include part of that
recording in an appeal?

Those examples are (I hope) silly individually, but they are
consistent with the "no distribution or broadcasting" provision.

As important and in the context of other recent discussions, who
approved that restriction?  Were the Trustees of the IETF Trust
and their legal advisors involved and, if not, why not?  If they
were, should we expect a discussion in their April or May 2020
minutes (which are now significantly late)?

And, because it appears to be a very significant change from
IETF principles and history, when was the community consulted
about this and where is its consensus documented?    I hope no
one is going to claim that it was necessary on an emergency
basis to protect the revenue stream from registrations because
that claim could have been made at any time in the past (and I
can't be the only one who has recorded all or part of IETF
meeting WG or Plenary sessions and then shared them).