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

[Paul Koning <[e-mail]>]

>>>>> "Henry" == Henry Spencer <[e-mail]> writes:

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

 Henry> Unfortunately, when an Informational RFC is the sole document
 Henry> discussing how to solve vexing interoperability problems, it
 Henry> tends to become a de-facto standard even if it explicitly
 Henry> disclaims that status.  RFC 1036 was "the standard" for Usenet
 Henry> article formatting for a decade, even though it is (in modern
 Henry> terminology) an Informational RFC.

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

 Henry> We see a very real possibility of approaches which we consider
 Henry> inferior becoming accepted practice, hampering
 Henry> interoperability with better approaches, simply because they
 Henry> are the ones described by the only easily-accessible document
 Henry> on the subject. ...

Henry,

That may be true (I need to do more reading before I'd comment more
strongly) but I have to side with Tim on this.

Let's not throw the baby out with the bathwater.  Yes, there's a need
for more standards-track work.  Standards track RFCs should all have
the property that conformance implies interoperability -- all too
often that isn't true these days.  But meanwhile I feel the situation
is improved by making the knowledge in Tim's document widely
available.  

If any of what it says is technically incorrect (i.e., if you do what
it says in section X you're worse of than if you didn't) that needs to
be fixed.  Is there anything like that?  From what I can tell from the
discussion, no.

If anything it says is less than the full answer (i.e., if you do what
it says in section Y you're better off than if you didn't, but if you
do something different you will also get good results, perhaps even
better ones), that's not a valid argument against progress on this
document.  It isn't, even if this document is "the sole document
discussing how to solve vexing interoperability problems".  That
doesn't prevent anyone from distributing additional information.  It
doesn't prevent the creation of standards track documents that extend
or enhance what's been documented earlier.

If you have other ideas on how to make rekeying work better, please
document them.  That can give rise to additional informational RFCs,
new standards track documents, sections in already-planned documents,
or whatever is appropriate.

If no one steps forward to add to the work that Tim did, his RFC will
remain "the sole document discussing how to solve vexing
interoperability problems".  If that's how things work out, so be it.
I would take that as evidence that no one else cares strongly enough
to add to the work Tim has done -- but not as an argument against
Tim's work.

      paul