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

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

Hello Alvaro


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

I'll be rewording the other mail to adapt to your answers therein. Please do not reply more to this, and expect the complete reforged email very soon.

Take care,

Pascal

> -----Original Message-----
> From: Alvaro Retana <[e-mail]>
> Sent: jeudi 8 octobre 2020 23:10
> To: Pascal Thubert (pthubert) <[e-mail]>; draft-ietf-roll-unaware-
> [e-mail]
> Cc: [e-mail]; Routing Over Low power and Lossy networks
> <[e-mail]>; Rahul Jadhav <[e-mail]>
> Subject: RE: AD Review of draft-ietf-roll-unaware-leaves-18
> 
> 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.