Hi, Perhaps it would be good to sync - I believe that, at this point:
1) as you say, the only outstanding issue for this document is the cluster-wide query #4, 2) the only outstanding issues for RFC 9622 are the cluster-wide queries #4 and #5, 3) the only outstanding issues for RFC 9623 are the cluster-wide queries #4 and #5. Is this correct? Cheers, Michael > On Dec 9, 2024, at 7:24 PM, Megan Ferguson <[email protected]> wrote: > > All, > > Just duplicating the message to the cluster-wide message in this thread as > well for convenience/completeness: > > Hi Gorry and Michael, > > Thanks for sending along the file for RFC 9621 updated for <tt> consistency. > We used that version and added in the other cluster-wide update to use > multistream (closed compound) as well as the changes Gorry requested. > > We believe the only outstanding issue for this document is the response to > the capitalization consistency cluster-wide query (#4). > > Please review the other updates and let us know if further changes are > necessary. > > 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 > > Diff files are available here (please refresh): > https://www.rfc-editor.org/authors/rfc9621-diff.html (comprehensive) > https://www.rfc-editor.org/authors/rfc9621-rfcdiff.html (comprehensive > rfcdiff) > https://www.rfc-editor.org/authors/rfc9621-auth48diff.html (all AUTH48 > changes) > https://www.rfc-editor.org/authors/rfc9621-lastdiff.html (last version to > this) > https://www.rfc-editor.org/authors/rfc9621-lastrfcdiff.html (ditto but > rfcdiff) > > Thank you. > > RFC Editor/mf > >> On Dec 6, 2024, at 2:11 PM, Megan Ferguson <[email protected]> wrote: >> >> Gorry and Colin, >> >> Thanks for your replies. >> >> We have updated the POSIX reference to point to the 2024 version. >> >> Regarding this change: >> >>> OLD: >>> It is RECOMMENDED that the Transport Services API offer properties >>> that are common to multiple transport protocols. >>> NEW: >>> It is RECOMMENDED that the Transport Services API offers properties >>> that are common to multiple transport protocols. >>> >>> • Please check this change is still correct: My reading is that this >>> ought to say "offers", because there is only abstract API for the transport >>> services. I'm content if you check this and prefer your change. >> >> We have left as was. If interested, a quick reference exists here: >> http://www.englishpage.com/minitutorials/subjunctive.html >> >> Please review the other updates and let us know if further changes are >> necessary. >> >> 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 >> >> Diff files are available here (please refresh): >> https://www.rfc-editor.org/authors/rfc9621-diff.html (comprehensive) >> https://www.rfc-editor.org/authors/rfc9621-rfcdiff.html (comprehensive >> rfcdiff) >> https://www.rfc-editor.org/authors/rfc9621-auth48diff.html (all AUTH48 >> changes) >> https://www.rfc-editor.org/authors/rfc9621-lastdiff.html (last version to >> this) >> https://www.rfc-editor.org/authors/rfc9621-lastrfcdiff.html (ditto but >> rfcdiff) >> >> Thank you. >> >> RFC Editor/mf >> >>> On Dec 6, 2024, at 12:10 PM, Gorry Fairhurst <[email protected]> wrote: >>> >>> Please see below: >>> >>> On 06/12/2024 18:48, Megan Ferguson wrote: >>>> Hi Colin, >>>> >>>> Thanks for pointing this out. We have folded this change into our current >>>> version of the files (see below). >>>> >>>> Perhaps I am missing it, but I *think* we haven’t seen a response to this >>>> question from a previous mail: >>>> >>>> 2) Regarding the [POSIX] reference, should we update to the 2017 or 2024 >>>> version? >>>> >>>> May we assume that the most current is desired? >>>> >>> Yes - I think we should update to the most current! >>> >>> >>> >>>> 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 >>>> >>> I did a detailed read and found two anomolies and one query, could you look >>> at these, and I then expect to approve? >>> >>> -- >>> >>> OLD: >>> It is RECOMMENDED that the Transport Services API offer properties >>> that are common to multiple transport protocols. >>> NEW: >>> It is RECOMMENDED that the Transport Services API offers properties >>> that are common to multiple transport protocols. >>> >>> • Please check this change is still correct: My reading is that this >>> ought to say "offers", because there is only abstract API for the transport >>> services. I'm content if you check this and prefer your change. >>> OLD: >>> The input from an operating system or other global >>> preferences that can constrain or influence how an implementation >>> will gather candidate paths and Protocol Stacks >>> NEW: >>> The input from an operating system or other global >>> preferences that can constrain or influence how an implementation >>> will gather Candidate Paths and Candidate Protocol Stacks >>> ---- In the midst of all our checking, "candidate paths" somehow missed to >>> be capitalised, and the word candidate ought to appear before both items, >>> since these are terms. >>> >>> --- >>> >>> OLD: >>> The input from an operating system or other global >>> preferences that can constrain or influence how an implementation >>> will gather Candidate Paths and Protocol Stacks and race the >>> candidates during establishment of a Connection. >>> NEW: >>> The input from an operating system or other global >>> preferences that can constrain or influence how an implementation >>> will gather Candidate Paths and Candidate Protocol Stacks and race the >>> candidates during establishment of a Connection. >>> ---- It is the "Candidate Protocol Stacks" that are raced, not a Protocol >>> Stack. >>> >>> Best wishes, >>> >>> Gorry >>> >>> >>> >>> >>>> >>>>> On Dec 6, 2024, at 10:16 AM, Colin Perkins <[email protected]> >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Thanks for all the work on this. I have just one nit: in the bullet >>>>> points at the end of Section 2, just before the Section 2.1 heading: “is >>>>> asynchronous and event-driven” was changed to “is asynchronous and driven >>>>> by events”. I think the original is correct, “Event-driven” is the usual >>>>> term for these types of system. >>>>> >>>>> Otherwise, I approve publication. >>>>> >>>>> Cheers, >>>>> Colin >>>>> >>>>> On 6 Dec 2024, at 16:42, Megan Ferguson wrote: >>>>> >>>>> 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 >>>>> [email protected] >>>>> 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 >>>>> [email protected] >>>>> 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 >>>>> [email protected] >>>>> 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 >>>>> [email protected] >>>>> 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) >>>>> [email protected] >>>>> wrote: >>>>> >>>>> Greetings, all, >>>>> >>>>> Answers to editor questions inline, below. >>>>> >>>>> On 19 Nov 2024, at 00:29, >>>>> [email protected] >>>>> 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 >>>>> >>>>> • >>>>> [email protected] >>>>> (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). >>>>> >>>>> • >>>>> [email protected] >>>>> , 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, >>>>> >>>>> [email protected] >>>>> 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 -- [email protected] To unsubscribe send an email to [email protected]
