Brian and Gorry, Thanks for the replies. We have updated our current version of the document with the short/running title suggested by Brian.
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 Dec 6, 2024, at 6:02 AM, Gorry Fairhurst <go...@erg.abdn.ac.uk> wrote: > > On 06/12/2024 12:47, Brian Trammell (IETF) wrote: >> Not the document title, the short / footer title (which currently reads TAPS >> Architecture). > > Aha. > > Yes, I strongly agree with THAT proposal to change "<title abbrev="...: > > Gorry > >>> 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
