Good idea, Michael, That is what I have tracking at the AUTH48 status pages for each doc (you can see the notes for the docs in the cluster all together at: https://www.rfc-editor.org/auth48/C508).
RFC 9621: agree with your assessment. RFC 9622: agree (please also see document-specific questions 39 and 41 that overlap with the <tt> and caps questions that were cluster-wide as needed). The only other document-specific question that may remain unresolved was 42: > 42) <!--[rfced] Please review the use of the slash "/" character when it > communicates "and", "or", or "and/or" and consider if using one > of those alternatives would be clearer for the reader. > --> > GF: We still ought to do that. Apologies if I have misplaced any response to this, but don’t see anything when I scan the old messages. RFC 9623: agree Thank you! RFC Editor/mf > On Dec 9, 2024, at 11:27 AM, Michael Welzl <[email protected]> wrote: > > 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]
