Transmission of IPv6 Packets over Power Line Communication (PLC) Networks
draft-ietf-6lo-plc-11

I also support Roman's and Eric's DISCUSS positions.

Section 2 needs to be reviewed.  It defines "CID", "EV", "IPHC", "LAN", "MSDU", "OFDM", and "PSDU", but these terms are not used anywhere in the document.  It also defines "WAN" which is not used, though "LPWAN" is used yet not defined.

Please also define "6LR" someplace, or refer to its definition.  It first appears in Section 4.4, along with "6LBR" and "6BBR".  Perhaps there should be a mention of the 6LowPAN RFC in the Definitions section to import all of these definitions.

Thank you to Robert Sparks for the SECDIR review.

Thank you for addressing my COMMENTs and DISCUSS points.

Unsurprisingly, I also support Roman's and Eric's DISCUSS positions.

Thanks for working on this document and Thanks to Joe Touch for the TSVART review.

Thank you for the work put into this document.

Thank you also for addressing all my blocking points (except for the paywall for normative references) and most of my comments, either on the mailing list or in the document itself. I am therefore clearing up my DISCUSS ballot. 

Special thanks to Carles Gomez for his shepherd's write-up, which contains a good summary of the WG consensus *BUT* it does not mention that the IEEE normative references are not free. Strange that Carles' email address, carlesgo@entel.upc.edu, is not in the datatracker status page.

Please find below some *archived* DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated), and some nits.

Please also address Dave Thaler's INT-DIR review at:
https://datatracker.ietf.org/doc/review-ietf-6lo-plc-06-intdir-telechat-thaler-2021-08-06/ (some of my DISCUSS points are coming from Dave's review)

I hope that this helps to improve the document,

Regards,

-éric


== DISCUSS (for archiving not more standing/blocking) ==

Is there any reason why the IETF Last Call https://mailarchive.ietf.org/arch/msg/6lo/f59y8rMg-p_aCKYSSEtBzoJK4qQ/ did not mention that the two IEEE normative references were behind a paywall ? It prevented some more detailed reviews and is an important fact.

How can a PLC node distinguish between an IPv6 PDU and a non-IPv6 PDU ? I.e., is there the equivalent of a EtherType in a layer-2 PLC PDU ? Then, this should be mentioned in this document else some text explaining why it is not required would be welcome. Especially when the normative IEEE references are not freely available.

-- Section 4.1 --
I am repeating here Dave Thaler's point 1) as it is completely unclear to me how the shared secret/version number are shared and provisioned, this could prevent interoperation hence my DISCUSS.

While I appreciate that the nodes are constrained, some warnings about having a *single global IPv6 address* should be written or if the spec supports more than one global IPv6 address per node, then the current text must be changed.


== COMMENTS ==

A generic and probably naive question of mine: how can a PLC node (which has access to electrical power) can be qualified as 'low power' ? 

-- Section 2 --

Please add references to the IEEE references before using them in the table 1.

-- Section 3.1 --

Is the I-D limited to TCP & UDP only ? (based on figure 1 even if later RPL is mentioned)

-- Section 3.4 --

While not required, an expansion of "LOAD" as in "LOADng" will probably be welcome by readers.

-- Section 4.1 --

Strongly suggest to show the 48-bit pseudo MAC address before showing the generated 64-bit address, which looks like the old EUI-64 generation. Should there be some explanation about the lack of U/L bit flapping in this algorithm ?

Same comment for the 12-bit address.

Should there be some explanations about NID and TEI? Notably about how they are provisioned and how can collision be prevented.

  "A PLC host SHOULD use
   the IID derived from the link-layer short address to configure the
   IPv6 address used for communication with the public network"
Is the above text about how to provision the IP address ? E.g., via stateful DHCPv6 ?

-- Section 4.3.1 --
  "In order to avoid the possibility of duplicated IPv6 addresses, the
   value of the NID MUST be chosen so that the 7th and 8th bits of the
   first byte of the NID are both zero."
I failed to understand the reasoning in the above text: how can a reduction of entropy decrease the risk of collision ?

Please also specify the receiver's behavior when the padding is not 0 (probably 'ignore').

Rather than using "7th and 8th bits" please use "bits 6 and 7".

-- Section 4.3.2 --
Same comments as for section 4.3.1

-- Section 4.4 --
   "Although PLC devices are electrically powered, sleeping mode SHOULD
   still be used for power saving."
Suggest to add some justification for the "SHOULD" or at least explain when a PLC device may not use the sleeping mode.

The logical flow is weird in §4 " Duplicate Address Detection (DAD) MUST NOT be utilized.  Otherwise, the DAD MUST", i.e., with a "MUST NOT" there should be no "Otherwise" :-) The "MUST NOT" is probably a "SHOULD NOT" ?

-- Section 5 --
Nice and interesting section, may I suggest to move it earlier in the document ? Just after the introduction for example.

Figure 6 does not have any node "A" or "B" while the § before mentions those node names.

== NITS ==

I find it strange that some acronyms are sometimes expanded in the text *and* in the terminology (e.g., MTU) while others are not (e.g., PANC).

-- Section 3.3 --
Is "adapt" the right word in "For this reason, fragmentation and reassembly is required for G.9903-based networks to adapt IPv6."

-- Section 3.4 --
My eyebrows raised when reading "L2 routing"... as "routing" for me is usually reserved for layer 3 and above.

-- Section 4.4 --
s/For IPv6 address prefix dissemination/For IPv6 network prefix dissemination/ ?

I support Roman's and Eric's DISCUSS positions.

Otherwise, just a couple of nits:

s/which may includes/which may include

Expand DIO.

s/participate to RPL/participate in RPL

I'm not a big fan of using the "someone else did it already" excuse,
especially when there is a simple technical alternative available (do more
complicated bitslicing to avoid using bits whose semantics would be
overloaded), but the new discussion in §4.1 about the interaction with the
Universal/Local and Individual/Group bits does seem to provide an ample
discussion of the situation so as to let operators make an informed
choice.  Accordingly, I am (reluctantly) demoting this topic from the
DISCUSS section to the COMMENT section.

Going from the -06 to the -10 (I didn't peek within that range to see
exactly when the change occurred) the description of Source Address Mode
address compression in §4.5 had the prose change from describing 12 bits
carried in line to 16 bits carried in line (with corresponding change in
the number of bits elided).  It looks like this was done in response to
one of my comments about preserving byte alignment, and so the "new" four
bits are expected to be all zeros, which would justify using the "0XXX"
expression that is present in the -10.  However, it would probably be
worth stating explicitly that the four bits represented by the "0" are
indeed always zero.  Additionally, in the new chunk of text for
Destination Address Mode, we are inconsistent about whether it is "0XXX"
or "XXXX" that is carried in-line.  My recollection is that both stateless
and stateful compression in DAM should be copying the same set of bits.

Thank you for the vastly expanded security considerations section; it's a
big improvement.

Section 4

   A PLC node distinguishes between an IPv6 PDU and a non-IPv6 PDU based
   on the equivalent of a EtherType in a layer-2 PLC PDU.  [RFC7973]
   defines a Ethertype of "A0ED" for LoWPAN encapsulation, and this
   information can be carried in the IE field in the MAC header of
   [IEEE_1901.2] or [ITU-T_G.9903].  [...]

"Can be carried in the IE field", or "the IE field is defined to
carry..."?  Is this text subtly redefining the usage of the IEEE
specification's fields?


NITS

Section 4.1

   For privacy reasons, the IID derived from the MAC address (with
   padding and bits flipping) SHOULD only be used for link-local address

I would suggest s/padding and bits flipping/padding and bit clamping/ --
"flipping" has a connotation of changing the state of the bit, whatever
the current state is, whereas "clamping" implies forcing a speficic value
(as we do towards zero).  Also, "bit" singular is appropriate for the
abstract operation, even though we do specify that two bits are affected.

Section 4.5

   instead of 16 bits.  The only modification is the semantics of the
   "Source Address Mode" and the "Dstination Address Mode" when set as

s/Dstination/Destination/

Section 8

s/valide/valid/
s/more severer/more severe/

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).

Thanks to Joe Touch for the TSVART review.

No objections.

I spotted a typo "devcie" for "device" but I suspect that the RFC editor would also fix that anyway ...