DNS Catalog Zones
draft-ietf-dnsop-dns-catalog-zones-09

[Ballot comment]
Thanks for the IANA work (and thus for handling my DISCUSS ballot).

For posterity:

I support Paul Wouters' DISCUSS position.

General:

Could I trouble you for an example of a complete sample catalog zone, perhaps in BIND format, in an appendix?  I can see each individual concept illustrated, but it would be helpful to see them assembled someplace.

Section 3:

"Catalog consumers MUST ignore any RR in the catalog zone which is meaningless to or otherwise not supported by the implementation" seems peculiar.  Wouldn't you do that anyway?

Section 4.1:

Given the text in Section 3 (specifically that a catalog zone follows the same rules as any other zone), is this section needed?  The third paragraph could be its own differently-named section, but the rest seems redundant.

Section 4.2:

The SHOULD at the end leaves implementers with a choice.  Why might an implementer choose to do something other than what it says?  Or should this really be a MUST?

Section 4.3:

It doesn't say anywhere (unless I missed it) that the RRTYPEs of properties are unspecified, and depend on the property.  It might be good to make that explicit, because I kept searching for it.

Section 4.4.1:

Regarding the last paragraph, is there any advice to pass on to operators about how exactly one can tell when the COO is complete?

Section 7:

Why are the protections of zone transfers and updates only SHOULDs?

[Ballot comment]
Thanks for addressing my concerns. I'll leave two non-blocking comments here to consider.

Why must a catalog server / zone only support one version at most? Eg if version "3" comes out that would
add some things, but is backwards compatible with version "2", wouldn't it be useful to be able to have an
RRset of two RRs, showing it supports both version 2 and 3? Why is there a constraint to only allow at most 1
version per catalog zone ?

I find the valid use of the name "invalid" to be pretty horrible. An engineer looking at a catalog might quickly believe
the invalid is a bug where it should have shown a real domain. Why not _catalog.arpa or something ?

[ Note: Process / tooling wonkery ahead... ]

I returned the document to the DNSOP WG on Jan 24 2023. This cleared the "IESG State" field in the datatracker, but did not reset the "WG State" and so the document shows up in a weird state in the Datatracker. This change is purely administrative to make the states align.

[Ballot comment]
Hi,

Thanks for this document.  I'm not an expert on DNS, and hence found it slightly harder to read.

Minor level comments:

(1) p 2, sec 2.  Terminology

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
  "OPTIONAL" in this document are to be interpreted as described in BCP
  14 [RFC2119][RFC8174] when, and only when, they appear in all
  capitals, as shown here.

Is there a reference to generic DNS terminology that could be imported here.  This may aid readers less familiar with DNS.


Nit level comments:

(2) p 12, sec 6.  Implementation and operational Notes

    For example                                                                                                                                                                                                                                                                                                                                                                           
  if the catalog is generated by some script and this script for                                                                                                                                                                                                                                                                                                                           
  whatever reason generates an empty catalog, millions of member zones                                                                                                                                                                                                                                                                                                                     
  may get deleted from their secondaries within seconds and all the                                                                                                                                                                                                                                                                                                                       
  affected domains may be offline in a blink.                                                                                                                                                                                                                                                                                                                                             
                                                                                                                                                                                                                                                                                                                                                                                           
Minor bit, but I would expect the phrase to be "in a blink of an eye".

Regards,
Rob

[Ballot comment]
[ Trying something new here -- adding commentary in my existing Yes ballot ]

I'd like to thank the authors for responding to the ADs with DISCUSS positions - it looks like the replies and pull request address most of the comments.
I'd also like to thank David Blacka for the useful DNSDIR review - https://datatracker.ietf.org/doc/review-ietf-dnsop-dns-catalog-zones-08-dnsdir-lc-blacka-2022-12-27/

[Ballot comment]
I support Paul Wouters' DISCUSS position.

General:

Could I trouble you for an example of a complete sample catalog zone, perhaps in BIND format, in an appendix?  I can see each individual concept illustrated, but it would be helpful to see them assembled someplace.

Section 3:

"Catalog consumers MUST ignore any RR in the catalog zone which is meaningless to or otherwise not supported by the implementation" seems peculiar.  Wouldn't you do that anyway?

Section 4.1:

Given the text in Section 3 (specifically that a catalog zone follows the same rules as any other zone), is this section needed?  The third paragraph could be its own differently-named section, but the rest seems redundant.

Section 4.2:

The SHOULD at the end leaves implementers with a choice.  Why might an implementer choose to do something other than what it says?  Or should this really be a MUST?

Section 4.3:

It doesn't say anywhere (unless I missed it) that the RRTYPEs of properties are unspecified, and depend on the property.  It might be good to make that explicit, because I kept searching for it.

Section 4.4.1:

Regarding the last paragraph, is there any advice to pass on to operators about how exactly one can tell when the COO is complete?

Section 7:

Why are the protections of zone transfers and updates only SHOULDs?

[Ballot discuss]
# Sec AD review of draft-ietf-dnsop-dns-catalog-zones-08

CC @paulwouters

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions.

This review uses the format specified in https://github.com/mnot/ietf-comments/ which allows automated tools to process items (eg to produce github issues)


Note that I am a happy user of catalog zones since a few months. While I originally thought this seemed like an "if all you have is a DNS hammer" solution, it actually has some very clear advantages over other configuration synchronization methods. Thanks for this work, I am a fan!

I do have some issues I'd like to discuss though :)

## DISCUSS

### Section 4.3.1 Versioning

What should one do if the version supported is lower than the version of zone received? Attempt to understand it? preventively fail?

Are version 1 and 2 compatible? In what ways are they not? Should perhaps version 1 catalog zones always be ignored ?

### Group Properties

It seems like Section 4.4.2 defines "group properties" that are standardized, while Section 4.5 specifies Private Use group properties. But there is actually no registry created for Group Properties, and no definitions other than "examples" are given. This makes the status of, for example "nodnssec", unclear. Is this a custom (eg bind implementation only) property or is this really a custom private use entry, in which case the example is bad as it belongs under .bind.ext.

Since "nodnssec" seems a real use case, why does this document not create an IANA registry for Catalog Zone Group Properties and places "nodnssec" in it?

### 5.3 "MUST be removed"?
```
        Only when the zone was configured from a specific catalog zone,
        and the zone is removed as a member from that specific catalog
        zone, the zone and associated state (such as zone data and DNSSEC
        keys) MUST be removed.
```

What is "removed" here? I think perhaps it should be limited to "MUST no longer be served". For example, it would be bad if the operator made an error, and ended up briefly removing the zone and "removing" (aka destroying) some private DNSSEC keys, complicating the zone restoration. Also, perhaps the implementation wants to simply keep the state on disk but move it to a /var/lib/xxx/zones/archived/ directory. The use of "remove" sounds like that might not be allowed.

### Operational Considerations

What are the risks and benefits of Extension group properties?

Should one try to standardize these instead? Why is this document not doing that based on its operational experience with eg bind and knot and powerdns ?

### Security Considerations

Dealing with high value domains eg gmail.com is missing. If a large DNS hoster would enable catalog zones for its customers, how can it prevent rogue takeovers? If fully automated, it can never be safely deployed. If each zone needs a manual check, well than we don't really have "catalog zones" auto-populating name servers.

Is there an expectation that nameservers can do some authorization call before adding a new domain that is already delegated elsewhere? Eg if GoDaddy uses catalog zones, and I am their tiny customer with "nohats.ca" and then add a new zone "gmail.com", that could cause a significant disruption. Especially if the malicious person would create another domain that depends on "gmail.com" in such a way that GoDaddy's servers will start sending "gmail.com" data in their additional data reply for other domains. The section only has a "consumer(s) MAY ", which in my opinion, is far too weak as a security control. As the above example shows, it is just too easy to start poisoning nameservers via implementations that skip this one MAY clause in the Security Considerations.

[Ballot comment]
## Comments

### Appendix A

The appendix implementation status only mentions version 2 for bind. Presumably, the other implementations never supported version 1, but this could be made more clear (although granted, it is a little weird so late in the process to do this as it will get cut out before publication anyway, but if a new draft is done based on IESG review comments, please also clarify this.

### NITS

```
        such properties MUST be represented below the label ext.
```
I would use quotes, eg "ext." to make it clear this is literal string.

```
        Implementation and operational Notes
```

Weird capitalization ?

[Ballot comment]
Thanks for working on these specification.

My read did not identified any TSV related issues. However, a SHOULD for authentication for catalog update seem rather weak. I am expecting security ADs will have a closer look at it.

I regret on not getting explanations for more than 5 authors in this specification.

[Ballot comment]
Thanks for working on these specification.

My read did not identified any TSV related issues. However, a SHOULD for authentication for catalog update seem rather weak. I am expecting security ADs will have a closer look at it.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-dnsop-dns-catalog-zones-08
CC @evyncke

Thank you for the work put into this document. I really like the ideas behind this IETF draft (OTOH, DNS is now used as a control/transport protocol pretty much BGP nowadays...). But, I second Murray's DISCUSS point about IANA (and his ask to get an example because the whole document is not really easy to read for a non expert).

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 Tim Wicinski for the shepherd's write-up including the WG consensus *but* lacking the justification of the intended status :-(

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Lack of revised I-D after IETF Last Call

David Black did a Last Call review for the DNS directorate on the 27th of December 2022:
https://mailarchive.ietf.org/arch/msg/dnsdir/7v58S0wA1G5KfiwTrrEdYAqT73w/

Probably due to some personal time during that week, no replies/text changes are done yet. Are the authors intending to reply to David ?

### Section 1

Should IXFR / AXFR be cited with a reference ? Even if they are part of the RFC Editor set of known abbreviations.

### Section 4.1

Isn't the SOA serial already specified as being increased as soon as the zone content is changed ? If so, why repeating the MUST here ?

### Section 4.2

Even if the TTL value is to be ignored by secondary servers, is there a recommended value to be used in the catalog zone ?

### Section 4.3.1

Suggest removing "For this memo, ".

### Section 4

Should there be a clear indication about which label to use for each property? I.e., `the "coo" label is used for the change of ownership property`.

Should there be a IANA registry for all those special labels / property ? Or would it be an overkill ?

### Section 4.4.1

Just 2 personal comments, no need to reply... But,

* re-using the same node label among zones may be complex, I would have specified all zone properties are reset after a migration to start from a clean state
* I am unsure whether the last paragraph procedure is reliable and easy to do.

### Section 4.4.2.1

s/between the producer and the consumer of the catalog/between the producer and the consumer(s) of the catalog/ ?

### Section 6

Mostly at a DISCUSS level, but about the 1st paragraph, the 2 sentences are contradictory (as "invalid." is not under control of the catalog producer):

* `a catalog producer MUST NOT use names that are not under the control of the catalog producer`
* `It is RECOMMENDED ...or to use a name under a suitable name such as "invalid."`


## NITS

### I.e.

s/i.e./i.e.,/

### Section 3

s/Its records/Its resource records/ ? and introduce the RR abbreviation ?

s/for such zones/for regular zones/ ?

### Section 6

s/when catalog zones or another automatic configuration mechanism is not in place/when catalog zones or another automatic configuration mechanism are not in place/ ?

## 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 discuss]
This is cool stuff.  I assure you I'm going to ballot "Yes" after what's below is cleared up.

There's no IANA Considerations section.  Was this intentional?  I ask for a few reasons:

(1) It's expected ("should", per BCP 26), with no actions for IANA, to expressly include a section that says so.  It's conspicuously missing here.

(2) Why is there no registry for custom properties?  I can see that Section 4.5 takes a run at dealing with the collision risk by SHOULDing a particular way of naming custom properties, but it feels to me like a registry is the right way to deal with this.  As a consumer of this work, I might not want to reveal (via names) which DNS implementation I'm using, for example.

(3) I have a similar question about groups in Section 4.4.2; "nodnssec" is an example of something that we might want to register with global semantics, or more generally, that some values might be common in implementations and therefore worth documenting.

(4) Do we need a registry of names that are special in the context of catalog zones, e.g., "zones", "ext", "group", "version", "coo", "invalid"?

Separately: What action should be taken if a nameserver is already authoritative for a zone (say, is a primary), yet it receives a catalog update that now contains that same zone?  This seems like a possible attack that should be discussed.  I guess the second-last paragraph of Section 7 covers this, though indirectly.

[Ballot comment]
Thank you to Catherine Meadows for the SECDIR review.

I support Murray Kucherawy DISCUSS position.

** Section 3.
Catalog consumers MUST ignore any RR in the catalog zone which is
  meaningless to or otherwise not supported by the implementation.

Can “meaningless” be more formally described?  Are there specific RR which shouldn’t be in the catalog?

** Section 3.  Editorial.

The content of catalog zones may not be
  accessible from any recursive nameserver.

Can the intent of this be clarified?  Is it saying that the “contents of the catalog zone may _not necessarily_ be accessible from _all or some_ recursive nameservers”? or the “contents of the catalog zone _should not be/must not be_ accessible from any recursive nameserver”?

[Ballot discuss]
This is cool stuff.  I assure you I'm going to ballot "Yes" after what's below is cleared up.

There's no IANA Considerations section.  Was this intentional?  I ask for a few reasons:

(1) It's expected (required?), with no actions for IANA, to expressly include a section that says so.  It's conspicuously missing here.

(2) Why is there no registry for custom properties?  I can see that Section 4.5 takes a run at dealing with the collision risk by SHOULDing a particular way of naming custom properties, but it feels to me like a registry is the right way to deal with this.  As a consumer of this work, I might not want to reveal (via names) which DNS implementation I'm using, for example.

(3) I have a similar question about groups in Section 4.4.2; "nodnssec" is an example of something that we might want to register with global semantics, or more generally, that some values might be common in implementations and therefore worth documenting.

(4) Do we need a registry of names that are special in the context of catalog zones, e.g., "zones", "ext", "group", "version", "coo", "invalid"?

Separately: What action should be taken if a nameserver is already authoritative for a zone (say, is a primary), yet it receives a catalog update that now contains that same zone?  This seems like a possible attack that should be discussed.  I guess the second-last paragraph of Section 7 covers this, though indirectly.

[Ballot comment]
General:

Could I trouble you for an example of a complete sample catalog zone, perhaps in BIND format, in an appendix?  I can see each individual concept illustrated, but it would be helpful to see them assembled someplace.

Section 3:

"Catalog consumers MUST ignore any RR in the catalog zone which is meaningless to or otherwise not supported by the implementation" seems peculiar.  Wouldn't you do that anyway?

Section 4.1:

Given the text in Section 3 (specifically that a catalog zone follows the same rules as any other zone), is this section needed?  The third paragraph could be its own differently-named section, but the rest seems redundant.

Section 4.2:

The SHOULD at the end leaves implementers with a choice.  Why might an implementer choose to do something other than what it says?  Or should this really be a MUST?

Section 4.3:

It doesn't say anywhere (unless I missed it) that the RRTYPEs of properties are unspecified, and depend on the property.  It might be good to make that explicit, because I kept searching for it.

Section 4.4.1:

Regarding the last paragraph, is there any advice to pass on to operators about how exactly one can tell when the COO is complete?

Section 7:

Why are the protections of zone transfers and updates only SHOULDs?

[Ballot comment]
Section 3:

"Catalog consumers MUST ignore any RR in the catalog zone which is meaningless to or otherwise not supported by the implementation" seems peculiar.  Wouldn't you do that anyway?

Section 4.1:

Given the text in Section 3 (specifically that a catalog zo

[Ballot comment]
# Internet AD comments for draft-ietf-dnsop-dns-catalog-zones-08
CC @ekline

## Nits

### S4.3

* "Member-specific properties are described in Section 4.3" ->
  "Member-specific properties are described in Section 4.4"

### S4.4.2.1

* S4.3.1 has quotation marks around the contents of the TXT record, whereas
  this section does not.  Recommend standardizing on one format, and probably
  the one with surrounding quotation marks, i.e.:

  group..zones.$CATZ  0 IN TXT    "nodnssec"
  group..zones.$CATZ  0 IN TXT    "operator-x-sign-with-nsec3"
  group..zones.$CATZ  0 IN TXT    "operator-y-nsec3"

  Although, perhaps I've misunderstood something and this is not relevant.

[Ballot comment]
# GEN AD review of draft-ietf-dnsop-dns-catalog-zones-08

CC @larseggert

Thanks to Russ Housley for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/V-jMkADwNBpUN-H4TyNcC_RdTwg).

## Comments

### Section 3, paragraph 2
```
    Catalog consumers MUST ignore any RR in the catalog zone which is
    meaningless to or otherwise not supported by the implementation.
```
Russ Housley raised this in his Gen-ART review: What is meant
by "meaningless" here?

### Too many authors

The document has seven authors, which exceeds the recommended author limit. Has
the sponsoring AD agreed that this is appropriate?

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

#### "Table of Contents", paragraph 1
```
tent of a DNS zone is synchronized amongst its primary and secondary nameserv
                                  ^^^^^^^
```
Do not mix variants of the same word ("amongst" and "among") within a single
text.

#### Section 4.1, paragraph 3
```
ord in the collection.  has an unique value in the collection. When
                                      ^^
```
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

#### Section 5.1, paragraph 7
```
dure described in Section 4.4.1. Otherwise a migration of a member zone from
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Otherwise".

#### Section 5.2, paragraph 2
```
yet (because of a lost packet or down time or otherwise), but did already se
                                  ^^^^^^^^^
```
This word is normally spelled as one. Did you mean "downtime"?

#### Section 6, paragraph 1
```
to enumerate the contents of a multi-valued property (such as the list of m
                                ^^^^^^^^^^^^
```
This word is normally spelled as one.

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

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

The IANA Functions Operator has reviewed draft-ietf-dnsop-dns-catalog-zones-08, which is currently in Last Call, and has the following comments:

The IANA Functions Operator notes that this document does not contain a standard IANA Considerations section. After examining the draft, we understand that, upon approval of this document, there are no IANA Actions that need completion.

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,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-12-13):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-dns-catalog-zones@ietf.org, tjw.ietf@gmail.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DNS Catalog Zones) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'DNS Catalog Zones'
  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-12-13. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes a method for automatic DNS zone provisioning
  among DNS primary and secondary nameservers by storing and
  transferring the catalog of zones to be provisioned as one or more
  regular DNS zones.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/



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

(1) RFC is Standards Track, and this is the correct RFC type.


(2)

Technical Summary:

  This document describes a method for automatic DNS zone provisioning
  among DNS primary and secondary nameservers by storing and
  transferring the catalog of zones to be provisioned as one or more
  regular DNS zones.

Working Group Summary:

WG worked and collabrated on resolving any and all isssues. No rough consenus.

Document Quality:

Appendix A points out there are several implementations that interact successfully.

Personnel:

Document Shepherd: Tim Wicinski

Responsible Area Director: Warren Kumari

(3) The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) This document will update RFC7873, and it is in the abstract and the
introduction.

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section are accurate

(18) No new IANA registries

(19) No Automated checks needed

(20) No Yang

(1) RFC is Standards Track, and this is the correct RFC type.


(2)

Technical Summary:

  This document describes a method for automatic DNS zone provisioning
  among DNS primary and secondary nameservers by storing and
  transferring the catalog of zones to be provisioned as one or more
  regular DNS zones.

Working Group Summary:

WG worked and collabrated on resolving any and all isssues. No rough consenus.

Document Quality:

Appendix A points out there are several implementations that interact successfully.

Personnel:

Document Shepherd: Tim Wicinski

Responsible Area Director: Warren Kumari

(3) The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) This document will update RFC7873, and it is in the abstract and the
introduction.

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section are accurate

(18) No new IANA registries

(19) No Automated checks needed

(20) No Yang

(1) RFC is Standards Track, and this is the correct RFC type.


(2)

Technical Summary:

  This document describes a method for automatic DNS zone provisioning
  among DNS primary and secondary nameservers by storing and
  transferring the catalog of zones to be provisioned as one or more
  regular DNS zones.

Working Group Summary:

WG worked and collabrated on resolving any and all isssues. No rough consenus.

Document Quality:

Appendix A points out there are several implementations that interact successfully.

Personnel:

Document Shepherd: Tim Wicinski

Responsible Area Director: Warren Kumari

(3) The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) This document will update RFC7873, and it is in the abstract and the
introduction.

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section are accurate

(18) No new IANA registries

(19) No Automated checks needed

(20) No Yang