Last Call Review of draft-ietf-dhc-slap-quadrant-09
review-ietf-dhc-slap-quadrant-09-genart-lc-robles-2020-05-27-01

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