IP Fragmentation Avoidance in DNS over UDP
draft-ietf-dnsop-avoid-fragmentation-17

[Ballot comment]
Thanks for addressing my DISCUSS and Barry's remaining ARTART review point.

I support Rob Wilton's DISCUSS position.  Piling on a bit, in reference to:

  R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
  size to the RECOMMENDED size of 1400 or a smaller size.

I think the "RECOMMENDED" here is just carrying forward a "RECOMMENDED" from someplace else.  If that's correct, I suggest changing it to "recommended" or, if you want to be more precise, "... to the size recommended by RFCXXXX of 1400 or smaller."  Now it's clear what the SHOULD is referencing, and you don't own the RECOMMENDED part here.

I suggest defining "EMSGSIZE" in Section 2 to be the UNIX error code of the same name.  Otherwise, we encounter it in Section 3.1 in a way that could mean it's an error code (which is how I think you intend it) or as a symbolic name for the path MTU size.

Forwarded comments from Orie Steele, incoming ART Area Director:

"Recommendations for zone operators and DNS server operators"

* Define "large / small" better.

"Protocol compliance considerations"

* Would be nice to see reporting recommendations, perhaps that make the failure an internal cost for the failing component?... would not want a repeat of dmarc though.

[Ballot comment]
Thanks for addressing my DISCUSS.

Thanks to Mirja Kuhlewind for the TSVART review, and to the authors for responding.

(1) I support Rob's DISCUSS (and Paul's comment) about SHOULD/MAY. "do it unless the OS makes it impossible" is a typical use of SHOULD.

(2) Section 3.1, R1 says that responders SHOULD omit the fragment header. Under what circumstances would it be reasonable to keep it?

[Ballot comment]
Thank you for this document, DNS is so important for the global Internet that a BCP is welcome. I am afraid that for several reasons I was unable to review correctly this document on time, mainly relying on Vladimír Čunát's DNS-dir review at https://datatracker.ietf.org/doc/review-ietf-dnsop-avoid-fragmentation-16-dnsdir-telechat-cunat-2023-12-27/ .

Nevertheless, I support Rob's DISCUSS about the use of MAY/SHOULD about the IPv4 DF-bit in section 3.1; also, an assertion like `many OS kernel constraints make it difficult to set the DF bit` should be backed by a reference.

I also find 'light' to rely on TCP MSS as it is set by the end points only, i.e., it can also leads to IPv4 fragmentation in the path (or IPv6 fragmentation by the kernel at the source).

Section 3, does `These recommendations are intended for nodes with global IP addresses on the Internet` also cover the use of NAT/NPT when the requestor uses RFC 1918 addresses or ULA?

In section 3.1:

- R1 why not simply stating that there should be no IPv6 fragmentation ? Atomic fragments are now discouraged for IPv6

- R3 where is the packet size of 1400 coming from ? Some reasoning would be welcome (e.g., based on some measurements over the global Internet). Put at least a forward reference to the appendix.

In section 4, R9: where is `13 may be too large` coming from ?

Appendix `the authors' recommendation` is it a recommendation by the authors or by the IETF in an IETF stream document?

-éric

[Ballot comment]
# GEN AD review of draft-ietf-dnsop-avoid-fragmentation-16

CC @larseggert

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

## Comments

### Paragraph 2
```
                    IP Fragmentation Avoidance in DNS
```
Title should clarify this is for DNS over UDP.

### Section 1, paragraph 5
```
    This document specifies various techniques to avoid IP fragmentation
    of UDP packets in DNS.
```
Really wish that this BCP made a much stronger recommendation for DNS over TCP.

### Section 3.1, paragraph 0
```
  3.1.  Recommendations for UDP responders
```
I find myself agreeing with other ballots on these recommendations.
Will refrain from duplicating them (and also from holding another DISCUSS
based on them.)

### Section 3.1, paragraph 3
```
    At the time of writing, most DNS server software did not set the DF
    bit for IPv4, and many OS kernel constraints make it difficult to set
    the DF bit in all cases.  Best Current Practice documents should not
    specify what is currently impossible, so R2, which is setting the DF
    bit, is "MAY" rather than "SHOULD".
```
Maybe I'm familiar with different kernels, but all the ones I am
familiar with (except for some IoT platforms) readily offer socket
options to set DF (and prevent stack fragmentation in v6).

### Section 3.1, paragraph 3
```
    R3.  UDP responders SHOULD compose response packets that fit in the
    minimum of the offered requestor's maximum UDP payload size
    [RFC6891], the interface MTU, and the RECOMMENDED maximum DNS/UDP
    payload size 1400.
```
Why SHOULD, i.e., when would it ever be OK to do this? Also, where
does the 1400 byte value come from (magic constant?)

### Section 3.1, paragraph 3
```
    R5.  UDP responders SHOULD limit the response size when UDP
    responders are located on small MTU (<1500) networks.
```
Limit *to what*?

### Section 4, paragraph 0
```
  4.  Recommendations for zone operators and DNS server operators
```
I find it somewhat questionable to recommend changes in how DNS is
being operated just to cater to UDP needing to remain a viable
transport. (I realize I may be an outlier here.)

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

### Outdated references

Document references `draft-ietf-dnsop-svcb-https`, but that has been published
as `RFC9460`.

### Grammar/style

#### "Appendix B.", paragraph 3
```
fter two UDP timeouts, BIND 9 will fallback to TCP. C.2. Knot DNS and Knot R
                                  ^^^^^^^^
```
The word "fallback" is a noun. The verb is spelled with a space.

## 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 comment]
I support Rob Wilton's DISCUSS position.  Piling on a bit, in reference to:

  R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
  size to the RECOMMENDED size of 1400 or a smaller size.

I think the "RECOMMENDED" here is just carrying forward a "RECOMMENDED" from someplace else.  If that's correct, I suggest changing it to "recommended" or, if you want to be more precise, "... to the size recommended by RFCXXXX of 1400 or smaller."  Now it's clear what the SHOULD is referencing, and you don't own the RECOMMENDED part here.

I suggest defining "EMSGSIZE" in Section 2 to be the UNIX error code of the same name.  Otherwise, we encounter it in Section 3.1 in a way that could mean it's an error code (which is how I think you intend it) or as a symbolic name for the path MTU size.

Forwarded comments from Orie Steele, incoming ART Area Director:

"Recommendations for zone operators and DNS server operators"

* Define "large / small" better.

"Protocol compliance considerations"

* Would be nice to see reporting recommendations, perhaps that make the failure an internal cost for the failing component?... would not want a repeat of dmarc though.

[Ballot comment]
I support Rob Wilton's DISCUSS position.  Piling on a bit, in reference to:

  R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
  size to the RECOMMENDED size of 1400 or a smaller size.

I think the "RECOMMENDED" here is just carrying forward a "RECOMMENDED" from someplace else.  If that's correct, I suggest changing it to "recommended" or, if you want to be more precise, "... to the size recommended by RFCXXXX of 1400 or smaller."  Now it's clear what the SHOULD is referencing, and you don't own the RECOMMENDED part here.

I suggest defining "EMSGSIZE" in Section 2 to be the UNIX error code of the same name.  Otherwise, we encounter it in Section 3.1 in a way that could mean it's an error code (which is how I think you intend it) or as a symbolic name for the path MTU size.

[Ballot comment]
Thank you to Donald Eastlake for his SECDIR review.  Please review his proposed text on including clarifying language around the applicability of TSIG.

I support Martin Duke and Rob Wilton’s DISCUSS positions.

** Section 7.2
  This would indicate prior
  reliance upon IP fragmentation, which is universally considered to be
  harmful to both the performance and stability of applications,
  endpoints, and gateways.

Is there a reference that can be cited to substantiate this “universal” position?

[Ballot comment]
# Internet AD comments for draft-ietf-dnsop-avoid-fragmentation-16
CC @ekline

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

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

## Comments

### S1

* "TCP avoids fragmentation by ..."

  TCP also benefits hugely from widespread support for MSS rewriting.  If
  something like an "EDNS0 Payload Size rewriting" function was available
  and as widely deployed there might be a very different conversation to
  be had.

  No text changes necessary; just a random thought.

[Ballot discuss]
1) I'm unclear about Sec 4, R11 and Appendix B. When configured for minimal response, are responses to ALL requesters reduced in size, or only to those requesters that indicate a small MTU?

As DNS becomes a more important vehicle for various discovery protocols (e.g. ECH), I would hate for responders to globally invoke a policy that makes it hard to deploy those protocols. But I'm happy to discuss this.

2) In section 3.2, R8, please add RFC 8961 as a normative reference for how to set the timeout (e.g. "UDP requestors MUST observe [RFC8961] in setting their timeout.")

[Ballot comment]
Thanks to Mirja Kuhlewind for the TSVART review, and to the authors for responding.

(1) I support Rob's DISCUSS (and Paul's comment) about SHOULD/MAY. "do it unless the OS makes it impossible" is a typical use of SHOULD.

(2) Section 3.1, R1 says that responders SHOULD omit the fragment header. Under what circumstances would it be reasonable to keep it?

[Ballot discuss]
Hi,

Thanks for this document.

I'm echoing Paul's and the SECDIR review comments here on the use of MAY in recommendations (since everywhere you see MAY it is equally valid for an interpretation to treat it as "MAY NOT"), but I think that this makes the document, as a proposed BCP, unclear enough that I'm raising this to level of a DISCUSS.


(1) p 3, sec 3.1.  Recommendations for UDP responders

  At the time of writing, most DNS server software did not set the DF
  bit for IPv4, and many OS kernel constraints make it difficult to set
  the DF bit in all cases.  Best Current Practice documents should not
  specify what is currently impossible, so R2, which is setting the DF
  bit, is "MAY" rather than "SHOULD".


I think that this recommendation, particularly because it is using RFC 2119 language, is unclear.  I would suggest rephasing this to something like:

  R2.  Where supported, UDP responders SHOULD set IP "Don't Fragment
  flag (DF) bit" [RFC0791] on IPv4.


(2) p 3, sec 3.2.  Recommendations for UDP requestors

  R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
  size to the RECOMMENDED size of 1400 or a smaller size.

I find this recommendation to be unclear because it mixes both a "SHOULD" and "RECOMMENDED", i.e., I find it unclear as to what the "SHOULD" applies to.  Is the recommendation (i) that UDP requestors should limit the maximum UDP payload.  Or (ii) is the recommendation that a limit of 1400 be used, or (iii) perhaps both.  Maybe rewording this to something like the following would help:

  R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
  size to 1400 bytes, but MAY limit the maximum UDP payload size to a
  smaller size on small MTU (less than 1500 bytes) networks.

  or,

  R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
  size.  It is RECOMMENDED to use a limit of 1400 bytes, but a smaller
  limit MAY be used.


(3) p 3, sec 3.2.  Recommendations for UDP requestors

  R7.  UDP requestors MAY drop fragmented DNS/UDP responses without IP
  reassembly to avoid cache poisoning attacks.

As written, I don't think that this is really a recommendation.  Either it is a just a statement or fact (in which case it is not a recommendation), or it should be upgraded to a SHOULD.


(4) p 4, sec 3.2.  Recommendations for UDP requestors

  R7.  UDP requestors MAY drop fragmented DNS/UDP responses without IP
  reassembly to avoid cache poisoning attacks.
  R8.  DNS responses may be dropped by IP fragmentation.  Upon a
  timeout, to avoid resolution failures, UDP requestors MAY retry using
  TCP or UDP with a smaller EDNS requestor's maximum UDP payload size
  per local policy.

Again, I think that this document would be clearer if this was a SHOULD rather than a MAY.

Regards,
Rob

[Ballot comment]

        At the time of writing, most DNS server software did not set
        the DF bit for IPv4, and many OS kernel constraints make it
        difficult to set the DF bit in all cases. Best Current Practice
        documents should not specify what is currently impossible, so R2,
        which is setting the DF bit, is "MAY" rather than "SHOULD".

If what you want is "we really really want this but it cannot be done on every OS",
then I think SHOULD instead of MUST is fine, but MAY seems too weak.

        R7. UDP requestors MAY drop fragmented DNS/UDP responses without
        IP reassembly to avoid cache poisoning attacks.

        R8. DNS responses may be dropped by IP fragmentation. Upon a
        timeout, to avoid resolution failures, UDP requestors MAY retry
        using TCP or UDP with a smaller EDNS requestor's maximum UDP
        payload size per local policy.

Same here. R7 and R8 are "recommendations" so I feel the MAY's should be SHOULDs.
Otherwise the recommendation becomes "do whatever you MAY please", in which case
why are these in the document?


        R9. Use a smaller number of name servers (13 may be too large)

I would say "name server names" instead of "name servers", to avoid any ambiguity
of anycast name servers operating under the same name. Eg the document is not
saying "use less than 13 name servers", but it is saying "use less than 13 name
server names"


        smaller than those usually used for RSA.

smaller than those of equivalent cryptographic strength using RSA

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

IANA has completed its review of draft-ietf-dnsop-avoid-fragmentation-15, 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,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2023-10-27):

From: The IESG
To: IETF-Announce
CC: benno@NLnetLabs.nl, dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-avoid-fragmentation@ietf.org, swoolf@pir.org, tjw.ietf@gmail.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Fragmentation Avoidance in DNS) to Best Current Practice


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Fragmentation Avoidance in DNS'
  as Best Current Practice

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 2023-10-27. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  EDNS0 enables a DNS server to send large responses using UDP and is
  widely deployed.  Large DNS/UDP responses are fragmented, and IP
  fragmentation has exposed weaknesses in application protocols.  It is
  possible to avoid IP fragmentation in DNS by limiting response size
  where possible, and signaling the need to upgrade from UDP to TCP
  transport where necessary.  This document proposes techniques to
  avoid IP fragmentation in DNS.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8899: Packetization Layer Path MTU Discovery for Datagram Transports (Proposed Standard - Internet Engineering Task Force (IETF))

(1) RFC is Best Current Practice, and this is the proper type of RFC

(2)

Technical Summary:

  EDNS0 enables a DNS server to send large responses using UDP and is
  widely deployed.  Large DNS/UDP responses are fragmented, and IP
  fragmentation has exposed weaknesses in application protocols.  It is
  possible to avoid IP fragmentation in DNS by limiting response size
  where possible, and signaling the need to upgrade from UDP to TCP
  transport where necessary.  This document proposes to avoid IP
  fragmentation in DNS.

Working Group Summary:

The working group had a few issues to work through, which included adding an
appendix for implementations. Several comments came in after WGLC, but they
were very relevant, so the working group addressed them.
There are currently no issues and solid consensus with the final document.

Document Quality:

Document is of good quality.

Personnel:

Document Shepherd is Tim Wicinski

Responsible Area Director is Warren Kumari

(3) Document Shepherd did an editorial review, as a detailed technical review.
    Document is ready.

(4) Document Shepherd has no concerns over quality of review


(5) No broader review needed

(6) Document Shepherd does not have any concerns.


(7) All authors confirm no IPR

(8) No IPR

(9) WG Consensus is solid.

(10) No Appeals threatened

(11) No nits

(12) No formal reviews needed

(13) all references identified correctly.

(14) All normative references are ready.

(15) No downward normative references

(16) No existing RFCs will be updated.

(17) No IANA

(18) No IANA

(19) N/A

(20) No Yang

(1) RFC is Best Current Practice, and this is the proper type of RFC

(2)

Technical Summary:

  EDNS0 enables a DNS server to send large responses using UDP and is
  widely deployed.  Large DNS/UDP responses are fragmented, and IP
  fragmentation has exposed weaknesses in application protocols.  It is
  possible to avoid IP fragmentation in DNS by limiting response size
  where possible, and signaling the need to upgrade from UDP to TCP
  transport where necessary.  This document proposes to avoid IP
  fragmentation in DNS.

Working Group Summary:

The working group had a few issues to work through, which included adding an
appendix for implementations. Several comments came in after WGLC, but they
were very relevant, so the working group addressed them.
There are currently no issues and solid consensus with the final document.

Document Quality:

Document is of good quality.

Personnel:

Document Shepherd is Tim Wicinski

Responsible Area Director is Warren Kumari

(3) Document Shepherd did an editorial review, as a detailed technical review.
    Document is ready.

(4) Document Shepherd has no concerns over quality of review


(5) No broader review needed

(6) Document Shepherd does not have any concerns.


(7) All authors confirm no IPR

(8) No IPR

(9) WG Consensus is solid.

(10) No Appeals threatened

(11) No nits

(12) No formal reviews needed

(13) all references identified correctly.

(14) All normative references are ready.

(15) No downward normative references

(16) No existing RFCs will be updated.

(17) No IANA

(18) No IANA

(19) N/A

(20) No Yang

(1) RFC is Best Current Practice, and this is the proper type of RFC

(2)

Technical Summary:

  EDNS0 enables a DNS server to send large responses using UDP and is
  widely deployed.  Large DNS/UDP responses are fragmented, and IP
  fragmentation has exposed weaknesses in application protocols.  It is
  possible to avoid IP fragmentation in DNS by limiting response size
  where possible, and signaling the need to upgrade from UDP to TCP
  transport where necessary.  This document proposes to avoid IP
  fragmentation in DNS.

Working Group Summary:

The working group had a few issues to work through, which included adding an
appendix for implementations. Several comments came in after WGLC, but they
were very relevant, so the working group addressed them.
There are currently no issues and solid consensus with the final document.

Document Quality:

Document is of good quality.

Personnel:

Document Shepherd is Tim Wicinski

Responsible Area Director is Warren Kumari

(3) Document Shepherd did an editorial review, as a detailed technical review.
    Document is ready.

(4) Document Shepherd has no concerns over quality of review


(5) No broader review needed

(6) Document Shepherd does not have any concerns.


(7) All authors confirm no IPR

(8) No IPR

(9) WG Consensus is solid.

(10) No Appeals threatened

(11) No nits

(12) No formal reviews needed

(13) all references identified correctly.

(14) All normative references are ready.

(15) No downward normative references

(16) No existing RFCs will be updated.

(17) No IANA

(18) No IANA

(19) N/A

(20) No Yang

(1) RFC is Best Current Practice, and this is the proper type of RFC

(2)

Technical Summary:

  EDNS0 enables a DNS server to send large responses using UDP and is
  widely deployed.  Large DNS/UDP responses are fragmented, and IP
  fragmentation has exposed weaknesses in application protocols.  It is
  possible to avoid IP fragmentation in DNS by limiting response size
  where possible, and signaling the need to upgrade from UDP to TCP
  transport where necessary.  This document proposes to avoid IP
  fragmentation in DNS.

Working Group Summary:

The working group had a few issues to work through, which included adding an
appendix for implementations. Several comments came in after WGLC, but they
were very relevant, so the working group addressed them.
There are currently no issues and solid consensus with the final document.

Document Quality:

Document is of good quality.

Personnel:

Document Shepherd is Tim Wicinski

Responsible Area Director is Warren Kumari

(3) Document Shepherd did an editorial review, as a detailed technical review.
    Document is ready.

(4) Document Shepherd has no concerns over quality of review


(5) No broader review needed

(6) Document Shepherd does not have any concerns.


(7) All authors confirm no IPR

(8) No IPR

(9) WG Consensus is solid.

(10) No Appeals threatened

(11) No nits

(12) No formal reviews needed

(13) all references identified correctly.

(14) All normative references are ready.

(15) No downward normative references

(16) No existing RFCs will be updated.

(17) No IANA

(18) No IANA

(19) N/A

(20) No Yang

Implementers raised discussion points over which guidance will be addressed.
Suggestion from chairs to add an implementation appendix to document this.
Will need some WG consensus

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

See: https://mailarchive.ietf.org/arch/msg/dnsop/x_639OElsGSG5Gz10YrB80xS6Fg/

This thread expressed desire to have an implementation section, and the authors concurred. Chairs requested that document be returned to the WG for this to happen.

(1) RFC is Best Current Practice, and this is the proper type of RFC

(2)

Technical Summary:

  EDNS0 enables a DNS server to send large responses using UDP and is
  widely deployed.  Large DNS/UDP responses are fragmented, and IP
  fragmentation has exposed weaknesses in application protocols.  It is
  possible to avoid IP fragmentation in DNS by limiting response size
  where possible, and signaling the need to upgrade from UDP to TCP
  transport where necessary.  This document proposes to avoid IP
  fragmentation in DNS.

Working Group Summary:

The working group had a few issues to work through, but there no issues and
solid consensus with the final document.

Document Quality:

Document is of good quality.

Personnel:

Document Shepherd is Tim Wicinski

Responsible Area Director is Warren Kumari

(3) Document Shepherd did an editorial review, as a detailed technical review.
    Document is ready.

(4) Document Shepherd has no concerns over quality of review

(5) No broader review needed

(6) Document Shepherd has not concerns.

(7) All authors confirm no IPR

(8) No IPR

(9) WG Consensus is solid.

(10) No Appeals threatened

(11) No nits

(12) No formal reviews needed

(13) all references identified correctly.

(14) All normative references are ready.

(15) No downward normative references

(16) No existing RFCs will be updated.

(17) No IANA

(18) No IANA

(19) N/A

(20) No Yang

(1) RFC is Best Current Practice, and this is the proper type of RFC

(2)

Technical Summary:

  EDNS0 enables a DNS server to send large responses using UDP and is
  widely deployed.  Large DNS/UDP responses are fragmented, and IP
  fragmentation has exposed weaknesses in application protocols.  It is
  possible to avoid IP fragmentation in DNS by limiting response size
  where possible, and signaling the need to upgrade from UDP to TCP
  transport where necessary.  This document proposes to avoid IP
  fragmentation in DNS.

Working Group Summary:

The working group had a few issues to work through, but there no issues and
solid consensus with the final document.

Document Quality:

Document is of good quality.

Personnel:

Document Shepherd is Tim Wicinski

Responsible Area Director is Warren Kumari

(3) Document Shepherd did an editorial review, as a detailed technical review.
    Document is ready.

(4) Document Shepherd has no concerns over quality of review

(5) No broader review needed

(6) Document Shepherd has not concerns.

(7) All authors confirm no IPR

(8) No IPR

(9) WG Consensus is solid.

(10) No Appeals threatened

(11) No nits

(12) No formal reviews needed

(13) all references identified correctly.

(14) All normative references are ready.

(15) No downward normative references

(16) No existing RFCs will be updated.

(17) No IANA

(18) No IANA

(19) N/A

(20) No Yang