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

[Alvaro Retana <[e-mail]>]

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

>
> Alvaro Retana 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.
>
> > [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.]
>
> 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.

Right.  I now understand the intent/requirements.


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

s/does/does not


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

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.