Yes! That was my thought, but I could not locate it! I have updated the AUTH48 status page of 9622 to reflect this (https://www.rfc-editor.org/auth48/rfc9622).
Thanks, Michael! > On Dec 9, 2024, at 11:51 AM, Michael Welzl <[email protected]> wrote: > > Hi ! > > About question 42 below: I’m not sure if this was in a private email (by > accident?) or lost in a thread with a different subject line, … I can’t find > it either, but I do remember checking this, and writing, to someone, > somewhere :-) that I think all of these cases with the slash character > should stay as they are, since they are no cases that would cause ambiguities. > > Cheers, > Michael > > >> On Dec 9, 2024, at 7:42 PM, Megan Ferguson <[email protected]> wrote: >> >> 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]
