Subject: Re: Last call comments about draft-housley-tls-authz-extns-07

From: Bob Braden <[email-masked]>
Date: Mon, 5 Mar 2007 08:53:14 -0800 (PST)

*> 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/

Bob Braden

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: EKR <[email-masked]>
Date: Mon, 05 Mar 2007 09:11:17 -0800

>   *> more cruft to the RFC process, so let's not.

On the general I think I agree with Stephen. While it's important to
give credit to direct antecedents to one's work, this isn't academic
publishing or a patent application and I don't think it's necessary to
cite all prior or related work, especially if the new work is not in
any way derived from the old. On the particular point of this draft,
since the reason that it's being re-LCed is that there are newly
disclosed IPR issues, it might be nice to be clear on what portions
are isomorphic to something that precedes the IPR filing so a reference
might be appropriate.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 5 Mar 2007 09:19:47 -0800

>   *> more cruft to the RFC process, so let's not.

How does adding a downref to a dead document add more integrity to 
the RFC process?

--Paul Hoffman, Director
--VPN Consortium

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Mar 2007 12:39:35 -0500

--On Monday, 05 March, 2007 09:19 -0800 Paul Hoffman
<[email-masked]> 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

on.ietf.org with esmtp (Exim 4.43) id 1HOHAA-00083I-57
	for [email-masked]; Mon, 05 Mar 2007 12:39:54 -0500
Date: Mon, 05 Mar 2007 12:39:35 -0500
From: John C Klensin <[email-masked]>
To: Paul Hoffman <[email-masked]>, Bob Braden <[email-masked]>
Cc: [email-masked]
Subject: References to prior work (was: Re: Last call comments
 about draft-housley-tls-authz-extns-07)

--On Monday, 05 March, 2007 09:19 -0800 Paul Hoffman
<[email-masked]> 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

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 5 Mar 2007 13:26:41 -0500

On Mon, 05 Mar 2007 12:39:35 -0500

> contributors of either ideas or text.

Strong second.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 05 Mar 2007 19:32:35 +0000

> 	which was circulated in 1968."

I think something along these lines might be ok, so long as
its not a significant barrier to progress - I'd hate if every
new author had to be an I-D historian, or if anyone who wanted
to slow down a document could play the system using this. I
have a hard time seeing how that can be done.

Anyway, I think this is an area where the tools team could
come to the rescue yet again, given the right set of
requirements, maybe e.g. including a link to an auto
generated list with the IETF LC announcement. (Before
anyone asks: I'm not volunteering, but would be happy
to chat about it over beer in Prague.)

S.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 5 Mar 2007 12:13:01 -0800

At 12:39 PM -0500 3/5/07, John C Klensin wrote:
>history and context.

Fully disagree. A reference to a dead document that the reader cannot 
find directly provides no histor nor context. A diligent reader might 
use Google et. al., to search for the title, but they are then 
possibly confronted with documents with the same name and no way to 
know which the author meant. That is neither good history nor good 
context.

To be clear: downrefs to living documents that can identified by name 
is clearly a good thing, but downrefs to dead documents reduces the 
credibility of the RFC process because typical readers will ask "why 
can't I find this old Internet Draft" and then get sucked into the 
the vortex of the debates about the IETF keeping a public archive of 
old documents.

>We have learned, or should have learned,

That is not fixed with a reference to a dead document.

>	development for some time.

That can be done much more effectively by other mechanisms that cause 
less confusion to someone reading an RFC than a reference to 
something that they cannot get their hands on.

--Paul Hoffman, Director
--VPN Consortium

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 5 Mar 2007 13:43:47 -0800 (PST)

> have a hard time seeing how that can be done.

They need not be historian, i.e. if they do not know of the existance
of prior related work they don't have to site it, but if they do know
of the existance of have been alerted about it on public list or in
private comments due to their draft, than I'd say acknoledging the
work is required.