Explicit scoping is now in https://github.com/quicwg/ops-drafts/pull/464
> On 23 Mar 2022, at 11:00, Brian Trammell (IETF) <[email protected]> wrote: > > Hi Al, > > (Snipping a bit of context) > >> On 22 Mar 2022, at 20:51, MORTON JR., AL <[email protected]> wrote: >> >>>> In other words, the set of wire image features that can cause >>>> differential treatment in an operator's network is equal to the set of >>>> wire image features that are freely observable by that operator. >>> see above. there are many reasons a network operator would look at her >>> packets in order to diagnose problems not of her making. >>> >>> -- >>> P Vixie >> [acm] >> >> I think Paul is on the right track with this last sentence. There are >> several limiting assumptions in this thread about operator activities: >> >> + mid-path observations are only one of many ways to contribute to network >> management. Launching QUIC connections from hosts under operator control is >> another. Successful QUIC analysis seems to require different methods than >> with TCP, and that's fine. > > This is entirely missing; indeed, the document treats active measurement > techniques (which I think are quite promising for management of encrypted > transports) as implicitly out of scope. I’m not sure it makes sense to expand > the scope of this doc (intended as a user’s guide to the wire image) in last > call, but perhaps we should add text to make this scope explicit. > >> + the "operator that wants to support QUIC" case seems to be an unexpected >> role (so far). It would be useful to embrace this case in the manageability >> draft, IMO. > > The disconnect in this thread, I think, is related to how large we think the > set of useful passive measurement actions requiring access to data not in the > wire image is. I think that most of these tasks are things we think are > useful with analogy to TCP, because we are *so used* to debugging TCP > dynamics that we have unseen biases toward doing things that way. Indeed, I > think the actual set tends toward empty, in part due to the (theoretical, > perhaps tautological, but not at all meant as a straw man dismissal, > apologies as it came off as such) analysis that the wire image you can see to > troubleshoot is the same wire image your devices can see to break things. > > It would be interesting to dig into specifics to see how wrong I am. I’m not > sure that’s in scope *this* document, though. > > Thanks, cheers, > > Brian
