Extensions to the Access Control Lists (ACLs) YANG Model
draft-ietf-netmod-acl-extensions-17

[Ballot comment]
I agree with Deb's comments, especially regarding the use of 'reasonably' and 'particular'
and the use of secure transport protocols in the Security Considerations Section.


        In doing so, implementations would optimize the performance of
        matching lists vs multiple rules matching.

I don't believe this is universally true. Making complicated grouping can
actually cause more slowness than having multiple rules. Most DDoSes I
know in this space is from overcomplicated regexps trying to be clever on
matching IPv6.

[Ballot comment]
Thank you to Sean Turner and Linda Dunbar for their secdir reviews:

Section 5, para 2:  Please replace the second (and last sentence) with "The YANG-based management protocols require the use of a secure transport layer such as SSH [RFC4252], TLS [RFC8446], or QUIC [RFC9000].  The YANG-based management protocols also require mutual authentication."

Section 5, para 4:  Please define 'reasonably sensitive or vulnerable' and 'particular sensitivities/vulnerabilities.  Alternatively, delete the words 'reasonably' and 'particular'.

Section 5, para 5:  Perhaps the second to last sentence should say 'The former may result in the exposure of sensitive data, or compromise a device. 

Section 5, para 7:  Please delete the word 'particular'.

[Ballot discuss]
The XSLT of Appendix A.1, A.2 and A.3 imports “iana-yinx.xsl”:

   

Where does this file come from?  The XSLT does not compile without it.

[Ballot comment]
Thank you to Russ Housley for the GENART review.

** Section 6.3.1
  "enum":  Replicates the name from the registry with all spaces
      striped.

How should the text in the parentheses be handled (e.g., “Information Request (Deprecated)”)? 

Appendix A.2 seems to indicate that the content in the parenthesis should be stripped.  Perhaps additional text could be added here that this column is formatted according to the XSLT in Appendix A.1.

This feedback applies to Sections 6.3.2 and 6.3.3 too.

** Section 6.3.1
  "status":  Is included only if a registration has been deprecated or
      obsoleted.  IANA "deprecated" maps to YANG status "deprecated",
      and IANA "obsolete" maps to YANG status "obsolete".
...
  IANA is requested to add this note to "ICMP Type Numbers"
  [IANA-ICMPv4]:
...

[IANA-ICMPv4]
              "ICMP Type Numbers", n.d.,
              .

-- This reference should be normative since it is part of the IANA guidance

-- Shouldn’t the link to “ICMP Type Numbers” be https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-types

-- How does one know an entry is “obsolete” or “deprecated”?  Is it by looking for those strings in the name field?  There are a few that are “deprecated” but not “obsolete”

The same feedback applies to Section 6.3.2 and 6.3.3?

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-netmod-acl-extensions-15
CC @evyncke

Thank you for the work put into this document. It is easy to read and add real value to ACL.

Please find below  some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Lou Berger for the shepherd's write-up including the WG 'limited' interest/consensus and the justification of the intended status.

Other thanks to Tim Wicinski, the Internet directorate reviewer, please consider this int-dir last-call review:
https://datatracker.ietf.org/doc/review-ietf-netmod-acl-extensions-11-intdir-lc-wicinski-2024-11-17/ (status "ready")

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Abstract

s/This document discusses a set of extensions/This document specifies a set of extensions/ after all, its intended status is proposed standard.

### Section 1

Humm... I understand what is meant but this paragraph appears to be self-contradicting `Network operators maintain sets of IP prefixes ... These lists are maintained and manipulated by security expert teams` (suggest adding "of the network operators").

It took me a while to parse `supporting means to easily map to the filtering rules conveyed in messages triggered by these tools is valuable from a network operation standpoint` mainly because the subject of "is valuable" is too long.

### Section 2

In `IP address, IP prefixes,` any reason why the plural form is used for "IP prefixes" ?

### Section 3.2

Where are the names defined in ` A protocol can be identified either by a number (e.g., 17) or a name (e.g., UDP).`

Should the example for aliases be dual-stack ? I.e., having both an IPV6 address and an IPv4 one ? Same comment for section D.1

I was about the ballot a DISCUSS on `beyond just the header information` which header is it ? Layer-2 ? IP ? Based on `identity offset-type` appearing later, I am balloting NoObjection but the clarification should already be in this section.

### Section 3.6

Related to my near-DISCUSS on section 3.2, `data offset` from which start ?

### Section 4

Generic comment: why next-header-set for IPv4 and not protocol-set as in IPv6 as they refer to the same identities ? Or even having protocol subtree to be version agnostic (like TCP), i.e., some operators would probably like to allow protocol == 50 (ESP) on both IPv6 and IPv4.

Like Erik Kline, I think that `identity layer4` for offset is not correct and Erik's suggestion is correct.

`The offset start right after the end of the transport payload.`, I think that the authors mean "transport header".

Rather than defining identities for all TCP flags (e.g., `identity ack`), why not using the same technique as for ICMP type, i.e., rely on the https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-header-flags IANA registry?

### Section 6.3

Several IANA instructions are similar to `"enum": Replicates the name from the registry with all spaces striped.`, I am unsure whether the result will be readable and useful, it there a reason why the spaces must be removed ?

The "(deprecated)" and "(obsolete)" status appears only in the ICMPv4 registry, unsure whether they are applicable to ICMPv6 and extension headers registries. I will trust IANA review on this section.

### Section 7.2

As some IANA registries are used as input by the XSLT in appendix A, I wonder whether they should be normative references.

### Section E.3

Should there also be a match on the 'protocol' ? I.e., do not match for TCP packets having "2001:db8::1"

Moreover, I guess that the payload match is a binary comparison so it will never match the ASCII "2001:db8::1", suggest using an hexadecimal string in this example.


## NITS (non-blocking / cosmetic)

s/transpot/transport/ (saw it at least once)

[Ballot comment]
In 3.2, I found this statement to be confusing, perhaps because of my limited familiarity with YANG: "The port numbers can be individual port numbers, a range of port numbers, and an operation." At the least, I would have expected "or", and I didn't know what "an operation" would represent in the context of port numbers.

This seems to be referencing RFC 8519's `port-range-or-operator` grouping, which allows for a single port number, a range of port numbers, or a combination of a single port number with an operator (which in turn can be `eq`, `neq`, `lte`, or `gte`). Clearer wording and an explicit reference might be helpful here, though I assume the intended audience is already familiar with YANG conventions.

[Ballot comment]
In 3.2, I found this statement to be confusing, perhaps because of my limited familiarity with YANG: "The port numbers can be individual port numbers, a range of port numbers, and an operation."

This seems to be referencing RFC 8519's `port-range-or-operator` grouping, which allows for a single port number, a range of port numbers, or a combination of a port number with an operator (which in turn can be `eq`, `neq`, `lte`, or `gte`). Clearer wording and an explicit reference might be helpful here, though I assume the intended audience is already familiar with YANG conventions.

[Ballot comment]
# Internet AD comments for draft-ietf-netmod-acl-extensions-15
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S4

* The `identity layer4` description doesn't address whether IPv6 Extension
  Headers, or other "IP-layer" headers like AH, are to be skipped over or
  not.  I suspect they are, but this description could say explicitly.

  In the spirit of "send text", here's one attempt:

  identity layer4 {
    base offset-type;
    description
      "The offset start right after the IP header and any headers
      pertaining to that IP layer, e.g. IPv6 Extension Headers and the
      Authentication Header (AH). This can be typically the beginning of
      a transport header (e.g., TCP or UDP) or any encapsulation scheme
      over IP such as IP-in-IP.";
  }

  but that's just for your consideration.

* For the `payload` identity and the length in the `payload-match` for
  an `offset` of type `payload`, where is the end of the payload?

  Specifically, does this allow matching into the UDP Options space that
  is beyond the UDP payload but still within the IP payload?

  If the UDP Options space is excluded (or punted until future work), then
  it might be good to have some clarification about that here (we intend
  to include it in the payload match, exclude it, or leave it up to the
  implementer).

* In `payload-match`, the `description` for `operator` reads:

    "How to interpret the prefix match."

  Should that be s/prefix/pattern/?  (this seems like it might be a
  copy-paste error?)

* Not important for this document, but we should probably consider whether
  it should be good practice to include SCTP and maybe DCCP, even if it's
  only for the port set ACL definitions and nothing fancier.

  Just a comment, not a request for any change.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-netmod-acl-extensions-13. If any part of this review is inaccurate, please let us know.

IANA has a question about some of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are eleven actions which we must complete.

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

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

four new namespaces will be registered as follows:

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

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

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

ID: yang:iana-ipv6-ext-types
URI: urn:ietf:params:xml:ns:yang:iana-ipv6-ext-types
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

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

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

four new YANG modules will be registered as follows:

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

Name: iana-icmpv4-types
File: [ TBD-at-Registration ]
Maintained by IANA? Y
Namespace: urn:ietf:params:xml:ns:yang:iana-icmpv4-types
Prefix: iana-icmpv4-types
Module:
Reference: [ RFC-to-be ]

Name: iana-icmpv6-types
File: [ TBD-at-Registration ]
Maintained by IANA? Y
Namespace: urn:ietf:params:xml:ns:yang:iana-icmpv6-types
Prefix: iana-icmpv6-types
Module:
Reference: [ RFC-to-be ]

Name: iana-ipv6-ext-types
File: [ TBD-at-Registration ]
Maintained by IANA? Y
Namespace: urn:ietf:params:xml:ns:yang:iana-ipv6-ext-types
Prefix: iana-ipv6-ext-types
Module:
Reference: [ RFC-to-be ]

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

Third, IANA will create a new registry under the YANG Modules group located at:

https://www.iana.org/protocols

the new registry will be named:

iana-icmpv4-types YANG Module

and will contain the the initial version of the IANA-maintained "iana-icmpv4-types" YANG module.

Fourth, the following note will be added to the YANG Parameters registry group located at:

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

New values must not be directly added to the "iana-icmpv4-types" YANG module. They must instead be added to the "ICMP Type Numbers" registry located at:

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

IANA Question --> In section 6.3.1 of the current draft, the authors require that when a value is added to the "ICMP Type Numbers" registry, a new "enum" statement must be added to the "iana-icmpv4-types" YANG module. Is that guidance for future document authors, or is that a request for IANA to add the enum statements? If it is a request for IANA to modify the YANG module, what, in a future document, would be the trigger for IANA action?

Fifth, in the ICMP Type Numbers registry in the Internet Control Message Protocol (ICMP) Parameters registry group located at:

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

a new note will be added to the registry as follows:

When this registry is modified, the YANG module "iana-icmpv4-types" [YANG_URL] must be updated as defined in [ RFC-to-be ].

where [YANG_URL] will be the will be the URL that points to the newly created registry from action three above.

The reference for this registry will be changed from:

[RFC2780]

to:

[RFC2780][ RFC-to-be ]

Sixth, IANA will create a new registry under the YANG Modules group located at:

https://www.iana.org/protocols

the new registry will be named:

iana-icmpv6-types YANG Module

and will contain the the initial version of the IANA-maintained "iana-icmpv6-types" YANG module.

Seventh, the following note will be added to the YANG Parameters registry group located at:

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

New values must not be directly added to the "iana-icmpv6-types" YANG module. They must instead be added to the "ICMPv6 "type" Numbers" registry located at:

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

IANA Question --> In section 6.3.2 of the current draft as with section 6.3.1, the authors require that when a value is added to the "ICMPv6 "type" Numbers" registry, a new "enum" statement must be added to the "iana-icmpv4-types" YANG module. Is that guidance for future document authors, or is that a request for IANA to add the enum statements? If it is a request for IANA to modify the YANG module, what, in a future document, would be the trigger for IANA action?

Eighth, in the ICMPv6 "type" Numbers registry in the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry group located at:

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

a new note will be added to the registry as follows:

When this registry is modified, the YANG module "iana-icmpv6-types" [YANG_URL2] must be updated as defined in [ RFC-to-be ].

where [YANG_URL2] will be the will be the URL that points to the newly created registry from action six above.

The reference for this registry will be changed from:

[RFC4443]

to:

[RFC4443][ RFC-to-be ]

Ninth, IANA will create a new registry under the YANG Modules group located at:

https://www.iana.org/protocols

the new registry will be named:

iana-icmpv6-ext-types YANG Module

and will contain the the initial version of the IANA-maintained "iana-icmpv6-ext-types" YANG module.

Tenth, the following note will be added to the YANG Parameters registry group located at:

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

New values must not be directly added to the "iana-icmpv6-ext-types" YANG module. They must instead be added to the "IPv6 Extension Header Types" registry located at:

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

IANA Question --> In section 6.3.3 of the current draft as with section 6.3.2 and 6.3.1, the authors require that when a value is added to the "IPv6 Extension Header Types" registry, a new "enum" statement must be added to the "iana-icmpv4-types" YANG module. Is that guidance for future document authors, or is that a request for IANA to add the enum statements? If it is a request for IANA to modify the YANG module, what, in a future document, would be the trigger for IANA action?

Eleventh, in the IPv6 Extension Header Types registry in the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry group located at:

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

a new note will be added to the registry as follows:

When this registry is modified, the YANG module "iana-icmpv6-ext-types" [YANG_URL3] must be updated as defined in [ RFC-to-be ].

where [YANG_URL3] will be the will be the URL that points to the newly created registry from action nine above.

The reference for this registry will be changed from:

[RFC2780][RFC5237][RFC7045]

to:

[RFC2780][RFC5237][RFC7045][ RFC-to-be ]

We understand 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.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-01-27):

From: The IESG
To: IETF-Announce
CC: draft-ietf-netmod-acl-extensions@ietf.org, lberger@labn.net, mjethanandani@gmail.com, netmod-chairs@ietf.org, netmod@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Extensions to the Access Control Lists (ACLs) YANG Model) to Proposed Standard


The IESG has received a request from the Network Modeling WG (netmod) to
consider the following document: - 'Extensions to the Access Control Lists
(ACLs) YANG Model'
  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 2025-01-27. 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


  RFC 8519 defines a YANG data model for Access Control Lists (ACLs).
  This document discusses a set of extensions that fix many of the
  limitations of the ACL model as initially defined in RFC 8519.

  The document also defines IANA-maintained modules for ICMP types and
  IPv6 extension headers.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-extensions/



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

The authors have addressed the *DIR review comments received, except for SECDIR, which I hope comes soon. They have also addressed the AD review comments. Will, therefore, progress the draft.

Request for Last Call review by YANGDOCTORS Completed: Ready with Issues. Reviewer: Per Andersson. Sent review to list. Submission of review completed at an earlier date.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents strong concurrence of a few individuals -- mainly authors

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

None

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Unknown, no public statements were made WRT implementation.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

While other technologies, such as VLANs, are mentioned. Their usage is not particularly unusual or novel, so no new reviews/liaisons are recommended (by the Shepherd).

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

An YANG Dr early review was conducted and the document was updated accordingly.  A final/LC review is expected to go through without major issues.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

tested using https://www.yangcatalog.org/yangvalidator, no issues reported.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The main YANG model was checked using the above validator tool. XML and json in the appendices was not checked using any tooling (just visual inspection).

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, this document is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The sole issue found during Shepherd review that had not been addressed during LC updates was ID Nits related and these have been addressed in the latest version.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard - this is appropriate given it is defining a YANG model.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, no IPR was disclosed, see https://mailarchive.ietf.org/arch/msg/netmod/feUn3481mywXnGfdd4WCkoj-5Vk/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

It shows warnings with unusual spacing due to yang models - I think this is a NITs issue.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

One could argue that this document updates 8519, but as an extension/augmentation it is not formally such and is so (un) marked.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section was fully reviewed, in the Shepherd's opinion it is unusually well written and comprehensive.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents strong concurrence of a few individuals -- mainly authors

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

None

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Unknown, no public statements were made WRT implementation.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

While other technologies, such as VLANs, are mentioned. Their usage is not particularly unusual or novel, so no new reviews/liaisons are recommended (by the Shepherd).

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

An YANG Dr early review was conducted and the document was updated accordingly.  A final/LC review is expected to go through without major issues.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

tested using https://www.yangcatalog.org/yangvalidator, no issues reported.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The main YANG model was checked using the above validator tool. XML and json in the appendices was not checked using any tooling (just visual inspection).

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, this document is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The sole issue found during Shepherd review that had not been addressed during LC updates was ID Nits related and these have been addressed in the latest version.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard - this is appropriate given it is defining a YANG model.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, no IPR was disclosed, see https://mailarchive.ietf.org/arch/msg/netmod/feUn3481mywXnGfdd4WCkoj-5Vk/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

It shows warnings with unusual spacing due to yang models - I think this is a NITs issue.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

One could argue that this document updates 8519, but as an extension/augmentation it is not formally such and is so (un) marked.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section was fully reviewed, in the Shepherd's opinion it is unusually well written and comprehensive.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents strong concurrence of a few individuals -- mainly authors

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

None

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Unknown, no public statements were made WRT implementation.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

While other technologies, such as VLANs, are mentioned. Their usage is not particularly unusual or novel, so no new reviews/liaisons are recommended (by the Shepherd).

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

An YANG Dr early review was conducted and the document was updated accordingly.  A final/LC review is expected to go through without major issues.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

tested using https://www.yangcatalog.org/yangvalidator, no issues reported.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The main YANG model was checked using the above validator tool. XML and json in the appendices was not checked using any tooling (just visual inspection).

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, this document is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The sole issue found during Shepherd review that had not been addressed during LC updates was ID Nits related and these have been addressed in the latest version.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard - this is appropriate given it is defining a YANG model.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, no IPR was disclosed, see https://mailarchive.ietf.org/arch/msg/netmod/feUn3481mywXnGfdd4WCkoj-5Vk/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Yes, with false positives.(assuming fixes in -11)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No (to be fixed in -11).

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

One could argue that this document updates 8519, but as an extension/augmentation it is not formally such and is so (un) marked.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section was fully reviewed, in the Shepherd's opinion it is unusually well written and comprehensive.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents strong concurrence of a few individuals -- mainly authors

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

None

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Unknown, no public statements were made WRT implementation.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

While other technologies, such as VLANs, are mentioned. Their usage is not particularly unusual or novel, so no new reviews/liaisons are recommended (by the Shepherd).

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

An YANG Dr early review was conducted and the document was updated accordingly.  A final/LC review is expected to go through without major issues.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

tested using https://www.yangcatalog.org/yangvalidator, no issues reported.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The main YANG model was checked using the above validator tool. XML and json in the appendices was not checked using any tooling (just visual inspection).

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, this document is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The sole issue found during Shepherd review that had not been addressed during LC updates was ID Nits related and these have been addressed in the latest version.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard - this is appropriate given it is defining a YANG model.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, no IPR was disclosed, see https://mailarchive.ietf.org/arch/msg/netmod/feUn3481mywXnGfdd4WCkoj-5Vk/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Yes, with false positives.(assuming fixes in -11)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No (to be fixed in -11)

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

One could argue that this document updates 8519, but as an extension/augmentation it is not formally such, and is so (un) marked.


20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section was fully reviewed, in the Shepherd's opinion it is unusually well written and comprehensive.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Pre WG LC IPR call complete:
https://mailarchive.ietf.org/arch/msg/netmod/ii7gNmsnQcq07F3G0-dwV7TR4Po/  Thread
https://mailarchive.ietf.org/arch/msg/netmod/u152JYoYj3QB-_8iRbs9Kp0bVAE/  mohamed.boucadair
https://mailarchive.ietf.org/arch/msg/netmod/IX1pBME5ICKBETf_GihUJsDf5oo/  Oscar González de Dios
https://mailarchive.ietf.org/arch/msg/netmod/v2oKJNamsDhrKshFVAiVyXGi0h0/  Samier Barguil Giraldo
https://mailarchive.ietf.org/arch/msg/netmod/tg3fDCvB6hruyjYLeivbq9b_uso/  Qin Wu