From nobody Mon Sep 4 14:04:30 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 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> <3DCD6C58-7342-4C28-BDA7-65EAFD009096@ericsson.com> <041C30F4-6F51-45F2-996C-F47065B29885@ericsson.com> In-Reply-To: <041C30F4-6F51-45F2-996C-F47065B29885@ericsson.com> From: Aaron Falk Date: Mon, 4 Sep 2023 14:04:11 -0700 Message-ID: To: Mirja Kuehlewind Cc: Zaheduzzaman Sarker , "Eric Vyncke (evyncke)" , Michael Welzl , The IESG , "draft-ietf-taps-arch@ietf.org" , "taps-chairs@ietf.org" , "taps@ietf.org" , "bevolz@gmail.com" Content-Type: multipart/alternative; boundary="000000000000b838b206048edaeb" Archived-At: Subject: Re: [Taps] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-taps?= =?utf-8?q?-arch-18=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Mon, 04 Sep 2023 21:04:28 -0000 --000000000000b838b206048edaeb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM 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 t= o > highlight that. So I don=E2=80=99t think simply just removing the normati= ve > language is providing anybody a service. > > > > Therefore, I guess your question really is should this document be called > =E2=80=9Carchitecture and requirements=E2=80=9D. I don=E2=80=99t have a s= trong opinion here but I > also don=E2=80=99t think it would make the document any better. The main = focus is > on the architecture. Also note that these requirements are not requiremen= ts > 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 statin= g > this in the title). > > > > Mirja > > > > > > > > *From: *Zaheduzzaman Sarker > *Date: *Monday, 4. September 2023 at 17:25 > *To: *"Eric Vyncke (evyncke)" > *Cc: *Mirja Kuehlewind , Michael Welzl < > michawe@ifi.uio.no>, The IESG , " > draft-ietf-taps-arch@ietf.org" , " > taps-chairs@ietf.org" , "taps@ietf.org" < > taps@ietf.org>, "bevolz@gmail.com" > *Subject: *Re: [Taps] =C3=89ric 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=E2=80=AFPM Eric Vyncke (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 preferenc= e > is to avoid normative language in an architecture I-D, else it becomes a > 'requirements' I-D. > > > > Regards, > > > > -=C3=A9ric > > > > *From: *Mirja Kuehlewind > *Date: *Monday, 4 September 2023 at 15:56 > *To: *Michael Welzl , Eric Vyncke > *Cc: *The IESG , "draft-ietf-taps-arch@ietf.org" < > draft-ietf-taps-arch@ietf.org>, "taps-chairs@ietf.org" < > taps-chairs@ietf.org>, "taps@ietf.org" , "bevolz@gmail.com= " > > *Subject: *Re: [Taps] =C3=89ric 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 o= f > 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=E2=80=99s probably enough if you read the arch and th= e API doc. > If you only want to get a high-level idea what taps is, you might read on= ly > the arch doc. > > > > Mirja > > > > > > > > *From: *Taps on behalf of Michael Welzl < > michawe@ifi.uio.no> > *Date: *Monday, 4. September 2023 at 10:19 > *To: *=C3=89ric Vyncke > *Cc: *The IESG , "draft-ietf-taps-arch@ietf.org" < > draft-ietf-taps-arch@ietf.org>, "taps-chairs@ietf.org" < > taps-chairs@ietf.org>, "taps@ietf.org" , "bevolz@gmail.com= " > > *Subject: *Re: [Taps] =C3=89ric Vyncke's Discuss on draft-ietf-taps-arch-= 18: > (with DISCUSS and COMMENT) > > > > Dear =C3=89ric, > > > > 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 =E2=80=9Cthe c= harter=E2=80=9D > says that this is the intended status. I believe I made a mistake here, = by > referring to the =E2=80=9CMilestones=E2=80=9D as a part of the =E2=80=9CC= harter=E2=80=9D, 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=E2=80=99s 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=E2=80=99s statement is perhaps the clearest: "RFC 2026 all= ows > Proposed Standards to be Technical Standards and Applicability statements= . > Proposed Standards are part of the Standards track. There is an expectati= on > 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 a= re > 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 > > and we take it from there. > > > > > > On 28 Aug 2023, at 12:47, =C3=89ric Vyncke via Datatracker > wrote: > > > > =C3=89ric 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-positio= ns/ > 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: > ---------------------------------------------------------------------- > > > # =C3=89ric Vyncke, INT AD, comments for draft-ietf-taps-arch-18 > > Thank you for the work put into this *NEAT* document (private joke). It i= s > 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, > > -=C3=A9ric > > # 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 topic= s: > > ## 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 po= rt > 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 o= n > 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/ ? > > > > --000000000000b838b206048edaeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't have too much to add beyond M= irja's=C2=A0point.=C2=A0 The working group=C2=A0felt strongly that TAPS= could not be correctly implemented without reading the architecture docume= nt.=C2=A0 Further=C2=A0https://www.ietf.org/standards/process/inform= ational-vs-experimental/ says:

An "Informational" specification is published fo= r the general information of the Internet community, and does not represent= an Internet community consensus or recommendation.

Neither of which accurately describe the doc.=C2=A0 Like Mirja, I&= #39;m open to tweaking the title although I think something like=C2=A0 &quo= t;An Architecture for Transport Services (Read This First)" would be m= ore useful than adding the term "Requirements"=C2=A0but YMMV.

--aaron

On Mon, Sep 4, 2023 at 8:57=E2=80=AFAM M= irja Kuehlewind <mirja.= kuehlewind@ericsson.com> wrote:

Hi Eric,

=C2=A0

the use of normative language i= s separate from your discussion point (on intended status), right?

=C2=A0

I just want to mention that the= re 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=E2=80=99t think simp= ly just removing the normative language is providing anybody a service.<= /u>

=C2=A0

Therefore, I guess your questio= n really is should this document be called =E2=80=9Carchitecture and requir= ements=E2=80=9D. I don=E2=80=99t have a strong opinion here but I also don= =E2=80=99t 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 o= ften 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).

=C2=A0

Mirja

=C2=A0

=C2=A0

=C2=A0

From: Zaheduzzaman Sarker &= lt;zahed.s= arker.ietf@gmail.com>
Date: Monday, 4. September 2023 at 17:25
To: "Eric Vyncke (evyncke)" <evyncke=3D40cisco.com@dmarc.ietf.org<= /a>>
Cc: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, Michael Welz= l <michawe@ifi.u= io.no>, The IESG <iesg@ietf.org>, "draft-ietf-taps-arch@ietf.org" <draft-ietf-tap= s-arch@ietf.org>, "taps-chairs@ietf.org" <taps-chairs@ietf.org>, "taps@ietf.org" <taps@ietf.org>, "bevolz@gmail.c= om" <bevo= lz@gmail.com>
Subject: Re: [Taps] =C3=89ric Vyncke's Discuss on draft-ietf-tap= s-arch-18: (with DISCUSS and COMMENT)

=C2=A0

Hi Eric,

=C2=A0

Sure, lets discuss this d= uring 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.

=C2=A0

//Zahed

=C2=A0

On Mon, Sep 4, 2023 at 4:= 07=E2=80=AFPM Eric Vyncke (evyncke) <evyncke=3D40cisco.com@dmarc.ietf.org> w= rote:

Let's have a chat (aka discussion) during the IESG= telechat on Thursday with the AD (and authors/shepherd if they want to joi= n). My own preference is to avoid normative language in an architecture I-D= , else it becomes a 'requirements' I-D.

=C2=A0

Regards,

=C2=A0

-=C3=A9ric

=C2=A0

=C2=A0

Hi Eric,

=C2=A0

Michael, thanks for digging up the minutes.<= /u>

=C2=A0

In my memory I think there was also at the end a stron= g sense in the room to have all doc the same intended status. In my view th= ese docs really belong closely together and as an implementer you really ne= ed all three of them. The reason for the split up is maybe more a service for non-implementors. E.g. if you onl= y want to understand the interface in order to use it, it=E2=80=99s probabl= y enough if you read the arch and the API doc. If you only want to get a hi= gh-level idea what taps is, you might read only the arch doc.

=C2=A0

Mirja

=C2=A0

=C2=A0

=C2=A0

From: Taps <taps-bounces@ietf.org> on behalf of Michael= Welzl <michawe@= ifi.uio.no>
Date: Monday, 4. September 2023 at 10:19
To: =C3=89ric Vyncke <evyncke@cisco.com>
Cc: The IESG <= iesg@ietf.org>, "draft-ietf-taps-arch@ietf.org" <draft-ietf-taps-ar= ch@ietf.org>, "taps-chair= s@ietf.org" <taps-chairs@ietf.org>, "taps@ietf.org" <taps@ietf.org>, "bevolz@gmail.c= om" <bevo= lz@gmail.com>
Subject: Re: [Taps] =C3=89ric Vyncke's Discuss on draft-ietf-tap= s-arch-18: (with DISCUSS and COMMENT)

=C2=A0

Dear =C3=89ric,

=C2=A0

Many thanks for your thoughtful review! =C2=A0 Regarding the DISCUSS point,= which is about the intended status of the architecture document:=

=C2=A0

First, my apologies. In my shepherd write-up, I wrote that =E2=80=9Cthe cha= rter=E2=80=9D says that this is the intended status.=C2=A0 I believe I made= a mistake here, by referring to the =E2=80=9CMilestones=E2=80=9D as a part= of the =E2=80=9CCharter=E2=80=9D, since they appear on the same page. From= the milestones, the planned status is clear: =C2=A0https://datatracker.ietf.org/wg/taps/abo= ut/

Digging deeper, I managed to find the discussion that led to this decision.= It=E2=80=99s here, right on the top (first meeting item):

=C2=A0

If I were to summarize this discussion, I would point out the following:=

=C2=A0

* there was a strong hum for Standards, and a light hum for Informational

=C2=A0

* Pete Resnick=E2=80=99s statement is perhaps the clearest: "RFC 2026 = allows Proposed Standards to be Technical Standards and Applicability state= ments. Proposed Standards are part of the Standards track. There is an expe= ctation 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.=C2=A0Informational is when we have not= developed a protocol and we are not recommending it for something. This is= Proposed Standard."

=C2=A0

I hope this helps?

=C2=A0

Cheers,

Michael

=C2=A0

PS: JFYI, regarding your other comments - yours, and all others, become iss= ues in our github: =C2=A0https://github.com/iet= f-tapswg/api-drafts/issues=C2=A0 and we take it from there.

=C2=A0

=C2=A0

On 28 Aug 2023, at 12:47, =C3=89ric Vyncke via Datatracker <noreply@ietf.org> wrote:

=C2=A0

=C3=89ric 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:
----------------------------------------------------------------------


# =C3=89ric 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 in= cluding
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 reque= st),
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,

-=C3=A9ric

# 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 thi= s
discussion. The shepherd's write-up writes that the intended status is<= br> "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 statu= s.
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 protoco= l 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 connectin= g to
a single address over a single interface.` should there be a mention of one= or
several 'source' IP addresses ? Should 'address' be qualifi= ed 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 `incrementa= l
deployability [RFC8170] requires coexistence`. Suggest to use "recomme= nd" or
something similar to avoid confusion.

## Section 3.1

The presence of normative BCP14 terms ("SHOULD", ...) in an archi= tecture
document looks weird to me (see my DISCUSS point above). Is this document a= n
'architecture' document or an 'architecture and requirements= 9; one ?

## Section 3.3

What is the exact meaning of 'safely' in `Equivalent Protocol Stack= s can be
safely swapped or raced in parallel` ?

## Section 4.1

s/Establishment (Section 4.1.4) focuses on the *actions* that an applicatio= n
*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 n= ot
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 address= es
(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/ ?

=C2=A0

--000000000000b838b206048edaeb--