Reviewer: Tatuya Jinmei Review result: Ready with Issues I am an assigned INT directorate reviewer for draft-ietf-dhc-slap-quadrant. 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/ This draft defines a new DHCPv6 option that is supposed to be used with draft-ietf-dhc-mac-assign. The new option makes it possible for a client to specify its preferred "type" (SLAP) of MAC addresses to be assigned and for the server to make the assignment decision based on the preference. The draft is generally well written. I think it's basically ready, but there are several points not very clear to me. I guess these are largely editorial glitches or simply due to my lack of understanding of the background rather than substantial technical issues. As a reader I'd feel happy if my questions are clarified, but I'd leave these to authors. Specific comments: - Section 4.1-3 [...] The client SHOULD NOT pick a server that does not advertise an address in the requested quadrant. Does this mean if a client follows this "SHOULD NOT" and receives Advertise messages from servers that don't understand the new QUAD option, then the client can't choose any server? If so, is it okay? - Section 4.1: 5. When the assigned addresses are about to expire, the client sends a Renew message. 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" addresses. It's not clear to me what 'the preferred quadrants are known for the allocation of any "new" addresses' means. Does this mean the server will assign a new address from the specified quadrant(s) in response to the Renew in this situation? - Section 4.2-3 The preference between client's supplied QUAD and relay supplied QUAD (or whether it matters) isn't clear to me. What if these are inconsistent? Perhaps this paragraph at the end of Section 4.2 answers the question? The server SHOULD implement a configuration parameter to deal with the case where the client's DHCP message contains an instance of OPTION_SLAP_QUAD, and the relay adds a second instance in its relay- forward message. [...] If so, it might be more reader friendly if 4.2-3 gives a forward reference to this consideration. Also, this paragraph seems to suggest the server may (only) process the relay's instance of the QUAD option. If so, and it's incompatible with the client's option, then I guess the same question as Section 4.1-3 applies here. - Section 5.1 [...] Note that a quadrant - preference tuple is used in this option (instead of using a list of quadrants ordered by preference) to support the case whereby a client really has no preference between two or three quadrants, leaving the decision to the server. What does "a quadrant - preference tuple is used in this option" mean? >From the context I guess it tries to talk about using the same preference for multiple quadrants, but the actual text doesn't really read that way to me... - Section 5.1 [...] If the server can provide an assignment from one of the specified quadrants, it SHOULD proceed with the assignment. If the server cannot provide an assignment from one of the specified quadrant-n fields, it MUST NOT assign any addresses and return a status of NoQuadAvail (IANA-2) in the IA_LL Option. The first and second sentece seem to contradict each other. If, for example, two quadrants Q1 and Q2 are specified and the server can only provide an assignment for Q1, what should it do? The first sentence seems to say the server should proceed with the assignemtn for Q1; the second sentence seems to say the server MUST NOT assign any address and simply return NoQuadAvail. BTW, the second sentence also seems to contradict Section 4.1? 4.1-2 states: [...] If the client specified more than one SLAP quadrant, the server MUST only return a NoQuadAvail status code if no address pool(s) configured at the server match any of the specified SLAP quadrants. Nits Section 2: s/in in/in/ relay A node that acts as an intermediary to deliver DHCP [...] functionality as described in in [RFC8415]. Section 2: s/it can be/if it can be/ ? quadrant might be different. For example, it can be managed, this -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
