IPComp editorial comments (Re: Working Group Last Call IKEv2)

[Abraham Shacham <shacham@trpz.com>]

Attached please find the IPComp editorial comments for IKEv2,
including in RFC editor format.

Regards,
avram

shacham@trpz.com
shacham@shacham.net

(*) Footnote to the bored reader of this repeated message: The I-D
is in wg last call, so at the most a single repeat is due --
during ietf last call ;-<


Barbara Fraser wrote:
> Hi,
> 
> This is a working group last call for comments on the IKEv2 draft, 
> draft-ietf-ipsec-ikev2-08.txt, for progression to Proposed Standard:
> 
> This last call will expire in three weeks on June 23, 2003.
> 
> thanks,
> Barb and Ted
> 
> 

> -------- Original Message --------
> Subject: IKEv2-05: IPComp (editorial) comments
> Date: Mon, 03 Mar 2003 00:21:59 -0800
> From: Abraham Shacham <shacham@trpz.com>
> To: IP Security List <ipsec@lists.tislabs.com>
> CC: ippcp <ippcp@external.cisco.com>
> 
> 
> s/IPcomp/IPComp/
> s/RFC 2393/RFC 3173/
> 
> In page 54:
> 
>   The Transform IDs currently defined are:
>      Name                     Number       Defined In
>      RESERVED                   0
>      IPCOMP_OUI                 1
>      IPCOMP_DEFLATE             2          (RFC2394)
>      IPCOMP_LZS                 3          (RFC2395)
> 
> Following RFC-3051, add:
> 
>      IPCOMP_LZJH                4          (RFC3051)
> 
> 
 >
 > Thanks,
 > avram
 >

=== the above comments in RFC editor format ===

page 2:

Old:

    2.22 IPcomp.................................................34

New:

    2.22 IPComp.................................................34


page 4:

Old:

    match fashion.  IKE can also negotiate use of IPcomp [RFC2393] in
    connection with an ESP and/or AH SA.  We call the IKE SA an "IKE_SA".

New:

    match fashion.  IKE can also negotiate use of IPComp [RFC3173] in
    connection with an ESP and/or AH SA.  We call the IKE SA an "IKE_SA".

page 11:

Old:

    SAs are nested, as when data (and IP headers if in tunnel mode) are
    encapsulated first with IPcomp, then with ESP, and finally with AH
    between the same pair of endpoints, all of the SAs MUST be deleted

New:

    SAs are nested, as when data (and IP headers if in tunnel mode) are
    encapsulated first with IPComp, then with ESP, and finally with AH
    between the same pair of endpoints, all of the SAs MUST be deleted

page 34:

Old:

2.22 IPcomp

New:

2.22 IPComp

Old:

    implementations of this specification MUST NOT accept an IPcomp
    algorithm that was not proposed, MUST NOT accept more than one, and

New:

    implementations of this specification MUST NOT accept an IPComp
    algorithm that was not proposed, MUST NOT accept more than one, and

Old:

    A side effect of separating the negotiation of IPcomp from
    cryptographic parameters is that it is not possible to propose

New:

    A side effect of separating the negotiation of IPComp from
    cryptographic parameters is that it is not possible to propose

pp 65, 66:

Old:

         IPCOMP_SUPPORTED                         24581

             This notification may only be included in a message
             containing an SA payload negotiating a CHILD_SA and
             indicates a willingness by its sender to use IPcomp on this
             SA. The data associated with this notification includes a
             two octet IPcomp CPI followed by a one octet transform ID
             optionally followed by attributes whose length and format is
             defined by that transform ID. A message proposing an SA may
             contain multiple IPCOMP_SUPPORTED notifications to indicate
             multiple supported algorithms. A message accepting an SA may
             contain at most one.

             The transform IDs currently defined are:

                  NAME         NUMBER  DEFINED IN
                  -----------  ------  -----------
                  RESERVED       0
                  IPCOMP_OUI     1
                  IPCOMP_DEFLATE 2     RFC 2394
                  IPCOMP_LZS     3     RFC 2395


                  values 4-240 are reserved to IANA. Values 241-255 are
                  for private use among mutually consenting parties.

New:

         IPCOMP_SUPPORTED                         24581

             This notification may only be included in a message
             containing an SA payload negotiating a CHILD_SA and
             indicates a willingness by its sender to use IPComp on this
             SA. The data associated with this notification includes a
             two octet IPComp CPI followed by a one octet transform ID
             optionally followed by attributes whose length and format is
             defined by that transform ID. A message proposing an SA may
             contain multiple IPCOMP_SUPPORTED notifications to indicate
             multiple supported algorithms. A message accepting an SA may
             contain at most one.

             The transform IDs currently defined are:

                  NAME         NUMBER  DEFINED IN
                  -----------  ------  -----------
                  RESERVED       0
                  IPCOMP_OUI     1
                  IPCOMP_DEFLATE 2     RFC 2394
                  IPCOMP_LZS     3     RFC 2395
                  IPCOMP_LZJH    4     RFC 3051


                  values 5-240 are reserved to IANA. Values 241-255 are
                  for private use among mutually consenting parties.


page 83:

Old:

    IPcomp Transform IDs

New:

    IPComp Transform IDs


page 85:

Old:

    [IPCOMP]   Shacham, A., Monsour, R., Pereira, R., and Thomas, M., "IP
               Payload Compression Protocol (IPComp)", RFC 2393,
               August 1998.

New:

    [IPCOMP]   Shacham, A., Monsour, R., Pereira, R., and Thomas, M., "IP
               Payload Compression Protocol (IPComp)", RFC 3173,
               September 2001.

=== eom ===