On Thu, Sep 7, 2023 at 8:27 AM Zaheduzzaman Sarker <[email protected]> wrote: > > On Wed, Sep 6, 2023 at 9:31 PM Devon H. O'Dell <[email protected]> wrote: >> >> On Wed, Sep 6, 2023 at 2:35 PM Michael Welzl <[email protected]> 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 _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
