Date: Tue, 26 Jun 2001 11:22:56 -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-07.txt


Attached is the annotated content diff between versions -06 and -07 of
rfc2393bis.  The changes in version -07 are based on the comments by
Thomas Narten, the Internet AD.

(Note: http://shacham.net/ipcomp/ provides details on rfc2393bis 
et al.)

Regards,
avram


1.  Compressing before encryption is now defined as 'must' instead of
'MUST'.  In addition to not being a protocol requirement, some threads
of the ipsec alias insisted that the policy (i.e., order of protocols
as negotiated) is holy, and could not agree that compression after
encryption makes no sense.  Still,

                            "Encrypting the IP datagram causes the data
   to be random in nature, rendering compression at lower protocol...
   ineffective."

*** 49,64 ****
     to be random in nature, rendering compression at lower protocol
     layers (e.g., PPP Compression Control Protocol [RFC-1962])
     ineffective.  If both compression and encryption are required,
!    compression MUST be applied before encryption.
--- 49,64 ----
     to be random in nature, rendering compression at lower protocol
     layers (e.g., PPP Compression Control Protocol [RFC-1962])
     ineffective.  If both compression and encryption are required,
!    compression must be applied before encryption.
***************

2.  Typo: 'MUST NOT' should have been here always.

*** 126,132 ****
     In the IPv6 context, IPComp is viewed as an end-to-end payload, and
!    MUST not apply to hop-by-hop, routing, and fragmentation extension
     headers.  The compression is applied starting at the first IP Header
     Option field that does not carry information that must be examined
--- 126,132 ----
     In the IPv6 context, IPComp is viewed as an end-to-end payload, and
!    MUST NOT apply to hop-by-hop, routing, and fragmentation extension
     headers.  The compression is applied starting at the first IP Header
     Option field that does not carry information that must be examined
***************

3.  s/than MTU/than the MTU/

*** 159,169 ****
     IPComp header is added to the datagram.  This policy ensures saving
     the decompression processing cycles and avoiding incurring IP
!    datagram fragmentation when the expanded datagram is larger than MTU.
  
--- 159,170 ----
     IPComp header is added to the datagram.  This policy ensures saving
     the decompression processing cycles and avoiding incurring IP
!    datagram fragmentation when the expanded datagram is larger than the
!    MTU.
  
***************

4.  Clarifying the description of some of the constants in the
adaptive algorithm.

*** 177,188 ****
     an upper layer in the communication stack, or by an off-line
     compression utility.  An adaptive algorithm should be implemented to
     avoid the performance hit.  For example, if the compression of i
!    consecutive IP datagrams of an IPCA fails, the next k IP datagrams
!    are sent without attempting compression.  If the next j datagrams are
!    also failing to compress, the next k+n datagrams are sent without
!    attempting compression.  Once a datagram is compressed successfully,
!    the normal process of IPComp restarts.  Such an adaptive algorithm,
!    including all the related thresholds, is implementation dependent.
  
--- 178,190 ----
     an upper layer in the communication stack, or by an off-line
     compression utility.  An adaptive algorithm should be implemented to
     avoid the performance hit.  For example, if the compression of i
!    consecutive IP datagrams of an IPCA fails, the next several IP
!    datagrams, say k, are sent without attempting compression.  If then
!    the next j datagrams also fail to compress, a larger number of
!    datagrams, say k+n, are sent without attempting compression.  Once a
!    datagram is compressed successfully, the normal process of IPComp
!    restarts.  Such an adaptive algorithm, including all the related
!    thresholds, is implementation dependent.
  
***************

5.  Adding a section for 'IANA Considerations'

*** 457,468 ****
  
! 6. References
  
--- 459,475 ----
  
+ 6. IANA Considerations
  
!    This document does not require any IANA actions.  The well-known
!    numbers used in this document are defined elsewhere; see [SECDOI].
  
! 7. References
  
=== eom ===


On Tue, 26 Jun 2001 Internet-Drafts@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: IP Payload Compression Protocol (IPComp)
> 	Author(s)	: A. Shacham, R. Monsour, R. Pereira, M. Thomas
> 	Filename	: draft-shacham-ippcp-rfc2393bis-07.txt
> 	Pages		: 11
> 	Date		: 25-Jun-01
> 	
> This document describes a protocol intended to provide lossless
> compression for Internet Protocol datagrams in an Internet
> environment.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-shacham-ippcp-rfc2393bis-07.txt
> 
[...]