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

Robert Friend <rfriend@hifn.com> Wed, 12 November 1997 01:36 UTC

Message-ID: <c=US%a=_%p=HIFN_Inc.%l=TBU1-971112013653Z-978@mailman.hifn.com>
From: Robert Friend <rfriend@hifn.com>
To: 'IPPCP' <ippcp@external.cisco.com>
Subject: Other comments on draft-ietf-ippcp-protocol-01.txt
Date: Tue, 11 Nov 1997 17:36:53 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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: rfriend@hifn.com

Other comments on draft-ietf-ippcp-protocol-01.txt Robert Friend
Re: Other comments on draft-ietf-ippcp-protocol-0… Avram Shacham