[dhcwg] WGLC comments on draft-ietf-dhc-mac-assign-01

[Tomek Mrugalski <[e-mail]>]

Disclaimer: I used to be involved in the draft-ietf-dhc-mac-assign a
year ago. I asked the other authors to remove my name from it, but they
feel my contributions were significant enough to keep it on.

So it's with my co-chair and co-author hats off, I support this work
moving forward. However, I have some comments that should be addressed.

Nitpicks:
Section 6, bullet numbering is wrong (no item 2)
Section 6, bullet 3: block of address => block of addresses

Section 6 properly explains that the client is supposed to set the valid
lifetime field to 0. I'd like to see a text for the other side: the
server MUST ignore the valid lifetime value.

Nitpick: "a IA_LL" => "an IA_LL". RFC8415 uses an for all IA options.

"The server MAY alter the allocation at this time." This is technically
incorrect. Server doesn't have any allocation yet, it's about to make
one. Better text would be: "The server allocates block of addresses
according to its configured policy. The server MAY assign a different
block than requested in the Request message."

Text in section 10.2: "This value can be only sent by a client that
requests a new block.". There are two issues with this text. First, I
would rephrase this text. The sentence as written now suggests that the
only entity allowed to set this field is a client and only under certain
circumstances. Maybe something like this: "A client is only allowed to
set this value when requesting a new block?". The second problem with
this text is that it's not really true, is it? What about renewals?
Client is expected to send the block it already has for renewal.

"extra-addresses - A four octets long field". Would be useful to clarify
that it's an unsigned field encoded in network byte order.

End of section 10.2: "More than one LLADDR option can appear in an IA_LL
option." This seems to be in contradiction with earlier text that says
"Therefore, if a client wants more addresses at a later stage, it SHOULD
send an IA_LL option with a different IAID to create another "container"
for more addresses.". So what are the circumstances when more than one
LLADDR is present in IA_LL? If there are none, perhaps best would be to
remove this sentence?

Section 13 should probably mentioned that there is no duplicate
detection mechanism such as DAD for IPv6. It's not really a problem,
though. A malicious node can start using any MAC address and doesn't
have to go through the hassles of implementing this protocol.

I hope to review the second draft in the coming days. Will send a
separate mail.

Thanks,
Tomek