Subject: [dhcwg] Comments on draft-ren-dhc-problem-statement-of-mredhcpv6-00

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 22 May 2018 15:19:21 +0000

I reviewed this individual submission draft and have some comments (as a WG member, hat off as DHC WG co-chair).

This draft is basically is a summary of what processing in DHCPv6 [servers] might want to be customizable (and how that might be done using CPNR and KEA extensions).

The title (and name of draft) are a bit odd given that it is much more generic overview and doesn't really address any specific "problem statement"?

I do have a bunch of nits (mostly because non-native English speaker issues), but I think we can forgo those for now.

The issues I found are:

  1.  There are multiple references to secure-dhcpv6 and this document is dead. I think this need to be removed as there are no plans by the WG to continue work on that document.
  2.  There is RFC2119 reference in the terminology section but I don't believe it is needed/used.
  3.  In several places "user" [requirements] is mentioned, but I think this likely should be "administrator"?
  4.  In section 3.1 for "Extended Options", the number of RFCs referenced should be reduced as everyone will get the point. Perhaps a reference to the options on the IANA page (https://www.iana.org/assignments/dhcpv6-parameters) should be used if you want to provide an indication of the number of options?
  5.  Section 4.2.2, while technically correct (all DHCPv6 options are standardized), there is a need to mention that the reason for this is that we have Vendor Option (17) that are supposed to be used for "private" purposes. This is a major hole in the work.
  6.  It would be better to reference 3315bis instead of 3315 (especially in section 5, Security Considerations). And again, in Section 5 is mention of secure dhcpv6 (sedhcpv6) which needs to be removed.
  7.  The intended status (Standards Track) is wrong; I think this is Informational.
  8.  Abstract states "and provides the possible directions to solve the problems" but I don't really see anything in the document that covers this (perhaps section 4.2.5 was to provide this)?

It isn't completely clear whether this draft is "needed". Certainly if it is Informational it doesn't hurt (and perhaps other DHCP server vendors will want to provide information to expand on what "extensions" different servers provided). But, again, I'm not sure that this information is important to highlight and might be left to the server vendor documentation?

-          Bernie