I am an assigned INT directorate reviewer for draft-ietf-6lo-plc-06.txt. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ . Overall I found the document to be fairly well written and understandable. There were a couple of areas though where I think additional elaboration is needed. Technical comments: 1) Page 8 talks about "the" IPv6 address used for communication with the public network, implying there can only be one at a time. This is not normal in IPv6, where you can have a public address, the current temporary address, and the previous temporary address (to allow for transition to a new one), all at the same time. Should this be changed to be plural? If not, how do you support privacy addresses in IPv6? What about cases where you have external connectivity to two public networks each with its own prefix? I don't see this answered anywhere in the doc. 2) Page 8 also mentions that a shared secret "or" version number can be used in a hash to derive an IID, but never defines any hash details. To me, that implies that this document currently does not provide any guarantee of interoperability, in which case why do you need an IETF RFC at all if every device has to come from the same vendor with an algorithm not specified in the standard? I expected this document to specify the details of a hash algorithm that must be implemented. 3) RFC 8065 explains that privacy of IPv6 link-local addresses is typically uninteresting because on broadcast media all devices can see all the link-layer addresses and mappings anyway. At least in the star and tree topologies, I suspect this is not the case. However the document doesn't seem to contain any discussion of the privacy considerations in such a case. 4) RFC 8065 section 4 provides a checklist of what adaptation layer documents like this need to address. I'd recommend addressing each point separately in the Security Considerations section, so it's clear that the draft addresses the whole checklist. For example, there's nothing in the document that mentions what the typical link lifetime is (years maybe?) As another example, it's really hard to tell from reading the last paragraph of section 4.5 of this draft how it addresses RFC 8065's statement that "any specification using Short Addresses should carefully construct an IID generation mechanism so as to provide sufficient entropy compared to the link lifetime" so elaboration here is warranted here in my opinion. I also have some editorial nits that can be found in a marked up copy at https://www.microsoft.com/en-us/research/uploads/prod/2021/08/draft-ietf-6lo-plc-06.pdf Dave