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

Hi Tomek,

I've gone through all your comments. I've addressed them all, and I only
have one comment, please see inline below.

Changes are included in -10, to be submitted soon.

Thanks,

Carlos

On Mon, Jun 8, 2020 at 3:31 PM CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
wrote:

> 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?
>>
>
[Carlos] I discussed this with Bernie and he suggested changing MUST to
MAY. The relay can only add up to ONE QUAD option. It may not add any, or
add one.

Thanks!

Carlos

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