Re: IETF Last Call for two IPR WG Dcouments

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 26 March 2008 04:25 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietfarch-ietf-archive@core3.amsl.com
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 095DB3A6BE2; Tue, 25 Mar 2008 21:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.053
X-Spam-Level:
X-Spam-Status: No, score=-100.053 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 hthdeZ1NdwtV; Tue, 25 Mar 2008 21:25:47 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74D128C111; Tue, 25 Mar 2008 21:25:46 -0700 (PDT)
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 79DF73A687C; Tue, 25 Mar 2008 21:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 vlzJsF-ea4s2; Tue, 25 Mar 2008 21:25:44 -0700 (PDT)
Received: from bender-mail.tigertech.net (bender-mail.tigertech.net [64.62.209.30]) by core3.amsl.com (Postfix) with ESMTP id 597EB3A67F4; Tue, 25 Mar 2008 21:25:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 39B5D7DE2; Tue, 25 Mar 2008 21:23:25 -0700 (PDT)
Received: from [10.10.10.101] (pool-71-161-50-201.clppva.east.verizon.net [71.161.50.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id E3B9A7DBD; Tue, 25 Mar 2008 21:23:23 -0700 (PDT)
Message-ID: <47E9CFB4.7060303@joelhalpern.com>
Date: Wed, 26 Mar 2008 00:23:16 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
Subject: Re: IETF Last Call for two IPR WG Dcouments
References: <20080324200545.D6E6328C3AE@core3.amsl.com> <47E9C36E.5080405@stpeter.im>
In-Reply-To: <47E9C36E.5080405@stpeter.im>
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net
Cc: ietf@ietf.org, ipr-wg@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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Comments in response to your comments on -outbound...
Firstly, thank you for reading these.
Second, what follows are my understandings of the reasons / contents.

Peter Saint-Andre wrote:
> Russ Housley wrote:
>> During the Wednesday Plenary at IETF 71, I gave the IETF community a 
>> "heads up" on two documents from the IPR WG that were nearing IETF 
>> Last Call.  Both of the documents have now reached IETF Last 
>> call.  The Last Call announcements are attached.  Please review and comment.
> 
> I've given these drafts a first reading. The following comments may
> represent a misunderstanding on my part, but I provide them in the
> interest of clarifying the meaning of these drafts.
> 
> One concern I have is the distinction between text and code. Where and
> how is that line drawn? What about, for example, protocol examples (of
> which there are many in most RFCs)? Are they text or code?

The document provides two ways to distinguish code from text.  It lists 
a set of constructs that are considered code.  Recognizing that things 
change, the draft indicates that the trustees shall maintain a list of 
such code.  The also says that the trustees shall come up with a marking 
mechanism so working groups can mark other things that need to be 
considered code, since there are often special cases.

This distinction was the working group rough consensus (as determined by 
the chairs), after MUCH discussion.

> 
> Another concern is the limitation on copying of text. It seems quite
> reasonable for developers to include snippets of text in their programs
> (think literate programming), and under many code licenses it is
> difficult if not impossible to separately license the code and any
> copied text when bundled together.

The question of whether to allow arbitrary modifications of all text 
from RFCs was discussed.  While there are some drawbacks of the 
agreement that was reached, in terms of the ability to use text from the 
RFC as documentation in programs which by license are subject to 
arbitrary change, there are also serious concerns about allowing 
arbitrary changes of text.  The text of RFCs often represents careful 
work to get the right meaning.  Arbitrary, well intentioned changes, may 
often introduce unintended problems.  (The discussion covered many 
related aspects, many of which I can not recreate on the fly.)
Obviously, this is closely related to the decision to create the code / 
text distinction.

> 
> Regarding the copying of text, Section 4.4 of the outgoing draft says:
> 
>    There is no consensus at this time to permit the use of text from
>    RFCs in contexts where the right to modify the text is required.  The
>    authors of IETF contributions may be able and willing to grant such
>    rights independently of the rights they have granted to the IETF by
>    making the contribution.
> 
> But Section 6 of the incoming draft says:
> 
>    It is also important to note that additional copyright notices are
>    not permitted in IETF Documents except in the case where such
>    document is the product of a joint development effort between the
>    IETF and another standards development organization or the document
>    is a republication of the work of another standards development
>    organization.  Such exceptions must be approved on an individual
>    basis by the IAB.
> 
> So it's not clear to me how contributors could (easily) grant the right
> to modify text that is copied from an RFC -- unless they do so outside
> the Internet Standards Process (based, I suppose, on the rights retained
> by the contributors). However, it seems that each implementor would need
> to separately approach the contributors in order to do that (and how
> would they know that the contributors are approachable in that way if
> not through inclusion of some kind of notice in the relevant RFC -- and
> would such a notice comprise an "additional copyright notice" as
> described in Section 6 fo the incoming draft?).
Indeed, any such grant would have to be outside the IETF process.  A 
legal notice is not what is needed to let folks know there are other 
options.  An informational note is quite different from a legal notice.

> 
> Finally, the outbound draft merely provides recommendations regarding
> license text and other materials, final definition of which seems to be
> under the sole purview of the Trustees of the IETF Trust. However, the
> outbound draft does not specify if the work of the Trustees shall be
> subject to review by the IPR WG, the IESG, the IAB, or the IETF
> community (e.g., in the form of an Internet-Draft) before it takes effect.

The decision to exclude legal text from the outbound document was a 
deliberate working group decision.  Having working groups write legal 
text has produced problems repeatedly.  So we concluded that was a bad 
way to proceed.  The question of how the trust will proceed to do its 
job is outside of this working groups purview.  The trustees have said 
it will take direction from the IETF.  I presume they will come up with 
a reasonable strategy for verifying that what they produce does what the 
community has said it wants.
In the worst case, if the community concludes that the trustees actions 
aren't what we want, we can either replace the trustees or write another 
IETF RFC.  Trying to work that out in this draft did not seem productive.

> 
> Peter

Yours,
Joel M. Halpern
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf