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

Scott Bradner <sob@sobco.com> Fri, 25 March 2016 16:30 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 CC79412DC3B for <ietf@ietfa.amsl.com>; Fri, 25 Mar 2016 09:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.109
X-Spam-Level:
X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-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 qjsmtYk1A21o for <ietf@ietfa.amsl.com>; Fri, 25 Mar 2016 09:30:58 -0700 (PDT)
Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796DC12DAAD for <ietf@ietf.org>; Fri, 25 Mar 2016 09:30:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 90AFA19C62E8; Fri, 25 Mar 2016 12:30:55 -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 ikWX9ZbDKwFC; Fri, 25 Mar 2016 12:30:54 -0400 (EDT)
Received: from dhcp2.sobco.com (vpn1.sobco.com [136.248.127.172]) by sobco.sobco.com (Postfix) with ESMTPSA id 7F92319C62D9; Fri, 25 Mar 2016 12:30:54 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Last Call on draft-bradner-rfc3979bis-08.txt ("Intellectual Property Rights in IETF Technology")
From: Scott Bradner <sob@sobco.com>
In-Reply-To: <DC9B799D-A1EF-457C-B791-9F103FDA7CD6@vigilsec.com>
Date: Fri, 25 Mar 2016 12:30:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <B7D5F7F3-0742-409A-8E6E-3D1AC7C97F43@sobco.com>
References: <0000431F-F977-4A24-BA4D-064F740977A0@piuha.net> <DC9B799D-A1EF-457C-B791-9F103FDA7CD6@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/qixMEiA5DT0fl8YwwCadIUDlqBA>
Cc: IETF <ietf@ietf.org>, "Jorge L. Contreras" <contreraslegal@att.net>
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:31:00 -0000

makes sense

Scott

> On Mar 25, 2016, at 12:28 PM, Russ Housley <housley@vigilsec.com> wrote:
> 
> 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)
>> 
>