[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Last Call: IPSec DOI Proposed Standard

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
>
>
References: