Re: [Roll] capability vs. configuration

[Abdussalam Baryun <[e-mail]>]

On Fri, May 24, 2019 at 3:01 PM Pascal Thubert (pthubert) <
[e-mail]> wrote:

> Dear all
>
> *   As you know, we have a configuration option in standard RPL. It is
> used by useofrplinfo to trigger the use of option x23 and by
> https://tools.ietf.org/html/draft-thubert-roll-turnon-rfc8138-00
> <https://tools.ietf.org/html/draft-thubert-roll-turnon-rfc8138-00> to
> trigger the use of RFC 8138 compression.   This must not be confused with
> the capability draft in draft-rahul-roll-mop-ext which is how the nodes and
> the root share on what capabilities they have. A configuration is a flat
> order from the root, the capability is an exchange of information.*
>

they need to be dealt/considered in different ways.

*   In order to decide whether  it can safely set the config flags, it
> would be good that the root knows about the node capabilities such as route
> projection, RFC 8138 compression and option x23 for RPI. So I thought that
> the node could expose that capability using mop-ext and we add the bits in
> the draft already.*
>

route projection is not a capability and must not be one.


> *   For route projection, we could include a number of routes that the
> node can store, using a number like 10 hops max for non-storing PDAOs.*
>

don't agree because we need to separate projection from storage.


> *   Wat do you think?*
>

I don't think this route projection is important for RPL, however it can be
an option to be used for configurations.

AB