From nobody Thu Sep 7 12:34:07 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 D4169C1516EA for ; Thu, 7 Sep 2023 12:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.61 X-Spam-Level: X-Spam-Status: No, score=-22.61 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 DN5K5LOT0zBn for ; Thu, 7 Sep 2023 12:34:04 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 03422C1516E3 for ; Thu, 7 Sep 2023 12:34:03 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id a1e0cc1a2514c-79a10807b4fso528612241.2 for ; Thu, 07 Sep 2023 12:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1694115243; x=1694720043; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UkHso3ulRETMS4Iyb0wSwQqvHX3TT8Sg5eWE6h59Zxs=; b=JA31GdxeOjfZ8jvSTAi0wO/yoX5KjDI+9TVhytGexTB4BydJa/F4DAfTdqhdQSQp+I YL0YMdl5sSm4H8Wl+gbcLaimQ0HWLXDqr0NtCZ2PZbu34wbswu4qviIutrkfsD9YDOsG 4cCEWzoG1qj1OIbitOoDhCFtZr7L+COEJCFFVpaRQM4QkVrvLDjCZzDQDPL7IStce4QO AAjHTkoS8X8iRSxI57GjTCJQzmVnopDncPRG+CQ9zQwDRt5XNSmEUx3f95KKItZrLHVq 2Uegmi4V2rWRqOTZ85eUgPVpCcev9ODCkQBNszmCu+hEZ72Iw95vLgJMkLalyd44dooy ZUSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694115243; x=1694720043; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UkHso3ulRETMS4Iyb0wSwQqvHX3TT8Sg5eWE6h59Zxs=; b=rR6127tOphWTUxhftirmlYdbxcZ59yP6D8Og03NSFrmujiXon68A6v41npyoFmDG63 3mF+sxMibMifynuknebz27giWjU3Am1otEsmQcBKkyAXbw+5Ad743OHxF4niYgS+Qkiq kzOeeu+fgc3nZr8ZfCJl+ja4GKzWFxkirWUbKVsCiiJRhKM/sbcaon1Mr2NAs5X6RS4F OZ6JyEjESwIIOhDufVJWkRY5d1oF+m+wnc8KSquVbnRKYLnn/wiJuDVHQfjSCHgn+OuU s4hhJ74pEE4PfhOwzz8yh1WD8SG30zyk9LOxan/thAjVzljwRB9nO5VMOJybJoFmGuVs Wu3g== X-Gm-Message-State: AOJu0Ywla8cTRQ4lgehpj57tgW8xOqYDCyYUuzRZxyKja2jwsNPLuDQU WvP1OOHlHFgZ8kAC9cS7gW9OKKhjsf87F1Uov2f1jg== X-Google-Smtp-Source: AGHT+IHxvL0gDOZkrILWKbz5L4I5eM7GJHQpOnTCMUsEL0ZxYoXQjAgc1vnz2BVYRRK1mjWcpwAnQiGoaFbtB5r9+2I= X-Received: by 2002:a67:fd41:0:b0:44d:40b1:926f with SMTP id g1-20020a67fd41000000b0044d40b1926fmr745509vsr.1.1694115242860; Thu, 07 Sep 2023 12:34:02 -0700 (PDT) MIME-Version: 1.0 From: "Devon H. O'Dell" Date: Thu, 7 Sep 2023 15:33:51 -0400 Message-ID: To: Zaheduzzaman Sarker Cc: Michael Welzl , Robert Wilton , The IESG , 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: [Taps] Observability, manageability, and policy in TAPS (was Re: 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: Thu, 07 Sep 2023 19:34:05 -0000 On Thu, Sep 7, 2023 at 8:27=E2=80=AFAM Zaheduzzaman Sarker wrote: > > On Wed, Sep 6, 2023 at 9:31=E2=80=AFPM Devon H. O'Dell wrote: >> >> On Wed, Sep 6, 2023 at 2:35=E2=80=AFPM Michael Welzl wrote: >> > >> > Hi, >> > >> > My 2 cents below - but note, I=E2=80=99m an individual who wasn=E2=80= =99t even a chair, so this is just an =E2=80=9Coutside=E2=80=9D 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=E2=80=99t so much =E2=80=9Cwould = it make sense for the TAPS WG to do this=E2=80=9D but also =E2=80=9Cdo we h= ave enough people here who would move this along=E2=80=9D. >> > As much as I personally like to see your interest, if I were a chair, = I wouldn=E2=80=99t consider keeping a group open because *one* person says = they=E2=80=99d want to continue some work=E2=80=A6 >> >> 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=E2=80=A6 a= host should have a policy system, as implementations do. Nobody volunteere= d to specify it, but we all agreed it would be useful. Another thing that w= ould be useful: more protocol mappings (see the open issues with label =E2= =80=9Cmappings=E2=80=9D in our github). The TAPS documents, as they stand, = will =E2=80=9Cwork=E2=80=9D without these things - this just means that peo= ple are free to implement their own policy manager without guidance, and th= ere=E2=80=99s won=E2=80=99t be conformity in what kind of monitoring inform= ation is being offered (indeed that=E2=80=99s pretty hard to spec, consider= ing that the system is meant to be flexible, even supporting protocols that= might not yet exist=E2=80=A6). Some written guidance would nevertheless be= useful, no doubt, and I hope that volunteers such as yourself can find a h= ome 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. > > > Good to see we are agreeing on the difficulties. > > I think (at least for me) we really need to understand what you meant by = "policy / management / observability" and in what context, at the first pla= ce. Sure, I'll try to clarify definitions and scope. I mean "policy" in reference to individual and aggregate configurations that define or influence the behavior of a TAPS system (like its choices in Connection Establishment, what resolvers to use, or Happy Eyeballs v2 tunables). Here, I do see room for specification along with "management". "Management" refers to an ability to read and mutate the initialization and runtime configuration state of a TAPS system. A concrete goal would be describing an API space implemented by a TAPS provider such that the TAPS system's entire configuration space could be read and re-supplied. "Observability" refers to an ability to read information about TAPS function and its associated resource usage at coarse and fine-grained levels. A concrete goal would be to identify the related needs of TAPS systems stakeholders (network operators, programmers, customers, external systems, security professionals, privacy professionals, support staff, etc) and design a flexible API to service those needs. I mention these terms in aggregate because there's overlap in scope of each. "Reading configuration" could be considered "observability". To this end, a concrete goal would be to understand whether this space can be adequately serviced under a single API surface. In the sense that "policy" refers to systems that consume observability and management APIs to achieve some goal (reliability, performance, cost, etc), I am only considering it as informative towards observability and management APIs. I do not intend to document policy system behavior, nor how or whether such systems ought to interact with TAPS. > Is this only about a TAPS system providing the information about how it i= s functioning and the state it is in? I assumed you meant more than that, i= n a broader sense that a TAPS system provides more APIs to actually query a= nd provide network information to the user of TAPS system. At least Rob was= referring to network failure and state, in his comments. That is why I thi= nk this is not only beyond TAPS working group but also requires broader IET= F discussions to see what can be done. Yes, I intend this to be constrained to APIs for TAPS to report information about its own function and state. I also understood Rob's comment as constrained to this space: I see it highlighting that TAPS APIs abstract over the system resources they consume, and the opacity of this abstraction is problematic in different ways for different stakeholders. I interpreted the specific metrics mentioned as example use-cases rather than a suggestion to require implementers provide any specific metrics at any particular granularity. I'd like to specify the how rather than the what. > To me it feels more like a OPS/INT discussion we want to have to figure o= ut what information we can or want to share with the applications and then = try to figure out the API aspects. I imagine this is true to make sure that such a solution would service the needs of stakeholders in the relevant area. A survey of relevant MIBs could provide an indicator of what kinds of data ought to be considered. I am still not sure that, given a scope constrained to TAPS system implementations, the work belongs in a different area if it becomes chartered. But I'm not sure about much regarding procedure here :). > (May be we should change the email thread title to further discuss this, = now we are into telechat ballot email thread which will be hard to find lat= er if we forget we exchanged our views in this ballot response :-) ) Thanks for the suggestion! I've done this and also removed the drafts-ietf-taps-interface list. I guess please feel free to reply and remove recipients if I've goofed up here :). Kind regards, --dho > > //Zahed