Hi, My 2 cents below - but note, I’m an individual who wasn’t even a chair, so this is just an “outside” opinion:
> On Sep 6, 2023, at 5:59 PM, Devon H. O'Dell <dho...@google.com> wrote: > > On Wed, Sep 6, 2023 at 11:02 AM Zaheduzzaman Sarker > <zahed.sarker.i...@gmail.com <mailto:zahed.sarker.i...@gmail.com>> wrote: >> On Wed, Sep 6, 2023 at 4:29 PM Devon H. O'Dell >> <dhobsd=40google....@dmarc.ietf.org> wrote: >>> >>> On Wed, Sep 6, 2023 at 9:56 AM Robert Wilton via Datatracker >>> <nore...@ietf.org> wrote: >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> Hi, >>>> >>>> Moderate level comments: >>>> >>>> (1) As per the architecture doc, I think that it is great that you are >>>> defining >>>> a new transport API. I note that this API doesn't really include any >>>> standard >>>> APIs or structures to monitor the state of the transport sessions for a >>>> given >>>> application (i.e., API user). E.g., how many connections are currently >>>> open, >>>> total number of connections (since library was initialized), number of >>>> errored >>>> transport connections, drops, mtu issues, flow rates, etc. I think that >>>> with >>>> some of the changes to the Internet architecture (e.g., QUIC to cite one >>>> obvious example), it reduces the ability for network operators to monitor >>>> and >>>> debug network issues between applications. A potential corollary of this >>>> is >>>> that a lot more debug and diagnostics information will need to be made >>>> available to applications in a common way to allow application support >>>> staff, >>>> and users of those applications to better understand where in the network >>>> issues and failures are happening. It would seem unreasonable for me to >>>> hold a >>>> discuss on this document for what might be a lot of work and discussion >>>> that >>>> could take a long time to resolve but I hope that the authors and WG will >>>> consider whether there is further useful future work required in additional >>>> RFCs. >>> >>> Thanks for bringing this up. It's indeed a huge subject and I agree >>> that it's a topic for additional publications. I had intended to >>> discuss this in the interim in May, but I was unfortunately unable to >>> attend last-minute. I see the observability space as related to >>> configuration / discoverability / policy topics. >> >> >> You have rightly identified this as a "huge subject" and it will need more >> work on technical gap analysis, security analysis and involvement from other >> expertise areas before we can take on the work and publish them. This, to >> me, goes beyond the transport services defined as in the TAPS and current >> TAPS charter scope. It would also need broader IETF discussion to understand >> views. >> >>> >>> >>> It appears in the minutes of that meeting[1] that Zahed still prefers >>> to close the WG. I'm still very much interested in exploring this >>> space. What's the best path forward on this topic? >> >> >> I think we should have a separate discussion on the topics you are >> interested in to find out what is the best way forward, rather tie it only >> to TAPS. I will be more than happy to discuss with you about it and I think >> Rob and others can also help to figure out the right things do here. > > Sounds good. > > FWIW, I think there's quite a lot of value in limiting the scope to TAPS: > > 1. Observability in the broader scope is largely covered by SNMP. > 2. Trying to solve for this in underlying systems will only yield the > aggregate resource usage of the Transport Services implementation and > the results of its choices. > 3. I think there's great value (especially in the debugging domain) > for application and network stack programmers to have well-defined > ways to observe and manage their systems. > 4. Increasing the scope outside of TAPS requires influencing too many > mature systems with specific solutions. > > If one wanted to go about solving the observability issue using SNMP, > though one might define a MIB, having a defined means to query the > implementation would help that effort. Without guidance of how to peer > in, implementations will diverge in this regard. It would be > unfortunate if people became skilled in specific TAPS implementations > due to external factors like environment debugging support. > > I agree this is outside the scope of the current charter, but I think > these issues are in the spirit of what the WG wanted to achieve. Happy > to move the discussion if it's better held elsewhere! 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… 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. Cheers, Michael
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
