Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem

Russ Housley <housley@vigilsec.com> Mon, 12 January 2009 22:31 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF873A68D0; Mon, 12 Jan 2009 14:31:20 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDDB23A6914 for <ietf@core3.amsl.com>; Mon, 12 Jan 2009 14:31:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.497
X-Spam-Level:
X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y5fbyrKndzO for <ietf@core3.amsl.com>; Mon, 12 Jan 2009 14:31:18 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by core3.amsl.com (Postfix) with SMTP id 8F30F3A68D0 for <ietf@ietf.org>; Mon, 12 Jan 2009 14:31:18 -0800 (PST)
Received: (qmail 2776 invoked by uid 0); 12 Jan 2009 22:24:16 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 12 Jan 2009 22:24:16 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 12 Jan 2009 17:24:20 -0500
To: john-ietf@jck.com
From: Russ Housley <housley@vigilsec.com>
Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem
In-Reply-To: <345C76B329D94E644F9DF70C@PST.jck.com>
References: <FB8A848E-E415-4CDE-9E3F-5C74A5614F18@cisco.com> <49678B2A.8000100@dcrocker.net> <20090109181503.GP24908@verdi> <6E372F257B0C42E7AB9B7DA6231FF4E4@LROSENTOSHIBA> <p06240800c58d5466241b@[10.227.48.131]> <DBAA71AA401E5398212B1E03@PST.jck.com> <4967CAA1.9020608@gmail.com> <B2385D8E5F5BA599A174BD43@PST.jck.com> <4967E348.7050300@joelhalpern.com> <87d4evgu35.fsf@mocca.josefsson.org> <20090110191055.GB31579@mit.edu> <7D0E9557A84E06BFB4E120CA@PST.jck.com> <496905AF.7090209@gmail.com> <345C76B329D94E644F9DF70C@PST.jck.com>
Mime-Version: 1.0
Message-Id: <20090112223118.8F30F3A68D0@core3.amsl.com>
Cc: trustees@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John:

I think that the cover note from the Chair of the IETF Trust, Ed 
Juskevicius, included the vast bulk of the information that you are 
requesting.  Let's look at all three parts of your request.

(1)  "this is the problem we are trying to solve"

 > Some I-D authors are having difficulty implementing RFC 5378.  An
 > example of the difficulty is as follows:
 >
 >  - an author wants to include pre-5378 content in a new submission
 >    or contribution to the IETF, but
 >  - s/he is not certain that all of the author(s) of the earlier
 >    material have agreed to license it to the IETF Trust according
 >    to RFC 5378.
 >
 > If an I-D author includes pre-5378 material in a new document, then s/he
 > must represent or warrant that all of the authors who created the
 > pre-5378 material have granted rights for that material to the IETF Trust.
 > If s/he cannot make this assertion, then s/he has a problem.

In my view, the Trustees are trying to prevent a situation that 
forces people to make assertions on behalf of third parties.  From 
this thread, and you messages in particular, it is quite clear that 
forcing people to do so would be a very big problem.


(2)  "this is the principle we are using as the basis of the solution"

 > ... The Trustees of the IETF Trust
 > are investigating ways to implement a temporary work-around so that IETF
 > work can continue to progress.  A permanent solution to this "pre-5378
 > problem" may require an update to RFC 5378, for example new work by the
 > community to create a 5378-bis document.

In my words, the Trustees are trying to use the flexibility in the 
existing BCPs to provide a work-around, and then the IETF can craft a 
long-term solution once this work-around has relieved the 
pressure.  The Trustees approach requires community review, but it 
does not require IETF consensus because it stays within the bounds of 
our of the existing BCPs.

As General Area Director, I support this approach for four 
reasons.  First, I believe that this work-around can be put in place 
faster than updating the BCP.  Even if we had the perfect 
Internet-Draft in hand three steps would be needed to approve it: AD 
Review (a day if it is really perfect), IETF Last Call (four weeks), 
and IESG Evaluation (a week or two).  And once it is approved, the 
RFC Editor would need to process the document (up to four 
weeks).  Second, I believe the discussion of the work-around will 
shed light on the long-term solution.  Third, I think that discussion 
of the work-around and the long-term solution at the same time will 
cause confusion, not provide clarity.  Fourth, I would like to keep 
the good things in RFC 5378 while repairing this problem. Clarity 
about the role of the IETF Trust and clarity about the rights to 
modify code in a way that is acceptable to the open source community 
are the most important things that would be lost by reverting to the 
previous IPR policy.


(3)  "with the advice of Counsel, we believe that this fix represents
a competent, best-efforts, legal-text representation of that principle
and nothing else".

The cover note does not address all of these points.  The Trustees 
did seek legal advice, and Counsel fully support this 
work-around.  As you might imagine, Counsel was heavily involved in 
the discussions as well as the words themselves.  The Trustees are 
trying to provide a near-term work-around within the current BCPs and 
nothing else.

The IETF Trust does not approve BCPs, but the IETF Trust has a role 
in implementing this BCP.  As explained in the cover note:

 > RFC 5378 sections 1.j and 5.3.c provide the IETF Trust with the
 > authority to develop legend text for authors to use in situations where
 > they wish to limit the granting of rights to modify and prepare
 > derivatives of the documents they submit.

Counsel provided very clear justification for this 
interpretation.  My initial reading of RFC 5378 lead me to a 
different conclusion, but I missed some important context in section 
1.j.  I'm glad to say that the Trustees do have the authority to 
implement this work-around if the community supports it.

Finally, the Trustees are not trying to repair RFC 5378.  That task 
is left for the General Area of the IETF.

Russ


At 03:46 PM 1/10/2009, John C Klensin wrote:
>To repeat myself, I will support that fix the moment the
>Trustees' come forward and say, explicitly, "this is the problem
>we are trying to solve, this is the principle we are using as
>the basis of the solution, and, with the advice of Counsel, we
>believe that this fix represents a competent, best-efforts,
>legal-text representation of that principle and nothing else".

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf