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

[Benjamin Kaduk <[e-mail]>]

Hi Carlos,

Thanks for the follow-up and updates.  Just a couple things inline...

On Fri, Jul 31, 2020 at 02:44:03PM +0200, CARLOS JESUS BERNARDOS CANO wrote:
> 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.

Makes sense; thanks.

> 
> >
> > 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 that case, I'd suggest to just say "instance" and not "instance(s)",
since only one instance is actually processed by the server (if I
understand correctly).

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

Sorry, I see now that this comment was too vague.
What I meant was that up in Section 4.1, when we talk about what seems to
be a similar situation, we say:

                 It includes the preferred SLAP quadrant(s) in the new
       QUAD IA_LL-option, so in case the server is unable to extend the
       lifetime on the existing address(es), the preferred quadrants are
       known for the allocation of any "new" (i.e., different)
       addresses.

I was wondering if there was value in including a similar statement in this
location.  ("No value" is a perfectly valid answer!)

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

Probably.  (To be honest, I don't remember exactly what my point was...)

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

That seems pretty plausible, good point.

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

Okay, thanks for the extra explanation (and reading 7227 more carefully
than me!).

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

Thank you as well,

Ben