Hello Lars, Thank you for your review and comments.
Please find my response inline. Remy -----邮件原件----- 发件人: Lars Eggert via Datatracker [mailto:[email protected]] 发送时间: 2021年8月6日 16:08 收件人: The IESG <[email protected]> 抄送: [email protected]; [email protected]; [email protected]; Carles Gomez <[email protected]>; [email protected] 主题: 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). _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
