Subject: Other comments on draft-ietf-ippcp-protocol-01.txt

From: Robert Friend <[email-masked]>
Date: Tue, 11 Nov 1997 17:36:53 -0800

Hi All,

After reviewing draft-ietf-ippcp-protocol-01.txt, I have the following
feedback:

1) In section 2.2., paragraph 4, what kind of compressibility test
(V.42bis) is suggested (referred to)?  My understanding is that the
example "compressibility test" provided is part of the algorithm.  In
which case It seems to me that this test would not be "implementation
dependent", rather "algorithm dependent".

Anyway, I don't understand how this approach would work for other
algorithms, such as LZS or MPPC?  

It seems to me that the non-expansion requirement (section 2.2.,
paragraph 3) covers this issue, so the text can be deleted.

2) Sorry for not being up to date, but why the change from 32-bits to
16-bits for CPI?  Will this scale well for large routers/servers with
lots of connections?

3) Two minor suggestions for clarification:

From:
4.3. Static Configuration

   Nodes may establish IPComp Associations using static configuration.

To:
4.3. Static Configuration

   Nodes may establish IPComp Associations using static configuration
(manual setup).
   
From:
5. Security Considerations

   ......  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 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.......

To:
5. Security Considerations

   ......  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.......

Regards,
_____________________________________________________________

Robert C. Friend              Hi/fn
Applications Engineering      5973 Avenida Encinas, Suite 110
voice: (760) 827-4542         Carlsbad, CA 92008
FAX:   (760) 827-4577         email: [email-masked]

---

From: Avram Shacham <[email-masked]>
Date: Wed, 12 Nov 1997 06:35:17 +0200

Robert,

At 05:36 PM 11/11/97 -0800, Robert Friend wrote:
<snip>
>(V.42bis) is suggested (referred to)?  

V.42bis checks for expendability at certain "check-points" along the packet
and stops compression when the intermediate compressed packet did not shrink
at these points.

>My understanding is that the
                    ^^^^^^^^^^^
Agree.

>algorithms, such as LZS or MPPC?  

In the current LZS algorithm - it does not work.

>paragraph 3) covers this issue, so the text can be deleted.

The target of this phrase is to serve as a guideline for performance
increase in the algorithm, so it is not a duplication of the non-expansion
requirement. And, 
the guideline is at the "MAY" (lowest level) of recommendation.

>16-bits for CPI?  Will this scale well for large routers/servers with

16-bit fits well in a 32-bit header and the feeling in Munich was that such
CPI space is adequate.

>   Nodes may establish IPComp Associations using static configuration
 ^^^^^^^^^^^^^^

Manual implies a-person-going-from-node-to-node-and-sets-values. Static
configuration may be distributed by some corporate-wide configuration utility.
   
>   positions within the datagram, and any transport-layer header fields
                                                    ^^^^^^
>   values after compression.......

Agree.

Regards,
avram