Re: Last Call: IPSec DOI Proposed Standard

[Avram Shacham <[e-mail]>]

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