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

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

There was a typo, the proposed text in section 7 reads:

   RPL Status subfields:

   E:  1-bit flag.  Set to indicate a rejection.  When not set, a value
      of 0 indicates success and other values indicate an non-outright-
      rejection as per RFC 6550.

   A:  1-bit flag.  Indicates the type of the status value.

   Status Value:  6-bit unsigned integer.  If the 'A' flag is set this
      field transports a status value defined for IPv6 ND EARO.  When
      the 'A' flag is reset, the status value is defined in a RPL
      extension.


Voila!

Pascal
> -----Original Message-----
> From: Pascal Thubert (pthubert) <[e-mail]>
> Sent: mardi 29 octobre 2019 18:22
> To: Alvaro Retana <[e-mail]>; draft-ietf-roll-efficient-
> [e-mail]
> Cc: [e-mail]; roll <[e-mail]>; Peter van der Stok
> <[e-mail]>
> Subject: RE: AD Review of draft-ietf-roll-efficient-npdao-16
> 
> Dear all
> 
> More on the proposal below:
> 
> The proposal is to place more details in the RPL status in the RUL draft and
> make it a normative ref to efficient NPDAO.
> 
> Changes in the efficient NPDAO draft:
> ====================
> 
> - Make the RUL draft a normative reference
> 
> - new description of the status:
> "
>    RPL Status: As defined in [RFC6550] and updated in
>    [I-D.ietf-roll-unaware-leaves].  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.  This
>    document does not specify a differentiated action based on the RPL
>    status.
> "
> 
> 
> 
> Changes in the RUL draft:
> ====================
> 
> - In 4.  Updating RFC 6550, add:
> 
> "
>    The RPL Status defined in section 6.5.1. of [RFC6550] for use in the
>    DAO-Ack message is extended to be used in the DCO messages
>    [EFFICIENT-NPDAO] as well.  Furthermore, this specification enables
>    to use a RPL status to transport the IPv6 ND status defined for use
>    in the EARO, more in Section 7.
> "
> 
> - Create a section 7 as:
> 
> "
> 7.  Updated RPL Status
> 
>    The RPL Status is defined in section 6.5.1. of [RFC6550] for use in
>    the DAO-Ack message and values are assigned as follows:
> 
>                   +---------+---------------------------+
>                   | Range   | Meaning                   |
>                   +=========+===========================+
>                   | 0       | RFC 6550                  |
>                   +---------+---------------------------+
>                   | 1-127   | Not an outright rejection |
>                   +---------+---------------------------+
>                   | 128-255 | Rejection                 |
>                   +---------+---------------------------+
> 
>                       Table 1: RPL Status per RFC 6550
> 
>    This specification extends the scope of the RPL status to be used in
>    RPL DCO messages.  Furthermore, this specification enables to carry
>    the status values defined for use in the IPv6 ND Extended Address
>    Registration Option (EARO) and listed in table 1 of [RFC8505].  Only
>    EARO status values in the range 0-63 can be transported.  The
>    resulting RPL status is as follows:
> 
>        0
>        0 1 2 3 4 5 6 7
>       +-+-+-+-+-+-+-+-+
>       |E|A|  Value    |
>       +-+-+-+-+-+-+-+-+
> 
>    RPL Status subfields:
> 
>    E:  1-bit flag.  Set to indicate a rejection.  When not set, A value
>       of 0 indicates success.  Other values are non-rejection as per RFC
>       6550.
> 
>    A:  1-bit flag.  Set to indicate the type of the status value.
> 
>    Value:  6-bit unsigned integer.  If the 'E' flag is set this field
>       transports a status value defined for IPv6 ND EARO.  When the 'E'
>       flag is reset, the status value is defined in a RPL extension
> 
>    When building a DCO message upon an IPv6 ND NA or DAC message, the
>    root MUST place the ARO status unchanged in a mapped DCO with the 'A'
>    bit set.  Conversely the 6LR MUST place the ARO status unchanged in
>    the NA(EARO) that is built upon a DCO with the 'A' bit set.
> 
> "
> 
> - Remove section 12.2 since we do not create new status values, we now
> transport the ARO status as defined by ND.
> 
> - Instead, create the missing registries that RFC 6550 did not as "
> 
> 13.2.  New Subregistry for the RPL Non-Rejection Status values
> 
>    This specification creates a new subregistry for the RPL Non-
>    Rejection Status values for use in RPL DAO-ACK and RCO Messages,
>    under the ICMPv6 parameters registry.
> 
>    *  Possible values are 6-bit unsigned integers (0..63).
> 
>    *  Registration procedure is "Standards Action" [RFC8126].
> 
>    *  Initial allocation is as indicated in Table 2:
> 
>             +-------+------------------------+---------------+
>             | Value | Meaning                | Defining Spec |
>             +=======+========================+===============+
>             | 0     | Unqualified acceptance | RFC 6550      |
>             +-------+------------------------+---------------+
> 
>             Table 2: Status values of the RPL DAO-ACK Message
> 
> 13.3.  New Subregistry for the RPL Rejection Status values
> 
>    This specification creates a new subregistry for the RPL Non-
>    Rejection Status values for use in RPL DAO-ACK and RCO Messages,
>    under the ICMPv6 parameters registry.
> 
>    *  Possible values are 6-bit unsigned integers (0..63).
> 
>    *  Registration procedure is "Standards Action" [RFC8126].
> 
>    *  There is no initial allocation
> "
> 
> 
> Fire at will!
> 
> Pascal
> > -----Original Message-----
> > From: Pascal Thubert (pthubert)
> > Sent: mardi 29 octobre 2019 10:52
> > To: 'Alvaro Retana' <[e-mail]>;
> > draft-ietf-roll-efficient- [e-mail]
> > Cc: [e-mail]; roll <[e-mail]>; Peter van der Stok
> > <[e-mail]>
> > Subject: RE: AD Review of draft-ietf-roll-efficient-npdao-16
> >
> > .
> > > >
> > > > 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