[Roll] Benjamin Kaduk's Abstain on draft-ietf-roll-aodv-rpl-13: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-roll-aodv-rpl-13: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the updates in -12 and -13, they're a big help for clarity and
readability.

I'm abstaining because I don't think this document should be published in
its current form, but cannot supply a concrete path to changes that would
make it suitable.  (I believe that such a path exists, but I cannot provide
a proof by construction.)  I'm also concerned about the level of review this
document has received, with multiple errors having gone uncaught until the
IESG Evaluation stage.

That said, I do have some additional comments to offer in the hope that they
improve the document.

Section 6.4.1 (RREP handling) directs the router's processing to proceed to
§6.2.2 (RREQ handling), which seems like an unfortunate copy/paste error.

I continue to believe that it would be very helpful to depict the 'S bit'
information associated with an RREQ-Instance as a tristate rather than a
single bit.  In essence, this state reflects the contract between adjacent
nodes about how to process the corresponding RREP-DIO, but a given
(intermediate) router needs to know what contract to use both when
processing an incoming RREP-DIO and when emitting an RREP-DIOO (indeed, even
to know whether to emit unicast or multicast), and it's hard to see how a
single bit could cover both incoming and outgoing RREP-DIOs at the point of
transition.

A few other section-by-section notes follow.

Section 4.1

   L
      2-bit unsigned integer determining the length of time that a node
      is able to belong to the RREQ-Instance (a temporary DAG including
      the OrigNode and the TargNode).  Once the time is reached, a node
      MUST leave the RREQ-Instance and stop sending or receiving any
      more DIOs for the RREQ-Instance.  This naturally depends on the
      node's ability to keep track of time.  Once a node leaves an RREQ-
      Instance, it MUST NOT rejoin the same RREQ-Instance.  L is
      independent from the route lifetime, which is defined in the DODAG
      configuration option.

I assume that this "MUST NOT rejoin" would have some timeframe associated
with it (at least for L != 0x00), since the instance-id could eventually be
reused for a different logical instance.

Section 4.2

   L
      2-bit unsigned integer defined as in RREQ option.  The lifetime of
      the RREP-Instance MUST be shorter than the lifetime of the RREQ-
      Instance to which it is paired.

Strictly shorter, or "less than or equal to"?  I think, given the limited
options, strictly shorter would be pretty disruptive.

Section 6.2.4

   Suppose a router has joined the RREQ-Instance, and H=0, and the S-bit
   of the RREQ-Instance is set to 1.  In this case, the router MAY
   optionally associate to the RREQ-Instance, the Address Vector of the
   symmetric route back to OrigNode.  This is useful if the router later
   receives an RREP-DIO that is paired with the RREQ.

I think we should say what happens if I don't do what the MAY says.  Do we
just fail to find a route entirely, or only with degraded performance, or
...?

Section 6.4.2

   The router updates its stored value of the TargNode's sequence number
   according to the value provided in the ART option.  The router next
   checks if one of its addresses is included in the ART Option.  If so,
   this router is the OrigNode of the route discovery.  [...]

This seems to set up a scenario where TargNode learns about its own sequence
number updates by processing the ART Option, which is rather amusing to
think about :)

NITS

Section 6.1

   RPLInstance and a DODAG rooted at itself.  Then it transmits a DIO
   message containing exactly one RREQ option (see Section 4.1) to
   multicast group all-RPL-nodes.  The DIO MUST contain at least one ART

"the multicast group".