Re: [Roll] AD Review of draft-ietf-roll-efficient-npdao-09

[Rahul Jadhav <[e-mail]>]

Thank you Alvaro for the detailed review. This has greatly improved the
document. We had to update major portion of the text and even though
there has been no semantic changes of DCO/DCO-ACK, there are lot
of text update and few new sections added.

Please find the responses to your comments and unless explicitly mentioned,
all the [nit]s and [minor]s comments are fixed as per your suggestions.
All the [major] comments have explicit responses.

Regards,
Rahul
-------------------------------------------

Dear authors:

Here's my review of this document.  The first part of the document mostly
resulted in nits, but (starting in §4) I then have some major comments.
I'll wait for those to be addressed before starting the IETF Last Call.

The most significant issue is the fact that the suggested values for the
DCO are already assigned!  The Shepherd's writeup says that a pilot
implementation exists -- which, I assume uses the suggested values.  What
is the impact on existing implementations?

[RJ] Our pilot implementation uses the codes which are assigned to P2P-RPL.
Since we do not have P2P-RPL currently implemented we missed out on this point.
We will be updating the values in the implementation once the
allocation is done.
Implementation-wise may have to just change the codes used.

[Line numbers come from idnits.]

...
14 Abstract

16   This document describes the problems associated with NPDAO messaging
17   used in RPL for route invalidation and signaling changes to improve
18   route invalidation efficiency.

[nit] Please expand NPDAO...you may have to do it completely (including
DAO).

[nit] RPL should be expanded in the Abstract as well...
[RJ] Fixed.

...
91 1.  Introduction

93   RPL [RFC6550] (Routing Protocol for Low power and lossy networks)
94   specifies a proactive distance-vector based routing scheme.  RPL has
95   an optional messaging in the form of DAO (Destination Advertisement
96   Object) messages using which the 6LBR (6Lo Border Router) and 6LR
97   (6Lo Router) can learn route towards the downstream nodes.  In
98   storing mode, DAO messages would result in routing entries been
99   created on all intermediate 6LRs from the node's parent all the way
100   towards the 6LBR.

[nit] s/messages using which the 6LBR (6Lo Border Router) and 6LR (6Lo
Router) can learn route/messages, which the 6LBR (6Lo Border Router) and
6LR (6Lo Router) can use to learn a route

[nit] s/routing entries been created/routing entries being created

[RJ] Fixed.

102   RPL allows use of No-Path DAO (NPDAO) messaging to invalidate a
103   routing path corresponding to the given target, thus releasing
104   resources utilized on that path.  A NPDAO is a DAO message with route
105   lifetime of zero, originates at the target node and always flows
106   upstream towards the 6LBR.  This document explains the problems
107   associated with the current use of NPDAO messaging and also discusses
108   the requirements for an optimized route invalidation messaging
109   scheme.  Further a new pro-active route invalidation message called
110   as "Destination Cleanup Object (DCO)" is specified which fulfills
111   requirements of an optimized route invalidation messaging.

[nit] s/allows use of/allows the use of

[nit] s/"Destination Cleanup Object (DCO)"/"Destination Cleanup Object"
(DCO)

[RJ] Fixed.
...
117 1.1.  Requirements Language and Terminology

119   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
120   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
121   document are to be interpreted as described in RFC 2119 [RFC2119].

[major] Please use the template in rfc8174.

[RJ] Updated based on RFC8174

123   6LR: 6LoWPAN Router.  This is an intermediate 6lowpan router which
124   allows traffic routing through itself in a multihop 6lo network.

[nit] Please be consistent: 6LoWPAN vs 6lowpan

[nit] You may have to define 6lo.

[minor] In this case, the definition includes the name: "6LoWPAN
Router...is an intermediate 6lowpan router..."

[nit] In general, simply pointing to rfc6550 (or other documents where the
terms are already defined) may be easier than redefining.

[RJ] Fixed.

...
161 1.2.  Current NPDAO messaging

163   RPL uses NPDAO messaging in the storing mode so that the node
164   changing it routing adjacencies can invalidate the previous route.
165   This is needed so that nodes along previous path can release any
166   resources (such as the routing entry) it maintains on behalf of
167   target node.

[nit] s/along previous path/along the previous path
[RJ] Fixed.

...
200 1.3.  Why NPDAO is important?

202   Nodes in LLNs may be resource constrained.  There is limited memory
203   available and routing entry records are one of the primary elements
204   occupying dynamic memory in the nodes.  Route invalidation helps 6LR
205   nodes to decide which entries could be discarded to better achieve
206   resource utilization.  Thus it becomes necessary to have efficient
207   route invalidation mechanism.  Also note that a single parent switch
208   may result in a "sub-tree" switching from one parent to another.
209   Thus the route invalidation needs to be done on behalf of the sub-
210   tree and not the switching node alone.  In the above example, when
211   Node (D) switches parent, the route updates needs to be done for the
212   routing tables entries of (C),(H),(A),(G), and (B) with destination
213   (D),(E) and (F).  Without efficient route invalidation, a 6LR may
214   have to hold a lot of stale route entries.

[nit] s/to have efficient/to have an efficient
[RJ] Fixed.

...
225 2.2.  Invalidate routes of dependent nodes

227   RPL does not specify how route invalidation will work for dependent
228   nodes rooted at switching node, resulting in stale routing entries of
229   the dependent nodes.  The only way for 6LR to invalidate the route
230   entries for dependent nodes would be to use route lifetime expiry
231   which could be substantially high for LLNs.

[nit] s/rooted at switching node/rooted at the switching node
[RJ] Fixed.

...
239 2.3.  Possible route downtime caused by async operation of NPDAO and DAO
...
247   In the example topology, consider Node (D) switches from parent (B)
248   to (C).  An NPDAO sent via previous route may invalidate the previous
249   route whereas there is no way to determine whether the new DAO has
250   successfully updated the route entries on the new path.

[nit] s/via previous route/via the previous route
[RJ] Fixed.

252 3.  Requirements for the NPDAO Optimization

254 3.1.  Req#1: Remove messaging dependency on link to the previous parent

256   When the switching node sends the NPDAO message to the previous
257   parent, it is normal that the link to the previous parent is prone to
258   failure (thats why the node decided to switch).  Therefore, it is
259   required that the route invalidation does not depend on the previous
260   link which is prone to failure.  The previous link referred here
261   represents the link between the node and its previous parent (from
262   whom the node is now disassociating).

[nit] s/thats/that's
[RJ] Fixed.

...
278 4.  Proposed changes to RPL signaling

[minor] These changes are not "proposed" anymore.  s/Proposed changes to
RPL signaling/Changes to RPL signaling
[RJ] Fixed.

280 4.1.  Change in RPL route invalidation semantics

282   As described in Section 1.2, the NPDAO originates at the node
283   switching the parent and traverses upstream towards the root.  In
284   order to solve the problems as mentioned in Section 2, the draft adds
285   new pro-active route invalidation message called as "Destination
286   Cleanup Object" (DCO) that originates at a common ancestor node
287   between the new and old path.  The common ancestor node generates a
288   DCO in response to the change in the next-hop on receiving a regular
289   DAO with updated path sequence for the target.

[nit] Maybe it's just me, but the "switching the parent" terminology
doesn't sound great.  By now I am not having to reread the text because my
mind tends to think of a switch (not the switching action)...but maybe
"changing", or even "switching to a new parent" may be better.  Another
option is to simply use the "target node" term defined above.  Please take
this comment for what it is: just a nit.

[nit] s/draft/document/g

[nit] s/adds new/adds a new

[nit] s/called as /called /g

[RJ] Fixed.

291   In Figure 1, when node D decides to switch the path from B to C, it
292   sends a regular DAO to node C with reachability information
293   containing target as address of D and a incremented path sequence
294   number.  Node C will update the routing table based on the
295   reachability information in DAO and in turn generate another DAO with
296   the same reachability information and forward it to H.  Node H also
297   follows the same procedure as Node C and forwards it to node A.  When
298   node A receives the regular DAO, it finds that it already has a
299   routing table entry on behalf of the target address of node D.  It
300   finds however that the next hop information for reaching node D has
301   changed i.e. the node D has decided to change the paths.  In this
302   case, Node A which is the common ancestor node for node D along the
303   two paths (previous and new), should generate a DCO which traverses
304   downwards in the network.

[major] I think that this illustration should be Normatively spelled out.
There are details, for example due to the fact that a new DAO is created at
every hop, that are not explicitly mentioned.  As the DAO is sent up the
tree, it is generated "with the same reachability information" -- I think
this document should be explicit about the setting of the I flag, the Path
Sequence to be used, etc..

[RJ] There is a new para added in the same section. Inspired by "DAO Base Rules"
section in rfc6550, a separate section "DCO Base Rules" is added which explains
rules an implementation should follow to handle DCO.

[major] Is a DCO generated at every hop?  IOW, A sends the DCO to G, which
takes action based on it (invalidates the routes) and then sends another
DCO (with the same information) to B...  If so, then that needs to be
explicitly specified as well.

[RJ] A new para in this section now clarifies this.

[nit] s/in DAO/in the DAO

[nit] s/i.e. the node D/i.e. node D
[RJ] Fixed.

306 4.2.  Transit Information Option changes

308   Every RPL message is divided into base message fields and additional
309   Options.  The base fields apply to the message as a whole and options
310   are appended to add message/use-case specific attributes.  As an
311   example, a DAO message may be attributed by one or more "RPL Target"
312   options which specify the reachability information for the given
313   targets.  Similarly, a Transit Information option may be associated
314   with a set of RPL Target options.

[nit] A reference to rfc6550 somewhere in the paragraph would help the
reader know that none of that is new...but a review.
[RJ] added ref.

316   The draft proposes a change in Transit Information option to contain
317   "Invalidate previous route" (I) bit.  This I-bit signals the common
318   ancestor node to generate a DCO on behalf of the target node.  The
319   I-bit is carried in the transit information option which augments the
320   reachability information for a given set of RPL Target(s).  Transit
321   information option should be carried in the DAO message with I-bit
322   set in case route invalidation is sought for the correspondig
323   target(s).

[nit] s/The draft proposes a change/This document specifies a change

[nit] s/in Transit Information option/in the Transit Information Option

[nit] s/contain "Invalidate/contain the "Invalidate

[nit] s/.  Transit information option/.  The Transit Information Option

[nit] s/correspondig/corresponding

[RJ] Fixed.

325     0                   1                   2                   3
326     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
327     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
328     |   Type = 0x06 | Option Length |E|I|  Flags    | Path Control  |
329     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
330     | Path Sequence | Path Lifetime |                               |
331     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
332     |                                                               |
333     +                                                               +
334     |                                                               |
335     +                        Parent Address*                        +
336     |                                                               |
337     +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
338     |                               |
339     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

341      Figure 2: Updated Transit Information Option (New I flag added)

[nit] Take the "*" off -- it was used in rfc6500, but has no meaning here.

[nit] Indent the definition of the fields for clarity.

[RJ] Fixed.
...
347   The common ancestor node SHOULD generate a DCO message in response to
348   this I-bit when it sees that the routing adjacencies have changed for
349   the target.  I-bit governs the ownership of the DCO message in a way
350   that the target node is still in control of its own route
351   invalidation.

[major] When/why would the common ancestor not generate a DCO message?
IOW, why is MUST not used?  I imagine that simply the nature of the LLN may
prevent it from generating one (which makes the SHOULD ok)...but I'm trying
to find out if there are other reasons.

[RJ] I could not think of any other reason as well. Having said that, I am also
not particularly religious about this i.e. am ok to change it to MUST if there
is any other good reason (from the WG pariticipants).

353 4.3.  Destination Cleanup Object (DCO)
...
383   K: The 'K' flag indicates that the recipient is expected to send a
384   DCO-ACK back.  If the DCO-ACK is not received even after setting the
385   'K', an implementation may choose to retry the DCO at a later time.
386   The number of retries are implementation and deployment dependent.
387   This document recommends using retries similar to what will be set
388   for DAO-ACK handling.

[minor] Why are the retries optional?  If "the recipient is expected to
send a DCO-ACK", then why wouldn't the sender retry?  If it doesn't matter,
then just don't set the flag.  Given that the DCO is akin to the DAO, maybe
use similar text as what is in rfc6550/§9.3...

[minor] The last sentence makes a recommendation, but with no reference.
 rfc6550 says that the retries are implementation specific...maybe mention
something like that here too.

[RJ] Have added the section "DCO Base Rules" inline with "DAO Base
Rules" (rfc6550/sect9.3).

390   D: The 'D' flag indicates that the DODAGID field is present.  This
391   flag MUST be set when a local RPLInstanceID is used.

393   Flags: The 6 bits remaining unused in the Flags field are reserved
394   for future use.  These bits MUST be initialized to zero by the sender
395   and MUST be ignored by the receiver.

[major] Do you expect IANA to manage the assignments of those bits?

[RJ] Yes, added this in IANA considerations section.


...
404   DODAGID (optional): 128-bit unsigned integer set by a DODAG root that
405   uniquely identifies a DODAG.  This field is only present when the 'D'
406   flag is set.  This field is typically only present when a local
407   RPLInstanceID is in use, in order to identify the DODAGID that is
408   associated with the RPLInstanceID.  When a global RPLInstanceID is in
409   use, this field need not be present.  Unassigned bits of the DCO Base
410   are reserved.  They MUST be set to zero on transmission and MUST be
411   ignored on reception.

[minor] "This field is typically only present when a local RPLInstanceID is
in use..."  "typically only present" is not in line with the MUST above
(describing the D flag): s/typically only present/only present

[RJ] Have changed the wordings here. Removed 'typically' also.

[major] The last couple of sentences seem to have been left behind, or at
least meant for their own paragraph... I see that similar text is used in
rfc6550...but I'm not sure what bits it refers to.

[RJ] Yeah, not sure what these bits are. I sheepishly picked up the whole
description as is from rfc6550. Removing this text even though it appears in
rfc6550.

413 4.3.1.  Secure DCO

415   A Secure DCO message follows the format in [RFC6550] figure 7, where
416   the base message format is the DCO message shown in Figure 3.

[nit] s/figure 7/Figure 7

418 4.3.2.  DCO Options

420   The DCO message MAY carry valid options.  This specification allows
421   for the DCO message to carry the following options:

423      0x00 Pad1
424      0x01 PadN
425      0x05 RPL Target
426      0x06 Transit Information
427      0x09 RPL Target Descriptor

429   The DCO carries a Target option and an associated Transit Information
430   option with a lifetime of 0x00000000 to indicate a loss of
431   reachability to that Target.

[major] Are the RPL Target and Transit Information options mandatory?  If
so, then that is at odds with the MAY above.

[RJ] Explicitly added the MUST clause for Target and Transit options. Also the
lifetime field in the transit option MUST be set to 0 in DCO's transit option.
Surprisingly rfc6550 does not mandate target/transit information in the DAO
message. We have raised this point with WG before and have already added this
to observation's draft.

[nit] s/a Target option/an RPL Target option

433 4.3.3.  Path Sequence number in the DCO

435   A DCO message may contain a Path Sequence in the transit information
436   option to identify the freshness of the DCO message.  The Path
437   Sequence in the DCO MUST use the same Path Sequence number present in
438   the regular DAO message when the DCO is generated in response to DAO
439   message.  The DAO and DCO path sequence are picked from the same
440   sequence number set.  Thus if a DCO is received by a 6LR and
441   subsequently a DAO is received with old seqeunce number, then the DAO
442   should be ignored.

[minor] To make sure I'm clear: the "DCO path sequence" refers to the Path
Sequence field in the Transit Information Option, right?  If so, please be
clear and specific.

[RJ] Updated.

[major] The text is not clear (I asked the same thing above) if the Transit
Information Option is mandatory or not in the DCO...is it?  The text above
says that the "DCO message may contain a Path Sequence in the transit
information option".  If the Transit Information Option is present, then
the Path Sequence is present too...so it sounds like the Transit
Information Option is not optional.

[RJ] We have made target/transit MUST options in DCO. DCO cannot operate
without these options.

[major] "Path Sequence in the DCO MUST use the same Path Sequence number
present in the regular DAO message when the DCO is generated in response to
DAO message"  The DAO message is obviously the one that triggered the
DCO...  When would a DCO *not* be originated in response to a DAO?  Are
there other cases when the DCO can be originated?  Requiring the same Path
Sequence is fine...the reason for this comment is the condition ("when the
DCO...").

[RJ] One other condition that i can think of is, if the common ancestor node
somehow believes that there are other high priority routing entries that it
must entertain, thus evicting existing ones. During such eviction the common
ancestor node could make use of the stored path sequence and initiate a DCO.
DCO can fully support this in current form. Do you think this use-case makes
sense? We introduced 'I' bit especially so that target is in full control of
its own invalidation. With such change we loosen up that part.

[minor] "The DAO and DCO path sequence are picked from the same sequence
number set."  I'm not sure what this means -- the text before it says that
the Path Sequence number "MUST use the same...present in the regular DAO
message", so in reality the Path Sequence in the DCO is not picked from the
same set...it's just copied.

[RJ] Yes the Path Sequence is simply copied. I have changed the wordings.

[minor] "Thus if a DCO is received by a 6LR and subsequently a DAO is
received with old seqeunce number, then the DAO should be ignored."  Should
this behavior be Normative?  IOW, do you want to use "SHOULD" instead?
Maybe even "MUST".  Just wondering: it seems like an important behavior..

[RJ] I have updated to MUST, because the older DAO MUST not be used.

[major] I know that the "ancestor node SHOULD generate a DCO message in
response to this I-bit" (§4.2), but what prevents a (rogue) ancestor from
generating a DCO at any other time?  The last sentence above opens the door
to an attack where the ancestor can send a DCO with a Path Sequence in the
future...and cause the route to be invalidated...*and* future updates to be
ignored.  Is this possible?  [This risk, and any possible mitigation should
be mentioned in the Security Considerations.]

[RJ] As commented above, yes, this is possible. I am wondering whether to
retain this behaviour as a feature i.e. common ancestor node could unilaterally
invalidate the route since it has all the possible state info required to do
this. I will reupdate the document based on response.

[nit] s/transit information option/Transit Information Option

[nit] s/response to DAO/response to a DAO

[nit] s/path sequence/Path Sequence

[minor] s/old seqeunce number/old Path Sequence number

[RJ] Fixed.

444 4.3.4.  Destination Cleanup Option Acknowledgement (DCO-ACK)

446   The DCO-ACK message may be sent as a unicast packet by a DCO
447   recipient in response to a unicast DCO message.

[minor] "may be sent"  Is this an optional response?  §4.3 defines the K
flag in the DCO to indicate "that the recipient is expected to send a
DCO-ACK back" -- that is not a Normative statement...but it seems like a
waste if no ACK is sent back.

[RJ] I have used SHOULD to send back the DCO-ACK. RFC6550 mentions similar
behaviour for DAO message with 'K' bit set.


...
477   Status: Indicates the completion.  Status 0 is defined as unqualified
478   acceptance in this specification.  The remaining status values are
479   reserved as rejection codes.

[minor] Do you expect IANA to handle the assignment of new codes?

[RJ] Unlike DAO-ACK status which has categorised statuses (normal status,
rejection, outright rejection), DCO-ACK status field is flat i.e. there is no
outright rejections. Added the status field to the IANA considerations section.


481   DODAGID (optional): 128-bit unsigned integer set by a DODAG root that
482   uniquely identifies a DODAG.  This field is only present when the 'D'
483   flag is set.  This field is typically only present when a local
484   RPLInstanceID is in use, in order to identify the DODAGID that is
485   associated with the RPLInstanceID.  When a global RPLInstanceID is in
486   use, this field need not be present.  Unassigned bits of the DCO-Ack
487   Base are reserved.  They MUST be set to zero on transmission and MUST
488   be ignored on reception.

[minor] Those last 2 sentences seem to be out of place.  Also, I think all
the bits are accounted for above.

[RJ] Yes this is fixed as per similar comment above.

[nit] s/DCO-Ack/DCO-ACK

490 4.3.5.  Secure DCO-ACK

492   A Secure DCO-ACK message follows the format in [RFC6550] figure 7,
493   where the base message format is the DCO-ACK message shown in
494   Figure 4.

[nit] s/figure 7/Figure 7

496 4.4.  Other considerations

498 4.4.1.  Dependent Nodes invalidation

500   Current RPL [RFC6550] does not provide a mechanism for route
501   invalidation for dependent nodes.  This document allows the dependent
502   nodes invalidation.  Dependent nodes will generate their respective
503   DAOs to update their paths, and the previous route invalidation for
504   those nodes should work in the similar manner described for switching
505   node.  The dependent node may set the I-bit in the transit
506   information option as part of regular DAO so as to request
507   invalidation of previous route from the common ancestor node.

[major] This part is underspecified.  How do the dependent nodes know of
the switch?  Is A (Figure 1) the common ancestor node mentioned above?

I found the same question being asked during WGLC, and the answer seems to
be: "the dependent nodes will always set the I-flag".  Is that my correct
interpretation?  The behavior needs to be reflected in the specification.

https://mailarchive.ietf.org/arch/msg/roll/LejLNET8Hk92wPWU3Xi6OaxCujg

[RJ] I have added a para to describe this more. Please check if it makes sense.

509 4.4.2.  NPDAO and DCO in the same network

511   Even with the changed semantics, the current NPDAO mechanism in
512   [RFC6550] can still be used, for example, when the route lifetime
513   expiry of the target happens or when the node simply decides to
514   gracefully terminate the RPL session on graceful node shutdown.
515   Moreover a deployment can have a mix of nodes supporting the proposed
516   DCO and the existing NPDAO mechanism.

[major] This text sounds as if the NPDAO is made optional. Is that the
intent?  rfc6550 says that "when a node removes a node from its DAO parent
set, it SHOULD send a No-Path DAO message".  If the behavior from rfc6550
is changing, then this document should be more specific and Normative about
it.

[RJ] Two new paras are added to further elaborate.

518 4.4.3.  DCO with multiple preferred parents

520   [RFC6550] allows a node to select multiple preferred parents for
521   route establishment.  Section 9.2.1 of [RFC6550] specifies, "All DAOs
522   generated at the same time for the same Target MUST be sent with the
523   same Path Sequence in the Transit Information".  Thus a DAO message
524   with the same path sequence MUST be sent to all the parents.
525   Subsequently when route invalidation has to be initiated, RPL
526   mentions that an NPDAO must be initiated with updated path sequence
527   to all the routes to be invalidated.

[major] "Thus a DAO message with the same path sequence MUST be sent to all
the parents."  This sentence seems to just be a repetition of what the
quoted text says...but making it Normative to this document.  I don't see
the point since the behavior is already Normative.

[RJ] I have removed the redundant statement.

[major] "RPL mentions that an NPDAO must be initiated with updated path
sequence to all the routes to be invalidated." I couldn't find a place in
rfc6550 that says that.

[RJ] I have updated the sentence.

529   With DCO, the Target node itself does not initiate the route
530   invalidation and it is left to the common ancestor node.  A common
531   ancestor node when it discovers an updated DAO from a new next-hop,
532   it initiates a DCO.  With multiple preferred parents, this handling
533   does not change.  But in this case it is recommended that an
534   implementation initiates a DCO after a time period such that the
535   common ancestor node may receive updated DAOs from all possible next-
536   hops.  This will help to reduce DCO control overhead i.e., the common
537   ancestor can wait for updated DAOs from all possible directions
538   before initiating a DCO for route invalidation.  The time period for
539   initiating a DCO could be based on the depth of the network.  After
540   timeout, the DCO needs to be generated for all the next-hops for whom
541   the route invalidation needs to be done.

[major] "With multiple preferred parents...it is recommended that an
implementation initiates a DCO after a time period..."  How does the
ancestor know if there are multiple parents or not?  Should this
recommendation be generic?  How long is should the ancestor wait?

[RJ] Have added two paras to explain the rationale for delaying DCO, what
happens if the DCO and DAO still overlaps and specific text to explain how to
set the timer.


...
548 6.  IANA Considerations

550   IANA is requested to allocate new ICMPv6 RPL control codes in RPL
551   [RFC6550] for DCO and DCO-ACK messages.

[major] The name of the registry is "RPL Control Codes".

[RJ] Fixed

s//IANA is requested to allocate new codes for the DCO and DCO-ACK messages
from the RPL Control Codes registry.

553   +------+---------------------------------------------+--------------+
554   | Code |                 Description                 |  Reference   |
555   +------+---------------------------------------------+--------------+
556   | 0x04 |          Destination Cleanup Object         |     This     |
557   |      |                                             |   document   |
558   | 0x05 |  Destination Cleanup Object Acknowledgement |     This     |
559   |      |                                             |   document   |
560   | 0x84 |      Secure Destination Cleanup Object      |     This     |
561   |      |                                             |   document   |
562   | 0x85 |      Secure Destination Cleanup Object      |     This     |
563   |      |               Acknowledgement               |   document   |
564   +------+---------------------------------------------+--------------+

[major] The values suggested in this table are already assigned.  I would
suggest you simply call the codes TBD1-TBD4.  Note that the corresponding
figures must also be updated.

https://www.iana.org/assignments/rpl/rpl.xhtml#control-codes

[RJ] Fixed as per suggestion


566   IANA is requested to allocate bit 18 in the Transit Information
567   Option defined in RPL [RFC6550] section 6.7.8 for Invalidate route
568   'I' flag.

[major] The registry is called "Transit Information Option Flags"...and the
requested assignment corresponds to bit 1.

[RJ] Fixed

s//IANA is requested to allocate bit 1 from the Transit Information Option
Flags registry the I-bit (Section 4.2).


570 7.  Security Considerations

[major] This section mostly points at rfc6550 (which is ok), but it doesn't
say anything about vulnerabilities (if any) that this specification may be
introducing...or why it doesn't. [See my related comment in §4.3.3.]

I would like to see (perhaps after the current text) something along the
lines of "This document introduces the ability to do abc.  It doesn't
introduce any new vulnerabilities becasue...  OR ... These are the new
vulnerabilities and this is how they can be mitigated...or why they are not
really of concern..."

[RJ] Have added this text in the beginning of the security considerations
section. Also have updated the "Unsecured" mode para, to say that the DCO and
DCO-ACK MUST be link-layer encrypted if link-layer security is been put to use.


...
609 Appendix A.  Example Messaging

611 A.1.  Example DCO Messaging

613   In Figure 1, node (D) switches its parent from (B) to (C).  The
614   sequence of actions is as follows:

616   1.  Node D switches its parent from node B to node C
617   2.  D sends a regular DAO(tgt=D,pathseq=x+1,I_flag=1) in the updated
618       path to C

[minor] The notation "DAO/DCO()" should be explained somewhere...and should
be consistent throughout (it changes below).

[RJ] Have added detailed explanation of the messaging convention used and the
details of the message parameters used.

619   3.  C checks for routing entry on behalf of D, since it cannot find
620       an entry on behalf of D it creates a new routing entry and
621       forwards the reachability information of the target D to H in a
622       DAO.

[nit] s/for routing entry/for a routing entry/g


...
637   7.  Similarly, B processes the DCO by invalidating the routing entry
638       of target D and forwards the (un)reachability information
639       downstream to D.

641   8.  D ignores the DCO since the target is itself.

[?] Just curious: why will B even propagate the DCO to D?  B already knows
that the target is D...

[RJ] B receives the target information of node D which is a non link-local IPv6
address. B cannot infer from this address that D is directly connected to it.

642   9.  The propagation of the DCO will stop at any node where the node
643       does not have an routing information associated with the target.
644       If the routing information is present and the pathseq associated
645       is not older, then still the DCO is dropped.

[major] This paragraph contains information that hasn't been specified
elsewhere in the document.  It must be.

[RJ] Have added this point in the "DCO Base Rules" section (newly added
section).

[minor] This sentence is awkwardly worded: "If the routing information is
present and the pathseq associated is not older, then still the DCO is
dropped."  Perhaps s/the pathseq associated is not older/its Path Sequence
is higher

[RJ] Fixed as per suggestion.

647 A.2.  Example DCO Messaging with multiple preferred parents
...
675   2.  (N32) sends DAO(tgt=N41,PS=x,I_flag=1) to (N22).  (N33) also
676       sends DAO(tgt=N41,PS=x,I_flag=1) to (N22).  (N22) learns multiple
677       routes for the same destination (N41) through multiple next-hops.
678       The route table at N22 should contain (Dst,NextHop,PS): {
679       (N41,N32,x), (N41,N33,x) }.
680   3.  (N22) sends DAO(tgt=N41,PS=x,I_flag=1) to (N11).

[major] The I_flag is set...but (N22) doesn't originate a DCO...  I think
the flag should not be set at this point.

[RJ] I have updated point 2 to explain why (N22) didnt initiate a DCO.

...
687   7.  (N32) sends DAO(tgt=N41,PS=x+1,I_flag=1) to (N22).  (N22) has
688       multiple routes to destination (N41).  It sees that a new path
689       sequence for Target=N41 is received and thus it waits for pre-
690       determined time period to invalidate another route
691       {(N41),(N33),x}. After time period, (N22) sends
692       DCO(tgt=N41,PS=x+1) to (N33).

[minor] The example is incomplete: (N33) sends a DCO to (N41)...

[RJ] Yes the example was incomplete (last 4 steps were missing).
Have added all the steps now.


On Fri, 12 Apr 2019 at 02:42, Alvaro Retana <[e-mail]> wrote:
>
> Dear authors:
>
> Here's my review of this document.  The first part of the document mostly
> resulted in nits, but (starting in §4) I then have some major comments