Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh
draft-ietf-sidrops-rov-no-rr-08

[Ballot comment]
My thanks to the authors for resolving the discussed issues in version 7.

As per my email to sidrops - I did have a request to ask the authors if they would remove the last sentence of section 5

Specifically:

Such circumstances could include operational work-arounds such as the informed consent of the affected peers.

Based on the fact that section 5 now moves from mandatory MUST's to lower case should's I am ok with removing this sentence, but I will leave that to the authors discretion.  In the mean time I am clearing this discuss.

[Ballot discuss]
Hi Authors,

Thanks for the document, for the most part I find it clear and easy to understand.

I however would like to discuss the following:

If the BGP speaker's equipment has insufficient resources to support
  either of the two proposed options, it MUST NOT be used for Route
  Origin Validation.  The equipment should either be replaced with
  capable equipment or ROV not used.  I.e. the knob in Section 4 should
  only be used in very well known and controlled circumstances.

My concerns with this are two fold - firstly - it's entirely unclear what is meant by "well known and controlled circumstances".

More importantly, I'm concerned that this paragraph as written could lead to a situation that where people read this as "if you can't support this behavior - forget BGP security" - and that I would think would be a more dangerous situation than the route refresh behavior.

I'd be happier if we could
a.) Either say that operators should plan for upgrades - but turn off RPKI in the meantime
or
b.) Change the wording such that it says something along the lines of "it MUST not be used for ROV without the informed consent of the peers" - meaning that peer that takes the brunt of the refreshes has to consent explicitly.

Either option prevents the position where operators running smaller older hardware are handed an excuse to forgo RPKI entirely - or to turn it off - because in my experience once someone turns something off, getting them to turn it back on again, can be a tricky proposition.

Let's discuss!

Thanks

Andrew

[Ballot comment]
Hi,

I found this document pretty easy to read, so thank you for that.  Here are some comments that might improve the document, that perhaps you may have already addressed:

1.
  but on the order of
  the in-degree of ROV implementing BGP speakers.

Being ignorant, I didn't know what "in-degree" meant before I looked it up.  Possibly, clarifying here would be beneficial.

2.
  As storing these paths could cause problems in resource constrained
  devices, there MUST be a knob allowing operator control of this
  feature.  Such a knob MUST NOT be per peer, as this could cause
  inconsistent behavior.

I would suggest that you use text like "config setting" rather than "knob".  I think that it would be useful to understand whether there is any IETF YANG configuration module to control this behaviour, either existing, or in the works.

3.
  Such a knob MUST NOT be per peer, as this could cause
  inconsistent behavior.

Would this necessarily give inconsistent behaviour?  Wouldn't it just mean that it would always need to resync against some BGP peers, but not others?  It feels quite prescriptive for an RFC to be banning more granular configuration options.

4.
  Operators deploying ROV and/or other RPKI based policies SHOULD
  ensure that the BGP speaker implementation is not causing unnecessary
  Route Refresh requests to neighbors.
 
Given these are "unnecessary Route Refresh", I was wondering why this couldn't be a MUST rather than a SHOULD.

5.
  If the BGP speaker has insufficient resources to support either of
  the two proposed options,
 
It was not 100% clear to me what the two proposed options are, I'm presuming that it is: "BGP Speakers MUST either keep the full Adj-RIB-In or implement the specification in Section 4.", but perhaps worth considering if this could be made clearer.

Regards,
Rob

[Ballot discuss]
This should be easy to resolve, but it's a necessary process check:  The shepherd writeup says this is going for Internet Standard status, but the other metadata and the document itself seems to be set for Proposed Standard.  Which is right?  I believe there are other incantations that have to be done if the former is true.

[Ballot comment]
In addition to being confusing in terms of what status is being sought for this document, question 11 on the shepherd writeup was not fully answered.

I think Section 7 should either be more than just the word "None" (e.g., "This document specifies no actions for IANA."), or it should state that the section should be removed prior to publication.

[Ballot discuss]
I'm strongly in favor of this work and glad to see it here.  I do
want to DISCUSS Section 4, though.  I apologize for not having
reviewed and commented on this section before now.

My concern can be summed up as, some of the language of Section 4 while
well-intentioned, can mislead the reader into thinking it's fine to
continue sending Route Refreshes after all.  If you could take a swing
at reorganizing it to mitigate that, it would be great. The most notable
example of a place where the reader could be misled is the third
paragraph, which has the clause "... MUST issue a route refresh".  I
think you are probably meaning to say that such a route refresh would be
a natural consequence of not following this spec (and not saving the
ineligible routes) -- but by using the 2119 keyword you create a
different expectation.

Please let me know if you want to talk this through in more detail.

[Ballot discuss]
I'm strongly in favor of this work and glad to see it here.  I do
want to DISCUSS Section 4, though.  I apologize for not having
reviewed and commented on this section before now.

My concern can be summed up as, some of the language of Section 4
while well-intentioned, can mislead the reader into thinking it's
fine to continue sending Route Refreshes after all.  If you could
see your way clear to taking a swing at reorganizing it to
mitigate that, it would be great.  The most notable example of
a place where the reader could be misled is the third paragraph,
which has the clause "... MUST issue a route refresh".  I think
you are probably meaning to say that such a route refresh would
be a natural consequence of not following this spec (and not saving
the ineligible routes) -- but by using the 2119 keyword you
create a different expectation.

Please let me know if you want to talk this through in more detail.

[Ballot comment]
1. I think this paragraph in Section 4 strays into dictating
implementation internals, and so is unsuitable for a protocol spec:

  Policy which may drop routes due to RPKI-based checks such as ROV,
  ASPA, BGPsec [RFC8205], etc.  MUST be run, and the dropped routes
  saved per the above paragraph, before non-RPKI policies are run, as
  the latter may change path attributes.

It's probably harmless to an experienced BGP implementor, so I'm not
going to die on this hill.

2. Can someone please update the replaced-by information to get
draft-ymbk-sidrops-rov-no-rr into the document history?  I had
to dig for it.

Nits:

- s/equiptment/equipment/
- s/equipement/equipment/

[Ballot comment]
Thank you to Mališa Vučinić for the SECDIR review.

** Abstract.  Expand ROV on first use.

** Abstract.  The text already describes the updates to RFC8481:
  This
  document updates RFC8481 by describing how to avoid doing so by
  either keeping a full Adj-RIB-In or saving paths dropped due to ROV
  so they may be reevaluated with respect to new RPKI data.

-- This text in the abstract isn’t repeated anywhere else in the body of the text.

-- Per the text in Section 5, it also appears that RFC8481 is also updated in the following way: “Conformance to this behavior is a additional, mandatory capability for BGP speakers performing ROV” (or something to that effect).

** Section 3.  Typo. s/aginst/against/

** Section 5.
  Operators deploying ROV and/or other RPKI based policies SHOULD
  ensure that the BGP speaker implementation is not causing unnecessary
  Route Refresh requests to neighbors.

Is there any qualification on what constitutes “unnecessary Route Refresh requests”?  Is it any behavior that does not conform to this document?

[Ballot comment]
# GEN AD review of draft-ietf-sidrops-rov-no-rr-03

CC @larseggert

Thanks to Paul Kyzivat for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/Qhb_8-Kc5e5QEE47En6NhULHnjI).

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

### Typos

#### Section 3, paragraph 1
```
-    the received paths aginst the new data.
+    the received paths against the new data.
+                        +
```

### Grammar/style

#### Paragraph 0
```
metadata for this document indicated a intended status of "Internet Standar
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 1, paragraph 1
```
k paths affected by RPKI-based policy so Route Refresh is no longer needed.
                                    ^^^
```
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

#### Section 4, paragraph 1
```
s, then it MUST issue a route refresh so those alternatives may be evaluated
                                    ^^^
```
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

## 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

[Ballot discuss]
# GEN AD review of draft-ietf-sidrops-rov-no-rr-03

CC @larseggert

Thanks to Paul Kyzivat for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/Qhb_8-Kc5e5QEE47En6NhULHnjI).

## Discuss

### Unclear RFC status
```
  Intended status: Standards Track                            Arrcus, Inc.
```
The datatracker metadata for this document indicated a intended status of
"Internet Standard". I assume this is incorrect and needs to be changed
(probably to "Proposed Standard".)

[Ballot comment]
## 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.

### Typos

#### Section 3, paragraph 1
```
-    the received paths aginst the new data.
+    the received paths against the new data.
+                        +
```

### Grammar/style

#### Paragraph 0
```
metadata for this document indicated a intended status of "Internet Standar
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 1, paragraph 1
```
k paths affected by RPKI-based policy so Route Refresh is no longer needed.
                                    ^^^
```
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

#### Section 4, paragraph 1
```
s, then it MUST issue a route refresh so those alternatives may be evaluated
                                    ^^^
```
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

## 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

[Ballot discuss]
(1) [I'm raising this point to be a discussion -- it may not end with changes to the document.]

This document recommends that route refresh not be used when inbound policies change at a relatively high rate.  ROV validation is "only" an example.

As Jeff Haas wrote on the idr list [1]:

  This isn't any different than any other over-aggressive
  provisioning tool's impact. 


Was there any consideration given to making a general recommendation and not just limiting it to ROV?  I can see the direct impact on rfc6811/rfc8481, and how general BGP advice is out of scope for sidrops.  However, I am primarily curious whether there is anything particular to ROV to focus the recommendation this way.  I couldn't find a related discussion (beyond Jeff's message) in the archive, but I may have missed it.


[1] https://mailarchive.ietf.org/arch/msg/idr/F3w0RDyv9dK4w15fzuDZx3P4Jw0



(2) I have a couple of issues with this paragraph from §4.  Addressing them should be relatively easy:

  When RPKI data cause one or more paths to be dropped due to ROV,
  those paths MUST NOT be evaluated for best path, but MUST be saved
  (either separately or marked) so they may be reevaluated with respect
  to new RPKI data.

(2a) "paths to be dropped due to ROV, those paths MUST NOT be evaluated for best path"

Neither rfc6811 nor rfc8481 require that routes be "dropped due to ROV".  rfc8481 requires that "Absent specific operator configuration, policy MUST NOT be applied."

Please clarify that the trigger above ("dropped due to ROV") is defined by the operator and is not just a result of ROV.


(b) "MUST be saved (either separately or marked)"

For a required action, the description is not clear.  For starters, "marked" how?  Separately where?

From §1.1/rfc4271:

  The Adj-RIBs-In contains unprocessed routing information that has
  been advertised to the local BGP speaker by its peers.

The RIB structures in rfc4271 are conceptual -- but since this document requires keeping information (presumably in the Adj-RIB-In), please be more specific about where and marked how.



(3) The following requirement from §5 is outside the scope of this document:

  If the BGP speaker has insufficient resources to support either of
  the two proposed options, it MUST NOT be used for Route Origin
  Validation.  I.e. the knob in Section 4 should only be used in very
  well known and controlled circumstances.

Requiring a node not to be used for ROV is a powerful statement.  It basically invalidates the base operation specified on rfc6811/rfc8481 by always requiring the mechanism in this document.  While I understand the potential resource demands, selecting a node to perform a specific operation in a particular operator's network is outside the scope of this document.

Instead, I would like to see guidance to the operator to consider not using the specific piece of equipment to perform a particular function.  This can be as easy as:

    If the BGP speaker has insufficient resources to support either
    of the two proposed options, the operator is strongly encouraged
    to consider an alternate piece of equipment to perform Route Origin
    Validation.


The second part of the sentence ("I.e. ...") sounds like a better recommendation -- and, clearly, not the same as "MUST NOT be used".

[Ballot comment]
(1) This document should be tagged as replacing draft-ymbk-sidrops-rov-no-rr.

(2) Expand ROV on first use.

(3) rfc4271 doesn't talk about a "best path" -- it does talk about a Decision Process that results in a best route (or ineligible routes).  Please be consistent with existing terminology.

(3) The reference to route-refresh should include rfc2918.

(4) §4: s/there MUST be a knob allowing operator control of this feature.  Such a knob MUST NOT be per peer, as this could cause inconsistent behavior./an implementation MUST provide a global mechanism to control the operation.

A knob makes me think of the CLI -- I'm sure you want the possibility to control the behavior in other ways: YANG, etc..

(5) §5: "Operators...SHOULD ensure that the BGP speaker implementation is not causing unnecessary Route Refresh requests to neighbors."

What is the interoperability-related requirement with "ensuring" that makes Normative language needed?  What does "ensure" entail?  When is it ok for the operator to not "ensure"?  Why is this action only recommended and not required?  After all, eliminating unnecessary route refresh requests is the purpose of this document.

There's a similar phrase later on without Normative language.

s/SHOULD/should

(6) §5: "the operator SHOULD enable the vendor's knob"

Same questions as above:  Why is Normative language needed here?  When is it ok to not enable the functionality?  Why is this action recommended and not required?  ...


(7) §5: "Pre-policy filtering...SHOULD be used to reduce this exposure."

When is it ok to not use pre-policy filtering?  Why is this action recommended and not required?


(8) rfc6811 and rfc8481 should be Normative references.


(9) s/(IXPs)which/(IXPs) which

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

The IANA Functions Operator has reviewed draft-ietf-sidrops-rov-no-rr-03, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

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

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-08-02):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sidrops-rov-no-rr@ietf.org, morrowc@ops-netman.net, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (RPKI-Based Policy Without Route Refresh) to Internet Standard


The IESG has received a request from the SIDR Operations WG (sidrops) to
consider the following document: - 'RPKI-Based Policy Without Route Refresh'
  as Internet 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-08-02. 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


  A BGP Speaker performing RPKI-based policy should not issue Route
  Refresh to its neighbors because it has received new RPKI data.  This
  document updates RFC8481 by describing how to avoid doing so by
  either keeping a full Adj-RIB-In or saving paths dropped due to ROV
  so they may be reevaluated with respect to new RPKI data.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rov-no-rr/



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7313: Enhanced Route Refresh Capability for BGP-4 (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc4271: A Border Gateway Protocol 4 (BGP-4) (Draft Standard - Internet Engineering Task Force (IETF))

# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup to give helpful context to Last Call and
Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in
completing it, is appreciated. The full role of the shepherd is further
described in [RFC 4858][2], and informally. You will need the cooperation of
authors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

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

Consensus achieved on document.

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

No controversy

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

Nope

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

N/A

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

Do not believe so.

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.

N/A

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

Nope.

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.

None required.

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

I believe this document is clear and concise.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

Nope


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

Internet Standard

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

Yes, no IPR claims claimed at claiming time.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

Yes

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

"  -- The draft header indicates that this document updates RFC8481, but the
    abstract doesn't seem to mention this, which it should."

This will be caught up in the next revision that includes iesg/etc commentary/replies.

15. Should any informative references be normative or vice-versa?

Nope!

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

N/A

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

N/A

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

N/A

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.

Should mark an update to RFC8481.

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][12]).

There are no proposed updates for IANA.

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://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup to give helpful context to Last Call and
Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in
completing it, is appreciated. The full role of the shepherd is further
described in [RFC 4858][2], and informally. You will need the cooperation of
authors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

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

Consensus achieved on document.

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

No controversy

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

Nope

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

N/A

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

Do not believe so.

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.

N/A

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

Nope.

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.

None required.

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

I believe this document is clear and concise.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

Nope


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

Internet Standard

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

Yes, no IPR claims claimed at claiming time.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

Yes

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

"  -- The draft header indicates that this document updates RFC8481, but the
    abstract doesn't seem to mention this, which it should."

This will be caught up in the next revision that includes iesg/etc commentary/replies.

15. Should any informative references be normative or vice-versa?

Nope!

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

N/A

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

N/A

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

N/A

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.

Should mark an update to RFC8481.

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][12]).

There are no proposed updates for IANA.

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://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html