Hello Michael, Thank you very much for your comments. We would love to follow your suggestions and make changes in the upcoming version in a couple of days.
Please check my response below. Best regards, Remy -----邮件原件----- 发件人: 6lo [mailto:[email protected]] 代表 Michael Richardson 发送时间: 2020年4月24日 0:05 收件人: [email protected] 主题: [6lo] comments on on draft-ietf-6lo-plc-02 Some comments/nits: 1) update your RFC2119 text to tbe BCP14 template. [Remy] Will do. 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} [Remy] You're 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. [Remy] Good suggestion. 5) comma after "e.g." -> "e.g.," {don't ask me why} [Remy] Lesson learnt. 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. [Remy] We were doing it manually. Will double check it. 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]" [Remy] Of course CoJP is one possible option, but before that each PLC technology has its own way to assign the short address. How about making the text like this: Short addresses can be assigned during the onboarding process, by the PANC or the JRC in 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. [Remy] You're right about this. MUST NOT is too heavy. It should be allowed to configure a PLC device to be a leaf, and RPL-unaware. In this case, the leaf device has to learn the prefix form the PIO carried in RA. 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. [Remy] You're right that we need more clarification here. We meant to use DTLS to transport the certificate to authenticate the PLC-PAN device. Alternatively, PSK(pre-shared keys) can also be used to authenticate a device as per [I.D-ietf-6tisch-minimal-security]. How about changing the text as follows: 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. A device may also join a wrong or even malicious network, exposing its data to illegal users. Thus it is highly recommended to conduct a mutual authentication between the network and the device tending to join in it. Pre-installed certificates can be transported over DTLS to facilitate the authentication. Alternatively, as per [I.D-ietf-6tisch-minimal-security], provisioning a unique pre-shared keys (PSKs) to each PLC device is also feasible. In both cases, if the PLC device is not direct neighbor to the PANC/JRC, where the authenticate is conducted, another PLC device which has joined the network can act as a proxy to help exchange the authentication messages. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
