[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: IPSec DOI Proposed Standard
At 04:55 PM 4/23/98 -0400, Theodore Y. Ts'o wrote:
[...]
> As for the numeric range of the IPComp Transform Identifiers - in Munich,
> the IPPCP working-group decided - given the number of existing compression
> algorithms - to allocate the IDs 1-63 for such known algorithms. The
> decision is reflected in the IPComp I-D. The DOI document did not follow
> this decision.
>
>Our apologies. Both I and the DOI editor were not aware of this
>decision.
The DOI editor _is_ a member of the IPPCP mailing list from day one, so he
must have been aware of the wg decisions in Munich. Also, I pointed these
inconsistencies to the DOI editor in several private email messages many
weeks ago.
>That being said, could you enlighten us as to why the ippcp
>wg made that decision?
Currently, the market offers 4 (four) compression algorithms. The IPPCP wg
felt that less than 50 (fifty) new algorithms are expected in the
foreseeable future.
>We can very easily make the DOI document state that the number of
>transforms is limited to the range 0-63 (despite the fact that the
>ISAKMP protocol has room for 8 bits), with say 0-53 to be assigned by
>the IANA, and 54-63 to be used by mutually consenting implementations.
>It would seem to me to be limiting the number space unnecessarily,
>though.
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.
Regards,
avram
Follow-Ups:
References: