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

[Zaheduzzaman Sarker <[e-mail]>]

On Wed, Sep 6, 2023 at 4:29 PM Devon H. O'Dell <dhobsd=
[e-mail]> wrote:

> On Wed, Sep 6, 2023 at 9:56 AM Robert Wilton via Datatracker
> <[e-mail]> 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.


//Zahed