Re: [dhcwg] Intdir last call review of draft-ietf-dhc-slap-quadrant-08

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

Thanks a lot for your detailed comments. I'll go through them and provide
our responses in the following days.

Carlos

On Mon, May 18, 2020 at 10:41 PM Tatuya Jinmei via Datatracker <
[e-mail]> wrote:

> 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
>
>
>
>