Dear Brian, find below our answers to your comments. They have been included to v18 of the draft recently published. -------------------
1) MAJOR COMMENT 1 I was very confused for several pages until I went back and read this again: > This specification defines operational parameters and procedures for > a minimal mode of operation to build a 6TiSCH Network. The 802.15.4 > TSCH mode, the 6LoWPAN framework, RPL [RFC6550], and its Objective > Function 0 (OF0) [RFC6552], are used unmodified. Then I realised that there is some very basic information missing at the beginning of the Introduction. That little phrase "the 6LoWPAN framework" seems to be the clue. What is the 6LoWPAN framework? Which RFCs? I'm guessing it would be RFC4944, RFC6282 and RFC6775, but maybe not. In any case, the very first sentence of the Introduction really needs to be a short paragraph that explains in outline, with citations, how a 6TiSCH network provides IPv6 connectivity over NBMA. With that, the rest of the document makes sense. RESOLUTIONS Introduction and abstract have been changed to clarify this point. NEW abstract This document describes a minimal mode of operation for a 6TiSCH Network. A minimal mode of operation is a baseline set of protocols, recommended configurations and modes of operation sufficient to enable a 6TiSCH functional network. 6TiSCH provides IPv6 connectivity over a Time Synchronized Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a collection of protocols with the respective configurations, including the 6LoWPAN framework, enabling interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH. This minimal configuration provides the necessary bandwidth for network and security bootstrap and defines the proper link between the IETF protocols that interface to the IEEE Std 802.15.4 TSCH. This minimal mode of operation should be implemented by all 6TiSCH compliant devices. NEW Introduction A 6TiSCH Network provides IPv6 connectivity [RFC2460] over a Time Synchronized Channel Hopping (TSCH) mesh [RFC7554] composed of IEEE Std 802.15.4 TSCH links [IEEE802154-2015]. IPv6 connectivity is obtained by the use of the 6LoWPAN framework ([RFC4944], [RFC6282], [RFC8025],[I-D.ietf-6lo-routing-dispatch] and [RFC6775]), RPL [RFC6550], and its Objective Function 0 (OF0) [RFC6552]. This specification defines operational parameters and procedures for a minimal mode of operation to build a 6TiSCH Network. Any 6TiSCH complaint device SHOULD implement this mode of operation. This operational parameters configuration provides the necessary bandwidth for nodes to bootstrap the network. The bootstrap process includes initial network configuration and security bootstrap. In this specification, the 802.15.4 TSCH mode, the 6LoWPAN framework, RPL [RFC6550], and its Objective Function 0 (OF0) [RFC6552], are used unmodified. Parameters and particular operations of TSCH are specified to guarantee interoperability between nodes in a 6TiSCH Network. RPL is specified to provide the framework for time synchronization in an 802.15.4 TSCH network. The specifics for interoperable interaction between RPL and TSCH are described. In a 6TiSCH network, nodes follow a communication schedule as per 802.15.4 TSCH. In it, nodes learn the schedule of the network when joining. When following this specification, the learned schedule is the same for all nodes and does not change over time. Future specifications may define mechanisms for dynamically managing the communication schedule. Dynamic scheduling solutions are out of scope of this document. IPv6 addressing and compression are achieved by the 6LoWPAN framework. The framework includes [RFC4944], [RFC6282], [RFC8025], the 6LoWPAN Routing Header dispatch [I-D.ietf-6lo-routing-dispatch] for addressing and header compression, and [RFC6775] for duplicate address detection (DAD) and address resolution. More advanced work is expected in the future to complement the Minimal Configuration with dynamic operations that can adapt the schedule to the needs of the traffic at run time. 2)MAJOR COMMENT 2 But related to that, the Abstract is confusing in the same way: > Abstract > > This document describes a minimal mode of operation for a 6TiSCH > Network. It provides IPv6 connectivity over a Non-Broadcast Multi- > Access (NBMA) mesh... "It" is confusing since it seems to refer to this document, which hardly mentions IPv6 connectivity. I suggest s/It/6TiSCH/. RESOLUTION NEW abstract This document describes a minimal mode of operation for a 6TiSCH Network. A minimal mode of operation is a baseline set of protocols, recommended configurations and modes of operation sufficient to enable a 6TiSCH functional network. 6TiSCH provides IPv6 connectivity over a Time Synchronized Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a collection of protocols with the respective configurations, including the 6LoWPAN framework, enabling interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH. This minimal configuration provides the necessary bandwidth for network and security bootstrap as well as define the proper link between the IETF protocols that interface the IEEE Std 802.15.4 TSCH. This minimal mode of operation should be implemented by all 6TiSCH compliant devices. 3) MAJOR COMMENT 3 As far as I know a Security Considerations section is still always required. I understand that this document discusses security in detail, but that doesn't cancel the requirement ( https://tools.ietf.org/html/rfc3552#section-5). RESOLUTION Added Security Considerations Section. (See document as it is long). 4) MINOR COMMENT 1 > 4.4. Timeslot Timing ... > The RX node needs to send the first bit after the > SFD of the MAC acknowledgment exactly tsTxAckDelay after the end of > the last byte of the received packet. I don't understand "exactly". Nothing is exact - there is always clock jitter. Shouldn't there be a stated tolerance rather than "exactly"? DISCUSSION This comment doesn’t really apply. tsTxAckDelay is measured from the end of the data packet until the beginning of the ACK. Per Table 8-145 in IEEE802.15.4-2015, 1000 us. Even if the drift is 100ppm, the error would be 100ns. The max error allowed macTsAckWait is 400us. That discussion does not belong in an IETF document, it’s IEEE world RESOLUTION Suggestion: drop the word “exactly” OLD The RX node needs to send the first bit after the SFD of the MAC acknowledgment exactly tsTxAckDelay after the end of the last byte of the received packet NEW The RX node sends the first bit after the SFD of the MAC acknowledgment tsTxAckDelay after the end of the last byte of the received packet. 5)MINOR COMMENT 2 > 4.5. Frame Formats > > The following sections detail the RECOMMENDED format of link-layer > frames of different types. A node MAY use a different formats (bit > settings, etc)... Doesn't this create an interoperability issue for independent implementations? How can you mix and match implementations that use variants of the frame format? DISCUSSION The title of the section is unclear. IEEE802.15.4-2015 defines the format of frames. Through a set of flags, IEEE802.15.4-2015 allows for several fields to be present or not, to have different lengths and different values. This specification details the RECOMMENDED contents of the IEEE802.15.4 frame, while strictly complying to IEEE802.15.4-2015. RESOLUTION OLD Frame Format The following sections detail the RECOMMENDED format of link-layer frames of different types. A node MAY use a different formats (bit settings, etc), but MUST implement IEEE802.15.4 TSCH correctly. As long as an implementation follows IEEE802.15.4 TSCH correctly, it is compliant to this specification. NEW Frame Contents <xref target="IEEE802154-2015"/> defines the format of frames. Through a set of flags, <xref target="IEEE802154-2015"/> allows for several fields to be present or not, to have different lengths, and to have different values. This specification details the RECOMMENDED contents of IEEE802.15.4 frames, while strictly complying to <xref target="IEEE802154-2015"/>. 6)MINOR COMMENT 3 This seems particularly strange: > The IEEE802.15.4 header of BEACON, DATA and ACKNOWLEDGMENT frames > SHOULD include the Source Address field and the Destination Address > field. How will it work if some nodes omit the addresses? DISCUSSION Again, this is an IEEE discussion which we don’t want to start at the IETF The IEEE header allows for some addresses to be omitted, so in some cases it could make sense to omit some addresses We are NOT redefining any of that, and the IETF spec is not the right location to have those discussions (as highlighted by Brian’s remark) RESOLUTION Suggestion: drop the discussion from this spec OLD The IEEE802.15.4 header of BEACON, DATA and ACKNOWLEDGMENT frames SHOULD include the Source Address field and the Destination Address field. The Frame Version field SHOULD be set to 0b10 (Frame Version 2). The IEEE802.15.4 header SHOULD include Source Address field and the Destination Address field. The Sequence Number field MAY be elided. NEW The Frame Version field SHOULD be set to 0b10 (Frame Version 2). The Sequence Number field MAY be elided. 7)MINOR COMMENT 4 > 4.6. Link-Layer Security ... > For early interoperability testing, value 36 54 69 53 43 48 20 6D 69 > 6E 69 6D 61 6C 31 35 ("6TiSCH minimal15") MAY be used for K1. Shouldn't this also say that this value MUST NOT be used in operational networks? DISCUSSION See comments to Tero. The current texts reads as follow: The value 36 54 69 53 43 48 20 6D 69 6E 69 6D 61 6C 31 38 ("6TiSCH minimal18") is RECOMMENDED for PI, but a network operator MAY change it for administrative and segregation reasons. 8) NITS 1 > 1. Introduction > > A 6TiSCH Network provides IPv6 connectivity... I would expect to see a reference to [RFC2460] right there. RESOLUTION citation to [RFC2460] has been added. 9)NITS 2 Outdated reference: draft-ietf-6lo-paging-dispatch has been published as RFC 8025. RESOLUTION The reference has been updated. -- Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 [email protected] <[email protected]> http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya]
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
