Re: Opsdir last call review of draft-ietf-quic-manageability-14

["Brian Trammell (IETF)" <[e-mail]>]

Explicit scoping is now in https://github.com/quicwg/ops-drafts/pull/464

> On 23 Mar 2022, at 11:00, Brian Trammell (IETF) <[e-mail]> wrote:
> 
> Hi Al,
> 
> (Snipping a bit of context)
> 
>> On 22 Mar 2022, at 20:51, MORTON JR., AL <[e-mail]> 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