Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17

[[e-mail]]

Hi,

I’ll be shepherding both of these documents. Please see the following comments
on draft-ietf-dhc-mac-assign-01. I’ll provide comments on draft-ietf-dhc-slap-quadrant-01
in a separate mail.

Thanks,
Ian

General point - The document doesn't place any requirements on how a client
creates its DUID. Could this result in having multiple clients with the same DUID?
Clients with clashes in the default/initial MAC address using e.g. DUID-Type 3
(which would have to be based on the initial MAC and
remain constant for the duration of the lease), isn't there the potential
for DUID conflict?

---------

1. Introduction
"Another use case is IoT devices.  Typically there is no need to  provide global
uniqueness of MAC addresses for such devices.  On the  other hand, the huge
number of such devices would likely exhaust a  vendor's OUI (Organizationally
Unique Identifier) global address space."

It's not clear to me how this supports the need for the DHCP based allocation
of MAC addresses as the first point seems to override the relevance of the
second. Based on what I think it’s trying to say, here’s an updated text proposal:

"Another use case is IoT devices.  The huge number of such devices would
likely exhaust a vendor's OUI (Organizationally Unique Identifier) global address
space, and while there is typically no need to provide global uniqueness for
such devices, a link-layer assingment mechanisms allows for conflicts
to be avoided inside an administrative domain."

-----------

7. Requesting Addresses
"The client MUST be able to handle a response that contains an address
 or addresses different than those requested."

Suggest that the following is used to include another of the described deviation cases:

"The client MUST be able to handle a response containing a smaller number of addresses,
or an address or addresses different than those requested."

The above suggestion is also relevant for the paragraph related to the Relpy message
later in the section.

-----------

10.2 Link-Layer Addresses Option
link-layer-type  - it would be useful if this provided a reference to the relevant
IANA table at 
https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml#arp-parameters-2

========================


> On 30. Oct 2019, at 02:51, Tomek Mrugalski <[e-mail]> wrote:
> 
> Hi,
> This mail initiates a Working Group Last Call on two related IDs:
> 
> Link-Layer Addresses Assignment Mechanism for DHCPv6
> draft-ietf-dhc-mac-assign-01
> https://tools.ietf.org/html/draft-ietf-dhc-mac-assign-01
> 
> and
> 
> SLAP quadrant selection options for DHCPv6
> draft-ietf-dhc-slap-quadrant-01
> https://tools.ietf.org/html/draft-ietf-dhc-slap-quadrant-01
> 
> Authors believe those drafts are ready for WGLC. Please post your
> substantial comments and your opinion whether those are ready for
> publication or not. If you have minor editorial comments, you may send
> them to the authors directly.
> 
> Please post your comments by Nov. 17th.
> 
> Cheers,
> Tomek
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg