Re: [dhcwg] A late review of draft-ietf-dhc-slap-quadrant-09

Hi Tomek,

Thanks for your review. I quickly went through your comments and I think I
mostly agree, but I'll come back to you with my responses to each of your
comments in the following days.

Thanks,

Carlos

On Mon, Jun 8, 2020 at 3:11 PM Tomek Mrugalski <tomasz.mrugalski@gmail.com>
wrote:

> Hi,
> I was requested by IANA to do an expert review of dhc-slap-quadrant-09.
> I did as requested and in the process I have reviewed the whole draft.
> It's a bit late for editorial changes, but I was not able to dedicate
> any time sooner. Sorry for that.
>
> The proposed changes are mostly editorial in nature, except the one
> about what the client should do if receives an address from different
> quadrant than requested.
>
> Abstract: "A new DHCPv6 option (OPTION_SLAP_QUAD, or QUAD)". Please pick
> one name that you want to use for the option and stick with it. Using
> alternate names is confusing. I'd prefer to not mention
> OPTION_SLAP_QUAD, because that the constant representing a specific
> value. The abstract should convey general idea, not the implementation
> details.
>
> Section 4.1, bullet 2: "The server, upon receiving an IA_LL option,
> inspects its contents. [...] If suitable addresses are found, the server
> sends back an Advertise message". This is imprecise. It can easily be
> misunderstood as "if there's IA_LL option, always send Advertise,
> regardless of if the client sent Solicit, Request or Renew.
> This must be rephrased. I suggest something like "The server, upon
> receiving an IA_LL option in Solicit, inspects its contents.".
>
> Section 4.1, bullet 5: "When the assigned addresses are about to expire,
> the client sends a Renew message." This is usually not true. The client
> sends Renew after T1, which usually (as recommended by RFC8415) is set
> to 50% of a valid lifetime.
>
> Section 4.1, bullet 6: " 6.  The server responds with a Reply message,
> including an LLADDR option with extended lifetime." This can easily be
> misinterpreted as "the server sends LLADD as a top-level option in
> Reply". This is not true. The LLADDR option is always supposed to be
> sent in IA_LL.
>
> "The client SHOULD check if the received MAC address comes from one of
> the requested quadrants.  Otherwise, the client SHOULD NOT configure
> the obtained address." What if the relay inserted a different an option
> asking for a different quadrant and the server's policy used that?
> Client following the text as written would drop the option and will not
> used the LL address assigned. So how exactly the server policy would
> work if anything the client didn't request would be dropped? The policy
> could only possible rearrange order of quadrants that the client said is
> willing to accept.
>
> I don't particularly like that. There are many mechanisms in DHCPv6
> where the client sends some options as hints or suggestions, but it's
> not really a negotiation. The server knows best. Would you be willing to
> change that, so the client always accepts what the server had said?
>
> If you want the client to pick a different server, you can do so when
> evaluating received Advertises. The text as written allows the client
> to change his mind when Reply is received.
>
> Section 4.2, bullet 2: "if a client sends multiple instances of the
> IA_LL option in the same message, the DHCP relay MUST only add a single
> instance of the QUAD option." What if the relay supports this draft,
> but isn't configured to insert specific value?
>
> Section 4.2, bullet 9: The same issue as 4.1, bullet 5 (sends renew
> when address about to expire).
>
> Section 5.1 "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." from one => from
> any.
>
> I support the draft moving forward and I'll pass a note to IANA about my
> positive expert review for the option format.
>
> Tomek
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>