From nobody Wed Sep 6 09:01:04 2023 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D0BC151554 for ; Wed, 6 Sep 2023 09:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.607 X-Spam-Level: X-Spam-Status: No, score=-17.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LhL4c34VIIr for ; Wed, 6 Sep 2023 09:00:56 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591D2C1522D3 for ; Wed, 6 Sep 2023 09:00:12 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id ada2fe7eead31-45088c95591so91190137.3 for ; Wed, 06 Sep 2023 09:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1694016011; x=1694620811; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KvL78UaKKScRfruXI+0JYaeUv2//npbU/m5lB1JJ7Tg=; b=yHC94IgMC5K+0fHedV1pydTv0Vn8v25NtlyHdwmbWUsvm546vitMDN4j9aivDGVlID SGm0YCXsYwJTxSXGShD9Hnsn0iVfXQCa0omtnJoWggMR/v2pIrw28aejmHyk8ovDxk7p XNXlUmOZrGcGpWjua79q4c3n7CiLLGVPFCKGDeNH6RXy1mP/w/U7QsVjB+C3jc2kkRst aSVeLYAAQuy0jyKSXInP3b/omH4uyp8SF0BtzJRCe+jV9m2Sl8F9BOmEHqgGLqyBHYR4 SyBMvahQQ7VM1FPs1MzBFAzefYO0bsajryNckO397wxosx+aRM5/bBjMekF1dUg9btOQ 2QbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694016011; x=1694620811; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KvL78UaKKScRfruXI+0JYaeUv2//npbU/m5lB1JJ7Tg=; b=fdrnWz0tvrmP6JD44dzmBATFWSTvxiiLKr2lbHXCFHWsv5mYdzI6lQ2BAwWoGneMkF vKQADshXodvOSmVPbDWKO70eZWC5mUNpuK+dD1wsI7zAxWkOaskWfaPv1hj5WZuD4JkG M6N0pw3pzqgWnbHh7a/6ie8MZGETRHKURKghub5ckdbNVZx2wiYg0K8ld0J9ExtuJvn4 8suBRzMvHINXM9t+rNPpzqHDBM8xHtVJorosx/YHuaUHB+A6hJDpamFtdIO8+3eGPe3C hQWeixmvj2epyR5OMuK+J+mSmN5WspIqODseNyPrOMPZ/Itf1B+zZuKRoi/El4dX4/UT xXgA== X-Gm-Message-State: AOJu0YwrFtaItwOvBWa5fZ9pa6xo05325mAkpjMQds0suH21t8F5POTJ iVaySE5Xahs3FGMhEdixGqjWEUzKXb8NLJeOlNTxNA== X-Google-Smtp-Source: AGHT+IHN1crEdeB/VWKlSDCyVLBJGIyDnjaZij3KQl2Z7+EibDfIpSamVWmtfOOI2ikQmdngYFyYL9VaCP02iyNjBKQ= X-Received: by 2002:a67:fc93:0:b0:44e:a9b6:5298 with SMTP id x19-20020a67fc93000000b0044ea9b65298mr3414203vsp.24.1694016010878; Wed, 06 Sep 2023 09:00:10 -0700 (PDT) MIME-Version: 1.0 References: <169400859112.20072.5328867108981284361@ietfa.amsl.com> In-Reply-To: From: "Devon H. O'Dell" Date: Wed, 6 Sep 2023 11:59:59 -0400 Message-ID: To: Zaheduzzaman Sarker Cc: "Devon H. O'Dell" , Robert Wilton , The IESG , draft-ietf-taps-interface@ietf.org, taps-chairs@ietf.org, taps@ietf.org, anna.brunstrom@kau.se Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] Robert Wilton's Yes on draft-ietf-taps-interface-22: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2023 16:01:00 -0000 On Wed, Sep 6, 2023 at 11:02=E2=80=AFAM Zaheduzzaman Sarker wrote: > On Wed, Sep 6, 2023 at 4:29=E2=80=AFPM Devon H. O'Dell wrote: >> >> On Wed, Sep 6, 2023 at 9:56=E2=80=AFAM Robert Wilton via Datatracker >> 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 currentl= y open, >> > total number of connections (since library was initialized), number of= errored >> > transport connections, drops, mtu issues, flow rates, etc. I think th= at with >> > some of the changes to the Internet architecture (e.g., QUIC to cite o= ne >> > obvious example), it reduces the ability for network operators to moni= tor and >> > debug network issues between applications. A potential corollary of t= his 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 netw= ork >> > 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 discussio= n that >> > could take a long time to resolve but I hope that the authors and WG w= ill >> > consider whether there is further useful future work required in addit= ional >> > 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 mor= e work on technical gap analysis, security analysis and involvement from ot= her 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 curren= t TAPS charter scope. It would also need broader IETF discussion to underst= and 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 intere= sted in to find out what is the best way forward, rather tie it only to TAP= S. I will be more than happy to discuss with you about it and I think Rob a= nd 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! Kind regards, --dho > //Zahed > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps