Re: Last Call: IPSec DOI Proposed Standard
"Theodore Y. Ts'o" <tytso@MIT.EDU> Fri, 24 April 1998 18:33 UTC
Return-Path: tytso@MIT.EDU
Received: from brittany.cisco.com (brittany.cisco.com [171.69.1.168]) by ftp-eng.cisco.com (8.8.5-Cisco.1/8.6.5) with SMTP id LAA02322 for <ippcp-archive-file@ftp-eng.cisco.com>; Fri, 24 Apr 1998 11:33:17 -0700 (PDT)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by brittany.cisco.com (8.6.12/8.6.5) with ESMTP id LAA11399 for <extdom.ippcp@aliashost.cisco.com>; Fri, 24 Apr 1998 11:32:32 -0700
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by kickme.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id LAA00577 for <ippcp@external.cisco.com>; Fri, 24 Apr 1998 11:32:30 -0700 (PDT)
Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id LAA00551 for <ippcp@external.cisco.com>; Fri, 24 Apr 1998 11:32:26 -0700 (PDT)
Received: from south-station-annex.mit.edu(18.72.1.2) by proxy1.cisco.com via smap (V2.0) id xma000528; Fri, 24 Apr 98 18:32:20 GMT
X-SMAP-Received-From: outside
Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA02083; Fri, 24 Apr 98 14:28:31 EDT
Received: by dcl.MIT.EDU (SMI-8.6/4.7) id OAA17558; Fri, 24 Apr 1998 14:28:30 -0400
Date: Fri, 24 Apr 1998 14:28:30 -0400
Message-Id: <199804241828.OAA17558@dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Avram Shacham <shacham@cisco.com>
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: Avram Shacham's message of Thu, 23 Apr 1998 21:52:51 -0700, <3.0.2.32.19980423215251.006d74c0@pita.cisco.com>
Subject: Re: Last Call: IPSec DOI Proposed Standard
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Thu, 23 Apr 1998 21:52:51 -0700 From: Avram Shacham <shacham@cisco.com> Please do. After all, six weeks ago the IESG approved the publication of IP Payload Compression Protocol (IPComp) _only_ as a Proposed Standard (but waiting for two IPSec docs.) If future experience proves the IPCOMP Transform Identifiers range is too narrow, there is always room for improvements. 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