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
- Boilerplate text Bill Fenner
- Re: Boilerplate text TS Glassey
- Re: Boilerplate text Stephan Wenger
- Re: Boilerplate text TS Glassey