[6tisch] Éric Vyncke's No Objection on draft-ietf-6tisch-architecture-24: (with COMMENT)

Éric Vyncke via Datatracker <noreply@ietf.org> Wed, 07 August 2019 09:44 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 61C3B1203B9; Wed, 7 Aug 2019 02:44:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6tisch-architecture@ietf.org, 6tisch-chairs@ietf.org, shwetha.bhandari@gmail.com, 6tisch@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.100.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <156517104035.8414.2091655258752129611.idtracker@ietfa.amsl.com>
Date: Wed, 07 Aug 2019 02:44:00 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/PD1jAw23K2gC27NMXC5C8v78clw>
Subject: [6tisch] Éric Vyncke's No Objection on draft-ietf-6tisch-architecture-24: (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: Wed, 07 Aug 2019 09:44:00 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-6tisch-architecture-24: 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-architecture/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Pascal,

Thank you for the hard work put into this document. It is extensive and
comprehensive. I really appreciate this well-written document as it is clear
(albeit long...), so, the COMMENTs and NITs are to improve the document quality
and not as a negative criticism; your reply + comments will be welcome though.

Regards, Bien à toi,

-éric

== COMMENTS ==

-- Section 1 --
Suggest to be more specific about the backbone: layer-2 or IP backbone ?

-- Section 2.1 --
Please define 'PAN' before first use.
The choice of 'ASN' in an IETF document was probably not the choice... ;-)
I was unable to understand the concept and use of layer-2 bundle by reading the
definition. Let's hope it is defined/explained later... It is probably too late
to change now, but, this section is really too heavy and by alphabetical order,
so, its usefulness is reduced for first-time readers. Section 3 is rather easy
to read for similar explanations.

-- Section 3.2 --
For my own curiosity, reducing mcast is always good of course but not critical
on the backbone if it is wired Ethernet. So, why mentioning this fact in this
memo?

-- Section 3.4 --
Minor inconsistency between the list of the schedule management ways and the
enumeration. Nothing critical though but confusing. In "Neighbor-to-Neighbor
Scheduling", perhaps replace "between adjacent routers" by "between adjacent
peers" as the text is mainly about peers?

-- Section 3.6 --
It is probably useful to define what "feasable" means in the context of this
memo. Probably too late in the publication process to change, but, I would
suggest to use "6LoWPAN Fragments Forwarding" (plural) of even "6LoWPAN
Fragments Chain Forwarding". More a nit but can you re-use the same names in
the table at the end of the section? This table should also have a number such
as Table 1

-- Section 3.7 --
Figure 4 mentions "to be IEEE Std. 802.15.12"... this is a hint to a IEEE work
which should be explained in the text or be removed.

-- Section 3.8 --
The first paragraph would benefit if it was clear that it is about
"*difference* between information and data models". Please define what
"duocast" is ;-)

-- Section 4.1.2 --
Its title is just in the reverse order of the previous sentence :-O And, should
it mention "colocated" ?

-- Section 4.2.2 --
Is there a difference between "IPv6 ND" in figure 5 and figure 6? It is
followed by "NA" "NS" in the latter.

-- Section 4.3.3 --
Please define "ETX" and "LQI" ?

-- Section 4.4 --
Is it on purpose that there is a lot of overlap with section 3.4 ?

-- Section 4.5.3 --
Is it worth to define "PRE" or is DetNet knowledge assumed?

-- Section 4.6 --
Please be consistent with the naming of the sub-sections wrt "three different
forwarding model"

-- Section 5 --
Please replace "This specification" by "This document" as it is not aimed to be
a Proposed Standard.

-- Section 6 --
"ASN" was not fully described before (except briefly in terminology section),
so, I find it weird to build the security section around this concept;
moreover, as it comes from DetNet, I would assume that the DetNet documents are
more suitable to have this security discussion (with just a point in this memo).

== NITS ==

-- Section 1 --
A comma is probably needed before "Industrial Automation Control Systems
(IACS)". Same section could possibly also introduce the 'IT' acronym. s/require
the addition/requires the addition/ ? s/, e.g., an Ethernet bridged network,/
(e.g. an Ethernet bridged network)/

-- Section 2.1 --
s/:  : /: /

-- Section 3.2 --
s/RPL network needs to share information/RPL network need to share information/
?

-- Section 3.7 --
s/aloha/Aloha/ ?
The sentence "The reference stack that the 6TiSCH architecture presents was
implemented and interop tested" would benefit from a couple of commas.

-- Section 4.3.1.1 --
Duplicate line.
Duplicate line. ;-)

- Section 4.6 --
s/three different forwarding model, /three different forwarding models: /