Date: Fri, 13 Oct 2000 07:17:24 -0700 (PDT)
From: Avram Shacham <shacham@shacham.net>
To: ippcp@external.cisco.com
cc: ipsec@lists.tislabs.com
Subject: Re: I-D ACTION:draft-shacham-ippcp-rfc2393bis-06.txt


Attached is the content diff between versions -05 and -06 of
rfc2393bis.  The changes reflect the discussions at the VPN workshop
in San Diego last month.

The first three changes are language-related.  The intent is to
clarify few words and phrases, while keeping the meaning identical.

The fourth change is the addition of an implementation note on yet
another aspect of using well-known CPIs.  The issue was detailed in
the minutes of the town-hall meeting that were posted to the lists
recently.

Acknowledgment: Many thanks to Hugh Redelmeier (hugh@mimosa.com) for
his enlightening remarks.

Your comments are appreciated,
avram


274,275c274,275
<         0-63 define well-known compression algorithms, which require no
<         additional information, and are used for manual setup.  The
---
>         0-63 designate well-known compression algorithms, which require
>         no additional information, and are used for manual setup.  The
305,311c305,318
<    selected compression algorithm.  The IPComp mode of operation is
<    either a node-to-node policy where IPComp is applied to every IP
<    packet between the nodes, or an ULP session based policy where only
<    selected ULP sessions between the nodes are using IPComp.  For each
<    IPCA, a different compression algorithm may be negotiated in each
<    direction, or only one direction may be compressed.  The default is
<    "no IPComp compression".
---
>    selected compression algorithm.  
> 
>    The policy for establishing IPComp may be either a node-to-node
>    policy where IPComp is applied to every IP packet between the nodes,
>    or a session-based policy where only selected sessions between the
>    nodes employ IPComp.
> 
>    Two nodes may choose to negotiate IPComp in either or both
>    directions, and they may choose to employ a different compression
>    algorithm in each direction.  The nodes MUST, however, negotiate a
>    compression algorithm in each direction for which they establish an
>    IPCA: there is no default compression algorithm.
> 
>    No compression algorithm is mandatory for an IPComp implementation.
353c360
<          To suggest a non-default Encapsulation Mode (such as Tunnel
---
>          To propose a non-default Encapsulation Mode (such as Tunnel
388a400,417
>    Implementation note:
> 
>       IPCAs become non-unique when two or more IPComp sessions are
>       established between two nodes, and the same well-known CPI is
>       used in at least two of the sessions.  Non-unique IPCAs pose
>       problems in maintaining attributes specific to each IPCA, either
>       negotiated (e.g., lifetime) or internal (e.g., the counters of
>       the adaptive algorithm for handling previously compressed
>       payload).  To ensure the uniqueness of IPCAs between two nodes,
>       when two or more of the IPCAs use the same compression
>       algorithm, the CPIs SHOULD be in the negotiated range.  However,
>       when the IPCAs are not required to be unique, for example when
>       no attribute is being utilized for these IPCAs, a well-known CPI
>       MAY be used.  To clarify: When only a single session using a
>       particular well-known CPI is established between two nodes, this
>       IPCA is unique.
>