I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. 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 address to the given client out of the quadrant requested by relay or client. The document is generally clear but I do have a few comments listed below. That the security considerations were incorporated by reference seems fine. - The document should expand acronyms on first use, for example U/L in first sentence of section 1, instead of leaving these to referenced documents. - Figures 3 and 4 reference a timer expiring but the prose does not. Including verbiage similar to second paragraph in section 4.3 of draft-ietf-dhc-mac-assign-05 may be worth doing. - Section 3 may benefit from providing rationale for the preferences given, i.e., why might ELI/SAI be good, etc. Framing the criteria in terms of the quadrants instead of type of device may be helpful in addition as well, if a best practices type guidance is reasonable. - Also in Section 3, I am not familiar with the IEEE specs that govern the addresses associated with the SAI quadrant, but Section 3 created an impression that a client has a freehand to choose between SAI and other options that wouldn't seem appropriate for a quadrant governed by other standards. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
