Re: Change in IPR policies

John C Klensin <> Tue, 09 June 2020 21:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66CD63A08E1; Tue, 9 Jun 2020 14:11:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v5R_3bpD5bBu; Tue, 9 Jun 2020 14:11:44 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 626323A08CB; Tue, 9 Jun 2020 14:11:44 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1jilX4-000107-V8; Tue, 09 Jun 2020 17:11:42 -0400
Date: Tue, 09 Jun 2020 17:11:35 -0400
From: John C Klensin <>
To: Jay Daley <>
Subject: Re: Change in IPR policies
Message-ID: <334CAE80B4EA58061943540D@PSB>
In-Reply-To: <>
References: <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 21:11:47 -0000

--On Wednesday, June 10, 2020 08:42 +1200 Jay Daley
<> wrote:

> John
>> On 10/06/2020, at 7:50 AM, John C Klensin <>
>> wrote:
>> Hi.
>> 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.
> The registration form at
> asks you to tick "I have read and understand the IETF Note
> Well" - is that not what you were expecting or have I missed
> something?

That is not what I was expecting, but I also misremembered it.
See my response to Scott.  Again, that is the least of my

>> (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.
> I need to check, but I think the intent there was to restrict
> livestreaming and nothing else as the combination of live
> streaming + open jabber rooms would effectively allow
> participation without registration.  Once I've reviewed I
> will get that corrected.

I think there are three separate concerns about this.  One is
Adrian's concern about WebEx (or Meetecho) and simultaneous
sessions.   The second is what this will actually restrict and
why.  If it is an attempt to prevent someone from registering
and passing the livestreaming on to their friends or colleagues
in real time to avoid registration fees, that seems very
heavy-handed unless the IETF Administration LLC has decided that
the main purpose of IETF meetings is revenue (that is very
different, IMO, from charging for registrations).  The third is
how this decision got made, by whom (important so it can be
appealed), and under what authority they claim allowed them to
make it without community involvement or even advanced warning.

I note that, given the traditions of people working together in
the IETF with mutual respect that if the only purpose of that
provision were to prevent secondary live streaming, it would
have been sufficient to say "in order to preserve the revenue
stream and general good order, we request that people not
redistribute meeting audio or video before the official versions
appear on YouTube".  That would take care of almost anyone who
might think about doing it and we could deal with others as we
deal with people who behavior in seriously anti-social or
unprofessional ways.   No need for this sort of
precedent-breaking, legal-sounding, prohibition.

But, at least for me, that third issue is, by far, the most
important.   Again, how was this decision made, who made it (if
you have to check, it apparently was not you, for which I'm
grateful), and under what authority.