Re: [6tisch] Alvaro Retana's No Objection on draft-ietf-6tisch-msf-12: (with COMMENT)

[Tengfei Chang <[e-mail]>]

Hi Alvaro,

I replied in the following starting with " *RESPONSE *", in case ">" is not
well displayed.

On Thu, Mar 12, 2020 at 2:41 PM Alvaro Retana via Datatracker <
[e-mail]> wrote:

> Alvaro Retana has entered the following ballot position for
> draft-ietf-6tisch-msf-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> (1) I support Roman's DISCUSS.
>

*RESPONSE*: yes, Roman's DISCUSS should be fixed in the next revision.

>
> (2) The datatracker should point at draft-chang-6tisch-msf being replaced
> by
> this document.
>
> (3) §2: "MSF RECOMMENDS the use of 3 slotframes."  Why isn't this
> REQUIRED?
> How does an implementation signal to a neighboring node that a different
> number
> of slotframes are being used (or a different length, which is also
> RECOMMENDED
> later)?  It seems to me that RECOMMENDING may not be enough for an
> interoperable implementation...but I may also be missing something in
> 802.15.4
> or rfc8180 (or somewhere else).  [BTW, the rfc2119 keyword is RECOMMENDED
> (not
> RECOMMENDS).]
>

* RESPONSE *: In RFC8480, the 6P request is able to point out the cell is
to installed/removed on which slotframe, by specifying the slotframe ID.
There is no problem to run multiple slotframe with different length, only
the slot boundary is needed to be aligned, according to IEEE802.15.4.

>
> I think the use of RECOMMENDED (vs REQUIRED) may be related to this text a
> couple of paragraphs before:
>
>    A node implementing MSF SHOULD implement the Minimal 6TiSCH
>    Configuration [RFC8180], which defines the "minimal cell", a single
>    shared cell providing minimal connectivity between the nodes in the
>    network.  The MSF implementation provided in this specification is
>    based on the implementation of the Minimal 6TiSCH Configuration.
>    However, an implementor MAY implement MSF based on other
>    specifications as long as the specification defines a way to
>    advertise the EB/DIO among the network.
>
> I understand that a configuration other than rfc8180 is possible, but if
> this
> document is based on rfc8180, then it would be clearer if the language was
> stronger (s/SHOULD/MUST) with the understanding that the specification
> refers
> to that case.
>

* RESPONSE: *by using MUST, it will restrict MSF to RFC8180 only.
IMO, the text is able to convey the relationship between MSF and RFC8180.

>
> (4) §4.3:
>
>    While the exact behavior is implementation-specific, it is
>    RECOMMENDED that after having received the first EB, a node keeps
>    listen for at most MAX_EB_DELAY seconds until it has received EBs
>    from NUM_NEIGHBOURS_TO_WAIT distinct neighbors, which is defined in
>    [RFC8180].
>
> rfc8180/§6.2 says that "after having received the first EB, a node MAY
> listen
> for at most MAX_EB_DELAY seconds until it has received EBs from
> NUM_NEIGHBOURS_TO_WAIT distinct neighbors."  The use of RECOMMENDED here
> is not
> consistent with the optional nature of the MAY.
>

*RESPONSE *: thanks for the comment. This paragraph will be revised
according to RFC8180 to be consistent.


>
> (5) Nits...
>
> s/represents node's preferred parent/represents the node's preferred parent
>
> s/no restrictions to go multiple MSF sessions/no restrictions to use (?)
> multiple MSF sessions
>
> s/One of the algorithm met the rule/One of the algorithms that meet the
> rule
>
> s/Alternative behaviors may involved/Alternative behaviors may be involved
>
> s/when alternative security/when an alternative security
>
> s/node keeps listen/node keeps listening
>
> s/pairs of following counters/pairs of the following counters
>

  *RESPONSE*: Those will be reolsved in the next revision.

Tengfei

>
>
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——————————————————————————————————————

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——————————————————————————————————————