Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9009 <draft-ietf-roll-efficient-npdao-18.txt> NOW AVAILABLE

[Lynne Bartholomew <[e-mail]>]

Hi, Pascal, Rahul, and Rabi.

Pascal, regarding changing 'E' to 'U':  In addition to updates per your notes below, we also updated this sentence; please let us know any concerns:

OLD:
   A StatusValue of 0 along with the 'E' bit set to 0
   indicates Success / Unqualified acceptance as per Figure 6 of
   [RFC9010].

NEW:
    A StatusValue of 0 along with the 'U' bit set to 0
    indicates Success / Unqualified acceptance as per Figure 6 of
    [RFC9010].

= = = = =

Rahul, thank you for providing Rabi's current email address.

= = = = =

Rabi, we have updated your email address in this document and in our corresponding database record.  Please let us know if further updates to your contact information in this document are needed.

Currently:

   Rabi Narayan Sahoo
   Huawei
   Whitefield
   Kundalahalli Village
   Bangalore 560037
   Karnataka
   India

   Phone: [phone]
   Email: [e-mail]


Please note that several questions -- listed below under Rahul's 25 March email -- are still pending.

The latest files are posted here (you might need to refresh your browser):

   https://www.rfc-editor.org/authors/rfc9009.txt
   https://www.rfc-editor.org/authors/rfc9009.pdf
   https://www.rfc-editor.org/authors/rfc9009.html
   https://www.rfc-editor.org/authors/rfc9009.xml
   https://www.rfc-editor.org/authors/rfc9009-diff.html
   https://www.rfc-editor.org/authors/rfc9009-auth48diff.html
   https://www.rfc-editor.org/authors/rfc9009-lastdiff.html
   https://www.rfc-editor.org/authors/rfc9009-lastrfcdiff.html

   https://www.rfc-editor.org/authors/rfc9009-xmldiff1.html
   https://www.rfc-editor.org/authors/rfc9009-xmldiff2.html

Thanks again!

RFC Editor/lb


> On Mar 26, 2021, at 11:06 AM, Pascal Thubert (pthubert) <[e-mail]> wrote:
> 
> Hello Lynne and all
> 
> Many thanks for the change to the U flag in RFC 9010. Please keep in mind that we need to adapt E ->U flag in RFC 9009. I suggest the following changes:
> 
> Value 195 represents the 'E' and 'A' bits in RPL Status, to be set as per Figure 6 of [RFC9010], with the lower 6 bits with value 3 indicating 'Moved' as per Table 1 of [RFC8505].
> ->
> Value 195 represents the 'U' and 'A' bits in RPL Status, to be set as per Figure 6 of [RFC9010], with the lower 6 bits set to the 6LoWPAN ND EARO Status value of 3 indicating ' Moved' as per Table 1 of [RFC8505].
> 
> 
> A StatusValue of 1 with 'E' bit set to 1 indicates 'No routing entry' as defined in Table 5 of [RFC9010].
> ->
> A Status value of 1 with 'U' bit set to 1 and the 'A' bit set to 0 indicates 'No routing entry' as defined in Table 5 of [RFC9010].
> 
> 
> Keep safe,
> 
> Pascal

> From: Rahul Jadhav <[e-mail]>
> Subject: Re: *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9009 <draft-ietf-roll-efficient-npdao-18.txt> NOW AVAILABLE
> Date: March 25, 2021 at 2:00:02 AM PDT
> To: Lynne Bartholomew <[e-mail]>
> Cc: "Pascal Thubert (pthubert)" <[e-mail]>, Alvaro Retana <[e-mail]>, dominique barthel <[e-mail]>, peter van der Stok <[e-mail]>, Ines Robles <[e-mail]>, Zhen Cao <[e-mail]>, John Scudder <[e-mail]>, Pascal Thubert <[e-mail]>, RFC System <[e-mail]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[e-mail]>, [e-mail], rabi narayan sahoo <[e-mail]>
> 
> Hi Lynne,
> 
> When I responded back to the previous mail, I had added Rabi's Gmail id ([e-mail]) in the CC. I should have explicitly stated this in my response but missed out.
> Anyways Rabi's Gmail id has been in CC since then and is present in the last email you sent. So no worries.
> 
> Thanks,
> Rahul

> > On Mar 24, 2021, at 2:16 PM, Lynne Bartholomew <[e-mail]> wrote:
> > 
> > Dear Pascal, Rahul, and *AD (Alvaro),
> > 
> > Pascal and Rahul, thank you for your prompt replies!  Rahul, many thanks also for your work and the updated XML file.
> > 
> > * Alvaro, please let us know if you approve the removal of the "New Registry for the Destination Cleanup Object Acknowledgment (DCO-ACK) Status Field" section -- apparently, the information listed there should all be found in companion document RFC 9010, as can mostly be seen on <https://www.iana.org/assignments/rpl/>.
> > 
> > However, please note that there appear to be two additional issues related to IANA items:
> > 
> > Issue 1.  Rahul's updated text in Section 4.3.4 of this document regarding "No routing entry" now points to companion document RFC 9010, but <https://www.iana.org/assignments/rpl/> shows the following:
> > 
> > 1     No routing entry        [draft-ietf-roll-efficient-npdao-18]
> > 
> > It appears that we should ask IANA to make the following update on <https://www.iana.org/assignments/rpl/>; is that correct?
> > 
> > Currently:
> > 
> > 1     No routing entry        [draft-ietf-roll-efficient-npdao-18]
> > 
> > Possibly:
> > 
> > 1     No routing entry        [RFC-ietf-roll-unaware-leaves-30]
> > 
> > (Note that IANA will add the appropriate RFC numbers when these documents are published.)
> > 
> > = = = =
> > 
> > Issue 2.  Table 5 of companion document RFC 9010 shows the following.  It appears that "9009" should be "9010" there and that we should ask the authors of RFC 9010 if we can update accordingly; is that correct?
> > 
> > 2.    | 1     | No routing entry      | RFC 9009  |
> > 
> > = = = = = = = =
> > 
> > Regarding this item and Rahul's reply:
> > 
> >> <!-- [rfced] Section 4.4:  Does "it" in this sentence refer to the                      
> >> DCOSequence values (in which case it should be "those values"), or                      
> >> something else?                                                                         
> >> 
> >> Original:                                                                               
> >> The scope of DCOSequence values is unique to the node which generates                  
> >> it.                                                                                    
> >> 
> >> [rahul] "it" refers to the node ... not the DCOSequence values.                         
> >> I believe the current statement is correct.                                             
> >> -->
> > 
> > 
> > If "it" refers to the node, then saying "unique to the node that generates the node" looks odd.  Please confirm that this is correct and will be clear to readers (in other words, does the node generate itself?).
> > 
> > = = = = = = = =
> > 
> > This updated sentence still does not parse.  Please clarify "are 6LRs en-route DCO message path that does not support".
> > 
> >   If there are 6LRs en-route DCO message path that does
> >   not support this document, then the route invalidation for
> >   corresponding targets may not work or may work partially, i.e., only        
> >   part of the path supporting the DCO may be invalidated.
> > 
> > = = = = = = = =