Reviewer: Tatuya Jinmei Review result: Ready with Nits I am an assigned INT directorate reviewer for draft-ietf-dhc-mac-assign. 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/ . I've reviewed draft-ietf-dhc-mac-assign-06 (07 was submitted while I was reviewing 06, and I also checked 07 on some specific points to see if it's changed, but the check is not comprehensive so some comments may be already moot or addressed.) I think this draft is basically ready. Its purpose and protocol details are well written, and the protocol is generally a straightforward application of the basic DHCPv6 (IP) address assignment protocol as described in RFC8415. I didn't find any obvious problem. My comments are largely editorial. The first one for Section 8 may need some discussion, but I'd basically leave the authors whether/how to address the comments including this one. Specific comments: - Section 1: The IEEE originally set aside half of the 48-bit MAC Address space for local use (where the U/L bit is set to 1). In 2017, the IEEE specified an optional specification (IEEE 802c) that divides this space into quadrants (Standards Assigned Identifier, Extended Local Identifier, Administratively Assigned Identifier, and a Reserved quadrant) - more details are in Appendix A. I wonder whether this paragraph could refer to draft-ietf-dhc-slap-quadrant. - Section 4 Clients implementing this mechanism SHOULD use the Rapid Commit option as specified in Section 5.1 and 18.2.1 of [RFC8415]. Just out of curiosity, what's the rationale of this SHOULD? (It's not obvious to me and) it doesn't seem to be explained anywhere in the draft. - Section 8 [...] The server MUST NOT shrink or expand the address block - once a block is assigned and has a non-zero valid lifetime, its size, starting address, and ending address MUST NOT change. We may need some clarification on the implication of this requirement on the following description of draft-ietf-dhc-slap-quadrant-09: [...] It includes the preferred SLAP quadrant(s) in the new QUAD IA_LL-option, so in case the server is unable to extend the lifetime on the existing address(es), the preferred quadrants are known for the allocation of any "new" (i.e., different) addresses. (Section 4.1-5) since on the surface of it, this could read as if it's against the MUST NOT. - Section 8 same text as the previous bullet While commenting on the previous point I've noticed one minor possible glitch: while "its size, starting address, and ending address MUST NOT change" prohibits any kind of change to the block, "MUST NOT shrink or expand the address block" sounds like only limiting a particular type of change (shrink or expand). So ,it's not 100% cleear, for example, if changing "start=02:04:06:08:0a, size=1 (extra-addresses=0)" to "start=02:04:06:08:0b, size=1" is allowed or not because this change does not "shrink or expand" the previos block. I believe the actual intent is the latter MUST NOT, i.e., prohibiting any kind of change, so we might rather say: [...] The server MUST NOT change the address block (including shrinking or expanding it) - once a block is assigned and has a non-zero valid lifetime, its size and starting address MUST NOT change. (btw I've removed "ending address" for another editorial cleanup because it seemed redundant - given it's a "block", the "ending address" is determined from the starting address and its size, and the "ending address" doesn't appear in the protocol explicitly). - Section 10 It may be too obvious, but you might want to clarify that the option field values are in network byte order (similar to Section 8 of RFC8415, for example). - Section 10.2 option-len 12 + link-layer-len field (typically 6) + length of "link-layer-len field value" may be better? Nit - Section 7: s/chose/choose/ [...] However, the server MAY chose to ignore some or all parameters of the requested address block. [...] -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
