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

Dear Ian,

Thanks again for the very helpful and detailed review I've updated the
document according to your comments (-02).

Please find below my initial responses to your comments.


On Tue, Jan 7, 2020 at 4:11 PM <[e-mail]> wrote:

> Hi,
>
> As mentioned in my previous email, here is my review
> of draft-ietf-dhc-slap-quadrant-01.
>
> Thanks,
> Ian
>
>
> 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.


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


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


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


> --------
>
>
> Sections 6 and 7.
>
>
> The IANA and Security Considerations need to be completed. I’ve indicated
> necessary registry updates where relevant.
>

[CB] Thanks, I've completed both sections.


>
>
>
> Minor Comments
> -----------------------
>
> Section 3.
>
> "Migratable/non-migratable VM.  If the function implemented by the VM is
> subject to be moved
> to another physical server or not.”
>
> Is the above statement accurate? Surely it’s the migration of the VM (and
> its function) to a new
> physical server that matters here.
>

[CB] OK, I've removed the "non-migratable" part to make it more
clear/accurate.


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


>
> ———
> Section 5.1
> The ERO option is introduced here, but I’m not sure how/why this would be
> used. If the server was to echo a Quad option back
> to a relay, what does it do with the received information?
>

[CB] I've removed it, because we don't really need this.


>
>
>
>
> Grammar / Wording comments
> -----------------------------------------
>
>
> 1.1.1. Wifi Devices
> "but ELI/SAI quadrants might be more suitable in some scenarios,
> such as if it is needed that the addresses belong to the CID
> assigned to the IoT communication device vendor.”
>
> Wording is quite cumbersome, suggest:
>
> "but ELI/SAI quadrants might be more suitable in some scenarios,
> such as if the addresses need to belong to the CID assigned to the IoT
> communication
>  device vendor.”
>

[CB] Thanks, I've adopted your suggested text.


> ——
>
> 1.1.2 Hypervisor: migratable vs non-migratable functions
>
> If a VM (providing a given function) might  need to be potentially migrated
> to another region of the data center (due to maintenance, resilience,
> end-user mobility, etc.) it is needed that this VM can keep its
> networking context in the new region, and this includes keeping
> its MAC addresses.
>
> The language is a bit redundnat in this sentance. Suggested re-word:
>
> If a VM (providing a given function) needs to be migrated to another region
> of the data center (e.g. for maintenance, resilience, end-user mobility,
> etc.),
> the VM's networking context needs to migrate with the VM. This includes
> the VM's
> MAC address(es).
>

[CB] Thanks, I've adopted your suggested text.


> ---
>
> Non-migratable functions.  If a VM will not be migrated to another
>       region of the data center, there are no requirements associated to
>       its MAC address, and then it is more efficient to allocate it from
>       the AAI SLAP quadrant, which does not need to be same for all the
>       data centers (i.e., each region can manage its own, without
>       checking for duplicates globally).
>
> Suggested re-word for readability:
>
> Non-migratable functions.  If a VM will not be migrated to another
>       region of the data center, there are no requirements associated with
>       its MAC address. In this case, it is more efficient to allocate it
> from
>       the AAI SLAP quadrant, that does not need to be unique across
>      multiple data centers (i.e., each region can manage its own MAC
> address
>      assignment, without checking for duplicates globally).
>

[CB] Thanks, I've adopted your suggested text.


> ——————
>
> 2. Terminology
>
> This has the following sentence:
> "The DHCPv6 terminology relevant to this specification from the DHCPv6
>    Protocol [RFC8415] applies here.”
>
> …then goes on to redefine client and server. Suggest that the above
> sentence
> is replaced with:
>
> “Where relevant, the DHCPv6 terminology from the DHCPv6
> Protocol [RFC8415] also applies here. Additionally, the following
> definitions are updated
> for this document."
>

[CB] Thanks, I've adopted your suggested text.

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


> —————
>
>
> 3. Quadrant selection mechanisms
>
> s/Quadrant selection mechanisms/Quadrant Selection Mechanisms/
>

[CB] Done, thanks.


> ----
>
> "We next describe some exemplary ways to perform SLAP quadrant
>    selection.  These are provided just as informational text to
>    exemplify how the quadrant preference mechanisms could be used.”
>
> Suggested re-word:
>
> The following section describes some examples of how the quadrant
> preference mechanisms could be used.
>

[CB] Done, thanks.


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

———
>
> The way that the IoT’s SLAP quadrant decision making is written implies a
> level of autonomy and free will
> that devices don’t possess and many of considerations are unknowable to
> the device itself. The bullet points are
> considerations that the device vendor/administrator may wish to use when
> defining the IoT device’s MAC
> address request policy. Please reword to reflect this.
>

[CB] Done.


> ——
>
> "IoT devices are typically very
>    resource constrained, so it might be as well that simple decisions
>    are just taken, for example based on pre-configured preferences.”
>
> Suggested reword for clarity:
>
> "IoT devices are typically very
>    resource constrained, so there may only be simple decision making
> process based on pre-configured preferences.”
>

[CB] Done.


> ——
>
> s/Most modern OS/Most modern OSs/
>

[CB] Done.

——
>
> s/and this might mean the OS to force the use or change of a local MAC
> address./
> and this might require that the OS forces the use of a local MAC address,
> or that
> the local MAC address is changed./
>

[CB] Done.


> ———
>
> 4.1 Address assignment from the preferred SLAP quadrant indicated by
>       the client
>
> s/Address assignment from the preferred SLAP quadrant indicated by
>       the client/Address Assignment from the Preferred SLAP Quadrant
> Indicated by
>       the Client/
>

[CB] Done.


> ——
>
> s/We describe next/Next, we describe/
>

[CB] Done.


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


> ————
>
>
> 4.2 Address assignment from the SLAP quadrant indicated by the relay
>
> s/Address assignment from the SLAP quadrant indicated by the relay/Address
> Assignment from the SLAP Quadrant Indicated by the Relay/
>

[CB] Done.


> ——
>
> s/We describe next/Next, we describe/
>

[CB] Done.


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

———
>
>
> 5.1. DHCPv6 options definitions
>
> s/DHCPv6 options definitions/DHCPv6 Option Definition/
>

[CB] Done.

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