OSPF Reverse Metric
draft-ietf-lsr-ospf-reverse-metric-13

[Ballot comment]
Apologies for being late to the party.  Just a few things to add beyond the feedback my colleagues have already provided:

The first sentence in Section 2.2 uses the phrase "toward the core" three times.  Seems like it could do with some common factoring.

There's a SHOULD at the bottom of Section 6.  Why's it only a SHOULD?  When might an implementer legitimately decide to do something else?

In Section 9, I suggest making it explicit that you're talking about the "Link Local Signalling TLV Identifiers" registry in the "Open Shortest Path First (OSPF) Link Local Signalling (LLS) - Type/Length/Value Identifiers (TLV)" registry group.

[Ballot comment]
Thanks for handling by DISCUSS.

I understand you and Alvaro are working on the details, but I'll be satisfied with the outcome of that.

***

A "don't be stupid" warning in 2.2 certainly wouldn't hurt, either.

[Ballot discuss]
Thanks for this document.

I support Alvaro's discuss.  Having read Alvaro's discuss after writing my ballot comments it seems to be some what closely related, but I am also balloting discuss because I find the operational guidelines to be unclear.

(1) p 8, sec 7.  Operational Guidelines                                                                                                                                                                                                                     
                                                                                                                                                                                                                                                           
  Implementations MUST NOT signal reverse metric to neighbors by                                                                                                                                                                                           
  default and MUST provide a configuration option to enable the                                                                                                                                                                                           
  signaling of reverse metric on specific links.  Implementations                                                                                                                                                                                         
  SHOULD NOT accept the RM from its neighbors by default and SHOULD                                                                                                                                                                                       
  provide a configuration option to enable the acceptance of the RM                                                                                                                                                                                       
  from neighbors on specific links.  This is to safeguard against                                                                                                                                                                                         
  inadvertent use of RM.                                                                                                                                                                                                                                   
                                                                                                                                                                                                                                                           
I'm not really sure that I properly understand how this feature works from a manageability perspective.  Particularly for your first use case, when considering that the proposal is for per link configuration for the acceptance of RM from neighbours.  This would seem to suggest that before you can make use of reverse-metric you have to already have determined the links on the affected devices to then configure them to accept the reverse-metrics, at which point, doesn't this partially defeat the use case?  Or is the main goal to simplify the coordination of changing the metric at both ends of the link at the same time?                                                                                                                                       

Or is the intention that during the maintenance window the operators would enable the "allow receipt of reverse-metrics" on all links within, say, an area?  If so, would hierarchical device and area specific configuration be more appropriate?  E.g., allow it to be enabled/disbaled on individual links, but also allow more coarse grained configuration.

Not as an update for this document, but I am assuming that the LSR working group with eventually update or augment the OSPF YANG module with standard configuration to support this feature.

(2) p 8, sec 7.  Operational Guidelines

  For the use case in Section 2.1, it is RECOMMENDED that the network
  operator limits the period of enablement of the reverse metric
  mechanism to be only the duration of a network maintenance window.

Presumably this isn't feasible when the CE is not managed by the provider?  In this scenario, is the expectation that the configuration to accept reverse-metrics would just be left always enabled on the CE device?  Is this a security concern?

Regards,
Rob

[Ballot discuss]
I am balloting DISCUSS because I believe that the behavior specified in this document is not clear enough.  I think these points should be easy to address.

(1) The main behavior in this document (using the reverse metric) is covered in the following sentences:

§6:
  A router receiving a Hello packet from its neighbor that contains the
  Reverse Metric TLV on a link SHOULD use the RM value to derive the
  metric for the link to the advertising router in its Router-LSA...

  ...
  The neighbor SHOULD use the reverse TE metric value...

§7:
  Implementations SHOULD NOT accept the RM from its neighbors by default
  and SHOULD provide a configuration option to enable the acceptance of
  the RM from neighbors on specific links.

For all cases, why is this behavior recommended and not required?  When is it ok to not use the RM, or to accept it by default?



(2) §6:

  A router stops including the Reverse Metric TLV in its Hello packets
  when it needs its neighbors to go back to using their own provisioned
  metric values.  When this happens, a router that had modified its
  metric in response to receiving a Reverse Metric TLV from its
  neighbor should revert to using its provisioned metric value.

No normative language is used here -- should there be a SHOULD/MUST there?

Even if "should revert" is used, the behavior is unclear and could be interpreted as not required.

[Ballot comment]
(0) I support Martin's DISCUSS.

(1) The calculation of the RM is out of scope, according to this text from §6:

  The mechanisms used to determine the value to be used for the
  RM is specific to the implementation and use case and is outside the
  scope of this document.


However, there are 3 occurrences in the same section that indicate requirements when determining the RM:

  *  The RM value that is signaled by a router to its neighbor MUST NOT
      be derived from...

  *  The RM value that is signaled by a router MUST NOT be derived from...

  ...a router MUST never start, stop, or change its RM metric signaling
  based on...


All 3 instances try to avoid a circular dependency on other RMs, which is good.  But normatively requiring that behavior (instead of making suggestions or pointing out the danger) contradicts declaring the mechanism used to derive the RM out of scope.



(2) §6 allows the inclusion of multiple instances of the Reverse Metric TLV (for different topologies).  What should a receiver do if multiple instances are received for the same MTID?

[Ballot discuss]
I hope this is a quick one.

A naive reading of Sec 2.2 implies that a router could generate reverse-metric TLVs quite rapidly, triggering a storm of TLVs from a potentially large number of neighbors. Each reverse metric advertisement generates N LSAs, increasing the amplification of any sort of misconfiguration or misbehavior far more than a traditional LSAs that is updated too often.

At the very least, this ought to come up in security considerations, but I wonder if applying some sort of rate limit (beyond which neighbors are free to ignore) would be a firmer way of limiting the problem. I'm flexible on the best way forward.

[Ballot comment]
Thank you for this document -- I must admit that I find the opportunities that this creates for a: shooting yourself in the foot or b: getting very confused by trying to be too clever with this somewhat scary, but, well, I don't need to use this if I don't want to.

Other than that, it seems like it could be a useful capability for people a: brighter and/or b: braver than me.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-shmoo-hackathon-07
CC @evyncke

Thank you for the work put into this document.

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

Special thanks to Acee Lindem for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. Even, if I cannot really parse `During the WG last call, a number of WG members the draft with the only issue being the predominant use cases.`.

Please note that Wassim Haddad is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well when Wassim will complete the review (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/reviewrequest/16329/

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Abstract

`that receiving neighbor(s) should use for a link to the signaling router` should the neighbor be qualified by "OSPF" ?

More generally about the abstract: it is rather hard to parse and to understand (at least for a native English reader).

### Generic

Should this be "mirrored metric" rather than "reverse metric". I appreciate that this is late in the process, but it sounds clearer.

### Section 1

s/and/or/ in `Open Shortest Path First (OSPFv2) [RFC2328] and OSPFv3 [RFC5340] `?

```
  ... then R2 advertises this value
  as its metric to R1 in its Router-LSA instead of its locally
  configured value. 
```
Suggest to s/in its Router-LSA/in its Router-LSAs to all its OSPF neighbors/

### Section 2.2

s/some point T/some point in time T/ ?

Please expand "CLOS"

### Section 6

` When using multi-topology routing with OSPF [RFC4915],` what about OSPFv3 ?

### Section 7

s/The use of reverse metric signaling does not alter the OSPF metric/The use of *received* reverse metric *signalling* does not alter the OSPF metric/ ?

Rather than `If routers that receive a reverse metric advertisement log an event to notify system administration, `, what about using "It is RECOMMENDED" or a "SHOULD" ?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
# GEN AD review of draft-ietf-lsr-ospf-reverse-metric-08

CC @larseggert

Thanks to Thomas Fossati for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/b581armfQ6xiXV2kBwnoChODULQ).

## Nits

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.

### Grammar/style

#### Section 3, paragraph 1
```
se Metric TLV is a new LLS TLV. It has following format: 0 1
                                      ^^^^^^^^^^^^^^^^
```
The article "the" may be missing.

#### Section 8, paragraph 1
```
edgements The authors would like to thanks Jay Karthik for his contributions
                                ^^^^^^^^^
```
Did you mean "to thank"?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

It looks like there are some agreed changes to reflect IETF LC/directorate review comments, and also the SECDIR minor comments left to respond to? Let’s get a new version posted for those, and then we can schedule this on the next IESG agenda.

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

The IANA Functions Operator has completed its review of draft-ietf-lsr-ospf-reverse-metric-07. If any part of this review is inaccurate, please let us know.

We understand that, upon approval of this document, there is a single action which we must complete.

In the Link Local Signalling TLV Identifiers (LLS Types) registry on the Open Shortest Path First (OSPF) Link Local Signalling (LLS) - Type/Length/Value Identifiers (TLV) registry page located at:

https://www.iana.org/assignments/ospf-lls-tlvs/

two existing temporary registrations will be made permanent and their references changed to [ RFC-to-be ]. The two LLS Types are:

LLS Type: 19
Name: Reverse Metric TLV
Reference: [ RFC-to-be ]

LLS Type: 20
Name: Reverse TE Metric TLV
Reference: [ RFC-to-be ]

We understand that this is the only action 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,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-09-20):

From: The IESG
To: IETF-Announce
CC: acee@cisco.com, chopps@chopps.org, draft-ietf-lsr-ospf-reverse-metric@ietf.org, jgs@juniper.net, lsr-chairs@ietf.org, lsr@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (OSPF Reverse Metric) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'OSPF Reverse Metric'
  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 2022-09-20. 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 specifies the extensions to OSPF that enable a router
  to use link-local signaling to signal the metric that receiving
  neighbor(s) should use for a link to the signaling router.  The
  signaling of this reverse metric, to be used on the link to the
  signaling router, allows a router to influence the amount of traffic
  flowing towards itself and in certain use cases enables routers to
  maintain symmetric metrics on both sides of a link between them.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/



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

(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 Proposed Standard.

Yes - Proposed Standard. This document level is required for protocol extension and interoperability.

(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 document provides extensions to OSPF to support dynamic modification of link metrics by ingress router on the link. In other words, an OSPF router can request an adjacent OSPF router to advertise a higher link metric.

Working Group Summary:

Given that the draft is implementing function already supported for IS-IS with RFC 8500, there wasn't a lot of excitement over the draft. During the WG last call, a number of WG members
the draft with the only issue being the predominant use cases. The draft is generally supported.

Document Quality:

The document describes a relatively simple OSPF extension and is analogous to similar function in IS-IS (RFC 8500). It is of high quality and ready for publication.

Personnel:

Document Shepherd: Acee Lindem
Responsible AD: John Scudder

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

The document shepherd reviewed the document and provided editorial and clarification comments.  The shepherd's review is acknowledged in the draft.

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

No.

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

No.

Matthew Bocci did a Routing Directorate review and only had editorial comments which were addressed.

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

None.

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

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

No.

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

There is general consensus behind the document with nobody objecting publication. One WG participant suggested solving the problem with different encodings, yet this WG member is alone in their opinion and this is frequently the case.

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

The nits have been all fixed.

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

None of these are applicable. The YANG model augmentations will be added in a separate draft.

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

Yes.

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

No.

(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 IANA registration request that have been provided through the early allocation process.

(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 the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

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

N/A

(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 Proposed Standard.

Yes - Proposed Standard. This document level is required for protocol extension and interoperability.

(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 document provides extensions to OSPF to support dynamic modification of link metrics by ingress router on the link. In other words, an OSPF router can request an adjacent OSPF router to advertise a higher link metric.

Working Group Summary:

Given that the draft is implementing function already supported for IS-IS with RFC 8500, there wasn't a lot of excitement over the draft. During the WG last call, a number of WG members
the draft with the only issue being the predominant use cases. The draft is generally supported.

Document Quality:

The document describes a relatively simple OSPF extension and is analogous to similar function in IS-IS (RFC 8500). It is of high quality and ready for publication.

Personnel:

Document Shepherd: Acee Lindem
Responsible AD: John Scudder

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

The document shepherd reviewed the document and provided editorial and clarification comments.  The shepherd's review is acknowledged in the draft.

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

No.

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

No.

Matthew Bocci did a Routing Directorate review and only had editorial comments which were addressed.

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

None.

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

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

No.

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

There is general consensus behind the document with nobody objecting publication. One WG participant suggested solving the problem with different encodings, yet this WG member is alone in their opinion and this is frequently the case.

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

The nits have been all fixed.

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

None of these are applicable. The YANG model augmentations will be added in a separate draft.

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

Yes.

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

No.

(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 IANA registration request that have been provided through the early allocation process.

(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 the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

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

N/A

(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 Proposed Standard.

Yes - Proposed Standard. This document level is required for protocol extension and interoperability.

(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 document provides extensions to OSPF to support dynamic modification of link metrics by ingress router on the link. In other words, an OSPF router can request an adjacent OSPF router to advertise a higher link metric.

Working Group Summary:

Given that the draft is implementing function already supported for IS-IS with RFC 8500, there wasn't a lot of excitement over the draft. During the WG last call, a number of WG members
the draft with the only issue being the predominant use cases. The draft is generally supported.

Document Quality:

The document describes a relatively simple OSPF extension and is analogous to similar function in IS-IS (RFC 8500). It is of high quality and ready for publication.

Personnel:

Document Shepherd: Acee Lindem
Responsible AD: John Scudder

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

The document shepherd reviewed the document and provided editorial and clarification comments.  The shepherd's review is acknowledged in the draft.

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

No.

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

No.

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

None.

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

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

No.

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

There is general consensus behind the document with nobody objecting publication.

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

The nits have been all fixed.

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

None of these are applicable. The YANG model augmentations will be added in a separate draft.

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

Yes.

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

No.

(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 IANA registration request that have been provided through the early allocation process.

(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 the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

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

N/A