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. > Cheers, > Michael Kind regards, --dho _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
