Re: [dhcwg] I-D Action: draft-ietf-dhc-mac-assign-07.txt

On Tue, Jun 2, 2020 at 2:17 PM Bernie Volz (volz) <volz@cisco.com> wrote:
>
> Hi:
>
> This revision hopefully addresses most of the comments raised by area reviews as well as by the IESG balloting (so far) - see https://datatracker.ietf.org/doc/draft-ietf-dhc-mac-assign/ for the reviews and IESG evaluation record.

Thank you, it does for me, and I have cleared my DISCUSS.

W

>
> I also followed some of the recommended changes to the slap-quadrant draft (such as related to IoT description (RFC7228) and adding RFC7227 to security considerations).
>
> And, also fixed an issue with Figure 2 which did not have the 32-bit header lines.
>
> The changes are mostly minor.
>
> For those with comments that I did not fully or correctly address, please let me know and I will see what I can do to adjust.
>
> Thanks in advance.
>
> - Bernie
>
> -----Original Message-----
> From: dhcwg <dhcwg-bounces@ietf.org> On Behalf Of internet-drafts@ietf.org
> Sent: Tuesday, June 2, 2020 2:08 PM
> To: i-d-announce@ietf.org
> Cc: dhcwg@ietf.org
> Subject: [dhcwg] I-D Action: draft-ietf-dhc-mac-assign-07.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Dynamic Host Configuration WG of the IETF.
>
>         Title           : Link-Layer Addresses Assignment Mechanism for DHCPv6
>         Authors         : Bernie Volz
>                           Tomek Mrugalski
>                           Carlos J. Bernardos
>         Filename        : draft-ietf-dhc-mac-assign-07.txt
>         Pages           : 20
>         Date            : 2020-06-02
>
> Abstract:
>    In certain environments, e.g. large scale virtualization deployments,
>    new devices are created in an automated manner.  Such devices
>    typically have their link-layer (MAC) addresses randomized.  With
>    sufficient scale, the likelihood of collision is not acceptable.
>    Therefore an allocation mechanism is required.  This draft proposes
>    an extension to DHCPv6 that allows a scalable approach to link-layer
>    address assignments.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-mac-assign/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dhc-mac-assign-07
> https://datatracker.ietf.org/doc/html/draft-ietf-dhc-mac-assign-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-mac-assign-07
>
>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf