Review request
draft-ietf-roll-useofrplinfo

After passing IESG review, this draft was pulled from RFC Editor queue in July 2019 (rev -31) for rework due to new developments.
It hadn't gotten an IOT Dir review at the time, and we would love to have an expert review focussing on the following points.
Thanks a lot! Ines & Dominique
====
Among the non-editorial changes, the most significant ones are related to better handling of RPL-unaware leaf nodes (RUL).
This specification is now explicit that the RULs are not expected to do IPv6-in-IPv6. They are expected to know to ignore the IPv6 RPL Option (RPI) and ignore consumed source routing headers (RH3).
RULs are now handled by a RPL mesh the same way as external destinations. Routes to them are not injected in the routers of the RPL mesh, even when it operates in storing mode, but only into the root. Packets destined to RULs are sent via the default route to the root, which knows which RPL router advertised the RUL as a destination. The root can therefore encapsulate the packet with IP-in-IP and send it through the RPL mesh to that RPL router, which decapsulates the packet and sends it to the RUL. 
Compared to -31, the hop-by-hop encapsulation/decapsulation within the RPL mesh is no longer used.
Another non-editorial change opens up a new possibility for a RPL-aware leaf node (RAL) when it sends a packet outside the RPL mesh or to a RUL. The RAL can now also encapsulate the packet in IP-in-IP and send it to the root, or not encapsulate as with -31. With the former option, the packet is bigger while it progresses through the RPL mesh, but smaller as it leaves the RPL mesh since the RPL options are stripped at decapsulation. With the latter option, the packet is smaller while transiting through the RPL mesh, but RPL options are still tagged as it leaves the RPL mesh en route to the external destination.
A change log is available at https://github.com/roll-wg/useofrplinfo/blob/master/ChangeLog.