A YANG Data Model for DHCPv6 Configuration
draft-ietf-dhc-dhcpv6-yang-25

[Ballot comment]
Many thanks for the updates in the -25!

I have no further comments other than to apologize for having taken
so long to review the changes and remove my DISCUSS.  Great work!

[Ballot comment]
Thanks for publishing another YANG module.

I found this document well written, and in particular I thought that the section on options extensibility and examples in the appendix to be thoughtful and helpful.  I ​only have a few minor (non blocking) comments on the structure of the YANG module that you may wish to consider:

1. You may want to consider putting the counters under a container to group them together, and perhaps to make it easier for a targeted telemetry subscription.

2. The paths on your RPCs and top level Notifications are using relative paths - it would probably be clearer to use absolute paths here.

3. I would remove "container" from the Option description strings, to improve help string readability.

4. Please make sure that you fix the 3 idnits YANG warnings (e.g., alignment of the revision-date to the extracted file date).

Perhaps in a future draft the IETF will manage to standardize common configuration for the class selection function since that will help interop but I can appreciate that is tricky to get consensus on if the existing models/CLIs are far apart, and you seem to have taken a pragmatic approach here.

Regards,
Rob

[Ballot comment]
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 4.1. , paragraph 10, nit:
-        to the license terms contained in, the Simplified BSD License
-                                              ^ ^^^^^^
+        to the license terms contained in, the Revised BSD License
+                                              ^^^ ^

Also elsewhere, please change them all. (The TLP recently changed.)

Section 3.1. , paragraph 3, nit:
>  than 128-octets) content field. Currently there are four defined types of D
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Currently".
[SENT_START_CONJUNCTIVE_LINKING_ADVERB_COMMA]

Section 3.1. , paragraph 5, nit:
> ed when there is a status message for an failure. 3.2. DHCPv6 Relay Tree Dia
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university". [EN_A_VS_AN]

Section 3.3. , paragraph 3, nit:
> th (1-128 octets) content field. Currently there are four defined types of D
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Currently".
[SENT_START_CONJUNCTIVE_LINKING_ADVERB_COMMA]

Section 4.1. , paragraph 20, nit:
>  this option to tell the client whether or not to accept Reconfigure messages
>                                ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether". [WHETHER]

Section 4.2. , paragraph 38, nit:
> nitions for DHCPv6 options that can be be sent by the client. Additional opti
>                                    ^^^^^
Possible typo: you repeated a word. [ENGLISH_WORD_REPEAT_RULE]

Section 4.4. , paragraph 29, nit:
> tions The following section provides a example of how the DHCPv6 option defi
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour". [EN_A_VS_AN]

Section 4.4. , paragraph 29, nit:
> escription "SIP server list identifier identifier."; } leaf sip-serv-domain-n
>                            ^^^^^^^^^^^^^^^^^^^^^
Possible typo: you repeated a word. [ENGLISH_WORD_REPEAT_RULE]

Section 4.4. , paragraph 33, nit:
> on "Configures how the server will stores leases."; choice storage-type { de
>                                    ^^^^^^
The modal verb "will" requires the verb's base form. [MD_BASEFORM]

Section 4.4. , paragraph 35, nit:
> rname { type string; description "User name of the account under which the se
>                                  ^^^^^^^^^
It's more common nowadays to write this noun as one word.
[RECOMMENDED_COMPOUNDS]

Section 5. , paragraph 2, nit:
> rname { type string; description "User name of the account under which the se
>                                  ^^^^^^^^^
It's more common nowadays to write this noun as one word.
[RECOMMENDED_COMPOUNDS]

[Ballot comment]
Thanks to the authors for their diligent efforts on this document. I really get impressed by all the YANG model documents I review. I don't think I have much to comment to improve this specification or something that I am worried about.

I however, think RFC 8987 should be in the normative reference as it is referenced from the "RPCs" section. You can let me know it should not.

[Ballot comment]
[S1.2; nit]

* s/demonstrate how this is can be/demonstrate how this can be/

[S3.1; nit]

* s/for an failure/for a failure/

[S3.2, S4.3]

* Should RFC 4649 remote-id be included here?  Or, perhaps, did RFC 8415
  S21.18 OPTION_INTERFACE_ID effectively obsolete OPTION_REMOTE_ID use
  cases (or perhaps I'm just confused)?

[S3.3, 4.4; question]

* For the user class and vendor class options, should they be annotated as
  "not anon-profile"?  I'm curious about these elements w.r.t. to
  RFC7844 S4.8.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

    This write-up is based on draft-ietf-dhc-dhcpv6-yang-22.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

    The RFC requested is Proposed Standard. And, this is appropriate for this
    document as it defines YANG modules for the configuration and management of
    DHCPv6 elements for use in NETCONF and RESTCONF.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This memo describes YANG data modules for the configuration and
  management of DHCPv6 (Dynamic Host Configuration Protocol for IPv6)
  servers, relays, and clients.


Working Group Summary:

  This document had review for the DHC Working Group, in particular Tom Petch
  has reviewed several versions of this document during the process.  Most of the
  discussion was about how to break up the modules to work for client, server, and
  relay.  Tom did several passes on the document during the process. 

Document Quality:

  The document was reviewed by a couple of members of the DHC working group.  It
  was also sent to a YANG Doctor (Acee Lindem) for early review.  During the YANG Review,
  the document was marked an On the Right Track. The authors have implemented the changes
  recommended by the review, with some additional comments from DHC Working Group members.

  Implementations of the DHCPv6 client module are available at: https://github.com/telekom/sysrepo-plugin-interfaces/tree/dhcpv6-client
  Server (based on the modules from -12 of the draft): https://github.com/telekom/dt-kea-netconf

Personnel:

    Timothy Winters is the Document Shepherd, Éric Vyncke is the Responsible
    Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

    As document shepherd, I reviewed this document to assure that it is following the WG   
    consensus and discussions and is of good quality. In my opinion, the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

    No. The document had review in DHC group and was also reviewed during the
    yang early review process. There was good discussion between a member of DHC
    and the authors of the document on use cases.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
   
    Yes this document received an YANG doctor early review which helped correct some default settings and corrected several minor issues.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

    I have no concerns or issues with any of the material.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

    Yes, the authors confirmed all the IPR disclosures requirements.  https://mailarchive.ietf.org/arch/msg/dhcwg/4AsYOwIHx9L3JaNz6rF_v5LqzFA/


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

    No, there is no IPR filed against this document and hence there was no IPR
    discussion in the WG.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
   
    This document had strong review by the few individuals that were involved in needing YANG models for DHCP deployments. 
    The silent members of the working group understood the need for YANG model for describing DHCP functions,
    but weren't interested in participating in the process.  There was no indication that anyone disagreed with any of the material.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

    Ran the ID nits, it only commented on potential white space issues that were in the yang models, so no issues.  Read the document and didn't find any errors or formatting issues.   
   


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    This document had an early Yang doctor review. 
    https://datatracker.ietf.org/doc/review-ietf-dhc-dhcpv6-yang-19-yangdoctors-early-lindem-2021-05-05/


(13) Have all references within this document been identified as either normative or informative?

Yes, every reference that I located had a valid reference. 


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document has a IANA considerations sections, that updated the proper registries for both YANG and XML.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A


(19) Describe reviews and automated checks performed by those Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Yang Validation runs without any issues on 2021-09-13.


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

It did run with the YANG validation tool and no issues were uncovered.  Yes it complies with RFC8342.

[Ballot discuss]
This should be easy to resolve, but we have to ask as it's pretty important:

Question 7 of the shepherd writeup, about the authors and BCP 78/79, appears not to have been answered.  Were these declarations made?

[Ballot comment]
I suggest breaking Section 6 into two subsections, one for each batch of registry operations.

A possibly ignorant question about YANG modules: Since RFCs 3319 and 8987 are referenced from within the module itself, shouldn't they be normative references?

[Ballot discuss]
Roman's comment touched on a related point, but I'd like to (hopefully
briefly) discuss the way we encode certain opaque protocol fields.
There are some places where we clearly intend a hex representation (a
string with a pattern that's marked out as pairs of hex digits), but
there are others where we just say "type string" with no indication of
encoding, and even a "type binary".  If we want the specification to
admit interoperable implementation we need to be more clear about what
encoding we expect for all of these nodes.  I have noted most (possibly
all, but please double check) in the COMMENT section, with a preference
for "type binary" where we don't need to apply regex restrictions.  But
that's just a personal preference, and choosing to use hex (or base64,
or any other well-defined) encoding will suffice to resolve the discuss
point.

[Ballot comment]
Thanks to the shepherd for answering the second part of question (1) in
the template, as well as the first; this part of the question is often
missed.  (There is, however, a third part as well...)

Section 1.2.1

Table 1 is described as showing "the DHCPv6 options that are modeled,
the element(s) they are sent by, and the relevant YANG module name".  In
my interpretation that means that:

- the only options that are in the table are ones that are modeled
- the contents of the table shows which elements send those options

But the contents of the table don't quite seem to match that -- it seems
that they only indicate which nodes have YANG modeling for how to send
the option, and not indicate nodes that send the option but do not need
YANG configuration to control how to populate the option.  (E.g.,
OPTION_AUTH and OPTION_USER_CLASS.)  If this is the intent, then perhaps
it's clearer to say "which YANG modules they are modeled for" or
something similar, rather than "the element(s) they are sent by".

Section 3.1

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

The node that seems to be where the "configured usage threshold" is
configured is scoped to an address pool or prefix pool.  Should this
description say "number of leased [...] in an address pool exceeds the
configured usage threshold"?

Section 4.1

        +------+------+----------+--------------+
        | 0001 | 0006 | 28490058 | 00005E005300 |
        +------+------+----------+--------------+

        This example includes the 2-octet DUID type of 1 (0x01), the
        hardware type is 0x06 (IEEE Hardware Types) the creation
        time is 0x028490058 (constructed as described above). Finally,
        the link-layer address is 0x5E005300 (EUI-48 address
        00-00-5E-00-53-00)";

Should there be some more zeros in here (e.g., in the artwork before
28490058)?

    typedef duid-en {
      type duid-base {
        pattern '0002'
          + '[0-9a-fA-F]{4,}';
      }
      description
        "DUID type 2, assigned by vendor based on Enterprise
        Number (DUID-EN). This DUID consists of the 4-octet vendor's
        registered Private Enterprise Number as maintained by IANA
        followed by a unique identifier assigned by the vendor. For
        example:

A 4-octet PEN would be 8 hex digits (the YANG allows as few as 4).

    typedef duid-unstructured {
      type duid-base {
        pattern '(000[1-4].*|.*[^0-9a-fA-F].*)' {
          modifier invert-match;
        }
      }

My understanding is that the "pattern" modifiers from the base type and
the derived type are "and"-ed together, so the "|.*[^0-9a-fA-F].*"
clause is redundant with the pattern in the base type and thus not
needed.

      container status {
      [...]
        leaf message {
          type string;
          description
            "A UTF-8 encoded text string suitable for display to an
            end user. It MUST NOT be null-terminated.";

(Related to Roman's comment)
This is probably more of a comment on RFC 8415 than this document, but
BCP 18 seems pretty clear that a string destined for display to a human
should be accompanied by a language indicator.
(This comment probably applies to every "leaf message" but I will just
mention it this once.)

    grouping auth-option-group {
    [...]
      container auth-option {
      [...]
        leaf auth-information {
          type string;
          description
            "The authentication information, as specified by the
            protocol and algorithm used in this Authentication
            option.";

This should probably be binary, not a string.  Or, if it needs to be a
string, it should specify an encoding (e.g., hex).

    grouping status-code-option-group {

FWIW, this grouping seems unused by the rest of the document.  (Perhaps
a remnant of a decision to move the status information out of the
options section and into a higher level of the relevant YANG trees?)

            leaf sub-option-data {
              type string {
                pattern '([0-9a-fA-F]{2}){0,}';
              }
              description
                "The data area for the sub-option.";

Why does this need to be hex-encoded (vs. YANG binary)?
And, if it is hex-encoded, we should probably say so explicitly in the
description.

Section 4.2

      leaf preferred-lifetime {
        type dhc6:timer-seconds32;
        description
          "Preferred lifetime for the Identity Association (IA).";
        reference "RFC 8415: Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6), Section 6";

Is Section 6 really the best section reference for this concept?

    grouping message-stats {

The relay module has a counter for discarded messages; would a similar
counter make sense here?  (Also for the server module, I think.)

Also, YANG does have dedicated "counter" types to more precisely
indicate semantics than just "uint32".  They are by definition
monotonically increasing, though, and are their use is typically
accompanied by a "last discontinuity time" node to indicate when they
have been reset.

    grouping info-refresh-time-option-group {
      [...]
        leaf info-refresh-time {
          type dhc6:timer-seconds32;
          description
            "Time duration relative to the current time, expressed
            in units of seconds.";

Is this really "relative to the current time" for purposes of the YANG
module?  This is the description that RFC 8415 uses, yes, but that
refers to the current time when the protocol message is received, and
YANG interactions may be asynchronous to that.

          container address-pools {
          [...]
            list address-pool {
              key pool-id;
              [...]
              leaf pool-id {
                type string;

What's the motivation for making the pool-id a string vs the option-set
and allocation-range lists that have an integer identifier?  (Also
applies to prefix pools.)

              leaf pool-prefix {
                type inet:ipv6-prefix;
                mandatory true;
                description
                  "IPv6 prefix for the pool.";

Does this prefix need to be contained within the overall
"network-prefix"?  (Same question for prefix-pools' pool-prefix.)

              leaf max-address-utilization {
                type dhc6:threshold;
                description
                  "Maximum amount of the addresses in the
                  pool which can be simultaneously allocated,
                  calculated as a percentage of the available
                  addresses (end-address minus start-address plus
                  one).";

Do we want to mention the relationship between this node and the
"address-pool-utiliziation-threshold-exceeded" notification?  I see the
pointer the other direction, but since we don't use the word "threshold"
in the description here I wouldn't mind a more explicit linkage.
(Likewise for the prefix-allocation case.)

                list active-lease {
                  key leased-prefix;
                  description
                    "List of active prefix leases.";
                  leaf leased-prefix {
                    type inet:ipv6-prefix;
                    description
                      "Active leased prefix entry.";

Is the prefix length available from some other information in the tree?
If not, should it be listed here?

    notification decline-received {
      if-feature na-assignment;
      description
        "Notification sent when the server has received a
        Decline (9) message from a client.";

Is this a potential DoS vector to the notification recipient (if a
malicious client just starts declining everything)?  Should we say
anything about rate-limiting?

    notification non-success-code-sent {
      description
        "Notification sent when the server responded
        to a client with non-success status code.";

(similarly here)

Section 4.3

    grouping interface-id-option-group {
      [...]
        leaf interface-id {
          type string;
          description
            "An opaque value of arbitrary length generated by the
            relay agent to identify one of the relay agent's
            interfaces.";

I think this is better as a YANG "binary" type than a string.  If not,
we should say something about the encoding.

Section 4.4

Why do we use "prefix-del" for the feature name in this module but the
full "prefix-delegation" in the other modules?

    grouping message-statistics {

The relay module has a counter for discarded messages; should we?

    grouping option-request-option-group {
      description
        "OPTION_ORO (6) Option Request Option. A client MUST include
        an Option Request option in a Solicit, Request, Renew,
            Rebind, or Information-request message to inform the server
              about options the client wants the server to send to the
              client.";

If I understand correctly, there are further MUST-level requirements for
what options must be present in the ORO.  E.g., INFORMATION_REFRESH_TIME
is required in Information-Request.  Do we want to mention that here?
Are there any considerations for how that requirement interacts with the
values configured by YANG?  E.g., do we expect implementations to
forcibly add those required options on top of the configured ones, in
scenarios where they are required?

    grouping user-class-option-group {
      [...]
          leaf user-class-data {
            type string;
            description
              "Opaque field representing a User Class
              of which the client is a member.";

I think this would be better as YANG binary than string.  If we keep it
as string, we need to say what encoding is used.

      container vendor-class-option {
        [...]
        list vendor-class-option-instances {
        [...]
          list vendor-class-data-element {
            [...]
            leaf vendor-class-data {
              type string;
              description
                "Opaque field representing a vendor class of which
                the client is a member.";

(likewise here)

      leaf client-duid {
        if-feature "non-temp-addr or prefix-del " +
          "or temp-addr and not anon-profile";

Does the default YANG operator precedence do what we want with respect
to ((non-temp-addr or prefix-del or temp-addr) and not anon-profile) vs
(non-temp-addr or prefix-del or (temp-addr and not anon-profile))?
From the context in the rest of the document, it's clear that we want
the former, but I'm not familiar enough with YANG minutiae to say if
that's what we actually are specifying.

    notification invalid-ia-address-detected {
      if-feature "non-temp-addr or temp-addr";
      [...]
      leaf ia-id {
        type uint32;
        mandatory true;
        description
          "IA-ID";

If I understand correctly, in DHCP the IA-ID is scoped per client DUID.
Does this notification convey enough information to disambiguate what
scope this IA-ID value belongs to?

      [...]
      leaf ia-na-t1-timer {
        type uint32;
        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).";

Should these two be here without a feature conditional?  They seem to be
NA-specific but we could send this notification if NA is not
implemented.

    notification transmission-failed {
        [...]
      leaf failure-type {
        type enumeration {

(side note?) I get antsy about not leaving an extension point for other
types of (re)transmission failure, but I also don't have any specific
scenario in mind that's not already covered, so.

    notification unsuccessful-status-code {
      description
        "Notification sent when the client receives a message that
        includes an unsuccessful Status Code option.";

As for the other notifications on failure, is this a potential DoS
vector?

Section 5

It's probably worth mentioning the risk of notifications turning into a
DoS vector (absent rate-limiting) here.

Can a misconfigured client cause problems for a (honest) server, e.g.,
by sending a lot of requests for a lot of things, very quickly?

  All data nodes defined in the YANG modules which can be created,
  modified, and deleted (i.e., config true, which is the default) are
  considered sensitive.  Write operations (e.g., edit-config) to these
  data nodes without proper protection can have a negative effect on
  network operations.

Do we want to go further and give some broad treatment of how the
negative effects would come about (e.g., by disrupting address
allocation and the routability of addresses/prefixes that clients
attempt to use)?

  An attacker with read/write access the DHCPv6 relay can undertake
  various attacks, such as:

  *  Modifying the relay's "destination-address" to send messages to a
      rogue DHCPv6 server.

  *  Deleting information about a client's delegated prefix, causing a
      denial of service attack as traffic will no longer be routed to
      the client.

I'd considering reiterating the "full denial of service" capability
(which is currently implicit in "send messages to a rouge DHCPv6 server"
combined with the list of attacks that a compromised server can
undertake).

  Some of the readable data nodes in this YANG module may be considered
  sensitive or vulnerable in some network environments.  Therefore, it
  is important to control read access (e.g., only permitting get, get-
  config, or notifications) to these data nodes.  These subtrees and
  data nodes can be misused to track the activity of a host:

First off, thank you for stating this consideration so clearly.

Second, there may be an additional consideration for read-only access --
knowledge of what pools of addresses are available for allocation might
facilitate network reconaissance (viz. RFC 7707).

  [RFC7824] covers privacy considerations for DHCPv6 and is applicable
  here.

I'd suggest mentioning the RFC 7844 privacy profile as a partial
mitigation that is sometimes applicable.

Section 9.2

RFC 8987 is used as in a few YANG reference stanzas, but is not
mentioned in the preface before the containing YANG module.  It could
arguably be classified as normative based on that usage.

Appendix D

        case user-class-option-id {
          description
            "Client class selection based on the value of the
            OPTION_USER_CLASS(15) and its user-class-data field.";
          leaf user-class-data {
            type string;
            mandatory true;
            description
              "Value of the enterprise-number field.";

This description doesn't look right.

NITS

We might check the spelling of "grouping message-stats" (vs "grouping
message-statistics") across modules.

Section 4.2

      leaf rapid-commit {
        type boolean;
        description
          "When set to 'true', Specifies that the pool supports
          client-server exchanges involving two messages.";

This is in the "grouping resource-config" that may or may not be used
within a "pool" container.  A more generic phrasing might be in order.

    grouping sol-max-rt-option-group {
      [...]
        leaf sol-max-rt-value {
          type dhc6:timer-seconds32;
          description
            "sol max rt value";

That's a pretty sparse description.

    grouping inf-max-rt-option-group {
      [...]
        leaf inf-max-rt-value {
          type dhc6:timer-seconds32;
          description
            "inf max rt value";

(ditto)

              leaf max-address-utilization {
                type dhc6:threshold;
                description
                  "Maximum amount of the addresses in the
                  pool which can be simultaneously allocated,
                  calculated as a percentage of the available
                  addresses (end-address minus start-address plus
                  one).";

The analogous prefix-allocation node has "rounded up" stated
explicitly.  Should we do so here as well?

Section 4.3

      leaf reply-sent-count {
        type uint32;
        config "false";
        description
          "Number of Reply (7) messages received.";
      }
      leaf release-received-count {
        type uint32;
        config "false";
        description
          "Number of Release (8) messages sent.";
      }
      leaf decline-received-count {
        type uint32;
        config "false";
        description
          "Number of Decline (9) messages sent.";

The descriptions seem out of sync about sent vs received, here.

Section 5

  As the RPCs for deleting/clearing active address and prefix entries
  in the server and relay modules are particularly sensitive, these use
  'nacm:default-deny-all'.

This looks like a comma splice.

  An attacker with read/write access the DHCPv6 server can undertake
  various attacks, such as:
  [...]
  An attacker with read/write access the DHCPv6 relay can undertake
  various attacks, such as:

s/access/access to/

  Some of the readable data nodes in this YANG module may be considered
  sensitive or vulnerable in some network environments.  Therefore, it
  is important to control read access (e.g., only permitting get, get-
  config, or notifications) to these data nodes.  These subtrees and

This doesn't match the template at
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines , where the
parenthetical is "(e.g., via get, get-config, or notification)" -- the
meaning is different!

Appendix A.1

  The 'max-pd-space-utilization' is set to 80 so that a 'prefix-pool-
  utilization-threshold-exceeded' notification will be raised if the
  number of prefix allocations exceeds this.

the max-pd-space-utilitization is a percentage, so the "number of prefix
allocations" needs a unit conversion to be comparable to it.

Appendix C

        container lease-storage {
          description
            "Configures how the server will stores leases.";
          choice storage-type {
            description
              "The type storage that will be used for lease
              information.";

s/type storage/type of storage/

            case mysql {
              leaf mysql-name {
                type string;
                description
                  "Name of the database.";
              }
              [...]

This seems to not have provision for configuring mandatory TLS usage for
connection to the mysql server.
(Same for the postgres case.)

              leaf mysql-port {
                type inet:port-number;
                default 5432;

mysql's registered port seems to be 3306 (5432 is assigned for
postgres).

Appendix D

  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.

s/example/example of/

    grouping client-class-id {
      description
        "Definitions of client message classification for
        authorization and assignment purposes.";
      leaf client-class-name {
        type string;
        description
          "Unique Identifier for client class identification list
          entries.";

Shouldn't this be mandatory if it's going to be the only way we refer to
class IDs?  I guess the grouping is currently only used in one place,
and it's a list key there (so implicitly mandatory), but I still wonder
if the grouping is more reusable with "mandatory true".

          leaf relay-interface {
            type string;
            description
              "Reference to the interface entry for the incoming
              DHCPv6 message.";

Whatever we do in the main module for the encoding of the interface
entry should be reflected here as well.

            leaf vendor-class-data {
              type string;
              mandatory true;
              description
                "Vendor class data to match.";

(likewise)

            leaf remote-id {
              type string;
              mandatory true;
              description
                "Remote-ID data to match.";

(and here)

[Ballot comment]
Thank you to Vincent Roca for the SECDIR review.

** (Editorial) Regex constraining hex strings.  When I first read the pattern constraining typedef duid-base (and the same is true in other places), I didn’t appreciate that this regex was operating on a string containing a hex representation of octets.

** There are a few places in the three yang modules where it appears that human-readable messages are being returned.  What is the expected approach (if any) for conveying a language tag per the guidance in Section 4.2 of BCP18?  An incomplete list of these places are:

-- Section 4.1. grouping status and status-code-option-group has a leaf message

-- Section 4.2. rpc delete-address-lease and delete-prefix-lease return a leaf return-message

-- Section 4.3. leaf return-message in the rpcs

** Section 4.1. grouping status has a leaf message which is explicitly described as of “type string” and is clarified as being a “UTF-8 encoded string ... that isn’t null-terminated”.  No issues with that guidance.  I’m wonder whether the other strings mentioned in the previous comment should also be described in this way.

** Section 5.  Additionally threats to document would be:

-- Generalize the threat of redirecting clients to services under the attackers’ control (e.g., DNS server or WPAP).  Say:

OLD
* Various attacks based on re-configuring the contents of DHCPv6
      options, leading to several types of security or privacy threats.
      For example, changing the address of a DNS server supplied in a
      DHCP option to point to a rogue server.

NEW
* Various attacks based on re-configuring the contents of DHCPv6 options, leading to several types of security or privacy threats.  These options could redirect clients to services under an attacker’s control. For example, changing the address of a DNS server supplied in a DHCP option to point to a rogue server.

-- Ability to read the leases from the Server or Relay could help the attacker fingerprint device types.

OLD
These subtrees and
  data nodes can be misused to track the activity of a host:

NEW
These subtrees and data nodes can be misused to track the activity or fingerprint the device type of the host:

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dhc-dhcpv6-yang-23. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

four, new namespaces will be registered as follows:

ID: yang:ietf-dhcpv6-server
URI: urn:ietf:params:xml:ns:yang:ietf-dhcpv6-server
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-dhcpv6-relay
URI: urn:ietf:params:xml:ns:yang:ietf-dhcpv6-relay
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-dhcpv6-client
URI: urn:ietf:params:xml:ns:yang:ietf-dhcpv6-client
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-dhcpv6-common
URI: urn:ietf:params:xml:ns:yang:ietf-dhcpv6-common
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

four, new YANG modules will be registered as follows:

Name: ietf-dhcpv6-server
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-dhcpv6-server
Prefix: dhc6-srv
Module:
Reference: [ RFC-to-be ]

Name: ietf-dhcpv6-relay
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-dhcpv6-relay
Prefix: dhc6-rly
Module:
Reference: [ RFC-to-be ]

Name: ietf-dhcpv6-client
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-dhcpv6-client
Prefix: dhc6-clnt
Module:
Reference: [ RFC-to-be ]

Name: ietf-dhcpv6-common
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-dhcpv6-common
Prefix: dhc6
Module:
Reference: [ RFC-to-be ]

While the YANG module names will be registered after the IESG approves the document, the YANG module files will be posted after the RFC Editor notifies us that the document has been published.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-11-15):

From: The IESG
To: IETF-Announce
CC: Timothy Winters , dhc-chairs@ietf.org, dhcwg@ietf.org, draft-ietf-dhc-dhcpv6-yang@ietf.org, evyncke@cisco.com, tim@qacafe.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (YANG Data Model for DHCPv6 Configuration) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG (dhc)
to consider the following document: - 'YANG Data Model for DHCPv6
Configuration'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-11-15. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes YANG data modules for the configuration and
  management of DHCPv6 (Dynamic Host Configuration Protocol for IPv6
  RFC8415) servers, relays, and clients.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

    This write-up is based on draft-ietf-dhc-dhcpv6-yang-22.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

    The RFC requested is Proposed Standard. And, this is appropriate for this
    document as it defines YANG modules for the configuration and management of
    DHCPv6 elements for use in NETCONF and RESTCONF.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This memo describes YANG data modules for the configuration and
  management of DHCPv6 (Dynamic Host Configuration Protocol for IPv6)
  servers, relays, and clients.


Working Group Summary:

  This document had review for the DHC Working Group, in particular Tom Petch
  has reviewed several versions of this document during the process.  Most of the
  discussion was about how to break up the modules to work for client, server, and
  relay.  Tom did several passes on the document during the process. 

Document Quality:

  The document was reviewed by a couple of members of the DHC working group.  It
  was also sent to a YANG Doctor (Acee Lindem) for early review.  During the YANG Review,
  the document was marked an On the Right Track. The authors have implemented the changes
  recommended by the review, with some additional comments from DHC Working Group members.

  Implementations of the DHCPv6 client module are available at: https://github.com/telekom/sysrepo-plugin-interfaces/tree/dhcpv6-client
  Server (based on the modules from -12 of the draft): https://github.com/telekom/dt-kea-netconf

Personnel:

    Timothy Winters is the Document Shepherd, Éric Vyncke is the Responsible
    Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

    As document shepherd, I reviewed this document to assure that it is following the WG   
    consensus and discussions and is of good quality. In my opinion, the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

    No. The document had review in DHC group and was also reviewed during the
    yang early review process. There was good discussion between a member of DHC
    and the authors of the document on use cases.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
   
    Yes this document received an YANG doctor early review which helped correct some default settings and corrected several minor issues.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

    I have no concerns or issues with any of the material.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

    No, there is no IPR filed against this document and hence there was no IPR
    discussion in the WG.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
   
    This document had strong review by the few individuals that were involved in needing YANG models for DHCP deployments. 
    The silent members of the working group understood the need for YANG model for describing DHCP functions,
    but weren't interested in participating in the process.  There was no indication that anyone disagreed with any of the material.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

    Ran the ID nits, it only commented on potential white space issues that were in the yang models, so no issues.  Read the document and didn't find any errors or formatting issues.   
   


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    This document had an early Yang doctor review. 
    https://datatracker.ietf.org/doc/review-ietf-dhc-dhcpv6-yang-19-yangdoctors-early-lindem-2021-05-05/


(13) Have all references within this document been identified as either normative or informative?

Yes, every reference that I located had a valid reference. 


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document has a IANA considerations sections, that updated the proper registries for both YANG and XML.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A


(19) Describe reviews and automated checks performed by those Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Yang Validation runs without any issues on 2021-09-13.


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

It did run with the YANG validation tool and no issues were uncovered.  Yes it complies with RFC8342.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

    This write-up is based on draft-ietf-dhc-dhcpv6-yang-22.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

    The RFC requested is Proposed Standard. And, this is appropriate for this
    document as it defines YANG modules for the configuration and management of
    DHCPv6 elements for use in NETCONF and RESTCONF.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This memo describes YANG data modules for the configuration and
  management of DHCPv6 (Dynamic Host Configuration Protocol for IPv6)
  servers, relays, and clients.


Working Group Summary:

  This document had review for the DHC Working Group, in particular Tom Petch
  has reviewed several versions of this document during the process.  Most of the
  discussion was about how to break up the modules to work for client, server, and
  relay.  Tom did several passes on the document during the process. 

Document Quality:

  The document was reviewed by a couple of members of the DHC working group.  It
  was also sent to a YANG Doctor (Acee Lindem) for early review.  During the YANG Review,
  the document was marked an On the Right Track. The authors have implemented the changes
  recommended by the review, with some additional comments from DHC Working Group members.

  Implementations of the DHCPv6 client module are available at: https://github.com/telekom/sysrepo-plugin-interfaces/tree/dhcpv6-client
  Server (based on the modules from -12 of the draft): https://github.com/telekom/dt-kea-netconf

Personnel:

    Timothy Winters is the Document Shepherd, Éric Vyncke is the Responsible
    Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

    As document shepherd, I reviewed this document to assure that it is following the WG   
    consensus and discussions and is of good quality. In my opinion, the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

    No. The document had review in DHC group and was also reviewed during the
    yang early review process. There was good discussion between a member of DHC
    and the authors of the document on use cases.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
   
    Yes this document received an YANG doctor early review which helped correct some default settings and corrected several minor issues.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

    I have no concerns or issues with any of the material.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

    No, there is no IPR filed against this document and hence there was no IPR
    discussion in the WG.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
   
    This document had strong review by the few individuals that were involved in needing YANG models for DHCP deployments. 
    The silent members of the working group understood the need for YANG model for describing DHCP functions,
    but weren't interested in participating in the process.  There was no indication that anyone disagreed with any of the material.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

    Ran the ID nits, it only commented on potential white space issues that were in the yang models, so no issues.  Read the document and didn't find any errors or formatting issues.   
   


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    This document had an early Yang doctor review. 
    https://datatracker.ietf.org/doc/review-ietf-dhc-dhcpv6-yang-19-yangdoctors-early-lindem-2021-05-05/


(13) Have all references within this document been identified as either normative or informative?

Yes, every reference that I located had a valid reference. 


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document has a IANA considerations sections, that updated the proper registries for both YANG and XML.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A


(19) Describe reviews and automated checks performed by those Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Yang Validation runs without any issues on 2021-09-13.


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

It did run with the YANG validation tool and no issues were uncovered.  Yes it complies with RFC8342.

Changed document external resources from:

['yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-dhcpv6-client@2018-09-04.yang (Yang catalog entry for ietf-dhcpv6-client@2018-09-04.yang)', 'yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-dhcpv6-options@2018-09-04.yang (Yang catalog entry for ietf-dhcpv6-options@2018-09-04.yang)', 'yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-dhcpv6-relay@2018-09-04.yang (Yang catalog entry for ietf-dhcpv6-relay@2018-09-04.yang)', 'yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-dhcpv6-server@2018-09-04.yang (Yang catalog entry for ietf-dhcpv6-server@2018-09-04.yang)', 'yc_entry https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-dhcpv6-types@2018-09-04.yang (Yang catalog entry for ietf-dhcpv6-types@2018-09-04.yang)', 'yc_impact https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-dhcpv6-options@2018-09-04.yang&modules[]=ietf-dhcpv6-types@2018-09-04.yang&modules[]=ietf-dhcpv6-client@2018-09-04.yang&modules[]=ietf-dhcpv6-relay@2018-09-04.yang&modules[]=ietf-dhcpv6-server@2018-09-04.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both (Yang impact analysis for draft-ietf-dhc-dhcpv6-yang)']

to:

Request for posting confirmation emailed to previous authors: Ian Farrer , Linhui Sun , Michal Nowikowski , Sladjana Zechlin , Yong Cui , Zihao He , dhc-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Sladjana Zoric , dhc-chairs@ietf.org, Yong Cui , Ian Farrer , Ted Lemon , Hao Wang , Linhui Sun