RE: draft-ietf-ippcp-lzs-01.txt for comments

[Robert Friend <[e-mail]>]

Hi Avrum,

Thanks for the feedback.  See below....

Regards,
_____________________________________________________________

Robert C. Friend              Hi/fn
Applications Engineering      5973 Avenida Encinas, Suite 110
voice: [phone]         Carlsbad, CA 92008
FAX:   [phone]         email: [e-mail]

>-----Original Message-----
>From:	Avram Shacham [SMTP:[e-mail]]
>Sent:	Monday, November 17, 1997 3:07 AM
>To:	Robert Friend; 'IPPCP'
>Subject:	Re: draft-ietf-ippcp-lzs-01.txt for comments
>
>Robert,
>
>Your draft looks good. Please see my comments in the document.
>[Rob]  Thanks.
>
>Regards,
>avram
>
>At 03:30 PM 11/14/97 -0800, Robert Friend wrote:
>>Abstract
>>
>>   This document describes a IP compression method based on the LZS
>                              ^^
>Is 'IP' necessary?
>[Rob]  I don't think so; I'll remove it.
>
><snip>
>
>>1.2 Background of LZS Compression
>>
>>   Starting with a sliding window compression history, similar to [LZ1],
>>   Hi/fn developed a new, enhanced compression algorithm identified as
>>   LZS. The LZS algorithm is optimized to compress all file types as
>                                                    ^^^^^^^^^^^^^^
>?
>[Rob]  How about "..all data types..".
>
>>   efficiently as possible.  Even string matches as short as two octets
>>   are effectively compressed.
>
><snip>
>
>>   The efficiency of the LZS algorithm depends on the degree of
>>   redundancy in the original data.  A typical compression ratio is 2:1.
>
>What do you define to be "typical"?  Your Appendix A shows that the Calgary
>files are compressed at a ratio of 2.04:1 for 4096 bytes datagrams, a very
>non common MTU.
>[Rob]  How about we replace that sentence with a reference to the table in
>the appendix (Section 7.).
>
><snip>
>
>>2. Compression Process
>>
>>2.2 Anti-expansion of Payload Data
>>
>>   The maximum expansion produced by the LZS algorithm is 12.5%.
>>
>>   If the size of a compressed IP datagram, including whatever overhead
>                                                       ^^^^^^^^^^^^^^^^^
>?
>[Rob]  I agree.  I'll put in text, such as: "..., including the Next Header,
>Flags, and CPI fields, is not smaller than the size of the original IP
>datagram,...."
>
><snip>
>
>>2.4 Compression Encoding Format
>>
>>   The input to the payload compression algorithm is an IP datagram
>>   payload. The output of the algorithm is a new (and hopefully smaller)
>>   payload. The output payload contains the input payload's data in
>>   either compressed or uncompressed format. The input and output
>>   payloads are each an integral number of bytes in length.
>>
>>   If the uncompressed form is used, the output payload is identical to
>>   the input payload and the IPComp header is omitted.  
>
>IPComp header is added _only_ to compressed payloads.
>[Rob]  Ok, I will explicitly state that the compressed payload is prepended
>with the IPComp header. 
>
><snip>
>
>>2.5 Padding
>>
>>   A datagram payload compressed using LZS always ends with the last
>>   compressed data byte (also known as the <end marker>), which is used
>>   to disambiguate padding.  This allows trailing bits as well as bytes
>>   to be considered padding.
>
>Could you specify compliance with the requirement:
>  "The size of a compressed payload MUST be in whole octet units."
>[Rob]  Ok.
>
><snip>
>
>>4. Security Considerations
>>
>>   IP payload compression potentially reduces the security of the
>>   Internet, similar to the effects of IP encapsulation [RFC-2003].  For
>>   example, IPComp makes it difficult for border routers to filter
>>   datagrams based on header fields.  In particular, the original value
>>   of the Protocol field in the IP header is not located in its normal
>>   positions within the datagram, and any transport-layer header fields
>>   within the datagram, such as port numbers, are neither located in
>>   their normal positions within the datagram nor presented in their
>>   original values after compression.  A filtering border router can
>>   filter the datagram only if it shares the IPComp Association used for
>>   the compression.  To allow this sort of compression in environments in
>>   which all packets need to be filtered (or at least accounted for), a
>>   mechanism must be in place for the receiving node to securely
>>   communicate the IPComp Association to the border router.  This might,
>>   more rarely, also apply to the IPComp Association used for outgoing
>>   datagrams.
>>
>>   When IPComp is used in the context of IPSec, it is not believed to
>>   have an effect on the underlying security functionality provide by
>>   the IPSec protocol; i.e., the use of compression is not known to
>>   degrade or alter the nature of the underlying security architecture
>>   or the encryption technologies used to implement it.
>
>Do you see the duplication of the "Security Considerations" from
><draft-ietf-ippcp-protocol-01.txt> necessary?
>[Rob]  I wonder if a pointer in this area would be sufficient?  Shouldn't we
>spell out what our limitations are per algorithm?  I would think they might
>vary.  Again, do you have any suggested text?
> 
>>5. References
>
>Are you sure all the references are required?
>[Rob]  DOI, ESP, ISAKMP, RFC-1700, RFC1883, and Thayer are not referenced in
>the text, so they could be removed.  RFC-1962 is not mentioned, but RFC-1967
>is, so I would leave RFC-1962 in.  Comments?
>
>=== end of comments ===
>