Hello Remy, First of all, sorry for the late response.
Thanks for taking my comments into consideration. Please find below my inline responses (labeled [Carles]): > Hello Carles, > > Thank you very much for your detailed review. [Carles] You are welcome! > We accept most of your suggestions. [Carles] Thanks! > Meanwhile, items that need further > discussion are posted below. > > 1. This specification provides a brief overview of PLC technologies. > Some of them have LLN characteristics, i.e. limited power > > Just a weak suggestion: LLN is a recognized term in many domains. > Nevertheless, feel free to consider using "Constrained-Node Network (CNN) > (see RFC 7228). > [Remy] Maybe LLN is a better choice since it is used in many RFCs in IOT > domain as well. Thank you for your suggestion though. [Carles] Feel free to use the term that you prefer. > 2. RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] > is a layer 3 routing protocol. AODV-RPL [I-D.ietf-roll-aodv-rpl] > updates RPL to include reactive, point-to-point, and asymmetric > routing. IEEE 1901.2 specifies Information Elements (IEs) with > MAC layer metrics, which can be provided to L3 routing protocol > for parent selection. For IPv6-addressable PLC networks, a > layer-3 routing protocol such as RPL and/or AODV-RPL SHOULD be > supported in the standard. > > Why "SHOULD"? And if "SHOULD" is the right term here, perhaps add some > clarification on reasons or circumstances motivating using a protocol > different from RPL and/or AODV-RPL? > [Remy] Yes, this sentence makes people confused. The reason why "SHOULD" > is used is that we have other options like L2-routing and LOADng. But this > sentence looks redundant now, because the whole section is talking about > the three options. Do you think it is OK to remove this sentence? [Carles] Yes, I agree to remove this sentence. > 3. IEEE 1901.1 supports 12-bit and 48-bit addresses. Header compression > over IEEE 1901.1 will need some form of adaptation, since RFC 6282 refers > to 16-bit and 64-bit addresses. > [Remy] Yes, we need adaptation. How to generate IID from 12-bit (1901.1), > 16-bit (G.9903 and 1901.2) and 48-bit address is defined in section 4.1 > (Stateless Address Autoconfiguration). And using the same method, the > original IPv6 address can be recovered from the L2 address. Thus that's > where the adaptation is defined. It may be not explicit enough. Actually, > the encoding format defined in RFC6282 applies to all the PLC technologies > mentioned in this draft. The only difference is: for 1901.1, when the SAM > or DAM in RFC6282 is set to 2, it means the source or destination IPv6 > address is compressed to 12 bits instead of 16bits. [Carles] In my opinion, adding some more explicit note would be helpful. > 4. PAN Coordinator (PANC) and PAN Device. The PANC is the primary > coordinator of the PLC subnet and can be seen as a master node; PAN > Devices are typically PLC meters and sensors. The PANC also serves > as the Routing Registrar for proxy registration and DAD procedures, > making use of the updated registration procedures in [RFC8505]. IPv6 > over PLC networks are built as tree, mesh or star according to the > use cases. Every network requires at least one PANC to communicate > with each PAN Device. > > The last sentence was unclear. Who/What communicates with each PAN > Device? > [Remy] We meant "the PANC communicates with the PAN devices". We try to > rephrase: Generally, each PLC network has one PANC. In some cases, the PLC > network can have alternate coordinators to replace the PANC when the PANC > leaves the network for some reason. [Carles] Your new proposed text looks good to me. > 5. What is the subnet model for the scenarios illustrated in this > section? > For example, is the "PLC subnet" a multilink subnet? Is each link in the > "PLC subnet" a subnet? > [Remy] It is a multilink subnet, instead of "each link is a subnet". [Carles] Thanks. Please add some text on this feature to the document. Best regards, Carles > Best regards, > Remy _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
