[Taps] Observability, manageability, and policy in TAPS (was Re: Robert Wilton's Yes on draft-ietf-taps-interface-22: (with COMMENT))

["Devon H. O'Dell" <[e-mail]>]

On Thu, Sep 7, 2023 at 8:27 AM Zaheduzzaman Sarker
<[e-mail]> wrote:
>
> On Wed, Sep 6, 2023 at 9:31 PM Devon H. O'Dell <[e-mail]> wrote:
>>
>> On Wed, Sep 6, 2023 at 2:35 PM Michael Welzl <[e-mail]> wrote:
>> >
>> > Hi,
>> >
>> > My 2 cents below - but note, I’m an individual who wasn’t even a chair, so this is just an “outside” opinion:
>>
>> Appreciate it. I don't have much experience collaborating formally
>> within the IETF, so this is all useful information. I just hope not to
>> be detracting from the goals of this thread!
>>
>> > [snip]
>> > From what I gathered, the issue wasn’t so much “would it make sense for the TAPS WG to do this” but also “do we have enough people here who would move this along”.
>> > As much as I personally like to see your interest, if I were a chair, I wouldn’t consider keeping a group open because *one* person says they’d want to continue some work…
>>
>> Yep, agreed. It'd be great if folks from the WG wanted to join in. It
>> sounds like that may not be likely. I do have some folks in mind who
>> may be interested in collaborating and I look forward to hearing how
>> that might proceed.
>>
>> > I very much agree that it would be useful to document / specify these things, but that goes for more things - e.g., the policy manager… a host should have a policy system, as implementations do. Nobody volunteered to specify it, but we all agreed it would be useful. Another thing that would be useful: more protocol mappings (see the open issues with label “mappings” in our github). The TAPS documents, as they stand, will “work” without these things - this just means that people are free to implement their own policy manager without guidance, and there’s won’t be conformity in what kind of monitoring information is being offered (indeed that’s pretty hard to spec, considering that the system is meant to be flexible, even supporting protocols that might not yet exist…). Some written guidance would nevertheless be useful, no doubt, and I hope that volunteers such as yourself can find a home for them somewhere in the IETF.
>>
>> Agree on the difficulty. It highlights another advantage of
>> constraining to TAPS, which is that some of these problems are already
>> solved "in spirit". Following a similar API design approach (small
>> surface, flexible inputs) seems like a promising direction for any of
>> these areas of policy / management / observability.
>
>
> Good to see we are agreeing on the difficulties.
>
> I think (at least for me) we really need to understand what you meant by "policy / management / observability" and in what context, at the first place.

Sure, I'll try to clarify definitions and scope.

I mean "policy" in reference to individual and aggregate
configurations that define or influence the behavior of a TAPS system
(like its choices in Connection Establishment, what resolvers to use,
or Happy Eyeballs v2 tunables). Here, I do see room for specification
along with "management".

"Management" refers to an ability to read and mutate the
initialization and runtime configuration state of a TAPS system. A
concrete goal would be describing an API space implemented by a TAPS
provider such that the TAPS system's entire configuration space could
be read and re-supplied.

"Observability" refers to an ability to read information about TAPS
function and its associated resource usage at coarse and fine-grained
levels. A concrete goal would be to identify the related needs of TAPS
systems stakeholders (network operators, programmers, customers,
external systems, security professionals, privacy professionals,
support staff, etc) and design a flexible API to service those needs.

I mention these terms in aggregate because there's overlap in scope of
each. "Reading configuration" could be considered "observability". To
this end, a concrete goal would be to understand whether this space
can be adequately serviced under a single API surface.

In the sense that "policy" refers to systems that consume
observability and management APIs to achieve some goal (reliability,
performance, cost, etc), I am only considering it as informative
towards observability and management APIs. I do not intend to document
policy system behavior, nor how or whether such systems ought to
interact with TAPS.

> Is this only about a TAPS system providing the information about how it is functioning and the state it is in? I assumed you meant more than that, in a broader sense that a TAPS system provides more APIs to actually query and provide network information to the user of TAPS system. At least Rob was referring to network failure and state, in his comments. That is why I think this is not only beyond TAPS working group but also requires broader IETF discussions to see what can be done.

Yes, I intend this to be constrained to APIs for TAPS to report
information about its own function and state. I also understood Rob's
comment as constrained to this space: I see it highlighting that TAPS
APIs abstract over the system resources they consume, and the opacity
of this abstraction is problematic in different ways for different
stakeholders. I interpreted the specific metrics mentioned as example
use-cases rather than a suggestion to require implementers provide any
specific metrics at any particular granularity. I'd like to specify
the how rather than the what.

> To me it feels more like a OPS/INT discussion we want to have to figure out what information we can or want to share with the applications and then try to figure out the API aspects.

I imagine this is true to make sure that such a solution would service
the needs of stakeholders in the relevant area. A survey of relevant
MIBs could provide an indicator of what kinds of data ought to be
considered. I am still not sure that, given a scope constrained to
TAPS system implementations, the work belongs in a different area if
it becomes chartered. But I'm not sure about much regarding procedure
here :).

> (May be we should change the email thread title to further discuss this, now we are into telechat ballot email thread which will be hard to find later if we forget we exchanged our views in this ballot response :-) )

Thanks for the suggestion! I've done this and also removed the
drafts-ietf-taps-interface list. I guess please feel free to reply and
remove recipients if I've goofed up here :).

Kind regards,

--dho

>
> //Zahed