Subject: [Roll] giving back MPDAO to RFC editor

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 4 Sep 2019 10:09:36 +0000

Dear all

We are holding NP DAO for a change that does not impact the behavior of the node but improves traceability.
I would like to confirm consensus on this change rapidly so we can give the doc back to RFC editor.

The proposed change is as follows:

----------------------------------

diff --git "a/C:\\Users\\pthubert\\Dropbox\\IETF\\doc\\rpi\\draft-ietf-roll-efficient-npdao-15.xml" "b/C:\\Users\\pthubert\\Dropbox\\IETF\\doc\\rpi\\draft-ietf-roll-efficient-npdao-16.xml"
index 8a0acca..2ed0920 100644
--- "a/C:\\Users\\pthubert\\Dropbox\\IETF\\doc\\rpi\\draft-ietf-roll-efficient-npdao-15.xml"
+++ "b/C:\\Users\\pthubert\\Dropbox\\IETF\\doc\\rpi\\draft-ietf-roll-efficient-npdao-16.xml"
@@ -35,7 +35,7 @@
<?rfc subcompact="yes" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
-<rfc category="std" docName="draft-ietf-roll-efficient-npdao-15" ipr="trust200902">
+<rfc category="std" docName="draft-ietf-roll-efficient-npdao-16" ipr="trust200902">
   <!-- category values: std, bcp, info, exp, and historic
      ipr values: full3667, noModification3667, noDerivatives3667
      you can add the attributes updates="NNNN" and obsoletes="NNNN"
@@ -582,11 +582,12 @@

             <t>
                 This document specifies a change in the Transit Information Option to
-                contain the "Invalidate previous route" (I) flag. This I-flag signals
+                contain the "Invalidate previous route" (I) flag. This 'I' flag signals
                 the common ancestor node to generate a DCO on behalf of the
-                target node. The I-flag is carried in the Transit Information
+                target node with a RPL Status of 130 indicating that the address
+                has moved. The 'I' flag is carried in the Transit Information
                 Option which augments the reachability information for a given
-                set of RPL Target(s). Transit Information Option with I-flag
+                set of RPL Target(s). Transit Information Option with 'I' flag
                 set should be carried in the DAO message when route
                 invalidation is sought for the corresponding target(s).
             </t>
@@ -615,8 +616,8 @@
             </t>
             <t>
                 The common ancestor node SHOULD generate a DCO message in
-                response to this I-flag when it sees that the routing
-                adjacencies have changed for the target. The I-flag is
+                response to this 'I' flag when it sees that the routing
+                adjacencies have changed for the target. The 'I' flag is
                 intended to give the target node control over its own route
                 invalidation, serving as a signal to request DCO generation.
             </t>
@@ -638,7 +639,7 @@
0                   1                   2                   3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| RPLInstanceID |K|D|   Flags   |   Reserved    | DCOSequence   |
+| RPLInstanceID |K|D|   Flags   |  RPL  Status  | DCOSequence   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
@@ -683,8 +684,15 @@
                 the sender and MUST be ignored by the receiver.
             </t>
             <t>
-                Reserved: 8-bit unused field. The field MUST be initialized to
-                zero by the sender and MUST be ignored by the receiver.
+                RPL Status: The RPL Status as defined in section 6.5.1 of <xref
+                target="RFC6550"/>.
+                Indicative of the reason why the DCO happened, the RPL Status
+                MUST NOT be changed as the DCO is propagated down the route
+                being invalidated.
+                This value is informative and does not affect the behavior of
+                the receiver. In particular, unknown values are ignored by the
+                receiver.
+                Only Rejection Codes (value above 128) are expected in a DCO.
             </t>
             <t>
                 DCOSequence: 8-bit field incremented at each unique DCO message
@@ -759,7 +767,7 @@
0                   1                   2                   3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| RPLInstanceID |D|   Flags     |  DCOSequence  |    Status     |
+| RPLInstanceID |D|   Flags     |  DCOSequence  | DCO-ACK Status|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
@@ -788,8 +796,10 @@
                     copied from the DCOSequence received in the DCO message.
                 </t>
                 <t>
-                    Status: Indicates the completion. Status 0 is defined as
-                    unqualified acceptance in this specification. Status 1 is
+                    DCO-ACK Status: Indicates the completion. A value of 0 is
+                    defined as
+                    unqualified acceptance in this specification. A value of 1
+                    is
                     defined as "No routing-entry for the Target found". The
                     remaining status values are reserved as rejection codes.
                 </t>
@@ -910,7 +920,7 @@
                     nodes will generate their respective DAOs to update their
                     paths, and the previous route invalidation for those nodes
                     should work in the similar manner described for switching
-                    node. The dependent node may set the I-flag in the Transit
+                    node. The dependent node may set the 'I' flag in the Transit
                     Information Option as part of regular DAO so as to
                     request invalidation of previous route from the common
                     ancestor node.
@@ -920,7 +930,7 @@
                     of their parents in turn have decided to switch their
                     parent. Thus for route invalidation the dependent nodes may
                     choose to always set the 'I' flag in all its DAO message's
-                    Transit Information Option. Note that setting the I-flag is
+                    Transit Information Option. Note that setting the 'I' flag is
                     not counterproductive even if there is no previous
                     route to be invalidated.
                 </t>
@@ -1103,7 +1113,7 @@

         <t>
             IANA is requested to allocate bit 1 from the Transit Information
-            Option Flags registry for the I-flag (<xref target="transit_opt_changes"/>)
+            Option Flags registry for the 'I' flag (<xref target="transit_opt_changes"/>)
         </t>
         <section title="New Registry for the Destination Cleanup Object (DCO) Flags">
             <t>
@@ -1210,22 +1220,29 @@
             This document introduces the ability for a common ancestor node to
             invalidate a route on behalf of the target node. The common
             ancestor node could be directed to do so by the target node using
-            the I-flag in DCO's Transit Information Option. However, the common
+            the 'I' flag in DCO's Transit Information Option. However, the common
             ancestor node is in a position to unilaterally initiate the route
             invalidation since it possesses all the required state information,
             namely, the Target address and the corresponding Path Sequence.
             Thus a rogue common ancestor node could initiate such an
            invalidation and impact the traffic to the target node.
         </t>
+        <t> The DCO carries a RPL Status value, which is informative. New Status
+            values may be created over time and a node will ignore an unknown
+            Status value. Which makes it so that the RPL Status field may be
+            used as a cover channel. But the channel only works once since the
+            message destroys its own medium, that is the existing route that it
+            is removing.
+        </t>
         <t>
-            This document also introduces an I-flag which is set by the target
+            This document also introduces an 'I' flag which is set by the target
             node and used by the ancestor node to initiate a DCO if the
             ancestor sees an update in the route adjacency. However,
             this flag could be spoofed by a malicious 6LR in the path and can
             cause invalidation of an existing active path. Note that invalidation
             will happen only if the other conditions such as Path Sequence
             condition is also met. Having said that, such a malicious 6LR may
-            spoof a DAO on behalf of the (sub) child with the I-flag set and
+            spoof a DAO on behalf of the (sub) child with the 'I' flag set and
             can cause route invalidation on behalf of the (sub) child node.
             Note that, using existing mechanisms offered by <xref
                 target="RFC6550"/>, a malicious 6LR might also spoof a DAO with

Chairs, could we please last call or whatever so we can move on?

Many thanks!

Pascal

---

From: Ines Robles <[email-masked]>
Date: Wed, 4 Sep 2019 13:33:48 +0300

Hi Pascal,

Thank you very much for your hard work.

Could you please convert the draft-ietf-roll-efficient-npdao-16.xml to txt [
https://xml2rfc.tools.ietf.org/] and put them here
https://github.com/roll-wg/efficient-route-invalidation, so people can read
the complete document with the proposed changes, thus we can have a last
call.

Many thanks again,

Ines and Peter.

On Wed, Sep 4, 2019 at 1:10 PM Pascal Thubert (pthubert) <[email-masked]>
wrote:

> diff --git
> "a/C:\\Users\\pthubert\\Dropbox\\IETF\\doc\\rpi\\draft-ietf-roll-efficient-npdao-15.xml"
> "b/C:\\Users\\pthubert\\Dropbox\\IETF\\doc\\rpi\\draft-ietf-roll-efficient-npdao-16.xml"
>
> ---
> "a/C:\\Users\\pthubert\\Dropbox\\IETF\\doc\\rpi\\draft-ietf-roll-efficient-npdao-15.xml"
>
> +++
> "b/C:\\Users\\pthubert\\Dropbox\\IETF\\doc\\rpi\\draft-ietf-roll-efficient-npdao-16.xml"
>
> @@ -35,7 +35,7 @@
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Ines Robles <[email-masked]>
Date: Wed, 4 Sep 2019 17:02:35 +0300

Dear all,

This is a last call for the modified NPDAO document (version 16) that you
can find here

https://github.com/pthubert/efficient-route-invalidation/blob/master/draft-ietf-roll-efficient-npdao.txt

This call is open until 23th September. Please let us know your opinion.

Thank you very much in advance,

Ines and Peter.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 4 Sep 2019 14:23:22 +0000

To generate rfcdiff https://tools.ietf.org/rfcdiff please use:
draft-ietf-roll-efficient-npdao
vs.
https://raw.githubusercontent.com/pthubert/efficient-route-invalidation/master/draft-ietf-roll-efficient-npdao.txt

All the best,

Pascal

From: Roll <[email-masked]> On Behalf Of Ines Robles
Sent: mercredi 4 septembre 2019 16:03
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: [Roll] Last call to draft-ietf-roll-efficient-npdao-16

Dear all,

This is a last call for the modified NPDAO document (version 16) that you can find here

Ines and Peter.

On Wed, Sep 4, 2019 at 1:10 PM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Dear all

             <t>

         <t>
             namely, the Target address and the corresponding Path Sequence..
             can cause route invalidation on behalf of the (sub) child node..

Many thanks!

Pascal
_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 4 Sep 2019 16:12:05 +0000

Hi Pascal,

The new text contains "RPL status code of 130 indicating that the address is moved". It has no reference and no IANA consideration. Is it ok to simply state this without explicit IANA consideration? Maybe I am just not aware of such procedural aspects of status code allocation, but how would a future work avoid using this value?

Regards,
Rahul

________________________________
From: Roll <[email-masked]> on behalf of Ines Robles <mariainesrobles=[email-masked]>
Sent: Wednesday, September 4, 2019 2:02 PM
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: [Roll] Last call to draft-ietf-roll-efficient-npdao-16

Dear all,

Ines and Peter.

Dear all

@@ -35,7 +35,7 @@

@@ -582,11 +582,12 @@

             <t>

             </t>

@@ -615,8 +616,8 @@

             </t>

             <t>

             </t>

@@ -638,7 +639,7 @@

0                   1                   2                   3

|                                                               |

+                                                               +

@@ -683,8 +684,15 @@

             </t>

             <t>

+                target="RFC6550"/>.

+                being invalidated.

+                receiver.

             </t>

             <t>

@@ -759,7 +767,7 @@

0                   1                   2                   3

|                                                               |

+                                                               +

@@ -788,8 +796,10 @@

                 </t>

                 <t>

+                    defined as

+                    is

                 </t>

@@ -910,7 +920,7 @@

                     ancestor node.

@@ -920,7 +930,7 @@

                     route to be invalidated.

                 </t>

@@ -1103,7 +1113,7 @@

         <t>

         </t>

             <t>

@@ -1210,22 +1220,29 @@

         </t>

+            is removing.

+        </t>

         <t>

Many thanks!

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 4 Sep 2019 17:37:47 +0000

Well since RPL did not create a registry we are on our own. My suggestion is to fix this in the RUL draft, see the IANA section there. The code 130 is consistent with it.

Regards,

Pascal

Le 4 sept. 2019 à 18:13, Rahul Jadhav <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Pascal,

Regards,
Rahul

________________________________
From: Roll <[email-masked]<mailto:[email-masked]>> on behalf of Ines Robles <mariainesrobles=[email-masked]<mailto:mariainesrobles=[email-masked]>>
Sent: Wednesday, September 4, 2019 2:02 PM
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Subject: [Roll] Last call to draft-ietf-roll-efficient-npdao-16

Dear all,

Ines and Peter.

Dear all

@@ -35,7 +35,7 @@

@@ -582,11 +582,12 @@

             <t>

             </t>

@@ -615,8 +616,8 @@

             </t>

             <t>

             </t>

@@ -638,7 +639,7 @@

0                   1                   2                   3

|                                                               |

+                                                               +

@@ -683,8 +684,15 @@

             </t>

             <t>

+                target="RFC6550"/>.

+                being invalidated.

+                receiver.

             </t>

             <t>

@@ -759,7 +767,7 @@

0                   1                   2                   3

|                                                               |

+                                                               +

@@ -788,8 +796,10 @@

                 </t>

                 <t>

+                    defined as

+                    is

                 </t>

@@ -910,7 +920,7 @@

                     ancestor node.

@@ -920,7 +930,7 @@

                     route to be invalidated.

                 </t>

@@ -1103,7 +1113,7 @@

         <t>

         </t>

             <t>

@@ -1210,22 +1220,29 @@

         </t>

+            is removing.

+        </t>

         <t>

Many thanks!

Pascal

---

From: Rahul Jadhav <[email-masked]>
Date: Thu, 5 Sep 2019 03:43:32 +0000

Thank you Pascal for the changes and pull request.
Have merged the changes.
I made two minor changes, please check if there are ok:
https://github.com/roll-wg/efficient-route-invalidation/commit/8af38e8f44b963987ee6754d644d6ef70409462f

If yes, then please use the latest xml from
https://github.com/roll-wg/efficient-route-invalidation/blob/master/draft-ietf-roll-efficient-npdao.xml

Thanks,
Rahul
________________________________
From: Roll <[email-masked]> on behalf of Ines Robles <mariainesrobles=[email-masked]>
Sent: Wednesday, September 4, 2019 10:33 AM
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: roll <[email-masked]>
Subject: Re: [Roll] giving back MPDAO to RFC editor

Hi Pascal,

Could you please convert the draft-ietf-roll-efficient-npdao-16.xml to txt [https://xml2rfc.tools.ietf.org/] and put them here https://github.com/roll-wg/efficient-route-invalidation, so people can read the complete document with the proposed changes, thus we can have a last call.

Many thanks again,

Ines and Peter.

Dear all

@@ -35,7 +35,7 @@

@@ -582,11 +582,12 @@

             <t>

             </t>

@@ -615,8 +616,8 @@

             </t>

             <t>

             </t>

@@ -638,7 +639,7 @@

0                   1                   2                   3

|                                                               |

+                                                               +

@@ -683,8 +684,15 @@

             </t>

             <t>

+                target="RFC6550"/>.

+                being invalidated.

+                receiver.

             </t>

             <t>

@@ -759,7 +767,7 @@

0                   1                   2                   3

|                                                               |

+                                                               +

@@ -788,8 +796,10 @@

                 </t>

                 <t>

+                    defined as

+                    is

                 </t>

@@ -910,7 +920,7 @@

                     ancestor node.

@@ -920,7 +930,7 @@

                     route to be invalidated.

                 </t>

@@ -1103,7 +1113,7 @@

         <t>

         </t>

             <t>

@@ -1210,22 +1220,29 @@

         </t>

+            is removing.

+        </t>

         <t>

Many thanks!

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 5 Sep 2019 06:29:38 +0000

Hello Rahul

RPL says

     1-127:  Not an outright rejection; the node sending the DAO-ACK
               is willing to act as a parent, but the receiving node is
               suggested to find and use an alternate parent instead.
     127-255:  Rejection; the node sending the DAO-ACK is unwilling to
               act as a parent.

Note that the 127 as a rejection is a typo. The intent was that 127 is not a rejection. We could write an erratum for this I guess so rejection starts at 128.

All the best,

Pascal

From: Rahul Jadhav <[email-masked]<mailto:[email-masked]>>
Sent: jeudi 5 septembre 2019 05:44
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Roll] giving back MPDAO to RFC editor

Thanks,
Rahul
________________________________
From: Roll <[email-masked]<mailto:[email-masked]>> on behalf of Ines Robles <mariainesrobles=[email-masked]<mailto:mariainesrobles=[email-masked]>>
Sent: Wednesday, September 4, 2019 10:33 AM
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: roll <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Roll] giving back MPDAO to RFC editor

Hi Pascal,

Many thanks again,

Ines and Peter.

Dear all

@@ -35,7 +35,7 @@

@@ -582,11 +582,12 @@

             <t>

             </t>

@@ -615,8 +616,8 @@

             </t>

             <t>

             </t>

@@ -638,7 +639,7 @@

0                   1                   2                   3

|                                                               |

+                                                               +

@@ -683,8 +684,15 @@

             </t>

             <t>

+                target="RFC6550"/>.

+                being invalidated.

+                receiver.

             </t>

             <t>

@@ -759,7 +767,7 @@

0                   1                   2                   3

|                                                               |

+                                                               +

@@ -788,8 +796,10 @@

                 </t>

                 <t>

+                    defined as

+                    is

                 </t>

@@ -910,7 +920,7 @@

                     ancestor node.

@@ -920,7 +930,7 @@

                     route to be invalidated.

                 </t>

@@ -1103,7 +1113,7 @@

         <t>

         </t>

             <t>

@@ -1210,22 +1220,29 @@

         </t>

+            is removing.

+        </t>

         <t>

Many thanks!

Pascal

---

From: Rahul Jadhav <[email-masked]>
Date: Thu, 5 Sep 2019 12:25:55 +0530

The erratum seems to have been reported long back.
Final updates: https://github.com/roll-wg/efficient-route-invalidation/commit/9fff6e6051c2a2560bddd3f5097bf19149edd52a

On Thu, 5 Sep 2019 at 12:01, Pascal Thubert (pthubert)
<[email-masked]> wrote:
> From: Rahul Jadhav <[email-masked]>
> To: Pascal Thubert (pthubert) <[email-masked]>; Routing Over Low power and Lossy networks <[email-masked]>
> On Wed, Sep 4, 2019 at 1:10 PM Pascal Thubert (pthubert) <[email-masked]> wrote:
>
> Dear all
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 5 Sep 2019 07:08:52 +0000

Cool. 

I created a pull request, also fixing the area tag. Seems you did too, so now we are conflicting : ) 
I'll let you handle it with the change that you prefer.

All the best,

Pascal

> -----Original Message-----
> From: Roll <[email-masked]> On Behalf Of Rahul Jadhav
> Sent: jeudi 5 septembre 2019 08:56
> Final updates: https://github.com/roll-wg/efficient-route-
> invalidation/commit/9fff6e6051c2a2560bddd3f5097bf19149edd52a
> 
> On Thu, 5 Sep 2019 at 12:01, Pascal Thubert (pthubert) <[email-masked]>
> wrote:
> >
> > Hello Rahul
> >
> >
> >
> > RPL says
> >
> >
> >
> > Note that the 127 as a rejection is a typo. The intent was that 127 is not a
> rejection. We could write an erratum for this I guess so rejection starts at 128.
> >
> >
> >
> > All the best,
> >
> >
> >
> > Pascal
> >
> >
> >
> > From: Roll <[email-masked]> on behalf of Ines Robles
> > <mariainesrobles=[email-masked]>
> > Could you please convert the draft-ietf-roll-efficient-npdao-16.xml to txt
> [https://xml2rfc.tools.ietf.org/] and put them here https://github.com/roll-
> wg/efficient-route-invalidation, so people can read the complete document
> with the proposed changes, thus we can have a last call.
> >
> >
> >
> > Many thanks again,
> >
> >
> >
> > Ines and Peter.
> >
> >
> >
> >
> >
> >
> >
> > diff --git "a/C:\\Users\\pthubert\\Dropbox\\IETF\\doc\\rpi\\draft-ietf-roll-
> efficient-npdao-15.xml"
> > +<rfc category="std" docName="draft-ietf-roll-efficient-npdao-16"
> > +ipr="trust200902">
> >
> > +                contain the "Invalidate previous route" (I) flag.
> > + This 'I' flag signals
> >
> > +                target node with a RPL Status of 130 indicating that
> > + the address
> >
> > +                has moved. The 'I' flag is carried in the Transit
> > + Information
> >
> > +                set of RPL Target(s). Transit Information Option with
> > + 'I' flag
> >
> > +                response to this 'I' flag when it sees that the
> > + routing
> >
> > +                adjacencies have changed for the target. The 'I' flag
> > + is
> >
> > +                RPL Status: The RPL Status as defined in section
> > + 6.5.1 of <xref
> >
> > +                target="RFC6550"/>.
> >
> > +                Indicative of the reason why the DCO happened, the
> > + RPL Status
> >
> > +                MUST NOT be changed as the DCO is propagated down the
> > + route
> >
> > +                being invalidated.
> >
> > +                This value is informative and does not affect the
> > + behavior of
> >
> > +                the receiver. In particular, unknown values are
> > + ignored by the
> >
> > +                receiver.
> >
> > +                    DCO-ACK Status: Indicates the completion. A value
> > + of 0 is
> >
> > +                    defined as
> >
> > +                    unqualified acceptance in this specification. A
> > + value of 1
> >
> > +                    is
> >
> > +                    node. The dependent node may set the 'I' flag in
> > + the Transit
> >
> > +                    Transit Information Option. Note that setting the
> > + 'I' flag is
> >
> > +            Option Flags registry for the 'I' flag (<xref
> > + target="transit_opt_changes"/>)
> >
> >          </t>
> >
> > +            the 'I' flag in DCO's Transit Information Option.
> > + However, the common
> >
> > +        <t> The DCO carries a RPL Status value, which is informative.
> > + New Status
> >
> > +            values may be created over time and a node will ignore an
> > + unknown
> >
> > +            Status value. Which makes it so that the RPL Status field
> > + may be
> >
> > +            used as a cover channel. But the channel only works once
> > + since the
> >
> > +            message destroys its own medium, that is the existing
> > + route that it
> >
> > +            is removing.
> >
> > +        </t>
> >
> >          <t>
> >
> > +            This document also introduces an 'I' flag which is set by
> > + the target
> >
> > +            spoof a DAO on behalf of the (sub) child with the 'I'
> > + flag set and
> >

---

From: Michael Richardson <[email-masked]>
Date: Tue, 10 Sep 2019 17:06:34 +0100

>      1-127: Not an outright rejection; the node sending the DAO-ACK is
    > willing to act as a parent, but the receiving node is suggested to find
    > and use an alternate parent instead.  127-255: Rejection; the node
    > sending the DAO-ACK is unwilling to act as a parent.

    > Note that the 127 as a rejection is a typo. The intent was that 127 is
    > not a rejection. We could write an erratum for this I guess so
    > rejection starts at 128.

Yes, that really needs to be an erratum.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 10 Sep 2019 17:08:11 +0100

> not a rejection. We could write an erratum for this I guess so

https://www.rfc-editor.org/errata/eid3287

---

From: Michael Richardson <[email-masked]>
Date: Tue, 10 Sep 2019 17:08:36 +0100

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > draft-ietf-roll-efficient-npdao vs.

I read the changes, and I agree.