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

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Thu, 12 Mar 2020 06:41:13 -0700

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.

(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).]

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.

(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.

(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

---

From: Tengfei Chang <[email-masked]>
Date: Tue, 24 Mar 2020 12:57:34 +0100

Hi Alvaro,

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

> https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/

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

> or rfc8180 (or somewhere else).  [BTW, the rfc2119 keyword is RECOMMENDED

* 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.

> stronger (s/SHOULD/MUST) with the understanding that the specification

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

> consistent with the optional nature of the MAY.

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

> s/pairs of following counters/pairs of the following counters

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

Tengfei

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

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

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

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