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

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

Dear Tatuya,

Thanks a lot again for your comments. Please see inline below some comments
and responses from my side.

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

[Carlos] Yes, in that case the expected behaviour would be that the client
does not choose any server. This is basically the same that happens with
other DHCP extensions. In any case, the text you referred to above was more
to describe what the client should do if the server supports the QUAD
option, but still does not have addresses available from the selected
quadrant.


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

[Carlos] Yes. If the currently assigned addresses cannot be renewed, then
the server will try to allocate different (that's what "new" means)
addresses from the same quadrant. We have added "different" to the text in
version -09 to make this clearer.


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

[Carlos] That's a good point. When we wrote this we thought that the
sentence "Depending on the server's policy, the instance(s) of the option
to process is selected." in 4.2-3 would be sufficient as a reference for
what comes at the end of Section 4.2 (which is indeed the answer to your
point). I think adding a more explicit reference would make the text
unnecessary long. What do you think?


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

[Carlos] It means that the option includes pairs (tuples) of quadrant-n &
pref-n. Would it be clearer if we use "pair" instead of tuple?


> - 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.
>
> [Carlos] Maybe is an English issue here (note that I'm not a native
speaker). What we mean is that if the server does not have at least
addresses from one of the specified quadrants, it must not assign any. So
if Q1 and Q2 are requested, and the server has only addresses from Q1, this
is fine and it should proceed with the assignment for Q1. Only if the
server does not have addresses from neither Q1 or Q2 it should return
NoQuadAvail.


> Nits
> Section 2: s/in in/in/
>    relay         A node that acts as an intermediary to deliver DHCP
> [...]
>                  functionality as described in in [RFC8415].
>

[Carlos] Thanks! Fixed in future version -09.

>
> Section 2: s/it can be/if it can be/ ?
>       quadrant might be different.  For example, it can be managed, this
>

[Carlos] Thanks! Fixed in future version -09.

Thanks a lot!

Carlos