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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk 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:
----------------------------------------------------------------------

I had a little bit of a hard time understanding how all the given
examples benefit from using a specific quadrant for their allocations,
but that may just be my lack of background, and in any case is not a
reason to hold up the document.

Section 1.1.1

   o  IoT (Internet of Things): where there are a lot of cheap,
      sometimes short lived and disposable devices.  Examples of this
      include: sensors and actuators for health or home automation
      applications.  In this scenario, it is common that upon a first
      boot, the device uses a temporary MAC address, to send initial
      DHCP packets to available DHCP servers.  IoT devices typically
      request a single MAC address for each available network interface.

I'm a bit confused by the use of present tense here ("it is common"),
given that AFAIK the companion document draft-ietf-dhc-mac-assign is the
first mechanism for DHCP-based MAC address assignment.

      temporary MAC address.  This type of device is typically not
      moving.  In general, any type of SLAP quadrant would be good for
      assigning addresses from, but ELI/SAI quadrants might be more
      suitable in some scenarios, such as if the addresses need to
      belong to the CID assigned to the IoT communication device vendor.

side note: I'm curious what kind of case would require that the address
belong to the CID of the device's vendor.

Section 2

Interesting that we say that client+server support IA_LL and LLADDR but
nothing about QUAD :)

Section 3

   change address several times).  This information includes, but it is
   not limited to:

   o  Type of network the device is connected: public, work, home.

   o  Trusted network?  Y/N.
   [...]

nit: it might be nice to use a parallel structure for all of the bullet
points ('?' vs ':', prose discussion vs short answer, etc.)

   o  Mobility?  Y/N.

A few more words about what sense "mobility" is used in might be in
order.

   quadrants.  If the device is not moving and attached to a trusted
   network (e.g. at work), then it is probably best to select the ELI

side note: it's not entirely clear that "at work" implies "not moving"
-- in some environments it's common to move between desk and conference
room, potentially on a different floor or in a different building.

   Last, if we consider the data center scenario, a hypervisor might
   request local MAC addresses to be assigned to virtual machines.  As
   in the previous scenarios, the hypervisor might select the preferred
   SLAP quadrant using information provided by the cloud management
   system (CMS) or virtualization infrastructure manager (VIM) running
   on top of the hypervisor.  This information might include, but is not
   limited to:

As was (IIRC) noted by a directorate reviewer, we don't use "CMS" or
"VIM" again, and since at least "CMS" collides with another well-known
IETF acronym, there seems to be little or negative value in including
the acronyms here.

Section 4.1

I suggest using "IA_LL(LLADDR,QUAD)" in step 1 of Figure 3, as is done
for the other lines, to match the prose text's MUST-level requirement to
include LLADDR.

       option.  In order to indicate the preferred SLAP quadrant(s), the
       IA_LL option includes the new OPTION_SLAP_QUAD option in the
       IA_LL-option field (with the LLAADR option).

Even though QUAD does not give provision for nested options, it would
perhaps be better to use "alongside" or "as a sibling of" or similar,
rather than "with", to describe the relationship between QUAD and
LLADDR.
Also, nit: s/LLAADR/LLADDR/.

       an LLADDR option that specifies the addresses being offered.  If
       the server supports the new QUAD IA_LL-option, and manages a
       block of addresses belonging to the requested quadrant(s), the
       addresses being offered MUST belong to the requested quadrant(s).

nit: I don't expect a single block of addresses to span quadrant
boundaries, so perhaps "belonging to a requested quadrant" and "MUST
belong to a requested quadrant" would be more appropriate.

   3.  The client waits for available servers to send Advertise
       responses and picks one server as defined in Section 18.2.9 of
       [RFC8415].  The client SHOULD NOT pick a server that does not
       advertise an address in the requested quadrant.  The client then

Perhaps "quadrant(s)" or "a requested quadrant", to match the previous
discussion?

       sends a Request message that includes the IA_LL container option
       with the LLADDR option copied from the Advertise message sent by
       the chosen server.  It includes the preferred SLAP quadrant(s) in
       the new QUAD IA_LL-option.

nit: I think s/the new/a new/ is better, since we have not discussed a
new QUAD option in the Request yet.

   The client SHOULD check if the received MAC address comes from one of
   the requested quadrants.  Otherwise, the client SHOULD NOT configure
   the obtained address.  It MAY repeat the process selecting a
   different DHCP server.

"repeat the process" sounds like sending the same Renew to a different
server, that is, different from the server that assigned the address
whose renewal is being requested.  Is that expected to be effective
(either in renewing the current assignment or in getting a new
allocation in a Reply, as opposed to an "I don't know about that" error
response)?

Section 4.2

side note: It's interesting to me that QUAD is not included in a
Relay-reply(Advertise()) but is included in a regular Advertise() when
no proxy is involved.  (Likewise for wrapped Reply().)

        payload.  Depending on the server's policy, the instance(s) of
        the option to process is selected.  For each of the entries in

Just to check: this is intended to allow both "use only one, and if both
are present which to use is up to local policy" and "apply the
intersection of both requests [with some local policy for which priority
to respect]"?  I note that later on we have some text that makes it
RECOMMENDED to prefer the client's, in a discussion that does not cover
the "intersection" option at all.  So perhaps the "intersection" option
is not intended to be available?

        in a Relay-reply message.  If the server supports the semantics
        of the preferred quadrant included in the QUAD option, and
        manages a block of addresses belonging to the requested
        quadrant(s), then the addresses being offered MUST belong to the
        requested quadrant(s).  The server SHOULD apply the contents of

[same nit as for §4.1]

   10.  This message is forwarded by the Relay in a Relay-forward
        message, including a QUAD IA_LL-option with the preferred
        quadrant.

I would consider repeating the mention from above about how the QUAD is
included here in case the server has to make a new assignment, to make
sure that the client (well, proxy's) preference is available in such
cases.

Section 5.1

   quadrant-n      Identifier of the quadrant (0: AAI, 1: ELI, 2:
                   Reserved, 3: SAI).  Each quadrant MUST only appear
                   once at most in the option.  A 1-byte field.

Perhaps note that this is Reserved in the sense of the IEEE quadrant,
not the usual IETF/IANA "reserved" usage?

   assigned preference).  Note that a quadrant - preference tuple is

nit: earlier we spell this a "(quadrant, preference) pair".  Using
consistent notation/terminology seems advisable.

   used in this option (instead of using a list of quadrants ordered by
   preference) to support the case whereby a client really has no
   preference between two or three quadrants, leaving the decision to
   the server.

side note: it's not 100% clear to me that we need to exclude the "no
preference among all four quadrants" case, though I certainly am not
insisting that we include it.

   specified quadrants, it SHOULD proceed with the assignment.  If the
   server cannot provide an assignment from one of the specified
   quadrant-n fields, it MUST NOT assign any addresses and return a
   status of NoQuadAvail (IANA-2) in the IA_LL Option.

This text seems to lose some of the subtlety around NoQuadAvail vs.
NoAddrsAvail that is prsent in Section 4.1.  It would be good to be
consistent about how we discuss these cases.

Section 7

Do I understand correctly that there is no technical mechanism to
prevent a relay from inserting a QUAD option inside what is nominally
the client's IA_LL, as opposed to as a top-level option in Relay-forward
(which is what it's "supposed to" do)?  We should probably say something
about how the proxy has to be trusted to do the right thing and a
malicious proxy could change/override the client's preference.

I'm surprised that RFC 7227 is not referenced here.

Though it is not referenced (yet?), RFC 7227 says that authors of
documents defining new DHCP options are "strongly advised to explicitly
define validation measures" for recipients of such options.  I do not
see much discussion of validation measures in this document (despite
there being MUST-level requirements on the quadrant-n fields with
respect to each other), just a mention that "first occurrance wins",
which is not exactly a validation step but more of a processing one; why
is there no need to provide more detailed validation measures?

Section 8

   The work in this draft will be further developed and explored under
   the framework of the H2020 5Growth (Grant 856709) and 5G-DIVE
   projects (Grant 859881).

I'm not 100% sure that we need to speculate about the future here
(especially given that it would become stale as time passes); would it
suffice to say that "this work is supported by" the grants in question?

Section 9.1

It's not entirely clear to me that we reference RFC 8200 in a normative
fashion.