Original text:
also discusses how common network management practices will be impacted by QUIC. <del> Of course, network management is not a one-size-fits-all endeavour: practices considered necessary or even mandatory within enterprise networks with certain compliance requirements, for example, would be </del>  impermissible on other networks without those requirements.  This document therefore does not make any specific recommendations as to which practices should or should not be applied; for each practice, In this section, we discusses those aspects of the QUIC transport protocol that have an impact on the design and operation of devices <del> that forward QUIC packets.  Here, we are concerned primarily with QUIC's unencrypted wire image WIRE-IMAGE, which we define as the information available in the packet header in each QUIC packet, and the dynamics of that information.  Since QUIC is a versioned </del>  protocol, the wire image of the header format can also change from version to version.  However, at least the mechanism by which a receiver can determine which version is used and the meaning and

Reviewer comments:
Feel free to close this if it's out of scope, but creating a proxy that attempts to passively observe QUIC is much more complex and potentially problematic than TLS over TCP. For example, all major OS's have mature TCP implementations, whereas a MITM would have to pull in its own QUIC implementation. If it does so, it would be important that's it's both conformant to IETF specifications and have good performance. This is the full L7 termination case, which is possible, but a lot of work, and we should heavily encourage anyone doing this to use an existing("good") implementation. A potential MITM option is to attempt to terminate the handshake, but then only observe ApplicationData packets. However, this could go wrong in many ways, so I believe it should be strongly discouraged. QUIC is designed as an end-to-end protocol and efforts to change that are likely to end very poorly. For example, if the length of the CID changes, then the offset of the header changes and a middlebox who doesn't track all CIDs both peers may be unable to decrypt packets. I'm sure there are more gotchas, particularly with the introduction of extensions. It may also be worth pointing out that QUIC frames are not TLV, so any frames(ie: extensions) that are not understood cause all other frames to be unparseable. Thanks to NAME for the specific examples of ways this could fail.
Still trying to figure out what my thinking is her, but it sounds a bit like you propose something like "If you want to implement a QUIC MITM, please terminate the whole connection up to L7 and use an existing library." Note sure that is actually giving quite there right message....
As a user's guide to the wire image, one of the base assumptions we make is that access to the wire image is read only. We should definitely be more explicit about this. We also need an explicit statement that MITM is out of scope for this doc and if you want to, terminate at L7 and congrats, now everything in -transport and -tls (and, realisitically, -http) applies.

Revised text:
also discusses how common network management practices will be impacted by QUIC.  <ins> Since QUIC's wire image WIRE-IMAGE is integrity protected and not modifiable on path, in-network operations are not possible without terminating the QUIC connection, for instance using a back-to-back proxy.  Proxy operations are not in scope for this document.  QUIC proxies must be fully-fledged QUIC endpoints, implementing the transport as defined in QUIC-TRANSPORT and QUIC-TLS as well as proxy- relevant semantics for the application(s) running over QUIC (e.g. HTTP/3 as defined in QUIC-HTTP). Network management is not a one-size-fits-all endeavour: practices considered necessary or even mandatory within enterprise networks with certain compliance requirements, for example, would be </ins> impermissible on other networks without those requirements.  This document therefore does not make any specific recommendations as to which practices should or should not be applied; for each practice, In this section, we discusses those aspects of the QUIC transport protocol that have an impact on the design and operation of devices  <ins> that forward QUIC packets.  Here, we are concerned primarily with the unencrypted part of QUIC's wire image WIRE-IMAGE, which we define as the information available in the packet header in each QUIC packet, and the dynamics of that information.  Since QUIC is a versioned </ins> protocol, the wire image of the header format can also change from version to version.  However, at least the mechanism by which a receiver can determine which version is used and the meaning and