Subject: Re: [Roll] Making RUL draft normative reference in useofrplinfo

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 3 Nov 2019 14:34:17 +0000

I do not think we concluded on this and we need to publish tomorrow.

On the one hand, we need to add a definition of a leaf in useofrpl information as a node that is attached to a RPL DODAG and as an IPv6 node is expected to handle consumed RH and HbH so it can receive a packet that went though the RPL domain with consumed RPL artifacts. That is needed, we are missing the definition of a leaf today.

On the other hand, we need to decide if the definition of a RUL is 1) that in the useofrplinfo draft as it stands today in the repo https://raw.githubusercontent.com/roll-wg/useofrplinfo/master/roll-useofrplinfo.txt (a leaf that does not speak RPL) or 2) the one in the RUL draft today (adds support to talk to the router using RFC 8505). If we leave as is I’ll update the RUL draft to say that the RUM draft plays with RUL that supports that additional stuff.

  1.  Is simple, no reference to RUL draft is needed, can go to RFC quickly
  2.  Makes the RUl draft a normative reference, guarantees to keep the 2 specs homogeneous

I’m OK either way, cutoff is tomorrow. Any clue?

Pascal

From: Ines Robles <[email-masked]>
Sent: vendredi 25 octobre 2019 13:18
To: roll <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; Michael Richardson <[email-masked]>
Subject: Making RUL draft normative reference in useofrplinfo

Dear all,

Discussing with Pascal and Michael, we would like to know if you think that unaware-leaves draft should be normative in useofrplinfo.

Please find below some discussion points:

The RUL draft introduces a new beast to the RPL family, a “Leaf-that-does-not-speak-RFC-6550“ but can now attach to the network and benefit from special forwarding rules, provided that it implements the RUL draft and some dependencies listed therein. Use-Of-RPL-Info aligned to the WIP but there’s still a risk if it is published too soon that it is not 100% aligned. The misalignment we noted is mostly a terminology thing: is a RUL a “Leaf-that-does-not-speak-RFC-6550“, or should we carry additional meaning like support of the RUL draft and/or the dependencies.

The behavior for a RUL in Use-Of-RPL-Info world for the is correct but it could apply to a slightly wider definition of a RUL than what the RUL draft considers. E.g., a node that 1) does not implement the RUL draft and even RFC 8505, but 2) never moves (tethered to the router or embedded therein), could also attach to a RPL network provided that the router does a new set of things, like handles the sequence counter and  stuff, and there could be tons of variations of that guy e.g.,  whether that guy could provide an “opaque” RPL-aware RPLinstanceID though it does not speak RFC 6550. The description of the operation of a RUL in Use-Of-RPL-Info would work for that guy as well, but that operation is not defined. IOW that guy is does not (yet) belong to the RPL family, and will hopefully never do, because the original 6LoWPAN ND is obsoleted by RFC 8505, so why not just do that?

To maximize the coverage of Use-Of-RPL-Info, we should need to include that guy in the generic “RUL” definition. I’m not too interested in defining all the variations of “that guy” and even less to give a name to all the variations, and/or ensure that it could be doable to do RPL on their behalf based on new hypothetic features in the router. Personally I’m happy enough if the RUL that the Use-Of-RPL-Info describes has a scope that is reduced to nodes that obey the RUL draft, because they are the only ones for which we have a defined behavior in the router. Thus the proposal to make the RUL draft a normative reference and live a few months with a missref.

Changes were done in the RUL draft to ensure that the operation described for a RUL in Use-Of-RPL-Info is compatible with the new beast that the RUL draft considers, making the new beast a subset of the RUL considered by Use-Of-RPL-Info. Because when the doc became WG doc a RUL was any sort of external route. the doc made it more specific. The price to pay was to introduce a different behavior for the RUL and other “external destinations”. As the text was changed for other “external destinations” indicating e.g., the need to route via the parent and thus to use Non-Storing signaling.

Then that text was stripped off the RUL draft and placed it in the Use-Of-RPL-Info because it was really text on the forwarding behavior, which is different if some assumptions cannot be made on the external destination (need to encaps to the parent when it is not necessarily needed for a RUL). That new text also fills a gap in Use-Of-RPL-Info and is completely localized in a  new section. the  text was moved about routing from the RUL draft to that section. Since it is not published yet, please find that text inline below:

“

4.1. Updates to RFC6550: Advertise External Routes with Non-Storing

Mode Signaling.

Section 6.7.8. of [RFC6550] introduces the 'E' flag that is set to

indicate that the 6LR that generates the DAO redistributes external

targets into the RPL network. An external Target is a Target that

has been learned through an alternate protocol, for instance a route

to a prefix that is outside the RPL domain but reachable via a 6LR.

Being outside of the RPL domain, a node that is reached via an

external target cannot be guaranteed to ignore the RPL artifacts and

cannot be expected to process the [RFC8138] compression correctly.

This means that the RPL artifacts should be contained in an IP-in-IP

encapsulation that is removed by the 6LR, and that any remaining

compression should be expanded by the 6LR before it forwards a packet

outside the RPL domain.

This specification updates RPL [RFC6550] to RECOMMEND that external

targets are advertised using Non-Storing Mode signaling even in a

Storing-Mode network. This way, all packets to an external target

reach the Root that can encapsulate them, and the Root is informed of

the address of the 6LR that terminates the IP-in-IP tunnel. In case

of an external target, the Root SHOULD use the same IP-in-IP

encapsulation for packets that it generates or that are originated

within the RPL domain as if the packets were coming from the

Internet.

A RUL is a special case of external target when the target is

actually a host and it is known to support a consumed Routing Header

and to ignore a HbH header as prescribed by [RFC8200]. The target

may have been learned through as a host route or may have been

registered to the 6LR using [RFC8505]. IP-in-IP encapsulation MAY be

avoided for Root to RUL communication if the RUL is known to process

the packets as forwarded by the parent 6LR without decapsulation.

In order to enable IP-in-IP all the way to a 6LN, it is beneficial

that the 6LN supports decapsulating IP-in-IP, but that is not assumed

by [RFC8504]. If the 6LN is a RUL, the Root that encapsulates a

packet SHOULD terminate the tunnel at a parent 6LR unless it is aware

that the RUL supports IP-in-IP decapsulation.

A node that is reachable over an external route is not expected to

support [RFC8138]. Whether a decapsulation took place or not and

even when the 6LR is delivering the packet to a RUL, the 6LR that

injected an external route MUST uncompress the packet before

forwarding over that external route.
“

So where are we?

We need to agree on what we place in the definition of a RUL for which Use-Of-RPL-Info presents a special behavior. Do we limit to the ground common with the RUL draft for which there is a defined RPL behavior, or do we define a new different thing where Use-Of-RPL-Info handles an unclear superset of the nodes that support the RUL draft and for which there is a defined RPL operation? I do not see the need because if (ever, though doubtful) a new draft defines the RPL operation for one version of “that guy” then is can also say whether “that guy” should be handled as a RUL or as an “external destination” in Use-Of-RPL-Info.

Thus the proposal to that that the operation of a “RUL” in Use-Of-RPL-Info is for a node that supports the RUL draft, and make the RUL draft a normative reference to define what that exactly mean. If we do so, MISSREF will play its guardian role to ensure that Use-Of-RPL-Info is consistent with the RUL draft till the last minute because it is not published too hastly.

Looking forward to your reactions,

Ines, Pascal and Michael.

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 4 Nov 2019 10:04:50 +0200

On Sun, Nov 3, 2019 at 4:34 PM Pascal Thubert (pthubert) <[email-masked]>
wrote:

> *   On the one hand, we need to add a definition of a leaf in useofrpl
> information as a node that is attached to a RPL DODAG and as an IPv6 node
> is expected to handle consumed RH and HbH so it can receive a packet that
> went though the RPL domain with consumed RPL artifacts. That is needed, we
> are missing the definition of a leaf today.   On the other hand, we need to
> decide if the definition of a RUL is 1) that in the useofrplinfo draft as
> it stands today in the repo
> https://raw.githubusercontent.com/roll-wg/useofrplinfo/master/roll-useofrplinfo.txt
> <https://raw.githubusercontent.com/roll-wg/useofrplinfo/master/roll-useofrplinfo.txt>
> (a leaf that does not speak RPL) or 2) the one in the RUL draft today (adds
> support to talk to the router using RFC 8505). If we leave as is I’ll
> update the RUL draft to say that the RUM draft plays with RUL that supports
> that additional stuff.   1. Is simple, no reference to RUL draft is needed,
> can go to RFC quickly2. Makes the RUl draft a normative reference,
> guarantees to keep the 2 specs homogeneous   I’m OK either way, cutoff is
> tomorrow. Any clue?*
>

I prefer (1), but me too, I'm OK either way,

Thanks
AB

>
>
>
>
>
>
> *   From: Ines Robles <[email-masked]
> <[email-masked]>> Sent: vendredi 25 octobre 2019 13:18 To:
> roll <[email-masked] <[email-masked]>> Cc: Pascal Thubert (pthubert)
> <[email-masked] <[email-masked]>>; Michael Richardson
> <[email-masked] <[email-masked]>> Subject: Making RUL draft
> normative reference in useofrplinfo   Dear all,   Discussing with Pascal
> and Michael, we would like to know if you think that unaware-leaves draft
> should be normative in useofrplinfo.   Please find below some discussion
> points:    The RUL draft introduces a new beast to the RPL family, a
> “Leaf-that-does-not-speak-RFC-6550“ but can now attach to the network and
> benefit from special forwarding rules, provided that it implements the RUL
> draft and some dependencies listed therein. Use-Of-RPL-Info aligned to the
> WIP but there’s still a risk if it is published too soon that it is not
> 100% aligned. The misalignment we noted is mostly a terminology thing: is a
> RUL a “Leaf-that-does-not-speak-RFC-6550“, or should we carry additional
> meaning like support of the RUL draft and/or the dependencies.   The
> behavior for a RUL in Use-Of-RPL-Info world for the is correct but it could
> apply to a slightly wider definition of a RUL than what the RUL draft
> considers. E.g., a node that 1) does not implement the RUL draft and even
> RFC 8505, but 2) never moves (tethered to the router or embedded therein),
> could also attach to a RPL network provided that the router does a new set
> of things, like handles the sequence counter and  stuff, and there could be
> tons of variations of that guy e.g.,  whether that guy could provide an
> “opaque” RPL-aware RPLinstanceID though it does not speak RFC 6550. The
> description of the operation of a RUL in Use-Of-RPL-Info would work for
> that guy as well, but that operation is not defined. IOW that guy is does
> not (yet) belong to the RPL family, and will hopefully never do, because
> the original 6LoWPAN ND is obsoleted by RFC 8505, so why not just do that?
>   To maximize the coverage of Use-Of-RPL-Info, we should need to include
> that guy in the generic “RUL” definition. I’m not too interested in
> defining all the variations of “that guy” and even less to give a name to
> all the variations, and/or ensure that it could be doable to do RPL on
> their behalf based on new hypothetic features in the router. Personally I’m
> happy enough if the RUL that the Use-Of-RPL-Info describes has a scope that
> is reduced to nodes that obey the RUL draft, because they are the only ones
> for which we have a defined behavior in the router. Thus the proposal to
> make the RUL draft a normative reference and live a few months with a
> missref.   Changes were done in the RUL draft to ensure that the operation
> described for a RUL in Use-Of-RPL-Info is compatible with the new beast
> that the RUL draft considers, making the new beast a subset of the RUL
> considered by Use-Of-RPL-Info. Because when the doc became WG doc a RUL was
> any sort of external route. the doc made it more specific. The price to pay
> was to introduce a different behavior for the RUL and other “external
> destinations”. As the text was changed for other “external destinations”
> indicating e.g., the need to route via the parent and thus to use
> Non-Storing signaling.   Then that text was stripped off the RUL draft and
> placed it in the Use-Of-RPL-Info because it was really text on the
> forwarding behavior, which is different if some assumptions cannot be made
> on the external destination (need to encaps to the parent when it is not
> necessarily needed for a RUL). That new text also fills a gap in
> Use-Of-RPL-Info and is completely localized in a  new section. the  text
> was moved about routing from the RUL draft to that section. Since it is not
> published yet, please find that text inline below:   “   4.1. Updates to
> RFC6550: Advertise External Routes with Non-Storing   Mode Signaling.
> targets into the RPL network. An external Target is a Target that   has
> been learned through an alternate protocol, for instance a route   to a
> prefix that is outside the RPL domain but reachable via a 6LR.   Being
> outside of the RPL domain, a node that is reached via an   external target
> cannot be guaranteed to ignore the RPL artifacts and   cannot be expected
> to process the [RFC8138] compression correctly.   This means that the RPL
> artifacts should be contained in an IP-in-IP   encapsulation that is
> removed by the 6LR, and that any remaining   compression should be expanded
> by the 6LR before it forwards a packet   outside the RPL domain.     This
> specification updates RPL [RFC6550] to RECOMMEND that external   targets
> are advertised using Non-Storing Mode signaling even in a   Storing-Mode
> network. This way, all packets to an external target   reach the Root that
> can encapsulate them, and the Root is informed of   the address of the 6LR
> that terminates the IP-in-IP tunnel. In case   of an external target, the
> Root SHOULD use the same IP-in-IP   encapsulation for packets that it
> generates or that are originated   within the RPL domain as if the packets
> were coming from the   Internet.     A RUL is a special case of external
> target when the target is   actually a host and it is known to support a
> consumed Routing Header   and to ignore a HbH header as prescribed by
> [RFC8200]. The target   may have been learned through as a host route or
> may have been   registered to the 6LR using [RFC8505]. IP-in-IP
> encapsulation MAY be   avoided for Root to RUL communication if the RUL is
> known to process   the packets as forwarded by the parent 6LR without
> decapsulation.     In order to enable IP-in-IP all the way to a 6LN, it is
> beneficial   that the 6LN supports decapsulating IP-in-IP, but that is not
> assumed   by [RFC8504]. If the 6LN is a RUL, the Root that encapsulates a
> that the RUL supports IP-in-IP decapsulation.     A node that is reachable
> over an external route is not expected to   support [RFC8138]. Whether a
> decapsulation took place or not and   even when the 6LR is delivering the
> packet to a RUL, the 6LR that   injected an external route MUST uncompress
> the packet before   forwarding over that external route. “   So where are
> we?   We need to agree on what we place in the definition of a RUL for
> which Use-Of-RPL-Info presents a special behavior. Do we limit to the
> ground common with the RUL draft for which there is a defined RPL behavior,
> or do we define a new different thing where Use-Of-RPL-Info handles an
> unclear superset of the nodes that support the RUL draft and for which
> there is a defined RPL operation? I do not see the need because if (ever,
> though doubtful) a new draft defines the RPL operation for one version of
> “that guy” then is can also say whether “that guy” should be handled as a
> RUL or as an “external destination” in Use-Of-RPL-Info.   Thus the proposal
> to that that the operation of a “RUL” in Use-Of-RPL-Info is for a node that
> supports the RUL draft, and make the RUL draft a normative reference to
> define what that exactly mean. If we do so, MISSREF will play its guardian
> role to ensure that Use-Of-RPL-Info is consistent with the RUL draft till
> the last minute because it is not published too hastly.   Looking forward
> to your reactions,   Ines, Pascal and Michael.           *
>
>
>
>
> * _______________________________________________ Roll mailing list
> [email-masked] <[email-masked]> https://www.ietf.org/mailman/listinfo/roll
> <https://www.ietf.org/mailman/listinfo/roll> *

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 4 Nov 2019 10:23:52 +0000

Well noted though a technical reason has more weight than a preference.

Editors: I made a pull request to define the Leaf.

The draft already has text like

“
                                                               Further details about
   this are mentioned in [I-D.thubert-roll-unaware-leaves], which
   specifies RPL routing for a 6LN acting as a plain host and not being
   aware of RPL.
“

This is very close to make the RUL draft a normative ref anyway. We need to change the name to draft-ietf by the way.

Is we ship UseOfRPLinfo without the Normative ref to the RUL draft, this makes it the draft the place where the term RUL is defined.

I need slight changes to the RUL draft to adapt to that and I’d like to be done either before cutoff so we can present to the group at IETF 106.

Please let me know!

Pascal

From: Roll <[email-masked]> On Behalf Of Abdussalam Baryun
Sent: lundi 4 novembre 2019 09:05
To: Routing Over Low power and Lossy networks <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Ines Robles <[email-masked]>
Subject: Re: [Roll] Making RUL draft normative reference in useofrplinfo

On Sun, Nov 3, 2019 at 4:34 PM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
I do not think we concluded on this and we need to publish tomorrow.

On the one hand, we need to add a definition of a leaf in useofrpl information as a node that is attached to a RPL DODAG and as an IPv6 node is expected to handle consumed RH and HbH so it can receive a packet that went though the RPL domain with consumed RPL artifacts. That is needed, we are missing the definition of a leaf today..

Thanks
AB

From: Ines Robles <[email-masked]<mailto:[email-masked]>>
Sent: vendredi 25 octobre 2019 13:18
To: roll <[email-masked]<mailto:[email-masked]>>
Cc: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; Michael Richardson <[email-masked]<mailto:[email-masked]>>
Subject: Making RUL draft normative reference in useofrplinfo

Dear all,

“

Mode Signaling.

outside the RPL domain.

Internet.

So where are we?

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

---

From: Ines Robles <[email-masked]>
Date: Mon, 4 Nov 2019 16:51:20 +0200

Thank you Pascal for adding the terminology clarification.

Then, following my understanding when you say a "RPL Leaf" it is a node
that do not necessarily implement RPL. It is just a node that is attached
to the DODAG (with the features that you mentioned below).
If I refer to a RPL Leaf that implements RPL I should call it,
RPL-aware-leaf, otherwise is a RPL-unaware-leaf. Is this correct?

Thanks,
Ines.

On Mon, Nov 4, 2019 at 12:24 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

>                                                                Further
> details about
> This is very close to make the RUL draft a normative ref anyway. We need
> to change the name to draft-ietf by the way.
>
>
>
> Is we ship UseOfRPLinfo without the Normative ref to the RUL draft, this
> makes it the draft the place where the term RUL is defined.
>
>
>
> I need slight changes to the RUL draft to adapt to that and I’d like to be
> done either before cutoff so we can present to the group at IETF 106.
>
>
>
> Please let me know!
>
>
>
> Pascal
>
>
>
> *From:* Roll <[email-masked]> *On Behalf Of *Abdussalam Baryun
> *Sent:* lundi 4 novembre 2019 09:05
> *To:* Routing Over Low power and Lossy networks <[email-masked]>
> *Cc:* Michael Richardson <[email-masked]>; Ines Robles <
> [email-masked]>
> *Subject:* Re: [Roll] Making RUL draft normative reference in useofrplinfo
>
>
>
>
>
>
>
> On Sun, Nov 3, 2019 at 4:34 PM Pascal Thubert (pthubert) <
> [email-masked]> wrote:
>
> *On the one hand, we need to add a definition of a leaf in useofrpl
> are missing the definition of a leaf today..*
>
>
>
> *On the other hand, we need to decide if the definition of a RUL is 1)
> that in the useofrplinfo draft as it stands today in the repo
> that additional stuff. *
>    1. *Is simple, no reference to RUL draft is needed, can go to RFC
>    quickly*
>    2. *Makes the RUl draft a normative reference, guarantees to keep the
>    2 specs homogeneous*
>
>
>
> *I’m OK either way, cutoff is tomorrow. Any clue?*
>
>
>
> *From:*
> * Ines Robles <[email-masked]
> normative reference in useofrplinfo*
>
>
>
> *Dear all,*
>
>
>
> *Discussing with Pascal and Michael, we would like to know if you think
> that unaware-leaves draft should be normative in useofrplinfo.*
>
>
>
> *Please find below some discussion points: *
>
>
>
> *The RUL draft introduces a new beast to the RPL family, a
> meaning like support of the RUL draft and/or the dependencies.*
>
>
>
> *The behavior for a RUL in Use-Of-RPL-Info world for the is correct but it
> could apply to a slightly wider definition of a RUL than what the RUL draft
> the original 6LoWPAN ND is obsoleted by RFC 8505, so why not just do that?*
>
>
>
> *To maximize the coverage of Use-Of-RPL-Info, we should need to include
> missref.*
> *Changes were done in the RUL draft to ensure that the operation described
> for a RUL in Use-Of-RPL-Info is compatible with the new beast that the RUL
> draft considers, making the new beast a subset of the RUL considered by
> Use-Of-RPL-Info. Because when the doc became WG doc a RUL was any sort of
> external route. the doc made it more specific. The price to pay was to
> introduce a different behavior for the RUL and other “external
> Non-Storing signaling.*
> *Then that text was stripped off the RUL draft and placed it in the
> Use-Of-RPL-Info because it was really text on the forwarding behavior,
> which is different if some assumptions cannot be made on the external
> destination (need to encaps to the parent when it is not necessarily needed
> for a RUL). That new text also fills a gap in Use-Of-RPL-Info and is
> completely localized in a  new section. the  text was moved about routing
> from the RUL draft to that section. Since it is not published yet, please
> find that text inline below:*
>
>
>
> *“*
>
>
>
> *“*
> *So where are we?*
> *We need to agree on what we place in the definition of a RUL for
> RUL or as an “external destination” in Use-Of-RPL-Info.*
>
>
>
> *Thus the proposal to that that the operation of a “RUL” in
> Use-Of-RPL-Info is for a node that supports the RUL draft, and make the RUL
> draft a normative reference to define what that exactly mean. If we do so,
> MISSREF will play its guardian role to ensure that Use-Of-RPL-Info is
> consistent with the RUL draft till the last minute because it is not
> published too hastly.*
>
>
>
> *Looking forward to your reactions,*
>
>
>
> *Ines, Pascal and Michael.*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *_______________________________________________ Roll mailing list
> <https://www.ietf.org/mailman/listinfo/roll>*
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 4 Nov 2019 16:33:39 +0000

Yes, Ines

RPL awareness and the position of leaf are now orthogonal properties. A RAL has both.

Can you please publish? I think cutoff is on us now.

All the best

Pascal

From: Ines Robles <[email-masked]>
Sent: lundi 4 novembre 2019 15:51
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Routing Over Low power and Lossy networks <[email-masked]>; Michael Richardson <[email-masked]>
Subject: Re: [Roll] Making RUL draft normative reference in useofrplinfo

Then, following my understanding when you say a "RPL Leaf" it is a node that do not necessarily implement RPL. It is just a node that is attached to the DODAG (with the features that you mentioned below).
If I refer to a RPL Leaf that implements RPL I should call it, RPL-aware-leaf, otherwise is a RPL-unaware-leaf. Is this correct?

Thanks,
Ines.

On Mon, Nov 4, 2019 at 12:24 PM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Well noted though a technical reason has more weight than a preference.

“
                                                               Further details about

Please let me know!

Pascal

From: Roll <[email-masked]<mailto:[email-masked]>> On Behalf Of Abdussalam Baryun
Sent: lundi 4 novembre 2019 09:05
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Cc: Michael Richardson <[email-masked]<mailto:[email-masked]>>; Ines Robles <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Roll] Making RUL draft normative reference in useofrplinfo

Thanks
AB

Dear all,

“

Mode Signaling.

outside the RPL domain.

Internet.

So where are we?

---

From: Ines Robles <[email-masked]>
Date: Mon, 4 Nov 2019 20:28:54 +0200

Thank you Pascal :)

Dear all, new version was updated including:

- Terminology clarifications

- New Section on Updates to RFC6550: Advertise External Routes with Non-
Storing Mode Signaling

- Assumptions Lists updated

- Uses cases in SM related with RUL as dst updated.

Please review and comments.

Much appreciated,

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-32
https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-32

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-32

Ines.

On Mon, Nov 4, 2019 at 6:34 PM Pascal Thubert (pthubert) <[email-masked]>
wrote:

> *From:* Ines Robles <[email-masked]>
> *Sent:* lundi 4 novembre 2019 15:51
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* Routing Over Low power and Lossy networks <[email-masked]>; Michael
> Richardson <[email-masked]>