Re: [C310] [IANA] Re: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-30.txt> NOW AVAILABLE

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

Hello Lynne

Yes, all good. 

Many thanks

Pascal

> -----Original Message-----
> From: Lynne Bartholomew <[e-mail]>
> Sent: mardi 6 avril 2021 1:03
> To: Amanda Baber via RT <[e-mail]>
> Cc: Pascal Thubert (pthubert) <[e-mail]>; Alvaro Retana
> <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]; RFC System <[e-mail]>;
> [e-mail]; Michael Richardson <[e-mail]>
> Subject: [IANA] Re: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-
> 30.txt> NOW AVAILABLE
> 
> Dear IANA,
> 
> We are preparing this document for publication.
> 
> Please make the following update to the "Address Registration Option
> Status Values" registry on <https://www.iana.org/assignments/icmpv6-
> parameters/>:
> 
> OLD:
> Reference
> [RFC6775]
> 
> NEW:
> Reference
> [RFC6775][RFC-ietf-roll-unaware-leaves-30]
> 
> Please make the following update on
> <https://www.iana.org/assignments/rpl/>:
> 
> OLD:
> 0 Unqualified acceptance [RFC6550][RFC-ietf-roll-unaware-leaves-30]
> 
> NEW:
> 0 Success / Unqualified acceptance [RFC6550][RFC-ietf-roll-unaware-leaves-
> 30]
> 
> Thank you.
> 
> RFC Editor/lb
> 
> > On Mar 29, 2021, at 5:08 PM, Michael Richardson <[e-mail]>
> wrote:
> >
> > Lynne Bartholomew <[e-mail]> wrote:
> >> https://www.rfc-editor.org/auth48/rfc9010
> >
> >> Michael, it's not clear whether you approve terminology updates only or
> >> the document's readiness for approval; please let us know.
> >
> > Yes. All.
> >
> 
> > On Mar 29, 2021, at 1:46 PM, Lynne Bartholomew <[e-mail]>
> wrote:
> >
> > Hi, Pascal and Michael.
> >
> > Pascal, we have updated the AUTH48 status page and noted your confirmed
> approval for publication:
> >
> >   https://www.rfc-editor.org/auth48/rfc9010
> >
> > Michael, it's not clear whether you approve terminology updates only or
> the document's readiness for approval; please let us know.
> >
> > Thank you!
> >
> > RFC Editor/lb
> >
> >
> >> On Mar 29, 2021, at 12:21 PM, Pascal Thubert (pthubert)
> <[e-mail]> wrote:
> >>
> >> Dear all
> >>
> >> Same here ; I approve the draft publication.
> >>
> >> Keep safe,
> >>
> >> Pascal
> >>
> >>> Le 29 mars 2021 à 20:48, Michael Richardson <[e-mail]> a
> écrit :
> >>>
> >>> 
> >>> I have reviewed the DODAG root changes, and I approve.
> >>>
> >>>
> >>> --
> >>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
> consulting )
> >>>         Sandelman Software Works Inc, Ottawa and Worldwide
> >>>
> >>>
> >>>
> >>>
> >
> > --
> > c310 mailing list
> > [e-mail]
> > https://www.rfc-editor.org/mailman/listinfo/c310
> 
> 
> 
> > Begin forwarded message:
> >
> > From: "Pascal Thubert (pthubert)" <[e-mail]>
> > Subject: RE: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-
> 30.txt> NOW AVAILABLE
> > Date: March 26, 2021 at 10:28:18 AM PDT
> > To: Lynne Bartholomew <[e-mail]>, Michael Richardson
> <[e-mail]>
> > Cc: Alvaro Retana <[e-mail]>, "[e-mail]"
> <[e-mail]>, "[e-mail]" <[e-mail]>,
> "[e-mail]" <[e-mail]>, RFC System
> <[e-mail]>, "[e-mail]" <[e-mail]>
> >
> > Hello Lynne
> >
> > Dear RFC editor. I made a full pass on the draft, rechecked after this
> republication. Happy that you used U for the flag now.
> >
> > Nits:
> >
> > RFC 8200 is about IPv6 not routing services so:
> > "to provide IPv6 routing services [RFC8200]" -> "to provide routing
> services for IPv6 [RFC8200]"
> >
> > "The unicast packet-forwarding operation by the 6LR serving a RUL is
> described in Section 4.1 of [RFC9008]."
> > That's really section 4.1.1
> >
> > RPL root -> RPL DODAG root.
> > Root -> root or "DODAG root" as you feel best. Please do not change the
> P flag definition that would impact IANA.
> >
> > Please record my approval for publication.
> >
> > Keep safe,
> >
> > Pascal
> >
> >> -----Original Message-----
> >> From: Lynne Bartholomew <[e-mail]>
> >> Sent: vendredi 26 mars 2021 18:16
> >> To: Michael Richardson <[e-mail]>
> >> Cc: Pascal Thubert (pthubert) <[e-mail]>; Alvaro Retana
> >> <[e-mail]>; [e-mail]; [e-mail];
> >> [e-mail]; RFC System <[e-mail]>;
> >> [e-mail]
> >> Subject: Re: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-
> 30.txt>
> >> NOW AVAILABLE
> >>
> >> Hi, Michael.
> >>
> >> Thank you for spotting those items!  I made further updates and
> reposted the
> >> files (no new iteration).
> >>
> >> Please note that in addition to reverting the change in Section 9.2.2
> per your
> >> note, I also reverted to "the External ('E') flag in the Transit
> Information Option
> >> (TIO)" in Section 3.  Please let me know if this is incorrect.
> >>
> >> Please review, and let me know if I missed anything or if anything else
> is
> >> incorrect.  (You'll need to refresh your browser.)
> >>
> >>   https://www.rfc-editor.org/authors/rfc9010.txt
> >>   https://www.rfc-editor.org/authors/rfc9010.pdf
> >>   https://www.rfc-editor.org/authors/rfc9010.html
> >>   https://www.rfc-editor.org/authors/rfc9010.xml
> >>   https://www.rfc-editor.org/authors/rfc9010-diff.html
> >>   https://www.rfc-editor.org/authors/rfc9010-auth48diff.html
> >>   https://www.rfc-editor.org/authors/rfc9010-lastdiff.html
> >>   https://www.rfc-editor.org/authors/rfc9010-lastrfcdiff.html
> >>
> >>   https://www.rfc-editor.org/authors/rfc9010-xmldiff1.html
> >>   https://www.rfc-editor.org/authors/rfc9010-xmldiff2.html
> >>   https://www.rfc-editor.org/authors/rfc9010-alt-diff.html
> >>
> >> Thanks again!
> >>
> >> RFC Editor/lb
> >>
> >>
> >>> On Mar 26, 2021, at 9:33 AM, Michael Richardson
> <[e-mail]>
> >> wrote:
> >>>
> >>>
> >>> Lynne Bartholomew <[e-mail]> wrote:
> >>>> 1. changed what I *believe* to be the "E" flags in question to "U"
> >>>
> >>>> 2. gone ahead and updated Sections 12.5 and 12.6 per your note
> >>>> further below (but using "U" instead of "E")
> >>>
> >>> I might be suffering from the confusion that we are trying to reduce!
> >>> But, I think that we need to change the name of the flag in figure 6
> >>> and the description too, right?
> >>>
> >>>                           0 1 2 3 4 5 6 7
> >>>                             +-+-+-+-+-+-+-+-+
> >>>                             |E|A|StatusValue|
> >>>                             +-+-+-+-+-+-+-+-+
> >>>
> >>>                       Figure 6: RPL Status Format
> >>>
> >>>  This specification updates the RPL Status with the following
> >>>  subfields:
> >>>
> >>>  E:  1-bit flag.  Set to 1 to indicate a rejection.  When set to 0, a
> >>>      Status value of 0 indicates Success / Unqualified acceptance and
> >>>      other values indicate "Not an outright rejection" as per
> >>>      RFC 6550.
> >>>
> >>> section 9.2.2:
> >>>
> >>>  3.  The 6LR sets the External ('E')-> ('U') flag in the TIO to
> indicate that
> >>>      it is redistributing an external target into the RPL network.
> >>>
> >>> I don't think that this replacement is correct.
> >>>
> >>> I think that the rest of the updates are correct.
> >>>
> >>>
> >>> --
> >>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
> consulting )
> >>>          Sandelman Software Works Inc, Ottawa and Worldwide
> >>>
> >>>
> >>>
> >>>
> >
> 
> > From: "Pascal Thubert (pthubert)" <[e-mail]>
> > Subject: RE: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-
> 30.txt> NOW AVAILABLE
> > Date: March 26, 2021 at 10:28:18 AM PDT
> > To: Lynne Bartholomew <[e-mail]>, Michael Richardson
> <[e-mail]>
> > Cc: Alvaro Retana <[e-mail]>, "[e-mail]"
> <[e-mail]>, "[e-mail]" <[e-mail]>,
> "[e-mail]" <[e-mail]>, RFC System
> <[e-mail]>, "[e-mail]" <[e-mail]>
> >
> > Hello Lynne
> >
> > Dear RFC editor. I made a full pass on the draft, rechecked after this
> republication. Happy that you used U for the flag now.
> >
> > Nits:
> >
> > RFC 8200 is about IPv6 not routing services so:
> > "to provide IPv6 routing services [RFC8200]" -> "to provide routing
> services for IPv6 [RFC8200]"
> >
> > "The unicast packet-forwarding operation by the 6LR serving a RUL is
> described in Section 4.1 of [RFC9008]."
> > That's really section 4.1.1
> >
> > RPL root -> RPL DODAG root.
> > Root -> root or "DODAG root" as you feel best. Please do not change the
> P flag definition that would impact IANA.
> >
> > Please record my approval for publication.
> >
> > Keep safe,
> >
> > Pascal
> >
> >> -----Original Message-----
> >> From: Lynne Bartholomew <[e-mail]>
> >> Sent: vendredi 26 mars 2021 18:16
> >> To: Michael Richardson <[e-mail]>
> >> Cc: Pascal Thubert (pthubert) <[e-mail]>; Alvaro Retana
> >> <[e-mail]>; [e-mail]; [e-mail];
> >> [e-mail]; RFC System <[e-mail]>;
> >> [e-mail]
> >> Subject: Re: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-
> 30.txt>
> >> NOW AVAILABLE
> >>
> >> Hi, Michael.
> >>
> >> Thank you for spotting those items!  I made further updates and
> reposted the
> >> files (no new iteration).
> >>
> >> Please note that in addition to reverting the change in Section 9.2.2
> per your
> >> note, I also reverted to "the External ('E') flag in the Transit
> Information Option
> >> (TIO)" in Section 3.  Please let me know if this is incorrect.
> >>
> >> Please review, and let me know if I missed anything or if anything else
> is
> >> incorrect.  (You'll need to refresh your browser.)
> >>
> >>   https://www.rfc-editor.org/authors/rfc9010.txt
> >>   https://www.rfc-editor.org/authors/rfc9010.pdf
> >>   https://www.rfc-editor.org/authors/rfc9010.html
> >>   https://www.rfc-editor.org/authors/rfc9010.xml
> >>   https://www.rfc-editor.org/authors/rfc9010-diff.html
> >>   https://www.rfc-editor.org/authors/rfc9010-auth48diff.html
> >>   https://www.rfc-editor.org/authors/rfc9010-lastdiff.html
> >>   https://www.rfc-editor.org/authors/rfc9010-lastrfcdiff.html
> >>
> >>   https://www.rfc-editor.org/authors/rfc9010-xmldiff1.html
> >>   https://www.rfc-editor.org/authors/rfc9010-xmldiff2.html
> >>   https://www.rfc-editor.org/authors/rfc9010-alt-diff.html
> >>
> >> Thanks again!
> >>
> >> RFC Editor/lb
> >>
> >>
> >>> On Mar 26, 2021, at 9:33 AM, Michael Richardson
> <[e-mail]>
> >> wrote:
> >>>
> >>>
> >>> Lynne Bartholomew <[e-mail]> wrote:
> >>>> 1. changed what I *believe* to be the "E" flags in question to "U"
> >>>
> >>>> 2. gone ahead and updated Sections 12.5 and 12.6 per your note
> >>>> further below (but using "U" instead of "E")
> >>>
> >>> I might be suffering from the confusion that we are trying to reduce!
> >>> But, I think that we need to change the name of the flag in figure 6
> >>> and the description too, right?
> >>>
> >>>                           0 1 2 3 4 5 6 7
> >>>                             +-+-+-+-+-+-+-+-+
> >>>                             |E|A|StatusValue|
> >>>                             +-+-+-+-+-+-+-+-+
> >>>
> >>>                       Figure 6: RPL Status Format
> >>>
> >>>  This specification updates the RPL Status with the following
> >>>  subfields:
> >>>
> >>>  E:  1-bit flag.  Set to 1 to indicate a rejection.  When set to 0, a
> >>>      Status value of 0 indicates Success / Unqualified acceptance and
> >>>      other values indicate "Not an outright rejection" as per
> >>>      RFC 6550.
> >>>
> >>> section 9.2.2:
> >>>
> >>>  3.  The 6LR sets the External ('E')-> ('U') flag in the TIO to
> indicate that
> >>>      it is redistributing an external target into the RPL network.
> >>>
> >>> I don't think that this replacement is correct.
> >>>
> >>> I think that the rest of the updates are correct.
> >>>
> >>>
> >>> --
> >>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
> consulting )
> >>>          Sandelman Software Works Inc, Ottawa and Worldwide
> >>>
> >>>
> >>>
> >>>
> >
> 
> > From: Michael Richardson <[e-mail]>
> > Subject: Re: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-
> 30.txt> NOW AVAILABLE
> > Date: March 26, 2021 at 10:25:17 AM PDT
> > To: Lynne Bartholomew <[e-mail]>
> > Cc: "Pascal Thubert \(pthubert\)" <[e-mail]>, Alvaro Retana
> <[e-mail]>, "jgs\@juniper.net" <[e-mail]>,
> "rahul.ietf\@gmail.com" <[e-mail]>,
> "martin.vigoureux\@nokia.com" <[e-mail]>, RFC System
> <[e-mail]>, "c310\@rfc-editor.org" <[e-mail]>
> >
> >
> > I have looked over the latest patch to the U-flag, and it all looks
> correct
> > to me.
> >
> >
> > --
> > Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting
> )
> >           Sandelman Software Works Inc, Ottawa and Worldwide
> >
> 
> > From: Lynne Bartholomew <[e-mail]>
> > Subject: Re: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-
> 30.txt> NOW AVAILABLE
> > Date: March 26, 2021 at 10:15:33 AM PDT
> > To: Michael Richardson <[e-mail]>
> > Cc: "Pascal Thubert \(pthubert\)" <[e-mail]>,
> "[e-mail]" <[e-mail]>, "[e-mail]"
> <[e-mail]>, "[e-mail]" <[e-mail]>, Alvaro Retana
> <[e-mail]>, "[e-mail]"
> <[e-mail]>, RFC System <[e-mail]>
> >
> > Hi, Michael.
> >
> > Thank you for spotting those items!  I made further updates and reposted
> the files (no new iteration).
> >
> > Please note that in addition to reverting the change in Section 9.2.2
> per your note, I also reverted to "the External ('E') flag in the Transit
> Information Option (TIO)" in Section 3.  Please let me know if this is
> incorrect.
> >
> > Please review, and let me know if I missed anything or if anything else
> is incorrect.  (You'll need to refresh your browser.)
> >
> >   https://www.rfc-editor.org/authors/rfc9010.txt
> >   https://www.rfc-editor.org/authors/rfc9010.pdf
> >   https://www.rfc-editor.org/authors/rfc9010.html
> >   https://www.rfc-editor.org/authors/rfc9010.xml
> >   https://www.rfc-editor.org/authors/rfc9010-diff.html
> >   https://www.rfc-editor.org/authors/rfc9010-auth48diff.html
> >   https://www.rfc-editor.org/authors/rfc9010-lastdiff.html
> >   https://www.rfc-editor.org/authors/rfc9010-lastrfcdiff.html
> >
> >   https://www.rfc-editor.org/authors/rfc9010-xmldiff1.html
> >   https://www.rfc-editor.org/authors/rfc9010-xmldiff2.html
> >   https://www.rfc-editor.org/authors/rfc9010-alt-diff.html
> >
> > Thanks again!
> >
> > RFC Editor/lb
> >
> >
> >> On Mar 26, 2021, at 9:33 AM, Michael Richardson <[e-mail]>
> wrote:
> >>
> >>
> >> Lynne Bartholomew <[e-mail]> wrote:
> >>> 1. changed what I *believe* to be the "E" flags in question to "U"
> >>
> >>> 2. gone ahead and updated Sections 12.5 and 12.6 per your note further
> >>> below (but using "U" instead of "E")
> >>
> >> I might be suffering from the confusion that we are trying to reduce!
> >> But, I think that we need to change the name of the flag in figure 6
> and the
> >> description too, right?
> >>
> >>                           0 1 2 3 4 5 6 7
> >>                             +-+-+-+-+-+-+-+-+
> >>                             |E|A|StatusValue|
> >>                             +-+-+-+-+-+-+-+-+
> >>
> >>                       Figure 6: RPL Status Format
> >>
> >>  This specification updates the RPL Status with the following
> >>  subfields:
> >>
> >>  E:  1-bit flag.  Set to 1 to indicate a rejection.  When set to 0, a
> >>      Status value of 0 indicates Success / Unqualified acceptance and
> >>      other values indicate "Not an outright rejection" as per
> >>      RFC 6550.
> >>
> >> section 9.2.2:
> >>
> >>  3.  The 6LR sets the External ('E')-> ('U') flag in the TIO to
> indicate that
> >>      it is redistributing an external target into the RPL network.
> >>
> >> I don't think that this replacement is correct.
> >>
> >> I think that the rest of the updates are correct.
> >>
> >>
> >> --
> >> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
> consulting )
> >>          Sandelman Software Works Inc, Ottawa and Worldwide
> >>
> >>
> 
> > From: Michael Richardson <[e-mail]>
> > Subject: Re: *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9010 <draft-
> ietf-roll-unaware-leaves-30.txt> NOW AVAILABLE
> > Date: March 26, 2021 at 9:33:14 AM PDT
> > To: Lynne Bartholomew <[e-mail]>
> > Cc: "Pascal Thubert \(pthubert\)" <[e-mail]>, Alvaro Retana
> <[e-mail]>, "jgs\@juniper.net" <[e-mail]>,
> "rahul.ietf\@gmail.com" <[e-mail]>,
> "martin.vigoureux\@nokia.com" <[e-mail]>, RFC System
> <[e-mail]>, "c310\@rfc-editor.org" <[e-mail]>
> >
> >
> > Lynne Bartholomew <[e-mail]> wrote:
> >> 1. changed what I *believe* to be the "E" flags in question to "U"
> >
> >> 2. gone ahead and updated Sections 12.5 and 12.6 per your note further
> >> below (but using "U" instead of "E")
> >
> > I might be suffering from the confusion that we are trying to reduce!
> > But, I think that we need to change the name of the flag in figure 6 and
> the
> > description too, right?
> >
> >                            0 1 2 3 4 5 6 7
> >                              +-+-+-+-+-+-+-+-+
> >                              |E|A|StatusValue|
> >                              +-+-+-+-+-+-+-+-+
> >
> >                        Figure 6: RPL Status Format
> >
> >   This specification updates the RPL Status with the following
> >   subfields:
> >
> >   E:  1-bit flag.  Set to 1 to indicate a rejection.  When set to 0, a
> >       Status value of 0 indicates Success / Unqualified acceptance and
> >       other values indicate "Not an outright rejection" as per
> >       RFC 6550.
> >
> > section 9.2.2:
> >
> >   3.  The 6LR sets the External ('E')-> ('U') flag in the TIO to
> indicate that
> >       it is redistributing an external target into the RPL network.
> >
> > I don't think that this replacement is correct.
> >
> > I think that the rest of the updates are correct.
> >
> >
> > --
> > Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting
> )
> >           Sandelman Software Works Inc, Ottawa and Worldwide
> >
> 
> > From: Lynne Bartholomew <[e-mail]>
> > Subject: Re: [C310] *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9010
> <draft-ietf-roll-unaware-leaves-30.txt> NOW AVAILABLE
> > Date: March 26, 2021 at 8:57:49 AM PDT
> > To: Alvaro Retana <[e-mail]>
> > Cc: "[e-mail]" <[e-mail]>, RFC System <rfc-editor@rfc-
> editor.org>, "[e-mail]" <[e-mail]>,
> [e-mail]
> >
> > Hi, Alvaro.
> >
> > We have noted your approval on the AUTH48 status page:
> >
> >   https://www.rfc-editor.org/auth48/rfc9010
> >
> > Thank you!
> >
> > RFC Editor/lb
> >
> >> On Mar 25, 2021, at 2:56 PM, Alvaro Retana <[e-mail]>
> wrote:
> >>
> >> On March 25, 2021 at 4:52:21 PM, Lynne Bartholomew wrote:
> >>
> >>> * Alvaro, please review the update to Section 6 (removed sentence per
> >>> Pascal's reply to our question 8) below), and let us know if you
> approve.
> >>
> >>
> >> Hi Lynn!
> >>
> >> I looked at the exchange, and the diffs, and this change is fine with
> me.
> >>
> >> Thanks!
> >>
> >> Alvaro.
> >>
> >
> > --
> > c310 mailing list
> > [e-mail]
> > https://www.rfc-editor.org/mailman/listinfo/c310
> 
> > From: Lynne Bartholomew <[e-mail]>
> > Subject: Re: *[AD - Alvaro Retana] Re: AUTH48 [LB]: RFC 9010 <draft-
> ietf-roll-unaware-leaves-30.txt> NOW AVAILABLE
> > Date: March 26, 2021 at 8:52:39 AM PDT
> > To: "Pascal Thubert (pthubert)" <[e-mail]>
> > Cc: Michael Richardson <[e-mail]>, "[e-mail]"
> <[e-mail]>, "[e-mail]" <[e-mail]>,
> "[e-mail]" <[e-mail]>, Alvaro Retana
> <[e-mail]>, "[e-mail]"
> <[e-mail]>, RFC System <[e-mail]>
> >
> > Hi, Pascal.
> >
> > Apologies for my confusion.
> >
> > For now, I have
> >
> > 1. changed what I *believe* to be the "E" flags in question to "U"
> >
> > 2. gone ahead and updated Sections 12.5 and 12.6 per your note further
> below (but using "U" instead of "E")
> >
> > 3. Left all quoting as is
> >
> > Please review my updates carefully (for example, is "External ('U')
> flag" correct?), and let me know any issues.  If my updates are completely
> wrong, I can easily revert to the previous iteration and start over in
> this regard.
> >
> > The latest files are posted here (you might need to refresh your
> browser):
> >
> >   https://www.rfc-editor.org/authors/rfc9010.txt
> >   https://www.rfc-editor.org/authors/rfc9010.pdf
> >   https://www.rfc-editor.org/authors/rfc9010.html
> >   https://www.rfc-editor.org/authors/rfc9010.xml
> >   https://www.rfc-editor.org/authors/rfc9010-diff.html
> >   https://www.rfc-editor.org/authors/rfc9010-auth48diff.html
> >   https://www.rfc-editor.org/authors/rfc9010-lastdiff.html
> >   https://www.rfc-editor.org/authors/rfc9010-lastrfcdiff.html
> >
> >   https://www.rfc-editor.org/authors/rfc9010-xmldiff1.html
> >   https://www.rfc-editor.org/authors/rfc9010-xmldiff2.html
> >   https://www.rfc-editor.org/authors/rfc9010-alt-diff.html
> >
> > Thank you very much for your patience.
> >
> > Lynne
> >
> >
> >> On Mar 25, 2021, at 11:20 PM, Pascal Thubert (pthubert)
> <[e-mail]> wrote:
> >>
> >> Hello Lynne
> >>
> >> In fact I tried to use the quotes in the way the original draft that
> defines the flag uses them. I thought that was better that way. Since you
> commented I was ok to change but I like it better if we conserve the form
> of the origin draft.
> >>
> >> This quote game helps discriminate the flags called E but that’s
> imperfect. I do not think we should go farther on that path. I believe
> that the text should remove all ambiguity regardless of quotes.
> >>
> >> Sorry for G I proposal didn’t look that deep. I’m primarily concerned
> with the consistency within this document; so the fact that it exists I. A
> reference hurts less; anyway any letter would do and I’d happy with
> another one, say U or V.
> >>
> >> If E remains we have to review all cases to ensure there’s never an
> ambiguity. I believe we are OK with the preexisting E flags from other
> RFCs, but not necessarily with the EARO. In case of slightest uncertainty,
> instead of saying ‘the E flag’ we must say ‘the E flag in the EARO’. I
> found several cases of that.
> >>
> >> My preference is to change the letter.
> >>
> >> Keep safe!
> >>
> >> Pascal
> >>
> >>> Le 25 mars 2021 à 21:52, Lynne Bartholomew <[e-mail]> a
> écrit :
> >>> Dear Michael, Pascal, and *AD (Alvaro),
> >>>
> >>> * Alvaro, please review the update to Section 6 (removed sentence per
> Pascal's reply to our question 8) below), and let us know if you approve.
> >>>
> >>> Thank you for the emails.
> >>>
> >>> A few follow-up items:
> >>>
> >>> Pascal, our current text in Sections 12.5 and 12.6 does not match what
> you list here as "OLD" (i.e., there is no "and the 'E' flag set to 0").
> Please advise.
> >>>
> >>>> We had a comment on the ROLL ML that makes sense. The comment is
> this:
> >>>> "
> >>>> Section 12.5 and Section 12.6 of the document specifies the RPL
> Status values. I believe section 12.5 is applicable only when the 'E' bit
> of the status is set to 0 and Section 12.6 is applicable only when the 'E'
> bit is set to 1. I came across this while reviewing it in context to NPDAO
> compatibility.
> >>>> "
> >>>> Suggestion:
> >>>>
> >>>> In section 12.5
> >>>> OLD
> >>>> "
> >>>> IANA has created a new subregistry for the RPL Non-Rejection Status
> >>>> values for use in the RPL DAO-ACK, DCO, and DCO-ACK messages with the
> >>>> 'A' flag set to 0 and the 'E' flag set to 0, under the "Routing
> Protocol for Low Power and
> >>>> Lossy Networks (RPL)" registry.
> >>>> "
> >>>> NEW
> >>>> "
> >>>> IANA has created a new subregistry for the RPL Non-Rejection Status
> >>>> values for use in the RPL DAO-ACK, DCO, and DCO-ACK messages with the
> >>>> A flag set to 0 and the E flag set to 1, under the "Routing Protocol
> for Low Power and
> >>>> Lossy Networks (RPL)" registry.
> >>>> "
> >>>>
> >>>> In section 12.6
> >>>> OLD
> >>>> "   IANA has created a new subregistry for the RPL Rejection Status
> >>>> values for use in the RPL DAO-ACK and DCO messages with the 'A' flag
> >>>> set to 0 and the 'E' flag set to 0, under the "Routing Protocol for
> Low Power and Lossy
> >>>> Networks (RPL)" registry.
> >>>> "
> >>>> NEW
> >>>> "   IANA has created a new subregistry for the RPL Rejection Status
> >>>> values for use in the RPL DAO-ACK and DCO messages with the A flag
> >>>> set to 0 and the E flag set to 1, under the "Routing Protocol for Low
> Power and Lossy
> >>>> Networks (RPL)" registry.
> >>>> "
> >>>
> >>>
> >>> = = = = =
> >>>
> >>> Apologies, but we are not sure how to proceed as relates to flag
> names.  For example:
> >>>
> >>> This note from Pascal, and Michael's reply:
> >>>
> >>>>> We could rename the E flag that we create here to some letter that
> does
> >>>>> not show in the spec, e.g.,  G.
> >>>>
> >>>> Is the suggestion that we rename to "G", and take the impact on
> RFC9009?
> >>>> Maybe we can just prefix:
> >>>>
> >>>> "EARO-E flag"
> >>>
> >>> Pascal's reply to our question about flag-naming conventions:
> >>>
> >>>>>> 19) <!-- [rfced] We see unquoted, single-quoted, and double-quoted
> flag
> >>>>> names
> >>>>>> in this document.  We also see both "flag" and "Flag" for flag
> names.  We
> >>>>>> recommend using single quotes and lowercasing "flag" for
> consistency with
> >>>>>> draft-ietf-roll-useofrplinfo and draft-ietf-roll-efficient-npdao.
> Please let us
> >>>>>> know if this is acceptable.
> >>>>>> For example:
> >>>>>> R flag
> >>>>>> R Flag
> >>>>>> "R" and "T" flags
> >>>>>> T Flag
> >>>>>> L, P and E flags
> >>>>>> 'E' flag
> >>>>>> 'P' flag
> >>>>>> 'P' Flag -->
> >>>>> Let us can align to RFC 8505 with no quote and lower case flag as in
> < R flag >.
> >>>
> >>> A note regarding the idea of the G flag:  We see the following in RFC
> 8505; would another G flag in this document be confusing?
> >>>
> >>> This specification defines five new capability bits for use in the
> >>> 6CIO as defined by [RFC7400] ("6LoWPAN-GHC: Generic Header
> >>> Compression for IPv6 over Low-Power Wireless Personal Area Networks
> >>> (6LoWPANs)"), for use in IPv6 ND messages.  (The G flag is defined in
> >>> Section 3.3 of [RFC7400].)
> >>>
> >>> We don't know which flags are GHC flags and which are EARO flags.  For
> example, which category of flag is "External ('E') flag in the
> >>> Transit Information Option (TIO)"?
> >>>
> >>> One option would be to double-quote the EARO flags and add some
> introductory text re. same (something like "Please note that, to avoid
> possible confusion, EARO flags are double-quoted and GHC flags are
> unquoted in this document.")
> >>>
> >>> We have left the quoting or unquoting of flag names for later and will
> wait for your guidance.  Another option is that, if it turns out that the
> three written styles of flag names indicate three categories of flags
> (i.e., EARO, GHC, and something else), perhaps we should leave all quoting
> as is and provide explanatory text (in the first paragraph of Section 3,
> or earlier).
> >>>
> >>> = = = = =
> >>>
> >>> Pascal, regarding this question and your reply:
> >>>
> >>>>>> 4) <!-- [rfced] The text refers to the "ND status codes".  Is it
> >>>>>> correct that this refers to the "Address Registration Option Status
> Values"
> >>>>> registry?
> >>>>>> Perhaps "ND status codes" should be "Address Registration Options"
> or
> >>>>>> "ARO/EARO Status values"?
> >>>>> Yes, let's go for "ARO/EARO Status values" in both cases below:
> >>>
> >>> Should the two instances of "ND status code" (Sections 6.3 and 9.1) be
> left as is?
> >>>
> >>> = = = = =
> >>>
> >>> In Section 10, "it is the RPL model that the" reads a bit oddly.
> Apologies for not asking our original question more clearly.  Does the
> current "Note that it is the RPL model that the multicast packet is
> copied" mean "Note that per the RPL model the multicast packet is copied",
> "Note that it is in the RPL model that the multicast packet is copied", or
> something else?
> >>>
> >>> = = = = =
> >>>
> >>> The latest files are posted here:
> >>>
> >>> https://www.rfc-editor.org/authors/rfc9010.txt
> >>> https://www.rfc-editor.org/authors/rfc9010.pdf
> >>> https://www.rfc-editor.org/authors/rfc9010.html
> >>> https://www.rfc-editor.org/authors/rfc9010.xml
> >>> https://www.rfc-editor.org/authors/rfc9010-diff.html
> >>> https://www.rfc-editor.org/authors/rfc9010-auth48diff.html
> >>>
> >>> https://www.rfc-editor.org/authors/rfc9010-alt-diff.html
> >>> https://www.rfc-editor.org/authors/rfc9010-xmldiff1.html
> >>> https://www.rfc-editor.org/authors/rfc9010-xmldiff2.html
> >>> https://www.rfc-editor.org/authors/rfc9010-alt-diff.html
> >>>
> >>> Thanks again!
> >>>
> >>> RFC Editor/lb
> >>>
> >>>
> >>>> On Mar 23, 2021, at 1:07 PM, Michael Richardson
> <[e-mail]> wrote:
> >>>>
> >>>>
> >>>> Pascal Thubert (pthubert) <[e-mail]> wrote:
> >>>>> There are different flags named E in this spec and this may create a
> >>>>> confusion. There's already one in the EARO, and one in the GHC.
> >>>>
> >>>>> We could rename the one we introduce here but that will impact both
> >>>>> this and RFC 9009.
> >>>>
> >>>>> We could rename the E flag that we create here to some letter that
> does
> >>>>> not show in the spec, e.g.,  G.
> >>>>
> >>>> Is the suggestion that we rename to "G", and take the impact on
> RFC9009?
> >>>> Maybe we can just prefix:
> >>>>
> >>>> "EARO-E flag"
> >>>>
> >>>>
> >>>> --
> >>>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
> consulting )
> >>>>        Sandelman Software Works Inc, Ottawa and Worldwide
> >>>
> >>>> From: "Pascal Thubert (pthubert)" <[e-mail]>
> >>>> Subject: RE: AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-leaves-
> 30.txt> NOW AVAILABLE
> >>>> Date: March 23, 2021 at 9:27:06 AM PDT
> >>>> To: "Pascal Thubert (pthubert)" <[e-mail]>, "rfc-
> [e-mail]" <[e-mail]>,
> "[e-mail]" <[e-mail]>, "[e-mail]"
> <[e-mail]>
> >>>> Cc: "[e-mail]" <[e-mail]>, "[e-mail]"
> <[e-mail]>
> >>>>
> >>>> Dear RFC Editor
> >>>>
> >>>> We had a comment on the ROLL ML that makes sense. The comment is
> this:
> >>>> "
> >>>> Section 12.5 and Section 12.6 of the document specifies the RPL
> Status values. I believe section 12.5 is applicable only when the 'E' bit
> of the status is set to 0 and Section 12.6 is applicable only when the 'E'
> bit is set to 1. I came across this while reviewing it in context to NPDAO
> compatibility.
> >>>> "
> >>>> Suggestion:
> >>>>
> >>>> In section 12.5
> >>>> OLD
> >>>> "
> >>>> IANA has created a new subregistry for the RPL Non-Rejection Status
> >>>> values for use in the RPL DAO-ACK, DCO, and DCO-ACK messages with the
> >>>> 'A' flag set to 0 and the 'E' flag set to 0, under the "Routing
> Protocol for Low Power and
> >>>> Lossy Networks (RPL)" registry.
> >>>> "
> >>>> NEW
> >>>> "
> >>>> IANA has created a new subregistry for the RPL Non-Rejection Status
> >>>> values for use in the RPL DAO-ACK, DCO, and DCO-ACK messages with the
> >>>> A flag set to 0 and the E flag set to 1, under the "Routing Protocol
> for Low Power and
> >>>> Lossy Networks (RPL)" registry.
> >>>> "
> >>>>
> >>>> In section 12.6
> >>>> OLD
> >>>> "   IANA has created a new subregistry for the RPL Rejection Status
> >>>> values for use in the RPL DAO-ACK and DCO messages with the 'A' flag
> >>>> set to 0 and the 'E' flag set to 0, under the "Routing Protocol for
> Low Power and Lossy
> >>>> Networks (RPL)" registry.
> >>>> "
> >>>> NEW
> >>>> "   IANA has created a new subregistry for the RPL Rejection Status
> >>>> values for use in the RPL DAO-ACK and DCO messages with the A flag
> >>>> set to 0 and the E flag set to 1, under the "Routing Protocol for Low
> Power and Lossy
> >>>> Networks (RPL)" registry.
> >>>> "
> >>>>
> >>>> Also:
> >>>>
> >>>> There are different flags named E in this spec and this may create a
> confusion. There's already one in the EARO, and one in the GHC.
> >>>> We could rename the one we introduce here but that will impact both
> this and RFC 9009.
> >>>> We could rename the E flag that we create here to some letter that
> does not show in the spec, e.g.,  G.
> >>>>
> >>>> What do you think?
> >>>>
> >>>> Pascal
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: c310 <[e-mail]> On Behalf Of Pascal Thubert
> >>>>> (pthubert) via c310
> >>>>> Sent: mardi 23 mars 2021 10:24
> >>>>> To: [e-mail]; [e-mail]
> >>>>> Cc: [e-mail]; [e-mail]; [e-mail]
> >>>>> Subject: Re: [C310] AUTH48 [LB]: RFC 9010 <draft-ietf-roll-unaware-
> leaves-
> >>>>> 30.txt> NOW AVAILABLE
> >>>>> Dear RFC editor
> >>>>> Please find inline some answers:
> >>>>>> 1) <!-- [rfced] As "https://" now appears to work in Michael
> >>>>>> Richardson's URL, we changed "http://" to "https://".  Please let
> us know any
> >>>>> objections.
> >>>>>> Original:
> >>>>>> URI:   http://www.sandelman.ca/
> >>>>>> Currently:
> >>>>>> URI:   https://www.sandelman.ca/ -->
> >>>>> Much better
> >>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that
> appear
> >>>>>> in the
> >>>>>> title) for use on https://www.rfc-editor.org/search -->
> >>>>> IPv6 ND Redistribution
> >>>>>> 3) <!-- [rfced] We suggest moving the first sentence to appear
> last.
> >>>>>> That way, the first sentence provides more insight regarding the
> >>>>>> content of the document.
> >>>>>> Original:
> >>>>>> This specification updates RFC6550, RFC6775, and RFC8505.  It
> >>>>>> provides a mechanism for a host that implements a routing-agnostic
> >>>>>> interface based on 6LoWPAN Neighbor Discovery to obtain
> reachability
> >>>>>> services across a network that leverages RFC6550 for its routing
> >>>>>> operations.
> >>>>>> Suggested:
> >>>>>> This specification provides a
> >>>>>> mechanism for a host that implements a routing-agnostic interface
> >>>>>> based on IPv6 over Low-Power Wireless Personal Area Network
> (6LoWPAN)
> >>>>>> Neighbor Discovery to obtain reachability services across a network
> >>>>>> that leverages RFC 6550 for its routing operations.  It updates
> RFCs
> >>>>>> 6550, 6775, and 8505.
> >>>>>> -->
> >>>>> Great!
> >>>>>> 4) <!-- [rfced] The text refers to the "ND status codes".  Is it
> >>>>>> correct that this refers to the "Address Registration Option Status
> Values"
> >>>>> registry?
> >>>>>> Perhaps "ND status codes" should be "Address Registration Options"
> or
> >>>>>> "ARO/EARO Status values"?
> >>>>> Yes, let's go for "ARO/EARO Status values" in both cases below:
> >>>>>> Original (Section 1):
> >>>>>> *  Section 8 presents the changes made to [RFC6775] and [RFC8505];
> >>>>>>   The range of the ND status codes is reduced down to 64 values,
> and
> >>>>>>   the remaining bits in the original status field are now reserved.
> >>>>>> Original (Section 8):
> >>>>>> This document updates [RFC6775] and [RFC8505] to reduce the range
> of
> >>>>>> the ND status codes down to 64 values.
> >>>>>> -->
> >>>>>> 5) <!-- [rfced] Glossary:  Please note that (1) we listed the terms
> in
> >>>>>> alphanumeric order and (2) we added several terms for ease of the
> reader.
> >>>>>> Please review, and let us know any objections. -->
> >>>>> All good
> >>>>>> 6) <!-- [rfced] Figure 2:  We updated the Registration Ownership
> >>>>>> Verifier
> >>>>>> (ROVR) field to match what is shown in Figure 1 in RFC 8505.
> >>>>>> Please let us know any objections.
> >>>>>> Original:
> >>>>>> ...             Registration Ownership Verifier                 ...
> >>>>>> Currently:
> >>>>>> ...          Registration Ownership Verifier (ROVR)             ...
> -->
> >>>>> Sure, thanks
> >>>>>> 7) <!-- [rfced] Section 5.2:  Because [USEofRPLinfo] does not have
> a
> >>>>>> Section 2.1 and Section 4.1 of [USEofRPLinfo] appears to be
> applicable
> >>>>>> (per text in Section
> >>>>>> 3 and later in this section), we updated this citation accordingly.
> >>>>>> Please let us know if a different section should be cited here.
> >>>>>> Original:
> >>>>>> Section 2.1 of [USEofRPLinfo] defines the rules for tunneling
> either
> >>>>>> to the final destination (e.g., a RUL) or to its attachment router
> (designated
> >>>>> as 6LR).
> >>>>>> Currently:
> >>>>>> Section 4.1 of [RFC9008] defines the rules for tunneling to either
> >>>>>> the final destination (e.g., a RUL) or its attachment router
> >>>>>> (designated as a 6LR). -->
> >>>>> Great catch. Must be a typo, that section was never 2.1! Now; that's
> really
> >>>>> 4.1.1. So I'd like to change to:
> >>>>> "  Section 4.1.1 of [RFC9008] defines the rules for signaling an
> external
> >>>>> destination (e.g., a RUL), and tunneling to its attachment router
> >>>>> (designated as 6LR) ."
> >>>>>> 8) <!-- [rfced] Section 6:  We received the following email from
> Pascal
> >>>>> Thubert,
> >>>>>> dated 5 January 2021.  Please review, and let us know if the
> sentence in
> >>>>>> question should be removed.
> >>>>>> Hello Lynne
> >>>>>> Please see https://datatracker.ietf.org/doc/draft-ietf-roll-
> unaware-leaves/
> >>>>>> in the same cluster.
> >>>>>> It says
> >>>>>> "The RPL Status defined in section 6.5.1 of [RFC6550] for use in
> the
> >>>>>> DAO-ACK message is extended to be placed in DCO messages
> [EFFICIENT-
> >>>>>> NPDAO]
> >>>>>> as well."
> >>>>>> Ideally we would retrofit that modification in the NPDAO draft and
> remove it
> >>>>>> from the RUL draft? -->
> >>>>> Maybe we can just remove that sentence.
> >>>>> I reviewed https://www.rfc-editor.org/authors/rfc9009.html#name-
> >>>>> destination-cleanup-object- and it looks good as is.
> >>>>>> 9) <!-- [rfced] Section 6.2:  We found this citation confusing, as
> the
> >>>>>> title of Section 4.3 of [USEofRPLinfo] is "Updates to RFC8138:
> >>>>>> Indicating the way to decompress with the new RPI Option Type", and
> we
> >>>>> could
> >>>>>> not find any mention of "MOP" in its text.  Please confirm that
> this citation is
> >>>>>> correct and will be clear to readers.
> >>>>>> Original:
> >>>>>> Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that
> the
> >>>>>> definition of the Flags applies to Mode of Operation (MOP) values
> from zero
> >>>>>> (0) to six (6) only.
> >>>>> -->
> >>>>> It is really section 4.1.3. :
> >>>>> "  Section 4.1.3 of [USEofRPLinfo] updates [RFC6550] to indicate
> that the
> >>>>> definition of the Flags applies to Mode of Operation (MOP) values
> from zero
> >>>>> (0) to six (6) only.
> >>>>> "
> >>>>>> 10) <!-- [rfced] The "RPL Non-Rejection Status" registry includes
> the following
> >>>>>> for value 0:
> >>>>>> 0 Unqualified acceptance [RFC6550][RFC-ietf-roll-unaware-leaves-30]
> >>>>>> Should the description be "Success / Unqualified acceptance"?
> >>>>> Yes
> >>>>>> Section 6.3:
> >>>>>>           | 0       | Success / Unqualified acceptance |
> >>>>>> E:  1-bit flag.  Set to 1 to indicate a rejection.  When set to 0,
> a
> >>>>>>    Status value of 0 indicates Success / Unqualified acceptance and
> >>>>>>    other values indicate "Not an outright rejection" as per
> >>>>>>    RFC 6550.
> >>>>>> -->
> >>>>> Yes, please also update table 4 in section 12.5 to say " Success /
> Unqualified
> >>>>> acceptance"
> >>>>>> 11) <!-- [rfced] Section 9.1:  We are revisiting this question
> (asked during the
> >>>>>> EDIT state):
> >>>>>> We updated the sentence in question per your feedback, but please
> >>>>>> note that we used "no longer" (as in "was reachable before; isn't
> >>>>>> reachable now") as opposed to "no more" (which looks to us like a
> >>>>>> comparison, i.e., "this one is no more reachable than this other
> >>>>>> one").  Please let us know if "no longer" is incorrect (i.e., a
> comparison is
> >>>>>> intended).
> >>>>>> Our original question:
> >>>>>> Section 9.1:  We had trouble following this sentence.
> >>>>>> We updated it as follows.  If this is incorrect, to what do the two
> instances of
> >>>>>> "it" refer?
> >>>>>> Author replies:
> >>>>>> Oups, no. "ignore" was meant to say "not be aware" that it is no
> more
> >>>>>> reachable What about:
> >>>>>> "
> >>>>>> Note that a legacy RAN that receives a Non-Storing  DCO that it
> does not
> >>>>>> support will ignore it silently, as specified in  section 6 of
> [RFC6550].
> >>>>>> The result is that it will remain unaware that it is no more
> reachable
> >>>>>> till its next RPL exchange happens.
> >>>>>> "
> >>>>>> Original (the previous sentence is included for context):
> >>>>>> Note that a legacy RAN that receives a Non-Storing  DCO that it
> does not
> >>>>>> support will ignore it silently, as specified in  section 6 of
> [RFC6550].  The
> >>>>> result
> >>>>>> is that it may ignore for a while  that it is no more reachable.
> >>>>>> Currently:
> >>>>>> The result is that it will
> >>>>>> remain unaware that it is no longer reachable until its next RPL
> exchange
> >>>>>> happens. -->
> >>>>> Perfect!!! This was my French. "Plus" can mean both "more" and
> "longer". We
> >>>>> understand from context which is which.
> >>>>>> 12) <!-- [rfced] Figure 10:  Would you like to close up the
> vertical line under
> >>>>>> "Root" in the "Proof-of-ownership" line?
> >>>>>> Original (best viewed with a fixed-point font such as Courier;
> >>>>>> dashed lines are broken so that xml2rfc doesn't treat them as
> >>>>>> comments):
> >>>>>> |- - - NS EARO and Proof-of-ownership   ->|                       |
> >>>>>> Possibly:
> >>>>>> |- -  NS(EARO) and proof of ownership - ->|           |           |
> >>>>>> -->
> >>>>> Please do
> >>>>>> 13) <!-- [rfced] Section 10:  This sentence does not parse.  Please
> clarify "the
> >>>>>> RPL model that the multicast packet is passed".
> >>>>>> Also, is the use of unicast a feature that is new to this document?
> >>>>>> We see this in RFC 6550:
> >>>>>> "The
> >>>>>> main difference is that the multicast traffic going down is copied
> to
> >>>>>> all the children that have registered with the multicast group,
> >>>>>> whereas unicast traffic is passed to one child only."
> >>>>>> Original:
> >>>>>> Note that it is the RPL model that the multicast packet is passed
> as  a Layer-2
> >>>>>> unicast to each of the interested children. -->
> >>>>> "Passed" was intended to mean "copied + transmitted. This is the
> French for
> >>>>> handed over. Again, sorry for the native language leaking through.
> >>>>> What about:
> >>>>> "
> >>>>> Note that it is the RPL model that the multicast packet is copied
> and
> >>>>> transmitted as  a Layer-2
> >>>>> unicast to each of the interested children.
> >>>>> "
> >>>>>> 14) <!-- [rfced] Section 10:  Please confirm that Section 5.1 of
> [RFC3810] is the
> >>>>>> correct section to cite here.  We ask because the only mention
> >>>>>> of "report" that we see in Section 5.1 of [RFC3810] is "a
> responding
> >>>>>> Report", and we don't see any mention of "unsolicited" in that
> section.  If the
> >>>>>> citation is correct, would it help the reader if this sentence were
> somehow
> >>>>>> reworded?
> >>>>>> Original:
> >>>>>> Upon a DAO with a Target option for a multicast address, the RPL
> Root
> >>>>> checks
> >>>>>> if it is already registered as a listener for that address,  and if
> not, it performs
> >>>>>> its own unsolicited Report for the multicast  address as described
> in section
> >>>>> 5.1
> >>>>>> of [RFC3810]. -->
> >>>>> Section 5.1 describes the message and secrtion 6 describes the
> operation.
> >>>>> Maybe clearer to indicate section 6.
> >>>>> Not that unsolicited is not a protocol term, just aims at indicating
> that it is not a
> >>>>> consequence of a query but an async indication from the listener.
> >>>>> Upon a DAO with a Target option for a multicast address, the RPL
> Root  checks
> >>>>> if it is already registered as a listener for that address,  and if
> not, it performs
> >>>>> its own unsolicited Report for the multicast  address as described
> in section 6.1
> >>>>> of [RFC3810].
> >>>>>> 15) <!-- [rfced] Section 10:  We had trouble following this
> sentence.
> >>>>>> How is one Report mapped to a DAO one by one?  Are the
> contents/entries of
> >>>>>> the Report mapped to a DAO one by one?
> >>>>>> Original:
> >>>>>> Upon the timing out of the Query
> >>>>>> Interval, the 6LR sends a Multicast Address Specific Query to each
> of  its
> >>>>>> listeners, for each Multicast Address, and gets a Report back  that
> is mapped
> >>>>>> into a DAO one by one. -->
> >>>>> "
> >>>>> Upon the timing out of the Query Interval, the 6LR sends a Multicast
> Address
> >>>>> Specific Query to each of  its listeners, for each Multicast
> Address.
> >>>>> The listeners respond with a Report.
> >>>>> Based on the Reports, the 6LR maintains the aggregated list
> >>>>> of all the Multicast Addresses for which there is a listener, and
> >>>>> advertises them using DAO messages as specified in section 12 of
> [RFC6550].
> >>>>> "
> >>>>>> 16) <!-- [rfced] Please confirm that this document be listed as a
> Reference for
> >>>>>> the registry, in addition to RFC 6775.  If confirmed, we will ask
> IANA to update
> >>>>>> https://www.iana.org/assignments/icmpv6-parameters/.
> >>>>>> Original:
> >>>>>> IANA is requested to modify the Address Registration Option Status
> >>>>>> values Registry so that the upper bound of the unassigned values is
> >>>>>> 63.  This document should be added as a reference.  The
> registration
> >>>>>> procedure does not change.
> >>>>>> https://www.iana.org/assignments/icmpv6-parameters/:
> >>>>>> Address Registration Option Status Values
> >>>>>> Registration Procedure(s)
> >>>>>> Standards Action
> >>>>>> Reference
> >>>>>> [RFC6775]
> >>>>>> -->
> >>>>> Yes, see section 12.2; we change the format of the values, and IANA
> is already
> >>>>> aware (my understanding).
> >>>>> Also a typo in 12.2, I guess we want "changed".
> >>>>> "
> >>>>> The registration procedure has not change.
> >>>>> "
> >>>>>> 17) <!-- [rfced] The following appeared inconsistently in this
> document.  We
> >>>>>> have used the form on the right for consistency with RFC 6550.
> Please let us
> >>>>>> know if any changes are needed.
> >>>>>> Target Option / Target option
> >>>>>> target address / Target address
> >>>>>> Root node / root node
> >>>>> Thanks for this
> >>>>>> We are revisiting this question (asked during the EDIT
> >>>>>> state):
> >>>>>> The following terms appear to be used inconsistently in this
> document.
> >>>>> Please
> >>>>>> let us know which form is preferred.
> >>>>>> advertised Prefix / advertised prefix
> >>>>>> Flags / flags (used generally, e.g., "the flags", "the Flags")
> >>>>>> Lifetime of zero / Lifetime of 0
> >>>>>> Multicast Address / multicast address (where used generally,
> >>>>>> e.g., "the Multicast Address as", "the multicast address as")
> >>>>>> Prefix route / prefix route (appears to be used generally)
> >>>>>> Status / status (used generally, e.g., "the non-zero status in the
> >>>>>> DCO supersedes a positive Status")
> >>>>>> the Lifetime / the lifetime (used more generally, e.g.,
> >>>>>> "the Lifetime of", "the lifetime indicated in")
> >>>>>> Updated / updated
> >>>>>> (in text, e.g., "Updated RPL Target option", "updated RPL Target
> >>>>>> Option")
> >>>>>> the Size of the ROVR / the size of the ROVR -->
> >>>>> Using the right version for all is OK with me.
> >>>>>> 18) <!-- [rfced] This document consistently uses "collocated",
> while
> >>>>>> draft-ietf-roll-useofrplinfo-44 and much of C310 use "co-locate".
> May we
> >>>>>> update the text to use "co-locate" for consistency with other C310
> >>>>> documents?
> >>>>>> Originals:
> >>>>>> ... (typically collocated with the 6LBR) ...
> >>>>>> [RFC8929] expects that the 6LBR is collocated with the RPL Root,
> ...
> >>>>>> Figure 9 illustrates this in the case where the 6LBR and the Root
> are
> >>>>>> not collocated, and the Root proxies the EDAR/EDAC flow.
> >>>>>> -->
> >>>>> Please do
> >>>>>> 19) <!-- [rfced] We see unquoted, single-quoted, and double-quoted
> flag
> >>>>> names
> >>>>>> in this document.  We also see both "flag" and "Flag" for flag
> names.  We
> >>>>>> recommend using single quotes and lowercasing "flag" for
> consistency with
> >>>>>> draft-ietf-roll-useofrplinfo and draft-ietf-roll-efficient-npdao.
> Please let us
> >>>>>> know if this is acceptable.
> >>>>>> For example:
> >>>>>> R flag
> >>>>>> R Flag
> >>>>>> "R" and "T" flags
> >>>>>> T Flag
> >>>>>> L, P and E flags
> >>>>>> 'E' flag
> >>>>>> 'P' flag
> >>>>>> 'P' Flag -->
> >>>>> Let us can align to RFC 8505 with no quote and lower case flag as in
> < R flag >.
> >>>>> Please let me know when the RFC is updated and I'll make the
> complete review
> >>>>> 😊
> >>>>> Pascal
> >>>>>> Thank you.
> >>>>>> RFC Editor
> >>>>>> On Mar 21, 2021, at 10:13 PM, [e-mail] wrote:
> >>>>>> *****IMPORTANT*****
> >>>>>> Updated 2021/03/21
> >>>>>> RFC Author(s):
> >>>>>> --------------
> >>>>>> Instructions for Completing AUTH48
> >>>>>> Your document has now entered AUTH48.  Once it has been reviewed
> and
> >>>>>> approved by you and all coauthors, it will be published as an RFC.
> >>>>>> If an author is no longer available, there are several remedies
> available as
> >>>>>> listed in the FAQ (https://www.rfc-editor.org/faq/).
> >>>>>> You and you coauthors are responsible for engaging other parties
> (e.g.,
> >>>>>> Contributors or Working Group) as necessary before providing your
> approval.
> >>>>>> Planning your review
> >>>>>> ---------------------
> >>>>>> Please review the following aspects of your document:
> >>>>>> *  RFC Editor questions
> >>>>>> Please review and resolve any questions raised by the RFC Editor
> >>>>>> that have been included in the XML file as comments marked as
> >>>>>> follows:
> >>>>>> <!-- [rfced] ... -->
> >>>>>> These questions will also be sent in a subsequent email.
> >>>>>> *  Changes submitted by coauthors
> >>>>>> Please ensure that you review any changes submitted by your
> >>>>>> coauthors.  We assume that if you do not speak up that you
> >>>>>> agree to changes submitted by your coauthors.
> >>>>>> *  Content
> >>>>>> Please review the full content of the document, as this cannot
> >>>>>> change once the RFC is published. Please pay particular attention
> to:
> >>>>>> - IANA considerations updates (if applicable)
> >>>>>> - contact information
> >>>>>> - references
> >>>>>> *  Copyright notices and legends
> >>>>>> Please review the copyright notice and legends as defined in
> >>>>>> RFC 5378 and the Trust Legal Provisions
> >>>>>> (TLP – https://trustee.ietf.org/license-info/).
> >>>>>> *  Semantic markup
> >>>>>> Please review the markup in the XML file to ensure that elements of
> >>>>>> content are correctly tagged.  For example, ensure that
> <sourcecode>
> >>>>>> and <artwork> are set correctly.  See details at
> >>>>>> <https://xml2rfc.tools.ietf.org/xml2rfc-doc.html>.
> >>>>>> *  Formatted output
> >>>>>> Please review the PDF, HTML, and TXT files to ensure that the
> >>>>>> formatted output, as generated from the markup in the XML file, is
> >>>>>> reasonable.  Please note that the TXT will have formatting
> >>>>>> limitations compared to the PDF and HTML.
> >>>>>> Submitting changes
> >>>>>> ------------------
> >>>>>> To submit changes, please reply to this email with one of the
> following, using
> >>>>>> ‘REPLY ALL’ as all the parties CC’ed on this message need to see
> your changes:
> >>>>>> An update to the provided XML file
> >>>>>> — OR —
> >>>>>> An explicit list of changes in this format
> >>>>>> Section # (or indicate Global)
> >>>>>> OLD:
> >>>>>> old text
> >>>>>> NEW:
> >>>>>> new text
> >>>>>> You do not need to reply with both an updated XML file and an
> explicit list of
> >>>>>> changes, as either form is sufficient.
> >>>>>> We will ask a stream manager to review and approve any changes that
> seem
> >>>>>> beyond editorial in nature, e.g., addition of new text, deletion of
> text, and
> >>>>>> technical changes.  Information about stream managers can be found
> in the
> >>>>>> FAQ.  Editorial changes do not require approval from a stream
> manager.
> >>>>>> Approving for publication
> >>>>>> --------------------------
> >>>>>> To approve your RFC for publication, please reply to this email s
> tating that
> >>>>> you
> >>>>>> approve this RFC for publication.  Please use ‘REPLY ALL’
> >>>>>> as all the parties CC’ed on this message need to see your approval.
> >>>>>> Files
> >>>>>> -----
> >>>>>> The files are available here:
> >>>>>> https://www.rfc-editor.org/authors/rfc9010.xml
> >>>>>> https://www.rfc-editor.org/authors/rfc9010.html
> >>>>>> https://www.rfc-editor.org/authors/rfc9010.pdf
> >>>>>> https://www.rfc-editor.org/authors/rfc9010.txt
> >>>>>> Diff file of the text:
> >>>>>> https://www.rfc-editor.org/authors/rfc9010-diff.html
> >>>>>> Diff of the XML:
> >>>>>> https://www.rfc-editor.org/authors/rfc9010-xmldiff1.html
> >>>>>> The following files are provided to facilitate creation of your own
> diff files of
> >>>>>> the XML.
> >>>>>> XMLv3 file that is a best effort to capture v3-related format
> updates
> >>>>>> only:
> >>>>>> https://www.rfc-editor.org/authors/rfc9010.form.xml
> >>>>>> Tracking progress
> >>>>>> -----------------
> >>>>>> The details of the AUTH48 status of your document are here:
> >>>>>> https://www.rfc-editor.org/auth48/rfc9010
> >>>>>> Please let us know if you have any questions.
> >>>>>> Thank you for your cooperation,
> >>>>>> RFC Editor
> >>>>>> --------------------------------------
> >>>>>> RFC9010 (draft-ietf-roll-unaware-leaves-30)
> >>>>>> Title            : Routing for RPL Leaves
> >>>>>> Author(s)        : P. Thubert, Ed., M. Richardson
> >>>>>> WG Chair(s)      : Dominique Barthel, Ines Robles
> >>>>>> Area Director(s) : Alvaro Retana, John Scudder, Martin Vigoureux
> >>>>> --
> >>>>> c310 mailing list
> >>>>> [e-mail]
> >>>>> https://www.rfc-editor.org/mailman/listinfo/c310
> >