Re: draft-bouazizi-rmt-alcframing-00.txt

Hello Stephan and Imed,

> please find attached a short I-D which I will be presenting on behalf  
> of the author in today's session.  We missed the -00 deadline, but  
> after consultation with the chairs, we thought that last minute  
> circulation by reflector is better than no document at all.  The  
> draft is rather short -- 7 pages including boilerplate.  Feel free to  
> spoil your lunch by reading it.

Generally speaking, I agree that sooner or later deploying ALC over
TCP will be needed. So the I-D is useful.
Concerning the document, I have a few comments:

** section 2, Framing method:
Why do you restrict yourself to a 16bit LENGTH field?
First it breaks the 32bit alignment of the ALC/LCT header. Second,
since TCP will fragment the ALC packet as required by the PMTU,
there is no real motivation for limiting the ALC packet size. It's a
completely different situation than when ALC runs on top of UDP
since big UDP packets will be fragmented by IP which is considered
harmfull.
There's probably situations where an ALC packet will go through TCP
tunnels (using the proposed method) and then will perhaps continue its
travel over UDP after crossing a dedicated middlebox. Then it makes
sense to restrict ourselves to ALC packets of size < 65535.
But there are also situations where one would like to go beyond this
threshold.

** Section 4, Further considerations:
It is said: