Change:
to make RFC Editor diffs smaller
These are manual; if only there were a tool... Diffs in the are all very small, and in each case reflects correction of an existing error or slight adjustment to accommodate limitations in XML (in one case); happy to suppy (CI is broken because of URL).
I just uploaded this to a branch on this repository so that a diff is generated in CI (assuming that I have a little more luck in getting a build to stick). The changes should be visible at URL if CI ever passes. Which of course it has not at this point...
Seems to be working occasionally; I fixed a lint problem, and diffs are now at URL
NAME I'd strongly prefer to keep this PR focused on behind-the-scenes tidying, rather than making an editorial wording choice. Beyond keeping the PR focused, doing this piecemeal is going to miss a large number of instances of "see..." because the changes represented here are only where a specific section is called out; you'd do much better to adjust that language consistently after this PR is applied (when you can do a search for and it should consistently show all instances, whether or not there's a section being referenced). If that's sensible to everyone, I think this is ready; tell me if I missed one of the comments.
NAME Fair enough. This LGTM.
Here are the diffs, since tools is failing so badly (I plan to work around that, but that will take some time). URL I've spotted one problem there already, but it does look good so far.
NAME and NAME I have learned something new about kramdown-rfc2629. Cheers.
NAME
NAME and NAME should approveThanks for doing this, recovery LGTM

Discussion:
When a sender receives credit after being blocked, it might be able to send a large amount of data in response, resulting in short-term <del> congestion; see Section 7.7 in QUIC-RECOVERY for a discussion of how </del> <ins> congestion; see Section 7.7 of QUIC-RECOVERY for a discussion of how </ins> a sender can avoid this congestion. 4.3.

datagram size are more likely to be dropped by the network.  Loss of a QUIC packet that is carried in a PMTU probe is therefore not a reliable indication of congestion and SHOULD NOT trigger a congestion <del> control reaction; see Section 3, Bullet 7 of DPLPMTUD.  However, PMTU probes consume congestion window, which could delay subsequent </del> <ins> control reaction; see Bullet 7 in Section 3 of DPLPMTUD.  However, PMTU probes consume congestion window, which could delay subsequent </ins> transmission by an application. 14.4.1.

21.1.1. The QUIC handshake incorporates the TLS 1.3 handshake and inherits <del> the cryptographic properties described in Appendix E.1 of TLS13. Many of the security properties of QUIC depend on the TLS handshake </del> <ins> the cryptographic properties described in Section E.1 of TLS13.  Many of the security properties of QUIC depend on the TLS handshake </ins> providing these properties.  Any attack on the TLS handshake could affect QUIC.

registrations in this registry are assigned using the Specification Required policy (RFC8126), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards <del> Action or IESG Approval as defined in Section 4.9 and 4.10 of </del> <ins> Action or IESG Approval as defined in Sections 4.9 and 4.10 of </ins> RFC8126. In addition to the fields in iana-provisional, permanent

policies.  Permanent registrations in this registry are assigned using the Specification Required policy (RFC8126), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned <del> using Standards Action or IESG Approval as defined in Section 4.9 and 4.10 of RFC8126. </del> <ins> using Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 of RFC8126. </ins> In addition to the fields in iana-provisional, permanent registrations in this registry MUST include the following fields: