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. 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. 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. (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 :-) ) //Zahed
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
