[yang-doctors] Yangdoctors early review of draft-ietf-dhc-dhcpv6-yang-19

[Acee Lindem via Datatracker <[e-mail]>]

Reviewer: Acee Lindem
Review result: On the Right Track

Document: draft-ietf-dhc-dhcpv6-yang-19
Reviewer: Acee Lindem
Review Date: May 5, 2021
Review Type: Early Review
Intended Status: Standards Track
Summary: On the right track - Issues and questions need to be resolved.

Modules: [e-mail]
         [e-mail]
         [e-mail]
         [e-mail]

Tech Summary: The document contains the base configuration and operational
              YANG model for the DHCPv6 protocol. The basic structure is
              very good but the major issues need to be addressed prior to WG
              last call.

Major Comments:

    1. Should the DHCP server, relay, and client functions be enabled by
       default? It seems they are require specific configuration to be
       viable.

    2. The threshold type in the ietf-dhcpv6-common is strange. It is a
       union with an enumeration to disable the threshold. Normally, if
       there is no threshold, you would simply not specify it. However,
       the data nodes of this type are mandatory. I'd make it a simple
       type and remove the mandatory designations for the data nodes. Also,
       the range should not start at 0% since this % makes no sense.

    3. There are examples of augmenting the ietf-dhcpv6-server module but
       no "Module Usage Examples" as specified in section 3.12 of RFC 8407.

Minor Comments:

    1. While not required by RFC 8407, many YANG RFCs explcitly call out
       the interaction with imported YANG modules in a separate section.

    2. No sense in maintaining all the intermediate revisions in the
       modules. Just update the one that is the initial version and update
       the date.

    3. The module prefixes are very descriptive but a bit long. Given
       the examples of augmentations, this will be especially true for
       DHCPv6 server augmentations. Perhaps, dhc6-serv, dhc6-rly, and
       dhc6-clnt would be better.

    4. Can host-reservation prefixes overlap with holes? If so,
       reserved-prefix may not be unique. If not, no problem.

    5. For nodes with patterns, describe what the pattern allows in
       the description with an example or two. This applies to
       link-address, duid-base, duid-llt, duid-en, duid-ll,
       duid-unstructured, and sub-option-data.

    6. With respect to link-address, what type of address is this? If it is
       an IPv6 link-local address, there is an ipv6-adddress type in RFC 6021.

Nits:

    1. IETF documents should use US English - not UK English. I've
       changed in suggested edits.

    2. Description format - Sometimes starting right have "description"
       and sometimes starting on the next line.

    3. sol-max-rt-option-group and inf-max-rt-option-group should spell out
       the words in the description rather than just repeating the short
       abreviations.

    4. In ietf-dhcpv6-client,  for ia_ta and ia_pd, spell our
       acronyms in the descriptions rather than just repeating them (which
       is useless).Is "ia" "interface address"? Don't make the reader
       go to the DHCPv6 RFC to know what you mean. What is "ia_ta"?

    5. See diffs below:

ACEE-M-3B86:Desktop acee$ diff -c draft-ietf-dhc-dhcpv6-yang-19.txt.orig
draft-ietf-dhc-dhcpv6-yang-19.txt *** draft-ietf-dhc-dhcpv6-yang-19.txt.orig   
  2021-05-04 13:13:40.000000000 -0400 --- draft-ietf-dhc-dhcpv6-yang-19.txt  
2021-05-05 16:46:30.000000000 -0400
***************
*** 100,106 ****
     DHCPv6 [RFC8415] is widely used for supplying configuration and other
     relevant parameters to clients in IPv6 networks.  This document
     defines YANG [RFC7950] modules for the configuration and management
!    of DHCPv6 'element' (servers, relays and clients) using the Network
     Configuration Protocol (NETCONF [RFC6241]) or RESTCONF [RFC8040]
     protocols.

--- 100,106 ----
     DHCPv6 [RFC8415] is widely used for supplying configuration and other
     relevant parameters to clients in IPv6 networks.  This document
     defines YANG [RFC7950] modules for the configuration and management
!    of DHCPv6 'element' (servers, relays, and clients) using the Network
     Configuration Protocol (NETCONF [RFC6241]) or RESTCONF [RFC8040]
     protocols.

***************
*** 123,129 ****
     replacement for the allocation of DHCPv6 assigned addressing and
     parameters by using NETCONF/YANG.  The DHCPv6 client module is
     intended for the configuration and monitoring of the DHCPv6 client
!    function and does not play a part in the normal DHCPv6 message flow.

     The YANG modules in this document adopt the Network Management
     Datastore Architecture (NMDA) [RFC8342].
--- 123,130 ----
     replacement for the allocation of DHCPv6 assigned addressing and
     parameters by using NETCONF/YANG.  The DHCPv6 client module is
     intended for the configuration and monitoring of the DHCPv6 client
!    function and does not replace DHCPv6 address and parameter
!    configuration.

     The YANG modules in this document adopt the Network Management
     Datastore Architecture (NMDA) [RFC8342].
***************
*** 136,157 ****
     options.  The YANG modules contained in this document do not attempt
     to capture all of these extensions and additions, rather to model the
     DHCPv6 functions and options covered in [RFC8415].  A focus has also
!    been given on the extensibility of the modules so that it is easy to
!    augment in additional functionality as required by a particular
     implementation or deployment scenario.

  1.2.  Extensibility of the DHCPv6 Server YANG Module

!    The modules in this document only attempt to model DHCPv6 specific
     behavior and do not cover the configuration and management of
     functionality relevant for specific server implementations.  The
     level of variance between implementations is too great to attempt to
!    standardize in a way that is useful without being restrictive.

!    However, it is recognized that implementation specific configuration
     and management is also an essential part of DHCP deployment and
     operations.  To resolve this, Appendix B contains an example YANG
!    module for the configuration of implementation specific functions,
     illustrating how this functionality can be augmented into the main
     'ietf-dhcpv6-server.yang' module.

--- 137,158 ----
     options.  The YANG modules contained in this document do not attempt
     to capture all of these extensions and additions, rather to model the
     DHCPv6 functions and options covered in [RFC8415].  A focus has also
!    been given on the extensibility of the modules so that they are easy to
!    augment to add additional functionality as required by a particular
     implementation or deployment scenario.

  1.2.  Extensibility of the DHCPv6 Server YANG Module

!    The modules in this document only attempt to model DHCPv6-specific
     behavior and do not cover the configuration and management of
     functionality relevant for specific server implementations.  The
     level of variance between implementations is too great to attempt to
!    standardize them in a way that is useful without being restrictive.

!    However, it is recognized that implementation-specific configuration
     and management is also an essential part of DHCP deployment and
     operations.  To resolve this, Appendix B contains an example YANG
!    module for the configuration of implementation-specific functions,
     illustrating how this functionality can be augmented into the main
     'ietf-dhcpv6-server.yang' module.

***************
*** 161,167 ****
     provisioning information can be supplied.  For example, allocating a
     prefix from the correct pool, or supplying a set of options relevant
     for a specific vendor's client implementation.  During the
!    development of this document, research has been carried out into a

--- 162,168 ----
     provisioning information can be supplied.  For example, allocating a
     prefix from the correct pool, or supplying a set of options relevant
     for a specific vendor's client implementation.  During the
!    development of this document, a number of vendor's class selection

***************
*** 170,181 ****
  Internet-Draft              DHCPv6 YANG Model                 March 2021

!    number of vendor's class selection implementations and the findings
     were that while this function is common to all, the method for
     configuring and implementing this function differs greatly.
     Therefore, configuration of the class selection function has been
     omitted from the DHCPv6 server module to allow implementors to define
!    their own suitable YANG module.  Appendix C provides an example of
     this, to demonstrate how this is can be integrated with the main
     'ietf-dhcpv6-server.yang' module.

--- 171,182 ----
  Internet-Draft              DHCPv6 YANG Model                 March 2021

!    implementations were researched and the findings
     were that while this function is common to all, the method for
     configuring and implementing this function differs greatly.
     Therefore, configuration of the class selection function has been
     omitted from the DHCPv6 server module to allow implementors to define
!    their own suitable YANG modules.  Appendix C provides an example of
     this, to demonstrate how this is can be integrated with the main
     'ietf-dhcpv6-server.yang' module.

***************
*** 188,202 ****
     [RFC8415] are included in this document.

     Of these, only the options that require operator configuration are
!    modelled.  E.g.  OPTION_IA_NA (3) is created by the DHCP server when
     requested by the client.  The contents of the fields in the option
     are based on a number of input configuration parameters which the
     server will apply when it receives the request (e.g., the T1/T2
     timers that are relevant for the pool of addresses).  As a result,
!    there are no fields that are directly configurable in the option, so
!    it is not modelled.

!    The following table shows the DHCPv6 options that are modelled, the
     element(s) they are sent by, and the relevant YANG module name:

     +---------------------+------+-----+------+-------------------------+
--- 189,203 ----
     [RFC8415] are included in this document.

     Of these, only the options that require operator configuration are
!    modeled.  For example, OPTION_IA_NA (3) is created by the DHCP server when
     requested by the client.  The contents of the fields in the option
     are based on a number of input configuration parameters which the
     server will apply when it receives the request (e.g., the T1/T2
     timers that are relevant for the pool of addresses).  As a result,
!    there are no fields that are directly configurable for the option, so
!    it is not modeled.

!    The following table shows the DHCPv6 options that are modeled, the
     element(s) they are sent by, and the relevant YANG module name:

     +---------------------+------+-----+------+-------------------------+
***************
*** 268,274 ****
     | Option              |      |     |      |                         |
     +---------------------+------+-----+------+-------------------------+

!                       Table 1: Modelled DHCPv6 Options

--- 269,275 ----
     | Option              |      |     |      |                         |
     +---------------------+------+-----+------+-------------------------+

!                       Table 1: Modeled DHCPv6 Options

***************
*** 282,289 ****
  Internet-Draft              DHCPv6 YANG Model                 March 2021

!    Further options definitions can be added using additional YANG
!    modules via augmentation into the relevant element modules from this
     document.  Appendix A contains an example module showing how the
     DHCPv6 option definitions can be extended in this manner.  Some
     guidance on how to write YANG modules for additional DHCPv6 options
--- 283,290 ----
  Internet-Draft              DHCPv6 YANG Model                 March 2021

!    Further option definitions can be added using additional YANG
!    modules via augmentation of the relevant element modules from this
     document.  Appendix A contains an example module showing how the
     DHCPv6 option definitions can be extended in this manner.  Some
     guidance on how to write YANG modules for additional DHCPv6 options
***************
*** 291,297 ****

  1.3.  Terminology

!    The reader should be familiar with the YANG data modelling language
     defined in [RFC7950].

     The YANG modules in this document adopt the Network Management
--- 292,298 ----

  1.3.  Terminology

!    The reader should be familiar with the YANG data modeling language
     defined in [RFC7950].

     The YANG modules in this document adopt the Network Management
***************
*** 594,600 ****

     *  server-duid: Each server must have a DUID (DHCP Unique Identifier)
        to identify itself to clients.  A DUID consists of a two-octet
!       type field and an arbitrary length (of no more than 128-bytes)
        content field.  Currently there are four defined types of DUIDs in
        [RFC8415] and [RFC6355].  The DUID may be configured using the
        format for one of these types, or using the 'unstructured' format.
--- 595,601 ----

     *  server-duid: Each server must have a DUID (DHCP Unique Identifier)
        to identify itself to clients.  A DUID consists of a two-octet
!       type field and an arbitrary length (1-128 octets)
        content field.  Currently there are four defined types of DUIDs in
        [RFC8415] and [RFC6355].  The DUID may be configured using the
        format for one of these types, or using the 'unstructured' format.
***************
*** 603,609 ****
        are referenced for the relevant DUID types.

     *  vendor-config: This container is provided as a location for
!       additional implementation specific YANG nodes for the
        configuration of the device to be augmented.  See Appendix B for
        an example of such a module.

--- 604,610 ----
        are referenced for the relevant DUID types.

     *  vendor-config: This container is provided as a location for
!       additional implementation-specific YANG nodes for the
        configuration of the device to be augmented.  See Appendix B for
        an example of such a module.

***************
*** 637,643 ****
        this.

     *  network-ranges: A hierarchical model is used for the allocation of
!       addresses and prefixes.  At the top level 'network-ranges' holds
        global configuration parameters.  Under this, a list of 'network-
        ranges' can be defined.  Inside 'network-rages', 'address-pools'
        (for IA_NA and IA_TA allocations), and 'prefix-pools' (for IA_PD
--- 638,644 ----
        this.

     *  network-ranges: A hierarchical model is used for the allocation of
!       addresses and prefixes.  At the top level, 'network-ranges' holds
        global configuration parameters.  Under this, a list of 'network-
        ranges' can be defined.  Inside 'network-rages', 'address-pools'
        (for IA_NA and IA_TA allocations), and 'prefix-pools' (for IA_PD
***************
*** 651,662 ****
     Information about notifications:

     *  address/prefix-pool-utilization-threshold-exceeded: Raised when
!       number of leased addresses or prefixes exceeds the configured
        usage threshold.

     *  invalid-client-detected: Raised when the server detects an invalid
!       client.  A description of the error that has generated the
!       notification can be included.

     *  decline-received: Raised when a DHCPv6 Decline message is received
        from a client.
--- 652,663 ----
     Information about notifications:

     *  address/prefix-pool-utilization-threshold-exceeded: Raised when
!       the number of leased addresses or prefixes exceeds the configured
        usage threshold.

     *  invalid-client-detected: Raised when the server detects an invalid
!       client.  A description of the error and message type that has
!       generated the notification can be included.

     *  decline-received: Raised when a DHCPv6 Decline message is received
        from a client.
***************
*** 775,781 ****

     *  enabled: Globally enables/disables all DHCPv6 relay functions.

!    *  dhcpv6-relay: This container holds the relay's DHCPv6 specific
        configuration.

--- 776,782 ----

     *  enabled: Globally enables/disables all DHCPv6 relay functions.

!    *  dhcpv6-relay: This container holds the relay's DHCPv6-specific
        configuration.

***************
*** 818,824 ****
     Information about notifications:

     *  topology-changed: Raised when the topology of the relay agent is
!       changed, e.g. a client facing interface is reconfigured.

     Information about RPCs

--- 819,825 ----
     Information about notifications:

     *  topology-changed: Raised when the topology of the relay agent is
!       changed, e.g., a client facing interface is reconfigured.

     Information about RPCs

***************
*** 846,852 ****

     The tree diagram in Figure 3 provides an overview of the DHCPv6
     client module.  The tree also includes the common functions module
!    Section 3.4.

       module: ietf-dhcpv6-client
         +--rw dhcpv6-client
--- 847,853 ----

     The tree diagram in Figure 3 provides an overview of the DHCPv6
     client module.  The tree also includes the common functions module
!    defined in Section 3.4.

       module: ietf-dhcpv6-client
         +--rw dhcpv6-client
***************
*** 999,1006 ****

     *  client-duid: Each client must have a DUID (DHCP Unique Identifier)
        to identify itself to servers and relays.  A DUID consists of a
!       two-octet type field and an arbitrary length (of no more than
!       128-bytes) content field.  Currently there are four defined types
        of DUIDs in [RFC8415] and [RFC6355].  The DUID may be configured

--- 1000,1007 ----

     *  client-duid: Each client must have a DUID (DHCP Unique Identifier)
        to identify itself to servers and relays.  A DUID consists of a
!       two-octet type field and an arbitrary length (1-128 octets)
!       content field.  Currently there are four defined types
        of DUIDs in [RFC8415] and [RFC6355].  The DUID may be configured

***************
*** 1024,1030 ****

     *  ia-na, ia-ta, ia-pd: Contains configuration nodes relevant for
        requesting one or more of each of the lease types.  Read-only
!       nodes related to the active lease are also located here.

     Information about notifications:

--- 1025,1032 ----

     *  ia-na, ia-ta, ia-pd: Contains configuration nodes relevant for
        requesting one or more of each of the lease types.  Read-only
!       nodes related to the active leases for each type are also located
!       here.

     Information about notifications:

***************
*** 1216,1222 ****
             path "/dhcpv6-server/option-sets/option-set/option-set-id";
           }
           description "The ID field of relevant set of DHCPv6 options
!            (option-set) to be provisioned to clients of this
             network-range.";
         }
         leaf valid-lifetime {
--- 1218,1224 ----
             path "/dhcpv6-server/option-sets/option-set/option-set-id";
           }
           description "The ID field of relevant set of DHCPv6 options
!            (option-set) to be provisioned to clients of the using
             network-range.";
         }
         leaf valid-lifetime {
***************
*** 1246,1252 ****
           reference "RFC 8415: Dynamic Host Configuration Protocol for
             IPv6 (DHCPv6), Section 4.2";
         }
!        leaf preferred-lifetime {
           type dhcpv6-common:timer-seconds32;
           description "Preferred lifetime for the Identity Association
             (IA).";
--- 1248,1254 ----
           reference "RFC 8415: Dynamic Host Configuration Protocol for
             IPv6 (DHCPv6), Section 4.2";
         }
!       leaf preferred-lifetime {
           type dhcpv6-common:timer-seconds32;
           description "Preferred lifetime for the Identity Association
             (IA).";
***************
*** 1587,1594 ****
             in order to identify and classify incoming client messages
             so that they can be given the correct configuration.
             The mechanisms used for implementing this function vary
!            greatly between different implementations such that they
!            are not possible to include in this module. This container
             provides a location for server implementors to augment
             their own class-selector YANG.";
         }
--- 1589,1596 ----
             in order to identify and classify incoming client messages
             so that they can be given the correct configuration.
             The mechanisms used for implementing this function vary
!            greatly between different implementations such it is
!            not possible to include them in this module. This container
             provides a location for server implementors to augment
             their own class-selector YANG.";
         }
***************
*** 1647,1658 ****
                 leaf start-address {
                   type inet:ipv6-address-no-zone;
                   mandatory true;
!                  description "Start IPv6 address for the pool.";
                 }
                 leaf end-address {
                   type inet:ipv6-address-no-zone;
                   mandatory true;
!                  description "End IPv6 address for the pool.";
                 }
                 leaf max-address-utilization {
                   type dhcpv6-common:threshold;
--- 1649,1660 ----
                 leaf start-address {
                   type inet:ipv6-address-no-zone;
                   mandatory true;
!                  description "Starting IPv6 address for the pool.";
                 }
                 leaf end-address {
                   type inet:ipv6-address-no-zone;
                   mandatory true;
!                  description "Ending IPv6 address for the pool.";
                 }
                 leaf max-address-utilization {
                   type dhcpv6-common:threshold;
***************
*** 1762,1768 ****
                     from the prefix pool.";
                   list prefix-reservation {
                     key reserved-prefix;
!                    description "reserved prefix reservation";
                     leaf client-duid {
                       type dhcpv6-common:duid;
                       description "Client DUID for the reservation.";
--- 1764,1770 ----
                     from the prefix pool.";
                   list prefix-reservation {
                     key reserved-prefix;
!                    description "Reserved prefix reservation";
                     leaf client-duid {
                       type dhcpv6-common:duid;
                       description "Client DUID for the reservation.";
***************
*** 1780,1786 ****
                 }
                 container active-leases {
                   config false;
!                  description "Holds state related to for active client
                     prefix leases.";
                   leaf total-count {
                     type uint64;
--- 1782,1788 ----
                 }
                 container active-leases {
                   config false;
!                  description "Holds state related to active client
                     prefix leases.";
                   leaf total-count {
                     type uint64;
***************
*** 1890,1896 ****
           description "Maximum number of prefixes that can be
             simultaneously allocated from the pool. This value may be
             less than count of total prefixes. Calculated as the
!            max-precfix-utilization (percentage) of the
             total-pool-prefixes, rounded up.";
         }
         leaf allocated-prefixes-count {
--- 1892,1898 ----
           description "Maximum number of prefixes that can be
             simultaneously allocated from the pool. This value may be
             less than count of total prefixes. Calculated as the
!            max-prefix-utilization (percentage) of the
             total-pool-prefixes, rounded up.";
         }
         leaf allocated-prefixes-count {
***************
*** 1947,1953 ****
         }
         leaf description {
           type string;
!          description "Description of the event (e.g. and error code or
             log message).";
         }
       }
--- 1949,1955 ----
         }
         leaf description {
           type string;
!          description "Description of the event (e.g., and error code or
             log message).";
         }
       }
***************
*** 2008,2015 ****
       rpc delete-address-lease {
         nacm:default-deny-all;
         description "Deletes a client's active address lease from the
!          server's lease database. Note, this will not cause the address
!          to be revoked from the client, and the lease may be refreshed

--- 2010,2017 ----
       rpc delete-address-lease {
         nacm:default-deny-all;
         description "Deletes a client's active address lease from the
!          server's lease database. Note that this will not cause the
!          address to be revoked from the client, and the lease may be

***************
*** 2018,2033 ****
  Internet-Draft              DHCPv6 YANG Model                 March 2021

!          or renewed by the client.";
         input {
           leaf lease-address-to-delete {
             type leafref {
               path "../../dhcpv6-server/network-ranges/network-range" +
!                "/address-pools/address-pool/active-leases/active-lease"
!    +
!                "/leased-address";
             }
!              mandatory true;
             description "IPv6 address of an active lease that will be
               deleted from the server.";
           }
--- 2020,2034 ----
  Internet-Draft              DHCPv6 YANG Model                 March 2021

!          refreshed or renewed by the client.";
         input {
           leaf lease-address-to-delete {
             type leafref {
               path "../../dhcpv6-server/network-ranges/network-range" +
!                "/address-pools/address-pool/active-leases" +
!                "/active-lease/leased-address";
             }
!            mandatory true;
             description "IPv6 address of an active lease that will be
               deleted from the server.";
           }
***************
*** 2271,2277 ****
           }
           leaf client-peer-address {
             type inet:ipv6-address;
!            description "Peer-address of the client.";
           }
           leaf client-duid {
             type dhcpv6-common:duid;
--- 2272,2278 ----
           }
           leaf client-peer-address {
             type inet:ipv6-address;
!            description "Peer-address of the leasing client.";
           }
           leaf client-duid {
             type dhcpv6-common:duid;
***************
*** 2449,2455 ****
       container dhcpv6-relay {
         description
           "This container contains the configuration data nodes for
!          the relay.";
         reference "RFC 8415: Dynamic Host Configuration Protocol for
             IPv6 (DHCPv6), Section 19";
        leaf enabled {
--- 2450,2456 ----
       container dhcpv6-relay {
         description
           "This container contains the configuration data nodes for
!           the relay.";
         reference "RFC 8415: Dynamic Host Configuration Protocol for
             IPv6 (DHCPv6), Section 19";
        leaf enabled {
***************
*** 2483,2490 ****
             type inet:ipv6-address;
             description "Each DHCPv6 relay agent may be configured with
               a list of destination addresses for relayed messages.
!              The list may include unicast addresses, multicast addresses
!              or other valid addresses.";
           }
           leaf link-address {
             type string {
--- 2484,2491 ----
             type inet:ipv6-address;
             description "Each DHCPv6 relay agent may be configured with
               a list of destination addresses for relayed messages.
!              The list may include unicast addresses, multicast
!              addresses, or other valid addresses.";
           }
           leaf link-address {
             type string {
***************
*** 2495,2502 ****
          }
           container relay-options {
             description "Definitions for DHCPv6 options that can be sent
!              by the relay are augmented to this location from other YANG
!              modules as required.";
             uses dhcpv6-common:auth-option-group;
             uses dhcpv6-common:status-code-option-group;
             uses interface-id-option-group;
--- 2496,2503 ----
          }
           container relay-options {
             description "Definitions for DHCPv6 options that can be sent
!              by the relay. This container can be augmented from other
!              YANG modules as required.";
             uses dhcpv6-common:auth-option-group;
             uses dhcpv6-common:status-code-option-group;
             uses interface-id-option-group;
***************
*** 2559,2567 ****
         input {
           leaf lease-prefix {
             type leafref {
!              path "/dhcpv6-relay/relay-if/prefix-delegation/pd-leases/"
!    +
!              "ia-pd-prefix";
             }
             mandatory true;
             description "IPv6 prefix of an active lease entry that will
--- 2560,2567 ----
         input {
           leaf lease-prefix {
             type leafref {
!              path "/dhcpv6-relay/relay-if/prefix-delegation/" +
!              "pd-leases/ia-pd-prefix";
             }
             mandatory true;
             description "IPv6 prefix of an active lease entry that will
***************
*** 2594,2600 ****
           leaf client-duid {
             type dhcpv6-common:duid;
             mandatory true;
!            description "DUID of the client .";
           }
         }
         output {
--- 2594,2600 ----
           leaf client-duid {
             type dhcpv6-common:duid;
             mandatory true;
!            description "DUID of the client.";
           }
         }
         output {
***************
*** 2981,2988 ****
         }
         list client-if {
           key if-name;
!          description "The list of interfaces that the client will be
!            requesting DHCPv6 configuration for.";
           leaf if-name {
             type if:interface-ref;
             mandatory true;
--- 2981,2988 ----
         }
         list client-if {
           key if-name;
!          description "The list of interfaces for which the client will
!            be requesting DHCPv6 configuration.";
           leaf if-name {
             type if:interface-ref;
             mandatory true;
***************
*** 3002,3008 ****
               IPv6 (DHCPv6), Section 11";
           }
           container client-configured-options {
!            description " Definitions for DHCPv6 options that can be be
               sent by the client. Additional option definitions can be
               augmented to this location from other YANG modules as
               required.";
--- 3002,3008 ----
               IPv6 (DHCPv6), Section 11";
           }
           container client-configured-options {
!            description "Definitions for DHCPv6 options that can be be
               sent by the client. Additional option definitions can be
               augmented to this location from other YANG modules as
               required.";
***************
*** 3048,3059 ****
               leaf preferred-lifetime {
                 type dhcpv6-common:timer-seconds32;
                 description "The preferred lifetime for the leased
!                  address expressed in units of seconds.";
               }
               leaf valid-lifetime {
                 type dhcpv6-common:timer-seconds32;
                 description "The valid lifetime for the leased address
!                  expressed in units of seconds.";
               }
               leaf lease-t1 {
                 type dhcpv6-common:timer-seconds32;
--- 3048,3059 ----
               leaf preferred-lifetime {
                 type dhcpv6-common:timer-seconds32;
                 description "The preferred lifetime for the leased
!                  address expressed in seconds.";
               }
               leaf valid-lifetime {
                 type dhcpv6-common:timer-seconds32;
                 description "The valid lifetime for the leased address
!                  expressed in seconds.";
               }
               leaf lease-t1 {
                 type dhcpv6-common:timer-seconds32;
***************
*** 3118,3129 ****
               leaf preferred-lifetime {
                 type dhcpv6-common:timer-seconds32;
                 description "The preferred lifetime for the leased
!                  address expressed in units of seconds.";
               }
               leaf valid-lifetime {
                 type dhcpv6-common:timer-seconds32;
                 description "The valid lifetime for the leased address
!                  expressed in units of seconds.";
               }
               leaf allocation-time {
                 type yang:date-and-time;
--- 3118,3129 ----
               leaf preferred-lifetime {
                 type dhcpv6-common:timer-seconds32;
                 description "The preferred lifetime for the leased
!                  address expressed in seconds.";
               }
               leaf valid-lifetime {
                 type dhcpv6-common:timer-seconds32;
                 description "The valid lifetime for the leased address
!                  expressed in seconds.";
               }
               leaf allocation-time {
                 type yang:date-and-time;
***************
*** 3150,3160 ****
             }
           }
           list ia-pd {
!            key iaid;
             description "Configuration relevant for an IA_PD.";
             reference "RFC 8415: Dynamic Host Configuration Protocol for
               IPv6 (DHCPv6), Section 13.3";
!            leaf iaid {
               type uint32;
               description "The unique identifier for this IA_PD.";
               reference "RFC 8415: Dynamic Host Configuration Protocol
--- 3150,3160 ----
             }
           }
           list ia-pd {
!            key ia-id;
             description "Configuration relevant for an IA_PD.";
             reference "RFC 8415: Dynamic Host Configuration Protocol for
               IPv6 (DHCPv6), Section 13.3";
!            leaf ia-id {
               type uint32;
               description "The unique identifier for this IA_PD.";
               reference "RFC 8415: Dynamic Host Configuration Protocol
***************
*** 3230,3244 ****

       notification invalid-ia-address-detected {
         description "Notification sent when an address received
!          in an identity association option can be proved to be invalid.
           Possible conditions include a duplicate or otherwise illegal
           address.";
         reference "RFC 8415: Dynamic Host Configuration Protocol for
           IPv6 (DHCPv6), Section 18.2.10.1";
!        leaf iaid {
           type uint32;
           mandatory true;
!          description "IAID";
         }
         leaf ia-na-t1-timer {
           type uint32;
--- 3230,3244 ----

       notification invalid-ia-address-detected {
         description "Notification sent when an address received
!          in an identity association option is determined invalid.
           Possible conditions include a duplicate or otherwise illegal
           address.";
         reference "RFC 8415: Dynamic Host Configuration Protocol for
           IPv6 (DHCPv6), Section 18.2.10.1";
!        leaf ia-id {
           type uint32;
           mandatory true;
!          description "IA-ID";
         }
         leaf ia-na-t1-timer {
           type uint32;
***************
*** 3250,3262 ****
  Internet-Draft              DHCPv6 YANG Model                 March 2021

!          description "The value of the T1 time field for non-tempory
             address allocations (OPTION_IA_NA).";
         }
         leaf ia-na-t2-timer {
           type uint32;
           description "The value of the preferred-lifetime field for
!            non-tempory address allocations (OPTION_IA_NA).";
         }
         leaf invalid-address {
           type inet:ipv6-address;
--- 3250,3262 ----
  Internet-Draft              DHCPv6 YANG Model                 March 2021

!          description "The value of the T1 time field for non-temporary
             address allocations (OPTION_IA_NA).";
         }
         leaf ia-na-t2-timer {
           type uint32;
           description "The value of the preferred-lifetime field for
!            non-temporary address allocations (OPTION_IA_NA).";
         }
         leaf invalid-address {
           type inet:ipv6-address;
***************
*** 3280,3286 ****
         }
         leaf description {
           type string;
!          description "Description of the event.";
         }
       }

--- 3280,3287 ----
         }
         leaf description {
           type string;
!          description "Description of the invalid Identity
!          Association (IA) detection error.";
         }
       }

***************
*** 3375,3381 ****
       notification server-duid-changed {
         description "Notification sent when the client receives a lease
           from a server with different DUID to the one currently stored
!          by the client, e.g. in response to a Rebind message.";
         reference "RFC 8415: Dynamic Host Configuration Protocol for
           IPv6 (DHCPv6), Section 18.2.5";
         leaf new-server-duid {
--- 3376,3382 ----
       notification server-duid-changed {
         description "Notification sent when the client receives a lease
           from a server with different DUID to the one currently stored
!          by the client, e.g., in response to a Rebind message.";
         reference "RFC 8415: Dynamic Host Configuration Protocol for
           IPv6 (DHCPv6), Section 18.2.5";
         leaf new-server-duid {
***************
*** 3559,3565 ****
         }
         description "Each DHCP server and client has a DUID (DHCP
           Unique Identifier). The DUID consists of a two-octet
!          type field and an arbitrary length (between 1 and 128 octets)
           content field.  Currently, there are four defined types of
           DUIDs in RFC 8415 and RFC 6355 - DUID-LLT, DUID-EN, DUID-LL
           and DUID-UUID.  DUID-unstructured represents DUIDs which
--- 3560,3566 ----
         }
         description "Each DHCP server and client has a DUID (DHCP
           Unique Identifier). The DUID consists of a two-octet
!          type field and an arbitrary length (1-128 octets)
           content field.  Currently, there are four defined types of
           DUIDs in RFC 8415 and RFC 6355 - DUID-LLT, DUID-EN, DUID-LL
           and DUID-UUID.  DUID-unstructured represents DUIDs which
***************
*** 3742,3748 ****
           leaf status-message {
             type string;
             description "A UTF-8 encoded text string suitable for
!              display to an end user. MUST NOT be null-terminated.";
           }
         }
       }
--- 3743,3749 ----
           leaf status-message {
             type string;
             description "A UTF-8 encoded text string suitable for
!              display to an end-user. It MUST NOT be null-terminated.";
           }
         }
       }
***************
*** 3775,3781 ****
             Information Option container.";
           list vendor-specific-information-option-instances {
             key enterprise-number;
!            description "The vendor specific information option allows
               for multiple instances in a single message. Each list entry
               defines the contents of an instance of the option.";
             leaf enterprise-number {
--- 3776,3782 ----
             Information Option container.";
           list vendor-specific-information-option-instances {
             key enterprise-number;
!            description "The vendor-specific information option allows
               for multiple instances in a single message. Each list entry
               defines the contents of an instance of the option.";
             leaf enterprise-number {
***************
*** 3873,3880 ****
        rogue DHCPv6 server.

     *  Various attacks based on re-configuring the contents of DHCPv6
!       options.  E.g., changing the address of a the DNS server supplied
!       in a DHCP option to point to a rogue server.

     An attacker who is able to access the DHCPv6 relay can undertake
     various attacks, such as:
--- 3874,3881 ----
        rogue DHCPv6 server.

     *  Various attacks based on re-configuring the contents of DHCPv6
!       options.  For example, changing the address of a the DNS server
!       advertised in a DHCP option to point to a rogue server.

     An attacker who is able to access the DHCPv6 relay can undertake
     various attacks, such as:
***************
*** 3893,3899 ****
     data nodes can be misused to track the activity of a host:

     *  Information the server holds about clients with active leases:
!       (dhcpv6-server/network-ranges/network-range/ address-pools/
        address-pool/active-leases)

     *  Information the relay holds about clients with active leases:
--- 3894,3900 ----
     data nodes can be misused to track the activity of a host:

     *  Information the server holds about clients with active leases:
!       (dhcpv6-server/network-ranges/network-range/address-pools/
        address-pool/active-leases)

     *  Information the relay holds about clients with active leases:
***************
*** 3958,3965 ****
  6.  Acknowledgments

     The authors would like to thank Qi Sun, Lishan Li, Hao Wang, Tomek
!    Mrugalski, Marcin Siodelski, Bernie Volz, Ted Lemon, Bing Liu, and
!    Tom Petch for their valuable comments and contributions to this work.

  7.  Contributors

--- 3959,3967 ----
  6.  Acknowledgments

     The authors would like to thank Qi Sun, Lishan Li, Hao Wang, Tomek
!    Mrugalski, Marcin Siodelski, Bernie Volz, Ted Lemon, Bing Liu, Tom
!    Petch, and Acee Lindem for their valuable comments and contributions
!    to this work.

  7.  Contributors

***************
*** 4300,4306 ****
           (DHCPv6) Options for Session Initiation Protocol (SIP)
           Servers";
         container sip-server-domain-name-list-option {
!         description "OPTION_SIP_SERVER_D (21) SIP Servers Domain Name
            List container.";
          list sip-server {
             key sip-serv-id;
--- 4302,4308 ----
           (DHCPv6) Options for Session Initiation Protocol (SIP)
           Servers";
         container sip-server-domain-name-list-option {
!         description "OPTION_SIP_SERVER_D (21) SIP Servers Domain-Name
            List container.";
          list sip-server {
             key sip-serv-id;
***************
*** 4374,4386 ****

     The correct location to augment the new option definition(s) will
     vary according to the specific rules defined for the use of that
!    specific option.  E.g. for options which will be augmented into the
!    ietf-dhcpv6-server module, in many cases, these will be augmented to:

!    '/dhcpv6-server:dhcpv6-server/dhcpv6-server:option-sets/\ dhcpv6-
!    server:option-set'

!    so that they can be defined within option sets.  However, there are
     some options which are only applicable for specific deployment
     scenarios and in these cases it may be more logical to augment the
     option group to a location relevant for the option.
--- 4376,4389 ----

     The correct location to augment the new option definition(s) will
     vary according to the specific rules defined for the use of that
!    specific option.  Fpr example, for options which will be augmented
!    into the ietf-dhcpv6-server module, in many cases, these will be
!    augmented to:

!    '/dhcpv6-server:dhcpv6-server/dhcpv6-server:option-sets/
!      dhcpv6-server:option-set'

!    So that they can be defined within option sets.  However, there are
     some options which are only applicable for specific deployment
     scenarios and in these cases it may be more logical to augment the
     option group to a location relevant for the option.
***************
*** 4390,4404 ****
     specific prefix.  In this case, the following location for the
     augmentation may be more suitable:

!    '/dhcpv6-server:dhcpv6-server/dhcpv6-server:network-ranges/\ dhcpv6-
!    server:network-range/dhcpv6-server:prefix-pools/\ dhcpv6-
!    server:prefix-pool"

! Appendix B.  Example Vendor Specific Server Configuration Module

     This section shows how to extend the server YANG module defined in
     this document with vendor specific configuration nodes, e.g.,
!    configuring access to a lease storage database.

     The example module defines additional server attributes such as name
     and description.  Storage for leases is configured using a lease-
--- 4393,4407 ----
     specific prefix.  In this case, the following location for the
     augmentation may be more suitable:

!    '/dhcpv6-server:dhcpv6-server/dhcpv6-server:network-ranges/
!      dhcpv6-server:network-range/dhcpv6-server:prefix-pools/
!      dhcpv6-server:prefix-pool'

! Appendix B.  Example Vendor-Specific Server Configuration Module

     This section shows how to extend the server YANG module defined in
     this document with vendor specific configuration nodes, e.g.,
!    configuring access to a lease-storage database.

     The example module defines additional server attributes such as name
     and description.  Storage for leases is configured using a lease-
***************
*** 4454,4460 ****
       description "This YANG module defines components for the
         configuration and management of vendor/implementation specific
         DHCPv6 server functionality. As this functionality varies
!        greatly between different implementations, the module
         provided as an example only.

         Copyright (c) 2021 IETF Trust and the persons identified as
--- 4457,4463 ----
       description "This YANG module defines components for the
         configuration and management of vendor/implementation specific
         DHCPv6 server functionality. As this functionality varies
!        greatly between different implementations, the module is
         provided as an example only.

         Copyright (c) 2021 IETF Trust and the persons identified as
***************
*** 4569,4576 ****
             case interface-list {
               leaf-list interfaces {
                 type if:interface-ref;
!                description "List of interfaces that the server will
!                  listen for incoming messages on. Messages addressed
                   to any valid IPv6 address (unicast and multicast) will
                   be received.";
               }
--- 4572,4579 ----
             case interface-list {
               leaf-list interfaces {
                 type if:interface-ref;
!                description "List of interfaces on which the server will
!                  listen for incoming DHCPv6 messages Messages addressed
                   to any valid IPv6 address (unicast and multicast) will
                   be received.";
               }
***************
*** 4578,4585 ****
             case address-list {
               leaf-list address-list {
                 type inet:ipv6-address;
!                description "List of IPv6 address(es) that the server
!                  will listen for incoming messages on.";
               }
             }
           }
--- 4581,4588 ----
             case address-list {
               leaf-list address-list {
                 type inet:ipv6-address;
!                description "List of IPv6 address(es) on which the server
!                  will listen for incoming DHCPv6 messages.";
               }
             }
           }
***************
*** 4594,4601 ****
  Internet-Draft              DHCPv6 YANG Model                 March 2021

!            description "A leaf list to denote which one or more
!              interfaces the server should listen on.";
           }
           container lease-storage {
             description "Configures how the server will stores leases.";
--- 4597,4604 ----
  Internet-Draft              DHCPv6 YANG Model                 March 2021

!            description "A leaf list of interfaces on which the server
!              should listen.";
           }
           container lease-storage {
             description "Configures how the server will stores leases.";
***************
*** 4603,4610 ****
               description "The type storage that will be used for lease
                 information.";
               case memfile {
!                description "Configuration for storing leases information
!                  in a CSV file.";
                 leaf memfile-name {
                   type string;
                   description "Specifies the absolute location
--- 4606,4613 ----
               description "The type storage that will be used for lease
                 information.";
               case memfile {
!                description "Configuration for storing lease information
!                  in a Common-Separated Valu (CSV) file.";
                 leaf memfile-name {
                   type string;
                   description "Specifies the absolute location
***************
*** 4630,4637 ****
                       type inet:domain-name;
                       default "localhost";
                       description "If the database is located on a
!                        different system to the DHCPv6 server, the
!                          domain name can be specified.";
                     }
                   }
                   case mysql-server-address {
--- 4633,4640 ----
                       type inet:domain-name;
                       default "localhost";
                       description "If the database is located on a
!                        different system than the DHCPv6 server, the
!                        domain name can be specified.";
                     }
                   }
                   case mysql-server-address {
***************
*** 4766,4786 ****
     }
     <CODE ENDS>

! Appendix C.  Example definition of class selector configuration

     The module "ietf-example-dhcpv6-class-selector" provides an example
!    of how vendor specific class selection configuration can be modelled
     and integrated with the "ietf-dhcpv6-server" module defined in this
     document.

     The example module defines "client-class-names" with associated
     matching rules.  A client can be classified based on "client-id",
!    "interface-id" (ingress interface of the client's messages), packets
     source or destination address, relay link address, relay link
     interface-id and more.  Actually, there are endless methods for
     classifying clients.  So this standard does not try to provide full
     specification for class selection, it only shows an example how it
!    can be defined.

     At the end of the example augment statements are used to add the
     defined class selector rules into the overall DHCPv6 addressing
--- 4769,4789 ----
     }
     <CODE ENDS>

! Appendix C.  Example definition of class-selector configuration

     The module "ietf-example-dhcpv6-class-selector" provides an example
!    of how vendor-specific class selection configuration can be modeled
     and integrated with the "ietf-dhcpv6-server" module defined in this
     document.

     The example module defines "client-class-names" with associated
     matching rules.  A client can be classified based on "client-id",
!    "interface-id" (ingress interface of the client's messages), packet's
     source or destination address, relay link address, relay link
     interface-id and more.  Actually, there are endless methods for
     classifying clients.  So this standard does not try to provide full
     specification for class selection, it only shows an example how it
!    could be defined.

     At the end of the example augment statements are used to add the
     defined class selector rules into the overall DHCPv6 addressing
***************
*** 4843,4854 ****
          Author:   Michal Nowikowski <[e-mail]>";

       description "This YANG module defines components for the
!        definition and configuration of the client class selector functio
!    n
!        for a DHCPv6 server.  As this functionality varies greatly betwee
!    n
!        different implementations, the module provided as an example
!        only.

         Copyright (c) 2021 IETF Trust and the persons identified as
         authors of the code.  All rights reserved.
--- 4846,4855 ----
          Author:   Michal Nowikowski <[e-mail]>";

       description "This YANG module defines components for the
!        definition and configuration of the client class selector
!        function for a DHCPv6 server.  As this functionality varies
!        greatly between different implementations, the module is
!        provided only as an example.

         Copyright (c) 2021 IETF Trust and the persons identified as
         authors of the code.  All rights reserved.