Re: Change in IPR policies

"Scott O. Bradner" <sob@sobco.com> Tue, 09 June 2020 20:23 UTC

Return-Path: <sob@sobco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C3C3A07BE; Tue, 9 Jun 2020 13:23:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iL9IEaqqharg; Tue, 9 Jun 2020 13:23:47 -0700 (PDT)
Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE4A3A07CE; Tue, 9 Jun 2020 13:23:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id ECF6A3854921; Tue, 9 Jun 2020 16:23:45 -0400 (EDT)
X-Virus-Scanned: amavisd-new at sobco.com
Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoyO8lTY4rdL; Tue, 9 Jun 2020 16:23:41 -0400 (EDT)
Received: from [192.168.50.224] (173-166-5-67-newengland.hfc.comcastbusiness.net [173.166.5.67]) by sobco.sobco.com (Postfix) with ESMTPSA id 12419385490C; Tue, 9 Jun 2020 16:23:41 -0400 (EDT)
From: "Scott O. Bradner" <sob@sobco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
Subject: Re: Change in IPR policies
Date: Tue, 9 Jun 2020 16:23:38 -0400
References: <96A3BDFE6F7DC38D2366581F@PSB>
To: trustees@ietf.org, IETF Discussion Mailing List <ietf@ietf.org>
In-Reply-To: <96A3BDFE6F7DC38D2366581F@PSB>
Message-Id: <F95BB047-2E63-40C7-9642-3372154B4E9F@sobco.com>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/4TpxgM3NrO7giJEuAiu6JgmQVec>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2020 20:23:49 -0000

relative to John’s point #2

does this mean that the IETF will not be making the session recordings openly available? - there seems 
to be no reason for a distribution prohibition otherwise

(for example see https://datatracker.ietf.org/meeting/103/proceedings - it list the audio & video recordings)

if so, that would, as John points out, would be a rather big change and I did not see any discussion
of any proposal to make such a change - can you point me to the archive of the discussion - thanks

Scott

> On Jun 9, 2020, at 3:50 PM, John C Klensin <john-ietf@jck.com> 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.
> 
> (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).
> 
> best,
>   john
> 
>