Subject: Re: [Roll] AD Review of draft-ietf-roll-unaware-leaves-18

From: Alvaro Retana <[email-masked]>
Date: Tue, 6 Oct 2020 14:00:44 -0400

Pascal:

Hi!

I'm including 3 different sections below.

(1) Inline comment to your response to my review (of -18).

(2) Some additional nits on -21.

(3) You didn't reply past the initial comment in §5, which makes me think
    that your email client truncated my message. :-(  [I've seen this happen
    many times before, specially when the receiver is using Outlook.  Please
    take a look at the archive just in case.]  I am including the comments
    starting in §5 (based on -18).  The sections don't match to -21, but I'll
    leave that exercise to you. ;-)

About Updates: 6550...

Thanks!

Alvaro.

 === Part 1: comments on your review ===

On September 18, 2020 at 10:00:30 AM, Pascal Thubert wrote:

...
> > 440 4. Updating RFC 6550
...
> > 442 This document specifies a new behavior whereby a 6LR injects DAO
> > 443 messages for unicast addresses (see Section 10) and multicast
> > 444 addresses (see Section 11) on behalf of leaves that are not aware of
> > 445 RPL. The RUL addresses are exposed as external targets [RFC6550].
> > 446 Conforming [USEofRPLinfo], an IP-in-IP encapsulation between the 6LR
> > 447 and the RPL Root is used to carry the RPL artifacts and remove them
> > 448 when forwarding outside the RPL domain, e.g., to a RUL.
> >
>
> >
> > [] Is there anything in rfc6550 that limits the source of the routing
> > information in the DAOs? It seems to me that rfc6550 already allows
> > external information to be injected in the network...so getting it from a
> > RUL doesn't sound like an Update to me.
> >
>
> True, that is not why we have the updates. See sections "Updated RPL Status
> " and "Updated RPL Target Option"

...but this text is in the section titled "Updating RFC 6550".

Perhaps this section should be titled "Changes/Enhancements/? to
rfc6550" -- and then the subsections can explicitly spell out the
Updates.  [Assuming that change, I won't make the same comment on the
other pieces of this section.]

This clear differentiation between items that are
changes/enhancements, and ones that represent a formal Update is what
I want to see clarified.

 === Part 2: Additional comments based on -21 ===

[Line numbers from idnits.]

...
99	1.  Introduction
...
140	   In that mode, IPv6 addresses are advertised individually as Host
141	   routes.  Some nodes may act as Routers and participate to the
142	   forwarding operations whereas others will only terminate packets,
143	   acting as Hosts in the data-plane.  In [RFC6550] terms, an IPv6 Host
144	   [RFC8504] that is reachable over the RPL network is called a Leaf.

[nit] s/participate to/participate in/g

...
188	   *  Section 6, Section 7, and Section 8 present the additions made to
189	      [RFC6550], [EFFICIENT-NPDAO], and [RFC8505].

[] "additions"  Changes/extensions/updates??

 === Part 3: remaining comments (based on -18) ===

...
484	5.  Updating draft-ietf-roll-efficient-npdao

[major] To me, Updating an RFC means that the implementations of that
RFC should also implement this one.  In this case, there would be an
expectation that all nodes that support the DCO would support the
Non-Storing MOP as well.  Is that what is intended?

Note that Updating is different than simply expecting the nodes that
implement this specification to comply.

[Personal opinion: I don't think a formal Update of
draft-ietf-roll-efficient-npdao is needed.  As mentioned below, this
document "extends"...]

486	  [EFFICIENT-NPDAO] defines the DCO for RPL Storing Mode only, with a
487	  link-local scope.  This specification extends its use to the Non-
488	  Storing MOP, whereby the DCO is sent unicast by the Root directly to
489	  the RAN that injected the DAO message for the considered target.

491	  This specification leverages the DCO between the Root and the 6LR
492	  that serves as attachment router for a RUL.

[] Just another piece of information: draft-ietf-roll-efficient-npdao
already "assumes that all the 6LRs in the network support this
specification".  draft-ietf-roll-efficient-npdao did not Update
rfc6550, so it is not expected that "basic" RPL nodes would know what
the DCO is...

[major] Regardless of whether this document Updates NPDAO or not, some
text should be added related to the possibility that not all nodes may
know what the DCO is.  See §10.2.3.

494	6.  Updating RFC 8505

[major] To me, Updating an RFC means that the implementations of that
RFC should also implement this one.  In this case, there would be an
expectation that all 6LRs would support the change.  Is that what is
intended?

Note that Updating is different than simply expecting the nodes that
implement this specification to comply...in this case, *if* "the RPL
Root advertise[s] the capability...".

[Personal opinion: rfc8505 applies to 6LRs in general, not just RPL
routers in particular...so I think that Updating it is not the right
choice.]

496	  This document updates [RFC8505] to change the behavior of a RPL
497	  Router acting as 6LR in the 6LoWPAN ND Address Registration of a RUL
498	  acting as 6LN.  If the RPL Root advertise the capability to proxy the
499	  EDAR/EDAC exchange to the 6LBR, the 6LR refrains from sending the
500	  keep-alive EDAR message.  Instead, if it is separated from the 6LBR,
501	  the Root regenerates the EDAR message to the 6LBR periodically, upon
502	  a DAO message that signals the liveliness of the Address.

[nit] s/Root advertise/Root advertises

[] See the comment in §8 about a separate reason to Update rfc8505 and rfc6775.

...
510	7.1.  Support of 6LoWPAN ND

512	  In order to obtain routing services from a 6LR, a RUL MUST implement
513	  [RFC8505] and set the "R" and "T" flags in the EARO.  The RUL SHOULD
514	  support [AP-ND] to protect the ownership of its addresses.  The RUL
515	  MUST NOT request routing services from a 6LR that does not originate
516	  RA messages with a CIO that has the L, P, and E flags all set as
517	  discussed in Section 3.3.1, unless configured to do so.

[major] I may be lost already...  A RUL is by definition RPL-unaware.
It then follows that a RUL can't be assumed to be aware of this
specification, right?  If so, then all the Normative language used in
this section can't be used because we can't specify the behavior of a
node that (by definition) is not aware of this document.  [See more
related comments below.]

Note that §1 defines a RUL this way: "A RUL is an IPv6 Host [RFC8504]
that needs a RPL-Aware Router to obtain routing services over the RPL
network."

[major] "The RUL SHOULD support [AP-ND] to protect the ownership of
its addresses."   When it is ok for the RUL not to support AP-ND?
IOW, why is the support only recommended and not required?

...
523	  Parallel Address Registrations to several 6LRs SHOULD be performed in
524	  an rapid sequence, using the exact same EARO for the same Address.
525	  Gaps between the Address Registrations will invalidate some of the
526	  routes till the Address Registration finally shows on those routes.

[nit] s/an rapid sequence/rapid sequence

[nit] s/the exact same EARO/the same EARO

[major] How fast is in "rapid sequence"...how big can "gaps" be?  If
using Normative language, then the text needs to be specific.

528	  [RFC8505] introduces error Status values in the NA(EARO) which can be
529	  received synchronously upon an NS(EARO) or asynchronously.  The RUL
530	  MUST support both cases and MUST refrain from using the address when
531	  the Status Value indicates a rejection.

[major] "MUST support both cases and MUST refrain"  Isn't this
behavior already specified in rfc8505?  We shouldn't use normative
language in that case (unless you are quoting directly).

[major] I didn't find a "rejection" Status Value.  I'm assuming you're
referring to a group of values: Duplicate Address, Moved, etc..
Please be explicit.

533	7.2.  External Routes and RPL Artifacts

535	  Section 4.1 of [USEofRPLinfo] provides a set of rules detailed below
536	  that MUST be followed for routing packets from and to a RUL.

[major] Because the specification is in USEofRPLinfo already, then
there's no need to normatively require it here as well.  Also, not all
the actions in §4.1/USEofRPLinfo are required, some are just
recommended, so there would be a Normative conflict.   s/MUST/must

...
554	  The RPL data packets always carry a Hop-by-Hop Header to transport a
555	  RPL Packet Information (RPI) [RFC6550].  So unless the RUL originates
556	  its packets with an RPI, the 6LR needs to tunnel them to the Root to
557	  add the RPI.  As a rule of a thumb and except for the very special
558	  case above, the packets from and to a RUL are always encapsulated
559	  using an IP-in-IP tunnel between the Root and the 6LR that serves the
560	  RUL (see sections 7.1.4, 7.2.3, 7.2.4, 7.3.3, 7.3.4, 8.1.3, 8.1.4,
561	  8.2.3, 8.2.4, 8.3.3 and 8.3.4 of [USEofRPLinfo] for details).

[minor] Listing all these sections may be prone to errors or
inconsistency.  What about §7.1.3/§8.3.2?   Maybe simply "see
[USEofRPLinfo] for details" is better.

563	  In Non-Storing Mode, packets going down carry a Source Routing Header
564	  (SRH).  The IP-in-IP encapsulation, the RPI and the SRH are
565	  collectively called the "RPL artifacts" and can be compressed using
566	  [RFC8138].  Figure 10 presents an example compressed format for a
567	  packet forwarded by the Root to a RUL in a Storing Mode DODAG.

[minor] s/Figure 10/Appendix A

...
576	  A RUL is not expected to support the compression method defined in
577	  [RFC8138].  Unless configured otherwise, the border router MUST
578	  restore the outgoing packet before forwarding over an external route,
579	  even if it is not the destination of the incoming packet, and even
580	  when delivering to a RUL.

[minor] s/restore/uncompress

[major] "the border router MUST restore the outgoing packet before
forwarding over an external route, even if it is not the destination
of the incoming packet"

USEofRPLinfo already specifies this behavior, so please don't specify
it again.  Also, the language of "even if it is not the destination"
made me think twice about complying with rfc8200.  Maybe better to
describe the behavior in the same way that USEofRPLinfo does.

Suggestion>
   A RUL is not expected to support the compression method defined in
   [RFC8138].  The border router uncompresses the packet before forwarding
   over an external route to a RUL [USEofRPLinfo].

...
608	8.  Updated RPL Status
...
623	                    Table 1: RPL Status per RFC 6550

[minor] Please add a table (later in this section) showing the updated
RPL Status...along with a forward reference to the IANA Considerations
sub-section where the new registry is created.

[] BTW, this change should formally Update rfc6500.

625	  The 6LoWPAN ND Status was defined for use in the EARO and the
626	  currently defined values are listed in table 1 of [RFC8505].  This
627	  specification enables to carry the 6LoWPAN ND Status values in RPL
628	  DAO and DCO messages, embedded in the RPL Status field.

[minor] "the currently defined values are listed in table 1 of [RFC8505]"

Given that the registry is being modified, and that other values may
be added...it doesn't seem like a good idea to point at "currently
defined values".  Please take out that part of the sentence.

630	  To achieve this, Section 13.2 reduces the range of the EARO Status
631	  values to 0-63 to ensure that they fit within a RPL Status as shown
632	  in Figure 3.

[major] "Section 13.2 reduces the range"

§13.2 is part of the IANA Considerations, which reflects what is
specified elsewhere.  IOW, specify the reduced range elsewhere
(here?).

Suggestion>
   To achieve this, the range of the EARO Status values is reduced to 0-63.
   This reduction ensures that the values fit within a RPL Status as shown in
   Figure 3.

[major] What about the ARO?  The Status values are shared between the
EARO and the ARO.

[major] Changing the range of values is not as easy as updating the
registry...the behavior of the EARO and ARO have to be updated.  This
means that this document should Update both rfc6775 and rfc8505 where
it relates to the redefined Status field.

The E/A flags (below) don't seem to apply to the ARO/EARO, so a
specification of the behavior is needed; something like "ignore the
first two bits".

634	                              0 1 2 3 4 5 6 7
635	                             +-+-+-+-+-+-+-+-+
636	                             |E|A|  Value    |
637	                             +-+-+-+-+-+-+-+-+

...
643	  E:  1-bit flag.  Set to indicate a rejection.  When not set, a value
644	     of 0 indicates Success/Unqualified acceptance and other values
645	     indicate "not an outright rejection" as per RFC 6550.

[minor] "When not set, a value of 0...and other values..."  This is
just one bit, so there are only two values, not "other values". ;-)
You obviously mean "a value of 0...and other values of the RPL
Status".

s/a value of 0/an RPL Status value of 0

[major] ""not an outright rejection" as per RFC 6550"  rfc6550
differentiated between a "rejection" and "not an outright rejection".
Is the intent for the rejection codes to reflect that difference (at
some point), or is the ability to signal the difference lost?

...
649	  Status Value:  6-bit unsigned integer.  If the 'A' flag is set this
650	     field transports a Status Value defined for IPv6 ND EARO.  When
651	     the 'A' flag is not set, the Status Value is defined for RPL.

[major] This change in the RPL Status format should be a formal Update
of rfc6550.

653	  When building a DCO or a DAO-ACK message upon an IPv6 ND NA or a EDAC
654	  message, the RPL Root MUST copy the 6LoWPAN ND Status unchanged in
655	  the RPL Status and set the 'A' bit.  The RPL Root MUST set the 'E'
656	  flag for Values in range 1-10 which are all considered rejections.

[nit] s/'A' bit/'A' flag

[major] What should the receiver do if the corresponding 6LoWPAN ND
Status is unknown?  Or does it matter?  I'm wondering if "MUST" is the
right requirement, or if should be "SHOULD"...

[major] What should a receiver do if the E flag is not set for "Values
in range 1-10"?

[major] For future rejection-related values, the E flag has to also be
set, right?  How can we word the specification so that we don't depend
on future specification saying that the E flag has to be set?  I worry
that not all the status codes use the work "rejection", even if their
description (rfc8505) can be interpreted as such.  Maybe something
like this:

   The RPL Root MUST set the 'E' flag for all rejection Values.  The Status
   Codes in range 1-10 [rfc8505] are all considered rejections.

658	  Reciprocally, upon a DCO or a DAO-ACK message from the RPL Root with
659	  a RPL Status that has the 'A' bit set, the 6LR MUST copy the RPL
660	  Status Value unchanged in the Status field of the EARO when
661	  generating an NA to the RUL.

[major] "MUST copy the RPL Status Value unchanged"   Even if the value
is unknown?

663	9.  Updated RPL Target Option
...
679	  With this specification the ROVR is the remainder of the RPL Target
680	  Option.  The size of the ROVR is indicated in a new ROVR Size field
681	  that is encoded to map one-to-one with the Code Suffix in the EDAR
682	  message (see table 4 of [RFC8505]).

[nit] "ROVR Size field"   The field is called ROVRsz.  To be
consistent, perhaps describe the field (below) as "ROVRsz (ROVR
Size):"

[?] Why is the size of the ROVR needed?  It can be figured out from
the setting of the F flag and the Option and Prefix Lengths.  Just
curious.

684	  The modified format is illustrated in Figure 4.  It is backward
685	  compatible with the Target Option in [RFC6550] and SHOULD be used as
686	  a replacement in new implementations even for Storing Mode operations
687	  in preparation for upcoming security mechanisms based in the ROVR.

[nit] s/modified format/updated format

[nit] s/based in/based on

[major] "It is backward compatible..."

True, but what about "forward" compatible?  If the F flag is not set,
how does a receiver know that this is the updated Option?  Is there a
chance of spurious information (in either the flag or the ROVRsz) to
be present and cause the receiver to misinterpret the information?  I
know that rfc6550 specifies that the "field MUST be initialized to
zero by the sender and MUST be ignored by the receiver"...but I just
want to test the edges.

This forward compatibility may be a reason to formally Update rfc6550.

[major] "SHOULD be used as a replacement in new implementations"

Referring to §4 (Updating RFC 6550) and my comments there about
Updating... If this change is an Update -- meaning that all RPL nodes
must support it --, when would it be ok to not use it?  IOW, why is it
a recommendation and not a requirement.

OTOH, the modification is backwards compatible...so only the nodes
that need to understand the change need to implement it.

[major] "...in preparation for upcoming security mechanisms"

What it that?  If support is required for a different specification,
what is it?   It seems to me that recommending the use in preparation
for something in the future is not appropriate in a specification
without an explicit reference.

689	     0                   1                   2                   3
690	     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
691	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
692	     |   Type = 0x05 | Option Length |ROVRsz |F|Flags| Prefix Length |
693	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
694	     |                                                               |
695	     |                Target Prefix (Variable Length)                |
696	     .                                                               .
697	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
698	     |                                                               |
699	    ...            Registration Ownership Verifier (ROVR)           ...
700	     |                                                               |
701	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

703	                     Figure 4: Updated Target Option

[nit] Align the bit numbers:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

705	  New fields:

707	  ROVRsz:  Indicates the Size of the ROVR.  It MAY be 1, 2, 3, or 4,
708	     denoting a ROVR size of 64, 128, 192, or 256 bits, respectively.

[major] s/MAY be 1, 2, 3, or 4/MUST be 1, 2, 3, or 4

It is not optional to use those values, they are the only ones.

[?] Why are 4 bits needed if there are only 4 values?  Why not just use 3?

[major] What should the receiver do if a different value is used?

710	  F:  1-bit flag.  Set to indicate that Target Prefix field contains an
711	     Address of prefix advertiser in full.

[minor] To be in sync with the Registry in §15:
s/F:/F (Advertiser Address in Full):

...
716	10.  Protocol Operations for Unicast Addresses

718	  The description below assumes that the Root sets the "P" flag in the
719	  DODAG Configuration Option and performs the EDAR proxy operation.

[major] Where is the "P" flag defined?  I didn't find it in this draft.

...
726	10.1.  General Flow

[minor] It would be very nice if at the start of this sub-section a
note mentioned the fact that §10.2 contains the detailed operation.
That would help the linear reader (like me!) time in trying to figure
out the details. ;-)

[minor] Also, it would be great if this overview had forward
references to where the detail is provided.

...
775	  On the first Address Registration, illustrated in Figure 5 for RPL
776	  Non-Storing Mode, the Extended Duplicate Address exchange takes place
777	  as prescribed by [RFC8505].  If the exchange fails, the 6LR returns
778	  an NA message with a negative status to the 6LN, the NCE is not
779	  created and the address is not injected in RPL.  If it is successful,
780	  the 6LR creates an NCE and injects the Registered Address in the RPL
781	  routing using a DAO/DAO-ACK exchange with the RPL DODAG Root.

[major] "the Extended Duplicate Address exchange takes place as
prescribed by [RFC8505]"   Yes, except that NA is delayed until after
the RPL registration is completed.  (See related comments in §10.2.2
below.)

[nit] s/created and/created, and

783	  An issue may be detected later, e.g., the address moves within the
784	  LLN or to a different Root on a backbone [6BBR].  In that case the
785	  value of the status that indicates the issue can be passed from
786	  6LoWPAN ND to RPL and back as illustrated in Figure 6.

[minor] "backbone router" is not used anywhere else.  Do we need to
introduce this term and reference here?  It seems like an unnecessary
reference to me.

[nit] s/In that case/In that case,

[nit] s/back as/back, as

...
800	  An Address re-Registration is performed by the 6LN to maintain the
801	  NCE in the 6LR alive before lifetime expires.  Upon the refresh of an
802	  Address re-Registration, as illustrated in Figure 7, the 6LR injects
803	  the Registered Address in RPL.

[nit] s/before lifetime/before the lifetime

[major] Under what circumstances does the process in Figure 7 apply?
I'm assuming that only if the registration hasn't expired, is that
true?  If the registration already expired, should the whole process
(Figure 5) be repeated?  I see mention of (re)registration in §10.2.1,
but none in §10.2.2.

805	         6LN/RUL            6LR            Root               6LBR
806	            |                |              |                   |
807	            |   NS(EARO)     |              |                   |
808	            |--------------->|                                  |
809	            |                |      DAO     |                   |
810	            |                |------------->|                   |
811	            |                |              |       EDAR        |
812	            |                |              |------------------>|
813	            |                |              |       EDAC        |
814	            |                |              |<------------------|
815	            |                |    DAO-ACK   |                   |
816	            |                |<-------------|                   |
817	            |   NA(EARO)     |              |                   |
818	            |<---------------|              |                   |

[nit] A "|" is missing under the Root.

...
828	  The 6LR may receive a requested DAO-ACK after it received an
829	  asynchronous DCO, but the negative Status in the DCO supersedes a
830	  positive Status in the DAO-ACK regardless of the order in which they
831	  are received.  Upon the DAO-ACK - or the DCO if one arrives first -
832	  the 6LR responds to the RUL with an NA(EARO).

[major] "the negative Status in the DCO supersedes a positive Status
in the DAO-ACK regardless of the order in which they are received"

I don't remember anything like this in
draft-ietf-roll-efficient-npdao.  Should something be mentioned?  The
ability of a parent to send an unsolicited DCO seems to fall in the
same category: the DAO-ACK doesn't matter if the DCO was received
first...

I'm assuming the DCO negative status in this case has some type of
expiration time, right?  I'm thinking of the case where a problem did
occur, but on a retry there is success...??

This property of the DCO allows a rogue node to invalidate a
registration.  Something similar to this text from
draft-ietf-roll-efficient-npdao should be included in the Security
Considerations section:

   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 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.

834	  The RUL MAY terminate the registration at any time by using a
835	  Registration Lifetime of 0.  This specification requires that the RPL
836	  Target Option transports the ROVR.  This way, the same flow as the
837	  heartbeat flow is sufficient to inform the 6LBR using the Root as
838	  proxy as illustrated in Figure 7.

[major] s/MAY/may   In this case, the sentence is just pointing at a
fact, not making a normative statement.

[nit] s/proxy as/proxy, as

840	  Any combination of the logical functions of 6LR, Root and 6LBR might
841	  be collapsed in a single node.

[nit] s/Root and/Root, and

843	10.2.  Detailed Operation

845	10.2.1.  Perspective of the RUL Acting as 6LN

847	  This specification does not alter the operation of a 6LoWPAN ND-
848	  compliant 6LN, and a RUL is expected to operate as follows:

[minor] s/6LN, and a RUL /6LN/RUL, which

850	  1.  The 6LN obtains an IPv6 global address, either using Stateless
851	      Address Autoconfiguration (SLAAC) [RFC4862] based on a Prefix
852	      Information Option (PIO) [RFC4861] found in an RA message, or
853	      some other means such as DHCPv6 [RFC3315].

[nit] s/means such/means, such

[major] s/RFC3315/RFC8415

855	  2.  Once it has formed an address, the 6LN (re)registers its address
856	      periodically, within the Lifetime of the previous Address
857	      Registration, as prescribed by [RFC6775], to refresh the NCE
858	      before the lifetime indicated in the EARO expires.  It MUST set
859	      the "T" flag and the TID is incremented each time and wraps in a
860	      lollipop fashion (see section 5.2.1 of [RFC8505] which is fully
861	      compatible with section 7.2 of [RFC6550]).

[minor] s/It MUST set the "T" flag and the TID is incremented/It MUST
set the "T" flag.  The TID is incremented

[nit] s/[RFC8505] which/[RFC8505], which

863	  3.  As stated in section 5.2 of [RFC8505], the 6LN can register to
864	      more than one 6LR at the same time.  In that case, it uses the
865	      same EARO for all of the parallel Address Registrations.  The 6LN
866	      SHOULD send the registration(s) that have a non-zero Registration
867	      Lifetime and ensure that one succeeds before it terminates other
868	      registrations, to maintain the state in the network and at the
869	      6LBR and minimize the churn.

[major] "The 6LN SHOULD send the registration(s) that have a non-zero
Registration Lifetime..."

It sounds as if you're trying to specify what the value of the
Registration Lifetime should be.  If so: s/that have a non-zero/with a
non-zero

What are the cases when it is ok to not use a non-zero value?  IOW,
why is it recommended and not required?  rfc8505 talks about setting
the Registration Lifetime to 0, which brings me to: it seems to me
that the Normative language may be out of place since the
specification is already made in rfc8505.  ??

871	  4.  Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets
872	      the "R" flag in the EARO of at least one registration, whereas
873	      acting as a RAN it never does.  If the "R" flag is not echoed in
874	      the NA, the RUL SHOULD attempt to use another 6LR.  The RUL
875	      SHOULD send the registration(s) with the "R" flag set and ensure
876	      that one succeeds before it sends the registrations with the flag
877	      reset.  In case of a conflict with the preceeding rule on
878	      lifetime, the rule on lifetime has precedence.

[nit] "6LN acting as a RUL"  The title of this section is "Perspective
of the RUL Acting as 6LN", which one is it? ;-)

[minor] "whereas acting as a RAN it never does"   rfc8505 says this:
"A 6LR that manages its reachability SHOULD NOT set the R flag".
"SHOULD NOT" doesn't imply never.

[minor] "If the "R" flag is not echoed in the NA..."  I didn't find in
rfc8505 where echoing the R flag is discussed.  But §10.2.2 requires
the R flag set...is that where the specification is?

[major] "SHOULD send the registration(s) with the "R" flag set and
ensure that one succeeds before it sends the registrations with the
flag reset."

This text is in conflict with §5.1/rfc8505: "MUST set the R flag to
indicate that it is not a router and that it will not handle its own
reachability".  There isn't a provision for a RUL to not set the R
flag.

[nit] s/preceeding/preceding

880	  5.  The 6LN may use any of the 6LRs to which it registered as default
881	      gateway.  Using a 6LR to which the 6LN is not registered may
882	      result in packets dropped at the 6LR by a Source Address
883	      Validation function (SAVI) so it is NOT RECOMMENDED.

[nit] s/as default/as the default

[minor] Please add an Informative reference to SAVI.

[major] s/NOT RECOMMENDED/not recommended
This text is not specifying normative behavior related to interoperability.

885	  Even without support for RPL, a RUL may be aware of opaque values to
886	  be provided to the routing protocol.  If the RUL has a knowledge of
887	  the RPL Instance the packet should be injected into, then it SHOULD
888	  set the Opaque field in the EARO to the RPLInstanceID, else it MUST
889	  leave the Opaque field to zero.

[nit] s/has a knowledge/has knowledge

[major] If a RUL is *unaware* by definition, I don't see how this
paragraph can fit in this specification...especially because it seems
to be speculating about potential knowledge ("may be aware of opaque
values")...  What do we call a RUL that has partial knowledge?

891	  Regardless of the setting of the Opaque field, the 6LN MUST set the
892	  "I" field to zero to signal "topological information to be passed to
893	  a routing process" as specified in section 5.1 of [RFC8505].

[nit] s/process" as/process", as

895	  A RUL is not expected to produce RPL artifacts in the data packets,
896	  but it MAY do so.  For instance, if the RUL has a minimal awareness
897	  of the RPL Instance then it can build an RPI.  A RUL that places an
898	  RPI in a data packet MUST indicate the RPLInstanceID of the RPL
899	  Instance where the packet should be forwarded.  All the flags and the
900	  Rank field are set to zero as specified by section 11.2 of [RFC6550].

[major] s/MAY/may   In this case, the text is just expressing a fact,
not a Normative action.

[nit] s/has a minimal/has minimal

[major] The Normative text in this paragraph is equivalent to the one
above (two paragraphs up)...please avoid duplication/redundancy.

[major] "A RUL that places an RPI in a data packet MUST indicate the
RPLInstanceID of the RPL Instance where the packet should be
forwarded."

So...even if we leave the *unaware* nature of a RUL out...this text
means that any leaf can inject traffic onto an RPL Instance, just by
knowing the ID (or even guessing it).  Please add some text in the
Security Considerations about how the rfc6553 considerations apply
here too.

902	10.2.2.  Perspective of the Border Router Acting as 6LR

[nit] How else would a Border Router act as?

[] This terminology of "acting as" is confusing... <sigh>

904	  Also as prescribed by [RFC8505], the 6LR generates an EDAR message
905	  upon reception of a valid NS(EARO) message for the registration of a
906	  new IPv6 Address by a 6LN.  If the initial EDAR/EDAC exchange
907	  succeeds, then the 6LR installs an NCE for the Registration Lifetime.
908	  For the registration refreshes, if the RPL Root has indicated that it
909	  proxies the keep-alive EDAR/EDAC exchange with the 6LBR (see
910	  Section 4), the 6LR MUST refrain from sending the keep-alive EDAR.

[nit] s/Also as prescribed/As prescribed

912	  If the "R" flag is set in the NS(EARO), the 6LR MUST inject the Host
913	  route in RPL, unless this is barred for other reasons, such as the
914	  saturation of the RPL parents.  The 6LR MUST use a RPL Non-Storing
915	  Mode signaling and the updated Target Option (see Section 9).  The
916	  6LR MUST request a DAO-ACK by setting the 'K' flag in the DAO
917	  message.  Success injecting the route to the RUL is indicated by the
918	  'E' flag set to 0 in the RPL status of the DAO-ACK message.

[major] What is "the Host route"?  I guess you mean a "host route to
the Registered Address contained in the EDAC".  Or, as you mention
later, "router to the RUL".

[major] "MUST...unless"   The use of MUST implies no exceptions.   s/MUST/SHOULD

920	  The Opaque field in the EARO hints the 6LR on the RPL Instance that
921	  SHOULD be used for the DAO advertisements, and for the forwarding of
922	  packets sourced at the registered address when there is no RPI in the
923	  packet, in which case the 6LR MUST encapsulate the packet to the Root
924	  adding an RPI in the outer header.  If the Opaque field is zero, the
925	  6LR is free to use the default RPL Instance (zero) for the registered
926	  address or to select an Instance of its choice.

[major] "hints"   It is really a hint, or the RPL Instance?  If only a
hint, where would the Instance that "SHOULD be used" come from?  The
text in §10.2.1 implies that the 6LN knows what the Instance is.

[major] "the RPL Instance that SHOULD be used for the DAO advertisements"

When would the 6LR not use the Instance signaled by the 6LN?  IOW, why
is this a recommendation and not a requirement?

[nit] s/and for the/and the

[major] "SHOULD be used for...forwarding...in which case the 6LR MUST
encapsulate the packet to the Root adding an RPI in the outer header"

There's a Normative conflict between recommending the use of the
RPLInstanceID and requiring the use of the RPI (which contains the
RPLInstanceID).

[minor] How is the 6LR to "select an Instance of its choice"?
§11.2/rfc6550 talks specifically about the need for guidance for
external packets:

   The definition and provisioning of RPL Instances are out of scope for
   this specification.  Guidelines may be application and implementation
   specific, and they are expected to be elaborated in future companion
   specifications.  Those operations are expected to be such that data
   packets coming from the outside of the RPL network can unambiguously
   be associated to at least one RPL Instance and be safely routed over
   any instance that would match the packet.

928	  If the "I" field is not zero, then the 6LR MUST consider that the
929	  Opaque field is zero.  If the Opaque field is not zero, then it is
930	  expected to carry a RPLInstanceID for the RPL Instance suggested by
931	  the 6LN.  If the 6LR does not participate to the associated Instance,
932	  then the 6LR MUST consider that the Opaque field is zero; else, that
933	  is if the 6LR participates to the suggested RPL Instance, then the
934	  6LR SHOULD use that Instance for the Registered Address.

[nit] There is some redundancy/repetition between this paragraph and
the last one.

[major] "If the "I" field is not zero, then the 6LR MUST consider that
the Opaque field is zero."

rfc8505 already specifies pretty much the same thing.

OLD>
   If the "I" field is not zero, then the 6LR MUST consider that the
   Opaque field is zero.  If the Opaque field is not zero, then it is
   expected to carry a RPLInstanceID for the RPL Instance suggested by
   the 6LN.

NEW>
   As described in rfc8505, if the "I" field is zero, then the Opaque field
   is expected to carry the RPLInstanceID suggested by the 6LN.  Otherwise,
   the Opaque field is ignored.

[nit] s/participate to the/participate in the

...
939	  1.  The Registered Address is signaled as Target Prefix in the
940	      updated Target Option in the DAO message; the Prefix Length is
941	      set to 128.  The ROVR field is copied unchanged from the EARO
942	      (see Section 9).

[nit] s/as Target Prefix/as the Target Prefix

[minor] "Prefix Length is set to 128" ...and the F flag is set.

...
948	  3.  The 6LR sets the External 'E' flag in the TIO to indicate that it
949	      redistributes an external target into the RPL network

[nit] s/it redistributes/it is redistributing

951	  4.  the Path Lifetime in the TIO is computed from the Lifetime in the
952	      EARO Option.  This adapts it to the Lifetime Units used in the
953	      RPL operation; note that if the lifetime is 0, then the DAO
954	      message is a No-Path DAO that cleans up the the routes down to
955	      the RUL; this also causes the Root as a proxy to send an EDAR
956	      message to the 6LBR with a Lifetime of 0.

[minor] s/Lifetime/Registration Lifetime

[minor] "Path Lifetime in the TIO is computed"  How?  Given that the
Registration Lifetime is in seconds, but the Lifetime Unit can be in
days, there may be cases where the result is close to 0.  Would that
result in an NPDAO?

[nit] s/the the/the

...
961	  Upon receiving the DAO-ACK or an asynchronous DCO message, the 6LR
962	  MUST send the NA(EARO) to the RUL.

[major] "Upon receiving the DAO-ACK ...the 6LR MUST send the NA(EARO)".

My interpretation is that the 6LR will wait for the DAO-ACK before
sending the NA(EARO), is that correct?

§9.3/rfc6550:

   4.  A node receiving a unicast DAO message with the 'K' flag set
       SHOULD respond with a DAO-ACK.  A node receiving a DAO message
       without the 'K' flag set MAY respond with a DAO-ACK, especially
       to report an error condition.

   5.  A node that sets the 'K' flag in a unicast DAO message but does
       not receive a DAO-ACK in response MAY reschedule the DAO message
       transmission for another attempt, up until an implementation-
       specific number of retries.

This text says that the 6LR may never receive a DAO-ACK.  If that
happens (even after trying again), what should the 6LR do?   During
this time the RUL is waiting for the NS(EARO)...

964	  The 6LR MUST set "R" flag in the NA(EARO) back if and only if the 'E'
965	  flag is reset, indicating that the 6LR injected the Registered
966	  Address in the RPL routing successfully and that the EDAR proxy
967	  operation succeeded.

[nit] s/set "R"/set the "R"

969	  If the 'A' flag in the RPL Status is set, the embedded Status Value
970	  is passed back to the RUL in the EARO Status.  If the 'E' flags is
971	  also set, the registration failed for 6LoWPAN ND related reasons, and
972	  the NCE is removed.

[nit] s/'E' flags/'E' flag

974	  If the 'A' flag is not set in the RPL Status of the DAO-ACK, then the
975	  6LoWPAN ND operation succeeded and an EARO Status of 0 (Success) MUST
976	  be returned to the RUL, even if the 'E' flag is set in the RPL
977	  Status.  The EARO Status of 0 MUST also be used if the 6LR could not
978	  even try to inject the route.

[major] "If the 'A' flag is not set in the RPL Status of the DAO-ACK,
then the 6LoWPAN ND operation succeeded..."

§8 says this: "the RPL Root MUST copy the 6LoWPAN ND Status unchanged
in the RPL Status and set the 'A' bit"   This means that if the A flag
is not set then the Root didn't comply with the MUST in §8...or that
it did not copy result from the EDAC...which then means that the
DAO-ACK is not valid.  What am I missing?

[nit] s/succeeded and/succeeded, and

[major] "even if the 'E' flag is set"   Sorry, what?  The E flag
indicates a rejection...  I thought I understood the logic (in §8) of
setting the A/E flags...but it seems that I didn't.  It would be ideal
to then be explicit about the different combinations and how we can
get to them.

980	  This means that, in case of an error injecting the route that is not
981	  related to ND, the registration succeeds but the RPL route is not
982	  installed, which is signaled by the "R" flag reset.  It is up to the
983	  6LN to keep the binding with the 6LR or destroy it.

[nit] s/succeeds but/succeeds, but

[major] Figure 5 seems to indicate that the DAO-ACK is generated when
the EDAC is received, which is inline with the specification in §8
("the RPL Root MUST copy the 6LoWPAN ND Status unchanged in the RPL
Status and set the 'A' bit")...but from the last few paragraphs it
seems that there are other reasons for generating the DAO-ACK.  While
not clear from the Figure, §10.2.3 does hint by saying "if a DAO is
pending"...  Again, I think that this part of the operation has to be
much more explicit.

rfc6550 has no information about "pending" DAOs, or how fast the
DAO-ACK is to be sent.  In fact, there is no firm requirement for the
DAO-ACK to exist, just hope that it does:

- §6.4/rfc6550: "The DAO message may optionally, upon explicit request or
  error, be acknowledged by its destination with a Destination Advertisement
  Acknowledgement (DAO-ACK) message back to the sender of the DAO."

This sentence suggests that the DAO-ACK is optional, even if
requested, and §9.3/rfc6550 supports that:

"  3.  A node MAY set the 'K' flag in a unicast DAO message to solicit a
       unicast DAO-ACK in response in order to confirm the attempt.

   4.  A node receiving a unicast DAO message with the 'K' flag set
       SHOULD respond with a DAO-ACK.  A node receiving a DAO message
       without the 'K' flag set MAY respond with a DAO-ACK, especially
       to report an error condition.
"

Note that "SHOULD respond with a DAO-ACK" leaves the door open to not
doing it.  Unfortunately rfc6550 didn't explicitly mention what may be
the reasons to not send a DAO-ACK (or not using MUST instead).

In summary, there doesn't seem to be a guarantee that a DAO-ACK will
be received...which means that the 6LN may be left waiting for a
response to the registration (the same issues appears to be present
for a re-registration).

985	  In a network where Address Protected Neighbor Discovery (AP-ND) is
986	  enabled, in case of a DAO-ACK or a DCO indicating transporting an
987	  EARO Status Value of 5 (Validation Requested), the 6LR MUST challenge
988	  the 6LN for ownership of the address, as described in section 6.1 of
989	  [AP-ND], before the Registration is complete.  This ensures that the
990	  address is validated before it is injected in the RPL routing.

[major maybe] "network where...(AP-ND) is enabled"  Just to make sure
I'm understanding: the network itself is not enabled for AP-ND, but
the important nodes (6LN, 6LR, Root and 6LBR) are.  IOW, RPL only
carries the EARO status values that result from the AP-ND operation.
If this true?

Also, the only reason the EARO Status Value would be 5 is if the 6LN
already supports AP-ND, right?  I'm asking this because of the "MUST
challenge" above, and §7.1 saying that the "RUL SHOULD support
[AP-ND]" (recommended, not required).

If my understanding is correct, then the text as is looks fine. :-)

992	  If the challenge succeeds then the operations continue as normal.  In
993	  particular a DAO message is generated upon the NS(EARO) that proves
994	  the ownership of the address.  If the challenge failed, the 6LR
995	  rejects the registration as prescribed by AP-ND and may take actions
996	  to protect itself against DoS attacks by a rogue 6LN, see Section 12.

[nit] s/succeeds then the operations continue/succeeds, then the
operation continues

[nit] s/particular/particular,

[minor] "a DAO message is generated upon the NS(EARO) that proves the
ownership of the address"

It would be very nice is a new figure was included (either here or in
§10.1) to show this updated flow.

998	  The 6LR may at any time send a unicast asynchronous NA(EARO) with the
999	  "R" flag reset to signal that it stops providing routing services,
1000	  and/or with the EARO Status 2 "Neighbor Cache full" to signal that it
1001	  removes the NCE.  It may also send a final RA, unicast or multicast,
1002	  with a Router Lifetime field of zero, to signal that it stops serving
1003	  as router, as specified in section 6.2.5 of [RFC4861].

[minor] What are the RPL actions that should take place?  For example,
if the 6LR "stops providing routing services" to a specific 6LN, but
still acts as a router for others...should it also send an NPDAO/DCO
to remove the routing state?  Is there a reference somewhere about how
a RPL router gracefully "stops serving as router"?

1005	  If a 6LR receives a valid NS(EARO) message with the "R" flag reset
1006	  and a Registration Lifetime that is not 0, and the 6LR was injecting
1007	  the Registered Address due to previous NS(EARO) messages with the "R"
1008	  flag set, then the 6LR MUST stop injecting the address.  It is up to
1009	  the Registering 6LN to maintain the corresponding route from then on,
1010	  either keeping it active via a different 6LR or by acting as a RAN
1011	  and managing its own reachability.

[major] "MUST stop injecting the address"  Can you be more specific?
What does this mean in RPL terms?  Send an NPDAO/DCO?

1013	10.2.3.  Perspective of the RPL Root

1015	  A RPL Root SHOULD set the "P" flag in the RPL DODAG Configuration
1016	  Option of the DIO messages that it generates (see Section 4) to
1017	  signal that it proxies the EDAR/EDAC exchange and supports the
1018	  Updated RPL Target option.  The remainder of this section assumes
1019	  that it does.

[major] If the Root supports the functionality, when would it be ok
for it to not set the P flag?  IOW, why is it recommended and not
required?  [Note that I may be missing context because there is no
specification for that flag.]

1021	  Upon reception of a DAO message, for each updated RPL Target Option
1022	  (see Section 9) that creates or updates an existing RPL state, the
1023	  Root MUST notify the 6LBR.  This can be done using an internal API if
1024	  they are integrated, or using a proxied EDAR/EDAC exchange if they
1025	  are separate entities.

[major nit] "MUST notify the 6LBR.  This can be done..."   I'm not too
happy with the wording as it seems to provide options to a
requirement...

Suggestion>
   The Root MUST notify the 6LBR by using a proxied EDAR/EDAC exchange if
   they are separate entities.  If the RPL Root and 6LBR are integrated,
   then an internal API can be used.

...
1043	  Upon receiving an EDAC message from the 6LBR, if a DAO is pending,
1044	  then the Root MUST send a DAO-ACK back to the 6LR.  Else, if the
1045	  Status in the EDAC message is not "Success", then it MUST send an
1046	  asynchronous DCO to the 6LR.

[?] "if a DAO is pending"  Even though rfc6550 doesn't talk about
"pending", I take this to mean that the DAO hasn't been ack'd.  Just
wondering (because I couldn't find it in rfc6550), is there a timer
that defines the time between receiving the DAO and sending a DAO-ACK.
I'm also wondering about it since sending a DAO-ACK is only
recommended.

[major] What if the EDAC message is not received?  Should the Root
signal a failure?  What if the EDAC message comes in after a failure
is signaled?  This should presumably not happen, especially since the
6LN already registered...but I'm worried about the timing.

[major] Some text should be added related to the possibility that not
all nodes may know what the DCO is.

Suggestion (borrowing from §4.6.2/EFFICIENT-NPDAO)>
   This document assumes that all the 6LRs in the network support this
   specification.  If there are 6LRs in the DCO message path which do not
   support this document, then the issue indication may not reach the 6LR.
   Alternatively, the Root could...

I stopped there because the text above says that the Root "MUST send
an asynchronous DCO".

...
1059	11.  Protocol Operations for Multicast Addresses
...
1068	  "Multicast Listener Discovery (MLD) for IPv6" [RFC2710] and its
1069	  updated version "Multicast Listener Discovery Version 2 (MLDv2) for
1070	  IPv6" [RFC3810] provide an interface for a listener to register to
1071	  multicast flows.  MLDv2 is backwards compatible with MLD, and adds in
1072	  particular the capability to filter the sources via black lists and
1073	  white lists.  In the MLD model, the Router is a "querier" and the
1074	  Host is a multicast listener that registers to the querier to obtain
1075	  copies of the particular flows it is interested in.

[nit] s/backwards/backward

[nit] s/"querier" and/"querier", and

[major] In general, the text talks about an "MLD listener/querier" --
are you using "MLD" to indicate support for both rfc2710/rfc3810, or
are you assuming MLDv1 support only?  The phrase "MLDv2 is backwards
compatible with MLD" is what is confusing me.

I also ask because the pim WG has an ongoing discussion about
deprecating MLDv1.  I am assuming MLDv2, which is what rfc8504
requires.  If so, let's focus on rfc3810.

[-] s/capability to filter the sources via black lists and white
lists/support for source filtering

That is the language used in rfc3810.

1077	  On the first Address Registration, as illustrated in Figure 8, the
1078	  6LN, as an MLD listener, sends an unsolicited Report to the 6LR in
1079	  order to start receiving the flow immediately.

[minor] "On the first Address Registration..."  Do you mean when the
6LN registers its own address (Figure 5)?   I would assume you're
talking about when the 6LN decides to listen to multicast; maybe
reword...

1081	     6LN/RUL                6LR             Root                6LBR
1082	        |                    |               |                    |
1083	        | unsolicited Report |               |                    |
1084	        |------------------->|               |                    |
1085	        |     <L2 ack>       |               |                    |

[] See the comment below about the L2 ack.  This same phrase shows up
in Figure 9 later on...

1086	        |                    | DAO           |                    |
1087	        |                    |-------------->|                    |
1088	        |                    |    DAO-ACK    |                    |
1089	        |                    |<--------------|                    |
1090	        |                    |               | <if not listening> |

[minor] "if not listening"  Even if the 6LBR is listening, the Report
should be unsolicited, right?  I'm not sure what this phrase means...

...
1097	  Since multicast Layer-2 messages are avoided, it is important that
1098	  the asynchronous messages for unsolicited Report and Done are sent
1099	  reliably, for instance using a Layer-2 acknowledgment, or attempted
1100	  multiple times.

[major] The lack of reliable transmission is already addressed in
rfc3810.  What concerns me about the text is the suggestion that a
different (L2 ack) mechanism can be used for MLD without any
specifics.

1102	  The 6LR acts as a generic MLD querier and generates a DAO for the
1103	  multicast target.  The lifetime of the DAO is set to be in the order
1104	  of the Query Interval, yet larger to account for variable propagation
1105	  delays.

[minor] s/multicast target/Multicast Address in the Report message

[major] "generates a DAO for the multicast target"   This document is
a standards track specification...we need to be more explicit.  I'm
assuming that the Multicast Address is included as the Target Prefix
in the Target Option...

[major] One Multicast Address per DAO?  I think I saw a related
discussion on the list recently.

[major] "lifetime of the DAO"  The Path Lifetime?

[major] "lifetime...is set to be in the order of the Query Interval,
yet larger..."  How much is that?  Double?  Just a few seconds more?
ms?

...
1111	  Upon a DAO with a multicast target, the RPL Root checks if it is
1112	  already registered as a listener for that address, and if not, it
1113	  performs its own unsolicited Report for the multicast target.

[major] As above, please be specific.  How is the DAO information used
to build a Query?

1115	  An Address re-Registration is pulled periodically by 6LR acting as
1116	  querier.  Note that the message may be sent unicast to all the known
1117	  individual listeners.

[major] In MLDv2 that is called a Query...

[nit] s/by 6LR/by the 6LR

[major] "message may be sent unicast to all the known individual
listeners"  The first paragraph in this section says that "the
multicast packet is passed as a Layer-2 unicast to each of the
interested children", so there is no other option, right?

...
1144	  Note that any of the functions 6LR, Root and 6LBR might be collapsed
1145	  in a single node, in which case the flow above happens internally,
1146	  and possibly through internal API calls as opposed to messaging.

[nit] s/Root and/Root, and

1148	12.  Security Considerations

1150	  First of all, it is worth noting that with [RFC6550], every node in
1151	  the LLN is RPL-aware and can inject any RPL-based attack in the
1152	  network.  This specification isolates edge nodes that can only
1153	  interact with the RPL routers using 6LoWPAN ND, meaning that they
1154	  cannot perform RPL insider attacks.

[nit] s/First of all, it/I

[major] Because 6LoWPAN ND is used, please add text about the Security
Considerations from rfc6775, rfc8505 apply.

[major] Also, let's work in a general pointer to rfc7416 somewhere
(instead of the very specific one below).

[major ?] Are there attacks that can be injected into the RPL network
through ND?  I'm wondering if a RUL can request and inject a
significant number of addresses so that it could hinder the operation
of the LLN.  I don't know if that's even an issue...just thinking out
loud.

1156	  6LoWPAN ND can optionally provide SAVI features with [AP-ND], which
1157	  reduces even more the attack perimeter that is available to the edge
1158	  nodes.

[minor] I think there's some discussion of this in rfc8505...maybe
point to that.  Otherwise, this paragraph feels orphan...

1160	  The LLN nodes depend on the 6LBR and the RPL participants for their
1161	  operation.  A trust model must be put in place to ensure that the
1162	  right devices are acting in these roles, so as to avoid threats such
1163	  as black-holing, (see [RFC7416] section 7) or bombing attack whereby
1164	  an impersonated 6LBR would destroy state in the network by using the
1165	  "Removed" Status code.

1167	  This trust model could be at a minimum based on a Layer-2 Secure
1168	  joining and the Link-Layer security.  This is a generic 6LoWPAN
1169	  requirement, see Req5.1 in Appendix of [RFC8505].

1171	  Additionally, the trust model could include a role validation to
1172	  ensure that the node that claims to be a 6LBR or a RPL Root is
1173	  entitled to do so.

[major] There was some trust model-related text in
draft-ietf-roll-turnon-rfc8138 that we ended up replacing.  Please do
the same here.

1175	  At the time of this writing RPL does not have a zerotrust model
1176	  whereby it is possible to validate the origin of an address that is
1177	  injected in a DAO.  This specification makes a first step in that
1178	  direction by allowing the Root to challenge the RUL via the 6LR that
1179	  serves it.

[nit] s/writing RPL/writing, RPL

[nit] s/zerotrust/zero-trust

[minor] The challenge really comes from the 6LBR (not the Root)...but
only if AP-ND is present.  IOW, the use of AP-ND is what adds the
protection, not the specification itself.  Is that what we're talking
about here?

If so, then I have a couple more things to point at:

- §3.2.3: "This specification does not address how the protection by [AP-ND]
  could be extended to RPL."  But that is what seems to be claimed above.

- §7.1: "The RUL SHOULD support [AP-ND] to protect the ownership of its
  addresses."  If the RUL doesn't, then whatever benefit is claimed/expected
  is lost.

1181	13.  IANA Considerations

[major] §14-17 should be sub-sections of this one.

...
1191	13.2.  Resizing the ARO Status values

1193	  Section 12 of [RFC6775] creates the Address Registration Option
1194	  Status Values Registry with a range 0-255.

1196	  This specification reduces that range to 0-63.

[minor] NEW>
   This specification reduces that range to 0-63 (Section 8).

1198	  IANA is requested to reduce the upper bound of the unassigned values
1199	  in the Address Registration Option Status Values Registry from -255
1200	  to -63.

[major] NEW>
   IANA is requested modify the Address Registration Option Status Values
   Registry so that the upper bound of the unassigned values is 63.  This
   document should be added as a reference.  The registration procedure does
   not change.

[major] Because of this change in the registry defined by rfc6775,
that RFC should be formally Updated.

1202	14.  New DODAG Configuration Option Flag

1204	  This specification updates the Registry for the "DODAG Configuration
1205	  Option Flags" that was created for [RFC6550] as follows:

[major] NEW>
   IANA is requested to assign a flag from the "DODAG Configuration Option
   Flags" registry as follows:

1207	         +------------+----------------------------+-----------+
1208	         | Bit Number | Capability Description     | Reference |
1209	         +============+============================+===========+
1210	         | 1          | Root Proxies EDAR/EDAC (P) | THIS RFC  |
1211	         +------------+----------------------------+-----------+

[major] Please mark the value (1) as suggested.

...
1215	15.  New RPL Target Option Flag

1217	  Section 20.15 of [RFC6550] creates a Registry for the 8-bit "RPL
1218	  Target Option Flags" field.  IANA is requested to reduce the size of
1219	  the field in the Registry to 4 bits.  This specification also defines
1220	  a new entry in the Registry as follows:

[] Suggestion>

   This document modifies the "RPL Target Option Flags" registry initially
   created in Section 20.15 of [RFC6550].  The registry now includes only
   4-bits (Section 9) and should point to this document as an additional
   reference.  The registration procedure doesn't change.

   The following table shows the initial assignment.

[major] This change in the registry should be flagged as an Update to rfc6550.

...
1228	                   Table 3: New RPL Target Option Flag

[minor] s/New RPL Target Option Flag/RPL Target Option Registry

1230	16.  New Subregistry for the RPL Non-Rejection Status values

1232	  This specification creates a new Subregistry for the RPL Non-
1233	  Rejection Status values for use in RPL DAO-ACK and DCO messages with
1234	  the 'A' flag reset, under the ICMPv6 parameters registry.

[nit] s/in RPL/in the RPL

[major] The DCO-ACK Status registry is under the RPL registry.  Why
isn't this one there too?  It is RPL-related.

...
1238	  *  Registration procedure is "Standards Action" [RFC8126].

[major ?] All the other RPL registries have an "IETF Review"
registration procedure.  Why is this one different?

...
1242	             +-------+------------------------+-----------+
1243	             | Value | Meaning                | Reference |
1244	             +=======+========================+===========+
1245	             | 0     | Unqualified acceptance | RFC 6550  |
1246	             +-------+------------------------+-----------+

[major] Let's also add this document as a reference for this initial allocation.

...
1250	17.  New Subregistry for the RPL Rejection Status values

1252	  This specification creates a new Subregistry for the RPL Rejection
1253	  Status values for use in RPL DAO-ACK and RCO messages with the 'A'
1254	  flag reset, under the ICMPv6 parameters registry.

[nit] s/in RPL/in the RPL

[minor] s/RCO/DCO

[major] The DCO-ACK Status registry is under the RPL registry.  Why
isn't this one there too?  It is RPL-related.

...
1258	  *  Registration procedure is "Standards Action" [RFC8126].

[major ?] All the other RPL registries have an "IETF Review"
registration procedure.  Why is this one different?

...
1276	19.  Normative References

[minor] The following references can be Informative:

...
1293	  [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
1294	             over Low-Power Wireless Personal Area Networks (6LoWPANs):
1295	             Overview, Assumptions, Problem Statement, and Goals",
1296	             RFC 4919, DOI 10.17487/RFC4919, August 2007,
1297	             <https://www.rfc-editor.org/info/rfc4919>.
...
1304	  [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
1305	             Address Autoconfiguration", RFC 4862,
1306	             DOI 10.17487/RFC4862, September 2007,
1307	             <https://www.rfc-editor.org/info/rfc4862>.
...
1316	  [RFC6553]  Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
1317	             Power and Lossy Networks (RPL) Option for Carrying RPL
1318	             Information in Data-Plane Datagrams", RFC 6553,
1319	             DOI 10.17487/RFC6553, March 2012,
1320	             <https://www.rfc-editor.org/info/rfc6553>.
...
1322	  [RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
1323	             Routing Header for Source Routes with the Routing Protocol
1324	             for Low-Power and Lossy Networks (RPL)", RFC 6554,
1325	             DOI 10.17487/RFC6554, March 2012,
1326	             <https://www.rfc-editor.org/info/rfc6554>.
...
1338	  [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
1339	             Constrained-Node Networks", RFC 7228,
1340	             DOI 10.17487/RFC7228, May 2014,
1341	             <https://www.rfc-editor.org/info/rfc7228>.
...
1353	  [RFC8138]  Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
1354	             "IPv6 over Low-Power Wireless Personal Area Network
1355	             (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
1356	             April 2017, <https://www.rfc-editor.org/info/rfc8138>.

...
1394	20.  Informative References
...
1429	  [RFC8504]  Chown, T., Loughney, J., and T. Winters, "IPv6 Node
1430	             Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
1431	             January 2019, <https://www.rfc-editor.org/info/rfc8504>.

[major] This reference should be Normative.

...
1439	Appendix A.  Example Compression
...
1455	  The difference with the example presented in Figure 19 of [RFC8138]
1456	  is the addition of a SRH-6LoRH before the RPI-6LoRH to transport the
1457	  compressed address of the 6LR as the destination address of the outer
1458	  IPv6 header.  In the original example the destination IP of the outer
1459	  header was elided and was implicitly the same address as the
1460	  destination of the inner header.  Type 1 was arbitrarily chosen, and
1461	  the size of 0 denotes a single address in the SRH.

[minor] Which one is the "original example", this one, or the one in rfc8138?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Oct 2020 14:18:00 -0400

> ...  484 5.  Updating draft-ietf-roll-efficient-npdao

    > draft-ietf-roll-efficient-npdao is needed.  As mentioned below, this

1) I agree that we are extending, not updating.
   It feels weird to update a document that is in the same cluster :-)

2) The text says:

   [EFFICIENT-NPDAO] defines the DCO for RPL Storing Mode only, with a
   link-local scope.  This specification extends its use to the Non-
   Storing MOP, whereby the DCO is sent unicast by the Root directly to
   the RAN that injected the DAO message for the considered target.

If an RPL aware node supports RUL, then it has to support DCOs
even when operating in a Non-Storing MOP.

The document does NOT say that a node with RUL support has to support
Non-Storing MOPs.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Oct 2020 14:22:15 -0400

Alvaro Retana <[email-masked]> wrote:
    > ...  510 7.1.  Support of 6LoWPAN ND

    doc> 512  In order to obtain routing services from a 6LR, a RUL MUST
    doc> implement 513  [RFC8505] and set the "R" and "T" flags in the
    doc> EARO.  The RUL SHOULD 514  support [AP-ND] to protect the ownership of
    doc> its addresses.  The RUL 515  MUST NOT request routing services from a
    doc> 6LR that does not originate 516  RA messages with a CIO that has the L,
    doc> P, and E flags all set as 517  discussed in Section 3.3.1, unless
    doc> configured to do so.

    > node that (by definition) is not aware of this document.  [See more

We would have liked to have written a document that explained how to support
RFC8504-compliant hosts, and at the time of 8504, we tried to make this an
issue, but we failed.

So, yes, a RUL has to be aware of this document, and RFC8505, but it does
need to speak RPL.

Such a node could be connected to a MANET or OLSR mesh using RFC8505-ND
equally well.

Maybe we should consider changing the title of the document?

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 6 Oct 2020 14:33:29 -0400

Just to make sure, we’re agreeing…right?

On October 6, 2020 at 2:18:41 PM, Michael Richardson ([email-masked])
wrote:

2) The text says:

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 6 Oct 2020 14:37:29 -0400

On October 6, 2020 at 2:22:25 PM, Michael Richardson wrote:

> Alvaro Retana wrote:

Right.  I now understand the intent/requirements.

> So, yes, a RUL has to be aware of this document, and RFC8505, but it does

s/does/does not

> Maybe we should consider changing the title of the document?

The title ("Routing for RPL Leaves") is not as misleading as the RUL
name...which is why I made the initial assumption of not being aware
of this document.

If clarified early, I don't think we need to change the name.  Also, I
don't know what would be a better name.

Alvaro.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Oct 2020 20:34:16 -0400

>> Non-Storing MOP as well.  Is that what is intended?

That's not what's expected.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Oct 2020 20:35:32 -0400

Alvaro Retana <[email-masked]> wrote:
    >> So, yes, a RUL has to be aware of this document, and RFC8505, but it
    >> does need to speak RPL.

    > s/does/does not

ARGH.

So, yes, a RUL has to be aware of this document, and RFC8505, but it does not
need to speak RPL.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 7 Oct 2020 08:00:28 +0000

> -----Original Message-----
> From: Roll <[email-masked]> On Behalf Of Michael Richardson
> Sent: mercredi 7 octobre 2020 02:36
> To: Alvaro Retana <[email-masked]>; Routing Over Low power and
> Lossy networks <[email-masked]>
> Subject: Re: [Roll] AD Review of draft-ietf-roll-unaware-leaves-18
> 
> 

Exactly!

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 7 Oct 2020 08:18:33 +0000

Many thanks to you both for your help here!

> That's not what's expected.
Agreed, the formal update is already gone (this was about -18).
For 22 I'll change the name of eth section from "updating" to "extending"

Is that all that is needed for this point?

Keep safe,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 7 Oct 2020 12:57:27 +0000

> From: Roll <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
> Sent: mercredi 7 octobre 2020 10:00
> To: Routing Over Low power and Lossy networks <[email-masked]>; Alvaro
> Retana <[email-masked]>
> > does not need to speak RPL.
> 
> Exactly!
> 
I already had acted on this but I understand it was not enough; So let me propose the additional diff (which is on the first mention of a RUL)

OLD

   [USEofRPLinfo] introduces the terms RPL-Aware-Leaf (RAL) and RPL-
   Unaware Leaf (RUL).  A RAL is a Leaf that injects Host routes in RPL
   to manage the reachability of its IPv6 addresses.  Conversely, a RUL
   does not participate to RPL and cannot inject its Host routes in RPL.
   The RUL therefore needs a Host-to-Router interface to advertise its
   IPv6 addresses to its access Router so the Router can inject them the
   RPL network on its behalf.  Section 5 details the interface needed by
   a router that implements this specification.

NEW

   [USEofRPLinfo] introduces the terms RPL-Aware-Leaf (RAL) and RPL-
   Unaware Leaf (RUL).  A RAL is a Leaf that injects Host routes in RPL
   to manage the reachability of its IPv6 addresses.  Conversely, a RUL
   does not participate to RPL and cannot inject routes.  Section 5
   details a Host-to-Router interface that the RUL needs to implement to
   advertise its IPv6 addresses to a Router that supports this
   specification.  The document specifies how the Router injects those
   addresses as Host Routes in the RPL network on behalf of the RUL.

Works?

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Oct 2020 13:21:38 -0400

Pascal Thubert \(pthubert\) <pthubert=[email-masked]> wrote:
    > Unaware Leaf (RUL).  A RAL is a Leaf that injects Host routes in RPL to
    > manage the reachability of its IPv6 addresses.  Conversely, a RUL does
    > not participate to RPL and cannot inject routes.  Section 5 details a
    > Host-to-Router interface that the RUL needs to implement to advertise
    > its IPv6 addresses to a Router that supports this specification.  The
    > document specifies how the Router injects those addresses as Host
    > Routes in the RPL network on behalf of the RUL.

I would go on with two additional paragraphs:

  An RAL is an RPL router node that just happens to have no children, either by
  design (e.g., it sleeps too much to be useful), or circumstance.

  An RUL could connect to any mesh network that supports RFC8505, even if it
  operates with a mesh protocol other than RPL.  Assuming of course that the
  physical layers were compatible: radios types, frequencies, scheduling, etc..

Maybe this is beating people over the head, but I think, in the introduction,
that's okay.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 8 Oct 2020 19:26:20 +0000

Hello Alvaro:

Damn sorry that a piece of your review was cutoff, and yes, I'm using outlook. 

For the rest I can only thank you deeply for the width and breadth of your review. 

I did not yet go to the end (went 2/3 down) but I need your advice about updating RFC 8505 at the end of the covered piece. So I thought I should send you the partial response as of now.

The diffs so far are here: https://github.com/roll-wg/roll-unaware-leaves/commit/12fa6f5d9423b04da2ffd1dd19ee8ff4041355b6

Let's go!
 
> other pieces of this section.]

I like enhancements, changing the title to " Enhancements to RFC 6550 ".

We end up as follows if I understood you well:

   6.  Enhancements to RFC 6550  . . . . . . . . . . . . . . . . . .  12
     6.1.  Updated RPL Target Option . . . . . . . . . . . . . . . .  13
     6.2.  New Flag in the RPL DODAG Configuration Option  . . . . .  14
     6.3.  Updated RPL Status  . . . . . . . . . . . . . . . . . . .  15
   7.  Extending draft-ietf-roll-efficient-npdao . . . . . . . . . .  16
   8.  Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . .  16

I expect a review after this to ask me to rollback since we maintain the formal update (because of the RTO).

> changes/enhancements, and ones that represent a formal Update is what

For RFC 6550 
The term updates remains in the section " The RPL Target Option " since we want to generalize the new format.
This is to become the base for not only this spec but a trusted DAO operation in general.
It is added in the " Updated RPL Status " section as
"
   This specification updates the RPL Status with subfields as indicated below:
"

For RFC 8505
The term "updates" remains to change the behavior of the 6LR.

> [] "additions"  Changes/extensions/updates??

I picked "changes"

> draft-ietf-roll-efficient-npdao is needed.  As mentioned below, this

That was already gone, but then, we also discuss this in another thread

> rfc6550, so it is not expected that "basic" RPL nodes would know what

Understood
 
> know what the DCO is.  See §10.2.3.

I note  an  unfortunate name collision between the DCO message and the DODAG Config. Option, but we do not use DCO for the latter so we should be OK

Another note: section 10.2.3 is now 9.2.3

If I understand you it's can be easy one. This spec only uses NPDAO in non-storing mode. This means is end-to-end between the Root and the 6LR that implements this spec. Intermediate nodes just route a packet unaware that this is a control packet. So all we need to is indicate that the 6LR MUST support the DCO as updated therein.

Suggestion to cover it here:

7.  Extending draft-ietf-roll-efficient-npdao

   [EFFICIENT-NPDAO] defines the DCO message for RPL Storing Mode only,
   with a link-local scope.  All nodes in the RPL network are expected
   to support the specification since the message in processed hop by
   hop along the path this is being cleaned up.

   This specification extends the use of the DCO message to the Non-
   Storing MOP, whereby the DCO is sent end-to-end by the Root directly
   to the RAN that injected the DAO message for the considered target.
   In that case, intermediate nodes do not need to support
   [EFFICIENT-NPDAO]; they forward the DCO message as a plain IPv6
   packet between the Root and the RAN.

   This specification leverages the Non-Storing DCO between the Root and
   the 6LR that serves as attachment Router for a RUL.  A 6LR and a Root
   that support this specification MUST implement the Non-Storing DCO.
> routers in particular...so I think that Updating it is not the right

Whao, a difficult one. We update the RFC8505 behavior. 
But not to all type of node that implement RFC 8505. Only those that are RPL Routers.
So what is the most important? That we change the operation of an RFC or that the change ios scoped to a subset of nodes?
I'm asking, not proposing and answer. The reason behind is that is another RFC updates RFC 8505 with a change that is not compatible, the fact that we did not update will make it harder to track.

> node that (by definition) is not aware of this document.  [See more

This document is not RPL. A RUL is not aware of RFC 6550 but it must implement this.
I believe with the help of Michael and the new text in the introduction, this is now resolved.
For memory, that new text is

"

> that needs a RPL-Aware Router to obtain routing services over the RPL

Yes. It does not support RFC 6550 and needs a router that does; not clear what the contradiction was, but the text is the one that changed. I hope it is cleared now?

> IOW, why is the support only recommended and not required?

I see what you mean; more than in most case, the answer appear to be in the question. 
This text was already changed per your previous review; it now says
"
It is suggested that the
   RUL also implements [AP-ND] to protect the ownership of its
   addresses.
"
If you ask me, RFC 8505 and AP ND should be REQUIRED in 8504bis.

> using Normative language, then the text needs to be specific.

The point is that during the window thus created, only a subset of the routes will be available which limits the load balancing.
I made that change for your review already? Strange.

  Parallel Address Registrations to several 6LRs should be performed in
   an rapid sequence, using the exact same EARO for the same Address.
   Gaps between the Address Registrations will invalidate some of the
   routes till the Address Registration finally shows on those routes.
> language in that case (unless you are quoting directly).

Again already changed, more below.

> referring to a group of values: Duplicate Address, Moved, etc..

That's in section 6.3 where we have
"
   E:  1-bit flag.  Set to indicate a rejection.  When not set, a value
"

Let me add a reference. So we end up with

"
   [RFC8505] introduces error Status values in the NA(EARO) which can be
   received synchronously upon an NS(EARO) or asynchronously.  The RUL
   needs to support both cases and should refrain from using the address
   when the Status Value indicates a rejection (see Section 6.3).
"

> recommended, so there would be a Normative conflict.   s/MUST/must

Done

> [USEofRPLinfo] for details" is better.

Or a middle term between your proposals, e.g. ," sections 7 and 8 of [USEofRPLinfo] for details"? 
I hate the idea of asking to look at the whole big draft without a little help on where to search.

> [minor] s/Figure 10/Appendix A
Ok

> [minor] s/restore/uncompress

Ok

>    over an external route to a RUL [USEofRPLinfo].

Thanks for the suggestion. Applied.

> sub-section where the new registry is created.

We have this
"
                               0 1 2 3 4 5 6 7
                              +-+-+-+-+-+-+-+-+
                              |E|A|  Value    |
                              +-+-+-+-+-+-+-+-+

                        Figure 5: RPL Status Format
"

> [] BTW, this change should formally Update rfc6500.

I read rfc6550. Yes, this is one of the 2 reasons to the formal update.
Please note that there is no existing registry for the RPL status so we are creating it.
But we're also merging the statis with the DCO-ACK Status
In that we deprecate https://www.iana.org/assignments/rpl/rpl.xhtml#rpl-dco-ack-status
So we should update the NPDAO draft and remove that entry shouldn't we?
Note that NPDAO is already in missref because of this draft https://www.rfc-editor.org/cluster_info.php?cid=C310

> defined values".  Please take out that part of the sentence.

Ack; I can provide a ref to support the initial words instead
"
  The 6LoWPAN ND Status was defined for use in the EARO, see section
   4.1 of [RFC8505].
"

>    This reduction ensures that the values fit within a RPL Status as shown in
The suggestion is greatly appreciated. You also asked for the fwd pointer to IANA.
"
   To achieve this, the range of the EARO Status values is reduced to
   0-63.  This reduction ensures that the values fit within a RPL Status
   as shown in Figure 5.  See Section 12.2, Section 12.5, and
   Section 12.6 for the IANA declarations.
"

> [major] What about the ARO?  The Status values are shared between the

The IANA update applies to the registry that was created by RFC 6775 and updated by RFC 8505.
The text actually points at RFC 6775 as the reference for the registry so we are impacting both ARO and EARO.

"

12.2.  Resizing the ARO Status values

   Section 12 of [RFC6775] creates the Address Registration Option
   Status Values Registry with a range 0-255.

   This specification reduces that range to 0-63.

   IANA is requested to reduce the upper bound of the unassigned values
   in the Address Registration Option Status Values Registry from -255
   to -63.
"

> it relates to the redefined Status field.

Isn't this transitive? I mean the field defined in RFC 6775 is updated by RFC 8505.
Maybe the 6lo group should clarify that the ARO is deprecated somehow?

> specification of the behavior is needed; something like "ignore the

For "E" its another way if saying >127 as RPL did in the past. So this is not a change that the code can see.
For "A" set, there was no such case in the past. Now I'm confused. Who should ignore the bits? 
An old implementation will see unknown status values when the A bit is set by a new implementation. 
An old implementation will not set those bits because the status values 

> s/a value of 0/an RPL Status value of 0

Ok

> some point), or is the ability to signal the difference lost?

This describes the art of RPL? In this case, not a rejection means that the command was accepted but something meaningful happened that is worth signaling. The problem is to enable a backward compatibility for new status codes. A code written today will not be able to understand beyond the fact that the bit is set or not. But at least it can consider that the command was executed or not and take a different path.

> [major] This change in the RPL Status format should be a formal Update

Done

> 656	  flag for Values in range 1-10 which are all considered rejections.

Done twice 

> [major] What should a receiver do if the E flag is not set for "Values

Fair enough. 

> set, right? 

Right, that is what makes it hard, but if you look at it, 6LoWPAN ND is missing that bit.
So an existing implementation already has the problem of dealing with unknown status which means that by default it is an error. So setting the 'E' flag for unknown value is the safe bet.

>  How can we word the specification so that we don't depend

Excellent; I added 'unknown'
"
                                                                The RPL Root MUST set the
   'E' flag for all rejection and unknown Status Codes.  The Status
   Codes in range 1-10 [RFC8505] are all considered rejections."

> [major] "MUST copy the RPL Status Value unchanged"   Even if the value

Yes. It is unknown to the Root but still informative, e.g., at the 6LR or looking at traces.
Why loose that information?

> consistent, perhaps describe the field (below) as "ROVRsz (ROVR

Cool, done

> the setting of the F flag and the Option and Prefix Lengths.  Just

In EDAR we have to deduce from the overall length and that blocked the extensibility of the message, e.g., to add options.
So we ended up coding it in the code suffix, see https://tools.ietf.org/html/rfc8505#section-4.2. Better safe than sorry. 

> [nit] s/modified format/updated format

Yep; note the not-so-subtle hint that ROVR was designed for ROV even if defined in ND ; ) 

> how does a receiver know that this is the updated Option? 

The legacy implementation reads the bits up to Prefix Length And ignores the rest.
So it ignores that the address of the host is in full, and it ignores that the ROVR is present.
The other way around, the ROVRsz set to 0 indicates that the ROVR is not there.
So we get:

"
ROVRsz (ROVR Size):  Indicates the Size of the ROVR.  It MAY be 1, 2,
      3, or 4, indicating a ROVR size of 64, 128, 192, or 256 bits,
      respectively.  A value if 0 thus denotes a legacy Target Option.

"

> Is there a

Well it's a MUST... if a reserved field is not set to  0 all bets are off anywhere you use a reserved space for backward compatibility. The chances is that Rover Size + Prefix Length as wrongly computed exceed the Option Length, in which case it can be detected and reported.

> This forward compatibility may be a reason to formally Update rfc6550.

The updated RTO is one of the 2 reasons, the status being the other; but I do not think we have a forward compatibility problem.

> a recommendation and not a requirement.

Extremely constrained nodes may not be able to.

> without an explicit reference.

I'd rather say:
"
  The new 'F' flag is set to indicate that the Target Prefix field
   contains the IPv6 address of the advertising node, in which case the
   length of the Target Prefix field is 128 bits regardless of the value
   of the Prefix Length field.  If the 'F' flag is reset, the Target
   
"

To your point on the registry I changed the first appearance of the 'F' flag to:
" 
  Section 6.7.7 of [RFC6550] introduces the RPL Target Option, which
   can be used in RPL Control messages such as the DAO message to signal
   a destination prefix.  This document adds the capabilities to
   transport the ROVR field (see Section 4.2.3) and the IPv6 Address of
   the prefix advertiser when the Target is a shorter prefix.  Their use
   is signaled respectively by a new ROVR Size field being non-zero and
   a new "Advertiser address in Full" 'F' flag set, more in Section 6.1.

   This specification defines the new "Root Proxies EDAR/EDAC" (P) flag
   and encodes it in one of these reserved flags of the RPL DODAG
   Configuration option, more in Section 6.2

   "

> [major] Where is the "P" flag defined?  I didn't find it in this draft.

It is now in that new text where we describe the relation with the MOP

"
  This specification defines a new flag "Root Proxies EDAR/EDAC" (P).
   The 'P' flag is encoded in position 1 of the reserved Flags in the
   DODAG Configuration Option (counting from bit 0 as the most
   significant bit) and set to 0 in legacy implementations as specified
   respectively in Sections 20.14 and 6.7.6 of [RFC6550].

   The 'P' flag is set to indicate that the Root performs the proxy
   operation, which implies that it supports this specification and the
   updated RPL Target Option (see Section 6.1).

   Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that the
   definition of the Flags applies to Mode of Operation (MOP) values
   zero (0) to six (6) only.  For a MOP value of 7, the Root is expected
   to perform the proxy operation by default.
"

> That would help the linear reader (like me!) time in trying to figure

Oups. Noting that section 10 is now section 9. I added just before 9.1:

"
   Section 9.1 provides an overview of the route injection in RPL,
   whereas Section 9.2 offers more details from the perspective of the
   different nodes involved in the flow.

9.1.  General Flow
"

> references to where the detail is provided.

Problem is that is triaged per node type.

> the RPL registration is completed.  (See related comments in §10.2.2

The EDAR exchange does not comprise the NA. AlsoRFC 8505 does not indicate a strict timing for the NA.

> introduce this term and reference here?  It seems like an unnecessary

This is https://www.rfc-editor.org/authors/rfc8929.html 
This is the only known case where we inject "removed" so I thought it was worth mentioning to get the full picture.
Actually the picture next had a typo, not a 6LBR but a 6BBR on the right. I also indicated the protocols in the figure for clarity.

"
   An issue may be detected later, e.g., the address moves within the
   LLN or to a Root attached to a different 6LoWPAN Backbone Router
   (6BBR) [6BBR].  In that case, the ND Status Code is mapped in a RPL
   Status Value and back, as shown in Figure 7.

          6LN/RUL   <-ND-> 6LR   <-RPL->   		Root   <-ND->    6BBR
             |                  	|              		|                  	|
             |                  	|               		| NA(EARO, Status) |
             |                  	|  DCO(Status)  		|<-----------------	|
             | NA(EARO, Status) |<--------------		|                  	|
             |<-----------------	|               		|                 	|
             |               	|               		|                  	|

                        Figure 7: Asynchronous Issue

"
> true?  

Yes. Note that Fig 7 is now 8. 

Earlier we explain that the lifetimes are aligned. Since you may have missed it, I clarify that text as:
"
  To achieve this, the lifetimes and sequence counters in 6LoWPAN ND
   and RPL are aligned.
"
And then 
"
   An Address Registration refresh is performed by the 6LN to maintain
   the NCE in the 6LR alive before the lifetime expires.  Upon the
   refresh of a registration, the 6LR reinjects the corresponding route
   in RPL before it expires, as illustrated in Figure 8.

<snip>

                    Figure 8: Next RUL Registration Flow "

> If the registration already expired, should the whole process
> (Figure 5) be repeated?  

Yes but the alignment of lifetime is meant to avoid that. 

I see mention of (re)registration in §10.2.1,
> but none in §10.2.2.

The first paragraph was about this. 

"
   Also as prescribed by [RFC8505], the 6LR generates an EDAR message
   upon reception of a valid NS(EARO) message for the registration of a
   new IPv6 address by a 6LN.  If the initial EDAR/EDAC exchange
   succeeds, then the 6LR installs an NCE for the Registration Lifetime.
   For the registration refreshes, if the RPL Root has indicated that it
   proxies the keep-alive EDAR/EDAC exchange with the 6LBR (see
   Section 6), the 6LR MUST refrain from sending the keep-alive EDAR.
"

Let me use 'registration refresh' throughout for consistency.

> draft-ietf-roll-efficient-npdao.  Should something be mentioned? 

There was no mapping between ND and RPL so far. 
We are redefining the DCO status to be a RPL status and conform the same mapping as the rest.
DCO is asynchronous; the message may fly slower or faster than the DAO-ACK.
We want to avoid confusion if both are received with a different status.

>  The

Yes

> occur, but on a retry there is success...??

I do not know of such a case. But then, that should be a case where the 'E' flag is cleared. Else the DCO destroys the route.

>    the traffic to the target node.

Makes sense;  I added 

"
   [EFFICIENT-NPDAO] introduces the ability for a rogue common ancestor
   node to invalidate a route on behalf of the target node.  In that
   case, the RPL Status in the DCO has the 'A' flag not set, and a
   NA(EARO) is returned to the 6LN with the 'R' flag not set.  This
   encourages the 6LN to try another 6LR.  If a 6LR exists that does not
   use the rogue common ancestor, then the 6LN will eventually succeed
   gaining reachability over the RPL network in spite of the rogue node.

"

> fact, not making a normative statement.

Done

> [minor] s/6LN, and a RUL /6LN/RUL, which

Done

> [major] s/RFC3315/RFC8415

Oups

> set the "T" flag.  The TID is incremented
Done

> [nit] s/[RFC8505] which/[RFC8505], which

Done

> Registration Lifetime should be.  If so: s/that have a non-zero/with a

Done

> specification is already made in rfc8505.  ??

What is recommended is to do the registration(s) that keep(s) the state active before the ones that destroy it, so there is no transient when the state is destroy for nothing. Rewording to:

"
   3.  As stated in section 5.2 of [RFC8505], the 6LN can register to
       more than one 6LR at the same time.  In that case, it uses the
       same EARO for all of the parallel Address Registrations.  The 6LN
       SHOULD send the NS(EARO), if any, that maintain a registration
       active (i.e., with a non-zero Registration Lifetime) and ensure
       that one succeeds before it sends an NS(EARO) that terminates
       other registrations, to avoid the churn related to transient
       route invalidation in the RPL network.
"

> of the RUL Acting as 6LN", which one is it? ;-)

Argl

The former

Fixed

> "SHOULD NOT" doesn't imply never.

Agreed, that is incorrect.  I removed that extra text.

> the R flag set...is that where the specification is?

Maybe that one is a lot less minor than meet the eye.
I've been juggling with both specs and missed that the setting or the 'R' flag in the NA(EARO) is not discussed in RFC 8505.
I guess it should have been. Now we appear to need to specify this in here.
Which means we update RFC 8505 because this is the desired operation for any node that sets the 'R' flag

> reachability".  There isn't a provision for a RUL to not set the R

The intention was that it sets the R flag in at least one registration not necessarily all...

I need your advice to progress on the last points here, so I leave it at that for today.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 8 Oct 2020 16:09:56 -0500

On October 8, 2020 at 3:26:36 PM, Pascal Thubert wrote:

Pascal:

Hi!

...
> I did not yet go to the end (went 2/3 down) but I need your advice about
> updating RFC 8505 at the end of the covered piece. So I thought I should
> send you the partial response as of now.

In this message I'm just commenting on what is related to updating
rfc8505.  I'll take a look at the rest later.

Thanks!

Alvaro.

...
> So what is the most important? That we change the operation of an RFC or
> that the change ios scoped to a subset of nodes?

IMO, the answer is to make the change that is necessary, and no more.

> I'm asking, not proposing and answer. The reason behind is that is another
> RFC updates RFC 8505 with a change that is not compatible, the fact that we
> did not update will make it harder to track.

Yes, this is where an "Extends" or at least "See Also" tag would be
great [1], but we don't have those.

OTOH, the reason we do so many reviews (WG, directorates, IETF LCs,
etc.) is to get also cross-area review.  This should catch
incompatible changes.  Yes, I realize this is the ideal situation, and
that a change like this may still be missed... :-(

The risk is then that the process doesn't work; i.e. that people don't
do good reviews. :-(

Having said all that, if you (the WG) want to change the behavior for
all the nodes, then we'll need positive confirmation from 6lo that
this is ok.  I seem to remember that there was already communication
with 6lo about the proposed changes, and there was no opposition.  I
can go find that thread again...

Given the text in this document (like the sentence below for example
-- and what you said above), it doesn't seem to me that making a
change for all the nodes (vs. just RPL routers) was the WGs intent.
So we'll have to confirm that as well.

Also, we'll probably need to generalize the specification to not be
specific to RPL.  But with any RPL-specific normative behavior
highlighted.

What do you want to do?

[1] https://tools.ietf.org/html/draft-kuehlewind-update-tag

...
...
> Isn't this transitive? I mean the field defined in RFC 6775 is updated by

No.  As far as I understand it, rfc8505 didn't change the behavior of
the ARO, it extended it.  In fact, the changes are backward
compatible, which tell me that the ARO (independent of an EARO) is
still valid and expected to work.  I would be happy to be corrected.

It may be that no one cares about changes to the ARO anymore...but
that is a different conversation.  And updating only the EARO seems to
break the backward compatibility.

> Maybe the 6lo group should clarify that the ARO is deprecated somehow?

That would be nice...but that is not what rfc8505 says.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 9 Oct 2020 06:39:40 +0000

OK Alvaro;

In summary,

We update RFC 6775 and RFC 8505 because we alter the range of the ND Status Code
We extend RFC 6775 and RFC 8505 because we refrain from sending the from sending the EDAR on a registration refresh with the 'R' flag.
We extend RFC 6775 because  we process the 'R' flag in the NA(EARO) and other stuff in the RUL perspective section.

Do we agree?

So many thanks;

Pascal
 
> From: Alvaro Retana <[email-masked]>
> Sent: jeudi 8 octobre 2020 23:10
> To: Pascal Thubert (pthubert) <[email-masked]>; draft-ietf-roll-unaware-
> [email-masked]
> Cc: [email-masked]; Routing Over Low power and Lossy networks
> <[email-masked]>; Rahul Jadhav <[email-masked]>
> Subject: RE: AD Review of draft-ietf-roll-unaware-leaves-18
> 
> > I did not yet go to the end (went 2/3 down) but I need your advice
> > about updating RFC 8505 at the end of the covered piece. So I thought
> > I should send you the partial response as of now.
> 
> > > [major] To me, Updating an RFC means that the implementations of
> > > that RFC should also implement this one. In this case, there would
> > > be an expectation that all 6LRs would support the change. Is that
> > > what is intended?
> > >
> > So what is the most important? That we change the operation of an RFC
> > or that the change ios scoped to a subset of nodes?
> 
> > I'm asking, not proposing and answer. The reason behind is that is
> > another RFC updates RFC 8505 with a change that is not compatible, the
> > fact that we did not update will make it harder to track.
> 
> Yes, this is where an "Extends" or at least "See Also" tag would be great [1],
> but we don't have those.
> 
> etc.) is to get also cross-area review.  This should catch incompatible
> changes.  Yes, I realize this is the ideal situation, and that a change like this
> may still be missed... :-(
> 
> The risk is then that the process doesn't work; i.e. that people don't do good
> reviews. :-(
> 
> 
> Having said all that, if you (the WG) want to change the behavior for all the
> nodes, then we'll need positive confirmation from 6lo that this is ok.  I seem to
> remember that there was already communication with 6lo about the proposed
> changes, and there was no opposition.  I can go find that thread again...
> 
> -- and what you said above), it doesn't seem to me that making a change for all
> the nodes (vs. just RPL routers) was the WGs intent.
> Also, we'll probably need to generalize the specification to not be specific to
> RPL.  But with any RPL-specific normative behavior highlighted.
> 
> 
> What do you want to do?
> 
> 
> > > means that this document should Update both rfc6775 and rfc8505
> > > where it relates to the redefined Status field.
> >
> No.  As far as I understand it, rfc8505 didn't change the behavior of the ARO, it
> extended it.  In fact, the changes are backward compatible, which tell me that
> the ARO (independent of an EARO) is still valid and expected to work.  I would
> be happy to be corrected.
> 
> It may be that no one cares about changes to the ARO anymore...but that is a
> different conversation.  And updating only the EARO seems to break the
> backward compatibility.
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 9 Oct 2020 07:10:22 +0000

Hello Alvaro

> rfc8505.  I'll take a look at the rest later.

I'll be rewording the other mail to adapt to your answers therein. Please do not reply more to this, and expect the complete reforged email very soon.

Take care,

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Sat, 10 Oct 2020 18:43:12 -0400

> great [1], but we don't have those.

Yes, but we can still (and should), in the text explain if it's Extends or
See Also, right?

    > [1] https://tools.ietf.org/html/draft-kuehlewind-update-tag

It seems we should just sprinkle Updates all over the place just to cover all
our bases :-)

---

From: Michael Richardson <[email-masked]>
Date: Sat, 10 Oct 2020 18:54:14 -0400

> We extend RFC 6775 and RFC 8505 because we refrain from sending the
    > from sending the EDAR on a registration refresh with the 'R' flag.
    > We extend RFC 6775 because  we process the 'R' flag in the NA(EARO) and
    > other stuff in the RUL perspective section.

    > Do we agree?

agreed.

It's a bit of a mess, but making an omlette...
I guess there is a book here for someone.