Received changes through RFC Editor sync (created alias RFC 8163, changed title to 'Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks', changed abstract to 'Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily 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.', changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2017-05-05, changed IESG state to RFC Published)

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.31. 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 3Rephrase 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 4Consider rephrasing to "This specification restricts an MSDU length for at least 1280 octets and at most 1500 octets (before encoding)."

Section 51. 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 6Consider 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 10Consider 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 12Consider 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.

2016-12-01

06

Jari Arkko

[Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko

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.

[Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli

2016-11-30

06

Spencer Dawkins

[Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins

2016-11-30

06

Suresh Krishnan

IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead

2016-11-30

06

Deborah Brungard

[Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard

2016-11-30

06

Terry Manderson

[Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson

2016-11-30

06

Alissa Cooper

[Ballot discuss]Section 12 says:

"For this reason, it is RECOMMENDED that a different (but stable) IID be generated for each globally scoped address ...

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

2016-11-30

06

Alissa Cooper

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

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

2016-11-30

06

Alissa Cooper

[Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper

2016-11-30

06

Mirja Kühlewind

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

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

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!

2016-11-30

06

Mirja Kühlewind

[Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind

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

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

2016-11-30

06

Stephen Farrell

[Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell

2016-11-30

06

(System)

IESG state changed to Waiting for AD Go-Ahead from In Last Call

2016-11-29

06

Kathleen Moriarty

[Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty

2016-11-29

06

Alia Atlas

[Ballot comment]In Appendix B, given that there is code, it would be good to specifically mark it as such. As I recall, there ...

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

2016-11-29

06

Alia Atlas

[Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas

2016-11-29

06

Ben Campbell

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

[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

2016-11-29

06

Ben Campbell

[Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell

2016-11-29

06

Alvaro Retana

[Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana

2016-11-29

06

Suresh Krishnan

Ballot has been issued

2016-11-29

06

Suresh Krishnan

[Ballot Position Update] New position, Yes, has been recorded for Suresh Krishnan

The IESG has received a request from the IPv6 over Networks ofResource-constrained Nodes WG (6lo) to consider the following document:- 'Transmission of IPv6 over MS/TP Networks' <draft-ietf-6lo-6lobac-06.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicitsfinal comments on this action. Please send substantive comments to theietf@ietf.org mailing lists by 2016-11-30. Exceptionally, comments may besent to iesg@ietf.org instead. In either case, please retain thebeginning 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.

(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 ...

(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 indicatedin 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 headerformat, the author expressed concerns over draft-ietf-6man-default-iids restrictions and suggestions for usingprivacy 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 manyother 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

2016-07-28

05

Samita Chakrabarti

Responsible AD changed to Suresh Krishnan

2016-07-28

05

Samita Chakrabarti

IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up

2016-07-28

05

Samita Chakrabarti

IESG state changed to Publication Requested

2016-07-28

05

Samita Chakrabarti

IESG process started in state Publication Requested

2016-07-28

05

Samita Chakrabarti

Tag Doc Shepherd Follow-up Underway cleared.

2016-07-28

05

Samita Chakrabarti

Changed consensus to Yes from Unknown

2016-07-28

05

Samita Chakrabarti

Intended Status changed to Proposed Standard from None

2016-07-28

05

Samita Chakrabarti

Changed document writeup

2016-06-16

05

Kerry Lynn

New version available: draft-ietf-6lo-6lobac-05.txt

2016-06-02

04

Samita Chakrabarti

Tag Doc Shepherd Follow-up Underway set.

2016-06-02

04

Samita Chakrabarti

IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead

2016-04-06

04

Samita Chakrabarti

IETF WG state changed to Waiting for WG Chair Go-Ahead from WG Consensus: Waiting for Write-Up

2016-04-06

04

Samita Chakrabarti

IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead

2016-04-06

04

Samita Chakrabarti

IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call