I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dhc-slap-quadrant-09
Reviewer: Ines Robles
Review Date: 2020-05-27
IETF LC End Date: 2020-05-27
IESG Telechat date: 2020-06-11

Summary:

This document proposes extensions to DHCPv6 protocols to enable a
   DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant
   to the server, so that the server allocates the MAC addresses to the
   given client out of the quadrant requested by relay or client.  A new
   DHCPv6 option (OPTION_SLAP_QUAD, or QUAD) is defined for this
   purpose.

The document is easy to read, however I have some minor issues/questions for the authors that would be nice to be addressed. 

The review was done for version 08, but after a look at the diff with version 09,  I believe my comments apply for version 09 as well.

Major issues: Not found

Minor issues:

Section 1:

1- Should be specified for each quadrant  who is responsible to ensure: a) uniqueness of assigned addresses and b) compatibility with other assignment protocols on the same LAN (if applicable)?, e.g for AAI, the administrator should be the responsible?

2- The caption in Figure 1, should state: "Initial octet of the IEEE 48-bit MAC address structure?" since it is represented 1 byte in the figure instead of the 6 bytes.

Section 1.1.1:

3- Should be added "(IEEE 802.11)" to WiFi?

4- When it is mentioned IoT devices, I think it would be nice identify the use case with the class of device (RFC7228)
 instead of "there are a lot of cheap, sometimes short lived and disposable devices".
  I am not sure if cheap is a right word here, since it is subjective, I mean it has to be defined what is considerate cheap.
  Relate with -short lived- it could be due to a malfunction that the device gets broken, thus I suggest to use "battery-powered device" or similar.
  Thus, a suggestion: "IoT (Internet of Things): In general, composed of constrained devices [RFC7228] with constrains such as ..."

  Note: There is another document taking place for IoT terminology [draft-bormann-lwig-7228bis]

  5- Related to: " This type of device is typically not moving".  There is  a reference for this? Following my understanding there is a huge amount of smart health devices that are mobile

  Section 2:

  6- It would be nice to add the definition and expansion for IA_LL and LLADDR

  Section 3:

  7- Related to "Managed/unmanaged: depending on whether the IoT device is managed during its lifetime or cannot be re-configured the selected
      quadrant might be different...."

  7.1-It would be nice to describe the example referencing the management during the life cycle (rfc7548#section-3)

  7.2- The sentence is not fully clear to me. "quadrant might be different" would it be better: "the quadrant might change when the device gets a configuration update"? Or the draft refers self-managed devices (rfc7547#section-3.5) gets a quadrant different to those managed by a manager server? 
  There are specific quadrant recommendations for different IoT configuration functionality levels (RFC7547, section 1.7)?

  7.3 "it can be managed, this means that network topology changes might occur during its lifetime": Would it be better to explain this based on the Dynamicity level of the network topology (rfc7547#section1.3), for example smth like: "networks with high dinamicity level have high probability of quadrant changes", does it make sense?


Section 7:

Should the security considerations section includes reference to the security section and privacy considerations of RFC7227?

Nits/editorial comments: Not found

Thank you for this document,

Ines