I’d prefer to update the running title to “Transport Services Architecture” to reflect the other documents.
With that change, I approve this revision. Thanks! Cheers, Brian > On 5 Dec 2024, at 19:49, Megan Ferguson <mfergu...@amsl.com> wrote: > > Authors, > > Just an FYI that we have updated the files to include the title change to > RFC-to-be 9622 in the reference entry. You may review the change in the > files below. > > Please also review the short/running title using TAPS and let us know if/how > this should be updated as it has been changed in the other docs in this > cluster. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9621.txt > https://www.rfc-editor.org/authors/rfc9621.pdf > https://www.rfc-editor.org/authors/rfc9621.html > https://www.rfc-editor.org/authors/rfc9621.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9621-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9621-auth48diff.html (AUTH48 changes > only) > https://www.rfc-editor.org/authors/rfc9621-lastdiff.html (last to current > version only) > > Please contact us with any further updates/questions/comments you may have. > > We will await approvals from each of the parties listed on the AUTH48 status > page prior to moving forward to publication. > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9621 > > Thank you. > > RFC Editor/mf > >> On Nov 29, 2024, at 12:50 PM, Gorry Fairhurst <go...@erg.abdn.ac.uk> wrote: >> >> On 29/11/2024 13:17, Colin Perkins wrote: >>> Hi Megan, >>> >>> Happy with the changes so far. >>> >>> Regarding the <tt> query: I actually think the use of <tt> helps >>> readability, provided we can be sure it’s consistent. It’s not critical, >>> but it helps. >>> >>> Colin >>> >> +1 It helps, the render I see looks good. >> >> Gorry >> >>> On 21 Nov 2024, at 20:43, Megan Ferguson wrote: >>> >>> Hi Brian and Colin, >>> >>> Thanks for the quick replies. We have a few comments/questions to follow up >>> on: >>> >>> • Regarding the use of <tt>: >>> • <!-- [rfced] Please review usage of <tt> in this document, and let us >>> >>> know if any updates are needed. For example, we see >>> "to initiate a connection" (no <tt>) and "to Initiate a Connection" >>> in the XML file. --> >>> >>> The usage here is not consistent. >>> >>> The intention is that terms appearing in Figure 4 representing methods are >>> rendered in monospace (this is an implementation of the backtick notation >>> in Markdown, from which these XML files are generated). >>> >>> <tt> around Listen, Initiate, Rendezvous, Rendezvous, Receive, Send, Close, >>> Abort (as capitalized) should remain; I see some around Connection that are >>> spurious and can be removed. >>> >>> If this styling isn’t supported by the RFC Editor’s renderings of the XML, >>> <tt> can also be safely removed. >>> >>> Before we make any updates to the use of <tt> in this document, we suggest >>> the authors have a look at both: >>> >>> -the related <tt> query for RFC-to-be 9622 and >>> >>> -the html output for RFC-to-be 9622 >>> >>> and consider how to handle them with the following in mind: >>> >>> • Whether the large volume of <tt> tags in RFC-to-be 9622, in addition >>> to a heavy amount of capped terms, might actually be distracting to readers. >>> >>> • The author workload necessary to make the use of <tt> tags consistent >>> within RFC-to-be 9622 itself and among the docs in the cluster. Because >>> many of these terms vary in capitalization (see the example in our original >>> query above) or are used sometimes in a general sense or without labels, >>> locating and applying these fixes may prove somewhat difficult. >>> >>> Note: We are currently completing our review of RFC-to-be 9623, which also >>> uses <tt>. >>> >>> Please let us know how best to proceed. >>> >>> • Regarding the [POSIX] reference, should we update to the 2017 or 2024 >>> version? >>> All other updates are available for you to review. >>> >>> Please review the files carefully as we do not make changes after >>> publication. >>> >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9621.txt >>> https://www.rfc-editor.org/authors/rfc9621.pdf >>> https://www.rfc-editor.org/authors/rfc9621.html >>> https://www.rfc-editor.org/authors/rfc9621.xml >>> >>> The relevant diff files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9621-diff.html (comprehensive diff) >>> https://www.rfc-editor.org/authors/rfc9621-auth48diff.html (AUTH48 changes >>> only) >>> https://www.rfc-editor.org/authors/rfc9621-lastdiff.html (last to current >>> version only) >>> >>> Please contact us with any further updates/questions/comments you may have. >>> >>> We will await approvals from each of the parties listed on the AUTH48 >>> status page prior to moving forward to publication. >>> >>> The AUTH48 status page for this document is available here: >>> >>> https://www.rfc-editor.org/auth48/rfc9621 >>> >>> Thank you. >>> >>> RFC Editor/mf >>> >>> On Nov 19, 2024, at 11:03 AM, Brian Trammell (IETF) i...@trammell.ch wrote: >>> >>> Greetings, all, >>> >>> Answers to editor questions inline, below. >>> >>> On 19 Nov 2024, at 00:29, rfc-edi...@rfc-editor.org wrote: >>> >>> Authors, >>> >>> While reviewing this document during AUTH48, please resolve (as necessary) >>> the following questions, which are also in the XML file. >>> >>> Note: Further questions that affect multiple documents in this cluster >>> (C508) >>> will be sent in separate mail. >>> >>> Please see cluster info at: https://www.rfc-editor.org/auth48/C508. >>> >>> • <!-- [rfced] Please insert any keywords (beyond those that appear in >>> the >>> >>> title) for use on https://www.rfc-editor.org/search . --> >>> >>> • <!-- [rfced] Section 1: Per Internet searches, it appears that some >>> >>> consider the BSD Socket API to be distinct from the POSIX Socket API. >>> Please confirm that this text will be clear to readers. >>> >>> Original: >>> Many application programming interfaces (APIs) to provide transport >>> interfaces to networks have been deployed, perhaps the most widely >>> known and imitated being the BSD Socket [POSIX] interface (Socket >>> API). --> >>> >>> We can remove BSD here “…the Socket [POSIX] interface" >>> >>> • <!-- [rfced] Section 1.4: We do not see the terms/words >>> >>> "Transport Property" or any form of "prohib*" in RFC 8095. >>> Please confirm that this citation is correct and will be clear to >>> readers. >>> >>> Original: >>> >>> • Transport Property: A property that expresses requirements, >>> prohibitions and preferences [RFC8095]. --> >>> >>> I suspect this is vestigial. >>> >>> “A property of a transport protocol and the services it provides [RFC8095]." >>> >>> • <!-- [rfced] Section 2.3: To what does "which are" refer in this >>> >>> sentence - the identifiers, the IP addresses, or something else? >>> >>> Original: >>> This >>> requires applications to specify identifiers for the Local and Remote >>> Endpoint that are higher-level than IP addresses, such as a hostname >>> or URL, which are used by a Transport Services Implementation for >>> resolution, path selection, and racing. --> >>> >>> The identifiers. >>> >>> • <!-- [rfced] Please review usage of <tt> in this document, and let us >>> >>> know if any updates are needed. For example, we see >>> "to initiate a connection" (no <tt>) and "to Initiate a Connection" >>> in the XML file. --> >>> >>> The usage here is not consistent. >>> >>> The intention is that terms appearing in Figure 4 representing methods are >>> rendered in monospace (this is an implementation of the backtick notation >>> in Markdown, from which these XML files are generated). >>> >>> <tt> around Listen, Initiate, Rendezvous, Rendezvous, Receive, Send, Close, >>> Abort (as capitalized) should remain; I see some around Connection that are >>> spurious and can be removed. >>> >>> If this styling isn’t supported by the RFC Editor’s renderings of the XML, >>> <tt> can also be safely removed. >>> >>> • <!-- [rfced] Section 4.1.1: To what does "this" refer in this >>> >>> sentence? >>> >>> Original (the previous sentence is included for context): >>> A Remote Endpoint Identifier can also >>> represent a multicast group or anycast address. In the case of >>> multicast, this selects a multicast transport for communication. --> >>> >>> NEW: “In the case of multicast, a multicast transport will be selected" >>> >>> • <!-- [rfced] Section 4.1.2: We do not see "Remote Endpoint >>> >>> Identifier" mentioned in Section 4.1.3. Please confirm that this >>> citation is correct and will be clear to readers. >>> >>> Original: >>> It has state that >>> describes parameters of the Connection: the Local Endpoint >>> Identifier from which that Connection will be established, the >>> Remote Endpoint Identifier (Section 4.1.3) to which it will >>> connect, and Transport Properties that influence the paths and >>> protocols a Connection will use. --> >>> >>> The citation is spurious (probably vestigial) and can be removed. >>> >>> • <!-- [rfced] Section 4.1.3: We changed "fast open support" to >>> >>> "support for TCP Fast Open" per usage elsewhere in this cluster and >>> per post-6000 published RFCs. Please let us know any objections. >>> >>> Original: >>> Examples of properties >>> that influence protocol selection and configuration of transport >>> protocol features include reliability, multipath support, and fast >>> open support. >>> >>> Currently: >>> Examples of properties >>> that influence protocol selection and configuration of transport >>> protocol features include reliability, multipath support, and >>> support for TCP Fast Open. --> >>> >>> While TCP is the only transport protocol supporting a fast open feature, >>> the choice here was deliberate to refer to the class of transport protocol >>> features containing TCP Fast Open in the abstract. Either is fine. >>> >>> • <!-- [rfced] Section 4.1.7: We had trouble parsing this sentence. >>> >>> We updated it as follows. If this is incorrect, please clarify the >>> text. >>> >>> Original: >>> >>> • Close: The action an application takes on a Connection to indicate >>> that it no longer intends to send data, is no longer willing to >>> receive data, and that the protocol should signal this state to >>> the Remote Endpoint if the transport protocol allows this. >>> >>> Currently: >>> Close: The action an application takes on a Connection to indicate >>> that it no longer intends to send data or is no longer willing to >>> receive data. The protocol should signal this state to the Remote >>> Endpoint if the transport protocol permits it. --> >>> >>> yep this is better (and remains as intended), thanks! >>> >>> • <!-- [rfced] Section 4.1.7: This sentence does not parse. If the >>> >>> suggested text is not correct, please clarify how "and immediately >>> drop the connection" relates to the rest of the sentence. >>> >>> Original: >>> >>> • Abort: The action the application takes on a Connection to >>> indicate a Close and also indicate that the Transport Services >>> System should not attempt to deliver any outstanding data, and >>> immediately drop the connection. >>> Suggested: >>> Abort: The action the application takes on a Connection to indicate >>> a Close and also indicate that the Transport Services System >>> should not attempt to deliver any outstanding data and should >>> immediately drop the connection. --> >>> >>> Better, but I think this could be made clearer: >>> >>> NEW: >>> >>> Abort: The action the application takes on a Connection >>> to indicate that the Transport Services System >>> should not attempt to deliver any outstanding data, and should >>> immediately close and drop the connection >>> >>> • <!-- [rfced] Section 4.2: This sentence does not parse. Please >>> >>> clarify "going through a single security and transport protocol, >>> over IP; or, a multi-path transport protocol". >>> >>> Original: >>> A single stack can be simple (a single transport >>> protocol instance over IP), or it can be complex (multiple >>> application protocol streams going through a single security and >>> transport protocol, over IP; or, a multi-path transport protocol >>> over multiple transport sub-flows). --> >>> >>> Suggested rework: >>> >>> A single stack can be simple (e.g. one application stream carried TCP >>> running over IP), or complex (e.g. multiple application streams carried >>> over a multipath transport protocol using multiple subflows over IP). >>> >>> • <!-- [rfced] Section 4.2.3: What can lead to linkability - the >>> >>> cached protocol state itself or the act of reusing it? If the >>> suggested text (the act of reusing cached protocol state) is not >>> correct, please provide clarifying text. >>> >>> Original (previous text is included for context; also, we >>> restructured the list): >>> >>> Possible reasons to isolate Connections using separate >>> Connection Contexts include: >>> >>> • Privacy concerns about re-using cached protocol state that can >>> lead to linkability. >>> >>> Suggested: >>> Possible reasons to isolate Connections using separate >>> Connection Contexts include privacy concerns regarding: >>> >>> • reusing cached protocol state, as this can lead to linkability. >>> --> >>> >>> This is good, thanks! >>> >>> • <!-- [rfced] Section 6: We changed "other another security protocol >>> >>> handshake that is" to "other security protocol handshakes that are". >>> If this is incorrect, please clarify the text. >>> >>> Original: >>> For example, if an >>> application provides a certificate to only be used as client >>> authentication for outbound TLS and QUIC connections, the Transport >>> Services System MUST NOT use this automatically in other contexts >>> (such as server authentication for inbound connections, or in other >>> another security protocol handshake that is not equivalent to TLS). >>> >>> Currently: >>> For example, if an >>> application provides a certificate to only be used as client >>> authentication for outbound TLS and QUIC connections, the Transport >>> Services System MUST NOT use this automatically in other contexts >>> (such as server authentication for inbound connections or in other >>> security protocol handshakes that are not equivalent to TLS). --> >>> >>> yep, thanks! >>> >>> • <!-- [rfced] The 2008 version of [POSIX] is marked "Superseded". >>> >>> There is a 2017 revision (https://ieeexplore.ieee.org/document/8277153) >>> and a 2024 revision (https://ieeexplore.ieee.org/document/10555529). >>> Please let us know if you would like to update this reference to one >>> of these revisions; if yes, please let us know which revision is >>> appropriate for this document. >>> >>> Original (double dash changed to single in order to avoid xml2rfc's >>> "Double hyphen within comment" error): >>> [POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology >>> - Portable Operating System Interface (POSIX). Open >>> group Technical Standard: Base Specifications, Issue 7", >>> 2008. --> >>> >>> Please update the reference, thanks! >>> >>> • <!-- [rfced] RFC 5389 has been obsoleted by RFC 8489 >>> >>> (https://www.rfc-editor.org/info/rfc8489). As the citation in >>> Section 4.1.4 appears to be general in nature, we updated this >>> document to list and cite RFC 8489 instead, per companion document >>> draft-ietf-taps-interface. Please let us know any objections. >>> >>> Original: >>> However, if the set of Local Endpoints includes >>> server reflexive candidates, such as those provided by STUN >>> (Session Traversal Utilities for NAT) [RFC5389], a Rendezvous >>> action will race candidates in the style of the ICE (Interactive >>> Connection Establishment) algorithm [RFC8445] to perform NAT >>> binding discovery and initiate a peer-to-peer connection. >>> ... >>> [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, >>> "Session Traversal Utilities for NAT (STUN)", RFC 5389, >>> DOI 10.17487/RFC5389, October 2008, >>> https://www.rfc-editor.org/rfc/rfc5389 . >>> >>> Currently: >>> However, if the set of Local Endpoints includes >>> server-reflexive candidates, such as those provided by STUN >>> (Session Traversal Utilities for NAT) [RFC8489], a Rendezvous >>> action will race candidates in the style of the ICE (Interactive >>> Connectivity Establishment) algorithm [RFC8445] to perform NAT >>> binding discovery and initiate a peer-to-peer connection. >>> ... >>> [RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, >>> D., Mahy, R., and P. Matthews, "Session Traversal >>> Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489, >>> February 2020, https://www.rfc-editor.org/info/rfc8489 . --> >>> >>> Please update the reference, thanks! >>> >>> • <!-- [rfced] Please review the "Inclusive Language" portion of the >>> >>> online Style Guide at >>> https://www.rfc-editor.org/styleguide/part2/#inclusive_language , >>> and let us know if any changes are needed. Updates of this nature >>> typically result in more precise language, which is helpful for >>> readers. >>> >>> In addition, please consider whether "tradition" should be updated >>> for clarity (possibly "commonly used", "typical", or >>> "long-established"). While the NIST website >>> (https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1) >>> indicates that this term is potentially biased, it is also ambiguous. >>> "Tradition" is a subjective term, as it is not the same for everyone. --> >>> >>> The use of “traditional” here is meant to refer to the UNIX programming >>> tradition; I believe this is inclusive of all networking systems >>> programmers using UNIX systems or those systems compatible with and/or >>> inspired by them (and the insight, and indeed the entirety of the TAPS >>> work, is irrelevant to people who are not networking systems prorgammers), >>> so IMO this is fine to keep. >>> >>> • <!-- [rfced] The following terms were used inconsistently in this >>> >>> document. We chose to use the latter forms. Please let us know >>> any objections. >>> >>> Transport Feature / transport feature (in running text) >>> (per usage elsewhere in this document, in the rest of this >>> cluster, and in RFC 8303) >>> >>> Transport Service API (1 instance in Cluster 508) / >>> Transport Services API (per the rest of this document and the >>> cluster) >>> >>> Transport Service System (1 instance in Cluster 508) / >>> Transport Services System (per the rest of this document and the >>> cluster) --> >>> >>> These are fine, thanks. >>> >>> Thank you. >>> >>> RFC Editor/lb/mf >>> >>> IMPORTANT >>> >>> Updated 2024/11/18 >>> >>> RFC Author(s): >>> >>> Instructions for Completing AUTH48 >>> >>> Your document has now entered AUTH48. Once it has been reviewed and >>> approved by you and all coauthors, it will be published as an RFC. >>> If an author is no longer available, there are several remedies >>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>> >>> You and you coauthors are responsible for engaging other parties >>> (e.g., Contributors or Working Group) as necessary before providing >>> your approval. >>> >>> Planning your review >>> >>> Please review the following aspects of your document: >>> >>> • RFC Editor questions >>> Please review and resolve any questions raised by the RFC Editor >>> that have been included in the XML file as comments marked as >>> follows: >>> >>> <!-- [rfced] ... --> >>> >>> These questions will also be sent in a subsequent email. >>> >>> • Changes submitted by coauthors >>> Please ensure that you review any changes submitted by your >>> coauthors. We assume that if you do not speak up that you >>> agree to changes submitted by your coauthors. >>> >>> • Content >>> Please review the full content of the document, as this cannot >>> change once the RFC is published. Please pay particular attention to: >>> >>> • IANA considerations updates (if applicable) >>> • contact information >>> • references >>> • Copyright notices and legends >>> Please review the copyright notice and legends as defined in >>> RFC 5378 and the Trust Legal Provisions >>> (TLP – https://trustee.ietf.org/license-info). >>> >>> • Semantic markup >>> Please review the markup in the XML file to ensure that elements of >>> content are correctly tagged. For example, ensure that <sourcecode> >>> and <artwork> are set correctly. See details at >>> https://authors.ietf.org/rfcxml-vocabulary . >>> >>> • Formatted output >>> Please review the PDF, HTML, and TXT files to ensure that the >>> formatted output, as generated from the markup in the XML file, is >>> reasonable. Please note that the TXT will have formatting >>> limitations compared to the PDF and HTML. >>> >>> Submitting changes >>> >>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>> the parties CCed on this message need to see your changes. The parties >>> include: >>> >>> • your coauthors >>> >>> • rfc-edi...@rfc-editor.org (the RPC team) >>> >>> • other document participants, depending on the stream (e.g., >>> IETF Stream participants are your working group chairs, the >>> responsible ADs, and the document shepherd). >>> >>> • auth48archive@rfc-editor.org, which is a new archival mailing list >>> to preserve AUTH48 conversations; it is not an active discussion >>> list: >>> >>> • More info: >>> >>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>> >>> • The archive itself: >>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>> >>> • Note: If only absolutely necessary, you may temporarily opt out >>> of the archiving of messages (e.g., to discuss a sensitive matter). >>> If needed, please add a note at the top of the message that you >>> have dropped the address. When the discussion is concluded, >>> auth48archive@rfc-editor.org will be re-added to the CC list and >>> its addition will be noted at the top of the message. >>> You may submit your changes in one of two ways: >>> >>> An update to the provided XML file >>> — OR — >>> An explicit list of changes in this format >>> >>> Section # (or indicate Global) >>> >>> OLD: >>> old text >>> >>> NEW: >>> new text >>> >>> You do not need to reply with both an updated XML file and an explicit >>> list of changes, as either form is sufficient. >>> >>> We will ask a stream manager to review and approve any changes that seem >>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>> and technical changes. Information about stream managers can be found in >>> the FAQ. Editorial changes do not require approval from a stream manager. >>> >>> Approving for publication >>> >>> To approve your RFC for publication, please reply to this email stating >>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>> as all the parties CCed on this message need to see your approval. >>> >>> Files >>> >>> The files are available here: >>> https://www.rfc-editor.org/authors/rfc9621.xml >>> https://www.rfc-editor.org/authors/rfc9621.html >>> https://www.rfc-editor.org/authors/rfc9621.pdf >>> https://www.rfc-editor.org/authors/rfc9621.txt >>> >>> Diff file of the text: >>> https://www.rfc-editor.org/authors/rfc9621-diff.html >>> https://www.rfc-editor.org/authors/rfc9621-rfcdiff.html (side by side) >>> >>> Diff of the XML: >>> https://www.rfc-editor.org/authors/rfc9621-xmldiff1.html >>> >>> Tracking progress >>> >>> The details of the AUTH48 status of your document are here: >>> https://www.rfc-editor.org/auth48/rfc9621 >>> >>> Please let us know if you have any questions. >>> >>> Thank you for your cooperation, >>> >>> RFC Editor >>> >>> RFC9621 (draft-ietf-taps-arch-19) >>> >>> Title : Architecture and Requirements for Transport Services >>> Author(s) : T. Pauly, Ed., B. Trammell, Ed., A. Brunstrom, G. Fairhurst, C. >>> S. Perkins >>> WG Chair(s) : Reese Enghardt, Aaron Falk >>> >>> Area Director(s) : Zaheduzzaman Sarker, Francesca Palombini >>> >> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
