[6lo] comments on on draft-ietf-6lo-plc-02

[Michael Richardson <[e-mail]>]

Some comments/nits:
1) update your RFC2119 text to tbe BCP14 template.

2) change:
Compared to
   [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks], this document
   provides a structured and greatly expanded specification of an
   adaptation layer for IPv6 over PLC (6LoPLC) networks.

to:
There was work previously proposed as [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks]
which did not reach consensus.  This document provides a more structured
specification than the previous work, expanding to a larger variety of PLC
networks.

{assuming that I got it right}

3)    PAN device:  An entity follows the PLC standards and implements the
         protocol stack described in this draft.

to:
   PLC/PAN device:  An entity that follows the PLC standards and implements the
         protocol stack described in this draft.

4) the table mapping is good.  Can you add a fourth column which is the term
   that this document will use?
   Or maybe put a (*) next to the name used.

5) comma after "e.g." -> "e.g.," {don't ask me why}

6) split up section 3.0 into multiple paragraphs.
   maybe: Various...
          Moreoever,...
          Currently,...

7) I don't know if you are numbering your figures and tables manually or if
   xml2rfc is doing it. Maybe they should be numbered from the same sequence.
   I never looked at what xml2rfc does anyway.  Not a big deal.

8) 3.1,
   The routes can be built in mesh-under
   mode at layer 2 or in route-over mode at layer 3
        add: as explained in section 3.4.


9) section 3.2:
   Each PLC device joins the network by using the long address and
   communicates with other devices by using the short address after
   joining the network.
           add "Short addresses can be assigned during the onboarding
               process, such as by using CoJP [I.D-ietf-6tisch-minimal-security]"

10) You will get pushback by using RFC4291 on privacy issues.
    I would change that.

Rewrite to say:
   As explained in [RFC4291], the IPv6 link-local address for a PLC interface
   may be formed by appending the IID, as defined above, to the prefix FE80::/64 (see
   Figure 2).  Implementations should look at RFC8064 as well.

11) section 4.4
    In this case, the prefix information option
    (PIO) MUST NOT be included in the Router Advertisement.

that isn't necessarily the case.  The rpl-unaware-leaves document says more,
and probably should be referenced instead.

12) section 7.

>   Malicious PLC devices could paralyze the whole network via DOS attacks,
>   e.g., keep joining and leaving the network frequently, or multicast
>   routing messages containing fake metrics.  The security can be enhanced
>   by using DTLS to authenticate a PLC device when it enrolles itself.  If
>   the PLC device is not direct neighbor to the PANC, where the authenticate
>   is conducted, another PLC device which has joined the network can act as
>   a proxy to help exchange the authenticate messages.  The key used for
>   encryption can also be negociated via DTLS.

"Just use DTLS" doesn't really work.
Please reference 6tisch-minimal-security instead.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-