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

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

Hi Ian,

One more time, thanks for the comments. Please see inline below.

Carlos

On Thu, Mar 5, 2020 at 12:38 PM <[e-mail]> wrote:

> 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.
>
>
[CB] OK, done.


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

[CB] Done, thanks.


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

[CB] Fixed, thanks. And no need for apologies. I should have noticed.


>
> -
> 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
>
> [CB] OK, I agree. Done.


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

[CB] I've fixed this in all the occurences of "a IA_LL". Thanks.


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

[CB] OK, done.


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

>
> --
>
>
> Section 5
> s/If a same preference value/If the same preference value/
>
> [CB] Fixed, thanks.


> -----
>
> "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,”
>
> [CB] OK, fixed.


>
> ——
>
> (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).
>

[CB] Right, fixed. Thanks.


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

[CB] OK, I agree. I've removed the second one.


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

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


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

[CB] Yes. OK, I've added some text to include this rationale.


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

[CB] Since Bernie already replied in another e-mail, I haven't addressed
that point.


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

Thanks a lot!

I will submit a new version.

Carlos


>
>
>> ——
>>>
>>> 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]
>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>
>>
>>
>