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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At 12:39 PM -0500 3/5/07, John C Klensin wrote:
--On Monday, 05 March, 2007 09:19 -0800 Paul Hoffman
<paul.hoffman@xxxxxxxx> 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.

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,
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.

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

	(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.

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

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]