Xavier - I hope the comments are helpful. In my opinion, it would be useful for the WG as a whole to discuss the intention for the document, and review whether that intention is sufficiently well-described to guide the WG in determining the contents of the document and to guide readers in how to use the document.
- Ralph > On Dec 24, 2016, at 12:27 AM, Xavier Vilajosana > <[email protected]> wrote: > > Dear Ralph, > > thanks so much for your comments. We will go through them and also will > consider Jonathan, Brian and Tero's comments sent some days back and provide > and updated version of the document asap. > > kind regards, > Xavi > > > 2016-12-23 19:53 GMT+01:00 Ralph Droms <[email protected]>: > My review of draft-ietf-6tisch-minimal-17 is included below. I recognize > that the IETF last call has ended, and I apologize for missing the > deadline. I hope this review will still be useful. > > In my opinion, draft-ietf-6tisch-minimal-17 has several major issues > and is not ready for publication. > > Most importantly, this document needs to explain its > intended use. From the Abstract: "This document describes a minimal > mode of operation for a 6TiSCH Network." Exactly what is a "minimal > mode of operation"? Is the document intended to describe: > > 1) a starting point for design and deployment of a "6TiSCH network"? > > 2) a baseline set of required protocols and modes of operation, which > will be extended by future specifications (as suggested in section 1)? > > 3) initial behavior that will guarantee out of the box > interoperability among devices from, say, different vendors? > > 4) something else? > > As an example, if I were reading the document for point 1, I can see > the value of pointing out, as in this rev of the document, various > operational choices. However, if I were reading the document for > point 3, I don't see how interoperability can be guaranteed given the > variety of specific choices a vendor might make in the production of a device. > > Major issues regarding the document as a whole: > > If this document is concerned with "IPv6 connectivity", why is there > no mention of address selection, prefix advertisement, use of ND, > etc.? Similarly, why is there no advice about 6LoWPAN compression > modes? > > What is the relationship between the recommended configuration in this > document and protocol semantics that provide the same configuration > parameters? For example, there are operational parameters provided in > EBs that are also specified in this document. How does a node choose > which parameters to use? > > A document such as this one that specifies the use of protocols > specified elsewhere should use pointers to the other specifications > wherever possible and should avoid repeating a description of those > other protocols. The danger is getting the specifications out of sync > or describing them in a misleading or incorrect way. In the case of > this document, in my opinion there is text that repeats the > description of aspects of the IEEE 802.15.4 and RPL specifications > that should be elided. For example, section 4.2 and 4.3 describe > details of cell transmission that appear to be redundant relative to > the IEEE 802.15.4 specification. > > Specific issues: > > From the Introduction: "a node learns the schedule of the network when > joining, the schedule is static and the same for all nodes". This > statement of operational behavior seems important. How does a node > learn the schedule? Is it up to the network administrator to > configure all the nodes so that the schedule is "static and the same > for all nodes"? What happens if different nodes advertise different > schedules (or other operational parameters) in EBs? Is that situation > considered an administrative error? > > In a related issue, I found the text in section 4.1 about future use > of unscheduled cells confusing, after the assertion that "There is > only a single scheduled cell in the slotframe". > > Similarly, in section 4.2, if the schedule is static, why is it > necessary to state that "The scheduled cell... cannot be moved or > relocated by any dynamic scheduling mechanism"? > > Section 4.4 seems to me to be a rewording of the IEEE 802.15.4 > specification. Is there some specific reason that the text is > included here? > > In section 5.1.1, the description of ETX computation "ETX is computed > using the reception/non-reception of link-layer ACKs" doesn't seem to > give enough information, while RFC 6551 specifically "does not mandate > the use of a specific formula to compute the ETX value". RFC 6551 > describes ETX as a constraint or as a path metric; in the latter case, > ETX is cumulative from the node to the DAG root. How is ETX > computed for this application? > > In section 5.2, what does the word "supported" mean? Which mode of > operation should be implemented according to this specification? > > I don't understand the relation between sections 6.2, "Initial Time > Source Neighbor Selection", 6.4, "Time Source Neighbor Selection" and > section 6.5, "Hysteresis". In particular, section 6.4 seems to give > only a requirement that a node must have a selected time source > neighbor, but gives no advice on how the node makes the selection. > > Editorial issues: > > In the Introduction, why is RPL called out specifically as a "natural > choice" without any justification? Why not just give the explicit > explanation that RPL is specified to provide the framework for > IEEE802.15.4 time sync? > > Check for consistency of parameter names and protocol fields; e.g., I > assume macTsRxAckDelay and tsRxAckDelay refer to the same information > element. > > In section 4.1, this instance of "MAY" is not an RFC 2119 usage: > "Dynamic scheduling solutions MAY be defined in the future [...]" > > In section 4.5.1, the first and third sentences seem to be redundant. > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
