Comments on WGLC for draft-rmt-bb-lct-revised-06

Mark and al.

I went through the whole document and here are a few comments:

Potentially controversial comments:

1- the version number of this specification is set to 1, i.e.,
   the same value as that of RFC3451 whereas many features have
   changed. I can understand that a specification that makes
   obsolete the previous specification keep the same version
   value. Yet it must be considered that in the meantime LCT has
   been widely deployed, and from this point of view I'm a little
   bit concerned by this choice. I don't remember any previous
   discussion on this topic.

2- the CCI (Congestion Control Information) field length is still
   set to:   length = 32*(C+1) bits
   In other words it mandate that each LCT packet contain at least
   a 32 bit CCI field.
   Though I agree on the fact that CC is mandatory, I'm wondering
   if it wouldn't be wiser not to mandate the presence of the CCI
   field in all LCT packets. It is straightforward, we just need
   to say that length = 32*C.
   The motivation: with some CC mechanisms, in particular in case
   of a CBR (constant bit rate) transmission within a CBR channel,
   the CCI field is not used and zero'd. That's the case AFAIK
   in all DVB-* use-cases.
   If we change as suggested, the fact that it is no longer
   possible to have CCI fields that are 128 bit long is not a big
   issue since long CCI fields can be moved to a specific HE.


Minor comments:

3- p.17, Close Session flag: It is said:
       A received packet with A set to 1 indicates to a
       receiver that the sender will immediately stop sending packets for
       the session.
    Instead of "immediately", I'd rather say "imminently" since
    there can be several such packets as it is explained.

    p.17, Close Object flag: same remark

4- 5.2.1.  General: It is said:
   o  Sender and Receiver authentication information.
    The use of HE for "receiver authentication" contradicts
    what is said before (e.g., in section 2. Rationale) that
    LCT is purely unidirectional.
    I suggest to remove any reference to "receiver" here, even
    if the same HE format could be used in another context.


5- 5.2.1, p.22: it is said:
       If EXT_AUTH is present,
       whatever packet authentication checks that can be
       performed immediately upon reception of the packet
       SHOULD be performed before accepting the packet and
       performing any congestion control-related action on it.
    Is the SHOULD appropriate here? I'd rather say MUST.

6- p.25: it is said, concerning the PI-specific use field:
       The bits that
       are not specified by the PI built on top of LCT SHOULD
       be set to zero.
    Is the SHOULD appropriate here? I'd rather say MUST,
    even if it refers to another document.

7- p.28, section 6.1:
    I suggest that instead of MTU, the text refers to PMTU
    (Path MTU) which is the key requirement to improve end-2-end
    transmissions efficient.
    The words "or when" in this sentence is also probably an
    error. I guess the authors mean "otherwise".

8- Section 8. This security section can probably be improved.
    In particular (but not only) appending an MD5 hash to the
    object without any signature cannot be regarded as offering
    any security since any wise attacker will change the hash
    in such a way to make the attack invisible.


A few typos:

* p.22: singe -> single in:
    applicability (for example to a singe Protocol Instantiation) SHOULD

* p.27: is -> are in:
    distribution of session descriptions is beyond the scope of this

* p.31, bottom: the right reference is probably [RIZ1997b].
   Anyway [RIZ1997] and [RIZ1997a] are a duplicated single reference.

* p.35, 9.1: Instanciation is badly spelled.
   Besides, is it appropriate to refer to the "previous Experimental
   version of this specification"?
   I believe that RFC3451 is more appropriate.

* p.35, 9.2: two -> three
    This document registers two values in the namespace "ietf:rmt:lct:


And a final suggestion:

* in sections 2 and 4, on several occasions it is said:
   "the use of coding for reliability".
   I understand it, but shouldn' we say instead: "the use of
   FEC encoding for reliability"? I think it clarifies what is
   meant by "coding".