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

My pleasure! I'm happy to take another look at future revisions if needed.

Best,
Chris

On Sun, May 24, 2020, at 4:15 PM, Benjamin Kaduk wrote:
> 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
>