[dhcwg] Genart last call review of draft-ietf-dhc-slap-quadrant-09

Ines Robles via Datatracker <noreply@ietf.org> Wed, 27 May 2020 20:59 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E593A0BF0; Wed, 27 May 2020 13:59:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ines Robles via Datatracker <noreply@ietf.org>
To: <gen-art@ietf.org>
Cc: draft-ietf-dhc-slap-quadrant.all@ietf.org, last-call@ietf.org, dhcwg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159061319196.9649.15971472183672816729@ietfa.amsl.com>
Reply-To: Ines Robles <mariainesrobles@googlemail.com>
Date: Wed, 27 May 2020 13:59:52 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/DHDKreiabyoE-xUk3H7EBvY0PAk>
Subject: [dhcwg] Genart last call review of draft-ietf-dhc-slap-quadrant-09
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2020 21:00:00 -0000

Reviewer: Ines Robles
Review result: Ready with Issues

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


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


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

The document is easy to read, however I have some minor issues/questions for
the authors

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 you are representing 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
  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 use
  battery-powered device or similar. Thus, it could be: "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

  5- Related to: " This type of device is typically not moving". Do you have 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,