Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks
draft-ietf-6lo-6lobac-08

[Ballot 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.

[Ballot comment]
Mahesh Jethanandani  performed the opsdir review

it would probably be good to discuss these concerns before it gets out the door.

I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Document reviewed:  draft-ietf-6lo-6lobac-06

Summary:

    The abstract of the document says “This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks.
    This document is on a standards track.


Operational Considerations

    Operations. The document does talk about existence of legacy Master Slave/Token Passing (MS/TP) along with nodes that will implement this new MS/TP frame format. It says that if these legacy nodes are present, they will ignore the frame format defined in this specification. It also says that co-existence with legacy implementations is only a secondary goal. To enable this, no changes are permitted to the MS/TP addressing modes, frame header format, control frames, or Master Node state machine.
    From an operational perspective, everything that can be configured can also be misconfigured. One way to simplify configuration, would be by specifying reasonable defaults, including default modes and parameters. Are there default parameters? If so, what are they?
    It appears from the draft that the deployment scenario in consideration is a green field opportunity. That only nodes that implement the new MS/TP frame format will be able to communicate with each other. So there is no consideration outlined for a migration path. In other words, even though co-existence with legacy implementations is one of the goals, it is not clear how that will enable a migration from that implementation to the new format.
    It is also not clear on what the impact if any this new format may have on existing legacy implementations. For example, for multicast frames, it states that multicast is not supported in MS/TP. That all multicast frames are broadcasted at the MAC layer and filtered at the IPv6 layer. What impact could this have on the nodes that have to process these multicast packets that are broadcasted to all the nodes?
    How is the node with the new MS/TP frame format expected to verified for correct operation? Is it by actively monitoring the node, and if so what are the elements that can be verified for correct operation. Are there events generated as part of protocol operations that can be used to verify its operation?


Management Considerations:

    Will the nodes with this new MS/TP frame format need to be configured, or monitored? What are some of the management operations that are needed? How are these operations performed, e.g. locally, remotely etc. Where is this management interface defined?
    Are there any new faults or health indicators associated with this new frame formats? How are the alarms and events exposed? Will they be pushed or do the devices have to be polled?
    Similarly, if one of the nodes in the network is not behaving correctly, how would an operator be able to determine which node it is? Are there counters maintained by each node that can be monitored to see what each node is doing? Anything that can be used to do a root cause analysis, and or fault isolation is helpful.
    Are there any performance considerations that an operator should be aware of with this new frame format?
    Certain properties of this new frame format can be useful to monitor. For example, the number of packets received with the frame format or the number of packets sent. Are there particular counters that can be used for monitoring?


Accounting Considerations

    Is it appropriate to collect usage information related to this new frame format? If so, what usage information would be appropriate to collect?


A run of idnits reveals one misc. warning that might be worth looking at.

    Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- Found something which looks like a code comment -- if you have code
    sections in the document, please surround them with '' and
    '' lines.

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com





_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

[Ballot discuss]
Section 12 says:

"For this reason, it is RECOMMENDED that a different (but stable) IID be
  generated for each globally scoped address in use according to, for
  example, [RFC3315], [RFC3972], [RFC4941], [RFC5535], or [RFC7217]."

I have a couple of questions about this recommendation that should be easy to clear up. First, do you really mean "different" IID? EUI-64 identifiers are different from each other, but embedding one in an IID still leaves you susceptible to address scanning attacks. Maybe what is meant here is "semantically opaque" or "with maximum supportable entropy" or something along those lines?

Second, what is meant by the word "stable" here? The mechanisms cited offer a variety of different "stability" spans -- DHCP lease lifetime, temporary address lifetime, lifetime of connection to a link, etc. So it's not clear what is actually being recommended or if the cited mechanisms all provide the desired property.

[Ballot comment]
I mostly understand why Sections 6 and 12 are specified as they are but there are a couple of points of departure from draft-ietf-6lo-privacy-considerations and draft-ietf-6man-default-iids that I'd like to discuss.

(1) draft-ietf-6man-default-iids says that the choice of address generation mechanism should be configurable when a mechanism is specified to embed a link layer address in an IID. Is there a reason that doesn't apply here? The document doesn't say anything about it for the link-local case.

(2) draft-ietf-6lo-privacy-considerations says:

"Specifications should make sure that an IPv6 address can change
      over long periods of time.  For example, the interface identifier
      might change each time a device connects to the network (if
      connections are short), or might change each day (if connections
      can be long).  This is necessary to mitigate correlation over
      time."

This document doesn't seem to provide any guidance about supporting the ability to change an IPv6 address within the life span of a long-lived attachment to the same physical network. Some of the mechanisms cited in Section 12 provide this and some do not. I appreciate that correlation of activities over time isn't perceived to be a huge threat here, but aren't there cases where being able to change an address despite remaining attached to the same physical network would be desirable? That seems worth some guidance for nodes that want to support it.

[Ballot comment]
1) Agree with Ben that normative wording should not be used if it just summarizes things that are specified in a different doc.

2) Section 5: "A node implementing [RFC7400] MUST probe its peers for GHC support before applying GHC." How?

3) Just to make sure I get the security section right: MS/TP networks are not connected to the Internet or use something like a gateway. Maybe make this point more clear: basically say that the reason to use IPv6 is NOT that you want to send these packets eventually directly to the Internet!

[Ballot comment]

- 1.3: "cost effective" and similar marketing language is
better avoided. I'd say deleting that sentence is better.

- section 5: It's not clear to me why the 115k data rate
"dictates" header compression to reduce latency. I'm not
doubting that it might, but it's not clear from what's
stated that it does.

- Appendices B/C: I'm not clear how these are not part of
the standard. I think what you mean is that the code is
not, but the algorithms in fact are in fact necessary to
implement this. (I also agree with Alia's suggestion to add
the IETF trust stuff, assuming that's not
problematic.)

[Ballot comment]
In Appendix B, given that there is code, it would be good to specifically mark it as such.  As I recall, there are different copyright aspects to the code fragments in an RFC than to the text.  I believe that https://www.ietf.org/iesg/statement/copyright.html  provides pointers to the implications and encourages marking the code segments with  and .

[Ballot comment]
Substantive:

- 1.3 Do I undertand correctly that this section is strictly an overview of something described elsewhere? If so, I am surprised to find the MUSTs in the the 5th paragraph from the end of the section.

- 2 and 3 also have some MUSTs that seem to describe MS/TP nodes in general--are those new requirements described in this spec, or existing requirements? (If the later, please consider stating them without 2119 keywords.)

-6, 2nd paragraph: Why is the SHOULD NOT not a MUST NOT? What is the consequences of ignoring the SHOULD NOT?

- 12, 2nd paragraph: "MS/TP networks are by definition wired and not susceptible to casual
  eavesdropping. "
I think this depends on too many factors to state this broadly. It may be easier to eves drop on an unprotected piece of wire than, say, an encrypted wireless link.

- 14.2: [EUI-64] and [I-D.ietf-6lo-privacy-considerations] seem to be cited normatively.

Editorial:
- 4: Please expand MSDU

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-6lo-6lobac-06.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: 6lo-chairs@ietf.org, draft-ietf-6lo-6lobac@ietf.org, samitac.ietf@gmail.com, suresh.krishnan@ericsson.com, "Samita Chakrabarti" , 6lo@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Transmission of IPv6 over MS/TP Networks) to Proposed Standard


The IESG has received a request from the IPv6 over Networks of
Resource-constrained Nodes WG (6lo) to consider the following document:
- 'Transmission of IPv6 over MS/TP Networks'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-11-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Master-Slave/Token-Passing (MS/TP) is a medium access control method
  for the RS-485 physical layer, which is used extensively in building
  automation networks.  This specification defines the frame format for
  transmission of IPv6 packets and the method of forming link-local and
  statelessly autoconfigured IPv6 addresses on MS/TP networks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6lo-6lobac/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6lo-6lobac/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational,
Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in
the title page header?

A. draft-ietf-6lo-6lobac-05 draft is a 'standards track' document. This intended status is indicated
in the document header. Since it is defining ipv6-over-foo adaptation layer, it is standard track.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a
Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  Master-Slave/Token-Passing (MS/TP) is a medium access control method
  for the RS-485 physical layer, which is used extensively in building
  automation networks.  This specification defines the frame format for
  transmission of IPv6 packets and the method of forming link-local and
  statelessly autoconfigured IPv6 addresses on MS/TP networks in the context
  of 6loWPAN specifications ( RFC4944, RFC6282, RFC6775). MS/TP devices are
  typically based on low-cost microcontollers with limited processing power
  and memory and they form a constrained wired network. A brief overview of
  MS/TP is available in ANSI/ASHRE 135-2012 BACNET, Clause 9 (see below):

              American Society of Heating, Refrigerating, and Air-
              Conditioning Engineers, "BACnet - A Data Communication
              Protocol for Building Automation and Control Networks",
              ANSI/ASHRAE 135-2012 (Clause 9), March 2013.



Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular
points or were there decisions where the consensus was particularly rough?

A. Due to the nature of MS/TP (wired constraiend network) deployment and its requirement on compressed header
format, the author expressed concerns over draft-ietf-6man-default-iids restrictions and suggestions for using
privacy addresses as default for link-local Ipv6 addresses.
https://www.ietf.org/mail-archive/web/6lo/current/msg01423.html

Section 6 of the document addresses privacy while forming the forwardable IPv6 address.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their
plan to implement the specification? Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a conclusion that the document had no
substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)?
In the case of a Media Type review, on what date was the request posted?

A.

The document has been reviewed and discussed by many 6lo experts in the WG including Carsten Bormann,
Dave Thaler, Samita Chakrabarti, Peter van Der Stock, James Woodyatt, Alex Petrescue, Geoff Mulligan, Don Sturek
etc. - some on-line and some of them provided comments off-line.

An implementation of lobac exists and they participated on a 6lo plugtest in Yokohama IETF94.
Since the document is closely co-ordinated with ASHER/BACNET Building networks SDO, it is assumed that many
other vendors will adopt the solution once it is a published RFC.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Document Shepherd: Samita Chakrabarti, Responsible Area Director: Suresh Krishnan


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version
of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A. Document shepherd has reviewed the -05 version of the document. The document is ready for publication.



(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been
performed?

A. The document is well written with lots of explanation (even code) at the Appendix.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security,
operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took
place.

A. Not applicable.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the
Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail
those concerns here.

A.  It has been reviewed by a number of WG members and the shepherd. It is ready to advance.

A note to the Area Director: One of teh co-author's email address (jerald.p.martocci@jci.com) is currently bouncing emails. The document
editor Kerry Lynn has been informed about the issue.The recommendation to the editor is to revise the draft
with correct email address.

Shepherd's minor editorial comment on section 5 second paragraph: "Add a line specifying that GHC support capability

among the MS/TP nodes are out of scope of this document". The author will update the text in the next revision.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with
the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

A. No IPR disclosures had been filed by the co-authors of the document. Confirmation with each author is
in progress.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and
conclusion regarding the IPR disclosures.
A. No

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the WG as a whole understand and agree with it?

A. The working group as a whole understands and agrees with the progress of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the
areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate
email because this questionnaire is publicly available.)

A. No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough;
this check needs to be thorough.

No issues found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type,
and URI type reviews.

A. Not Applicable.

(13) Have all references within this document been identified as either normative or informative?

A. Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an
unclear state? If such normative references exist, what is the plan for their completion?
A. No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references
to support the Area Director in the Last Call procedure.

A. None.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the
title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the document where the relationship of
this document to the other RFCs is discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

No. This document will not update any base 6lo documents or  existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to
its consistency with the body of the document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations procedures for future registrations
are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

A. The document does not request any IANA change.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public
guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

A. Not Applicable

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the
document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.(1) What type of
RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

A. Not Applicable