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

From: "Liubing (Remy)" <[email-masked]>
Date: Thu, 23 Sep 2021 03:22:06 +0000

Hello Lars,

Thank you for your review and comments.

Please find my response inline.

Remy

-----邮件原件-----
发件人: Lars Eggert via Datatracker [mailto:[email-masked]] 
发送时间: 2021年8月6日 16:08
收件人: The IESG <[email-masked]>
抄送: [email-masked]; [email-masked]; [email-masked]; Carles Gomez <[email-masked]>; [email-masked]
主题: Lars Eggert's No Objection on draft-ietf-6lo-plc-06: (with COMMENT)

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?

[Remy] In the implementations that I met, TCP and UDP are common. However, without losing generality, "Transport Layer" is a better term.

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".
[Remy] Will change the terms.
-------------------------------------------------------------------------------
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).