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

From: Tatuya Jinmei via Datatracker <[email-masked]>
Date: Mon, 18 May 2020 13:41:26 -0700

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

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Tue, 19 May 2020 16:32:57 +0200

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 <
[email-masked]> wrote:

> on the INT Directorate, see
> https://datatracker.ietf.org/group/intdir/about/
>

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Wed, 27 May 2020 18:55:57 +0200

Dear Tatuya,

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

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

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

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

> preference for multiple quadrants, but the actual text doesn't really

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

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

>                  functionality as described in in [RFC8415].

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

>       quadrant might be different.  For example, it can be managed, this

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

Thanks a lot!

Carlos

---

From: 神明達哉 <[email-masked]>
Date: Fri, 29 May 2020 09:49:21 -0700

At Wed, 27 May 2020 18:55:57 +0200,

> option, but still does not have addresses available from the selected

I understand that (what this text is about).  My question was about
the compatibility with legacy servers and newer clients.  I don't know
of other similar cases in DHCP(v6) extensions, but in any case if
breaking the compatibility is the intent, I don't oppose that.  I just
wanted to make sure if it's intentional.

> version -09 to make this clearer.

Hmm, isn't it different from what the server would do with Renew for
other types of IAs?  (Assuming that's correct) being different itself
isn't necessarily wrong, but in that case I'd like to see an
explanation on why it differs.

BTW, "what 'new' means" isn't an issue for me, so the change in 09
doesn't affect my point.

> unnecessary long. What do you think?

I don't think it "unnecessarily long" to add a short forward reference
like "see also at the end of this section" after "Depending on ...is
selected", but these are all about readability, which is generally
subjective.  If you believe the current text is the best I don't
oppose.

> pref-n. Would it be clearer if we use "pair" instead of tuple?

Ah, I now see where my confusion comes from.  On my first read I
misunderstood that this entire text talks about some actual protocol
behavior, but now I see the text after "Note that..." explains your
design choice (correct?).  Now that I (hopefully) understand it's
difficult to suggest how to prevent the same kind of confusion, but
I'd perhaps say, e.g.

   If the same preference value is used for more than one quadrant, the
   server MAY select which quadrant should be preferred (if the server
   can assign addresses from all or some of the quadrants with the same
   assigned preference).  Note that this is not a simple list of
   quadrants ordered by preference without no preference value but a
   list of quadrants with explicit preference values.  This way it can
   support the case whereby a client really has no preference between
   two or three quadrants, leaving the decision to the server.

> server does not have addresses from neither Q1 or Q2 it should return

Okay, in that case I'd change

> >    server cannot provide an assignment from one of the specified

to

> >    server cannot provide an assignment from any of the specified

i.e., "one" to "any".  At least to me this will make the two sentences
clearly consistent.

BTW I'm not a native English speaker either, so it's quite possible
that it's due to my poor reading of English text:-)

--
JINMEI, Tatuya