Re: [Taps] Éric Vyncke's Discuss on draft-ietf-taps-arch-18: (with DISCUSS and COMMENT)
Aaron Falk <aaron.falk@gmail.com> Mon, 04 September 2023 21:04 UTC
Return-Path: <aaron.falk@gmail.com>
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 D97EEC15EF28; Mon, 4 Sep 2023 14:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.005
X-Spam-Level:
X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 tzMjdIpguJPD; Mon, 4 Sep 2023 14:04:24 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 A9BD0C151087; Mon, 4 Sep 2023 14:04:24 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-2bcb89b476bso27985751fa.1; Mon, 04 Sep 2023 14:04:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693861462; x=1694466262; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AX9bP5lNn7UXH+kyaVUpWHvQB5eBckWM01s8SHAd+CE=; b=PnPwkZ3lHtGe1xj4Lz7CBoGoBTJnq56Spx169eQL3kLCOkZ0gCvJ7iaghxhqqxN1nq 1vnZ9jD2GkYy6A2siOe6DG/6Rmqxn7MJeCix2FKdrvAE43VSEYXTUoatemllYk7gt0qk 0aCrQ7aoxFJNX9RrDWrdL+a+Sbf5dXFexYZaiMyjqKSOD++GmDR/GXArytZCsbRHpFIS 1wiWTe5Ad5G8C1NbQRvHbQIAJYhMUXE+Sno4IM/Z0X7IlHV2JErdMc2DKFGgsxxLthdu WNUP4kASP5XHzqbIEu2jRz2PI3LX4qewXl8+ypwKw9TOjcY5Wy0G31ajQjXNwpqow4Dj UGwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693861462; x=1694466262; h=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=AX9bP5lNn7UXH+kyaVUpWHvQB5eBckWM01s8SHAd+CE=; b=ed+dqB9xQPUWFSMcZ0KiXPdegYduztj9H0lJjwpvKP3/qm/U5MYTs/H/yZtyd3Z1sI 6W/TdNVm00kxVpHIEPiGhLm6SwuybTQ4P/AU6Wb5k2kUaa37lchHJbTDSub0qV84GNLy ys7cwdPv1f7pWaK+snxBZE6DvYTQ80Q+3nFz3pi9HQKqgt64FPEpTG4fknPDOjDPcozi W/m/oYCtbCIMbQoyL7VGh6VyeuHB3FLTm/rv9BO9zO/0bZxxVrHd32h8rGCnSv+fYkbm W7FOgeY38bwk1CroiIgO6GwK6fKHKWINht4KUiySoCHBSY9mNOmFD0g1fQX21cHxBGa6 NUGQ==
X-Gm-Message-State: AOJu0YzA8O46DiwtmVOXeyV/77jL4MfYDJx7YojsgjUZFnMRPh4Dfg4f z3cxkOCcB3peMsarw/BKh+iXGK51vgPOyLvj+I0=
X-Google-Smtp-Source: AGHT+IEIQ/FnP0FvDhTZa6ZBrwXT79g0NzrwJtRWe2QqyD541kTOLgfGtIo3ZzveJ1raSAwwGl3pW4nsj+k82mnnYAU=
X-Received: by 2002:a2e:7819:0:b0:2bc:b815:d64d with SMTP id t25-20020a2e7819000000b002bcb815d64dmr7820796ljc.30.1693861461635; Mon, 04 Sep 2023 14:04:21 -0700 (PDT)
MIME-Version: 1.0
References: <169321963459.52820.17905626018364439033@ietfa.amsl.com> <C4797CCC-C6A7-44F3-A616-86B9352BAB17@ifi.uio.no> <3DCD6C58-7342-4C28-BDA7-65EAFD009096@ericsson.com> <EF3B0847-FE70-4B18-B808-81939115C540@cisco.com> <CAEh=tceBfe86s1n8c2nk-P6mFH_OBLQE4wFnEgLZ0aNgUi+tUg@mail.gmail.com> <041C30F4-6F51-45F2-996C-F47065B29885@ericsson.com>
In-Reply-To: <041C30F4-6F51-45F2-996C-F47065B29885@ericsson.com>
From: Aaron Falk <aaron.falk@gmail.com>
Date: Mon, 04 Sep 2023 14:04:11 -0700
Message-ID: <CAD62q9VHfQ4z6e4qDSDgCF9=Uz6X+OoxZ8O5i2BU5Vey5k84fQ@mail.gmail.com>
To: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
Cc: Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>, "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>, Michael Welzl <michawe@ifi.uio.no>, The IESG <iesg@ietf.org>, "draft-ietf-taps-arch@ietf.org" <draft-ietf-taps-arch@ietf.org>, "taps-chairs@ietf.org" <taps-chairs@ietf.org>, "taps@ietf.org" <taps@ietf.org>, "bevolz@gmail.com" <bevolz@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000b838b206048edaeb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/U5Af49634_r4p8Cyve3QJeAKRGg>
Subject: Re: [Taps] Éric Vyncke's Discuss on draft-ietf-taps-arch-18: (with DISCUSS and COMMENT)
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Sep 2023 21:04:28 -0000
I don't have too much to add beyond Mirja's point. The working group felt strongly that TAPS could not be correctly implemented without reading the architecture document. Further https://www.ietf.org/standards/process/informational-vs-experimental/ says: An "Informational" specification is published for the general information > of the Internet community, and does not represent an Internet community > consensus or recommendation. Neither of which accurately describe the doc. Like Mirja, I'm open to tweaking the title although I think something like "An Architecture for Transport Services (Read This First)" would be more useful than adding the term "Requirements" but YMMV. --aaron On Mon, Sep 4, 2023 at 8:57 AM Mirja Kuehlewind < mirja.kuehlewind@ericsson.com> wrote: > Hi Eric, > > > > the use of normative language is separate from your discussion point (on > intended status), right? > > > > I just want to mention that there was also quite extensive discussion > about this in the working group. And as you say correctly there are some > requirements in this document, and we decided to use normative language to > highlight that. So I don’t think simply just removing the normative > language is providing anybody a service. > > > > Therefore, I guess your question really is should this document be called > “architecture and requirements”. I don’t have a strong opinion here but I > also don’t think it would make the document any better. The main focus is > on the architecture. Also note that these requirements are not requirements > for the design of the API (as we often do for requirement doc in the IETF) > but requirement for the deployment of this architecture. And therefore, > fully in the scope of an architecture document (without explicitly stating > this in the title). > > > > Mirja > > > > > > > > *From: *Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com> > *Date: *Monday, 4. September 2023 at 17:25 > *To: *"Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org> > *Cc: *Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, Michael Welzl < > michawe@ifi.uio.no>, The IESG <iesg@ietf.org>, " > draft-ietf-taps-arch@ietf.org" <draft-ietf-taps-arch@ietf.org>, " > taps-chairs@ietf.org" <taps-chairs@ietf.org>, "taps@ietf.org" < > taps@ietf.org>, "bevolz@gmail.com" <bevolz@gmail.com> > *Subject: *Re: [Taps] Éric Vyncke's Discuss on draft-ietf-taps-arch-18: > (with DISCUSS and COMMENT) > > > > Hi Eric, > > > > Sure, lets discuss this during the telechat. In the mean time if you can > provide more information on the exact separation and definition of > architecture I-D vs requirements I-D, hopefully in some sort of > documentation with consensus , that would be helpful. > > > > //Zahed > > > > On Mon, Sep 4, 2023 at 4:07 PM Eric Vyncke (evyncke) <evyncke= > 40cisco.com@dmarc.ietf.org> wrote: > > Let's have a chat (aka discussion) during the IESG telechat on Thursday > with the AD (and authors/shepherd if they want to join). My own preference > is to avoid normative language in an architecture I-D, else it becomes a > 'requirements' I-D. > > > > Regards, > > > > -éric > > > > *From: *Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> > *Date: *Monday, 4 September 2023 at 15:56 > *To: *Michael Welzl <michawe@ifi.uio.no>, Eric Vyncke <evyncke@cisco.com> > *Cc: *The IESG <iesg@ietf.org>, "draft-ietf-taps-arch@ietf.org" < > draft-ietf-taps-arch@ietf.org>, "taps-chairs@ietf.org" < > taps-chairs@ietf.org>, "taps@ietf.org" <taps@ietf.org>, "bevolz@gmail.com" > <bevolz@gmail.com> > *Subject: *Re: [Taps] Éric Vyncke's Discuss on draft-ietf-taps-arch-18: > (with DISCUSS and COMMENT) > > > > Hi Eric, > > > > Michael, thanks for digging up the minutes. > > > > In my memory I think there was also at the end a strong sense in the room > to have all doc the same intended status. In my view these docs really > belong closely together and as an implementer you really need all three of > them. The reason for the split up is maybe more a service for > non-implementors. E.g. if you only want to understand the interface in > order to use it, it’s probably enough if you read the arch and the API doc. > If you only want to get a high-level idea what taps is, you might read only > the arch doc. > > > > Mirja > > > > > > > > *From: *Taps <taps-bounces@ietf.org> on behalf of Michael Welzl < > michawe@ifi.uio.no> > *Date: *Monday, 4. September 2023 at 10:19 > *To: *Éric Vyncke <evyncke@cisco.com> > *Cc: *The IESG <iesg@ietf.org>, "draft-ietf-taps-arch@ietf.org" < > draft-ietf-taps-arch@ietf.org>, "taps-chairs@ietf.org" < > taps-chairs@ietf.org>, "taps@ietf.org" <taps@ietf.org>, "bevolz@gmail.com" > <bevolz@gmail.com> > *Subject: *Re: [Taps] Éric Vyncke's Discuss on draft-ietf-taps-arch-18: > (with DISCUSS and COMMENT) > > > > Dear Éric, > > > > Many thanks for your thoughtful review! Regarding the DISCUSS point, > which is about the intended status of the architecture document: > > > > First, my apologies. In my shepherd write-up, I wrote that “the charter” > says that this is the intended status. I believe I made a mistake here, by > referring to the “Milestones” as a part of the “Charter”, since they appear > on the same page. From the milestones, the planned status is clear: > https://datatracker.ietf.org/wg/taps/about/ > > Digging deeper, I managed to find the discussion that led to this > decision. It’s here, right on the top (first meeting item): > > https://datatracker.ietf.org/meeting/102/materials/minutes-102-taps-00 > > > > If I were to summarize this discussion, I would point out the following: > > > > * there was a strong hum for Standards, and a light hum for Informational > > > > * Pete Resnick’s statement is perhaps the clearest: "RFC 2026 allows > Proposed Standards to be Technical Standards and Applicability statements. > Proposed Standards are part of the Standards track. There is an expectation > that you revise it. You can continue to make changes to it. Experimental > are when you want to test something in a corner, not on the real > internet. Informational is when we have not developed a protocol and we are > not recommending it for something. This is Proposed Standard." > > > > I hope this helps? > > > > Cheers, > > Michael > > > > PS: JFYI, regarding your other comments - yours, and all others, become > issues in our github: https://github.com/ietf-tapswg/api-drafts/issues > <https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-2fc48301f7570c95&q=1&e=c189c75b-ab30-4b04-92a7-bd391b816384&u=https%3A%2F%2Fgithub.com%2Fietf-tapswg%2Fapi-drafts%2Fissues> > and we take it from there. > > > > > > On 28 Aug 2023, at 12:47, Éric Vyncke via Datatracker <noreply@ietf.org> > wrote: > > > > Éric Vyncke has entered the following ballot position for > draft-ietf-taps-arch-18: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-taps-arch/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > # Éric Vyncke, INT AD, comments for draft-ietf-taps-arch-18 > > Thank you for the work put into this *NEAT* document (private joke). It is > easy > to read and is an important piece of work required to deploy new > transports. > > Please find below one blocking DISCUSS points (mainly to have a > discussion, do > not worry too much), some non-blocking COMMENT points (but replies would be > appreciated even if only for my own education), and some nits. > > Special thanks to Michael Welzl for the shepherd's detailed write-up > including > the WG consensus and the justification of the intended status *even* if I > disagree with the intended status (see below my DISCUSS point). > > Other thanks to Bernie Volz, the Internet directorate reviewer (at my > request), > please consider this int-dir review: > > https://datatracker.ietf.org/doc/review-ietf-taps-arch-18-intdir-telechat-volz-2023-08-25/ > (minor nits) > > I hope that this review helps to improve the document, > > Regards, > > -éric > > # DISCUSS > > As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a > DISCUSS ballot is a request to have a *discussion* on the following topics: > > ## Intended status > > This is only to have a public discussion (over email before the telechat or > during the IESG telechat), I intend to ballot either NoObj or Yes after > this > discussion. The shepherd's write-up writes that the intended status is > "proposed standard" per TAPS WG charter and I do not see anything related > to an > architecture document in the charter and even less about its intended > status. > Moreover, most IETF architecture documents are 'informational'. > > See also my comments about section 3.1 > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > # COMMENTS > > ## Anycast address > > This document differentiates between unicast and multicast addresses, but > should there be a specific case of anycast addresses ? > > ## Section 1.4 > > I am not a transport expert but I would have included the transport > protocol in > `Socket: The combination of a destination IP address and a destination port > number [RFC8303].` > > ## Section 2 > > Should 'DNS' be included in `system-provided stub resolver` ? > > Figure 1 & 2 are nice but, please, add a references to them in the text. > > In `it describes how implementations can use multiple IP addresses` isn't > it > hidden usually to the application ? > > ## Section 2.3 > > In `The Socket API for protocols like TCP is generally limited to > connecting to > a single address over a single interface.` should there be a mention of > one or > several 'source' IP addresses ? Should 'address' be qualified by 'IP' (as > opposed to a DNS name or "Internet address" aka URL)? > > ## Section 2.4 > > How can a (nice) informational RFC 8170 "requires" in `incremental > deployability [RFC8170] requires coexistence`. Suggest to use "recommend" > or > something similar to avoid confusion. > > ## Section 3.1 > > The presence of normative BCP14 terms ("SHOULD", ...) in an architecture > document looks weird to me (see my DISCUSS point above). Is this document > an > 'architecture' document or an 'architecture and requirements' one ? > > ## Section 3.3 > > What is the exact meaning of 'safely' in `Equivalent Protocol Stacks can be > safely swapped or raced in parallel` ? > > ## Section 4.1 > > s/Establishment (Section 4.1.4) focuses on the *actions* that an > application > *takes on* the connection objects/Establishment (Section 4.1.4) focuses on > the > *requests* that an application *sets to* the connection objects/ as it is > not > really the application doing those actions ? > > ## Section 4.1.1 > > Please state the obvious: a multicast endpoint can only be a destination > endpoint. > > ## Section 4.1.3 > > Do the security parameters include DNS resolution security parameters ? > E.g., > mandatory use of DNSSEC or DoH? > > ## Section 4.1.5 > > Unsure whether the sentence `Messages are sent in the payload of IP > packet` is > really useful. Suggest to remove it. > > ## Section 4.2.2 > > Suggest to mention RFC 7556 in the discussion about different local > addresses > (interfaces?) and DNS resolvers. > > # NITS > > ## Section 2 > > Is a capitalised "Connections" required in `the interface for an > application to > create Connections and transfer data` ? Or should there be a text in the > glossary section about the use of capitalised terms ? > > ## Section 2.1 > > s/all interaction using the Transport Services API is expected to be > asynchronous/all interactionS using the Transport Services API ARE > expected to > be asynchronous/ ? > > > >
- [Taps] Éric Vyncke's Discuss on draft-ietf-taps-a… Éric Vyncke via Datatracker
- Re: [Taps] Éric Vyncke's Discuss on draft-ietf-ta… tom petch
- Re: [Taps] Éric Vyncke's Discuss on draft-ietf-ta… Michael Welzl
- Re: [Taps] Éric Vyncke's Discuss on draft-ietf-ta… Mirja Kuehlewind
- Re: [Taps] Éric Vyncke's Discuss on draft-ietf-ta… Eric Vyncke (evyncke)
- Re: [Taps] Éric Vyncke's Discuss on draft-ietf-ta… Zaheduzzaman Sarker
- Re: [Taps] Éric Vyncke's Discuss on draft-ietf-ta… Mirja Kuehlewind
- Re: [Taps] Éric Vyncke's Discuss on draft-ietf-ta… Aaron Falk
- Re: [Taps] Éric Vyncke's Discuss on draft-ietf-ta… Brian Trammell (IETF)
- Re: [Taps] Éric Vyncke's Discuss on draft-ietf-ta… Brian Trammell (IETF)
- Re: [Taps] Éric Vyncke's Discuss on draft-ietf-ta… Gorry Fairhurst
- Re: [Taps] Éric Vyncke's Discuss on draft-ietf-ta… Brian Trammell (IETF)
- Re: [Taps] Éric Vyncke's Discuss on draft-ietf-ta… Eric Vyncke (evyncke)
- Re: [Taps] Éric Vyncke's Discuss on draft-ietf-ta… Mirja Kuehlewind