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

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

Thanks Ben!

See inline below.

On Fri, Jul 31, 2020 at 8:08 PM Benjamin Kaduk <[e-mail]> wrote:

> 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).
>
> [Carlos] OK, changed.


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

[Carlos] OK, I see now. I think I'll keep the original text here.


>
> >
> > >
> > > 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,
>
> Thanks again!

Carlos


> Ben
>