Re: Last Call: IPSec DOI Proposed Standard
Avram Shacham <shacham@cisco.com> Fri, 24 April 1998 19:16 UTC
Return-Path: shacham@cisco.com
Received: from rhine.cisco.com (rhine.cisco.com [171.69.43.21]) by ftp-eng.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA02668 for <ippcp-archive-file@ftp-eng.cisco.com>; Fri, 24 Apr 1998 12:16:42 -0700 (PDT)
Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by rhine.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA10524 for <extdom.ippcp@aliashost.cisco.com>; Fri, 24 Apr 1998 12:15:55 -0700 (PDT)
Received: from pita.cisco.com (pita.cisco.com [171.71.68.13]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id MAA01455 for <ippcp@external.cisco.com>; Fri, 24 Apr 1998 12:15:54 -0700 (PDT)
Received: from shacham-home-pc-4.cisco.com ([171.71.69.80]) by pita.cisco.com (8.8.5-Cisco.1/8.6.5) with SMTP id MAA08349; Fri, 24 Apr 1998 12:15:19 -0700 (PDT)
Message-Id: <3.0.2.32.19980424121326.006a0da8@pita.cisco.com>
X-Sender: shacham@pita.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Fri, 24 Apr 1998 12:13:26 -0700
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
From: Avram Shacham <shacham@cisco.com>
Subject: Re: Last Call: IPSec DOI Proposed Standard
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, "'iesg@ns.ietf.org'" <iesg@ietf.org>, ipsec@tis.com, ippcp@external.cisco.com
In-Reply-To: <199804241828.OAA17558@dcl.MIT.EDU>
References: <Avram Shacham's message of Thu, 23 Apr 1998 21:52:51 -0700, <3.0.2.32.19980423215251.006d74c0@pita.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Ted, I agree that your compromise is more flexible for future changes. Unless other members of the IPPCP wg voice objections, I suggest that both documents (DOI and IPComp) will be modified to reflect your suggestion. Also, the DOI document should be modified to correct the non-accurate wording describing the IPComp protocol: (a) deleting the words "before ESP encryption" in section 4.4.5 and "before ESP" is 6.6, and (b) the term "IP compression" should be modified to "IP payload compression." I hope this process will not delay any of our documents. Comments? avram At 02:28 PM 4/24/98 -0400, Theodore Y. Ts'o wrote: > >Actually, it will be much, much harder to change this in the future if >there are implementations which start assigning CPI's in the range >64-255. This will prevent us from expanding the range in the future for >static transforms, since they will be used for dynamically assigned >values. > >It's clear we will need to make a change to one or the other document, >both of which have been voted on and approved by the IESG (the IPSEC >documents modulo some fixups, including this one). > >One compromise position that we might explore would involve putting text >in the IPSEC documents that reserve the range 64-255 for future >expansion, and so implementations MUST NOT assign CPI's in that range. >This at least gives us the opportunity to allow more "well-known" >transforms in the future. What do people think about this? > >You're right that with only four compression algorithms, this isn't a >big deal either way, and shouldn't be used to delay the documents. On >the other hand, I can't think of any architectural justification to >artificially constrain the ability to expand the number space at this >point in time. It'd be like the original IP designers saying that IP >addresses should be only 28 bits, instead 32, because surely we would >*never* need 2**28 addresses --- never mind that 4 bytes gives you 32 >bits and the cost is the same whether you use 28 or 32 bits. > >Taking the analogy back to IPPCP, if we have 1 full byte available to >us, why not use the whole 8 bits, instead of stopping at 6? Surely we >can spare 192 dynamically assigned CPI's out of over 61,000. (Note that >the compromise I suggested above reserves these 192 dynamically assigned >CPI's so that we have the option in the future to expand the range.) > > - Ted > >
- RE: Last Call: IPSec DOI Proposed Standard Avram Shacham
- Re: Last Call: IPSec DOI Proposed Standard Theodore Y. Ts'o
- Re: Last Call: IPSec DOI Proposed Standard Avram Shacham
- Re: Last Call: IPSec DOI Proposed Standard Naganand Doraswamy
- Re: Last Call: IPSec DOI Proposed Standard Derrell D. Piper
- Re: Last Call: IPSec DOI Proposed Standard Theodore Y. Ts'o
- Re: Last Call: IPSec DOI Proposed Standard Avram Shacham
- Re: Last Call: IPSec DOI Proposed Standard Theodore Y. Ts'o
- Re: Last Call: IPSec DOI Proposed Standard Avram Shacham
- Re: Last Call: IPSec DOI Proposed Standard Naganand Doraswamy