Re: [Taps] Robert Wilton's Yes on draft-ietf-taps-interface-22: (with COMMENT)

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

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.

> Cheers,
> Michael

Kind regards,

--dho