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

[Avram Shacham <[e-mail]>]

Robert,

At 05:36 PM 11/11/97 -0800, Robert Friend wrote:
<snip>
>1) In section 2.2., paragraph 4, what kind of compressibility test
>(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
>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".
                    ^^^^^^^^^^^
Agree.

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

In the current LZS algorithm - it does not work.

>It seems to me that the non-expansion requirement (section 2.2.,
>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.

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

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

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

Manual implies a-person-going-from-node-to-node-and-sets-values. Static
configuration may be distributed by some corporate-wide configuration utility.
   
>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.......

Agree.

Regards,
avram