Re: [dhcwg] My read of draft-ietf-dhc-dhcpv6-yang-00

[Linhui Sun <[e-mail]>]

Hi Marcin,

Sorry for the delay and really thanks for your detailed review, please see
comments inline.

Regards,
Linhui

2015-11-05 0:15 GMT+09:00 Marcin Siodelski <[e-mail]>:

> In Prague I mentioned I'd review the YANG models for DHCP. There is
> never good time to review a document that ends up being 84 pages long. I
> finally had a look into this today and reviewed some bits of YANG models
> for DJCPv6. Note that it is not all. I just try to highlight the most
> obvious things that occurred to me while reading this (mostly client and
> server sections).
>
>
> Abstract
> "There has no unified method to configure DHCPv6 server ,relay and
>    client itself, always pre-configured manually by operators."
>
> This sentence sounds a bit odd. There are some typos. There is
> extraneous "itself". Also, I am not sure what this is trying to say:
>
[LH]: Agree the "itself" is redundant, will remove it.

> "always pre-configured manually by operators", in the context of this
> draft. I think this draft doesn't eliminate manual configuration, it
> merely introduces unified data structures. The configuration would still
> have to be "manual", regardless if remote or local. Or maybe I am
> reading something that it doesn't try to say.

[LH]: I agree the manual configuration is still inevitable with the help of
YANG model. I think the statement here is so absolute that may mislead
people. How about changing to "There has no unified method to configure
DHCPv6 server, relay and client itself, typically pre-configured by
operators through traditional configuration manners (e.g. command line
interfaces)."

>
>
> Introduction
> For completeness, it may also be worth to mention that not only does
> this model provide means to configure the server, client and relay, but
> it also provides means to gather statistics and notifications from the
> server. Perhaps, this could be also mentioned in abstract.
>
> I am not clear what the difference between "configuration" and
> "management" is.
>
[LH]: IMO, configuration is for those "rw" nodes while the management is
for the "ro" nodes. Do you think we need a very clear distinction between
those two terminologies? Or do you think the concept of "management" should
contain the "configuration"?

>
> I am not very enthusiastic about the paragraph starting:
> "For DHCPv6 client configuration..."
>
> I'd suggest something more like this, because it is shorter and less
> convoluted:
>
> "The DHCPv6 client module provides means to control the DHCPv6 client
> software running on host. For example, it allows for specifying whether
> or not the client should request specific DHCP options when it contacts
> the DHCP server. This model is not intended to be used to replace or
> override host configuration, which a DHCP client (being controlled using
> this model) receives from the DHCP server."


>
> I don't understand the need for sections 2.1-2.3, as they don't convey
> any information. Are they going to be extended with any specific text?
>
[LH]: This sections are supposed to be filled with several general and
brief description of the model structure (i.e. the server, relay and client
respectively). I think we will complement this in the next version.

>
>
> 3.1 DHCPv6 server tree diagrams
>
> Is the ultimate goal to describe *all* elements of the tree under the
> tree? Or, you assume that some of those elements don't require
> description  in section 3.1 because they are described in section 4?
>
[LH]: The YANG validator requires us that each data node should have a
description, that is what you could see in section 4. For the Section 3, I
would prefer to provide descriptions of some important nodes.

>
> Proposed models do not make use of the *default* values. There are many
> mandatory parameters without default values, which probably implies that
> I'd need to always configure them. Is this really the intent?
>
[LH]: We are not intended to imply that people have to configure them every
time. RFC6020 does define how to make a default value for the leaf (use the
"default" statement). We will add this statements in the next version.

>
> For example "container sol-max-rt-option" includes a leaf "enable" which
> indicates whether this option will be included in the option set - I
> read it as it will be sent to the client. Wouldn't it be more convenient
> to assume that it is sent if specified, i.e. default for "enable" would
> be true. If I don't want to send it, I'd set it to false explicitly.
>
[LH]: Agree.

>
> "ipv6-address" - What address is this? A server could actually contain
> multiple interfaces and multiple addresses on each of them. Is this an
> address recommended to use to connect to the server with a NETCONF?
>
[LH]: It has nothing to do with the NETCONF. I'm just wondering wether to
remove it or make it compatible with the "interfaces-config" list. What's
your suggestion?

>
> "pd-function" - As a matter of curiosity. You define this knob to
> enable/disable prefix delegation. But, can you actually enable/disable
> address assignment?
>
[LH]: I'm afraid I cannot understand what you mean here. Do you mean we
should not enable/disable the prefix delegation?

>
> "stateless-service"
> The definition of this says:
> "A boolean value specifies whether the server
>       support client-server exchanges involving two messages defined in
>       ([RFC3315])."
>
> which is ambiguous. It should rather explicitly mention
> Information-request. Note that there are other possibilities for
> exchanges involving two messages, e.g. Solicit-Reply (with Rapid Commit).
>
[LH]: Agree, will improve the description in the next version.

>
>
> I am also wondering if it should be possible to define "pd-function" and
> "rapid-commit" per network range, e.g. allow prefix delegation for
> client's connected to this network but not to that network?
>
[LH]: I think it is a good feature and that is what you provide in Kea.
After a brief talk with Tomek before, I think we will make the nodes both
available in global and network ranges in the next version.

>
> "interfaces-config"
> Doesn't a free-text type of configuration for listing active interfaces,
> together with optional unicast addresses violate the structure of the
> YANG model that is hierarchical? Moreover, the current description
> doesn't really explain how to enable multiple selected interfaces, or
> all interfaces. Should they be listed as comma separated names? Or, is
> it left up to the implementation of the server?


> I also think that enabling all interfaces by default may cause
> significant issues. If I forget to specify the interface configuration
> and I enable the server, it would start replying to all messages it
> detects on any of its interfaces. This could disrupt the operation of
> the network to which the server is connected.

[LH]: I think this part definitely need to be refined, I will respond this
later.

>


> "vendor-info"
> Is this intended to include the name of the server software and its
> version? For example: isc-dhcp-4.3?
>
[LH]: Yes

>
>
> 3.3. DHCPv6 Client Tree Diagrams
>
> "cli-id"
> I don't know what this is, and there is no description. Client
> identifier? How does it relate to DUID?
>
[LH]: The only reason that "cli-id" was introduced is DUID is a large value
(i.e. not appropriate to be a key value), we use the "cli-id" as the key
value for some lists. But I think we need to omit the "cli-id" to use the
unified DUID.

>
> "duid"
> Per RFC3315 terminology DUID is:
> "A DHCP Unique IDentifier for a DHCP
> participant; each DHCP client and server
> has exactly one DUID.  See section 9 for
> details of the ways in which a DUID may
> be constructed."
>
> In other words defining DUID per interface would violate the rule of one
> DUID per client, no?
>
[LH]: I think that is why the client should be in a per-interface manner,
am I right?

>
>
> "mo-tab"
> Is there any particular reason for this awkward configuration using the
> MO flags, rather than:
>
> - "request-pd" boolean
> - "request-na" boolean
> - "stateless" boolean
>
> where "stateless" being true means send Information-request, and if it
> is false, the other two indicate what stateful options to request.
>
[LH]: We have discussed these before the dhc session, the "mo-tab" seems to
be difficult to understand and redundant. But I don't understand what the
"request-pd" & "request-na" mean here, I think the "stateless" is enough.

>
> On that matter, there is also an interesting question how to configure
> the client to request more than one IA_NA if it needs to do so.
>
> I recognize that there is the "ro identity-associations" but it is read
> only and probably to only gather the configuration that the client has
> obtained, not to configure the client to request a specific address(es).
> And how about hints? For example a hint for prefix length.
>
[LH]: I think this should be included in the "client-configured-options"
container, how about adding the IA_PD option in that  container?

>
>
> I also couldn't find in the models the way to configure dedicated
> options for specific hosts. Container "reserved-addresses" merely
> includes mappings between the DUIDs and addresses, but it is frequently
> desired to also provide specific options for clients having reservations.
>
[LH]: Are you talking about the server side configuration? If so, we could
specified a specific option set for specific hosts (i.e. under the "hosts"
container).

>
> Also, per RFC6939 the link-layer address of the client may be provided
> by the relay, in which case it should be possible to do static
> reservation based on the MAC address, rather than DUID.
>
[LH]: This needs to be added to the relay portion, thanks.

>
> Marcin
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>