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

Good comments by Alissa, Mirja and others.

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 <CODE_BEGINS> and <CODE_ENDS>.

Thanks for addressing my DISCUSS and COMMENTs. One nit in Section 12: 

s/strongly RECOMMENDED/RECOMMENDED/

Qualifiers on 2119 keywords don't change their meaning.

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

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.

Mahesh Jethanandani <mjethanandani@gmail.com> 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 '<CODE BEGINS>' and
     '<CODE ENDS>' lines.

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com





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

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!

- 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 <CODE BEGINS> stuff, assuming that's not
problematic.)