RE: procedural RE: problems with draft-jenkins-ipsec-rekeying-06. txt

Tim Jenkins <TJenkins@Catena.com> Thu, 13 July 2000 20:19 UTC

Message-ID: <310508EDF557D31188FA0050DA0A3752658716@CAT01S2>
From: Tim Jenkins <TJenkins@Catena.com>
To: 'Henry Spencer' <henry@spsystems.net>
Cc: Hugh Redelmeier <hugh@mimosa.com>, IPsec List <ipsec@lists.tislabs.com>, Hugh Daniel <hugh@toad.com>, John Gilmore <gnu@toad.com>
Subject: RE: procedural RE: problems with draft-jenkins-ipsec-rekeying-06. txt
Date: Thu, 13 Jul 2000 12:53:39 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk


> -----Original Message-----
> From: Henry Spencer [mailto:henry@spsystems.net]
> Sent: Thursday, July 13, 2000 12:13 PM
> To: Tim Jenkins
> Cc: Hugh Redelmeier; IPsec List; Hugh Daniel; John Gilmore
> Subject: procedural RE: problems with
> draft-jenkins-ipsec-rekeying-06.txt
> 
> 
> On Thu, 13 Jul 2000, Tim Jenkins wrote:
> > First, my understanding of an information RFC "... does not 
> represent an
> > Internet community consensus or recommendation" ...
> > Given that I believe and have been told by others that the 
> information in
> > this document is of value to IPsec implementors, I wanted 
> to make the
> > information available persistently. The only way that I 
> know how to do that
> > under the current circumstances is to make it an informational RFC.
> 
> Unfortunately, when an Informational RFC is the sole document 
> discussing
> how to solve vexing interoperability problems, it tends to become a
> de-facto standard even if it explicitly disclaims that 
> status.  RFC 1036
> was "the standard" for Usenet article formatting for a 
> decade, even though
> it is (in modern terminology) an Informational RFC. 

This sounds like a problem with the RFC process, not the document.

> 
> There is a crying need for a standards-track effort in this area, but
> currently none is being made. 

Then make the effort. The publication of this document could serve as a
catalyst.

> 
> We see a very real possibility of approaches which we 
> consider inferior
> becoming accepted practice, hampering interoperability with better
> approaches, simply because they are the ones described by the only
> easily-accessible document on the subject.  Pasting a 
> disclaimer on the
> document will not prevent this, not when the document fills a 
> persistent
> and painful vacuum.  Hence our objections.

The alternative is that this document is lost. Is that worse or better than
a examination of the issues and an offered solution that works?

> 
>                                                           
> Henry Spencer
>                                                        
> henry@spsystems.net
>

RE: procedural RE: problems with draft-jenkins-ip… Tim Jenkins