Hello, I also approve this latest version of RFC 9621. Thanks!
Tommy > On Dec 13, 2024, at 3:00 AM, Gorry Fairhurst <[email protected]> wrote: > > Megan/RFC-Ed, > > As an author, I'd now like to add my APPROVAL for RFC9621. > > I think this is now ready. > > Best wishes, > Gorry > > On 09/12/2024 19:29, Megan Ferguson wrote: >> 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]
