Draft: draft-ietf-quic-manageability

Commentary: here , I propose to rewrite the first part of the paragraph so that it is easy to read . for example - Packets in the handshake belong to three separate cryptographic and transport contexts - " Initial " , which contains observable payload , " Handshake " , which is not observable " 1 - RTT " , which is not observable Here we are repeating stuffs from RFC9000 without referring to them but I found the figure in RFC9000 more explanatory . why are we rewriting it here instead of just referring to RFC9000 ? 
 I think it is important to have a figure in this document as reader of this document are not necessarily willing to read RFC9000 . Thus this document should be useful as a stand - alone read . The figure in this document is meant to be a simplification compared to the one in RFC900 there it is omitting some of the less relevant details , e.g that there is an initial and a handshake packet . 
 Also disagree that the diagram in RFC9000 is better for the purposes of this document ; would prefer to keep it . The paragraph is a bit difficult to read , though , reflecting the history of this section more than what we actually want to say . Will propose a reordering / simplification ... 
 Ok , I think I understand why you want to keep the figure . I actually had to look at the RFC9000 to understand it better . I hope the promised reordering would help here .
Paragraph (version A):
Packets in the handshake belong to three separate cryptographic and
transport contexts ("Initial", which contains observable payload, and
"Handshake" and "1-RTT", which do not).  QUIC packets in separate
contexts during the handshake can be coalesced (see coalesced) in
order to reduce the number of UDP datagrams sent during the
handshake.  QUIC packets can be lost and reordered, so packets within
a flight might not be sent close in time, though the sequence of the
flights will not change, because one flight depends upon the peer's
previous flight.
Paragraph (version A):
As shown here, the client can send 0-RTT data as soon as it has sent
its Client Hello, and the server can send 1-RTT data as soon as it
has sent its Server Hello.
Paragraph (version A):
A handshake starts with the client sending one or more datagrams
containing Initial packets as shown in fig-client-initial, which
elicits the Server Initial response as shown in fig-server-initial
typically containing three types of packets: Initial packet(s) with
the beginning of the server's side of the TLS handshake, Handshake
packet(s) with the rest of the server's portion of the TLS handshake,
and 1-RTT packet(s), if present.
Paragraph (version A):
The Client Completion flight contains at least one Handshake packet
and could also include an Initial packet.
Paragraph (version B):
A handshake starts with the client sending one or more datagrams
containing Initial packets, detailed fig-client-initial, which
elicits the Server Initial response detailed in fig-server-initial
typically containing three types of packets: Initial packet(s) with
the beginning of the server's side of the TLS handshake, Handshake
packet(s) with the rest of the server's portion of the TLS handshake,
and 1-RTT packet(s), if present.
Paragraph (version B):
As shown here, the client can send 0-RTT data as soon as it has sent
its Client Hello, and the server can send 1-RTT data as soon as it
has sent its Server Hello.  The Client Completion flight contains at
least one Handshake packet and could also include an Initial packet.
QUIC packets in separate contexts during the handshake can be
coalesced (see coalesced) in order to reduce the number of UDP
datagrams sent during the handshake.  QUIC packets can be lost and
reordered, so packets within a flight might not be sent close in
time, though the sequence of the flights will not change, because one
flight depends upon the peer's previous flight.