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

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

Hi Benjamin,

Thanks a lot for your review, and apologies for the belated reply.

Please see below inline some comments. All changes are applied to -10, to
be posted soon.

On Tue, Jun 9, 2020 at 12:40 AM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

> 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.
>

[Carlos] You are right. We have rewritten it using "In this scenario, a
reasonable
behavior would be that, upon a first boot, [...]"


>       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.
>

[Carlos] This also comes from IEEE feedback. It seems realistic that some
devices cannot come with a burned-in address, but still want to use a local
address using 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 :)
>
> [Carlos] Good point. We've fixed it. Thanks.


> 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.)
>

[Carlos] OK, done. Though some of the prose discussion has been kept as I
believe it was needed (the points were not straightforward to follow).


>
>    o  Mobility?  Y/N.
>
> A few more words about what sense "mobility" is used in might be in
> order.
>

[Carlos] Done.


>
>    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.
>

[Carlos] Thanks, good points. I've massaged a bit the text in that part.


>    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.
>

[Carlos] Fixed. I've removed the acronym and now use the expanded term.


>
> 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.
>

[Carlos] Done.


>
>        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.
>

[Carlos] OK, thanks. I've picked "alongside".


> Also, nit: s/LLAADR/LLADDR/.
>

[Carlos] Thanks, fixed.


>
>        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.
>

[Carlos] OK, thanks.


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

[Carlos] OK, thanks, picked "quadrant(s)".


>
>        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.
>

[Carlos] OK, thanks.


>
>    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)?
>
> [Carlos] We have changed this, based on feedback received at both IETF and
IEEE, and now reads as follows:

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

The idea is that the client might pick a different server from those that
sent and Advertise and try.


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

[Carlos] The intended idea is "use only one, and if both are present which
to use is up to local policy".


>
>         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]
>

[Carlos] OK, fixed.


>
>    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.
>

[Carlos] Not sure I got your point here. Do you mean using the text in #2?


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

[Carlos] Good point, thanks. I've used "Reserved by IEEE" and a ref
to [IEEEStd802c])


>    assigned preference).  Note that a quadrant - preference tuple is
>
> nit: earlier we spell this a "(quadrant, preference) pair".  Using
> consistent notation/terminology seems advisable.
>

[Carlos] Thanks. This specific paragraph has been revised as a result of
another comment we received. Now only "pair" is used in the document.


>    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.
>

[Carlos] Well, since at the time of writing this there are only 3 possible
quadrants, we are de-facto considering the case of "no preference among all
possible quadrants". I guess this was your point, no?


>
>    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.
>

[Carlos] OK, fixed.


>
> 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.
>

[Carlos] I assume here the considerations described in RFC 8415 would
apply.

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

[Carlos] It is now. We got the same comment from another reviewer ;)


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

[Carlos] RFC 7227 also states that "However, validation measures already
defined by RFC 3315 or other specifications referenced by the new option
document are redundant and can introduce errors, so authors are equally
strongly advised to refer to the base specification for any such validation
language rather than copying it into the new specification." We refer to
RFC 8415 (which obsoletes 3315), assuming that this is sufficient.


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

[Carlos] OK, revised.


>
> Section 9.1
>
> It's not entirely clear to me that we reference RFC 8200 in a normative
> fashion.
>
> [Carlos] I agree. I've moved it to informative (also being consistent with
draft-ietf-dhc-mac-assign).

Thanks a lot!

Carlos