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 / Bernie / Tomek,

@Bernie / Tomek - As there are defined values for the different SLAP Quadrant Identifiers, do you see the need to create an IANA registry for these values? We’ve done similar things in the past, e.g. RFC8026.


@Carlos,
Thanks for the update. There’s a few new comments based on the current version. I’ve also responded inline to the existing comments and deleted the ones that are now closed.

Best regards,
Ian


-----

Abstract.

Could you add this sentence to the end:

"A new DHCPv6 option (OPTION_SLAP_QUAD, or QUAD) is defined for this purpose."

as the term QUAD is used to refer to the new option throughout, but it’s not defined anywhere.

------


Section 4.2


Step 2.

Spaces missing in the following text:
Note that if a client sends multiple
        instances of the IA_LLoption in the same message, the DHCP relay
        MUST ONLY add a singleinstance of the QUAD option.  The server
        SHOULD apply thecontents of the relay's supplied QUAD option for
        all of theclient's IA_LLs, unless configured to do otherwise.

-
Also (this mistake was from my proposed text. Apologies:-):
s/MUST ONLY/MUST only/

-
This text is in step 2, but as it describes how the server behaves, it really
belongs in Step 3:

"The server  SHOULD apply thecontents of the relay's supplied QUAD option for
        all of theclient's IA_LLs, unless configured to do otherwise."

I suggest that it replaces the last sentence in step 3 (starting ’Note that
if the client is sending multiple…’ as this client related text isn’t really relevant
in the relay section


——

Step 3. 
s/The server, upon receiving a IA_LL option/The server, upon receiving an IA_LL option/
-

s/then the addresses being offered SHOULD belong to the requested quadrant(s)./
then the addresses being offered MUST belong to the requested quadrant(s)./

Please change in line with Section 4.1 Step 2 ‘the addresses being offered MUST belong to the requested quadrant(s)’

-----

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!

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

--


Section 5
s/If a same preference value/If the same preference value/

-----

"A quadrant value MUST only appear once at most in the option. If an
   option includes more than one occurence of the same quadrant value,”

This text is a little ambiguous (on first read, I thought that the value was for the preference. I
suggest the following re-word (‘occurence’ typo is also fixed):

“A quadrant identifier value MUST only appear at most once in the option. If an
   option includes more than one occurrence of the same quadrant identifier,”


——

(if the server can assign addresses from all of some of the quadrants
   with the same assigned preference).

I guess that the intended text here is: 

(if the server can assign addresses from all or some of the quadrants
   with the same assigned preference).



-----

Section 5.1
The text:
   A quadrant value MUST only appear once at most in the option.  If an
   option includes more than one occurence of the same quadrant value,
   only the first occurence is processed and the rest MUST be ignored by
   the server.

and 
   Client and relay agent MUST NOT place the same quadrant value into
   the option more than once; however servers should be capable of
   dealing with this by using the more preferred instance (as it
   requires no special handling).

both deal with the same case, but describe different behaviour for the server. I suggest
one of the two paragraphs is deleted.
----



> On 28. Feb 2020, at 00:32, CARLOS JESUS BERNARDOS CANO <[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…. ]

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

> 
>>  
>> ------
>> 
>> Section 5.1
>> 
>> The structure of the option seems needlessly complex and introduces problems/exceptions that currently aren’t discussed, but could be 
>> avoided. i.e. what happens if a quadrant id appears more than once? What if two id’s have the same preference values?
>> 
>> Couldn’t a simple, ordered list be used here? This would be processed in order (first to last) until a match is found. RFC8026 provides
>> an example of this.
>> 
>> [CB] Since not all the quadrants might appear in the option, we believe it's better to keep the current format, but we agree that we have to add text to discuss how different cases should be addressed, and which ones should be avoided. I've added some text to clarify that part.
> 
> [if - I’m with Bernie on this. It would be much simpler. Using an ordered list format does not mean that every value has to appear in it. ]
> 
> [Carlos] I still resist to change it. One more comment about changing it and I'll do it ;)

[if - The only case that I can think of that requires having the id/priority tuple is the case whereby a client really has no preference between two or three IDs and so the server can decide. No preference between all 4 types would be the same as not including the option. Is this a case that you can see arising? If so, it might be worth having some text describing the case as the question may well get raised again in later review stages.] 

>  
> 
> 
>>  
>> ———
>> 
>> I’m not sure if a new IANA registry of the valid values for the 'quadrant-n’ field is necessary. I’d appreciate the Chairs input on this.
>> 
>> [CB] I'll wait for Chairs' advise on this.
> 
> [if - I wonder if a point
> 
> [Carlos] ??

[if - I’ve put the question at the top of the email so hopefully it doesn’t get missed]

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

>> 
>> ——
>> 
>> Figure 4 seem to show that the relay adds the Quad option into the client's SOLICIT - i.e. alters the contents of the client’s
>> message.
>> 
>> This is not described by the body text, but the diagram needs to be fixed to avoid confusion here.
>> 
>> [CB] I'm not sure I follow this. The next says that "The relay, based on local knowledge and policies, includes in the Relay-Forw message the QUAD option with the preferred quadrant.", so it is described in the text, or am I missing something?
> 
> 
> [if - I should have explained this better. Figure 4 shows the following:
> 
> 2. Relay-forward
> (Solicit(IA_LL),QUAD)
> 
> The parentheses seem to indicate that QUAD is being inserted either into the client’s solicit message, or the relay_msg). The following format shows the encapsulations better:
> 
> Relay-forward
> ((RELAY_MSG(SOLICIT(IA_LL)),QUAD))
> ]
> 
> [Carlos] I still don't see this point. Current text says "Relay-forward(Solicit(IA_LL),QUAD)". For me this does not imply that the relay add the QUAD option in the client's solicit. In Figure 3, where we describe the client behavior adding the QUAD option uses "Solicit(IA_LL(QUAD))". For me it's clear the difference, but maybe I'm missing something.

[OK, let’s leave it as is]

> 
> Thanks a lot!
> 
> Carlos
>> 
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>