RE: problems with draft-jenkins-ipsec-rekeying-06.txt
Henry Spencer <henry@spsystems.net> Tue, 18 July 2000 00:07 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA27084; Mon, 17 Jul 2000 17:07:21 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16480 Mon, 17 Jul 2000 18:27:58 -0400 (EDT)
Date: Mon, 17 Jul 2000 18:36:03 -0400
From: Henry Spencer <henry@spsystems.net>
To: Andrew Krywaniuk <andrew.krywaniuk@alcatel.com>
cc: hugh@mimosa.com, 'Tim Jenkins' <TJenkins@Catena.com>, 'IPsec List' <ipsec@lists.tislabs.com>, 'Hugh Daniel' <hugh@toad.com>, 'John Gilmore' <gnu@toad.com>
Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt
In-Reply-To: <001101bff024$5cba37e0$d23e788a@andrewk3.ca.newbridge.com>
Message-ID: <Pine.BSI.3.91.1000717181505.18264I-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Mon, 17 Jul 2000, Andrew Krywaniuk wrote: > Internet drafts are written in a mix of English and jargon; sometimes the > two languages overlap and it confuses people. I don't actually think that's an issue here... > Obviously, Dan knows what the > intent of the wording in the IKE RFC is; I don't see how you can argue with > that. Most of the rest of us figured it out as well. The problem with standards which rely on "well, everybody knows that where it says WX_Z it really means WXQZ" is precisely that not everybody *does* know. Dan surely knows what the RFC was supposed to say, but that's not what it actually says. Moreover, I think this has slightly missed our point. We are not just arguing that there is a different interpretation possible here, or that it is the preferred interpretation in the absence of supplementary folklore (although we do make both those claims). We contend that our interpretation is *superior*. It improves the protocol's robustness, and permits solving certain vexing problems in a much simpler way than Tim Jenkins proposes, and does this (as verified by both analysis and practical experience) without introducing significant implementation difficulties or interoperability problems. The primary criterion for choice when resolving ambiguities should be technical merit, not closeness to the original intent. Henry Spencer henry@spsystems.net
- problems with draft-jenkins-ipsec-rekeying-06.txt D. Hugh Redelmeier
- RE: problems with draft-jenkins-ipsec-rekeying-06… Tim Jenkins
- procedural RE: problems with draft-jenkins-ipsec-… Henry Spencer
- RE: problems with draft-jenkins-ipsec-rekeying-06… D. Hugh Redelmeier
- Re: procedural RE: problems with draft-jenkins-ip… Paul Koning
- RE: problems with draft-jenkins-ipsec-rekeying-06… Andrew Krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… Mason, David
- Re: problems with draft-jenkins-ipsec-rekeying-06… Dan Harkins
- Re: problems with draft-jenkins-ipsec-rekeying-06… Dan Harkins
- RE: problems with draft-jenkins-ipsec-rekeying-06… D. Hugh Redelmeier
- RE: problems with draft-jenkins-ipsec-rekeying-06… Andrew Krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… Henry Spencer
- Re: problems with draft-jenkins-ipsec-rekeying-06… Dan Harkins
- RE: problems with draft-jenkins-ipsec-rekeying-06… andrew.krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… Henry Spencer
- RE: problems with draft-jenkins-ipsec-rekeying-06… Paul Koning
- RE: problems with draft-jenkins-ipsec-rekeying-06… Andrew Krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… andrew.krywaniuk
- RE: problems with draft-jenkins-ipsec-rekeying-06… Paul Koning
- RE: problems with draft-jenkins-ipsec-rekeying-06… D. Hugh Redelmeier
- RE: problems with draft-jenkins-ipsec-rekeying-06… Andrew Krywaniuk