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

[Alvaro Retana <[e-mail]>]

On October 8, 2020 at 3:26:36 PM, Pascal Thubert wrote:


Pascal:

Hi!


...
> I did not yet go to the end (went 2/3 down) but I need your advice about
> updating RFC 8505 at the end of the covered piece. So I thought I should
> send you the partial response as of now.

In this message I'm just commenting on what is related to updating
rfc8505.  I'll take a look at the rest later.


Thanks!

Alvaro.


...
> > 494 6. Updating RFC 8505
> >
> > [major] To me, Updating an RFC means that the implementations of that
> > RFC should also implement this one. In this case, there would be an
> > expectation that all 6LRs would support the change. Is that what is
> > intended?
> >
> > Note that Updating is different than simply expecting the nodes that
> > implement this specification to comply...in this case, *if* "the RPL
> > Root advertise[s] the capability...".
> >
> > [Personal opinion: rfc8505 applies to 6LRs in general, not just RPL
> > routers in particular...so I think that Updating it is not the right
> > choice.]
> >
>
> Whao, a difficult one. We update the RFC8505 behavior.
> But not to all type of node that implement RFC 8505. Only those that are
> RPL Routers.
> So what is the most important? That we change the operation of an RFC or
> that the change ios scoped to a subset of nodes?

IMO, the answer is to make the change that is necessary, and no more.


> I'm asking, not proposing and answer. The reason behind is that is another
> RFC updates RFC 8505 with a change that is not compatible, the fact that we
> did not update will make it harder to track.

Yes, this is where an "Extends" or at least "See Also" tag would be
great [1], but we don't have those.

OTOH, the reason we do so many reviews (WG, directorates, IETF LCs,
etc.) is to get also cross-area review.  This should catch
incompatible changes.  Yes, I realize this is the ideal situation, and
that a change like this may still be missed... :-(

The risk is then that the process doesn't work; i.e. that people don't
do good reviews. :-(


Having said all that, if you (the WG) want to change the behavior for
all the nodes, then we'll need positive confirmation from 6lo that
this is ok.  I seem to remember that there was already communication
with 6lo about the proposed changes, and there was no opposition.  I
can go find that thread again...

Given the text in this document (like the sentence below for example
-- and what you said above), it doesn't seem to me that making a
change for all the nodes (vs. just RPL routers) was the WGs intent.
So we'll have to confirm that as well.

Also, we'll probably need to generalize the specification to not be
specific to RPL.  But with any RPL-specific normative behavior
highlighted.


What do you want to do?


[1] https://tools.ietf.org/html/draft-kuehlewind-update-tag


> > 496 This document updates [RFC8505] to change the behavior of a RPL
> > 497 Router acting as 6LR in the 6LoWPAN ND Address Registration of a
> > RUL
> > 498 acting as 6LN. If the RPL Root advertise the capability to proxy the
> > 499 EDAR/EDAC exchange to the 6LBR, the 6LR refrains from sending the
> > 500 keep-alive EDAR message. Instead, if it is separated from the 6LBR,
> > 501 the Root regenerates the EDAR message to the 6LBR periodically,
> > upon
> > 502 a DAO message that signals the liveliness of the Address.





...
> 12.2. Resizing the ARO Status values
...
> > [major] Changing the range of values is not as easy as updating the
> > registry...the behavior of the EARO and ARO have to be updated. This
> > means that this document should Update both rfc6775 and rfc8505 where
> > it relates to the redefined Status field.
>
> Isn't this transitive? I mean the field defined in RFC 6775 is updated by
> RFC 8505.

No.  As far as I understand it, rfc8505 didn't change the behavior of
the ARO, it extended it.  In fact, the changes are backward
compatible, which tell me that the ARO (independent of an EARO) is
still valid and expected to work.  I would be happy to be corrected.

It may be that no one cares about changes to the ARO anymore...but
that is a different conversation.  And updating only the EARO seems to
break the backward compatibility.


> Maybe the 6lo group should clarify that the ARO is deprecated somehow?

That would be nice...but that is not what rfc8505 says.