Re: [secdir] Secdir last call review of draft-ietf-dhc-problem-statement-of-mredhcpv6-05

["Eric Vyncke (evyncke)" <[e-mail]>]

Thank you Chris for your review.

I will take your and Pete's reviews when considering the next steps.

Regards

-éric

-----Original Message-----
From: Christopher Wood via Datatracker <[e-mail]>
Reply-To: Christopher Wood <[e-mail]>
Date: Wednesday, 20 May 2020 at 01:51
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Secdir last call review of draft-ietf-dhc-problem-statement-of-mredhcpv6-05
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, Eric Vyncke <[e-mail]>, <[e-mail]>, Bernie Volz <[e-mail]>
Resent-Date: Wednesday, 20 May 2020 at 01:51

    Reviewer: Christopher Wood
    Review result: Serious Issues

    Summary: Series Issues

    Comments:

    - Section 1. The introduction needs a lot of work. It seems to be trying to say
    something, but I cannot tell what that is. It's claimed that many documents
    attempt to extend DHCPv6, yet no extensions are cited. There's mention of
    "multi-requirement extension problems," but no example of such a problem.
    There's reference to the possibility of administrators modifying DHCPv6 code
    (and possibly breaking things in the process), but that does not seem relevant
    to or follow from the previous text. Please revise this entire section and make
    the goal clear. What is the problem being solved, why is it important, and what
    is the summary of the proposed solution?

    - Section 3.2. This section seems largely irrelevant. What is its purpose? It
    mainly documents software support, rather than "extension practices."

    - Section 4.1. Figure 1 could benefit from some descriptive text to match the
    diagram. For example, it's clear how "options" are points of extensibility, but
    how are "message processing functions" points of extensibility? An example
    might help clarify.

    - Section 4.2.3. What does "not all DHCPv6 software considers this extension"
    mean? Does it imply that not all server implements support for this extension,
    or something else?

    - Section 5. This seems to be the crux of the document, yet I failed to glean
    much from its contents. There are some examples of extensions which may require
    multiple more than one "moving part," such as (1) client identity transmission
    and (2) server use of those identities for address allocation. Is there
    guidance that should be followed for specifying this type of multi-requirement
    extension? If so, what is it? (Is that not the whole point of this document?)
    Are there considerations administrators or specification writers should be
    mindful of when designing these extensions? If so, what are they?

    In general, it seems that if a document is to emphasize considerations for
    folks, then those considerations out to be clearly articulated. Instead, this
    document seems to just list some examples (current practices) without any
    further insight. This makes me question its overall value for the community.

    Nits:

    - Section 1. "The IP address plays a significant role in the communication of
    the Internet." Did this mean to say communication *on* the Internet?

    - Please remove unnecessary gender terms from the document ("his").

    - This text:

       For example, considering such a requirement that
       DHCPv6 servers assign IPv6 addresses generated by user identifiers to
       the clients in a network to hold users accountable, two extensions
       should be fulfilled to meet this requirement.

    Could probably be simplified. Also, what does it mean for an extension to be
    fulfilled?