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

["Amanda Baber via RT" <[e-mail]>]

Hi Lynne, all,

These updates are complete:

On Mon Apr 05 23:03:28 2021, [e-mail] wrote:
> 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]

Done:

https://www.iana.org/assignments/icmpv6-parameters

> 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]

Done:

https://www.iana.org/assignments/rpl

Best regards,

Amanda Baber
Lead IANA Services Specialist

> 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]" <c310@rfc-
> > editor.org>
> >
> > 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]" <c310@rfc-
> > editor.org>
> >
> > 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" <c310@rfc-
> > editor.org>
> >
> >
> > 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" <c310@rfc-
> > editor.org>
> >
> >
> > 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]; c310@rfc-
> >>>>> editor.org
> >>>>> 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
> >