5378 - one purpose

Black_David@emc.com Mon, 12 January 2009 17:46 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 CF05A28C37F; Mon, 12 Jan 2009 09:46:21 -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 D12C23A6A36; Sun, 11 Jan 2009 14:03:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level:
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 dXG70a9ZYTF9; Sun, 11 Jan 2009 14:03:08 -0800 (PST)
Received: from mexforwardwc.lss.emc.com (mexforwardwc.lss.emc.com [137.69.117.200]) by core3.amsl.com (Postfix) with ESMTP id 17BAE3A6962; Sun, 11 Jan 2009 14:03:07 -0800 (PST)
Received: from scl02-01d02-si01.isus.emc.com (scl02-01d02-si01.isus.emc.com [137.69.225.84]) by mexforwardwc.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n0BM2niW016956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 14:02:49 -0800 (PST)
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by scl02-01d02-si01.isus.emc.com (Tablus Interceptor); Sun, 11 Jan 2009 14:02:42 -0800
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n0BM2eUI013422; Sun, 11 Jan 2009 17:02:41 -0500 (EST)
From: Black_David@emc.com
Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Jan 2009 17:02:40 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: 5378 - one purpose
Date: Sun, 11 Jan 2009 17:02:40 -0500
Message-ID: <9FA859626025B64FBC2AF149D97C944A01074D8B@CORPUSMX80A.corp.emc.com>
In-Reply-To: <44D118A7DDE76EE60062D389@PST.jck.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: 5378 - one purpose
Thread-Index: AclyfCO7VbCPlSy+QLabZroTvusVcgBukm7Q
References: <70873A2B7F744826B0507D4B84903E60@noisy><FB8A848E-E415-4CDE-9E3F-5C74A5614F18@cisco.com><F857DDBB-CDEE-48A8-B59C-56AEDA65CE79@cs.tcd.ie> <44D118A7DDE76EE60062D389@PST.jck.com>
To: john-ietf@jck.com
X-OriginalArrivalTime: 11 Jan 2009 22:02:40.0635 (UTC) FILETIME=[5268A4B0:01C97438]
X-RSA-Inspected: yes
X-RSA-Classifications:
X-RSA-Action: allow
X-Mailman-Approved-At: Mon, 12 Jan 2009 09:46:18 -0800
Cc: trustees@ietf.org, wgchairs@ietf.org, ietf@ietf.org, Black_David@emc.com, rfc-editor@rfc-editor.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

John,

> If I'm correct and transfer of a Standard to another SDO is
> really a non-issue, then perhaps the question of what problem(s)
> 5378 was intended to solve becomes more relevant... or perhaps
> it does not.  But, given the problems the 5378/5377 model has
> turned out to create, eliminating one of the major claimed
> reasons for creating that model makes it much easier to consider
> just repealing the things and doing a small update to 3978/4748
> to de-glitch them.

My recollection of one of the major problems that 5378 was
intended to solve is allowing use of text from IETF standards
outside of the IETF.  Two specific examples are:
1) Use of code from an RFC in an implementation.  This often
	requires the ability to modify the code in some minor
	ways.
2) Use of text from an RFC in another standard.  This is *not*
	transfer of the standard, but rather allowing use of
	the actual text in a different standard that does
	something similar.
The pre-5378 copyright rules block both of these.

The ipr WG spent a great deal of time discussing code use, and
whether to apply the same provisions to text (ultimately, the
same provisions were not applied).  I have personally been in a
situation where an editor in another standards organization had
to do a complete rewrite of a large quantity of text obtained
from an RFC because the IETF could not grant copyright
permission independent of whether the IETF wanted to grant
that permission or not.

Regardless of the mess that's been made for revisions of
documents that used the old rules, I doubt that a "de-glitch"
effort on 3978/4748 can address the two examples noted above, 
as both require additional permissions from authors that the
IETF has not obtained in the past (and hence that the IETF
does not have for documents created under past rules).

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf