Re: [Roll] AD Review of draft-ietf-roll-efficient-npdao-16

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

.
> >
> > It cannot be a convergence because RPL had rules in
> > https://tools.ietf.org/html/rfc6550#section-6.5.1 whereby the status
> > below
> > 128 are warning.
> > That provision was not really used so far to my best knowledge. So we
> > could drop it. We chose not to so far. Could be done though if that's
> > your recommendation.
> 
> I think that would be a lot clearer...but that is a decision that the WG needs to
> make.
> 
> 


Maybe we could restructure the RPL Status with the first 2 bits becoming significant as opposed to the first bit only.

Today:

Bit 0 set  => error
Bits 1->7 => status code

Proposed change:

Bit 0 set  => means error ( 0 is warning or OK)
Bit 1 set  => transporting ARO status (refers to RFC 8505 and updates for definition off the next status)
Bits 2->7 => status code | ARO status depending on bit 1

> 
> > > (2) draft-ietf-roll-unaware-leaves doesn't update the allocation
> > > guidelines from rfc6550 (§6.5.1) for the Status, which then lands
> > > "moved" in the "Rejection" range. IOW, the meaning is changed, but
> > > the original meaning of the DAO-ACK Status is not updated...
> > >
> > > [We are not reviewing draft-ietf-roll-unaware-leaves here, so some
> > > of these comments can be saved for later. ;-)]
> >
> > I see: we need to indicate that we update/extend the semantics of a
> > the DAO-ACK status.
> > Should that be indicated in npdao draft or in unaware leaves, where
> > the IANA is done for all?
> 
> If the IANA update is to be done in draft-ietf-roll-unaware-leaves, then there
> (that is part of the reason for the Normative dependence below).


I'm good with that. Considering the stage of this doc, I'd rather not change it too much and do the above in the RUL draft.
We can complete the RUL draft quite quickly now,  and ship this useofrplinfo and RUL together.
 
> 
> > > Needless to say, I don't like this approach.
> 
> To be clear, what I don't like is the fact that message that seem to be intended
> for different things (ND, DAO-ACK, DCO) share the same status
> information...and that it is not consistently corresponding (the same values
> don't mean the same things...)....so while homogenizing is a good thing, we
> seem to (currently) only go half way.
> 

This is really helpful, Alvaro.
I read the whole answer once before starting to answer and the proposal above is what I found to meet this and the below.


> > We are specifying it right now in Efficient-NPDAO. RFC 8505 was
> > forward looking to that respect. It had to indicate the ND status for
> > that case and that status is "moved".
> > - It means the guys was down there but is no more. Which is exactly
> > the topic of NPDAA, cleanup a downwards path that leads to a location
> > from which the target has moved away.
> > - But it could not discuss how RPL translates it back and forth. The
> > generic spec for that is unaware-leaves. DCO is a special case of
> > RC/status that matches "moved" in RFC 8505.
> 
> Ok...so this piece is also dependent on
> draft-ietf-roll-unaware-leaves.  I expect then clear pointers from draft-ietf-roll-
> efficient-npdao to it.
> 
> 

Certainly


> > The meaning we wanted to convey is that when propagating down the DCO,
> > the status from the parent MUST be repeated unchanged to the children.
> 
> Yes, I understand.
> 
> My question is from the Normative point of view.  The rfc2119 keywords
> "MUST only be used where it is actually required for interoperation".
> If informative, then we don't need "MUST NOT"...but if there is a behavior
> expectation (or as you wrote above: "be turned into ND again and in those cases
> the meaning must be conveyed unmodified"), then the required behavior
> should be able to be verified somehow...and, ideally, the specification should
> include an indication of what the behavior should be if the mandatory action is
> not met.  We can of course trust that nodes will follow the specification and will
> not change the contents of the status...
> 
> So..I would like to see a couple of things:
> 
> (1) A clear indication of whether specific behavior is expected (you have
> mentioned it twice in this thread, but the document doesn't reflect that) or not
> based on the status.

Will do

> 
> (2) Text (maybe in the security considerations) pointing out the effect of,
> changing the value in-flight, and how (if possible) to mitigate it.
 
Same here. Note that I do not have a mitigation in mind right now.


> 
> 
> > Suggestion to reword from the perspective of the intermediate router.
> >
> > > (2) If only values > 128 are expected, then what should a receiver
> > > do if a value < 128 is received? Should the DCO not be propagated further?
> >
> > Yes, the DCO should be propagated and as done today, it causes the
> > destruction of the path regardless of the value of the status, even a
> > warning <128.
> > Should we change that so a warning is propagated but the route is
> > conserved or something? There is no known usage of that today, does
> > that protect the future better?
> 
> Going back to the text, which reads: "Only Rejection Codes (values of
> 128 and above) are expected in a DCO."  Also, going back to your statements
> above about specific behavior resulting from the status value.  I just want to
> make sure the specification is clear related to what should be done; if any value
> is ok, then the text is, at minimum not clear...if the behavior depends on the
> value, then there's an effect if the value is not that is expected...
> 

That text goes away if you agree with the proposal of the additional bit in the RPL status. The new text would say that "the ARO status MUST be placed unchanged by the root" in the mapped DCO with the bit ARO set. Conversely that the "6LR MUST place the mapped ARO status in the NA(ARO) that is built upon the DCO". 

RPL already has text like "
                  The root of a DODAG is
   authoritative for setting that information and the information is
   unchanged as propagated down the DODAG.
"

We can emulate that form for the DCO, say that "The root or common parent that generates a DCO is authoritative for setting the status information and the information is unchanged as propagated down the DODAG. " The transported ARO status is just a case of that. We'd also say that "this spec does not specify a differentiated action based on the status."


> 
> I hope we're making progress.  If not, we might want to think about speaking
> live. :-)

We are. If you agree with the proposed line above I'll make editions and come back to you for more comments and/or approval.

This is all very much appreciated, Alvaro.

Pascal