Last Call Review of draft-cardenas-dff-09
review-cardenas-dff-09-genart-lc-romascanu-2013-02-24-00

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)