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 <noreply@xxxxxxxx>
Reply-To: Christopher Wood <caw@xxxxxxxxxxxxxxx>
Date: Wednesday, 20 May 2020 at 01:51
To: "secdir@xxxxxxxx" <secdir@xxxxxxxx>
Cc: "dhcwg@xxxxxxxx" <dhcwg@xxxxxxxx>, "draft-ietf-dhc-problem-statement-of-mredhcpv6.all@xxxxxxxx" <draft-ietf-dhc-problem-statement-of-mredhcpv6.all@xxxxxxxx>, "last-call@xxxxxxxx" <last-call@xxxxxxxx>
Subject: Secdir last call review of draft-ietf-dhc-problem-statement-of-mredhcpv6-05
Resent-From: <alias-bounces@xxxxxxxx>
Resent-To: <rengang@xxxxxxxxxxxxx>, <he-l14@xxxxxxxxxxxxxxxxxxxxx>, <liuying@xxxxxxxxxxxxx>, <volz@xxxxxxxxx>, <tomasz.mrugalski@xxxxxxxxx>, Eric Vyncke <evyncke@xxxxxxxxx>, <ek.ietf@xxxxxxxxx>, Bernie Volz <volz@xxxxxxxxx>
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?
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
