[6lo] Jari Arkko's No Objection on draft-ietf-6lo-6lobac-06: (with COMMENT)

"Jari Arkko" <jari.arkko@piuha.net> Thu, 01 December 2016 08:39 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: 6lo@ietf.org
Delivered-To: 6lo@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D502C1295A0; Thu, 1 Dec 2016 00:39:21 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Jari Arkko <jari.arkko@piuha.net>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148058156186.10430.13823817193512321955.idtracker@ietfa.amsl.com>
Date: Thu, 01 Dec 2016 00:39:21 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/znj2iJ_0yMrct3-kF59qcObdb-k>
Cc: oritl@microsoft.com, 6lo-chairs@ietf.org, samitac.ietf@gmail.com, draft-ietf-6lo-6lobac@ietf.org, 6lo@ietf.org
Subject: [6lo] Jari Arkko's No Objection on draft-ietf-6lo-6lobac-06: (with COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2016 08:39:22 -0000

Jari Arkko has entered the following ballot position for
draft-ietf-6lo-6lobac-06: 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-6lo-6lobac/



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

Comments from Orit Levin's Gen-ART review should be addressed:

---

Document: draft-ietf-6lo-6lobac-06
Reviewer: Orit Levin
Review Date: 2016-11-26
IETF LC End Date: 2016-11-30
IESG Telechat date: (if known)

Summary:
This draft is basically ready for publication, but has editorial nits
that should be fixed before publication.

Abstract:
Remove the word "extensively" from the first sentence.

Introduction:
1. Remove the word "extensively" from the first sentence. (Not a
standard-appropriate language.) 2.Consider rephrasing to "... these
constraints are similar to those faced in 6LoWPAN networks, which
suggests that some elements of that solution might be leveraged."
3. Consider rephrasing the last sentence to "This document also specifies
a mandatory header compression mechanism, based on [RFC6282], which
reduces latency and makes IPv6 practical on MS/TP networks."

Section 1.3
1. This section is called "MS/TP Overview". The overview of the existing
specifications is "mingled" with the new features and profiling defined
in "this specification". By just reading this section, it is not always
clear which statements refer to the "baseline" specifications and which
to the new "features" defined in this document. Either consider
introducing/improving "linking" sentences to clarify the text or
reorganize/split the text into two independent summaries: of baseline
functionality and of new functionality. 
2. In the second paragraph, rephrase to "These features make MS/TP a
cost-effective field bus applicable to building an automation network."
(Not a standard-appropriate language: "for the most numerous and least
expensive devices".) 3. Add the word "only" to "A master node may
initiate the transmission of a data frame only when it holds the token."
4. Consider changing "MS/TP COBS-encoded frame fields have the following
descriptions:" to "MS/TP COBS-encoded frame fields are defined as
follows:"
5. Remove "MUST"s from "Frame Types 32 - 127 designate COBS-encoded
frames and MUST convey Encoded Data and Encoded CRC-32K fields.  All
master nodes MUST understand Token, Poll For Master, and Reply to Poll
For Master control frames." (See my first comment to this section above.
Where is this defined? In the baseline specs or in this document?)

Section 3
Rephrase to "The method specified in Section 6 for creating a
MAC-layer-derived Interface Identifier (IID) ensures that an IID of all
zeros can never be generated."

Section 4
Consider rephrasing to "This specification restricts an MSDU length for
at least 1280 octets and at most 1500 octets (before encoding)."

Section 5
1. Rephrase to "Because of the relatively low data rates of MS/TP, header
compression is used as a means to reduce latency."
2. Add "of" after "comprises" in "The encapsulation format defined in
this section ... comprises of the MSDU of an IPv6 over MS/TP frame."
3. In "The Dispatch value may be treated as an unstructured namespace",
it would be simpler to say "is treated" unless there is a special
significance to "may be". In later case, it needs to be explained.

Section 6
Consider replacing ", as" by "and is" in "The general procedure for
creating a MAC-address-derived IID is described in [RFC4291] Appendix A,
"Creating Modified EUI-64 Format Interface Identifiers", as updated by
[RFC7136]."

Section 10
Consider replacing the second and the third sentences with "This section
provides the text substitutions for [RFC6282] that make it applicable to
LoBAC as follows:"

Section 12
Consider rephrasing to "MS/TP networks are by definition wired and thus
not susceptible to casual eavesdropping. Furthermore, because MS/TP nodes
are stationary, correlation of activities or location tracking of
individuals is unlikely."

Thank you,
Orit Levin.