TSV-ART Reviewer: Gorry Fairhurst Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. The document primarily describes an architecture that provides a link layer /subnet method to support IPv6 datagrams over the TSCH mode of IEEE 802.15.4. Intended status ------------- The document is proposed with standards track status, but appears to mainly provide informational background about the architecture. There are no normative requirements made. This could be published as informational. * Use of References: I suggest someone checks the presence of a large body of informative references to current working group documents - rather than normative citation of the published work. I am concerned about citing individual work in progress within the body of the document: Final para of Section 3.1 makes a reference to an individual draft that appears to target the ROLL WG. Section 3.2 makes reference to an individual draft to describe multicast [ID.thubert…] Section 4.1.1 makes a reference to an individual draft that appears to target the ROLL WG, mentioned twice as defining something, Section 4.1.1 makes a reference to an individual draft that appears to target the ROLL WG. * References to unchartered individual work in Appendix. Appendix A describes a set of architectural dependencies that depend on non-adopted (individual) documents or work not formally chartered by the IETF. This description raises concerns about what happens when the present document is published, and this work is not taken-up or some alternative proposal is instead pursued, it would be safer to remove these references - or at least to confine them to an appendix that clearly sets out that this work is individual work in progress. Transport issues -------------- * "Transport Mode" Section 4.7.1 describes a "transport mode”, but from the perspective of the IETF transport area is not a transport. While there have been many interpretations of “transports” by SDOs and IETF Specs, I suggest it would beneficial to add a few words refining the meaning of the words in the present usage: e.g. that this does not provide a “transport protocol”, but provides a way to send and receive IPv6 packets that carry a transport protocol. * The IPv6 Flow Label may be zero Section 4.7.1.1 seems to imply that IPv6 packets carry a non-zero flow label value. Whilst I would support that desire, there are still cases where no flow label is set, and this casts should be described (or noted) in the text. * Assumption about IPv6 MTU Section 4.7.3 notes the IPv6 MTU is 1280 B. This is not true, please rewrite this sentence. It could be that the intentional was to state the minimum IPv6 MTU or something else was intended? * Possible PHB - reference to not chartered transport work. Section 4.8.3 describes a transport feature (diffserv PHB) and appears to promote an individual draft. The particular drafts appear to target tsvwg, but I do not recall these being proposed to that WG for adoption, and therefore this seems a little presumptuous to appear in the main body of text or within the architecture. The reference is also out-of-date. - I suggest it would be sufficient to explain that a future document could define a PHB for this purpose and refer to the IANA registry as the place where IETF-defined PHBs are listed. - Please this without citing a ref to an individual spec.? - In addition, I think if this sections retained, it needs to be moved to the appendix. Editorial Issues ------------- The following editorial issues should be addressed: The document makes frequent use of the phrase “in order to”, which in most (all?) cases could be replaced more simply by “to” without loss of meaning. This would remove several cases where the sentence could currently be mis-interpreted as requiring temporal ordering of the actions. Section 4.3.3: “infoirmation” should be “information”. Section 1, Sentence “Distributed is a concurrent model that..”. i could not understand the intended meaning of this sentence. “such a Advance metering”. “a” maybe should be “as”? Why is Advanced capitalised, I think this sentence lacks some necessary explanation, please add, and provide a reference. CoJP - no reference is provided to where this is specified.