[dhcwg] Alvaro Retana's No Objection on draft-ietf-dhc-mac-assign-07: (with COMMENT)

[Alvaro Retana via Datatracker <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-dhc-mac-assign-07: 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:
----------------------------------------------------------------------

(0) I support Ben's DISCUSS.

(1) An informative reference to the "birthday paradox" would be nice.

(2) §4.2

   Note that a client that operates as above that does not have a
   globally unique link-layer address on any of its interfaces MUST NOT
   use a link-layer based DUID (DHCP Unique Identifier), i.e., DUID-LLT
   or DUID-LL, for its client identifier.  As of this writing, this
   means such a device MUST use a DUID-EN or DUID-UUID (though new DUID
   types may be defined in the future).  For more details, refer to
   Section 11 of [RFC8415].

Given that "new DUID types may be defined in the future", and assuming that it
applies to any type of DUID, it may be a good idea to generalize/simplify this
paragraph.

NEW>
   A client that operates as above that does not have a globally unique
   link-layer address on any of its interfaces MUST NOT use a link-layer based
   DUID (DHCP Unique Identifier).  For more details, refer to Section 11 of
   [RFC8415].

(3) s/allocates block/allocates a block

(4) §7:

   The client MUST be able to handle an Advertise message containing a
   smaller number of addresses, or an address or addresses different
   from those requested.
   ...
   The client MUST be able to handle a Reply message containing a
   smaller number of addresses, or an address or addresses different
   from those requested.

What does "MUST be able to handle" mean?  Being able to handle something
doesn't sound normatively enforceable.  I'm guessing that maybe the client MUST
accept the allocation...but this interpretation might be in conflict with §9. 
Ben offered other suggestions in his review.

(5) §10.1  As far as I can see, some of the fields (IAID, T1, T2) (should) have
the same definition as in rfc8415.  To avoid duplicating the definition, or
deviating from it, consider simply pointing at the definition there.

(6) s/If the time at which the addresses in an IA_LL are to be renewed is to be
left to the discretion of the client, the server sets T1 and T2 to 0./If the
server sets T1 and T2 to 0, then the time at which the addresses in an IA_LL
are to be renewed is to be left to the discretion of the client.

(7) §10.1: "the client MUST use the values in the T1 and T2 fields for the T1
and T2 times, unless those values in those fields are 0."  This sounds as if 0
is not valid.  Maybe "MUST set" would be better.

(8) I-D.ietf-dhc-slap-quadrant and IEEEStd802c-2017 should be Normative
references.