Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17

[[e-mail]]

Hi Carlos,

Thanks for the update. 

Please see inline below.

Cheers,
Ian

> 
> -----
> 
> For the following text:
> 
>    If a client provides a QUAD IA_LL-option and the relay agent is still
>    configured to add its preference value, the server SHOULD follow what
>    is administratively configured in a QUAD_RELAY_PREF internal
>    variable.  If the value is set to 1, then the realy provided
>    preference overrides what the client has provided, while if the
>    variable is set to 0, then the client's provided preference is
>    considered.  It is RECOMMENDED that QUAD_RELAY_PREF is set to 1 at
>    the server.
> 
> I don’t agree with the recommendation here, as in section 4.2 the text states that the
> client SHOULD NOT configure a prefix from an unrequested quadrant. The ‘1' recommendation
> says ‘relay knows best’, but the client’s actually got the veto on whether it will configure it
> or not. The client clearly knows best here!
> 
> [CB] Good point. I agree. I've changed it.
>  
> 
> Also, the text using QUAD_RELAY_PREF and ‘value is set to 1’ etc. seems overly prescriptive
> for an implementation. It would be better to use more general terms e.g. ‘administratively
> configured to evaluate the client’s supplied instance of OPTION_SLAP_QUAD and ignore
> the relay supplied instance, or vice versa’.
> 
> [CB] I'm not sure I got this point right. I've rewritten this part and now reads as follows:
> 
> "If a client provides a QUAD IA_LL-option and the relay agent is still configured
> to add its preference value, the server SHOULD follow what is administratively
> configured in a QUAD_RELAY_PREF internal variable. If the value is set to 1, the
> server is administratively configured to evaluate the client's supplied instance
> of OPTION_SLAP_QUAD and ignore the relay supplied instance. If the variable is
> set to 0, then the server is administratively configured to evaluate the relay's
> provided preference and ignore the client supplied instance. It is RECOMMENDED
> that QUAD_RELAY_PREF is set to 0 at the server.”

[if - My point here is that defining the name of a configuration parameter (QUAD_RELAY_PREF)
and its allowable values is really unnecessary. I’m sure that implementors will use whatever
naming they see fit.

Additionally, I think the first point has got a bit mangled. Can I propose the following text for the
paragraph which addresses both points:

"
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. This parameter
configures the server to process either the client’s, or the relay’s instance of option QUAD.
It is RECOMMENDED that the default for such a parameter is to process the client’s instance
of the option.
“
]


> 
> 
>> On 28. Feb 2020, at 00:32, CARLOS JESUS BERNARDOS CANO <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi Ian,
>> 
>> Thanks a lot for your comments.
>> 
>> Please see inline below.
>> 
>> 
>> On Tue, Jan 14, 2020 at 12:22 PM <[e-mail] <mailto:[e-mail]>> wrote:
>> Hi Carlos,
>> 
>> Thanks for the update. I’ve got a few more comments on the current version, in addition to Bernie's.
>> 
>> Thanks and best regards,
>> Ian 
>> 
>> 
>> 
>> Section 4.1 Step 2:
>> 
>> "If the server supports the new QUAD IA-LL-option, and manages
>> a block of addresses belonging to the requested quadrant, the
>> addresses being offered SHOULD belong to the requested
>> quadrant.  If the server does not have addresses from the
>> requested quadrant, it MUST return the IA_LL option
>> containing a Status Code option with status set to NoQuadAvail (IANA-2).”
>> 
>> 1, This should describe the process of checking the QUAD option’s 
>> priorities to find the highest priority quadrant with an available address.
> 
> [if - The text still doesn’t describe how the server parses the client’s request. Can I suggest
> the. following text change:
> 
> old:
> The server, upon receiving a IA_LL option, inspects its content
>        and may offer an address or addresses for each LLADDR option
>        according to its policy. The server sends back an Advertise
>        message ...
> 
> new:
> The server, upon receiving a IA_LL option, inspects its contents. For each of the entries in OPTION_SLAP_QUAD, in order of the preference field (highest to lowest), the server checks if it has a configured MAC address pool matching the requested quadrant identifier, and an available range of addresses of the requested size. If suitable addresses are found, The server sends back an Advertise message…. ]

[if - I think this one got missed. As this is now in step 3,  the comment is relevant for this.]

> 
>> 
>> ---
>> 
>> Section 4.1 Step3. 
>> 1, Does the client perform any validation that the received MAC address comes from one of 
>> the requested quadrants? If the address doesn’t, what does the client do? I think it would be worth having
>> some text on how the client is expected to behave in this case. This is especially important
>> in the case of the relay adding the option, as if the quadrant the relay prefers is one that the
>> client will not configure, then there’s a risk of breaking things.
>> 
>> [Carlos] Again, a very good point, thanks. I've added some text at the end of Sections 4.1 and 4.2.
> 
> 
> [if - A question that arises from the above is what the client should then do with any other addressing information that is has been received in the DHCPv6 reply (i.e. an address allocation for a requested IA_NA). Should the IA_NA be used with the existing (initial, temporary) MAC address, or should it not be configured and DHCP retried until a MAC address from a requested quadrant is received (and a new IA_NA allocation with it?]
> 
> [CB] That's a very good question. I think the client should configure it independently from the MAC address configuration process. If the client wants to first configure the MAC address and then other aspects, it could follow a sequential process, first configuring its MAC address and then going for additional things, no? What do you think?

[if - I think this question is relevant to both this draft and draft-ieft-dhc-mac-assign. I’ve raised it in a separate email.]

>>> ----
>>> 
>>> There also needs to be a definition for the relay function, as it needs to be updated for
>>> the Quad option as well.
>>> 
>>> [CB] I've added it. Thanks.
>> 
>> [if - One question about the wording here - does the relay need to support IA_LL, or only QUAD? I don’t see
>> any requirement for the relay to look for instances of IA_LL in the client’s messages, and the relay doesn’t 
>> create them itself.)
> 
> [if. - I didn’t see an answer for this. Also, the relay definition doesn’t state that the relay (may) implement OPTION_SLAP_QUAD.]
> 
> [CB] If I got your point right, the relay does not need to support IA_LL, only QUAD. However, an implementation of relay might look for instances of IA_LL instances in the client's messages and decide whether to add a QUAD option (and what to put there) taking into consideration the content of the IA_LL option. Do you agree? Should we add some text about this?
> 

[if - I still don’t think that this is likely to be implemented, or what the benefit would be given that the client can indicate a quad preference (if it has one), the relay can add a quad, the server can be configured to say which one it will use if there is a choice, and all of this can be done without relay message snooping logic. What is missing that would justify this complexity?]