[dhcwg] Review of the draft-ietf-dhc-dhcpv6-yang-03

[Marcin Siodelski <[e-mail]>]

I reviewed version -03 of the document, but I mostly focused on the
server part as this is where I mostly have an expertise. I am not
netconf/yang expert, so some of the comments may be a result of lack of
understanding of the syntax.

The general suggestion I have for the document is that you should
improve descriptions of particular parameters in the model. For example
the description for the "operator-option-int16" says "operator integer
16 option", which doesn't explain the purpose of this parameter. The
parameter in fact specifies the value for an option carrying a single
field with a 2-byte long numeric value. But, with the proper description
I can't tell for sure that I am right. This is going to significantly
help reviewers of this document if you improve those descriptions.

You should also revise existing descriptions for copy-paste errors, like
for "operator-ipv6-addr" the description is "operator ipv6 address id",
where as it was intended be "operator ipv6 address value".

The model doesn't appear to contain all standard configurable DHCPv6
options -
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml.
For example, I don't see option 88 in the model. How did you select
options to be included in the model?


serv-attributes/name:
What exactly is the server name and how is this used? Is this something
that can be retrieved by the Netconf client to identify the server it is
communicating with? Should this be unique across DHCP servers in the
administrative domain?

In addition, I don't think this should be mandatory because not all
servers would support it. Many would probably ignore it.

serv-attributes/duid:
First of all, there is no reason to require the DUID to be mandatory.
RFC3315 specifies that the DUID-LLT is a default DUID type for the DHCP
server and the server would generate the DUID using available link-layer
address and generated time value. Overriding the DUID via configuration
should be optional, typically if the administrator wants to use
non-default DUID type, e.g. DUID-LL or DUID-EN. Technically, the value
of the DUID-LLT could be assigned via configuration but there is usually
no need for it.

That said, I also think that there should be a way to change the DUID
type, without having to specify the values for this new DUID type. In
particular, you may want to say that the server should use DUID-LL,
rather than the default DUID-LLT, but you want to leave it up to the
server to pick the suitable link-layer address to generate the DUID.
Looking at the "duidtype" typedef I don't see whether it is possible
with the current model.

serv-attributes/enable:
Are there any particular requirements for the DHCP server implementation
to react to receiving enable=true and enable=false? In particular, the
server process should startup/shutdown in that case, or it is rather
aimed at enabling/disabling DHCP function from the client standpoint,
server starts/stops responding to DHCP messages, but the process
continues to run? Or it is implementation specific?

serv-attributes/ipv6-address:
What is the purpose of this particular parameter? The server would
typically use multiple addresses configured on the interfaces on which
it is listening. Those addresses would be assigned to those interfaces
by some "other" means. Why is this limited to a single address?

serv-atrributes/pd-function:
Should this really be mandatory? Can't we just assume that if this value
isn't specified, the server would do PD for those network-ranges for
which prefix-pools exist?

Also, it strikes me that its odd that we don't have ability to
enable/disable address assignment function, if we have ability to
enable/disable pd-function and stateless-service.

serv-attributes/*/option-set/operator-option-ipv6-address:
I am not sure what the operator-options-* are going to be used for. The
model includes a bunch of standard options already, e.g.
"dns-config-option", for which the model includes the data types carried
within the options. In case of the "dns-config-option" it is
inet:ipv6-address. I also understand that "new-or-standard-option"
allows for defining and assigning a value to any existing or not
existing option (presumably in the binary or hexadecimal format). The
"new-or-standard-option" contains the option code so as the server may
create an instance of the option and send it out to the client. For the
options like "operator-option-ipv6-address", I thought they would serve
similar role like "new-or-standard-option" but would allow for
specifying values of the options in much more friendly format. If this
is correct, I'd think that "operator" options should contain the same
set of parameters as "new-or-standard-option", including code, name,
description and reference?

serv-attributes/network-ranges/*/address-pool/reserved-addresses:
I suggest that "reserved-addresses" are rather specified at the
network-range level, not address-pool level. In many cases you don't
want to include static assignments within the pool from which addresses
are also allocated dynamically (to clients that don't have
reservations). The reason is that it affects performance of the dynamic
allocations because the server has to find the available address among
those assigned statically and dynamically. If you make your reservations
outside of the pool the server would only have to avoid collisions with
other dynamically assigned addresses.

There are also other important considerations about "reserved-addresses"
and "reserved-prefixes". One of them is that, even though the DUID", is
a most obvious identifier for a client, in many cases it is useless for
assigning static reservations because the server administrator doesn't
know the DUID until the client contacts the server for the first time.
There are other options which can be considered to make a reservation,
e.g. MAC address, Remote-id, Subscriber-id. The model should allow for
using those (perhaps also some other identifiers) to make static
reservations.

Perhaps you should simply use "hosts" structure to make address/prefix
reservations?

serv-attributes/network-ranges/*/address-pool/reserved-prefixes:
Does this structure allow for reserving multiple prefixes for the same
client (requesting router)?

What is "other-reserv-prefix" for?

serv-attributes/network-ranges/*/hosts:
Same issue with the DUID based reservations as for the
"reserved-addresses" and "reserved-prefixes". It should allow for other
identifiers too.


client/client-if/duid:
The description says (correctly) that the client has only one DUID
(regardless of the interface). However, the "duid" value in the model is
still specified at the interface level. So with the current model it is
possible to specify different duid values for different interfaces. The
"duid" specification should thus be used one level up.

client/client-id/cli-id:
What is "cli-id", a client idenitfier? Why not simply use DUID?

Marcin