Re: [Trustees] Last Call for Comments: Proposed work-around to thePre-5378 Problem

Marshall Eubanks <tme@multicasttech.com> Mon, 09 February 2009 23:11 UTC

Return-Path: <tme@multicasttech.com>
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 4F6153A6967; Mon, 9 Feb 2009 15:11:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.465
X-Spam-Level:
X-Spam-Status: No, score=-103.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 ULiKlA1x4kC2; Mon, 9 Feb 2009 15:11:06 -0800 (PST)
Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id CBD1B3A6944; Mon, 9 Feb 2009 15:11:05 -0800 (PST)
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14579065; Mon, 09 Feb 2009 18:10:08 -0500
Message-Id: <ACFC88ED-E2B0-40A7-BB37-454A5C13A84D@multicasttech.com>
From: Marshall Eubanks <tme@multicasttech.com>
To: Thomas Narten <narten@us.ibm.com>
In-Reply-To: <200902092227.n19MQvn3030778@cichlid.raleigh.ibm.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: [Trustees] Last Call for Comments: Proposed work-around to thePre-5378 Problem
Date: Mon, 09 Feb 2009 18:11:05 -0500
References: <50E312B117033946BA23AA102C8134C6031B3C07@SDCPEXCCL2MX.wilmerhale.com> <200902092227.n19MQvn3030778@cichlid.raleigh.ibm.com>
X-Mailer: Apple Mail (2.930.3)
Cc: Trustees <trustees@ietf.org>, SM <sm@resistor.net>, "Contreras, Jorge" <Jorge.Contreras@wilmerhale.com>, 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-Archive: <http://www.ietf.org/mail-archive/web/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: Mon, 09 Feb 2009 23:11:07 -0000

On Feb 9, 2009, at 5:26 PM, Thomas Narten wrote:

>> Ok, I think (hope) I understand the intention now.  How about the
>> following as a friendly clarifying amendment to the proposed text:
>
> Sorry, I'm still not happy with the proposed text. I think it is still
> not clear. It is the simple English I have issue with. But maybe I
> have just been looking at this too hard for too long now. :-(
>
>> NEW PROPOSED
>
>> c. Derivative Works and Publication Limitations.  If a Contributor
>> desires to limit the right to make modifications and derivative works
>> of,
>
> Right. This presumably handles the case where the contributer doesn't
> allow anything but publication as an ID. i.e., case (i)
>
>> or to publish,
>
> Publish as what? an RFC?
>
> Also, now we are already getting ambiguous. I assume that "limit the
> right to" prepends this, but this is not 100% clear. Maybe the
> contributer only desires to "publish" the document. :-)
>
>> an IETF Contribution that is not a standards-track
>> document or, in most cases, a working group document,
>
> I'm not sure why this text is needed actually. This text is really
> supposed to point out that documents that don't allow the IETF the
> right to produce derivative works can't normally be WG documents or
> standards track. But that is an implication of the contributer
> choosing to limit derivative works. Normally, the contributor is NOT
> submiting a document with such a restriction because they wish that it
> not be standards track or a WG document.
>
> This clause has been in the document for sometime. I wonder if it is
> even needed at all to address the motivation for using the modified
> boilerplate.
>
>> then one of the
>> notices in clause (i) or (ii) below must be included.
>
> For the above text to be more clear, I'd suggest something like:
>
> NEW PROPOSED
>
>    c. Derivative Works and Publication Limitations.  If a Contributor
>       desires to limit the right to make modifications and derivative

s/desires/needs/

I don't think that "desires" is appropriate here - as John pointed  
out, the contributor has no discretion here, except for their  
judgement as to whether rights are available.

Regards
Marshall



>
>       works of an IETF Contribution, then one of the notices in
>       clause (i) or (ii) below must be included. Note that a
>       contribution with such a clause cannot become a Standards Track
>       document or, in most cases, a working group document,
>
> IMO, the specific clauses (i) and (ii) make it amply clear why one
> would choose one or the other, so no additional elaboration is needed
> above.
>
> The rest of the proposed text:
>
> 	If an IETF Contribution contains pre-5378 Material as to which
> 	the IETF Trust has not been granted, or may not have been
> 	granted, the necessary permissions to allow modification of
> 	such pre-5378 Material outside the IETF Standards Process,
> 	then the notice in clause (iii) may be included by the
> 	Contributor of such IETF Contribution to limit the right to
> 	make modifications to such pre-5378 Material outside the IETF
> 	Standards Process.
>
> is OK with me.
>
> Thomas
> _______________________________________________
> Trustees mailing list
> Trustees@ietf.org
> https://www.ietf.org/mailman/listinfo/trustees