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/ <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 <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://github.com/ietf-tapswg/api-drafts/issues> 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
