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 <noreply@xxxxxxxx> 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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
