Draft: draft-ietf-quic-transport

Commentary: 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 (  is broken because of ) . 
 I just uploaded this to a branch on this repository so that a diff is generated in  ( assuming that I have a little more luck in getting a build to stick ) . The changes should be visible at if  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 
 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 . 
 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 ) . I 've spotted one problem there already , but it does look good so far . 
 and I have learned something new about kramdown - rfc2629 . Cheers . 
 and should approveThanks for doing this , recovery LGTM
Paragraph (version B):
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
congestion; see Section 7.7 of QUIC-RECOVERY for a discussion of how
a sender can avoid this congestion.
Paragraph (version A):
Endpoints could limit the content of PMTU probes to PING and PADDING
frames, since packets that are larger than the current maximum
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
control reaction; see Section 3, Bullet 7 of DPLPMTUD.  However, PMTU
probes consume congestion window, which could delay subsequent
transmission by an application.
Paragraph (version B):
Endpoints could limit the content of PMTU probes to PING and PADDING
frames, since packets that are larger than the current maximum
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
control reaction; see Bullet 7 in Section 3 of DPLPMTUD.  However,
PMTU probes consume congestion window, which could delay subsequent
transmission by an application.
Paragraph (version B):
The QUIC handshake incorporates the TLS 1.3 handshake and inherits
the cryptographic properties described in Section E.1 of TLS13.  Many
of the security properties of QUIC depend on the TLS handshake
providing these properties.  Any attack on the TLS handshake could
affect QUIC.
Paragraph (version B):
The "QUIC Frame Types" registry governs a 62-bit space.  This
registry follows the registration policy from iana-policy.  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 using Standards
Action or IESG Approval as defined in Sections 4.9 and 4.10 of
RFC8126.
Paragraph (version B):
The "QUIC Transport Error Codes" registry governs a 62-bit space.
This space is split into three regions that are governed by different
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
using Standards Action or IESG Approval as defined in Sections 4.9
and 4.10 of RFC8126.