Re: [Last-Call] [Int-dir] Intdir last call review of draft-ietf-dhc-mac-assign-06

["Bernie Volz (volz)" <[e-mail]>]

Hi Jinmei.

Thanks much for the review!

Comments below (BV>). Carlos may also have some.

As these are fairly minor, I will queue them up for a -08 as there may be more discussion on these comments and/or IESG reviews may raise some additional issues.

- Bernie

-----Original Message-----
From: Int-dir <[e-mail]> On Behalf Of Tatuya Jinmei via Datatracker
Sent: Wednesday, June 3, 2020 2:30 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [Int-dir] Intdir last call review of draft-ietf-dhc-mac-assign-06

Reviewer: Tatuya Jinmei
Review result: Ready with Nits

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.

BV> Technically this was just a historical perspective as to what IEEE did. We do reference the slap-quadrant elsewhere.

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

BV> We thought this would be useful as the server(s) can decide whether to honor or not and fewer packets (i.e., no Request/Reply exchange) would be beneficial. I guess we could say:

   Clients implementing this mechanism SHOULD use the Rapid Commit
   option as specified in Section 5.1 and 18.2.1 of [RFC8415] to obtain
   addresses with a 2-message exchange when possible.

BV> This expedites the client using the final address. Technically it is less critical for the hypervisor case, but it shouldn't hurt.

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

BV> This is the case that the old lease may not be desired anymore (i.e., server policy change or an administrative request for the lease to no longer be extended) and so the server needs to know the quadrant details to assign a new allocation.  See below regarding your example. This is normal DHCPv6 renumbering and letting an old lease expire while providing a new one. With link-layer addresses, when the client switches (as I doubt it would want to use both) is up to it (immediately or on expiration of the valid lifetime of the old).

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

BV> FYI "start=02:04:06:08:0b, size=1" would be a NEW block (for example, this could be a renumbering event - for some reason the old block should stop being used when the valid lifetime runs out). I think that the text is clear enough as it is - the most common action that someone might think to do is to shrink or expand the size but the text already includes the other prohibitions. No other reviewers have had issues with this text.

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

BV> Yeah, I think as these are DHCPv6 options the base standard is already clear on this.

- Section 10.2

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

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

BV> OK.

Nit
- Section 7: s/chose/choose/

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

BV> OK.


_______________________________________________
Int-dir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/int-dir