Re: [Roll] draft-ietf-roll-unaware-leaves (WAS: AD Review of draft-ietf-roll-efficient-npdao-16)

Hi Pascal,

Agree with the status codes.

Questions:

1- In the  Table 1: RPL Status per RFC 6550, when the status is zero, would
it be good to add between  brackets (Success/Unqualified acceptance -since
you mentioned it when explaining bit E -) like: ,

                  +---------+---------------------------+

                  | Range   | Meaning                   |

                  +=========+===========================+

                  | 0       | RFC 6550 (Success)        |

                  +---------+---------------------------+

2- where states "...When the 'A' flag is reset," should it be better "When the
'A' flag is not set," ?

Thank you,

Ines.

On Wed, Oct 30, 2019 at 5:43 PM Alvaro Retana <aretana.ietf@gmail.com>
wrote:

> Just for clarity.
>
> The changes proposed here are for draft-ietf-roll-unaware-leaves
> (not draft-ietf-roll-efficient-npdao).  I changed the subject to reflect
> that.
>
> Alvaro.
>
> On October 30, 2019 at 6:37:15 AM, Pascal Thubert (pthubert) (
> pthubert@cisco.com) wrote:
>
> Dear all :
>
>
>
> There is a need in the RUL draft to carry a 6LoWPAN ND status inside a RPL
> status so we can avoid duplicating DAR/DAC and DAO/DAO-ACK through the
> network. This also allows async communication down the DODAG through DCO
> (efficient NPDAO).
>
>
>
> Alvaro pointed out that mapping one  status in the other as proposed so
> far was not too clean. The change proposed herein addresses this concern.
> The change would be adding another control bit in the RPL status and
> formalizing the format as follows:
>
>
>
> 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 1 2 3 4 5 6 7
>
>                       +-+-+-+-+-+-+-+-+
>
>                        |E|A|  Value    |
>
>                        +-+-+-+-+-+-+-+-+
>
>
>
>                         Figure 2: RPL status Format
>
>
>
>    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
>
>
>
>    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.
>
>
>
> Comments welcome (and urgent!). Unless I see opposition I plan to publish
> before cutoff so we can discuss it at IETF 106.
>
>
>
> All the best;
>
>
>
> Pascal
>
>
>
> *From:* Alvaro Retana <aretana.ietf@gmail.com>
> *Sent:* mardi 29 octobre 2019 23:10
> *To:* Pascal Thubert (pthubert) <pthubert@cisco.com>;
> draft-ietf-roll-efficient-npdao@ietf.org
> *Cc:* roll-chairs@ietf.org; roll <roll@ietf.org>; Peter van der Stok <
> consultancy@vanderstok.org>
> *Subject:* RE: AD Review of draft-ietf-roll-efficient-npdao-16
>
>
>
> Hi!
>
>
>
> I’m fine with the changes proposed to draft-ietf-roll-efficient-npdao.
>
>
>
> I want to see the WG reach consensus on the changes related
> to draft-ietf-roll-unaware-leaves.
>
>
>
> Thanks!
>
>
>
> Alvaro.
>
>
>
> On October 29, 2019 at 5:52:13 AM, Pascal Thubert (pthubert) (
> pthubert@cisco.com) wrote:
>
>  If you agree with the proposed line above I'll make editions and come
> back to you for more comments and/or approval.
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>