Re: Boilerplate text

"TS Glassey" <tglassey@earthlink.net> Fri, 01 August 2008 00:39 UTC

Return-Path: <ipr-wg-bounces@ietf.org>
X-Original-To: ipr-wg-archive@megatron.ietf.org
Delivered-To: ietfarch-ipr-wg-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118CF28C370; Thu, 31 Jul 2008 17:39:58 -0700 (PDT)
X-Original-To: ipr-wg@core3.amsl.com
Delivered-To: ipr-wg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD33B28C36B for <ipr-wg@core3.amsl.com>; Thu, 31 Jul 2008 17:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.579
X-Spam-Level:
X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
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 0ALBM-5Izjs3 for <ipr-wg@core3.amsl.com>; Thu, 31 Jul 2008 17:39:55 -0700 (PDT)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id E87B43A6950 for <ipr-wg@ietf.org>; Thu, 31 Jul 2008 17:39:26 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=JOqWRzyQmabTWLAIKAKMNJwceXSH8rzqKbrtuQsETHf8EumqSk77nlgLCLFMokHR; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [24.23.176.93] (helo=tsg1) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <tglassey@earthlink.net>) id 1KOifr-00077h-U5; Thu, 31 Jul 2008 20:39:16 -0400
Message-ID: <001201c8f36f$08379940$6401a8c0@tsg1>
From: TS Glassey <tglassey@earthlink.net>
To: Bill Fenner <fenner@fenron.com>, ipr-wg@ietf.org
References: <54e226890807311617y61f1a366k9db181332c60eac0@mail.gmail.com>
Subject: Re: Boilerplate text
Date: Thu, 31 Jul 2008 17:06:18 -0700
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79d356cadae823f13232fe80285c5fe67e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 24.23.176.93
X-BeenThere: ipr-wg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPR-WG <ipr-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipr-wg>, <mailto:ipr-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipr-wg>
List-Post: <mailto:ipr-wg@ietf.org>
List-Help: <mailto:ipr-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipr-wg>, <mailto:ipr-wg-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ipr-wg-bounces@ietf.org
Errors-To: ipr-wg-bounces@ietf.org

----- Original Message ----- 
From: "Bill Fenner" <fenner@fenron.com>
To: <ipr-wg@ietf.org>
Sent: Thursday, July 31, 2008 4:17 PM
Subject: Boilerplate text


> I'm trying to apply the boilerplate text to a 1id-guidelines update.
> Was the word "the" left off between the copyright year and "IETF
> Trust" on purpose?  i.e., is "Copyright 2008 IETF Trust and Bill
> Fenner.  All rights reserved." the intended usage?
>
> Here is a new section 3 for 1id-guidelines:
>
> 3.  IPR-Related Notices Required in Internet-Drafts
>
>   All Internet-Drafts must have the following intellectual property
>   rights (IPR) and copyright statements on the first page:

This isnt something that should be in an Internet Draft... The Draft doesnt 
need to have anything in it about the terms and conditions it was subitted 
to the IETF under if there is only one set of terms for that submission that 
are being accepted now.

The ONLY thing the I-D needs in it is the outgoing license and anything else 
creates a new set of liabilities and responsibilities of the IETF. Ones that 
even IPR's words on paper cannot make go away.

That said the I-D itself should not be a part of the contract for submission 
of the IP that the I-D contains. Only a neophyte contract's person would 
embed the incoming release in the actual work-product itself. That is plain 
silly (actually I wanted to use a word that would give Harald grounds to be 
himself again but I am holding my toung - err fingers here).

Rather the submission process should be a separate and complete document 
which codifes all of the terms and conditions for participating, but hey, 
that wouldnt be elegant eh? - The point is simply that the participation 
process shouldnt be split across multiple documents.

To accomplish that I suggest that RFC2026 (what's left of it), 28, and the 
BCP79 sections pertaining to the "relying party contract" are placed into 
one document and those portions regarding the License to the IETF for the IP 
and BCP78 are placed in a single Submissions Document, and these two new 
document's will supersceed the previous document's.

>   All Internet-Drafts must have the following intellectual property
>   rights (IPR) and copyright statements on the first page:

Again - so what - why say this to the relying party? this is a statement for 
the submitter and no one else. The relying parties already know this because 
its said in BCP79 with the outgoing license statament;

>
>   "This Internet-Draft is submitted to IETF pursuant to, and in full
>   conformance with, the provisions of BCP 79.
>
>   Copyright [year] IETF Trust and [the listed authors].  All rights
>   reserved.
>
>   This document is subject to BCP 78 and the IETF Trust's Legal
>   Provisions Relating to IETF Documents.  Please review these documents
>   carefully, as they describe your rights and restrictions with respect
>   to this document.

Again - links to the actual document's that spell out exactly these sets of 
terms would be better than nothing. Telling somone to review IETF document's 
doesnt necessarily school them for that task. .

>
>   (See Trust Guidance [TrustGuidance] section 6a. and 6c.)
>
>   [year] in the copyright statement should be replaced by the year of
>   publication of the document, and [the listed authors] should be
>   replaced by the authors of the document.  Normal english list form
>   should be used, e.g., "IETF Trust and A. Nonymous" but "IETF Trust,
>   J. Blow and T. Rex".
>
>   Any submission which does not include these statements will be
>   returned to the submitter.  The IETF Secretariat will NOT add this
>   text.

The Secretariate's adding that text creates a new document. I have said this 
several times already but the significance of that has been ignored.

>
>
> Is "the IETF Trust's Legal Provisions Relating to IETF Documents" the
> right way to refer to this document?  Should I refer to it that way in
> the parenthetical comment too instead of my shorthand of "Trust
> Guidance"?

I would use a simpler term set. Something like

"IETF Document's are made available under the following terms and 
conditions" a really simple way of saying "uh, yo' this is how you do 
it."...

>
> When I was updating section 4 (which talks about the optional
> restrictions in 6b.) I ran across a minor hiccough -- 3978 allows the
> 6.b.ii. statement, "This document may not be modified, and derivative
> works of it may not be created, and it may not be published except as
> an Internet-Draft.", to be split into two: "This document may not be
> modified, and derivative works of it may not be created." and "This
> document may only be posted in an Internet-Draft." are in different
> sections of 3978.  The section of 3978 that mentions this also
> mentions optionally giving extra permissions for MIBs/PIBs published
> with this restriction: "other than to extract section XX as-is for
> separate use."

What exactly does 'this document can only be posted as an internet-draft' 
mean really? shouldn't this actually say something like This document will 
not be advanced as an RFC or Will Not Be Advanced as a Standards Track 
Document...

The problem is the ethical controls on Standards Tracks Document's and their 
requirement's need to be the same for I-D's and those advanced to RFC 
status. All of the IPR issues need to be addressed, and all of the release 
issues need to be met so that the conveyance of the IP to the IETF can be 
perfected as can the relying parties use of that IP through the Outgoing 
License Terms.

>
> -incoming only mentions that there are instructions in the Legend
> Instructions, which I assume are the same as the IETF Trust's Legal
> Provisions Relating to IETF Documents, so I can't really tell from
> that whether the wg intentionally removed these options; the trust
> intentionally removed these options; the trust unintentionally removed
> these options; or other.
>
> Thanks,
>  Bill
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/ipr-wg
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.138 / Virus Database: 270.5.10/1584 - Release Date: 7/31/2008 
> 12:00 PM
>
>
> 

_______________________________________________
Ipr-wg mailing list
Ipr-wg@ietf.org
https://www.ietf.org/mailman/listinfo/ipr-wg