Re: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem

Dean Willis <dean.willis@softarmor.com> Thu, 29 January 2009 06: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 978333A6C1F; Wed, 28 Jan 2009 22:46:13 -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 C78923A6C1F; Wed, 28 Jan 2009 22:46:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.536
X-Spam-Level:
X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599]
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 kun53yXcFXdq; Wed, 28 Jan 2009 22:46:11 -0800 (PST)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B251F3A69CA; Wed, 28 Jan 2009 22:46:11 -0800 (PST)
Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id n0T6joDk025608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 Jan 2009 00:45:52 -0600
Message-Id: <1E25B7A3-03A1-472F-8E42-07EB186E4581@softarmor.com>
From: Dean Willis <dean.willis@softarmor.com>
To: Bob Braden <braden@ISI.EDU>
In-Reply-To: <6.1.2.0.2.20090121100156.02670878@boreas.isi.edu>
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem
Date: Thu, 29 Jan 2009 00:45:45 -0600
References: <70873A2B7F744826B0507D4B84903E60@noisy> <54974382E5FF41D3A40EFDF758DB8C49@DGBP7M81> <20090112211809.515993A67EA@core3.amsl.com> <A2460A3CBF9453B10BC02375@PST.jck.com> <20090112221608.5659A3A67EA@core3.amsl.com> <7FCA5612-AACD-404A-A454-E72AB9A5F51E@softarmor.com> <6.1.2.0.2.20090121100156.02670878@boreas.isi.edu>
X-Mailer: Apple Mail (2.930.3)
Cc: John C Klensin <john-ietf@jck.com>, trustees@ietf.org, 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-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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Jan 21, 2009, at 12:16 PM, Bob Braden wrote:

> At 11:58 PM 1/20/2009, Dean Willis wrote:
>
>
>
>
>
>> Given that we've historically weeded out the contributor-list on a
>> document to "four or less", even if there were really dozens of
>> "contributors" at the alleged insistence of the RFC Editor, I don't
>> see how any older document or even a majority of new documents-in-  
>> progress could be adapted to the new rules.
>
>
> Whoa!  This contains several errors of fact and implication.  The  
> number authors named
> on the front page of  an RFC are generally limited to 5 (there are  
> occasional exceptions for
> good cause).  This rule was arrived at after discussions in
> the IETF and it has enjoyed general community support; it was not  
> "at the insistence of the RFC
> Editor".  The RFC Editor 's role was to alert the community to a  
> tendency towards
> ballooning of author lists when every telecomm vendor wanted their  
> name on the
> RFC, and perhaps it is true that the magic number "5" (which could  
> have been 4 or 6 or ....)
> was chosen and documented by the RFC Editor.  Otherwise, it was a  
> community
> consensus.
>
> At the time that the 5 limit was put in place, a new Contributors  
> section was added to RFCs
> to contain the overflow authors/contributors.

Yes, 5 is the number I should have said, and I'll accept your  
description of the history involved. Note my use of the term "alleged"  
in ascribing the origin to RFCEd; it is what I recall my AD telling me  
at the time. As the judge might say, this is "hearsay", and  
inadmissible in court ;-).

>
>
> It is my personal opinion, based on this history, that for IPR  
> purposes we ought to treat
> those listed in the Contributors sections as having equal copyrights  
> to those named on
> the front page.  (Maybe the Contributors section ought to come early  
> in the RFC, rather
> than late. but that would be another discussion.)  OTOH, the RFC  
> Editor recoils from the
> idea that those in the Contributors section should logically be  
> included in the AUTH48
> process; let's not!.
>

I concur that Contributors need to be considered from a copyright/IPR  
perspective.

The problem is that every RFC I'm aware of that was produced by a  
working contains tens to hundreds of contributions made either on- 
list, off-list (direct to an editor, or indirectly through another  
contributor and onto an editor) or made verbally, possibly at a  
microphone, possibly in a hallway discussion, or possibly at a meeting  
of an entirely different SDO, such as 3GPP or OMA, and relayed  
directly or indirectly into IETF.

We don't track these in the Author's section, and generally only the  
most vigorous of such contributors are noted as Contributors in common  
practice. We might have to change this, and Theo has outlined one  
procedure for doing so using source-control, although we'd need to  
extend this to cover the additional contribution channels (which could  
be really hard).

While NEW contributions brought into IETF might ostensibly be covered  
by our "Note Well", it seems that this would NOT apply to any document  
currently in-progress, or any document derived from a pre-5378 document.

Consequently, the only way to develop a document that I could sign off  
as being "RFC 5378 compliant" in the fullest sense would be clean-room  
development; that is, it would have to be started post-5378, copy no  
text from pre-5378 documents (or external specifications), and have  
the provenance of every contribution to the document carefully  
recorded for the purpose of tracking the assignment and assignability  
of rights related to that contribution. Even then, it could get foiled  
by somebody accidentally including a blurb overheard at a 3GPP  
meeting; while this might protect the IETF's liability, it could still  
taint the document. Of course, that's nothing new, and we've lived  
with that aspect so far.

Otherwise said, since we don't have a record of the contributions made  
to pre-5378 documents, we can never be sure that the rights necessary  
to publish the document with a full assignment-of-rights ala RFC 5378  
have actually been granted. At best, we can assume that the untracked  
contributions were made under the IPR terms of the time, which  
obviously have a lesser scope than RFC 5378. So the only thing we can  
do with any documents that were discussed on-list, a a meeting, or  
otherwise contain pre-5378 contributions is to publish them with a  
restricted rights statement.

Caveat: I'm not a lawyer. I professionally consult to lawyers about  
technical aspects of intellectual property, and this whole thing makes  
my head throb worse than tensor calculus. I hope I'm completely wrong  
about everything I think I understand.

--
Dean

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf