Draft: draft-ietf-quic-manageability

Commentary: This brings the ops drafts into line with the base ones . The configuration ( , Makefile , .editorconfig ) is copied over . I removed trailing whitespace from the drafts and reflowed paragraphs . I changed the references so that they are a little cleaner . Other than the reflow , I did n't touch the text , other than to change " section " to " Section " where I noticed some errors . 
 thanks !
Paragraph (version A):
QUIC I-D.ietf-quic-transport is a new transport protocol currently
under development in the IETF quic working group, focusing on support
of semantics as needed for HTTP/2 I-D.ietf-quic-http.  Based on
current deployment practices, QUIC is encapsulated in UDP and
encrypted by default.  The current version of QUIC integrates TLS I-
D.ietf-quic-tls to encrypt all payload data and most control
information.  Given QUIC is an end-to-end transport protocol, all
information in the protocol header, even that which can be inspected,
is is not meant to be mutable by the network, and will therefore be
integrity-protected to the extent possible.
Paragraph (version B):
QUIC QUIC is a new transport protocol currently under development in
the IETF quic working group, focusing on support of semantics as
needed for HTTP/2 QUIC-HTTP.  Based on current deployment practices,
QUIC is encapsulated in UDP and encrypted by default.  The current
version of QUIC integrates TLS QUIC-TLS to encrypt all payload data
and most control information.  Given QUIC is an end-to-end transport
protocol, all information in the protocol header, even that which can
be inspected, is is not meant to be mutable by the network, and will
therefore be integrity-protected to the extent possible.
Paragraph (version A):
This document is focused on the protocol as presently defined in I-
D.ietf-quic-transport and I-D.ietf-quic-tls, and will change to track
those documents.
Paragraph (version A):
The QUIC packet header is under active development; see section 5 of
I-D.ietf-quic-transport for the present header structure.
Paragraph (version B):
This document is focused on the protocol as presently defined in QUIC
and QUIC-TLS, and will change to track those documents.
Paragraph (version B):
The QUIC packet header is under active development; see section 5 of
QUIC for the present header structure.
Paragraph (version A):
section 7.6 of I-D.ietf-quic-transport.
Paragraph (version B):
Section 7.6 of QUIC.
Paragraph (version A):
Stateful network devices such as firewalls use exposed header
information to support state setup and tear-down.  I-D.trammell-plus-
statefulness provides a general model for in-network state management
on these devices, independent of transport protocol.  Features
already present in QUIC may be used for state maintenance in this
model.  Here, there are two important goals: distinguishing valid
QUIC connection establishment from other traffic, in order to
establish state; and determining the end of a QUIC connection, in
order to tear that state down.
Paragraph (version A):
Both, 1-RTT and O-RTT connection establishment, using a TLS handshake
on stream 0, is detectable using heuristics similar to those used to
detect TLS over TCP. 0-RTT connection may additional also send data
packets, right after the client hello.  These data may be reorder in
the network, therefore it may be possible that 0-RTT Protected data
packet are seen before the Client Initial packet.
Paragraph (version B):
Stateful network devices such as firewalls use exposed header
information to support state setup and tear-down.  STATEFULNESS
provides a general model for in-network state management on these
devices, independent of transport protocol.  Features already present
in QUIC may be used for state maintenance in this model.  Here, there
are two important goals: distinguishing valid QUIC connection
establishment from other traffic, in order to establish state; and
determining the end of a QUIC connection, in order to tear that state
down.
Paragraph (version B):
Both, 1-RTT and O-RTT connection establishment, using a TLS handshake
on stream 0, is detectable using heuristics similar to those used to
detect TLS over TCP.  0-RTT connection may additional also send data
packets, right after the client hello.  These data may be reorder in
the network, therefore it may be possible that 0-RTT Protected data
packet are seen before the Client Initial packet.
Paragraph (version A):
If the QUIC handshake was not observed by the defense system, the
connection ID can be used as a confirmation signal as per I-
D.trammell-plus-statefulness if present in both directions.
Paragraph (version B):
If the QUIC handshake was not observed by the defense system, the
connection ID can be used as a confirmation signal as per
STATEFULNESS if present in both directions.
Paragraph (version A):
Load balancers may cooperate with servers or server pools behind them
to use a server-generated Connection ID value, in order to support
stateless load balancing, even across NAT rebinding or other address
change events (see rebinding).  See section 5.7 of I-D.ietf-quic-
transport.
Paragraph (version B):
Load balancers may cooperate with servers or server pools behind them
to use a server-generated Connection ID value, in order to support
stateless load balancing, even across NAT rebinding or other address
change events (see rebinding).  See section 5.7 of QUIC.
Paragraph (version A):
QUIC I-D.ietf-quic-transport is a new transport protocol currently
under development in the IETF quic working group, focusing on support
of semantics as needed for HTTP/2 I-D.ietf-quic-http such as stream-
multiplexing to avoid head-of-line blocking.  Based on current
deployment practices, QUIC is encapsulated in UDP.  The version of
QUIC that is currently under development will integrate TLS 1.3 I-
D.ietf-quic-tls to encrypt all payload data and most control
information.
Paragraph (version A):
This document provides guidance for application developers that want
to use the QUIC protocol without implementing it on their own.  This
includes general guidance for application use of HTTP/2 over QUIC as
well as the use of other application layer protocols over QUIC.  For
specific guidance on how to integrate HTTP/2 with QUIC, see I-D.ietf-
quic-http.
Paragraph (version B):
QUIC QUIC is a new transport protocol currently under development in
the IETF quic working group, focusing on support of semantics as
needed for HTTP/2 QUIC-HTTP such as stream-multiplexing to avoid
head-of-line blocking.  Based on current deployment practices, QUIC
is encapsulated in UDP.  The version of QUIC that is currently under
development will integrate TLS 1.3 TLS13 to encrypt all payload data
and most control information.
Paragraph (version B):
This document provides guidance for application developers that want
to use the QUIC protocol without implementing it on their own.  This
includes general guidance for application use of HTTP/2 over QUIC as
well as the use of other application layer protocols over QUIC.  For
specific guidance on how to integrate HTTP/2 with QUIC, see QUIC-
HTTP.
Paragraph (version A):
QUIC provides for 0-RTT connection establishment (see section 3.2 of
I-D.ietf-quic-transport).  This presents opportunities and challenges
for applications using QUIC.
Paragraph (version B):
QUIC provides for 0-RTT connection establishment (see section 3.2 of
QUIC).  This presents opportunities and challenges for applications
using QUIC.
Paragraph (version A):
However, data in the frames contained in 0-RTT packets of a such a
connection must be treated specially by the application layer.
Replay of these packets can cause the data to processed twice.  This
is further described in I-D.nottingham-httpbis-retry.
Paragraph (version B):
However, data in the frames contained in 0-RTT packets of a such a
connection must be treated specially by the application layer.
Replay of these packets can cause the data to processed twice.  This
is further described in HTTP-RETRY.
Paragraph (version A):
Stream prioritization is not exposed to the network, nor to the
receiver.  Prioritization can be realized by the sender and the QUIC
transport should provide and interface for applications to prioritize
streams I-D.ietf-quic-transport.
Paragraph (version A):
Priority handling of retransmissions may be implemented by the sender
in the transport layer and I-D.ietf-quic-transport does not specify a
specific way how this must be handled.  Currently QUIC only provides
fully reliable stream transmission, and as such prioritization of
retransmission is likely beneficial.  For not fully reliable streams
priority scheduling of retransmissions over data of higher-priority
streams might not be desired.  In this case QUIC could also provide
an interface or derive the prioritization decision from the
reliability level of the stream.
Paragraph (version B):
Stream prioritization is not exposed to the network, nor to the
receiver.  Prioritization can be realized by the sender and the QUIC
transport should provide and interface for applications to prioritize
streams QUIC.
Paragraph (version B):
Priority handling of retransmissions may be implemented by the sender
in the transport layer and QUIC does not specify a specific way how
this must be handled.  Currently QUIC only provides fully reliable
stream transmission, and as such prioritization of retransmission is
likely beneficial.  For not fully reliable streams priority
scheduling of retransmissions over data of higher-priority streams
might not be desired.  In this case QUIC could also provide an
interface or derive the prioritization decision from the reliability
level of the stream.
Paragraph (version A):
QUIC supports a server-generated Connection ID, transmitted to the
client during connection establishment: see section 5.7 of I-D.ietf-
quic-transport Servers behind load balancers should propose a
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 needing
information about every specific flow it is forwarding.
Paragraph (version B):
QUIC supports a server-generated Connection ID, transmitted to the
client during connection establishment: see Section 5.7 of QUIC
Servers behind load balancers should propose a 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 needing information about every
specific flow it is forwarding.
Paragraph (version A):
A new version could use an encryption scheme other than TLS 1.3 or
higher.  I-D.ietf-quic-transport specifies requirements for the
cryptographic handshake as currently realized by TLS 1.3 and
described in a separate specification I-D.ietf-quic-tls.  This split
is performed to enable light-weight versioning with different
cryptographic handshakes.
Paragraph (version B):
A new version could use an encryption scheme other than TLS 1.3 or
higher.  QUIC specifies requirements for the cryptographic handshake
as currently realized by TLS 1.3 and described in a separate
specification QUIC-TLS.  This split is performed to enable light-
weight versioning with different cryptographic handshakes.
Paragraph (version A):
See the security considerations in I-D.ietf-quic-transport and I-
D.ietf-quic-tls; the security considerations for the underlying
transport protocol are relevant for applications using QUIC, as well.
Paragraph (version B):
See the security considerations in QUIC and QUIC-TLS; the security
considerations for the underlying transport protocol are relevant for
applications using QUIC, as well.