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]
