References to prior work (was: Re: Last call comments about draft-housley-tls-authz-extns-07)

[John C Klensin <john-ietf at jck.com>]

--On Monday, 05 March, 2007 09:19 -0800 Paul Hoffman
<paul.hoffman at vpnc.org> wrote:

> At 8:53 AM -0800 3/5/07, Bob Braden wrote:
>>   *> FWIW, I don't think we want to start bouncing specs
>>   because they *> don't pay homage - in this case all the
>>   similarities are probably *> the only obvious ways to add
>>   authorization tokens to a TLS *> handshake. Such downrefs
>>   to dead documents would anyway add yet *> more cruft to the
>>   RFC process, so let's not.
>>   *>
>>   *> S.
>>   *>
>> 
>> s/cruft/integrity/
> 
> How does adding a downref to a dead document add more
> integrity to the RFC process?

Independent of the merits in this particular case, it provides
history and context.   We have learned, or should have learned,
two things over and over again:

	(1) Failure to provide context and a track through
	rejected and alternative suggestions results in "new"
	proposals to try the same things again, usually from
	people who had no idea about the prior work.
	
	(2) Providing good documentation that recognizes the
	origins of an idea and its date, even if there were some
	changes from the original version, can be very helpful
	in defending our work against patent vultures who try to
	make filings on work that the IETF has had under
	development for some time.  Personally, I've reached the
	point that I would favor having most protocol
	specification RFCs contain a sentence of the form of
	"The work described here derives from a series of
	earlier drafts, including [ref, ref, ref] the first of
	which was circulated in 1968."

In addition, in the general case, it can be argued that
referencing prior work, even "dead drafts" is _required_ by the
obligation to recognize and acknowledge the involvement of
contributors of either ideas or text.

    john



_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf





on.ietf.org with esmtp (Exim 4.43) id 1HOHAA-00083I-57
	for ietf at ietf.org; Mon, 05 Mar 2007 12:39:54 -0500
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOH9t-0003sM-VN
	for ietf at ietf.org; Mon, 05 Mar 2007 12:39:54 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1HOH9r-000NGY-Ru; Mon, 05 Mar 2007 12:39:36 -0500
Date: Mon, 05 Mar 2007 12:39:35 -0500
From: John C Klensin <john-ietf at jck.com>
To: Paul Hoffman <paul.hoffman at vpnc.org>, Bob Braden <braden at ISI.EDU>
Message-ID: <5594485AC2A85A9D4C5C8454 at p3.JCK.COM>
In-Reply-To: <p06240836c21201911228 at [10.20.30.108]>
References: <200703051653.IAA04642 at gra.isi.edu>
	<p06240836c21201911228 at [10.20.30.108]>
X-Mailer: Mulberry/4.0.7 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: ietf at ietf.org
Subject: References to prior work (was: Re: Last call comments
 about draft-housley-tls-authz-extns-07)
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Errors-To: ietf-bounces at ietf.org



--On Monday, 05 March, 2007 09:19 -0800 Paul Hoffman
<paul.hoffman at vpnc.org> wrote:

> At 8:53 AM -0800 3/5/07, Bob Braden wrote:
>>   *> FWIW, I don't think we want to start bouncing specs
>>   because they *> don't pay homage - in this case all the
>>   similarities are probably *> the only obvious ways to add
>>   authorization tokens to a TLS *> handshake. Such downrefs
>>   to dead documents would anyway add yet *> more cruft to the
>>   RFC process, so let's not.
>>   *>
>>   *> S.
>>   *>
>> 
>> s/cruft/integrity/
> 
> How does adding a downref to a dead document add more
> integrity to the RFC process?

Independent of the merits in this particular case, it provides
history and context.   We have learned, or should have learned,
two things over and over again:

	(1) Failure to provide context and a track through
	rejected and alternative suggestions results in "new"
	proposals to try the same things again, usually from
	people who had no idea about the prior work.
	
	(2) Providing good documentation that recognizes the
	origins of an idea and its date, even if there were some
	changes from the original version, can be very helpful
	in defending our work against patent vultures who try to
	make filings on work that the IETF has had under
	development for some time.  Personally, I've reached the
	point that I would favor having most protocol
	specification RFCs contain a sentence of the form of
	"The work described here derives from a series of
	earlier drafts, including [ref, ref, ref] the first of
	which was circulated in 1968."

In addition, in the general case, it can be argued that
referencing prior work, even "dead drafts" is _required_ by the
obligation to recognize and acknowledge the involvement of
contributors of either ideas or text.

    john



_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf