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