Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves
draft-ietf-roll-unaware-leaves-30

Received changes through RFC Editor sync (created alias RFC 9010, changed title to 'Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves', changed abstract to 'This specification provides a mechanism for a host that implements a routing-agnostic interface based on IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery to obtain reachability services across a network that leverages RFC 6550 for its routing operations.  It updates RFCs 6550, 6775, and 8505.', changed pages to 36, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2021-04-09, changed IESG state to RFC Published, created updates relation between draft-ietf-roll-unaware-leaves and RFC 6550, created updates relation between draft-ietf-roll-unaware-leaves and RFC 6775, created updates relation between draft-ietf-roll-unaware-leaves and RFC 8505)

[Ballot comment]
Thanks to Carl Wallace for the secdir review, and to the authors for
having addressed the review comments.

There's a lot of updates in this document of various sorts, and it's a
bit challenging to reason about all of them, especially with respect to
feature negotiation/incremental deployment.  This will be a recurring
theme in my detailed comments.  My current understanding so far is:

- there is not currently any support for RULs, so we don't really need
  to worry about existing RULs that do not comply with this spec (though
  this spec does add a couple new requirements not present with the
  stock versions of 6LoWPAN ND, etc.)
- If the RPL Root doesn't support this, it can't be used
- the RPL Root advertises its support via the 'P' flag in the DODAG
  Configuration Option that is sent to all 6LRs
- Many message flows require the support of a 6LR to initiate them
- but there seem to be some cases where there are asynchronous messages
  originating from the root (or 6LBR) ... can they end up at a 6LR that
  does not support the new strucures?
- The RPL Root can now proxy EDAR/EDAC ... but can a 6LR "miss the memo"
  for that and also attempt EDAR?  (IIUC, "no", since such a 6LR
  wouldn't know about RULs in the first place.)
- Some of the new mechanisms (e.g., suppression of periodic EDAR in
  favor of DAO and proxying by the RPL Root) are not limited to use by
  RULs (?) and thus could be triggered on behalf of nodes not expecting
  such services (?)

It would be great to have some exposition on how this stuff is expected
to be rolled out and how it's safe for incremental deployment,
especially if (as the shepherd report indicates) we don't have any
implementation experience to build confidence.


There might be a small internal inconsistency in §9.2.2 in terms of what
needs to be waited for before the NA(EARO) is emitted (see the detailed
comments for why).


I still feel that if we're going to incrementally add new properties to
MOP 7, we should list the relevant documents as references in the
registry until MOP 7 is fully specified.  In this case we can arguably
get away with not doing so since this document Updates: RFC 6550 already
and thus could be said to be doing the reservation by modification of
the core protocol, but we are not using that procedure universally
(e.g., for turnon-rfc8138) and it seems prudent to use a consistent
mechanism.

Section 1

  A RUL may be unable to participate because it is very energy-
  constrained, code-space constrained, or because it would be unsafe to
  let it inject routes in RPL.  Using 6LoWPAN ND as opposed to RPL as
  the host-to-router interface limits the surface of the possible
  attacks by the RUL against the RPL domain, and can protect RUL for
  its address ownership.

(nit?) I am not entirely sure what sense "and can protect" is used in.
IIUC, a given leaf could either be a RAL or a RUL; an RAL participates
in RPL and as such is assumed to be trusted to properly advertise
routes, including protecting routes to its own address.  In contrast, an
RUL requires assistance of the RPL router to be able to protect its
address, something that 6LoWPAN ND enables by virtue of the ROVR.  So I
feel like the contrast is more of a "but can still protect the RUL's
address ownership" -- the "and can" construction suggests that this is
an additional benefit of using 6LoWPAN ND that is not achieved when the
leaf is RPL-aware.  (Or am I conflating RPL and 6LoWPAN ND too much?)

Section 3

  details).  If the packet from the RUL has an RPI, the 6LR as a RPL
  border router SHOULD rewrite the RPI to indicate the selected
  Instance and set the flags, but it does not need to encapsulate the
  packet.

(1) why is there any normative language in a non-normative section?
(2) doesn't it need to be a MUST, if it's not encapsulating?

  A RUL is not expected to support the compression method defined in
  [RFC8138].  For that reason, the border router uncompresses the
  packet before forwarding it over an external route to a RUL
  [USEofRPLinfo].

Just to confirm: the "border router" here is not the 6LBR but rather a
"normal" 6LR (i.e., an "RPL boder router")?

Section 4.2

  "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505]
  updates the behavior of RFC 6775 to enable a generic Address
  Registration to services such as routing and ND proxy, and defines
  the Extended Address Registration Option (EARO) as shown in Figure 2:

nit: the grammar seems off here; it would scan better if it was "to
provide services", but I'm not 100% sure that's correct.

Section 4.3

  The exchange is protected by the retry mechanism (ARQ) specified in
  Section 8.2.6 of [RFC6775], though in an LLN, a duration longer than
  the default value of the RetransTimer (RETRANS_TIMER) [RFC4861] of 1
  second may be necessary to cover the round trip delay between the 6LR
  and the 6LBR.

This is the only place in the document that we use the term ARQ (other
than the glossary), and RFC 6775 itself does not use the term either.
So I'm not sure that it's adding much value (just risk of confusion if
someone expects it to be present in RFC 6775 the way I did).

Section 5.1

  To obtain routing services from a router that implements this
  specification, a RUL needs to implement [RFC8505] and sets the "R"
  and "T" flags in the EARO to 1 as discussed in Section 4.2.1 and
  Section 4.2.3, respectively.  Section 9.2.1 specifies new behaviors

nit: s/4.2.3/4.2.2/

Section 6.1

  The updated format is illustrated in Figure 4.  It is backward
  compatible with the Target Option in [RFC6550].  It is recommended

I agree that it is backwards compatible in the sense that it degenerates
into the previous structure when the ROVR size is zero.  But do we have
confidence that existing implementations will do something useful if we
use bits that they treat as flags, to indicate that the overall size of
the option is increased in a way not previously envisioned?

Section 6.2

  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 implementation
  MUST consider that the Root performs the proxy operation.

How is this to be noted for future implementors of MOP value 7?  Are we
relying on the "Updates:" relationship with 6550 to note this?

Section 6.3

  Status Value:  6-bit unsigned integer.  If the 'A' flag is set to 1
      this field transports a Status value defined for IPv6 ND EARO.
      When the 'A' flag is set to 0, the Status value is defined for
      RPL.

nit(?): I suggest "the Status value is as defined for RPL" (add "as", or
perhaps "one" in the same place).

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

By my reading "copy the RPL Status value unchanged" includes the values
of the E and A flags (and this is predicated on 'A' being set), which
doesn't seem like it would have the desired effect...I expect that only
the StatusValue field is supposed to be copied (with the high bits set
to zero)?

Section 7

  In the case of a RUL, the 6LR that serves the RUL acts as the RAN
  that receives the Non-Storing DCO.  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.

Should we mention with in the discussion of the 'P' flag in §6.2?
I'm not entirely sure how the negotiation/enablement procedure works for
a RAL, either.

Section 8

  *  If the RPL Root advertises the capability to proxy the EDAR/EDAC
      exchange to the 6LBR, the 6LR refrains from sending the keep-alive
      EDAR message.  If it is separated from the 6LBR, the Root
      regenerates the EDAR message to the 6LBR periodically, upon a DAO
      message that signals the liveliness of the address.

I feel like we should mention the situation where the RPL Root
advertises the 'P' flag but the 6LR does not support this specification.
Do we end up with both the 6LR and the RPL Root sending the EDAR
message, or is the RPL Root expected to notice that the 6LR is sending
one and refrain from generating an additional one?  (I guess we expect
it to be uncommon that 6LBR and RPL Root are different, anyway?)  Or is
this just not supposed to happen because the mechanism only exists to
support RULs and an un-updated 6LR will not attempt to support RULs?

Section 9.1

          6LN/RUL            6LR  <6LR*>  Root              6LBR
            |                |              |                  |
            |<------ND------>|<----RPL----->|<-------ND-------->|
            |                |<----------------ND-------------->|

Are these arrows still part of the "legend" (of sorts) as opposed to
being indications of the initial flow(s)?

  To achieve this, the Path Sequence and the Path Lifetime in the DAO
  message are taken from the Transaction ID and the Address
  Registration lifetime in the NS(EARO) message from the 6LN.

Reusing an identifier taken from one context in one protocol to play a
role in a different context in a different protocol has historically led
to security-relevant flaws/attacks.  What kind of analysis has been done
to consider the risk of such issues here?

  [RFC8929] expects that the 6LBR is collocated with the RPL Root, but
  if not, the 6LBR MUST forward the status code to the originator of
  the EDAR, either the 6LR or the RPL Root that proxies for it.  The ND
  status code is mapped in a RPL Status value by the RPL Root, and then
  back by the 6LR.

Continuing the theme, can we get into a scenario where the 6LR in this
flow does not implement this specification but receives a DCO carrying
an EARO status code?

  Figure 9 illustrates this in the case where the 6LBR and the Root are
  not collocated, and the Root proxies the EDAR messages.

(The figure shows an EDAC message being proxied, not an EDAR message,
though for the general case using EDAR as the description seems to make
sense.)

Section 9.2.1

  This specification does not alter the operation of a 6LoWPAN ND-
  compliant 6LN/RUL, which is expected to operate as follows:
  [...]
  5.  Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets
      the R Flag in the EARO of its registration(s) for which it
      requires routing services.  If the R Flag is not echoed in the
      NA, the RUL SHOULD attempt to use another 6LR.  The RUL SHOULD
      ensure that one registration succeeds before setting the R Flag
      to 0.  [...]

AFAICT the SHOULDs here represent a divergence from the previously
specified 6LN/RUL 6LoWPAN ND behavior (not least because this document
seems to be the first definition of using the R flag in the NA as
opposed to NS), in contravention to the initial statement.

Section 9.2.2

  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, there is no suggested Instance.  If the 6LR participates
  in the suggested RPL Instance, then the 6LR MUST use that RPL
  Instance for the Registered Address.

This MUST-level requirement seems to preclude any kind of policy filter
on the 6LR to apply authorization checks to attempts to use a given RPL
Instance.  Is that intended?

  NA(EARO) to the RUL.  Upon receiving an asynchronous DCO message, if
  a DAO-ACK is pending then the 6LR MUST wait for the DAO-ACK to send
  the NA(EARO) and deliver the status found in the DCO, else it MUST
  send an asynchronous NA(EARO) to the RUL immediately.

I think I missed the explanation for why it has to wait for the DAO-ACK
before sending the NA(EARO), if the DCO is going to take precedence.
In particular, it seems to be in conflict with the description of the
general flow in §9.1, which says that "[u]pon the DAO-ACK - or the DCO
if one arrives first - the 6LR responds to the RUL with an NA(EARO)."

  The 6LR MUST set the R Flag to 1 in the NA(EARO) back if and only if
  the 'E' flag is set to 0, indicating that the 6LR injected the
  Registered Address in the RPL routing successfully and that the EDAR
  proxy operation succeeded.

Please use a bit more detail on where the 'E' flag is (I assume it's the
one taken from a bit that was formerly part of the 'Status' field in the
RPL message, but in the next paragraph we clearly say it's the flag "in
the RPL Status" to avoid any doubt).

  An error injecting the route causes the 'E' flag to be set to 1.  If
  the error is not related to ND, the 'A' flag is set to 0.  In that
  case, the registration succeeds, but the RPL route is not installed.
  So the NA(EARO) is returned with a status indicating success but the
  R Flag set to 0, which means that the 6LN obtained a binding but no
  route.

Continuing the theme, can we get into a situation where the RUL does not
check the R flag and assumes that there is a route installed?

  If the 'A' flag is set to 0 in the RPL Status of the DAO-ACK, then
  the 6LoWPAN ND operation succeeded, and an EARO Status of 0 (Success)
  MUST be returned to the 6LN.  The EARO Status of 0 MUST also be used
  if the 6LR did not attempt to inject the route but could create the
  binding after a successful EDAR/EDAC exchange or refresh it.

  If the 'E' flag is set to 1 in the RPL Status of the DAO-ACK, then
  the route was not installed and the R flag MUST be set to 0 in the
  NA(EARO).  The R flag MUST be set to 0 if the 6LR did not attempt to
  inject the route.

These two paragraphs seem to have some amount of redundancy with the
preceding few paragraphs, though I'm not entirely sure how much.

  In a network where Address Protected Neighbor Discovery (AP-ND) is
  enabled, in case of a DAO-ACK or a DCO indicating transporting an

nit: It seems that we should just pick one of "indicating transporting".

  EARO Status value of 5 (Validation Requested), the 6LR MUST challenge
  the 6LN for ownership of the address, as described in section 6.1 of
  [RFC8928], before the Registration is complete.  This flow,
  illustrated in Figure 10, ensures that the address is validated
  before it is injected in the RPL routing.

To me Figure 10 is showing the flow where the 6LR itself initiates the
"Validation Requested" state; I don't see a triggering DAO-ACK or DCO.

  The 6LR may at any time send a unicast asynchronous NA(EARO) with the
  R Flag set to 0 to signal that it stops providing routing services,

Staying on theme, what will a RUL that doesn't know about this spec do
with such an asynchronous NA(EARO)?

Section 9.2.3

  A RPL Root MUST set the 'P' flag to 1 in the RPL DODAG Configuration
  Option of the DIO messages that it generates (see Section 6) to
  signal that it proxies the EDAR/EDAC exchange and supports the
  Updated RPL Target option.

[just noting that this is another place, in addition to §6.2, where we
enumerate what the 'P' flag signals, which may be incomplete, per my
previous comment.]

Section 10

  The 6LR acts as a generic MLD querier and generates a DAO with the
  Multicast Address as the Target Prefix as described in section 12 of
  [RFC6550].  As for the Unicast host routes, the Path Lifetime
  associated to the Target is mapped from the Query Interval, and set
  to be larger to account for variable propagation delays to the Root.

(Is this just the "round up, if needed" setting, or is there more to
consider when accounting for variable propagation delays?)

  The Root proxies the MLD exchange as a listener with the 6LBR acting
  as the querier, so as to get packets from a source external to the
  RPL domain.

(Only if the source is external to the RPL domain, right?)

Section 11

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

(editorial) I suggest some phrasing akin to "this specification improves
the situation by isolating edge nodes so they can only interact [...]".

  In a general manner, the Security Considerations in [RFC7416]
  [RFC6775], and [RFC8505] apply to this specification as well.

But not those of RFC 6550?

  More importantly, the 6LR is the node that injects the traffic in the
  RPL domain, so it has the final word on which RPLInstance is to be
  used for the traffic coming from the RUL, per its own policy.

[I do believe I commented previously about just this topic :) ]

[Ballot comment]
The shepherd writeup says "With these reviews and discussions -15 is ready for IESG review."  But -23 was last called, and this is version -26.  Just checking... is this all still current?

Though it is present in the glossary in Section 2.2, I don't see "AR" anywhere in this document.  The glossary also needs to be sorted again.

[Ballot comment]
The shepherd writeup says "With these reviews and discussions -15 is ready for IESG review."  But -23 was last called, and this is version -26.  Is this all still current?

Though it is present in the glossary in Section 2.2, I don't see "AR" anywhere in this document.  The glossary also needs to be sorted again.

[Ballot comment]
(I reviewed -25, only skimmed the diff from -25 to -26)

[[ comments ]]

[ section 5.4 ]

* Another way to address non-zero segments left RH3s in
  useofrplinfo might be to add some text here saying they MUST
  be dropped and MAY send ICMPv6 error messages, and then
  point to this text.  Or just say that there's no change to
  the processing of these from existing documents. Or something.


[[ nits ]]

[ section 9.1 ]

* "to maintain the NCE ... alive" -> "to keep the NCE ... alive",
  I think

[ section 9.2 ]

* "ad serving" -> "and serving", probably

[ section 9.2.1 ]

* "signaled a 6CIO" -> "signaled by a 6CIO"

[ section 10 ]

* ". ." -> "."

[Ballot comment]
Thank you for responding to the SECDIR review and thank you to Carl Wallace for performing it

** Section 6.1.  ROVRsz value.

Indicates the Size of the ROVR.  It SHOULD be 1,
      2, 3, or 4, indicating a ROVR size of 64, 128, 192, or 256 bits,
      respectively.  If a legacy Target Option is used, then the value
      must remain 0, as specified in [RFC6550]. 

-- Why are the values of ROVRsz not constrained with a MUST to 0 – 4?  What’s the thinking on allowing undefined ROVR size values?  Or not specifying that these values comes from:
https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-codes-type-157-code-suffix
https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-codes-type-158-code-suffix

-- If the values of ROVR are 1 – 4 why are 4 bits required, not 3 (i.e., 100 = 4)?

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

How does this role validation (verification of entitlement) work?

[Ballot comment]
Thank you for the work put into this document. While the authors spent a lot of time in detailed explanations, I found this document hard to read, perhaps some additional diagrams may have helped (like those in section 9).

Big thanks to Peter Van der Stock for his Last Call review at:
https://datatracker.ietf.org/doc/review-ietf-roll-unaware-leaves-23-iotdir-lc-van-der-stok-2020-12-08/
Peter completed his review at the same time as -23 was published, so, authors, please have a look.

I appreciate that the shepherd and RTG AD have contacted the 6LO WG for review (even if no comments were received).

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Be aware of a down-ref: Normative reference to an Informational RFC: RFC 7102

-- Abstract --
Suggest to expand some acronyms in the abstract: RPL, ND. In the same vein, writing that RFC 6550 is RPL could help the reading of the abstract.

-- Section 1 --
s\whereas others will only terminate packets\whereas others will only receive/originate packets\ ?

-- Section 3 --
"packets going down" could probably be rewritten in a more formal way.

The use of "Source Routing Header (SRH)" is commonly linked to RFC 8754 Segment Routing Header... May I suggest to use 'RH' (as the "source" is always implicit in RH).

-- Section 6 --
Does the "reserved" word have any value in "encodes it in one of these reserved flags of the RPL DODAG" ? With the publication of this document, it is no more reserved IMHO.

-- Section 6.1 --
Should the normative uppercase language be used ? E.g., "length of the Target Prefix field is 128 bits regardless of the value" is not really normative...

I also wonder in which case the ROVR length cannot be derived from the Option Length and the Prefix Length (the HbH option length is expressed in octets per RFC 8200). Wasting valuable flags space for a length seems a bold decision to me. The text describing the option is convoluted so I am not sure about my point else I would have balloted a DISCUSS.

-- Section 6.3 --
While I appreciate that there are severe constraints and while I admire the authors' imagination, the mix of status codes looks like a chimera to me. Nothing blocking, just a comment of mine, no need to reply.

-- Section 9.1 --
Is there a reason why "Extended DAR" and "EDAR" coexist in figure 6 ?

Not the first time that "aligned" is used, e.g., in "This flow requires that the lifetimes and sequence counters in 6LoWPAN ND and RPL are aligned." but is this term well defined and well accepted?

What is the meaning of "negative" in "an NA message with a negative status " ? Most significant bit to 1 ?

-- Section 11 --
Should a rate limit of EDAR/DAO message by the 6LR be recommended ? RFC 4941 could be our enemy here...

== NITS ==

Unsure whether capitalized "Host" and "Router" and "Leaf" are required.

The companion document uses "IPv6-in-IPv6" rather than "IP-in-IP"

-- Section 5.3 --
Please expand HbH in the section title.

-- Section 5.4 --
Suggest to drop " and the packet is dropped otherwise."

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-roll-unaware-leaves-23. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the Address Registration Option Flags registry on the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry page located at:

https://www.iana.org/assignments/icmpv6-parameters/

the first field of the registry will be renamed from:

ARO Status

to:

Bit Number

Second, in the Address Registration Option Status Values registry also on the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry page located at:

https://www.iana.org/assignments/icmpv6-parameters/

the existing registry has values from 0-255. This will be changed to 0-63. The range of unassigned values at the end of the current registry will be changed from:

11-255 Unassigned

to:

11-63 Unassigned

Third, in the DODAG Configuration Option Flags for MOP 0..6 registry (currently named DODAG Configuration Option Flags and to be renamed upon approval of another draft) on the Routing Protocol for Low Power and Lossy Networks (RPL) registry page located at:

https://www.iana.org/assignments/rpl/

a single, new registration is to be made as follows:

Bit number: [ TBD-at-Registration ]
Capability Description: Root Proxies EDAR/EDAC (P)
Reference: [ RFC-to-be ]

IANA understands that the authors have suggested bit number 1 for this registration.

Fourth, in the RPL Target Option Flags also on the Routing Protocol for Low Power and Lossy Networks (RPL) registry page located at:

https://www.iana.org/assignments/rpl/

the registry is to be modified as containing registration for exactly 4 bits. There is a single, new registration in the registry as follows:

Bit number: [ TBD-at-Registration ]
Capability Description: Advertiser address in Full (F)
Reference: [ RFC-to-be ]

IANA understands that the authors have suggested bit number 1 for this registration.

Fifth, a new registry is to be created called the RPL Non-Rejection Status values registry. The new registry will be created on the Routing Protocol for Low Power and Lossy Networks (RPL) registry page located at:

https://www.iana.org/assignments/rpl/

The registry will contain values between 0-63. The registry will be managed via IETF review as defined in RFC 8126. There is a single, initial registration in the new registry as follows:

Value Meaning Reference
------+------------------------+-------------------------
0 Unqualified acceptance [RFC6550][ RFC-to-be ]
1-63 Unassigned

Sixth, a new registry is to be created called the RPL Rejection Status values registry. The new registry will be created on the Routing Protocol for Low Power and Lossy Networks (RPL) registry page located at:

https://www.iana.org/assignments/rpl/

The registry will contain values between 0-63. The registry will be managed via IETF review as defined in RFC 8126. There is a single, initial registration in the new registry as follows:

Value Meaning Reference
------+------------------------+-------------
0 Unqualified rejection [ RFC-to-be ]
1-63 Unassigned

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-12-09):

From: The IESG
To: IETF-Announce
CC: JADHAV Rahul , rahul.ietf@gmail.com, roll@ietf.org, roll-chairs@ietf.org, draft-ietf-roll-unaware-leaves@ietf.org, aretana.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Routing for RPL Leaves) to Proposed Standard


The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document: - 'Routing for RPL
Leaves'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-12-09. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification updates RFC6550, RFC6775, and RFC8505, to provide
  routing services to RPL Unaware Leaves that implement 6LoWPAN ND and
  the extensions therein.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/



No IPR declarations have been submitted directly on this I-D.

Closed request for Early review by IOTDIR with state 'Team Will not Review Version': The same draft of later version (v.13) has been reviewed and resolved in IOT-DIR list

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?
Shepherd response:  Proposed Standard.
The document enables reachability for RPL unaware 6LoWPAN hosts through RPL
network.  It provides routing services to 6LoWPAN Hosts by defining procedures
for the Host to attach to a RPL aware node which in turn acts as point of
transit for the Host.

b. Why is this the proper type of RFC?
Rsp: 'Standards Track' document is needed to mandate and recommend certain
handling such as aspects of Neighbor Discovery, and the draft also extends
RFC6550 and RFC8505.

c. Is this type of RFC indicated in the title page header?
Rsp: Yes

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Shepherd response:
Technical Summary

    The document enables reachability for RPL unaware 6LoWPAN hosts through RPL
    network.  It provides routing services to 6LoWPAN Hosts by defining
    procedures for the Host to attach to a RPL aware node which in turn acts as
    point of transit for the Host.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Shepherd response:
This draft has been discussed in ROLL/6lo working group. The draft had an
impact on 6LoWPAN ND status field. The status field had to be resized to 6bits
from 8bits and this was conveyed to the 6lo working group and no objections
were raised.
With these reviews and discussions -15 is ready for IESG review.
My personal take as a shepherd/reviewer/WG participant is that the document
solves the problem it indicates to solve. I certainly believe there are
use-cases which will benefit from this work.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
Shepherd response: There are currently NO implementations.

  Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?
Shepherd response:
Multiple reviews were done by Rahul Jadhav (shepherd) which resulted in 4
updates to this draft.

If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
Shepherd response: Not Applicable

Personnel

Document Shepherd: Rahul Jadhav
Responsible Area Director: Alvaro Retana

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
Shepherd response:
I have reviewed the document and my comments were addressed in version -15 that I
think is ready for IESG review.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
Shepherd response: No concerns. I certainly believe that the document solves
the problem it indicates to solve. It is now possible for 6LNs not supporting
RPL to participate in the network using RPL mesh as a transit.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
Shepherd response:
The document updates RFC8505 standardized in 6lo working group. ROLL chairs had
made a review-request on 6lo ML. No reviews were received from 6lo however 6lo
chairs had specifically replied positively about the ARO status value field
resize. 6lo AD had also FYIed IoT-Directorate for the changes and no objections
were raised.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
Shepherd response: No concerns

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Shepherd response: All the authors have confirmed. There are no IPRs
disclosures in the context.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
Shepherd response: Yes, all the authors have explicitly made a disclosure.
There are no IPRs on the draft.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
Shepherd response: Strong concurrence of few individuals with others being
silent, is the state I see.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
Shepherd response: No discontent raised by anyone.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
Shepherd response: The idnits tools showed 1 warning and 2 comments.
    == Outdated reference: A later version (-18) exists of
        draft-ietf-roll-efficient-npdao-17
    [Shepherd rsp: Not a problem]

Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--).

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
Shepherd response: Not Applicable

(13) Have all references within this document been identified as
either normative or informative?
Shepherd response: Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
Shepherd response: None

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
Shepherd response: None

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
Shepherd response: 6550, 8505 will be updated and are mentioned in title page
header.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
Shepherd response: All the IANA considerations are appropriately handled.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
Shepherd response: All the impacted registries are within 6lo and ROLL WG. 6lo
working group was consulted about the change and the 6lo chair (Carles)
indicated the support.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
Shepherd response: Not applicable as there are no formal language constructs in
the document.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?
Shepherd response:  Proposed Standard.
The document enables reachability for RPL unaware 6LoWPAN hosts through RPL
network.  It provides routing services to 6LoWPAN Hosts by defining procedures
for the Host to attach to a RPL aware node which in turn acts as point of
transit for the Host.

b. Why is this the proper type of RFC?
Rsp: 'Standards Track' document is needed to mandate and recommend certain
handling such as aspects of Neighbor Discovery, and the draft also extends
RFC6550 and RFC8505.

c. Is this type of RFC indicated in the title page header?
Rsp: Yes

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Shepherd response:
Technical Summary

    The document enables reachability for RPL unaware 6LoWPAN hosts through RPL
    network.  It provides routing services to 6LoWPAN Hosts by defining
    procedures for the Host to attach to a RPL aware node which in turn acts as
    point of transit for the Host.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Shepherd response:
This draft has been discussed in ROLL/6lo working group. The draft had an
impact on 6LoWPAN ND status field. The status field had to be resized to 6bits
from 8bits and this was conveyed to the 6lo working group and no objections
were raised.
With these reviews and discussions -15 is ready for IESG review.
My personal take as a shepherd/reviewer/WG participant is that the document
solves the problem it indicates to solve. I certainly believe there are
use-cases which will benefit from this work.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
Shepherd response: There are currently NO implementations.

  Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?
Shepherd response:
Multiple reviews were done by Rahul Jadhav (shepherd) which resulted in 4
updates to this draft.

If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
Shepherd response: Not Applicable

Personnel

Document Shepherd: Rahul Jadhav
Responsible Area Director: Alvaro Retana

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
Shepherd response:
I have reviewed the document and my comments were addressed in version -15 that I
think is ready for IESG review.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
Shepherd response: No concerns. I certainly believe that the document solves
the problem it indicates to solve. It is now possible for 6LNs not supporting
RPL to participate in the network using RPL mesh as a transit.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
Shepherd response:
The document updates RFC8505 standardized in 6lo working group. ROLL chairs had
made a review-request on 6lo ML. No reviews were received from 6lo however 6lo
chairs had specifically replied positively about the ARO status value field
resize. 6lo AD had also FYIed IoT-Directorate for the changes and no objections
were raised.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
Shepherd response: No concerns

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Shepherd response: All the authors have confirmed. There are no IPRs
disclosures in the context.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
Shepherd response: Yes, all the authors have explicitly made a disclosure.
There are no IPRs on the draft.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
Shepherd response: Strong concurrence of few individuals with others being
silent, is the state I see.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
Shepherd response: No discontent raised by anyone.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
Shepherd response: The idnits tools showed 1 warning and 2 comments.
    == Outdated reference: A later version (-18) exists of
        draft-ietf-roll-efficient-npdao-17
    [Shepherd rsp: Not a problem]

Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--).

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
Shepherd response: Not Applicable

(13) Have all references within this document been identified as
either normative or informative?
Shepherd response: Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
Shepherd response: None

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
Shepherd response: None

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
Shepherd response: 6550, 8505 will be updated and are mentioned in title page
header.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
Shepherd response: All the IANA considerations are appropriately handled.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
Shepherd response: All the impacted registries are within 6lo and ROLL WG. 6lo
working group was consulted about the change and the 6lo chair (Carles)
indicated the support.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
Shepherd response: Not applicable as there are no formal language constructs in
the document.