Reviewer: Ines Robles Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dhc-slap-quadrant-09 Reviewer: Ines Robles Review Date: 2020-05-27 IETF LC End Date: 2020-05-27 IESG Telechat date: 2020-06-11 Summary: This document proposes extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server, so that the server allocates the MAC addresses to the given client out of the quadrant requested by relay or client. A new DHCPv6 option (OPTION_SLAP_QUAD, or QUAD) is defined for this purpose. The document is easy to read, however I have some minor issues/questions for the authors Major issues: Not found Minor issues: Section 1: 1- Should be specified for each quadrant who is responsible to ensure: a) uniqueness of assigned addresses and b) compatibility with other assignment protocols on the same LAN (if applicable)?, e.g for AAI, the administrator should be the responsible? 2- The caption in Figure 1, should state: "Initial octet of the IEEE 48-bit MAC address structure?" since you are representing 1 byte in the figure instead of the 6 bytes. Section 1.1.1: 3- Should be added "(IEEE 802.11)" to WiFi? 4- When it is mentioned IoT devices, I think it would be nice identify the use case with the class of device (RFC7228) instead of "there are a lot of cheap, sometimes short lived and disposable devices". I am not sure if cheap is a right word here, since it is subjective, I mean it has to be defined what is considerate cheap. Relate with -short lived- it could be due to a malfunction that the device gets broken, thus I suggest use battery-powered device or similar. Thus, it could be: "IoT (Internet of Things): In general, composed of constrained devices [RFC7228] with constrains such as ..." Note: There is another document taking place for IoT terminology [draft-bormann-lwig-7228bis] 5- Related to: " This type of device is typically not moving". Do you have a reference for this? Following my understanding there is a huge amount of smart health devices that are mobile Section 2: 6- It would be nice to add the definition and expansion for IA_LL and LLADDR Section 3: 7- Related to "Managed/unmanaged: depending on whether the IoT device is managed during its lifetime or cannot be re-configured the selected quadrant might be different...." 7.1-It would be nice to describe the example referencing the management during the life cycle (rfc7548#section-3) 7.2- The sentence is not fully clear to me. "quadrant might be different" would it be better: "the quadrant might change when the device gets a configuration update"? Or the draft refers self-managed devices (rfc7547#section-3.5) gets a quadrant different to those managed by a manager server? There are specific quadrant recommendations for different IoT configuration functionality levels (RFC7547, section 1.7)? 7.3 "it can be managed, this means that network topology changes might occur during its lifetime": Would it be better to explain this based on the Dynamicity level of the network topology (rfc7547#section1.3), for example smth like: "networks with high dinamicity level have high probability of quadrant changes", does it make sense? Section 7: Should the security considerations section includes reference to the security section and privacy considerations of RFC7227? Nits/editorial comments: Not found Thank you for this document, Ines -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
