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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 23 April 2020 16:05 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6928E3A0B3D for <6lo@ietfa.amsl.com>; Thu, 23 Apr 2020 09:05:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hQ_ClVQ5mAcK for <6lo@ietfa.amsl.com>; Thu, 23 Apr 2020 09:05:13 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24B13A0B3B for <6lo@ietf.org>; Thu, 23 Apr 2020 09:05:12 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca []) by tuna.sandelman.ca (Postfix) with ESMTP id E376D3818F for <6lo@ietf.org>; Thu, 23 Apr 2020 12:03:22 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4E457D8C for <6lo@ietf.org>; Thu, 23 Apr 2020 12:05:11 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: 6lo@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 23 Apr 2020 12:05:11 -0400
Message-ID: <8510.1587657911@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/EKtXSMPRjImqOQ-sP_C3viOTqmI>
Subject: [6lo] comments on on draft-ietf-6lo-plc-02
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Apr 2020 16:05:16 -0000

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.

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

{assuming that I got it right}

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

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

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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-