[6lo] Éric Vyncke's Discuss on draft-ietf-6lo-plc-06: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-6lo-plc-06: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this document.

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,
[e-mail], is not in the datatracker status page.

Please find below some blocking DISCUSS points (probably easy to address), 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 ==

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.


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

== 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/ ?