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,

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
>
> Overall:
> Could I propose changing the option name to ‘OPTION_SLAP_QUAD’, as
> OPTION_QUAD is quite ambiguous, especially out of context?
>

[Carlos] I think it makes sense. I'll do it.


>
>
> 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.
>
> 2, What is the case where a server has addresses available from a requested
> quadrant, but makes an allocation from a different quadrant (i.e. why is
> this a SHOULD,
> not a MUST)?
>

[Carlos] Thinking more about this I think I agree that it is better to have
a MUST there. I'll update.


>
> 3, For the NoQuadAvail error, am I right in saying that there are two
> cases that could be
> generated:
> i, The server does not have a configured address pool matching the
> client’s request.
> ii, The server has a configured address pool of the correct quadrant, but
> no available
> addresses.
>
>
[Carlos] Yes, you are right. I'll clarify this.



> Really, these are not the same error. (i) is a NoQuadAvail, but (ii) is
> more like the
> existing Code 2 NoAddrsAvail. Would this be a better choice to use here?
>

[Carlos] I agree. Good point. I'll update it


>
> 4,  Is NoQuadAvail sent for every higher QUAD preference that can’t
> be met? i.e. if the client specifies ELI, SAI, AAI in that order, but the
> server can only
> supply AAI, then does it send NoQuadAvail for ELI and SLI? My guess is
> that it shouldn’t,
> but the current text could be read to mean that.
>

[Carlos] Right, your guess is right. I'll update the text to make it clear.


>
> 5, It would be better throughout this paragraph to use ‘a requested
> quadrant’ instead of
> ’the requested quadrant’ as the document is describing a mechanism for
> indicating
> the preference of multiple quadrant types.
>

[Carlos] I've adopted Bernie's suggestion of using "requested quadrant(s)".


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


>
> ----
>
> Section 4.2 Step 3.
>
> "or other means such as based on analyzing the Solicit message from the
> client."
>
> I’m a little uncomfortable about this line as to implement this requires
> additional logic in
> the relay. IME experience this does not tend to go very well
> (see draft-fkhp-dhc-dhcpv6-pd-relay-requirements). If this logic is
> necessary, then I think
> it’s behaviour needs to be properly specified. If not, I would rather see
> this line removed.
> It could always be specified in a follow up document if necessary.
>

[Carlos] I see your point. Based on Bernie's comment in another e-mail,
I've just left "or other means".


> ---
>
> Section 5.1
> 1, For the quadrant-n description, the values 3 & 4 are listed as
> reserved. As this is a mapping of
>  a 2-bits (Y-bit and Z-bit), why are there a total of 5 values (0-4 incl.)
> listed?
>

[Carlos] Right, my mistake. It should be 0-3. I've fixed it.


> Also, as the table in Fig 2 already effectively gives values for each of
> the types, wouldn’t it
>

[Carlos] OK, fixed.


>
> 2, There’s a discrepancy in the new text between:
>
> "If a same preference value is used for more than one quadrant,
> it is left to the server implementation which
> quadrant should be preferred (if the server can
> assign addresses from all of some of the quadrants
> with the same assigned preference).”
>
> and
>
> If the same preference value is used for more than one quadrant, the
> behavior as to which is more preferred is random.
>
> I suggest that the second paragraph is deleted as the first offers more
> flexibility for implementors.
>

[Carlos] OK, I've removed this.


> However, if the option format is changed to an ordered list, then this is
> no longer necessary.
>
> ———
>
> One other grammatical nits on rereading:
>
> 4. s/DHCPv6 extensions/DHCPv6 Extensions/
>

[Carlos] Fixed.


>
>
> In addition, please see the following comments on your answers. I’ve
> removed the ones that are closed.
>

[Carlos] Thanks, please see my comments below.


>
>

>
>
>>
>> Major Comments
>> ———————————
>>
>> Section 4.2
>>
>> If the relay needs to insert the Quad option, then as I understand it,
>> the right way to do this would be for the relay to put it into a Relay
>> Supplied Option Option
>> (RSOO RFC6422). This requires an update to the IANA table at:
>>
>>
>> https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#option-codes-s46-priority-option
>>
>
> [CB] As I understand RFC6422, this is useful if the relay needs to provide
> info to the client, but this is not the case. We just need the relay to
> include the preference to be considered by the server when assigning the
> link-local address.
>
>
> [if - On re-reading RFC6422, I agree.]
>
>
>
>
>> -----
>>
>> Step 3. If the client is sending multiple instances of the IA_LL, how are
>> these associated to the relevant Quad option(s) added
>> by the relay, or is only a single quadrant possible for all of the IA_LLs
>> in the client’s message?
>>
>
> [CB] We assumed that only a single Quad option could be sent, applying
> those preferences to all IA_LLs in the client message. I've added some text
> explicitly explaining this (in Steps 2 and 3).
>
>
> [if - Isn’t there a requirement on the server as well as the relay here?
> The relay only adds one instance of QUAD, but the server has the
> requirement on how this is to be interpreted. How about the following text
> for both step 2 & 3 (I’ve incorporated Bernie’s text suggestion as well)?:
>
> old:
> Note that if the client is sending  multiple instances of the IA_LL
> in the same message, the DHCP relay MUST include a single
> QUAD option, that applies to all of the IA_LLs in the client's message.
>
> new:
> Note that 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. The server SHOULD apply the
> contents of the relay’s supplied QUAD option for all of the
> client’s IA_LLs, unless configured to do otherwise.
>

[Carlos] Thanks. I've adopted your proposed text.


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


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


>
>
>>
> ———
>>
>> Section 4.1
>>
>> A ’NoQuadAvail’ error code is mentioned, but this is the only place in
>> the document it occurs. If a new
>> DHCPv6 error code is being created, then this needs to be defined and the
>> IANA registry updated:
>>
>> https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-5
>>
>
> [CB] I've added it to the IANA considerations sections.
>
>
> [if - As Bernie notes, the IANA section still needs some work.]
>

[Carlos] I've applied Bernie's comments.


>
>
>> ----
>>
>> 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.)
>
>
>
>> Putting the IoT, Wifi and Data Center examples into their own
>> sub-sections would improve the structure and
>> readability.
>>
>
> [CB] I have mixed feelings here. I see your point, but I still like the
> distinction between WiFi devices (that includes both IoT and WiFi devices
> required additional privacy protection) and the data center (hypervisors).
> I'll think a bit more about it. If others have an opinion on this, that
> would be appreciated.
>
> ———
>>
>>
> [if - OK]
>
>
>
>> ----
>>
>> Much of the content of this section duplicates what is described
>> in [I-D.ietf-dhc-mac-assign].
>> It would be better just to have a pointer to the relevant sections of
>> that document and describe
>> the changes that the Quad option makes to this process.
>>
>
> [CB] I prefer to keep it is for completion. I'd like to hear other
> opinions as well.
>
>
> [if - OK]
>
>
> ——
>>
>> 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.

Thanks a lot!

Carlos


>
>>
>>
>> On 30. Oct 2019, at 02:51, Tomek Mrugalski <[e-mail]>
>> wrote:
>>
>> Hi,
>> This mail initiates a Working Group Last Call on two related IDs:
>>
>> Link-Layer Addresses Assignment Mechanism for DHCPv6
>> draft-ietf-dhc-mac-assign-01
>> https://tools.ietf.org/html/draft-ietf-dhc-mac-assign-01
>>
>> and
>>
>> SLAP quadrant selection options for DHCPv6
>> draft-ietf-dhc-slap-quadrant-01
>> https://tools.ietf.org/html/draft-ietf-dhc-slap-quadrant-01
>>
>> Authors believe those drafts are ready for WGLC. Please post your
>> substantial comments and your opinion whether those are ready for
>> publication or not. If you have minor editorial comments, you may send
>> them to the authors directly.
>>
>> Please post your comments by Nov. 17th.
>>
>> Cheers,
>> Tomek
>>
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>>
>>
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>