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

Hi, Bernie!

Thanks for your valuable comments. Sorry for my late reply. See my comments
inline.

Bernie Volz (volz) <volz@cisco.com> 于2018年5月22日周二 下午11:19写道：

> 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”?
>

> LH
> > We will add some new contents to address “problem statement” of
> multi-requirement extensions for DHCPv6.
>

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

LH
> We will improve the writing in the next version.

> 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.
>
>

           LH
> Good, we will remove this reference in the next version of this draft.

           2.
There is RFC2119 reference in the terminology section but I don’t believe
it is needed/used.

           LH> Agree. We made a mistake here, and we will remove this
reference in the next version of this draft.

           3.
In several places “user” [requirements] is mentioned, but I think this
likely should be “administrator”?

GR> We consider “administrator” as one type of “user”.
Obviously, “administrator” is more accurate in this draft. Good.
           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?

LH
>
OK
, we will remove those references in the next version of this draft.

          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.

            LH> Vendor Option (17) can be used to transmit self-defined
parameters. But "self-defined options" in our context are more than just
defining some options to support "private" purposes. We hope that
self-defined options can be directly used in different clients. We will
update this part in the new version.

           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.

           LH
> We will reference 3315bis in the next version of this draft.

           7.
The intended status (Standards Track) is wrong; I think this is
Informational.

LH
> Agree. We will change the intended status into Informational in the next
version of this draft.

           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)?

>
>
           LH
> We will add more contents to provide the possible directions to solve the
problems.

> 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
>
>
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>

-- 

    Yours Sincerely,

*   Lin He*