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

Alvaro Retana via Datatracker <noreply@ietf.org> Thu, 12 March 2020 13:41 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: 6tisch@ietf.org
Delivered-To: 6tisch@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 492863A08EC; Thu, 12 Mar 2020 06:41:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-6tisch-msf@ietf.org, 6tisch-chairs@ietf.org, 6tisch@ietf.org, Pascal Thubert <pthubert@cisco.com>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.120.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alvaro Retana <aretana.ietf@gmail.com>
Message-ID: <158402047320.18051.10174813001043778615@ietfa.amsl.com>
Date: Thu, 12 Mar 2020 06:41:13 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/OAdjsQ-thdqfqfaNd1rovvixnJo>
Subject: [6tisch] Alvaro Retana's No Objection on draft-ietf-6tisch-msf-12: (with COMMENT)
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2020 13:41:14 -0000

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