Ballot for draft-ietf-dhc-slap-quadrant
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
Thank you for this short document. Please address all comments from the INT directorate review by Jinmei: https://datatracker.ietf.org/doc/review-ietf-dhc-slap-quadrant-08-intdir-lc-jinmei-2020-05-18/ as well as the IoT directorate review by Jaime Jimenez: https://datatracker.ietf.org/doc/review-ietf-dhc-slap-quadrant-07-iotdir-lc-jimenez-2020-06-04/ Regards -éric
As with Robert, I'm interested to hear what coordination with IEEE has occurred, both for this and for the companion "mac-assign" document. I'm also, as Warren, puzzled as to why the Shepherd Writeup claims there's no IPR claim when the datatracker disagrees, and struck by how much text here overlaps with the "mac-assign" document. As for editorial remarks, I have some: Section 1: * I am unable to parse the bullet that defines the "Administratively Assigned Identifier" quadrant. Section 1.1.1: * "Examples of this include: sensors ..." -- remove the colon * "... temporary MAC address, to send initial ..." -- remove the comma * "... good for assigning addresses from, but ..." -- remove "from" * "... easy to track users' movement." -- s/movement/movements/ * "... best SLAP quadrant to assign addresses from, ..." -- suggest "best SLAP quadrant from which to assign addresses, ..." Section 2: * Although I realize this section is explicit about where "IA_LL" and "LLADDR" are formally defined, it might be nice to provide their full prose names on first use. * "... typically 6 bytes long ..." -- s/6/six/ Section 3: * "If we now take the ..." -- suggest "Next, consider the ..." * Generally I found this section to have a mushy sort of structure. It begins and ends by mapping certain use cases onto certain quadrants explicitly, but in the middle seems to wander into a checklist of things you might think about without mapping those concepts toward a preferred quadrants. You might consider firming this up with, perhaps four separate paragraphs, or even subsections, each describing ideal uses for one of the quadrants, taking into account the facets of that choice you've enumerated here. Section 6 * I suggest omitting the IANA URL. What if it were to change? All you really need is the registry name.
I have one substantive / process question — the Shepherd writeup says that no IPR disclosures exist, but there does seem to be one — I wanted to make sure that this had been noted / process had been followed... Otherwise, seems good - I must admit I don’t like the fact that there is so much repeated text with the MAC assign document, and that it isn’t clearer that MACs only really have to be unique per segment, but those are just prefernces / opinions... Thank you for writing this, W
I support Rob's DISCUSS. IEEEStd802c-2017 should be a Normative reference.
— Abstract — The IEEE is working on mechanisms to allocate addresses in the one of these quadrants (IEEE 802.1CQ). Nit: change “in the one of” to “in one of”. given client out of the quadrant requested by relay or client. Nit: make it “by the relay or client.” — Section 1 — Multicast IPv6 packets use a destination address starting in 33-33 and this falls within this space and therefore should not be used to avoid conflict with the MAC addresses used for use with IPv6 multicast addresses. There are multiple problems with this sentence, starting with its being too long. I suggest this (but please correct this if I got it wrong): NEW Multicast IPv6 packets use a destination address starting with 33-33, which falls within the AAI quadrant. Those addresses should not be used, in order to avoid conflict with the MAC addresses used for IPv6 multicast. END o Quadrant "Reserved for future use" where MAC addresses may be Nit: remove “where”. — Section 1.1 — allocates the MAC address to the given client out of the quadrant requested by relay or client. Nit: make it “by the relay or client.” — Section 3 — o Type of IoT deployment: e.g., industrial, domestic, rural, etc. For small deployments, such as domestic ones, the IoT itself can Twice in this paragraph you say “the IoT”, when I think you mean “the IoT device”. IoT devices are typically very resource constrained, so there may only be simple decision making process Make it “be a simple decision-making process” If we now take the WiFi device scenario, considering for example that a laptop or smartphone connects to a network using its built in MAC address. This is not a complete sentence; please make it one. Besides, changing the SLAP quadrant used might also be used as an additional enhancement to make it harder to track the user location. This is awkward, “used might also be used”. I suggest, “...changing the SLAP quadrant might also...”. SLAP quadrant using information provided by the cloud management system (CMS) or virtualization infrastructure manager (VIM) running Neither abbreviation is used elsewhere in this document, so I suggest removing both “(CMS)” and “(VIM)”. as some quadrants are better suited (e.g., ELI/SAI) for supporting migration in a large The parenthetical is misplaced and interrupts the sentence flow. NEW as some quadrants (ELI and SAI) are better suited for supporting migration in a large END or, better still: NEW as the ELI and SAI quadrants are better suited for supporting migration in a large END o VM connectivity characteristics , e.g.,: standalone, part of a Nit: punctuation around “e.g.” is wrong: NEW o VM connectivity characteristics, e.g., standalone, part of a END — Section 4.1 — The client SHOULD NOT pick a server that does not advertise an address in the requested quadrant. This SHOULD NOT doesn’t make sense to me. Why would it? What would be an informed reason to pick one that doesn’t have what it wants? Is there a reason not to just say, “The client will pick a server that advertises an address in the quadrant the client requested,” without using BCP 14 key words?
I had a little bit of a hard time understanding how all the given examples benefit from using a specific quadrant for their allocations, but that may just be my lack of background, and in any case is not a reason to hold up the document. Section 1.1.1 o IoT (Internet of Things): where there are a lot of cheap, sometimes short lived and disposable devices. Examples of this include: sensors and actuators for health or home automation applications. In this scenario, it is common that upon a first boot, the device uses a temporary MAC address, to send initial DHCP packets to available DHCP servers. IoT devices typically request a single MAC address for each available network interface. I'm a bit confused by the use of present tense here ("it is common"), given that AFAIK the companion document draft-ietf-dhc-mac-assign is the first mechanism for DHCP-based MAC address assignment. temporary MAC address. This type of device is typically not moving. In general, any type of SLAP quadrant would be good for assigning addresses from, 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. side note: I'm curious what kind of case would require that the address belong to the CID of the device's vendor. Section 2 Interesting that we say that client+server support IA_LL and LLADDR but nothing about QUAD :) Section 3 change address several times). This information includes, but it is not limited to: o Type of network the device is connected: public, work, home. o Trusted network? Y/N. [...] nit: it might be nice to use a parallel structure for all of the bullet points ('?' vs ':', prose discussion vs short answer, etc.) o Mobility? Y/N. A few more words about what sense "mobility" is used in might be in order. quadrants. If the device is not moving and attached to a trusted network (e.g. at work), then it is probably best to select the ELI side note: it's not entirely clear that "at work" implies "not moving" -- in some environments it's common to move between desk and conference room, potentially on a different floor or in a different building. Last, if we consider the data center scenario, a hypervisor might request local MAC addresses to be assigned to virtual machines. As in the previous scenarios, the hypervisor might select the preferred SLAP quadrant using information provided by the cloud management system (CMS) or virtualization infrastructure manager (VIM) running on top of the hypervisor. This information might include, but is not limited to: As was (IIRC) noted by a directorate reviewer, we don't use "CMS" or "VIM" again, and since at least "CMS" collides with another well-known IETF acronym, there seems to be little or negative value in including the acronyms here. Section 4.1 I suggest using "IA_LL(LLADDR,QUAD)" in step 1 of Figure 3, as is done for the other lines, to match the prose text's MUST-level requirement to include LLADDR. option. In order to indicate the preferred SLAP quadrant(s), the IA_LL option includes the new OPTION_SLAP_QUAD option in the IA_LL-option field (with the LLAADR option). Even though QUAD does not give provision for nested options, it would perhaps be better to use "alongside" or "as a sibling of" or similar, rather than "with", to describe the relationship between QUAD and LLADDR. Also, nit: s/LLAADR/LLADDR/. an LLADDR option that specifies the addresses being offered. If the server supports the new QUAD IA_LL-option, and manages a block of addresses belonging to the requested quadrant(s), the addresses being offered MUST belong to the requested quadrant(s). nit: I don't expect a single block of addresses to span quadrant boundaries, so perhaps "belonging to a requested quadrant" and "MUST belong to a requested quadrant" would be more appropriate. 3. The client waits for available servers to send Advertise responses and picks one server as defined in Section 18.2.9 of [RFC8415]. The client SHOULD NOT pick a server that does not advertise an address in the requested quadrant. The client then Perhaps "quadrant(s)" or "a requested quadrant", to match the previous discussion? sends a Request message that includes the IA_LL container option with the LLADDR option copied from the Advertise message sent by the chosen server. It includes the preferred SLAP quadrant(s) in the new QUAD IA_LL-option. nit: I think s/the new/a new/ is better, since we have not discussed a new QUAD option in the Request yet. 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. "repeat the process" sounds like sending the same Renew to a different server, that is, different from the server that assigned the address whose renewal is being requested. Is that expected to be effective (either in renewing the current assignment or in getting a new allocation in a Reply, as opposed to an "I don't know about that" error response)? Section 4.2 side note: It's interesting to me that QUAD is not included in a Relay-reply(Advertise()) but is included in a regular Advertise() when no proxy is involved. (Likewise for wrapped Reply().) payload. Depending on the server's policy, the instance(s) of the option to process is selected. For each of the entries in Just to check: this is intended to allow both "use only one, and if both are present which to use is up to local policy" and "apply the intersection of both requests [with some local policy for which priority to respect]"? I note that later on we have some text that makes it RECOMMENDED to prefer the client's, in a discussion that does not cover the "intersection" option at all. So perhaps the "intersection" option is not intended to be available? in a Relay-reply message. If the server supports the semantics of the preferred quadrant included in the QUAD option, and manages a block of addresses belonging to the requested quadrant(s), then the addresses being offered MUST belong to the requested quadrant(s). The server SHOULD apply the contents of [same nit as for §4.1] 10. This message is forwarded by the Relay in a Relay-forward message, including a QUAD IA_LL-option with the preferred quadrant. I would consider repeating the mention from above about how the QUAD is included here in case the server has to make a new assignment, to make sure that the client (well, proxy's) preference is available in such cases. Section 5.1 quadrant-n Identifier of the quadrant (0: AAI, 1: ELI, 2: Reserved, 3: SAI). Each quadrant MUST only appear once at most in the option. A 1-byte field. Perhaps note that this is Reserved in the sense of the IEEE quadrant, not the usual IETF/IANA "reserved" usage? assigned preference). Note that a quadrant - preference tuple is nit: earlier we spell this a "(quadrant, preference) pair". Using consistent notation/terminology seems advisable. used in this option (instead of using a list of quadrants ordered by preference) to support the case whereby a client really has no preference between two or three quadrants, leaving the decision to the server. side note: it's not 100% clear to me that we need to exclude the "no preference among all four quadrants" case, though I certainly am not insisting that we include it. 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 (IANA-2) in the IA_LL Option. This text seems to lose some of the subtlety around NoQuadAvail vs. NoAddrsAvail that is prsent in Section 4.1. It would be good to be consistent about how we discuss these cases. Section 7 Do I understand correctly that there is no technical mechanism to prevent a relay from inserting a QUAD option inside what is nominally the client's IA_LL, as opposed to as a top-level option in Relay-forward (which is what it's "supposed to" do)? We should probably say something about how the proxy has to be trusted to do the right thing and a malicious proxy could change/override the client's preference. I'm surprised that RFC 7227 is not referenced here. Though it is not referenced (yet?), RFC 7227 says that authors of documents defining new DHCP options are "strongly advised to explicitly define validation measures" for recipients of such options. I do not see much discussion of validation measures in this document (despite there being MUST-level requirements on the quadrant-n fields with respect to each other), just a mention that "first occurrance wins", which is not exactly a validation step but more of a processing one; why is there no need to provide more detailed validation measures? Section 8 The work in this draft will be further developed and explored under the framework of the H2020 5Growth (Grant 856709) and 5G-DIVE projects (Grant 859881). I'm not 100% sure that we need to speculate about the future here (especially given that it would become stale as time passes); would it suffice to say that "this work is supported by" the grants in question? Section 9.1 It's not entirely clear to me that we reference RFC 8200 in a normative fashion.
Discuss cleared. The document has been reviewed by some members of IEEE, and appropriate mark ups have been made. Thank you for your perseverance to see this one through. Rob Previous discuss comment: Disclaimer: I'm not familiar with IEEE 802.1CQ, nor am I a DHCPv6 expert ... Some of these questions/comments may have been answered there. My first question relates to process: Have members of the IEEE 802.1WG had an opportunity to review and provide input into this document? If not, then I think that it would be good for them to be given the opportunity to do so. In particular, they might question whether it is appropriate for a client to be able to request MAC addresses to be assigned from the SAI or "reserved for future use" address pools. It is worth noting that there is an IETF-IEEE liaison meeting on Mon 15th, that may help. I'm not sure that I really like how the algorithm is defined in this document (relative to draft-ietf-dhc-mac-assign). In draft-ietf-dhc-mac-assign, the client makes a request, and the server can respond with a completely different smaller MAC address range, i.e. the client is just providing hints/suggestions to the server. I would be much happier if the QUAD option specified in this document behaved similarly. I.e. the QUAD option is used by a client to specify an ordered preference of quads to use, but otherwise the server is allow to offer up an address, or block of addresses, outside the preferred quads, which the client could choose to not accept, or release. Previous non blocking comments. 1. Introduction o Quadrant "Administratively Assigned Identifier" (AAI) MAC addresses are assigned locally by an administrator. Multicast IPv6 packets use a destination address starting in 33-33 and this falls within this space and therefore should not be used to avoid conflict with the MAC addresses used for use with IPv6 multicast addresses. For 48-bit MAC addresses, 44 bits are available. Multicast IPv6 packets shouldn't be a problem for the AAI range, on the assumption that only unicast MAC addresses get assigned. Hence, probably the text related to Multicast IPv6 addresses can be deleted. 3. Quadrant Selection Mechanisms examples I see that this text as not being normative, and is potentially somewhat repeating what has been stated in the introduction. I think that this text might be better moved to an appendix. 4. DHCPv6 Extensions The algorithmic description in this document seems to heavily overlap with the algorithm described in draft-ietf-dhc-mac-assign, with a fair amount of repetitive descriptive text of the algorithm. I believe that it would be better if this option was written as a modification of the procedure defined in draft-ietf-dhc-mac-assign (particularly, if the algorithm is simplified as a I propose in my discuss).