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 < [email protected]> 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 <[email protected]> > *Date: *Monday, 4. September 2023 at 17:25 > *To: *"Eric Vyncke (evyncke)" <[email protected]> > *Cc: *Mirja Kuehlewind <[email protected]>, Michael Welzl < > [email protected]>, The IESG <[email protected]>, " > [email protected]" <[email protected]>, " > [email protected]" <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" <[email protected]> > *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= > [email protected]> 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 <[email protected]> > *Date: *Monday, 4 September 2023 at 15:56 > *To: *Michael Welzl <[email protected]>, Eric Vyncke <[email protected]> > *Cc: *The IESG <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" < > [email protected]>, "[email protected]" <[email protected]>, "[email protected]" > <[email protected]> > *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 <[email protected]> on behalf of Michael Welzl < > [email protected]> > *Date: *Monday, 4. September 2023 at 10:19 > *To: *Éric Vyncke <[email protected]> > *Cc: *The IESG <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" < > [email protected]>, "[email protected]" <[email protected]>, "[email protected]" > <[email protected]> > *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 <[email protected]> > 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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
