Draft: draft-ietf-quic-manageability

Commentary: The ops drafts often reference the core drafts by section number ; make sure these section number references are correct for the WGLC drafts . 
 Correcting overcorrections regarding capitalization , but this seems benign .
Paragraph (version A):
Multiple QUIC packets may be coalesced into a UDP datagram, with a
datagram carrying one or more long header packets followed by zero or
one short header packets.  When packets are coalesced, the Length
fields in the long headers are used to separate QUIC packets.  The
length header field is variable length and its position in the header
is also variable depending on the length of the source and
destination connection ID.  See Section 4.6 of QUIC-TRANSPORT.
Paragraph (version B):
Multiple QUIC packets may be coalesced into a UDP datagram, with a
datagram carrying one or more long header packets followed by zero or
one short header packets.  When packets are coalesced, the Length
fields in the long headers are used to separate QUIC packets; see
Section 12.2 of QUIC-TRANSPORT.  The length header field is variable
length, and its position in the header is also variable depending on
the length of the source and destination connection ID; see
Section 17.2 of QUIC-TRANSPORT.
Paragraph (version A):
While a QUIC implementation must necessarily provide a way for an
application to send data on separate streams, it does not necessarily
expose stream identifiers to the application (see e.g.  QUIC-HTTP
section 6) either at the sender or receiver end, so applications
should not assume access to these identifiers.
Paragraph (version B):
While a QUIC implementation must necessarily provide a way for an
application to send data on separate streams, it does not necessarily
expose stream identifiers to the application (see, for example, QUIC-
HTTP, Section 6) either at the sender or receiver end, so
applications should not assume access to these identifiers.
Paragraph (version A):
An immidate close will emit an CONNECTION_CLOSE frame.  This frames
has two sets of types: one for QUIC internal problems that might lead
to connection closure, and one for closures initiated by the
application.  An application using QUIC can define application-
specific error codes, e.g. see QUIC-HTTP section 8.1.  In the case of
a grateful shut-down initiated by the application after application
layer negotiation, a NO_ERROR code is expected.  Further, the
CONNECTION_CLOSE frame provides an optional reason field, that can be
used to append human-readable information to an error code.  Note
that QUIC RESET_STREAM and STOP_SENDING frames provide similar
capablities.  Usually application error codes are defined to be
applicabile to all three frames.
Paragraph (version B):
An immidate close will emit an CONNECTION_CLOSE frame.  This frames
has two sets of types: one for QUIC internal problems that might lead
to connection closure, and one for closures initiated by the
application.  An application using QUIC can define application-
specific error codes (see, for example, QUIC-HTTP, Section 8.1).  In
the case of a grateful shut-down initiated by the application after
application layer negotiation, a NO_ERROR code is expected.  Further,
the CONNECTION_CLOSE frame provides an optional reason field, that
can be used to append human-readable information to an error code.
Note that QUIC RESET_STREAM and STOP_SENDING frames provide similar
capablities.  Usually application error codes are defined to be
applicabile to all three frames.
Paragraph (version A):
for longer than the announced timeout, it can send keep-alives
messages, or a QUIC implementation may provide an option to defer the
time-out to avoid unnecessary load, as specified in Section 10.2.2 of
QUIC.  See resumption-v-keepalive for further guidance on keep-
alives.
Paragraph (version B):
for longer than the announced timeout, it can send keep-alive
messages, or a QUIC implementation may provide an option to defer the
time-out to avoid unnecessary load, as specified in Section 10.1.2 of
QUIC.  See resumption-v-keepalive for further guidance on keep-
alives.
Paragraph (version A):
QUIC supports a server-generated Connection ID, transmitted to the
client during connection establishment (see Section 6.1 of QUIC).
Servers behind load balancers may need to change the Connection ID
during the handshake, encoding the identity of the server or
information about its load balancing pool, in order to support
stateless load balancing.  Once the server generates a Connection ID
that encodes its identity, every CDN load balancer would be able to
forward the packets to that server without retaining connection
state.
Paragraph (version B):
QUIC supports a server-generated Connection ID, transmitted to the
client during connection establishment (see Section 7.2 of QUIC).
Servers behind load balancers may need to change the Connection ID
during the handshake, encoding the identity of the server or
information about its load balancing pool, in order to support
stateless load balancing.  Once the server generates a Connection ID
that encodes its identity, every CDN load balancer would be able to
forward the packets to that server without retaining connection
state.