[dhcwg] Barry Leiba's No Objection on draft-ietf-dhc-slap-quadrant-09: (with COMMENT)

Barry Leiba via Datatracker <noreply@ietf.org> Tue, 09 June 2020 01:44 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 7ED243A08EF; Mon, 8 Jun 2020 18:44:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-dhc-slap-quadrant@ietf.org, dhc-chairs@ietf.org, dhcwg@ietf.org, Tomek Mrugalski <tomasz.mrugalski@gmail.com>, Ian Farrer <ianfarrer@gmx.com>, ianfarrer@gmx.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.3.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <159166707503.4308.11011951864784667729@ietfa.amsl.com>
Date: Mon, 08 Jun 2020 18:44:35 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/mx4USBxcOE9fwamR4C0intCqeWU>
Subject: [dhcwg] Barry Leiba's No Objection on draft-ietf-dhc-slap-quadrant-09: (with COMMENT)
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: Tue, 09 Jun 2020 01:44:36 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-dhc-slap-quadrant-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-slap-quadrant/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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