Not the document title, the short / footer title (which currently reads TAPS Architecture).
> On 6 Dec 2024, at 13:43, Gorry Fairhurst <go...@erg.abdn.ac.uk> wrote: > > On 06/12/2024 12:37, Brian Trammell (IETF) wrote: >> I’d prefer to update the running title to “Transport Services Architecture” >> to reflect the other documents. > > We debated this in some detail earlier and arrived at: > > Architecture and Requirements for Transport Services > > I'm just asking why we need a change now? > > Gorry > >> >> 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
