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

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Fri, 28 Feb 2020 00:32:37 +0100

Hi Bernie, all,

I've just submitted version -03 based on the good feedback received.

Please see inline below.

On Mon, Jan 13, 2020 at 11:57 PM Bernie Volz (volz) <[email-masked]> wrote:

> Thanks for the update.
>
>
>
> Here’s a few comments on the updated (02) version:
>
>
>
> I am still struggling with the value of the preference field. I still
> think an ordered list, in the preference order, would be far simpler. There
> really is nothing that the preference provides, except for the ordering.
> Removing the preference value reduces the complexity; and again, doesn’t
> seem to have any added value.
>
>
>
> In section 4.2, #2:
>
>
>
>         message from the client.  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.
>
>
>
> Perhaps “the DHCP relay MUST ONLY include a single QUAD option”. I think
> the ONLY part is what is important here?
>

[Carlos] OK, I've added the "only", but in lowercase.

>
>
> Also, later in the paragraph at the end of the section, fix
> “QUAD_REALY_PREF” (QUAD_RELAY_PREF).
>

[Carlos] OK, thanks. Fixed.

>
>
>
>
> In section 5.1:
>
>
>
> In the quadrant-n description you have:
>
>
>
> *                                           If an option includes more*
>
> *                   than one occurence of the same quadrant, only the*
>
> *                   first occurence is processed and the rest MUST be*
>
> *                   ignored by the server.*
>
>
>
> But later in the text which follows:
>
>
>
> *   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).*
>
>
>
> Which is it?
>

[Carlos] This is a good point. I tend to prefer to replace the MUSTs with
SHOULDs so we kind-of follow the "be strict in what you send and tolerant
in what you receive" from J. Postel. But I don't have a strict opinion and
we can also just remove the part of servers dealing with more than one
occurence of the same quadrant. What do you think?

>
>
> I’d also suggest for the field definitions to keeping to a description of
> what it is and the data type – use the text after the field definitions to
> define the rules for how the data is processed. That is the model we used
> in RFC8415.
>

[Carlos] OK, I was trying to do this. I've reviewed it and move some text
to keep the field definitions shorter.

>
>
> And, you might fix:
>
>
>
>    If the server can provide an assignment from one the specified
>
>    quadrants, it should proceed with the assignment
>
>
>
> One of the specified quadrants?
>

[Carlos] Fixed, thanks.

>
>
>
>
> For the IANA section, you should define the full details for the new
> option (the options have Client ORO and Singleton Option columns in the
> table and you need to tell IANA what to put here – No for both). IANA calls
> the “error codes” Status Codes. I actually need to fix the mac-assign
> document to address the additional columns for the 2 options requested
> there. You may want to see
> https://tools.ietf.org/html/draft-ietf-dhc-dhcp4o6-saddr-opt-08#section-10
> for how this was handled in a recent RFC’s draft.
>
>
>

[Carlos] Thanks. Fixed.

>
>
> Minor: Should OS be defined somewhere to be operating system, or is that
> too obvious? There are only 4 usages in Section 3, so perhaps change first
> to define it?
>

[Carlos] I expanded it the first time the term appeared.

Thanks!

Carlos

>
>
>    - Bernie
>
>
>
> *From:* dhcwg <[email-masked]> *On Behalf Of *CARLOS JESUS
> BERNARDOS CANO
> *Sent:* Monday, January 13, 2020 8:47 AM
> *To:* Bernie Volz (volz) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and
> draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17
>
>
>
> Hi Bernie,
>
>
>
> Thanks a lot for the comments. I've updated the doc according to your
> comments (-02).
>
>
>
> Please see inline below some feedback from my side.
>
>
>
>
>
> On Tue, Jan 7, 2020 at 10:05 PM Bernie Volz (volz) <[email-masked]> wrote:
>
> In addition to Ian’s comments, I will add the following for you and the WG
> to consider:
>
>
>
> For section 5.1, pref-n, I’d suggest explain what this value means (is a
> lower value more “preferred” or a higher?).
>
>
>
> [CB] I've added some text explaining that higher means more "preferred".
>
>
>
>
>
> I’m also still wondering whether a simpler mechanism would just be to have
> the client provide the list of quadrant values it would like in the order
> of preference, so the option would be just quadrant-1, quadrant-2, […]. I’m
> really not sure what the pref value adds and it makes things more
> complicated in processing.
>
>
>
> If you do keep the quad/pref, you should make it clear whether there is
> any requirement in terms of ordering or not (I would guess you would want
> not).
>
>
>
> [CB] Following Ian's comment I've tried to explain better how to process
> this. I still believe it's good to have the option as is, but we can
> discuss about it and change it if needed.
>
>
>
>
>
> And, in either case, what does the absence of a quadrant mean – that the
> server SHOULD NOT assign this or assume they are of even lower preference?
> This is buried in the text section 4.1, item #2:
>
>
>
>                                               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..
>
>
>
> I think you would want to specify the processing rules in the option
> description (i.e., section 5.1).
>
>
>
> [CB] Good point, done.
>
>
>
>
>
> And, the text earlier in sections 4.1 and 4.2 says “In order to indicate
> the preferred SLAP quadrant,“ but that seems to be indicating only 1 –
> not a list of possible values?
>
>
>
> [CB] Fixed.
>
>
>
>
>
> Perhaps in 5.1, after the fields, you should add something like:
>
>
>
> If the client or relay agent provide the OPTION_QUAD, the server uses the
> quadrant-n/pref-n values to order the selection of the quadrants. If the
> server can provide an assignment from one the specified quadrants, it
> should proceed with the assignment. 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 in the IA_LL Option.
>
>
>
> There is no requirement that the client or relay agent order the
> quadrant/pref values in any specific order; hence servers MUST NOT assume
> that quadrant-1/pref-1 have the highest preference (except if there is only
> 1 set of values).
>
>
>
> 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).
>
>
>
> If the same preference value is used for more than one quadrant, the
> behavior as to which is more preferred is random.
>
>
>
> [CB] Thanks a lot Bernie! I had drafted some similar text to address your
> and Ian's comments, but your text is better.
>
>
>
>
>
> But also note that servers that do not support the OPTION_QUAD will
> proceed with assigning from whatever may be available. So, I’m wondering if
> this behavior is really the best – does the client (or relay agent) need to
> check that the addresses were assigned from the quadrant?
>
>
>
> [CB] I think we don't need to specify this. The requester can always check
> if the assigned address belongs to the most preferred quadrant and take any
> action (if needed).
>
>
>
>
>
> Since this and the mac-assign document should probably go as a package,
> perhaps this argues for requiring implementation of both? Or perhaps we
> should have the server that supports and used the OPTION_QUAD echo it back
> (in the IA_LL-options field for clients and Relay-Reply for relay agent) as
> that would be one way for the client or relay agent to know the server
> understood it (this would also remove the need for this to be support in
> the ERO option). Also, if the relay agent’s value was used (overrides the
> clients), it would NOT be echoed back in the IA_LL-option – just in the
> Relay-Reply)?
>
>
>
> [CB] To be honest, I think I could use a bit of advice here. I removed the
> ERO part (as hinted by Ian) and I'm not sure which implementation option is
> best to recommend.
>
>
>
>
>
>
>
> As a nit, you probably should be consistent in usage of Relay-Forw and
> Relay-Reply (some cases lower case is used) … and per RFC8415, the usage is:
>
>                 Relay-forward and Reply-reply when referring to the
> messages
>
>                 RELAY-FORW and RELAY-REPLY when referring to the msg-type
> of a message
>
> So, you want to use “Relay-forward” and “Reply-reply” in pretty much all
> cases?
>
>
>
> [CB] I think I fixed this. I'm using "Relay-forward" "Relay-reply".
>
>
>
> Thanks a lot!
>
>
>
> Carlos
>
>
>

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Fri, 28 Feb 2020 00:32:59 +0100

Hi Ian,

Thanks a lot for your comments.

Please see inline below.

On Tue, Jan 14, 2020 at 12:22 PM <[email-masked]> 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
>
> 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 <[email-masked]>
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>>
>>
>> _______________________________________________
>> dhcwg mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 28 Feb 2020 00:05:52 +0000

Hi:

Thanks Carlos.

One other nit (which I hate to raise as I missed it before) is in section 4.1:

   1.  Link-layer addresses (i.e., MAC addresses) are assigned in
       blocks.  The smallest block is a single address.  To request an
       assignment, the client sends a Solicit message with a IA_LL
       option in the message.  The IA_LL option MUST contain a LLADDR
       option.  In order to indicate the preferred SLAP quadrant(s), the
       IA_LL option includes the new OPTION_SLAP_QUAD option(s) in the
       IA-LL-option field (with the LLAADR option).

First, the option(s) seems wrong as I think we only want one OPTION_SLAP_QUAD per IA_LL option?

Second, it the field is IA_LL-option.

Third, it turns out that this draft uses IA-LL in lots of places when it should be IA_LL (https://tools.ietf.org/html/draft-ietf-dhc-mac-assign-03 has no instances of IA-LL).

Also in same section, #2:

       return a NoQuadAvail status code if the address pool configured
       at the server does not match any of the specified SLAP quadrants.

Should we say pool(s) as there could be more than one? And perhaps better to use:

       return a NoQuadAvail status code if no address pool(s) configured
       at the server match any of the specified SLAP quadrants.

And at the end of the section there is:

   The client SHOULD check if the received MAC address comes from one
   of the requested quadrants.  If not, SHOULD NOT configure the
   obtained address.  It MAY repeat the process selecting a different
   DHCP server.

Which reads kind of oddly with the If not (what)? Perhaps re-word as:

   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.  It MAY repeat the process selecting a different
   DHCP server.

Probably it would be better to consider moving this logic into step 3 and suggest that the client NOT pick a server that does not advertise an address in the requested quadrant? Where the text is now, it is not clear if this should be done at the Advertise or Reply processing. Note that technically it should also be done at the Reply processing as a client might have requested Rapid Commit (and if in the Reply case, the client should ideally Release the mac address if it will not use it). And, might be wise to add some text about following the Rate Limiting advice in RFC8415 section 14.1 (https://tools.ietf.org/html/rfc8415#section-14.1) as otherwise a client might thrash if only a single server is available that doesn’t understand the SLAP_QUAD option.

And, in section 4.2, I’m also concerned about the last paragraph as this is could end up a no-win situation if the client and relay want different quadrants and the server does not offer the one the client wants – as then the client will reject. I think this may require some more consideration …

Perhaps we remove all of this text that client should check? (Except on Advertise and in that case the client should not prefer Advertisements that don’t match is desire. But if it never gets what it desires, it should use another.)

  *   Bernie

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Sent: Thursday, February 27, 2020 6:33 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17

Hi Bernie, all,

Please see inline below.

On Mon, Jan 13, 2020 at 11:57 PM Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the update.

I am still struggling with the value of the preference field. I still think an ordered list, in the preference order, would be far simpler. There really is nothing that the preference provides, except for the ordering. Removing the preference value reduces the complexity; and again, doesn’t seem to have any added value.

In section 4.2, #2:

Perhaps “the DHCP relay MUST ONLY include a single QUAD option”. I think the ONLY part is what is important here?

Also, later in the paragraph at the end of the section, fix “QUAD_REALY_PREF” (QUAD_RELAY_PREF).

In section 5.1:

                                           If an option includes more
                   than one occurence of the same quadrant, only the
                   first occurence is processed and the rest MUST be
                   ignored by the server.

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

Which is it?

[Carlos] This is a good point. I tend to prefer to replace the MUSTs with SHOULDs so we kind-of follow the "be strict in what you send and tolerant in what you receive" from J. Postel. But I don't have a strict opinion and we can also just remove the part of servers dealing with more than one occurence of the same quadrant. What do you think?

I’d also suggest for the field definitions to keeping to a description of what it is and the data type – use the text after the field definitions to define the rules for how the data is processed. That is the model we used in RFC8415.

[Carlos] OK, I was trying to do this. I've reviewed it and move some text to keep the field definitions shorter.

And, you might fix:

[Carlos] Fixed, thanks.

For the IANA section, you should define the full details for the new option (the options have Client ORO and Singleton Option columns in the table and you need to tell IANA what to put here – No for both). IANA calls the “error codes” Status Codes. I actually need to fix the mac-assign document to address the additional columns for the 2 options requested there. You may want to see https://tools.ietf.org/html/draft-ietf-dhc-dhcp4o6-saddr-opt-08#section-10 for how this was handled in a recent RFC’s draft.

[Carlos] Thanks. Fixed.

Minor: Should OS be defined somewhere to be operating system, or is that too obvious? There are only 4 usages in Section 3, so perhaps change first to define it?

Thanks!

Carlos

  *   Bernie

From: dhcwg <[email-masked]<mailto:[email-masked]>> On Behalf Of CARLOS JESUS BERNARDOS CANO
Sent: Monday, January 13, 2020 8:47 AM
To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17

Hi Bernie,

Thanks a lot for the comments. I've updated the doc according to your comments (-02).

On Tue, Jan 7, 2020 at 10:05 PM Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
In addition to Ian’s comments, I will add the following for you and the WG to consider:

For section 5.1, pref-n, I’d suggest explain what this value means (is a lower value more “preferred” or a higher?).

I’m also still wondering whether a simpler mechanism would just be to have the client provide the list of quadrant values it would like in the order of preference, so the option would be just quadrant-1, quadrant-2, […]. I’m really not sure what the pref value adds and it makes things more complicated in processing.

If you do keep the quad/pref, you should make it clear whether there is any requirement in terms of ordering or not (I would guess you would want not).

[CB] Following Ian's comment I've tried to explain better how to process this. I still believe it's good to have the option as is, but we can discuss about it and change it if needed.

And, in either case, what does the absence of a quadrant mean – that the server SHOULD NOT assign this or assume they are of even lower preference? This is buried in the text section 4.1, item #2:

                                              If the server does not

I think you would want to specify the processing rules in the option description (i.e., section 5.1).

[CB] Good point, done.

And, the text earlier in sections 4.1 and 4.2 says “In order to indicate the preferred SLAP quadrant,“ but that seems to be indicating only 1 – not a list of possible values?

[CB] Fixed.

If the client or relay agent provide the OPTION_QUAD, the server uses the quadrant-n/pref-n values to order the selection of the quadrants. If the server can provide an assignment from one the specified quadrants, it should proceed with the assignment. 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 in the IA_LL Option.

There is no requirement that the client or relay agent order the quadrant/pref values in any specific order; hence servers MUST NOT assume that quadrant-1/pref-1 have the highest preference (except if there is only 1 set of values).

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

If the same preference value is used for more than one quadrant, the behavior as to which is more preferred is random.

[CB] Thanks a lot Bernie! I had drafted some similar text to address your and Ian's comments, but your text is better.

But also note that servers that do not support the OPTION_QUAD will proceed with assigning from whatever may be available. So, I’m wondering if this behavior is really the best – does the client (or relay agent) need to check that the addresses were assigned from the quadrant?

[CB] I think we don't need to specify this. The requester can always check if the assigned address belongs to the most preferred quadrant and take any action (if needed).

Since this and the mac-assign document should probably go as a package, perhaps this argues for requiring implementation of both? Or perhaps we should have the server that supports and used the OPTION_QUAD echo it back (in the IA_LL-options field for clients and Relay-Reply for relay agent) as that would be one way for the client or relay agent to know the server understood it (this would also remove the need for this to be support in the ERO option). Also, if the relay agent’s value was used (overrides the clients), it would NOT be echoed back in the IA_LL-option – just in the Relay-Reply)?

[CB] To be honest, I think I could use a bit of advice here. I removed the ERO part (as hinted by Ian) and I'm not sure which implementation option is best to recommend.

As a nit, you probably should be consistent in usage of Relay-Forw and Relay-Reply (some cases lower case is used) … and per RFC8415, the usage is:
                Relay-forward and Reply-reply when referring to the messages
                RELAY-FORW and RELAY-REPLY when referring to the msg-type of a message
So, you want to use “Relay-forward” and “Reply-reply” in pretty much all cases?

Thanks a lot!

Carlos

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Fri, 28 Feb 2020 12:20:04 +0100

Hi Bernie,

Huge thanks again for your help and comments.

Please see inline below.

[Carlos] OK, fixed.

[Carlos] Fixed.

>
>
> Third, it turns out that this draft uses IA-LL in lots of places when it
> should be IA_LL (https://tools.ietf.org/html/draft-ietf-dhc-mac-assign-03
> has no instances of IA-LL).
>

[Carlos] Fixed.

> *       return a NoQuadAvail status code if the address pool configured*
>
> *       at the server does not match any of the specified SLAP quadrants.*
>
>
>
> *       return a NoQuadAvail status code if no address pool(s) configured*
>
> *       at the server match any of the specified SLAP quadrants.*
>

[Carlos] OK, thanks for the suggestion. I've used the proposed text.

>    *The client SHOULD check if the received MAC address comes from one*
>
> *   of the requested quadrants.  If not, SHOULD NOT configure the*
>
> *   obtained address.  It MAY repeat the process selecting a different*
>
> *   DHCP server.*
>
>
>
>    *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.  It MAY repeat the process selecting a different*
>
> *   DHCP server.*
>

[Carlos] Thanks again.

>
>
> Probably it would be better to consider moving this logic into step 3 and
> suggest that the client NOT pick a server that does not advertise an
> address in the requested quadrant? Where the text is now, it is not clear
> if this should be done at the Advertise or Reply processing. Note that
> technically it should also be done at the Reply processing as a client
> might have requested Rapid Commit (and if in the Reply case, the client
> should ideally Release the mac address if it will not use it). And, might
> be wise to add some text about following the Rate Limiting advice in
> RFC8415 section 14.1 (https://tools.ietf.org/html/rfc8415#section-14.1)
> as otherwise a client might thrash if only a single server is available
> that doesn’t understand the SLAP_QUAD option.
>

[Carlos] I've added some text in step 3, while keeping the logic at the
end. I hope in this way it is clear enough.

>
>
> And, in section 4.2, I’m also concerned about the last paragraph as this
> is could end up a no-win situation if the client and relay want different
> quadrants and the server does not offer the one the client wants – as then
> the client will reject. I think this may require some more consideration …
>
>
>
> Perhaps we remove all of this text that client should check? (Except on
> Advertise and in that case the client should not prefer Advertisements that
> don’t match is desire. But if it never gets what it desires, it should use
> another.)
>

[Carlos] OK, I see your point. What about the following approach (use MAY)?

The client MAY check if the received MAC address belongs to a quadrant it is
willing to use/configure, and MAY decide based on that whether to use
configure
the received address.

I've uploaded a new version (-04) with this changes.

Thanks!

Carlos

>
>
>    - Bernie
>
>
>
> *From:* CARLOS JESUS BERNARDOS CANO <[email-masked]>
> *Sent:* Thursday, February 27, 2020 6:33 PM