Subject: [Last-Call] secdir last call review of draft-ietf-dhc-slap-quadrant-07

From: Carl Wallace <[email-masked]>
Date: Tue, 26 May 2020 16:22:23 -0400

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document proposes extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server, so that the server allocates the MAC address to the given client out of the quadrant requested by relay or client.

The document is generally clear but I do have a few comments listed below. That the security considerations were incorporated by reference seems fine.

- The document should expand acronyms on first use, for example U/L in first sentence of section 1, instead of leaving these to referenced documents. 

- Figures 3 and 4 reference a timer expiring but the prose does not. Including verbiage similar to second paragraph in section 4.3 of draft-ietf-dhc-mac-assign-05 may be worth doing. 

- Section 3 may benefit from providing rationale for the preferences given, i.e., why might ELI/SAI be good, etc. Framing the criteria in terms of the quadrants instead of type of device may be helpful in addition as well, if a best practices type guidance is reasonable. 

- Also in Section 3, I am not familiar with the IEEE specs that govern the addresses associated with the SAI quadrant, but Section 3 created an impression that a client has a freehand to choose between SAI and other options that wouldn't seem appropriate for a quadrant governed by other standards.

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Wed, 27 May 2020 20:19:48 +0200

Hi Carl,

Thanks a lot for your review and comments. Please see inline below.

On Tue, May 26, 2020 at 10:22 PM Carl Wallace <[email-masked]>
wrote:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security area
> directors. Document editors and WG chairs should treat these comments just
> like any other last call comments.
>
> This document proposes extensions to DHCPv6 protocols to enable a DHCPv6
> client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the
> server, so that the server allocates the MAC address to the given client
> out of the quadrant requested by relay or client.
>
> The document is generally clear but I do have a few comments listed below.
> That the security considerations were incorporated by reference seems fine.
>
> - The document should expand acronyms on first use, for example U/L in
> first sentence of section 1, instead of leaving these to referenced
> documents.
>

[Carlos] Thanks. We've reviewed it and tried to expand them all the first
time they appear in version -09. Some of them are a bit tricky, as they are
too much "well known and widely used" by the IEEE community.

> - Figures 3 and 4 reference a timer expiring but the prose does not.
> Including verbiage similar to second paragraph in section 4.3 of
> draft-ietf-dhc-mac-assign-05 may be worth doing.
>

[Carlos] Thanks. Done in future version -09.

> - Section 3 may benefit from providing rationale for the preferences
> given, i.e., why might ELI/SAI be good, etc. Framing the criteria in terms
> of the quadrants instead of type of device may be helpful in addition as
> well, if a best practices type guidance is reasonable.
>

[Carlos] Since the section is meant to be just some examples, we prefer to
keep it as is, but I see and acknowledge your points. It's just that the
goal is not to provide normative guidance, but just some examples for the
need of the SLAP quadrant selection mechanisms.

>
> - Also in Section 3, I am not familiar with the IEEE specs that govern the
> addresses associated with the SAI quadrant, but Section 3 created an
> impression that a client has a freehand to choose between SAI and other
> options that wouldn't seem appropriate for a quadrant governed by other
> standards.
>
> [Carlos] Multiple protocols can be used, and the idea is that the DHCP
extensions specified in this document is one of the possible protocols. As
far as I know, discussion is ongoing in IEEE and this draft is part of the
discussion as one existing mechanism.

Thanks!

Carlos