Editorial pass: proposed new structure

[mirjak]

It's time for a full editorial pass on the doc and some clean ups. Before we start I would like to propose the following new structure:

1.  Introduction
1.1.  Basic Design Points (move to appendix or remove)
1.2.  Introduction of an Explicit Path Identifier (needed?)
1.3.  Use of Multiple Packet Number Spaces (needed?)
1.4.  Conventions and Definitions
2. Handshake Negotiation (or maybe: Cryptographic and Transport Handshake -> title of sec 7. In RFC9000)
2.1. New Transport Parameter
2.2 Relation to other Transport Parameters
2.3 Handling ACK and PATH_ACK in 0-RTT and 1-RTT
2.4  Packet Protection
2.4.1. Nonce Calculation
2.4.2. Key Update
3.  Path Management
3.1.  Path Initiation and Validation
3.1.1. Example Path Establishment
3.1.2 Relation to Migration and Probing
3.1.3 Address Validation Token
3.2.  Connection ID Handling
3.2.1 Issuing New Connection IDs
3.2.2 Retiring Connection IDs
3.3.  Path Status Management
3.4.  Path Close
3.4.1 Example Path Closure
3.4.2.  Avoiding Spurious Stateless Resets
3.4.3.  Handling PATH_ACK for abandoned paths (remove/merge into 3.4?)
3.3.4.  Idle Timeout (move to implementation guidance? -> no normative reqs here…)
3.3.5.  Early Abandon (is this important enough for a separate subsection or merge into 3.4?)
4.  New Frames
4.1.  PATH_ACK Frame
4.2.  PATH_ABANDON Frame
4.3.  PATH_BACKUP and PATH_AVAILABLE frames
4.4.  PATH_NEW_CONNECTION_ID frames
4.5.  PATH_RETIRE_CONNECTION_ID frames
4.6.  MAX_PATH_ID frames
4.7.  PATHS_BLOCKED and PATH_CIDS_BLOCKED frames
5.  Error Codes
6.  Implementation Considerations (review order of subsections to be done later)
6.1.  Number Spaces
6.2.  Congestion Control
6.3.  Computing Path RTT
6.4.  Packet Scheduling
6.5.  Retransmissions
6.6.  Handling PTO
6.7.  Handling different PMTU sizes
6.8.  Keep Alive
6.9.  Connection ID Changes
6.10. Migration and NAT Rebindings
6.11. Using multiple paths on the same 4-tuple
7.  IANA Considerations
8. Security Considerations
8.1.  Memory Allocation for Per-Path Resources
8.2.  Request Forgery with Spoofed Address
8.3.  Use of Transport Layer Security and the AEAD Encryption Nonce

Some of the main changes are:

• Move key protection into section 2. The idea is to handle everything related to the handshake here which includes the packet protection when negotiation is succeeded. Maybe there is a better title for this section to reflect that?
• Further also create subsections in section 2 but the content would be the same.
• Sec 3 includes the examples, path initiation would be splitted up in subsections (again same content as now), CID handling is moved up/renamed + subsection added (no new content).
• I have some open questions about moving some of the content from the path closure section...? (see above)
• No changes on frames and error codes
• Implementation considerations moved further to the back after frames and error codes (but this is optional; we can also keep it where it is now but I thought we have all normative things first)
• no review of the structure of the implementation considerations section was done yet; this will follow later

Also note that I already created a first editorial PR for the intro. However, we might first want to land all other PRs and submit another revision and then start the rest of the editorial work.