Subject: [Last-Call] Genart last call review of draft-ietf-roll-unaware-leaves-24

From: Elwyn Davies via Datatracker <[email-masked]>
Date: Sun, 13 Dec 2020 15:23:29 -0800

Reviewer: Elwyn Davies
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-roll-unaware-leaves-24
Reviewer: Elwyn Davies
Review Date: 2020-12-13
IETF LC End Date: 2020-12-09
IESG Telechat date: 2020-12-17

Summary:  The document is almost ready for publication.  As mentioned elsewhere
in reviews it is a very dense document requesting updates of several standards
and as such it is a difficult read and I would not be totally sure that
everything is consistent.  However, I did find s9 and s10 to be pretty clear. 
There are a few minor issues that need resolving IMO.
 Most are trivial  but the connection to EFFICIENT-NPDAO needs fixing - both
 these documents are in draft and specifying alterations or updates to a
 document still in draft doesn't seem sensible.  Apologies for rather late
 delivery of this review - it took longer than expected.

Major issues:
None

Minor issues:
s6.1, para 2: I found this paragraph difficult to parse. I note also that
nowhere in the document is the implementor told to set the F flag to 1 (there
is one place in s9.2.2 where it has to be forced to 0).  Presumably there
should be an instruction somewhere in s9.2.1 that there should be a Target
Option with the F flag set. I would suggest alternative text for this para as
follows: OLD: The new 'F' flag is set to 1 to indicate that the Target Prefix
field contains the IPv6 address of the advertising node, in which case the
length of the Target Prefix field is 128 bits regardless of the value of the
Prefix Length field. If the 'F' flag is set to 0, the Target Prefix field MUST
be aligned to the next byte boundary after the size (expressed in bits)
indicated by the Prefix Length field. Padding bits are reserved and set to 0
per section 6.7.7 of [RFC6550]. NEW: The added 'F' flag is set to 1 to indicate
that the Target Prefix field contains the IPv6 address of the advertising node
and will, accordingly,
 have the Prefix Length set to 128. The length of the Target Prefix
field will be an integral number of octets, TPL, which is the smallest
integer such that (TPL * 8) is greater than or equal to Prefix Length.
The Target Prefix is left (high bit) justified in the field and any
additional bits in the rightmost octet will be filled with padding bits.
Padding bits are reserved and set to 0 as specified in section 6.7.7 of
[RFC6550].
ENDS

s6.2, position of P flag: As a matter of interest why is the flag in position 1
and not position 0 or 4?  It might be more helpful in the event of further
additional functionality being added to have 3 spare bits together if the
position is of no consequence.

s6.3, next to last para. s8 and s 12.2:  In view of the statement in s6.3:
The RPL Root MUST set the 'E' flag to 1 for all rejection and unknown status
codes. The status codes in the 1-10 range [RFC8505] are all considered
rejections. I think that IANA should be requested to add a column to the EARO
status codes registry being modified by s12.2 to add a column that identifies a
status code as a rejection or otherwise.   Some words in s8 may be appropriate.

s7:  Given that [EFFICIENT-NPDAO] is still a draft,  I think this section
should be synchronized with the  draft so that we don't end up with one or the
other new RFC updating an RFC that doesn't yet exist.

s14: Idnits notes that there is a normative reference to RFC 7102 which is
informational.  I note that this was not mentioned in the Last Call. However
RFC 7102 has already had one accepted Downref waiver and the summary of terms
is a suitable use case.

Nits/editorial comments:

General: s/byte/octet/g

Abstract:  Expand RPL on first use (currently done in s1.) Expand ND.

Abstract:  Idnits produces a spurious warning about RFC 8505...

-- The draft header indicates that this document updates RFC8505, but the
abstract doesn't seem to directly say this. It does mention RFC8505 though, so
this could be OK.

The abstract says

This specification updates RFC6550, RFC6775, and RFC8505,

which is fine by me.  I will report this to the  Tools team.

s1, s2.2, s2.3: The term defined in [USEofRPLinfo] is RPL-Unaware-Leaf rather
than RPL-Unaware Leaf: s/RPL-Unaware Leaf/RPL-Unaware Leaf/ (3 places). 
Similarly s/RPL-Aware Leaf/RPL-Aware-Leaf/ (1 place) and s/RPL-Aware
Node/RPL-Aware-node/ (2 places).

s2.3, para 3:
>
> The term RPL-Aware Node (RAN) is introduced to refer to a node that is either
an RAL or a RPL Router. This term is already defined in [USEofRPLinfo] with,  I
understand, the same meaning. s3, para 1: s/detailed/summarized/ - the formal
details are in [USEofRPLinfo].

s3, para 3: Add MOP to glossary.

s3. para 4: s/to transport a RPL Packet Information (RPI) [RFC6550]./to
transport the RPL Packet Information (RPI) [RFC6550]option./

s3, para 4: '... except for the very special case above,' - I am not totally
sure what part of the section is being referred to by this.  Do you mean the
case referred to in the  previous sentence?  Please make this clearer.

s3, para 5: The jargon term 'going down' is used here without definition.  It
is sort of inherited from [USEofRPLinfo] (Section 8.3.1) but is not properly
defined there either.  Please improve and explain this jargon.

s3, para 5:  Might be sensible to add SRH to the glossary instead of expanding
here.

s3, last para: s/forwarding/forwarding it/

s4.1, para 3: It would be helpful to add 6LBR to the glossary.

s4.2.2: s/ (more in Section 5.1)/; this requirement is fully explained in
Section 5.1/

s4.2.3. title: Suggest expanding the acronym.

s4.2.3, para 2: s/The use of ROVR field enable/The use of the ROVR field
enables/

s4.3, para 1: s/8.2.6/Section 8.2.6/

s4.3, para 1: To avoid any future inconsistency the notional value of
RETRANS_TIMER should not be mentioned here: s/a duration longer than the 
RETRANS_TIMER [RFC4861] of 1 second /a duration longer than the default value
of the RetransTimer (RETRANS_TIMER) [RFC4861] /

s4.3, para1:  I would suggest using the conventional term: s/Turn Around Trip
delay/round trip delay/

s4.3, last para: Suggest adding a forward ref to s9.1 for Figure 7.

s4.3.1. last para: s/and set the/and sets the/

s4.3.1, last para: s/, more in Section 9.2./; this is fully explained in
Section 9.2./

s5, title:  s/RPL-Unware Leaf/RPL-Unware-Leaf/

s5, para 1: A document cannot provide anything! s/This document provides RPL
routing for a RUL./This document describes how RPL routing can be extended to a
RUL./

s5.3, title:  Expand HbH - it isn't used anywhere else.

s6: s/more in/see/ (5 places)

s6.1, Flags specification: s/4 bits/3 bits/

s6.2, title and para 2: s/New Flag/Additional Flag/ (with appropriate
capitalization)

s6.3, para 2:
OLD:
This specification enables to carry the 6LoWPAN ND Status values in RPL DAO and
DCO messages, NEW: This specification adds a capability to allow the carriage
of 6LoWPAN ND Status values in RPL DAO and DCO messages, ENDS

s9: A pointer back to s4.3 might be useful regarding the proxy operation.

s9.2:  By convention, there should be a brief description of the purpose and
subsections before starting s9.2.1.  The RFC Editor doesn't like empty sections

s9.2.1, para after item 6: s/else it MUST leave the Opaque field to
zero./otherwise it MUST leave the Opaque field as zero.

s9.2., para 4: s/mean/means/

s9.2.2, para after Figure 9: s/that it stops providing/that it is ceasing to
provide/; s/that it stops serving/that it is ceasing to serve/

s9.2.3, item 1:  This would be a useful point to mention that the Target IPv6
address is marked by the F Flag being 1.

s9.2.3, para after item 4: s/Else/Otherwise/

s11, para 3: s/Req5.1 in Appendix/Req-5.1 in Appendix B.5/

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 14 Dec 2020 18:35:26 +0000

Hello Elwyn;

Many thanks for your review! It was very thorough and helpful. 

I placed the first round of corrections here: https://github.com/roll-wg/roll-unaware-leaves/commit/523bd3c7b59a8eca822482a8a26b4cbd6b87c190 
There are a few items left open, in particular the RPL-Unaware Leaves vs.  RPL-Unaware-Leaves. I fail to see why there's a need for the '-' before Leave. 

I'm sorry the RPL world has its own terms and habits, and it's hard to write a spec without leaving some of that taken for granted. OTOH, we do not want to over re explain things which are core to RPL operations, when this doc is an extension to those operations; arguable the implementers will be already aware of the code they extend and the art / context. 

Please let me know what you think of the below (I snipped all the things I plainly applied, many of them):

> 
> Summary:  The document is almost ready for publication.  As mentioned
> elsewhere in reviews it is a very dense document requesting updates of several
> standards and as such it is a difficult read and I would not be totally sure that
> document still in draft doesn't seem sensible.  Apologies for rather late  delivery
> of this review - it took longer than expected.
> 
> Major issues:
> None
> 
> Minor issues:
> s6.1, para 2: I found this paragraph difficult to parse. I note also that nowhere in
> the document is the implementor told to set the F flag to 1 (there is one place in
> s9.2.2 where it has to be forced to 0).  Presumably there should be an
> instruction somewhere in s9.2.1 that there should be a Target Option with the F
> flag set. I would suggest alternative text for this para as
> follows: 
>
> OLD: The new 'F' flag is set to 1 to indicate that the Target Prefix field
> contains the IPv6 address of the advertising node, in which case the length of
> the Target Prefix field is 128 bits regardless of the value of the Prefix Length
> field. If the 'F' flag is set to 0, the Target Prefix field MUST be aligned to the next
> byte boundary after the size (expressed in bits) indicated by the Prefix Length
> field. Padding bits are reserved and set to 0 per section 6.7.7 of [RFC6550].
>
> NEW: The added 'F' flag is set to 1 to indicate that the Target Prefix field contains
> the IPv6 address of the advertising node and will, accordingly,  have the Prefix
> Length set to 128. The length of the Target Prefix field will be an integral number
> of octets, TPL, which is the smallest integer such that (TPL * 8) is greater than or
> equal to Prefix Length.
> The Target Prefix is left (high bit) justified in the field and any additional bits in
> the rightmost octet will be filled with padding bits.
> Padding bits are reserved and set to 0 as specified in section 6.7.7 of [RFC6550].
> ENDS
> 

Misunderstanding alert. The Prefix Length can be say /64 or /48. We need to indicate it, that's the main purpose of the option.
What we do with the bit on it put the rest of the bits of the advertiser's address after the prefix bits. Say it's a /48 we announce.
Out of that /48 there will be a /64 where the announcer resides. And the announcer will have an IPv6 address from that /64.
In that case, if the bit is on, you'll find a Prefix field of 128 bit and a prefix length of 48. The first 48 bits are still the announced prefix.
And the field contains the announcer's address starting with the 64 bits of its subnet prefix and then the advertising node's IID. 

I tried to do a mix to clarify; does the following help?
" 
   The Target Prefix of the RPL Target Option is left (high bit)
   justified and contains the advertised prefix; its size may be smaller
   than 128 when it indicates a Prefix route.  The Prefix Length field
   signals the number of bits that correspond to the advertised Prefix;
   it is 128 for a Host route or less in the case of a Prefix route.
   This remains unchanged.

   This specification defines the new 'F' flag that is set to 1 to
   indicate that the Target Prefix field is extended to 128 bits and
   contains an IPv6 address of the advertising node taken from the
   advertised Prefix.  When it is set, the Target Prefix field carries
   contain 2 distinct information, a route that can be a Host route or a
   Prefix route depending on the Prefix Length, and an IPv6 address of
   the advertiser.

   If the 'F' flag is set to 0, the Target Prefix field can be shorter
   than 128 bits and it MUST be aligned to the next byte boundary after
   the end of the prefix.  Any additional bits in the rightmost octet
   are filled with padding bits.  Padding bits are reserved and set to 0
   as specified in section 6.7.7 of [RFC6550].
"
>
> s6.2, position of P flag: As a matter of interest why is the flag in position 1 and
> not position 0 or 4?  It might be more helpful in the event of further additional
> functionality being added to have 3 spare bits together if the position is of no
> consequence.

There are other specs coming up which reserved the other bits but 0 and 1, and the bits were allocated starting from the right. 
See https://www.iana.org/assignments/rpl/rpl.xhtml#dodag-config-option-flags, knowing that the value of 2 was taken by https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138. Net-net, we're exactly where you'd like us to be.

> status code as a rejection or otherwise.   Some words in s8 may be appropriate.

Well that would require normative text on the 6LoWPAN part. I guess we can do that at the next iteration of a 6LoWPAN ND specification.
For now what we specify is that from the RPL perspective the listed codes denote a failure such that the RPL operation that wraps it cannot happen and that's enough for us.

> s7:  Given that [EFFICIENT-NPDAO] is still a draft,  I think this section should be
> synchronized with the  draft so that we don't end up with one or the other new
> RFC updating an RFC that doesn't yet exist.

Yes, this was a discussion with Alvaro as well during his AD review and what you see is the outcome.
In particular, this is one reason why [EFFICIENT-NPDAO] is referenced normatively. 

> informational.  I note that this was not mentioned in the Last Call. However RFC
> 7102 has already had one accepted Downref waiver and the summary of terms
> is a suitable use case.

Yes, this is a classical nit; the usual solution for that reference is that the AD accepts the downref and we move on.

> General: s/byte/octet/g

Fun. Carsten asked us to do the exact inverse change. Being French I favor "octets" but really the IETF should provide a guidance here. 
I just cannot go back and force with each new review.

> Abstract:  Expand RPL on first use (currently done in s1.) Expand ND.

Done it (relunctantly) for ND. RPL has been used as a noun by people of the art for a long while now. Expending it would turn the abstract in a book.

> abstract doesn't seem to directly say this. It does mention RFC8505 though, so

Tool's limitation.

> which is fine by me.  I will report this to the  Tools team.

Yep. We're used to that one. We just learned to ignore it, not sure it's worth the extra code discerning all the language niceties that can be used here.

> Node/RPL-Aware-node/ (2 places).

Good point. In terms of English which makes more sense? We can fix either draft.
I posted to the ROLL ML.

> details are in [USEofRPLinfo].

Yep,  was updated 😊 I changed to 
"
  This document uses the terms RPL-Unaware Leaf (RUL), RPL-Aware Node
   (RAN) and RPL Aware Leaf (RAL) consistently with [USEofRPLinfo].  A
   RAN is either an RAL or a RPL Router.  As opposed to a RUL, a RAN
   manages the reachability of its addresses and prefixes by injecting
   them in RPL by itself.
"

And made the other proposed change as well.

> transport the RPL Packet Information (RPI) [RFC6550]option./

Well both are transported, but RFC 6550 defines the RPI as abstract information not as an option. 
And to make things simpler we typically abuse "RPI" to say "RPL Option".
What about:
"

   The RPL data packets typically carry a Hop-by-Hop Header with a RPL
   Option [RFC6553] that contains the Packet Information (RPI) defined
   in section 11.2 of [RFC6550].  
" 
?

> 
> s3, para 4: '... except for the very special case above,' - I am not totally sure what
> part of the section is being referred to by this.  Do you mean the case referred to
> in the  previous sentence?  Please make this clearer.

I gave it a try:

"
                                                     Unless the RUL already placed a RPL
   Option in outer header chain, the packets from and to the RUL are
   encapsulated using an IP-in-IP tunnel between the Root and the 6LR
   that serves the RUL (see sections 7 and 8 of [USEofRPLinfo] for
   details).  If the packet from the RUL has an RPI, the 6LR as a RPL
   border router SHOULD rewrite the RPI to indicate the selected
   Instance and set the flags, but it does not need to encapsulate the
   packet.
"

Works?

> 
> s3, para 5: The jargon term 'going down' is used here without definition.  It is
> sort of inherited from [USEofRPLinfo] (Section 8.3.1) but is not properly defined
> there either.  Please improve and explain this jargon.

These are defined in section 2 of RFC 6550, and very, very common in RPL parlance.
I changed a sentence in section 2.2 to 
"
  "RPL", the "RPL Packet Information" (RPI), "RPL Instance" (indexed by
   a RPLInstanceID), "up", "down" are defined in "RPL: IPv6 Routing
   Protocol for Low-Power and Lossy Networks" [RFC6550]
"

> s3, para 5:  Might be sensible to add SRH to the glossary instead of expanding

Added. I kept the expansion though, in alignment with other acronyms in the glossary.

> s5, title:  s/RPL-Unware Leaf/RPL-Unware-Leaf/

I delayed that one. 

> s6.3, para 2:
> OLD:
> This specification enables to carry the 6LoWPAN ND Status values in RPL DAO
> and DCO messages, NEW: This specification adds a capability to allow the
> carriage of 6LoWPAN ND Status values in RPL DAO and DCO messages, ENDS

Heavy carriage! I'll trust you on this

> subsections before starting s9.2.1.  The RFC Editor doesn't like empty sections

I never hit that one. Interesting. For some reason the ETSI editor will force the opposite.
Done anyway.
> address is marked by the F Flag being 1.

Actually it is not. It is set to 0 per the previous section. But the Prefix Length is 128 indicating a host address (not that of the advertiser though, thus the 'F' flag set to 0).

Again, a great many thanks Elwyn!

Pascal

---

From: elwynd <[email-masked]>
Date: Mon, 14 Dec 2020 22:39:55 +0000

Hi, Pascal.Thanks for the *extremely* speedy response!Further responses inline.Cheers,ElwynSent from my Galaxy
-------- Original message --------From: "Pascal Thubert (pthubert)" <pthubert=[email-masked]> Date: 14/12/2020  18:36  (GMT+00:00) To: Elwyn Davies <[email-masked]>, [email-masked] Cc: [email-masked], [email-masked], [email-masked] Subject: Re: [Gen-art] Genart last call review of
  draft-ietf-roll-unaware-leaves-24 Hello Elwyn;Many thanks for your review! It was very thorough and helpful. I placed the first round of corrections here: https://github.com/roll-wg/roll-unaware-leaves/commit/523bd3c7b59a8eca822482a8a26b4cbd6b87c190 There are a few items left open, in particular the RPL-Unaware Leaves vs.  RPL-Unaware-Leaves. I fail to see why there's a need for the '-' before Leave. ED> I don't really care either way - as long as the two documents are consistent.  Aesthetically I think RPL-Unaware Leaves is marginally prettier.I'm sorry the RPL world has its own terms and habits, and it's hard to write a spec without leaving some of that taken for granted. OTOH, we do not want to over re explain things which are core to RPL operations, when this doc is an extension to those operations; arguable the implementers will be already aware of the code they extend and the art / context. ED> Don't worry!  I am well aware of this problem for draft authors.  Gen-art sees its job as trying to make sure that non-specialists are not totally bemused and can see if the RFC is of any relevance to them.Please let me know what you think of the below (I snipped all the things I plainly applied, many of them):> > Summary:  The document is almost ready for publication.  As mentioned> elsewhere in reviews it is a very dense document requesting updates of several> standards and as such it is a difficult read and I would not be totally sure that> everything is consistent.  However, I did find s9 and s10 to be pretty clear.> There are a few minor issues that need resolving IMO.>  Most are trivial  but the connection to EFFICIENT-NPDAO needs fixing - both> these documents are in draft and specifying alterations or updates to a> document still in draft doesn't seem sensible.  Apologies for rather late  delivery> of this review - it took longer than expected.> > Major issues:> None> > Minor issues:> s6.1, para 2: I found this paragraph difficult to parse. I note also that nowhere in> the document is the implementor told to set the F flag to 1 (there is one place in> s9.2.2 where it has to be forced to 0).  Presumably there should be an> instruction somewhere in s9.2.1 that there should be a Target Option with the F> flag set. I would suggest alternative text for this para as> follows: >> OLD: The new 'F' flag is set to 1 to indicate that the Target Prefix field> contains the IPv6 address of the advertising node, in which case the length of> the Target Prefix field is 128 bits regardless of the value of the Prefix Length> field. If the 'F' flag is set to 0, the Target Prefix field MUST be aligned to the next> byte boundary after the size (expressed in bits) indicated by the Prefix Length> field. Padding bits are reserved and set to 0 per section 6.7.7 of [RFC6550].>> NEW: The added 'F' flag is set to 1 to indicate that the Target Prefix field contains> the IPv6 address of the advertising node and will, accordingly,  have the Prefix> Length set to 128. The length of the Target Prefix field will be an integral number> of octets, TPL, which is the smallest integer such that (TPL * 8) is greater than or> equal to Prefix Length.> The Target Prefix is left (high bit) justified in the field and any additional bits in> the rightmost octet will be filled with padding bits.> Padding bits are reserved and set to 0 as specified in section 6.7.7 of [RFC6550].> ENDS> Misunderstanding alert. The Prefix Length can be say /64 or /48. We need to indicate it, that's the main purpose of the option.What we do with the bit on it put the rest of the bits of the advertiser's address after the prefix bits. Say it's a /48 we announce.Out of that /48 there will be a /64 where the announcer resides. And the announcer will have an IPv6 address from that /64.In that case, if the bit is on, you'll find a Prefix field of 128 bit and a prefix length of 48. The first 48 bits are still the announced prefix.And the field contains the announcer's address starting with the 64 bits of its subnet prefix and then the advertising node's IID. ED> Ah!  In that case I think that a clarification is indeed needed 'cos I hadn't got that story from the draft.I tried to do a mix to clarify; does the following help?"    The Target Prefix of the RPL Target Option is left (high bit)   justified and contains the advertised prefix; its size may be smaller   than 128 when it indicates a Prefix route.  The Prefix Length field   signals the number of bits that correspond to the advertised Prefix;   it is 128 for a Host route or less in the case of a Prefix route.   This remains unchanged.   This specification defines the new 'F' flag that is set to 1 to   indicate that the Target Prefix field is extended to 128 bits and   contains an IPv6 address of the advertising node taken from the   advertised Prefix.  When it is set, the Target Prefix field carries   contain 2 distinct information, a route that can be a Host route or a   Prefix route depending on the Prefix Length, and an IPv6 address of   the advertiser.ED> s/carries contain 2 distinct information,/carries two distinct pieces of information:/   If the 'F' flag is set to 0, the Target Prefix field can be shorter   than 128 bits and it MUST be aligned to the next byte boundary after   the end of the prefix.  Any additional bits in the rightmost octet   are filled with padding bits.  Padding bits are reserved and set to 0   as specified in section 6.7.7 of [RFC6550].ED>  That is much better.">> s6.2, position of P flag: As a matter of interest why is the flag in position 1 and> not position 0 or 4?  It might be more helpful in the event of further additional> functionality being added to have 3 spare bits together if the position is of no> consequence.There are other specs coming up which reserved the other bits but 0 and 1, and the bits were allocated starting from the right. See https://www.iana.org/assignments/rpl/rpl.xhtml#dodag-config-option-flags, knowing that the value of 2 was taken by https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138. Net-net, we're exactly where you'd like us to be.ED>  Great.  I did look at the IANA registry and I didn't see any early assignments but I might have missed them.> > s6.3, next to last para. s8 and s 12.2:  In view of the statement in s6.3:> The RPL Root MUST set the 'E' flag to 1 for all rejection and unknown status> codes. The status codes in the 1-10 range [RFC8505] are all considered> rejections. I think that IANA should be requested to add a column to the EARO> status codes registry being modified by s12.2 to add a column that identifies a> status code as a rejection or otherwise.   Some words in s8 may be appropriate.Well that would require normative text on the 6LoWPAN part. I guess we can do that at the next iteration of a 6LoWPAN ND specification.For now what we specify is that from the RPL perspective the listed codes denote a failure such that the RPL operation that wraps it cannot happen and that's enough for us.ED>  While I understand that it would be polite to involve 6LoWPAN, WGs don't 'own' RFCs and their associated IANA registries.  Since this draft 'needs' the extra information I personally wouldn't see a problem in asking for the extra column. It doesn't break anythng 6LoWPAN are doing AFAICS. Anyway that's not my call...  ask your AD.> s7:  Given that [EFFICIENT-NPDAO] is still a draft,  I think this section should be> synchronized with the  draft so that we don't end up with one or the other new> RFC updating an RFC that doesn't yet exist.Yes, this was a discussion with Alvaro as well during his AD review and what you see is the outcome.In particular, this is one reason why [EFFICIENT-NPDAO] is referenced normatively. ED>  Hmm.  Maybe the rest of the IESG will have something to say about this.  > s14: Idnits notes that there is a normative reference to RFC 7102 which is> informational.  I note that this was not mentioned in the Last Call. However RFC> 7102 has already had one accepted Downref waiver and the summary of terms> is a suitable use case.Yes, this is a classical nit; the usual solution for that reference is that the AD accepts the downref and we move on.ED>  Indeed.  This point is just there for form's sake and to remind your AD that he has to fill in the downref registry  [and to remind him that the Last Call notice should have said.]> > Nits/editorial comments:> > General: s/byte/octet/gFun. Carsten asked us to do the exact inverse change. Being French I favor "octets" but really the IETF should provide a guidance here. I just cannot go back and force with each new review.ED> I've been advocating for octets for about 15 years!  > > Abstract:  Expand RPL on first use (currently done in s1.) Expand ND.Done it (relunctantly) for ND. RPL has been used as a noun by people of the art for a long while now. Expending it would turn the abstract in a book.ED>  I know, I know.  But it isn't in the RDC Editor's list of well-jnown abbreviations.  Sorry!> > Abstract:  Idnits produces a spurious warning about RFC 8505...> > -- The draft header indicates that this document updates RFC8505, but the> abstract doesn't seem to directly say this. It does mention RFC8505 though, so> this could be OK.Tool's limitation. > The abstract says> > This specification updates RFC6550, RFC6775, and RFC8505,> > which is fine by me.  I will report this to the  Tools team.> Yep. We're used to that one. We just learned to ignore it, not sure it's worth the extra code discerning all the language niceties that can be used here.ED> Bit of fun for Henrik!> s1, s2.2, s2.3: The term defined in [USEofRPLinfo] is RPL-Unaware-Leaf rather> than RPL-Unaware Leaf: s/RPL-Unaware Leaf/RPL-Unaware Leaf/ (3 places).> Similarly s/RPL-Aware Leaf/RPL-Aware-Leaf/ (1 place) and s/RPL-Aware> Node/RPL-Aware-node/ (2 places).Good point. In terms of English which makes more sense? We can fix either draft.I posted to the ROLL ML.ED> As I suggested above, I think I have a small preference for RPL-Unaware Leaf bu I don't care as long it used consistently across drafts.> s2.3, para 3:> >> > The term RPL-Aware Node (RAN) is introduced to refer to a node that is> > either> an RAL or a RPL Router. This term is already defined in [USEofRPLinfo] with,  I> understand, the same meaning. s3, para 1: s/detailed/summarized/ - the formal> details are in [USEofRPLinfo].Yep,  was updated 😊 I changed to "  This document uses the terms RPL-Unaware Leaf (RUL), RPL-Aware Node   (RAN) and RPL Aware Leaf (RAL) consistently with [USEofRPLinfo].  A   RAN is either an RAL or a RPL Router.  As opposed to a RUL, a RAN   manages the reachability of its addresses and prefixes by injecting   them in RPL by itself."And made the other proposed change as well.ED> Fine.> > s3. para 4: s/to transport a RPL Packet Information (RPI) [RFC6550]./to> transport the RPL Packet Information (RPI) [RFC6550]option./Well both are transported, but RFC 6550 defines the RPI as abstract information not as an option. And to make things simpler we typically abuse "RPI" to say "RPL Option".What about:"   The RPL data packets typically carry a Hop-by-Hop Header with a RPL   Option [RFC6553] that contains the Packet Information (RPI) defined   in section 11.2 of [RFC6550].  " ?ED> Fair enough.> > s3, para 4: '... except for the very special case above,' - I am not totally sure what> part of the section is being referred to by this.  Do you mean the case referred to> in the  previous sentence?  Please make this clearer.I gave it a try:"                                                     Unless the RUL already placed a RPL   Option in outer header chain, the packets from and to the RUL are   encapsulated using an IP-in-IP tunnel between the Root and the 6LR   that serves the RUL (see sections 7 and 8 of [USEofRPLinfo] for   details).  If the packet from the RUL has an RPI, the 6LR as a RPL   border router SHOULD rewrite the RPI to indicate the selected   Instance and set the flags, but it does not need to encapsulate the   packet."Works?ED> I believe so.> > s3, para 5: The jargon term 'going down' is used here without definition.  It is> sort of inherited from [USEofRPLinfo] (Section 8.3.1) but is not properly defined> there either.  Please improve and explain this jargon.These are defined in section 2 of RFC 6550, and very, very common in RPL parlance.I changed a sentence in section 2.2 to "  "RPL", the "RPL Packet Information" (RPI), "RPL Instance" (indexed by   a RPLInstanceID), "up", "down" are defined in "RPL: IPv6 Routing   Protocol for Low-Power and Lossy Networks" [RFC6550]"ED> That resolves that.> s3, para 5:  Might be sensible to add SRH to the glossary instead of expanding> here.Added. I kept the expansion though, in alignment with other acronyms in the glossary.ED> Fine.> s5, title:  s/RPL-Unware Leaf/RPL-Unware-Leaf/I delayed that one. ED> OK.. see above.> s6.3, para 2:> OLD:> This specification enables to carry the 6LoWPAN ND Status values in RPL DAO> and DCO messages, NEW: This specification adds a capability to allow the> carriage of 6LoWPAN ND Status values in RPL DAO and DCO messages, ENDSHeavy carriage! I'll trust you on this]ED> :-)> s9.2:  By convention, there should be a brief description of the purpose and> subsections before starting s9.2.1.  The RFC Editor doesn't like empty sectionsI never hit that one. Interesting. For some reason the ETSI editor will force the opposite.Done anyway.ED> Ah, the unwriten rules!> s9.2.3, item 1:  This would be a useful point to mention that the Target IPv6> address is marked by the F Flag being 1.Actually it is not. It is set to 0 per the previous section. But the Prefix Length is 128 indicating a host address (not that of the advertiser though, thus the 'F' flag set to 0).ED> I'll take your word for that!  The point I was trying to make was that given you have introduced the F Flag,  I think it would be highly desirable to explicitly highlight the point where an implementation would expect to set an F flag as well as places where it isn't set.  I thought there would be an opportunity somewhere in s9.2.1.Again, a great many thanks Elwyn!ED> Glad to be of assistance.  Nice to have an interesting document to review.Cheers,ElwynPascal_______________________________________________Gen-art mailing [email-masked]://www.ietf.org/mailman/listinfo/gen-art

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 15 Dec 2020 07:36:45 +0000

ED>  While I understand that it would be polite to involve 6LoWPAN, WGs don't 'own' RFCs and their associated IANA registries.  Since this draft 'needs' the extra information I personally wouldn't see a problem in asking for the extra column. It doesn't break anythng 6LoWPAN are doing AFAICS. Anyway that's not my call...  ask your AD.

PT> I posted a separate thread on this one.

ED>  Hmm.  Maybe the rest of the IESG will have something to say about this.
PT> Maybe I misunderstand what you mean by synchronize. Would you report the change in NPDAO?
PT> trouble is that spec is virtually RFC, stuck in MISSREF in cluster C 310, in particular by this doc.

ED>  I know, I know.  But it isn't in the RDC Editor's list of well-jnown abbreviations.  Sorry!

PT> It’s hard to recognized RPL in its full expansion. I tricked the text to avoid the acronym.
“
   This specification updates RFC6550, RFC6775, and RFC8505, to provide
   routing services to IPv6 Nodes that implement RFC6775, RFC8505, and
   their extensions therein, but do not support RFC6550.

“

ED> I'll take your word for that!  The point I was trying to make was that given you have introduced the F Flag,  I think it would be highly desirable to explicitly highlight the point where an implementation would expect to set an F flag as well as places where it isn't set.  I thought there would be an opportunity somewhere in s9.2.1.

  PT> You’re correct, we define the flag here because we change the Target Option but this spec is not the one that really needs it. It was an opportunistic insertion. This information is useful to test the path back when we advertise a prefix. It gives the root an address to ping within the advertised prefix. For Host routes, it’s only an indicator that the node is advertising self vs. another party, which in the case of this spec, is redundant with the ‘External’ flag.

Take care,

Pascal

_______________________________________________
Gen-art mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 16 Dec 2020 21:27:32 -0500

Elwyn, thanks for your review. Pascal, thanks for your responses. I entered a No Objection ballot.

Alissa

> On Dec 15, 2020, at 2:36 AM, Pascal Thubert (pthubert) <pthubert=[email-masked]> wrote:
> 
> Many Thanks Elwynd:
> 
> > 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>_______________________________________________
> Gen-art mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 17 Dec 2020 07:59:50 +0000

Many thanks again, Elwyn and Alissa.

From: Alissa Cooper <[email-masked]>
Sent: jeudi 17 décembre 2020 03:28
To: Pascal Thubert (pthubert) <[email-masked]>; Elwyn Davies <[email-masked]>
Cc: elwynd <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Gen-art] Genart last call review of draft-ietf-roll-unaware-leaves-24

Alissa

On Dec 15, 2020, at 2:36 AM, Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>> wrote:

“

Take care,

Pascal