[dhcwg] My read of draft-ietf-dhc-dhcpv6-yang-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:
"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.


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.

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?


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?

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?

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.

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

"pd-function" - As a matter of curiosity. You define this knob to
enable/disable prefix delegation. But, can you actually enable/disable
address assignment?

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


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?

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

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


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?

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


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

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.


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.

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.

Marcin