Re: Last Call on draft-bradner-rfc3979bis-08.txt ("Intellectual Property Rights in IETF Technology")

Russ Housley <housley@vigilsec.com> Fri, 25 March 2016 16:29 UTC

Return-Path: <housley@vigilsec.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 4AFAF12DA5E for <ietf@ietfa.amsl.com>; Fri, 25 Mar 2016 09:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 h4GR-CQTMUw1 for <ietf@ietfa.amsl.com>; Fri, 25 Mar 2016 09:28:59 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id E376D12D90B for <ietf@ietf.org>; Fri, 25 Mar 2016 09:28:58 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 45D42F2403D; Fri, 25 Mar 2016 12:28:58 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id eZREOID8FLgi; Fri, 25 Mar 2016 12:15:00 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A566BF2403B; Fri, 25 Mar 2016 12:28:47 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Last Call on draft-bradner-rfc3979bis-08.txt ("Intellectual Property Rights in IETF Technology")
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <0000431F-F977-4A24-BA4D-064F740977A0@piuha.net>
Date: Fri, 25 Mar 2016 12:28:46 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <DC9B799D-A1EF-457C-B791-9F103FDA7CD6@vigilsec.com>
References: <0000431F-F977-4A24-BA4D-064F740977A0@piuha.net>
To: Jari Arkko <jari.arkko@piuha.net>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/H0fmU3kEfgeG_p-Entz8Y8FRFSs>
Cc: IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 25 Mar 2016 16:29:01 -0000

Jari:

I looked at the diff between RFC 3979 and draft-bradner-rfc3979bis-08.txt.  The changes are substantial.  Over the last few years there have been sessions at IETF meetings about the things that needed to be clarified, but my interpretation of those discussions was that we had most things right and a few things needed to be clarified.  So the extent of the proposed changes is a bit of a surprise to me.  I do not find Section 13 helpful is explaining the changes that were made, or the rationale for them.

The definition of Contribution now includes:

      o any IETF-sanctioned design team or portion thereof,

I really have a problem with the use of "IETF-sanctioned” in this bullet.  RFC 2418 talks about design teams.  It says:

6.5. Design teams

   It is often useful, and perhaps inevitable, for a sub-group of a
   working group to develop a proposal to solve a particular problem.
   Such a sub-group is called a design team.  In order for a design team
   to remain small and agile, it is acceptable to have closed membership
   and private meetings.  Design teams may range from an informal chat
   between people in a hallway to a formal set of expert volunteers that
   the WG chair or AD appoints to attack a controversial problem.  The
   output of a design team is always subject to approval, rejection or
   modification by the WG as a whole.

It seems to me that the design team, whether established by the leadership or self organized, intends to influence the IETF document.  For this reason, I think that any design team participation must be considered a contribution.

Russ


On Mar 22, 2016, at 8:17 AM, Jari Arkko <jari.arkko@piuha.net> wrote:

> 
> All,
> 
> RFC 3979 was published in 2005. Since then we’ve gathered a lot of experience, and we’d like to update the RFC with that experience. This isn’t a revolution of the IETF IPR approach, it is mostly about clarification, better documentation, and recognising some other new RFCs and changes. But the document itself has changed quite a lot and structured differently than RFC 3979 was.
> 
> Some of the main issues (such as how to define participation) were discussed in the IETF-87 meeting, but there are also a number of other changes in this document. Please give this document a careful read, and let us know your feedback.
> 
> I am starting a last call on this document today, but gave a longer last call period to make sure everyone has enough time to comment after IETF-95 as well. And thanks for the comments that some of you have already sent after the document was published; we’ve observed them and will make them part of the feedback from the Last Call.
> 
> The document is available here:
> 
>   https://datatracker.ietf.org/doc/draft-bradner-rfc3979bis/
>   https://tools.ietf.org/html/draft-bradner-rfc3979bis-08
> 
> Jari Arkko (as the responsible AD for this document)
>