Last Call Review of draft-ietf-dhc-mac-assign-06
review-ietf-dhc-mac-assign-06-intdir-lc-jinmei-2020-06-03-00

I am an assigned INT directorate reviewer for
draft-ietf-dhc-mac-assign. These comments were written primarily for
the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat
comments from any other IETF contributors and resolve them along with
any other Last Call comments that have been received. For more details
on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ .

I've reviewed draft-ietf-dhc-mac-assign-06 (07 was submitted while I
was reviewing 06, and I also checked 07 on some specific points to see
if it's changed, but the check is not comprehensive so some comments
may be already moot or addressed.)  I think this draft is basically
ready.  Its purpose and protocol details are well written, and the
protocol is generally a straightforward application of the basic
DHCPv6 (IP) address assignment protocol as described in RFC8415.  I
didn't find any obvious problem.

My comments are largely editorial.  The first one for Section 8 may
need some discussion, but I'd basically leave the authors whether/how
to address the comments including this one.

Specific comments:

- Section 1:

   The IEEE originally set aside half of the 48-bit MAC Address space
   for local use (where the U/L bit is set to 1).  In 2017, the IEEE
   specified an optional specification (IEEE 802c) that divides this
   space into quadrants (Standards Assigned Identifier, Extended Local
   Identifier, Administratively Assigned Identifier, and a Reserved
   quadrant) - more details are in Appendix A.

I wonder whether this paragraph could refer to draft-ietf-dhc-slap-quadrant.

- Section 4

   Clients implementing this mechanism SHOULD use the Rapid Commit
   option as specified in Section 5.1 and 18.2.1 of [RFC8415].

Just out of curiosity, what's the rationale of this SHOULD?  (It's not
obvious to me and) it doesn't seem to be explained anywhere in the
draft.

- Section 8

   [...]  The server MUST NOT shrink or expand the address block - once
   a block is assigned and has a non-zero valid lifetime, its size,
   starting address, and ending address MUST NOT change.

We may need some clarification on the implication of this requirement
on the following description of draft-ietf-dhc-slap-quadrant-09:

       [...]  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.
(Section 4.1-5)

since on the surface of it, this could read as if it's against the
MUST NOT.

- Section 8 same text as the previous bullet

While commenting on the previous point I've noticed one minor possible
glitch: while "its size, starting address, and ending address MUST NOT
change" prohibits any kind of change to the block, "MUST NOT shrink or
expand the address block" sounds like only limiting a particular type
of change (shrink or expand).  So ,it's not 100% cleear, for example,
if changing "start=02:04:06:08:0a, size=1 (extra-addresses=0)" to
"start=02:04:06:08:0b, size=1" is allowed or not because this
change does not "shrink or expand" the previos block.  I believe the
actual intent is the latter MUST NOT, i.e., prohibiting any kind of
change, so we might rather say:

   [...]  The server MUST NOT change the address block (including
 shrinking or expanding it) - once a block is assigned and has a
 non-zero valid lifetime, its size and starting address MUST NOT
 change.

(btw I've removed "ending address" for another editorial cleanup
because it seemed redundant - given it's a "block", the "ending
address" is determined from the starting address and its size, and the
"ending address" doesn't appear in the protocol explicitly).

- Section 10

It may be too obvious, but you might want to clarify that the option
field values are in network byte order (similar to Section 8 of
RFC8415, for example).

- Section 10.2

   option-len      12 + link-layer-len field (typically 6) + length of

"link-layer-len field value" may be better?

Nit
- Section 7: s/chose/choose/

   [...] However, the server
   MAY chose to ignore some or all parameters of the requested address
   block. [...]