Re: [Rmt] Comments on WGLC for draft-rmt-bb-lct-revised-06

[Vincent Roca <[e-mail]>]

Mark,

Thanks for the clarification.
I agree that if we don't want to implement (2) in order to
maintain backward compatibility, then there's no need to
update the version number. Since the answer is not so trivial,
I suggest to add a note somewhere in the document.

Cheers,

   Vincent


Mark Watson a écrit :
> Vincent, all,
> 
> It looks like I was mistaken in the meeting - 3GPP, at least, references
> RFC3451 (the Experimental RFC).
> 
> However, in the changes that we made to LCT, we did go to some trouble to
> maintain backwards compatibility:
> - The removal of the SCT and ERT from the header was accompanied by a
> requirement to set the indicator bits for these headers to zero, so that old
> receivers will not expect the fields themselves to be present
> - The new Protocol Specific Information (PSI) field replaces bits that were
> reserved in RFC3451 and 3451 specifically requires receivers to ignore them
> 
> A new protocol version number is only required when
> backwards-incompatibility is introduced and we have taken care not to do
> that here. So I still think the changes (1) and (2) below are unnecessary.
> 
> Regards,
> 
> Mark
> 
> 
> On 3/9/08 7:08 AM, "Vincent Roca" <[e-mail]> wrote:
> 
>> 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".
>>
>> _______________________________________________
>> Rmt mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rmt
>>
> 
> 
> 


-- 
------------------------------ http://planete.inrialpes.fr/people/roca/
   INRIA Rhone-Alpes - planete research team   [e-mail]
   Inovallée; 655 av de l'Europe; Montbonnot   phone [phone]
   38334 ST ISMIER cedex - France              fax   [phone]
_______________________________________________
Rmt mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rmt