[dhcwg] Barry Leiba's No Objection on draft-ietf-dhc-mac-assign-06: (with COMMENT)

Barry Leiba via Datatracker <noreply@ietf.org> Wed, 27 May 2020 04:58 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 DB96F3A00D5; Tue, 26 May 2020 21:58:53 -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-mac-assign@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.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <159055553387.7203.260400410044352642@ietfa.amsl.com>
Date: Tue, 26 May 2020 21:58:53 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/DiMWkzoDnrfNs-JaiPKknaUEphM>
Subject: [dhcwg] Barry Leiba's No Objection on draft-ietf-dhc-mac-assign-06: (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: Wed, 27 May 2020 04:58:54 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-dhc-mac-assign-06: 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-mac-assign/



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

Amazingly, “MAC” is not flagged as well-known in the RFC Editor abbreviations
list (we probably should suggest that “MAC address” be so flagged), so it
should be expanded on first use in the Introduction.

— Section 1 —

   a link-layer
   assignment mechanisms allows for conflicts to be avoided

Nit: “mechanism”, singular.

   types of resources (non-temporary addresses, temporary addresses,
   prefixes, but also many options)

The “but” feels wrong here.  I think I would change “but also” to “as well as”.

   and has necessary infrastructure
   (numerous server and client implementations, large deployed relay
   infrastructure, supportive solutions, like leasequery and failover)
   to maintain such assignment

Two things here: you used “allocate” before, not “assign”, so “such assignment”
doesn’t work.  And the parenthetical is too long for it to split the sentence
as it does:

NEW
   and has necessary infrastructure to maintain such allocation
   (numerous server and client implementations, large deployed relay
   infrastructure, supportive solutions like leasequery and failover)
END

   specified an optional specification (IEEE 802c) that divides this

“specified a specification” is awkward.  It’s probably better as “published an
optional specification”.  Also, why isn’t “IEEE 802c” a proper reference
citation?  You do have the reference, and it’s cited in Appendix A.  Why not
cite it here?

— Section 4.1 —

   block), to be then assigned for use to the final end-devices.

I would say, “to be then assigned for use by the final end-devices,” or, “to be
then assigned to the final end-devices for their use.”

   One
   relevant example of scenario of application of this mode is large
   scale virtualization.

“example of scenario of application of this mode” doesn’t work.  How about,
“Large-scale virtualization is one application scenario for proxy client mode.”?

   hypervisor is likely to increase its addresses usage.

Nit: “address usage”

— Section 4.2 —

   This mode is used when an entity acts as a DHCP client and requests
   available DHCP servers to assign one or more addresses (an address
   block) for its own use.

I don’t think you mean “for its own use”, which would be referring to one of
the servers.  I think you mean that the block is for the client’s use, so just
“for its use.”

— Section 4.3 —

   An administrator may also disable the need for the
   renewal mechanism by setting the T1 and T2 values to infinity.

You already said this a few paragraphs earlier.  Maybe check the organization
of this section?

   small footprint devices may choose to not support it.

Nit: hyphenate “small-footprint”.

— Section 6 —

   A client sets the extra-addresses field to either 0 for a single
   address or to the size of the requested address block minus 1.

Think of “either” and “both” as parentheses.  Here, the word “to” is outside
the parentheses and shouldn’t be repeated inside.  So make it “to either 0 for
a single address or the size...” or “either to 0 for a single address or to the
size...”.

— Section 7 —

   or an address or addresses different
   than those requested.

Nit: either “different from” (US usage) or “different to” (UK usage), but not
“different than”.

— Section 13 —

   There is a possibility of the same link-layer address being used by
   more than one device if not all parties on a link use this mechanism
   to obtain a link-layer address from the space assigned to the DHCP
   server.  It is also possible that a bad actor purposely uses a
   device's link-layer address.

It seems that it would be worth adding something about what the consequences of
that are.

Might it also be worth mentioning that a malicious client could request a very
large block of addresses and thus deplete the supply available to legitimate
clients?  If so, noting possible defense against that (such as a server policy
about maximum address block size) might also be useful.