Last Call Review of draft-ietf-dhc-mac-assign-06
review-ietf-dhc-mac-assign-06-iotdir-lc-chakrabarti-2020-05-11-00

 I took a quick glance at the draft from IoT point of view (only partial review
 ).

Section 4.2 talks about the IoT usecase as Direct Client Mode -- where they
talk about cheap devices which may not have unique UUID associated with it.

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 more details, refer to Section 11 of [RFC8415].

1. However,  it is not clear what  source initial link-layer address should be
used by these devices. should it point to section 6? will that suffice?

2. Moreover,  how safe the mechanism would be if the Security section says that
mechanism defined in this draft may be used by a bad actor ?

3. It appears to me the mechanisms are designed for VMs behind an hypervisor
and then IoT usages are added. My concerns are two fold for challenged low
capability IoT devices -- 1) will they be able to handle the complicated option
processing described here? 2) How to mitigate the security vulnerability for
IoT devices as direct clients?  (The security section does not talk about
mitigation)

Should there be a simpler option processing structure without TLV option
processing ( i,e a fixed structure part + then TLV part for optional
information]?