Draft: draft-ietf-quic-manageability

Commentary: note : do n't merge yet , still need to make the pass on applicability but working on the CI issue at the moment 
 done . mergeable if ok . 
 There are a few instances that might be read as normative statements . Is that really wise ? Examples : can not ? Maybe this is n't something that this document needs to say . It could just say that fallback to unencrypted TCP might not be a desirable outcome . There is also a bunch of " MUST"-level statements in the 0 - RTT section , but I 've proposed a rewrite that ( I hope ) eliminates them . 
 Fixed in : removed all 2119 language . 
 Not clear if these documents should use normative language at all . The applicability statement also sometimes uses normative language to recommend the implementation of certain interfaces ; I do n't think this is the right document for that but as we also do n't have another document , we should decide if we want to do that or not ! 
 Manageability is a user 's guide to the wire image , as such there 's no sense to normative language ( though I suppose some might like to add MUST NOT observe packets ) . Since applicability is in part a set of recommendations to application designers , normative language might make sense there ... but the document is informational , so normative language here has to reference or be trivially derived from normative language in one of the base drafts . To simplify things , I 'd just scrub all the SHOULDs , MAYs , and MUSTs .
Paragraph (version A):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
Paragraph (version A):
As soon as the cryptographic context is established, all information
in the QUIC header, including information exposed in the packet
header, is integrity protected.  Further, information that was sent
and exposed in handshake packets sent before the cryptographic
context was established are validated later during the cryptographic
handshake.  Therefore, devices on path MUST NOT change any
information or bits in QUIC packet headers, since alteration of
header information will lead to a failed integrity check at the
receiver, and can even lead to connection termination.
Paragraph (version B):
As soon as the cryptographic context is established, all information
in the QUIC header, including information exposed in the packet
header, is integrity protected.  Further, information that was sent
and exposed in handshake packets sent before the cryptographic
context was established are validated later during the cryptographic
handshake.  Therefore, devices on path cannot alter any information
or bits in QUIC packet headers, since alteration of header
information will lead to a failed integrity check at the receiver,
and can even lead to connection termination.
Paragraph (version A):
QoS mechanisms in the network MAY also use the connection ID for
service differentiation, as a change of connection ID is bound to a
change of address which anyway is likely to lead to a re-route on a
different path with different network characteristics.
Paragraph (version B):
QoS mechanisms in the network could also use the connection ID for
service differentiation, as a change of connection ID is bound to a
change of address which anyway is likely to lead to a re-route on a
different path with different network characteristics.
Paragraph (version A):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all
capitals, as shown here.