I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-cardenas-dff-09 Reviewer: Dan Romascanu Review Date: 2/19/2013 IETF LC End Date: 2/24/2013 IESG Telechat date: 2/28/2013 Summary: I have several questions and comments related to this document. Some of them may be the result of my lack of familiarity with this technology, some other may require clarifications or modifications in the document. Until the issues and questions noted below are addressed I cannot assess if this document is ready. Major issues: 1. Section 1 includes a note that 'this specification is intended for experimentation'. When such statements are made I believe the authors should include also some information about what kind of information they expect to receive from the experiments, where (in what types and sizes of networks) the experiments should be conducted, what are the criteria to consider the experiments successful. 2. In "mesh-under" mode both EUI-64 link layer addresses and 16-bit short addresses can be used. First question - can these be mixed in the same DFF domain? Second - the 16-bit short addresses are unique only within the same PAN. This means that a DFF domain cannot spin over more than one PAN. Am I correct or do I miss something? These should be articulated in the Applicability statement. 3. Are the protocol parameters defined in Section 8 configurable? Do they need to be kept in non-volatile memory to survive a power failure event? - there is no mention about this in the document. 4. Same question for the list of bidirectional neighbors - should they be stored in non-volatile memory, or are they completely rebuilt at (re)-boot? 5. Same question for the information sets used by DFF described in Section 6 - should they be stored in non-volatile memory, or are they completely rebuilt at (re)-boot? 6. In section 9.2 - what happened if when adding a new Processed Tuple based on a new incoming packet the routing discovers that the P_seq_number is already in used for another entry in the list. This can happen, as the sequence numbers are unique per routers, and current packets may originate from different routers? Is this not a problem? Why? 7. Section 14 - header formats - don't we need a version field? If not, why? 8. Security Considerations section 16.3.2 - should not Sequence Number Tampering be added to the Packet Header Modifications attacks? Minor issues: 1. The applicability statement says that the protocol ' Assumes that the underlying link layer provides means to detect if a Packet has been successfully delivered to the Next Hop or not', ' Is designed for networks with little traffic in terms of numbers of Packets per second', and 'Is used for unicast transmissions only'. These are limitations important enough to be mentioned in the Abstract and Introduction section. 2. Section 15 - am I right that DFF domains running in "route-over" MoP and "mesh-under" MoP never mix, so if they happen to be overlaying or adjoining one near the other they should be considered as distinct domains? If this is correct, I suggest to be explicit about this. Nits/editorial comments: 1. In Sections 2.1 and 2.2 the delimitors between the terms and their explanations are inconsistent (colons for some, dashes for other) _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
