[Roll] Iotdir last call review of draft-ietf-roll-unaware-leaves-13

[Shwetha Bhandari via Datatracker <[e-mail]>]

Reviewer: Shwetha Bhandari
Review result: Ready with Nits

This specification extends RFC6550 and RFC8505 to provide routing services to
Hosts called RPL Unaware Leaves that implement 6LoWPAN ND but do not
participate to RPL. This specification also enables the RPL Root to proxy the
6LoWPAN keep-alive flows in its DODAG. This draft is well written and covers
the updates to 6550 and 8505 along with detailed rules for behavior of 6LN
acting as a RPL Unaware Leaf(RUL), was 6LR, 6LBR and DODAG root to support
unicast and multicast routing of packets to and from RUL.

Some nits/comments/questions follow:

1. "The new "P" flag is defined only for MOP value between 0 to 6. "he new "P"
flag is defined only for MOP value between 0 to 6.  For a MOP value of 7 or
above, the flag MAY indicate something different and MUST NOT be interpreted as
"Root Proxies  EDAR/EDAC" unless the MOP specifies it : Given that currently on
0 - 5 MOP are specified and should this be changed to  MOP 6 and above P flag
may indicate according to a future specification? 2.  Resizing of fields and
changes to existing IANA registries :
      2.1: Resizing the ARO Status values - The proposed update seems file
      considering the 53 ARO status values that would still be available. There
      appear to be no backward compatibility issues either.
       2.2: Section12.3. RPL Target Option Flags - This specification reduces
       the field to 4 bits. - This looks fine as there are no flags defined
       since RFC 6550 created the flags registry for target options.
3. Towards the end of Section 9.2.1 the specification mentions a RUL that is
RPL minimal awareness, this is a bit under specified - "A RUL is not expected
to produce RPL artifacts in the data packets,  but it MAY do so." -> is this
necessary? Why would an 6LN implementation be built with minimal awareness and
capability to build RPI? is there a benefit in doing this?. 4. IANA registry
for acceptance and rejection status values - Section 12.4 and 12.5: Only
reserve 0 Unqualified rejection/acceptable. However Section 7 specifies copying
ARO status into the field where in acceptance/rejection status: "When building
a DCO or a DAO-ACK message upon an IPv6 ND NA or a DAC message, the RPL Root
MUST copy the ARO Status unchanged in a RPL Status with the 'A' bit set. The
RPL Root MUST set the 'E' flag for all values in range 1-10 which are all
considered rejections" - Shouldn't the registry account for existing ARO status
codes in the rejection registry? - ARO status is a 8 bit field  while RPL
status has only 6 bits. While currently there are only 10 status codes defined
for ARO, however in future MUST copy may truncate the top 2 bits of the field.