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

Thanks for the review, Chris!  I skimmed the doc and agree that the main
point is not readily apparent; hopefully it will get some edits before it
comes to the IESG.

-Ben

On Tue, May 19, 2020 at 04:51:07PM -0700, Christopher Wood via Datatracker wrote:
> 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?
> 
> 
> -- 
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call