Re: [Roll] Published draft-ietf-roll-unaware-leaves-03

["Pascal Thubert (pthubert)" <[e-mail]>]

If we decide to keep useofrplinfo on its current track and shape then this doc will update it.
I'd like you to write the update section, similar to that for RFC 6550 or RFC 8505.
Peter indicated that we should block useofrplinfo to update it. What do you think?

We also need a way for the root to declare that it can proxy DAO into EDAR. That could be a bit in the 6CIO (RFC 7400, already used a lot in RFC 8505) or a RPL specific thingy. You seemed to prefer RPL specific. Then it would be a capability from the root to all.
As a corollary we need to express whether the ROVR in DAO is used in the network. It is designed to be backwards compatible. Arguably some nodes could do it an others not, so we have to signal whether the root says nothing (legacy), SHOULD use it, or MUST use it else go away.
Note that RFC 6551 has already thought about those things:

P8:

   o  'C' flag.  When set, this indicates that the Routing Metric/
      Constraint object refers to a routing constraint.  When cleared,
      the routing object refers to a routing metric.

   o  'O' flag: The 'O' flag is used exclusively for routing constraints
      ('C' flag is set).  When set, this indicates that the constraint
      specified in the body of the object is optional.  When cleared,
      the constraint is mandatory.  If the 'C' flag is zero, the 'O'
      flag MUST be set to zero on transmission and ignored on reception.


P11:


3.1.  Node State and Attribute Object

   The Node State and Attribute (NSA) object is used to provide
   information on node characteristics.




All the best,

Pascal

> -----Original Message-----
> From: Roll <[e-mail]> On Behalf Of Michael Richardson
> Sent: lundi 2 septembre 2019 19:31
> To: Routing Over Low power and Lossy networks <[e-mail]>
> Subject: Re: [Roll] Published draft-ietf-roll-unaware-leaves-03
> 
> 
> Pascal Thubert (pthubert) <[e-mail]> wrote:
>     >>> *   Signal the capability by the root to proxy the EDAR in behalf of
>     >>> the 6LR. Should we use the MOP draft or make it protocol independent
>     >>> with 6CIO so any routing protocol could be used to proxy?
>     >>
>     >> I think we should use the root-announced (non-negotiated) capability.
>     >>
> 
>     > Works for me
> 
>     >>> *   Impact on useofrplinfo: the change that the (E flag) =>
>     >>> (non-storing signaling + tunnel to the 6LR)
>     >>
>     >> ....
>     >>
>     >>> Since those specs are not published yet, we could piggy-back the
>     >>> changes there but that means taking the drafts off the RFC editor's
>     >>> hands.
>     >>
>     >> I think that the useofrplinfo change affects only two (maybe) four of the
> 24
>     >> cases, and the case remains where we have an IPv6 Host only.
>     >> So I think it is better to Updates: useofrplinfo.
>     >>
> 
>     > Would you take the pen for this and the root capability? I’m looking at
>     > the mop draft in parallel
> 
> To clarify:
> My job is to document a capability (using mopex mechanism), in the
> unaware-leaves document so that the root can announce that it can
> process/proxy the EDAR.
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
>