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

From: [email-masked]
Date: Thu, 5 Mar 2020 12:38:46 +0100

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 <[email-masked]> wrote:
> 
> Hi Ian,
> 
> Thanks a lot for your comments.
> 
> Please see inline below.
> 
> 
> On Tue, Jan 14, 2020 at 12:22 PM <[email-masked] <mailto:[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 
> 
> 
> 
> 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
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 5 Mar 2020 16:31:50 +0000

>@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…

I don’t see a need for a registry for this because I doubt there would be new values in the future.

  *   Bernie

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

@Carlos,

Best regards,
Ian

-----

Abstract.

------

Section 4.2

Step 2.

-

-

——

Step 3.

-----

For the following text:

--

Section 5

-----

——

-----

Section 5.1
The text:

and

On 28. Feb 2020, at 00:32, CARLOS JESUS BERNARDOS CANO <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ian,

Please see inline below.

On Tue, Jan 14, 2020 at 12:22 PM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Carlos,

Thanks and best regards,
Ian

Section 4.1 Step 2:

old:

new:

---

Section 4.1 Step3.

------

Section 5.1

———

[Carlos] ??

----

——

2. Relay-forward
(Solicit(IA_LL),QUAD)

Relay-forward

Thanks a lot!

Carlos

[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Sat, 7 Mar 2020 19:26:14 +0100

Hi Ian,

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

Carlos

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

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

>         all of theclient's IA_LLs, unless configured to do otherwise.

[CB] Done, thanks.

> Also (this mistake was from my proposed text. Apologies:-):

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

> [CB] OK, I agree. Done.

> s/The server, upon receiving a IA_LL option/The server, upon receiving an

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

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

[CB] OK, done.

> or not. The client clearly knows best here!

[CB] Good point. I agree. I've changed it.

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

> [CB] Fixed, thanks.

> [CB] OK, fixed.

>    with the same assigned preference).

[CB] Right, fixed. Thanks.

> one of the two paragraphs is deleted.

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

> On Tue, Jan 14, 2020 at 12:22 PM <[email-masked]> wrote:
>
>> Hi Carlos,
>>
> 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.
> [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. ]
>>
>
> [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] Since Bernie already replied in another e-mail, I haven't addressed
that point.

> [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.
>>>
>> [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?
>>
>>
>>
>> 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
> [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.
>
>
>>> [email-masked]

---

From: [email-masked]
Date: Fri, 13 Mar 2020 16:47:54 +0100

Hi Carlos,

Thanks for the update. 

Please see inline below.

Cheers,
Ian

> [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 <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Ian,
>> 

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

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

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 13 Mar 2020 17:17:21 +0000

Hi:

Regarding the last point:

First, I’ve lost exactly what section/text we are talking about here …

Second, I agree that there is no need for a relay to support IA_LL (look for in client’s message) … it just adds the SLAP_QUAD option (it can do this blindly to all messages, even those without a client IA_LL). There’s no reason for the server to care about the SLAP_QUAD option if no IA_LL is present in the client’s message so it does not harm for relay to blindly add it. Processing of the SLAP_QUAD only comes up if there is a Solicit, Request, Renew, Rebind with a IA_LL. For all other cases, the relay’s option would just be completely ignored by server.

  *   Bernie

From: [email-masked] <[email-masked]>
Sent: Friday, March 13, 2020 11:48 AM
To: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Cc: Tomek Mrugalski <[email-masked]>; Bernie Volz (volz) <[email-masked]>; dhcwg <[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 Carlos,

Thanks for the update.

Please see inline below.

Cheers,
Ian

-----

For the following text:

"

Hi Ian,

Please see inline below.

Thanks and best regards,
Ian

Section 4.1 Step 2:

old:

new:

---

Section 4.1 Step3.

----

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Mon, 16 Mar 2020 16:14:43 +0100

Hi Ian,

Thanks again for your comments. Please see inline below.

> It is RECOMMENDED that the default for such a parameter is to process the
[CB] OK, I like your proposed text. Thanks a lot!

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

[CB] OK, sorry. Please check if the new version -06 (with the changes made
before) is OK.
BTW, why do you say it is step 3? the piece of text being discussed is step
2, right?

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

[CB] OK.

>> [if. - I didn’t see an answer for this. Also, the relay definition
>> doesn’t state that the relay (may) implement OPTION_SLAP_QUAD.]
>>
>
> [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?]
>
> [CB] I'll comment on this on top of Bernie's response in a different
> e-mail.
>

Thanks!

Carlos

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Mon, 16 Mar 2020 16:20:25 +0100

Hi,

Please see inline below.

On Fri, Mar 13, 2020 at 6:17 PM Bernie Volz (volz) <[email-masked]> wrote:

> Second, I agree that there is no need for a relay to support IA_LL (look
> for in client’s message) … it just adds the SLAP_QUAD option (it can do
> this blindly to all messages, even those without a client IA_LL). There’s
> no reason for the server to care about the SLAP_QUAD option if no IA_LL is
> present in the client’s message so it does not harm for relay to blindly
> add it. Processing of the SLAP_QUAD only comes up if there is a Solicit,
> Request, Renew, Rebind with a IA_LL. For all other cases, the relay’s
> option would just be completely ignored by server.
>

[CB] OK, I've removed in the definitions part, in the relay text the need
for the relay to support IA_LL and LLADDR. This should be, unless I
misunderstood something, what Ian was referring to.

Thanks,

Carlos

>
>
>    - Bernie
>
>
>
> *From:* [email-masked] <[email-masked]>
> *Sent:* Friday, March 13, 2020 11:48 AM
> *To:* CARLOS JESUS BERNARDOS CANO <[email-masked]>
> *Cc:* Tomek Mrugalski <[email-masked]>; Bernie Volz (volz) <
> [email-masked]>; dhcwg <[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 Carlos,
>
>
>
> Thanks for the update.
>
>
>
> Please see inline below.
>
>
>
> Cheers,
>
> Ian
>
>
>
>
>
> -----
>
>
>
> For the following text:
>
>
>