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,

OK, we’re getting there! A couple of small comments in line below.

Also, should ietf-dhc-mac-assign actually be a Normative reference? Surely without that, the QUAD option is useless. Also, the plan is to pubish both of these drafts together as a cluster.]

Thanks,
Ian


> 
> 
>> 
>> 
>>> On 28. Feb 2020, at 00:32, CARLOS JESUS BERNARDOS CANO <[e-mail] <mailto:[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…. ]
> 
> [if - I think this one got missed. As this is now in step 3,  the comment is relevant for this.]
> 
> [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 - Now I read it back, the step 3 comment above was actually for step 3 in section 4.2. The text in 4.1 looks good (with one change I should have caught):

s/upon receiving a IA_LL option/upon receiving an IA_LL option/

As 4.3 step 3 describes how the server processes the QUAD option with a relay, what about the following text to be consistent with 4.1 step2

Upon receiving a relayed message containing an IA_LL option, the server inspects the contents for instances of OPTION_SLAP_QUAD in both the Relay Forward message and the client’s message payload. Depending on the server’s policy, the instance(s) of the option to process is selected. 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….
]