Skip to main content

Last Call Review of draft-ietf-6lo-6lobac-06
review-ietf-6lo-6lobac-06-genart-lc-levin-2016-12-08-00

Request Review of draft-ietf-6lo-6lobac
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-11-30
Requested 2016-11-11
Authors Kerry Lynn , Jerry Martocci , Carl Neilson , Stuart Donaldson
I-D last updated 2016-12-08
Completed reviews Genart Last Call review of -06 by Orit Levin (diff)
Intdir Early review of -05 by Tim Chown (diff)
Intdir Early review of -05 by Brian Haberman (diff)
Opsdir Last Call review of -06 by Mahesh Jethanandani (diff)
Assignment Reviewer Orit Levin
State Completed
Request Last Call review on draft-ietf-6lo-6lobac by General Area Review Team (Gen-ART) Assigned
Reviewed revision 06 (document currently at 08)
Result Ready w/nits
Completed 2016-12-08
review-ietf-6lo-6lobac-06-genart-lc-levin-2016-12-08-00
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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:
1. 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
1. 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
1. 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.

Thank you,
Orit Levin.