Re: [6lo] Comments on draft-kelsey-6lo-mesh-link-establishment-00

[Gabriel Montenegro <[e-mail]>]

Was there any response to these comments from Yoshi? At least some of them seem to apply to the current rev 00 of MLE.

> -----Original Message-----
> From: 6lo [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Thursday, October 1, 2015 17:33
> To: [e-mail]
> Subject: [6lo] Comments on draft-kelsey-6lo-mesh-link-establishment-00
> 
> Here is my review comments on MLE draft.
> 
> ----
> 
> Section 1:
> 
> "
>    MLE was developed as part of the ZigBee IP networking standard
>    [ZigBeeIP].  This document describes the protocol as it was used in
>    that standard.
> "
> 
> I do not think this paragraph is needed since the published ZigBee IP
> specification references an older version of MLE draft.   Especially the 2nd
> sentence prevents us from updating the protocol for usages other than
> ZigBee IP.
> 
> Section 7:
> 
> The length of the TLV Length field is currently one octet, allowing up to 255
> bytes for Value field.  However, an MLE extension defined in draft-ohba-6lo-
> mle-hip-dex needs more than 255 bytes for Value field.  One case is to carry
> HIP DEX certificates in MLE message.  Another case is to carry a certificate
> revocation list in MLE.  Therefore, the length of TLV Length should be at least
> 2-octet for longer Value fields.
> 
> Section 7.1:
> 
> "
>    The Link-layer Frame Counter TLV (TLV Type 5) has a Value containing
>    the sender's current outgoing link-layer Frame Counter, encoded as an
>    N-byte unsigned integer.  For 802.15.4 this is a 4-byte value.
> "
> 
> The last sentence is inaccurate since IEEE 802.15.4e-2012 also supports 5-
> octet Frame Counter.
> 
> Section 7.7 :
> 
> "
>    A node that does not have a link configured to a neighbor but
>    receives a Link Quality TLV from that neighbor with the node's O flag
>    set to "1" SHOULD send an MLE message with a Link Quality TLV with
>    that neighbor's I bit set to "0".
> "
> 
> In this case, the Link Quality TLV with that neighbor's I bit set to "0" should
> also have the O bit set to "0" since the sending node of this TLV does not
> have the link configured to the neighbor.
> 
> It is also suggested to add a reference to Section 12 for detailed usage of I bit
> and O bit.
> 
> Section 7.8:
> 
> "
>   Delay               The delay before setting the parameter, in
>                        milliseconds.  This is a four-byte unsigned
>                        integer.  Having a delay gives time for the new
>                        value to propagate throughout the network.  It
>                        may also be used for limiting the time a
>                        particular parameter setting is in use, by
>                        including two different values for a single
>                        parameter, with two different delays.
> "
> 
> When two Network Parameter TLVs of the same Parameter ID with different
> Delay values are carried in a single message, how to distinguish the two
> different types of delays, i.e., the delay before setting the parameter, and the
> delay for limiting the time the parameter is in use?
> 
> "
>    The defined Network Parameters are:
> 
>    0    Channel
> 
>    1    PAN ID
> 
>    2    Permit Joining
> 
>    3    Beacon Payload
> "
> 
> Please add description or references to show how each network parameter
> (Channel, PAN ID, Permit Joining, Beacon Payload) is encoded into the Value
> field.
> 
> Section 7.9:
> 
> "
>    The MLE Frame Counter TLV (TLV Type 8) has a Value containing the
>    sender's current outgoing MLE Frame Counter, encoded as an 32-bit
>    unsigned integer.
> "
> 
> Since IEEE 802.15.4e-2012 supports 5-octet frame counter in addition to 4-
> octet frame counter, it is suggested to also support 5-octet MLE frame
> counter.  Note that draft-ohba-6lo-mle-hip-dex mandates use of 5-octet MLE
> Frame Counter.
> 
> ---
> 
> Best Regards,
> Yoshihiro Ohba