[6lo] Lars Eggert's No Objection on draft-ietf-6lo-plc-06: (with COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-6lo-plc-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-plc/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3.1. , paragraph 4, comment:
>                        Figure 1: PLC Protocol Stack

Since this says "TCP/UDP", are other transport protocols not supported? Or else
should this say "Transport Layer" instead?

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "master"; alternatives might be "active", "central", "initiator",
   "leader", "main", "orchestrator", "parent", "primary", "server".

 * Term "natively"; alternatives might be "built-in", "fundamental",
   "ingrained", "intrinsic", "original".

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1. , paragraph 3, nit:
-    been fully adapted for IPv6 based constrained networks.  The
-                               ^
-    resource-constrained IoT related scenarios lie in the low voltage PLC
-                            ^
+    been fully adapted for IPv6-based constrained networks.  The
+                               ^
+    resource-constrained IoT-related scenarios lie in the low voltage PLC
+                            ^

Section 1. , paragraph 3, nit:
-    networks, due to its large address space and efficent address auto-
+    networks, due to its large address space and efficient address auto-
+                                                      +

Section 1. , paragraph 4, nit:
-    them have LLN (low power and lossy network) characteristics, i.e.
+    them have LLN (low power and lossy network) characteristics, i.e.,
+                                                                     +

Section 3.3. , paragraph 4, nit:
-    MTU in high-noise communication environment.  Thus the 6lo functions,
+    MTU in high-noise communication environments.  Thus, the 6lo functions,
+                                               +       +

Section 3.3. , paragraph 5, nit:
-    required for G.9903-based networks to adapt IPv6.
-                                           ^^^^
+    required for G.9903-based networks to carry IPv6.
+                                          + ^^^

Section 3.4. , paragraph 3, nit:
-       is a layer 3 routing protocol.  AODV-RPL [I-D.ietf-roll-aodv-rpl]
-                 ^
+       is a layer-3 routing protocol.  AODV-RPL [I-D.ietf-roll-aodv-rpl]
+                 ^

Section 3.4. , paragraph 4, nit:
-    o  IEEE 1901.1 supports L2 routing.  Each PLC node maintains a L2
+    o  IEEE 1901.1 supports L2 routing.  Each PLC node maintains an L2
+                                                                  +

Section 4. , paragraph 2, nit:
-    [RFC8505] provides useful functionality including link-local IPv6
-                     -
+    [RFC8505] provide useful functionality including link-local IPv6

Section 4.4. , paragraph 3, nit:
-    layer 3 routing protocol, such as RPL, which may includes the prefix
-         ^
+    layer-3 routing protocol, such as RPL, which may includes the prefix
+         ^

Section 4.4. , paragraph 5, nit:
-    sending Neighbor Solicitaitons in order to extract the status
-                              -
+    sending Neighbor Solicitations in order to extract the status
+                             +

Section 4.6. , paragraph 3, nit:
-    octects, the fragmentation and reassembly defined in [RFC4944] MUST
-        -
+    octets, the fragmentation and reassembly defined in [RFC4944] MUST

Section 4.6. , paragraph 5, nit:
-    frequent incorrectly assembled IP fragments.  For constranied PLC,
-                                                              -
+    frequent incorrectly assembled IP fragments.  For constrained PLC,
+                                                             +

Section 4.6. , paragraph 5, nit:
-    thus the 16-bit tag is sufficient to assemble the fragements
-                                                          -
+    thus the 16-bit tag is sufficient to assemble the fragments

Section 4.4. , paragraph 6, nit:
> ets and 1576 octets respectively. However when the channel condition is nois
>                                   ^^^^^^^
A comma may be missing after the conjunctive/linking adverb "However".

Document references draft-ietf-emu-eap-noob-03, but -05 is the latest available
revision.

Document references draft-ietf-6tisch-minimal-security, but that has been
published as RFC9031.

Obsolete reference to RFC4941, obsoleted by RFC8981 (this may be on purpose).

Document references draft-ietf-roll-aodv-rpl-08, but -10 is the latest
available revision.

Document references draft-ietf-roll-unaware-leaves, but that has been published
as RFC9010.

Obsolete reference to RFC3315, obsoleted by RFC8415 (this may be on purpose).