Hi, Now finally, the comments for Section 10 in -impl. Here I think some of the fixes created some problems. I take the first instance I encountered as an example:
"Calling Clone on a TCP connection creates a new Connection with equivalent parameters. These Connections, and Connections generated via later calls to Clone on an Established Connection, form a Connection Group." The change to "TCP connection" is of course correct, but the problem comes when that connection is then referred to as "These Connections" and now all of a sudden is a "Connection" rather than a "connection". It is also unclear if the "new Connection" should be a "Connection" or "connection", both could be possible. The root cause is that the text is a bit compressed and you do not call Clone on a TCP connection, but on a Connection object mapped to a TCP connection, so it gets a bit messy when now trying to distinguish and keeping track of what refers to what. In the SCTP section the mapping is explicitly mentioned, but in most other parts we use a more compressed text. I have tried to fix the text for TCP and UDP to get consistent references without major edits in my suggested modifications below. Sorry about the somewhat long list of suggested updates this late in the process. I tried to keep track that the updates looked good overall and agreed with all the principles used, but I had not looked closely enough on the details in Section 10 until doing my final check today. I am also unsure why "UDP Multicast Receive Connection" is used and not "UDP Multicast Receive connection" in Section 10.5? Is there something special about UDP Multicast Receive that suggests it should not follow the general principles and "UDP Multicast Receive connection" is not the correct term? Perhaps it was just missed in the updates of the capitalization, but there is one instance where it is modified in the opposite direction, from "connection" to "Connection" suggesting it is a deliberate choice. Would be good if Michael can clarify the intentions with Section 10.5 before I suggest edits for that section. Also check my suggested updates below and see if you agree as you made the original edits. BR, Anna OLD: Clone: Calling Clone on a TCP connection creates a new Connection with equivalent parameters. These Connections, and Connections generated via later calls to Clone on an Established Connection, form a Connection Group. NEW: Clone: Calling Clone on a TCP connection creates a new TCP connection with equivalent parameters. The two associated Connection objects, and Connections generated via later calls to Clone on an Established Connection, form a Connection Group. OLD: Close: Calling Close on a TCP connection indicates that the Connection should be gracefully closed (CLOSE.TCP) by sending a FIN to the peer. It will then still be possible to receive data until the peer closes or aborts the TCP connection. The Closed event will be issued upon reception of a FIN. NEW: Close: Calling Close on a TCP connection indicates that the TCP connection should be gracefully closed (CLOSE.TCP) by sending a FIN to the peer. It will then still be possible to receive data until the peer closes or aborts the TCP connection. The Closed event will be issued upon reception of a FIN. --- As written, I think "the Connection" must refer back to "a TCP connection" and therefore also should be lower case. I added "TCP" just to avoid any confusion. The similar argument applies to several of the suggested modifications below. OLD: Abort: Calling Abort on a TCP connection indicates that the Connection should be immediately closed by sending a RST to the peer (ABORT.TCP). NEW: Abort: Calling Abort on a TCP connection indicates that the TCP connection should be immediately closed by sending a RST to the peer (ABORT.TCP). OLD: CloseGroup: Calling CloseGroup on a TCP connection (CLOSE.TCP) is identical to calling Close on this Connection and on all Connections in the same ConnectionGroup. NEW: CloseGroup: Calling CloseGroup on a TCP connection (CLOSE.TCP) is identical to calling Close on its Connection object and on all Connections in the same ConnectionGroup. OLD: AbortGroup: Calling AbortGroup on a TCP connection (ABORT.TCP) is identical to calling Abort on this Connection and on all Connections in the same ConnectionGroup. NEW: AbortGroup: Calling AbortGroup on a TCP connection (ABORT.TCP) is identical to calling Abort on its Connection object and on all Connections in the same ConnectionGroup. OLD: InitiateWithSend: Early data on a UDP connection does not have any special meaning. The data is sent whenever the Connection is Ready. NEW: InitiateWithSend: Early data on a UDP connection does not have any special meaning. The data is sent whenever the UDP connection is Ready. OLD: ConnectionReceived: UDP Listeners will deliver new connections once they have received traffic from a new Remote Endpoint. NEW: ConnectionReceived: UDP Listeners will deliver new Connections once they have received traffic from a new Remote Endpoint. --- Here I think we are talking about delivering new Connection objects so should be upper case. OLD: Clone: Calling Clone on a UDP connection creates a new Connection with equivalent parameters. The two Connections are otherwise independent. NEW: Clone: Calling Clone on a UDP connection creates a new UDP connection with equivalent parameters. The two associated Connection objects are otherwise independent. OLD: Close: Calling Close on a UDP connection (ABORT.UDP) releases the local port reservation. The Connection then issues a Closed event. NEW: Close: Calling Close on a UDP connection (ABORT.UDP) releases the local port reservation. A Closed event is then issued. OLD: Abort: Calling Abort on a UDP connection (ABORT.UDP) is identical to calling Close except that the Connection will send a ConnectionError event rather than a Closed event. NEW: Abort: Calling Abort on a UDP connection (ABORT.UDP) is identical to calling Close except that a ConnectionError event rather than a Closed event is issued. OLD: CloseGroup: Calling CloseGroup on a UDP connection (ABORT.UDP) is identical to calling Close on this Connection and on all Connections in the same ConnectionGroup. NEW: CloseGroup: Calling CloseGroup on a UDP connection (ABORT.UDP) is identical to calling Close on its Connection object and on all Connections in the same ConnectionGroup. OLD: AbortGroup: Calling AbortGroup on a UDP connection (ABORT.UDP) is identical to calling Close on this Connection and on all Connections in the same ConnectionGroup. NEW: AbortGroup: Calling AbortGroup on a UDP connection (ABORT.UDP) is identical to calling Close on its Connection object and on all Connections in the same ConnectionGroup. -----Original Message----- From: Anna Brunström Sent: den 27 december 2024 17:14 To: Megan Ferguson <mfergu...@amsl.com>; Philipp S. Tiesel <phil...@tiesel.net> Cc: Michael Welzl <mich...@ifi.uio.no>; Mirja Kuehlewind <mirja.kuehlew...@ericsson.com>; Brian Trammell <i...@trammell.ch>; Tommy Pauly <tpa...@apple.com>; Colin Perkins <c...@csperkins.org>; Gorry Fairhurst <go...@erg.abdn.ac.uk>; Reese Enghardt <i...@tenghardt.net>; Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com>; rfc-edi...@rfc-editor.org; taps-...@ietf.org; taps-cha...@ietf.org; auth48archive@rfc-editor.org Subject: RE: Cluster-Wide Questions for Cluster 508: ...: Comments for 9623 Hi, Now moving to -impl. I am splitting my comments in two parts, first all comments excluding comments on Section 10 with the protocol mappings. I will take Section 10 separately as there is where I think the capitalization created some problems, as the original text was less precise, and my co-authors may want to check those updates. OLD: Candidate Racing involves attempting multiple options for Connection establishment and choosing the first option to succeed as the Protocol Stack to use for the connection. NEW: Candidate Racing involves attempting multiple options for Connection establishment and choosing the first option to succeed as the Protocol Stack to use for the Connection. --- Connection here refers to the Connection object returned to the user and should be capitalized. OLD: 2. Protocol Options NEW: 2. Protocol options --- Protocol options is not a term defined anywhere and is mostly used in lower case in the document. We have Protocol Option Racing in -arch, but not as a capitalized term used in the text, just defined as an action and capitalized as all terms including Application and Protocol Instance. And it is not the same term anyway. OLD: Protocol Options are next checked in order. NEW: Protocol options are next checked in order. --- See comment above. OLD: The primary goal of the Candidate Racing process is to successfully negotiate a Protocol Stack to an Endpoint over an interface to connect a single leaf node of the tree with as little delay and as few unnecessary connections attempts as possible. NEW: The primary goal of the Candidate Racing process is to successfully negotiate a Protocol Stack to an Endpoint over an interface to connect a single leaf node of the tree with as little delay and as few unnecessary connection attempts as possible. --- Typo in "connections attempts" OLD: The function that implements custom framing logic will be referred to as the "framer "Framer implementation", which may be provided by a Transport Services implementation or the application itself. NEW: The function that implements custom framing logic will be referred to as the "framer "Framer implementation", which may be provided by a Transport Services Implementation or the application itself. --- Implementation should be capitalized. OLD: TCP can cache cookies for use in TFO NEW: TCP can cache cookies for use in TFO. --- The period got lost in the update (I assume it was a mistake as the bullet above has one). BR, Anna -----Original Message----- From: Anna Brunström Sent: den 27 december 2024 16:13 To: Megan Ferguson <mfergu...@amsl.com>; Philipp S. Tiesel <phil...@tiesel.net> Cc: Michael Welzl <mich...@ifi.uio.no>; Mirja Kuehlewind <mirja.kuehlew...@ericsson.com>; Brian Trammell <i...@trammell.ch>; Tommy Pauly <tpa...@apple.com>; Colin Perkins <c...@csperkins.org>; Gorry Fairhurst <go...@erg.abdn.ac.uk>; Reese Enghardt <i...@tenghardt.net>; Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com>; rfc-edi...@rfc-editor.org; taps-...@ietf.org; taps-cha...@ietf.org; auth48archive@rfc-editor.org Subject: RE: Cluster-Wide Questions for Cluster 508: ...: Comments for 9621 Hi again, Below are a few details for -arch. With the changes below, I approve the document. BR, Anna OLD: Instead, it provides the Protocol Stack with additional information to allow it to make better use of modern Transport Services, while simplifying the application's role in parsing data. NEW: Instead, it provides the Protocol Stack with additional information to allow it to make better use of modern transport protocols, while simplifying the application's role in parsing data. --- This change to upper case did not come out right, as it does not refer to the Transport Services offered in the API, but the realization in the stack. Changed to transport protocols to avoid any confusion. OLD: The normative requirements described in this section allow Transport Services APIs and the Transport Services Implementation to provide this functionality without causing incompatibility or introducing security vulnerabilities. NEW: The normative requirements described in this section allow Transport Services APIs and Transport Services Implementations to provide this functionality without causing incompatibility or introducing security vulnerabilities. --- If there are multiple Transport Services APIs there are multiple Transport Services Implementations. OLD: 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). NEW: A single stack can be simple (e.g., one application stream carried over TCP running over IP) or complex (e.g,. multiple application streams carried over a multipath transport protocol using multiple subflows over IP). --- There must a be a word missing in "carried TCP", so added "over". -----Original Message----- From: Anna Brunström Sent: den 27 december 2024 15:42 To: Megan Ferguson <mfergu...@amsl.com>; Philipp S. Tiesel <phil...@tiesel.net> Cc: Michael Welzl <mich...@ifi.uio.no>; Mirja Kuehlewind <mirja.kuehlew...@ericsson.com>; Brian Trammell <i...@trammell.ch>; Tommy Pauly <tpa...@apple.com>; Colin Perkins <c...@csperkins.org>; Gorry Fairhurst <go...@erg.abdn.ac.uk>; Reese Enghardt <i...@tenghardt.net>; Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com>; rfc-edi...@rfc-editor.org; taps-...@ietf.org; taps-cha...@ietf.org; auth48archive@rfc-editor.org Subject: RE: Cluster-Wide Questions for Cluster 508: RFCs 9621, 9622, and 9623 (draft-ietf-taps-arch-19, draft-ietf-taps-interface-26, and draft-ietf-taps-impl-18) Hi all, Thanks for all the efforts with the documents, and special thanks to Megan and Michael for your huge efforts of course! Too many deadlines before Christmas, but I have now managed to go through all the updates, and in particular all the capitalization changes. While I agree with all the principles discussed, I detected a few places where it did not work out right, as well as some other nits. To make it simpler and keep things in order, let me split up my feedback in multiple mails. Let me start here with one cluster wide alignment that apply also to -api. We use in the -arch document the term Candidate Protocol Stack, consistently with capitalization in multiple places, but this has not been applied in -impl or -api. Following the principles used, I think we should align the other two documents. The following changes below are needed to align them. In 9622: OLD: Once Initiate is called, the candidate Protocol Stack(s) can cause one or more candidate transport-layer connections to be created to the specified Remote Endpoint. NEW: Once Initiate is called, the Candidate Protocol Stack(s) can cause one or more candidate transport-layer connections to be created to the specified Remote Endpoint. OLD: The Ready event occurs after Initiate has established a transport-layer connection on at least one usable candidate Protocol Stack over at least one Candidate Path. NEW: The Ready event occurs after Initiate has established a transport-layer connection on at least one usable Candidate Protocol Stack over at least one Candidate Path. In 9623: OLD: During the process of establishment (Section 4), the Connection will not necessarily be immediately bound to a transport protocol instance, since multiple candidate Protocol Stacks might be raced. NEW: During the process of establishment (Section 4), the Connection will not necessarily be immediately bound to a transport protocol instance, since multiple Candidate Protocol Stacks might be raced. OLD: Cached protocol state is primarily used during Connection establishment for a single Protocol Stack, but it may be used to influence an implementation's preference between several candidate Protocol Stacks. NEW: Cached protocol state is primarily used during Connection establishment for a single Protocol Stack, but it may be used to influence an implementation's preference between several Candidate Protocol Stacks. This was the only comment that applies to -api, which was already approved by the authors. I will come back with my other comments in separate emails. Best, Anna -----Original Message----- From: Megan Ferguson <mfergu...@amsl.com> Sent: den 23 december 2024 17:07 To: Philipp S. Tiesel <phil...@tiesel.net>; Anna Brunström <anna.brunst...@kau.se> Cc: Michael Welzl <mich...@ifi.uio.no>; Mirja Kuehlewind <mirja.kuehlew...@ericsson.com>; Brian Trammell <i...@trammell.ch>; Tommy Pauly <tpa...@apple.com>; Colin Perkins <c...@csperkins.org>; Gorry Fairhurst <go...@erg.abdn.ac.uk>; Reese Enghardt <i...@tenghardt.net>; Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com>; rfc-edi...@rfc-editor.org; taps-...@ietf.org; taps-cha...@ietf.org; auth48archive@rfc-editor.org Subject: Re: Cluster-Wide Questions for Cluster 508: RFCs 9621, 9622, and 9623 (draft-ietf-taps-arch-19, draft-ietf-taps-interface-26, and draft-ietf-taps-impl-18) Hi Philipp and *Anna, Philipp - thank you for your reply; we have updated your status to “Approved” for RFC-to-be 9623. *Anna - once we hear your approvals for RFCs-to-be 9621 and 9623, this document set will be ready to move forward in the publication process. We look forward to hearing from you at your earliest convenience as our 2024 publication window is soon to close. The AUTH48 status page for this document set is viewable at: https://www.rfc-editor.org/auth48/C508 Thank you. RFC Editor/mf > On Dec 22, 2024, at 6:42 AM, Philipp S. Tiesel <phil...@tiesel.net> wrote: > > Hi, > > first to all, but especially to Megan and Michael a very big thank you! > > I am fine with the edits and the current versions and authorise publication > of RFC-to-be 9623. > > AVE! > Philipp > >> On 21. Dec 2024, at 03:15, Megan Ferguson <mfergu...@amsl.com> wrote: >> >> Michael, >> >> Thanks for sending. We have updated and moved RFC-to-be 9622 to AUTH48-DONE >> to await the other two documents. >> >> Thank you. >> >> RFC Editor/mf >> >> >>> On Dec 20, 2024, at 6:20 PM, Michael Welzl <mich...@ifi.uio.no> wrote: >>> >>> I see that 9622 lacks my approval: I’m ok eith the latest changes and >>> approve publication! >>> >>> Sent from my phone >>> >>>> Am 21.12.2024 um 02:55 schrieb Megan Ferguson <mfergu...@amsl.com>: >>>> >>>> Greetings, >>>> >>>> Just a final reminder for the year that this document set awaits author >>>> actions. See the email thread below as well as the AUTH48 status page: >>>> >>>> https://www.rfc-editor.org/auth48/C508 >>>> >>>> Note that time is running out to move forward with a 2024 publication date >>>> due to holidays etc. Please contact us at your earliest convenience with >>>> approvals and/or updates. >>>> >>>> Thank you. >>>> >>>> RFC Editor/mf >>>> >>>>> On Dec 20, 2024, at 11:04 AM, Megan Ferguson <mfergu...@amsl.com> wrote: >>>>> >>>>> Michael and Mirja, >>>>> >>>>> Thanks for replies and explanations. We have updated the files and >>>>> rolled these changes into the current versions of the diffs so as to keep >>>>> access to the previous capping updates and all of the capping changes >>>>> together where possible (to hopefully keep everyone in the loop). >>>>> >>>>> Notes: >>>>> -Mirja’s first point that Michael suggests leaving as was: we have made >>>>> no changes as this sounds acceptable to Mirja and Michael’s preference. >>>>> >>>>> -9622: we lowercased “Cellular data plan” in one instance. >>>>> >>>>> -9623: we updated to use only “policy” instead of “System Policy”. >>>>> >>>>> -9621: we have lowercased a single instance of “Message” and removed >>>>> “Properties” as seemed agreeable to both Mirja and Michael. >>>>> >>>>> Please review and confirm that these updates appear as desired. >>>>> >>>>> The AUTH48 status page for the entire cluster is viewable here: >>>>> https://www.rfc-editor.org/auth48/C508 >>>>> >>>>> Each document’s updated files and diffs are available as listed below: >>>>> >>>>> 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) >>>>> https://www.rfc-editor.org/authors/rfc9621-lastrfcdiff.html (ditto >>>>> but rfcdiff) >>>>> >>>>> The following diff contains the capping changes from the last two rounds >>>>> together: >>>>> https://www.rfc-editor.org/authors/rfc9621caps-diff.html >>>>> >>>>> —— >>>>> >>>>> The files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9622.txt >>>>> https://www.rfc-editor.org/authors/rfc9622.pdf >>>>> https://www.rfc-editor.org/authors/rfc9622.html >>>>> https://www.rfc-editor.org/authors/rfc9622.xml >>>>> >>>>> The relevant diff files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9622-diff.html >>>>> (comprehensive diff) >>>>> https://www.rfc-editor.org/authors/rfc9622-auth48diff.html (AUTH48 >>>>> changes only) >>>>> https://www.rfc-editor.org/authors/rfc9622-lastdiff.html (last to >>>>> current version only) >>>>> https://www.rfc-editor.org/authors/rfc9622-lastrfcdiff.html (ditto >>>>> but rfcdiff) >>>>> >>>>> >>>>> —— >>>>> >>>>> The files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9623.txt >>>>> https://www.rfc-editor.org/authors/rfc9623.pdf >>>>> https://www.rfc-editor.org/authors/rfc9623.html >>>>> https://www.rfc-editor.org/authors/rfc9623.xml >>>>> >>>>> The relevant diff files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9623-diff.html >>>>> (comprehensive diff) >>>>> https://www.rfc-editor.org/authors/rfc9623-auth48diff.html (AUTH48 >>>>> changes only) >>>>> https://www.rfc-editor.org/authors/rfc9623-lastdiff.html (last to >>>>> current version only) >>>>> https://www.rfc-editor.org/authors/rfc9623-lastrfcdiff.html (ditto >>>>> but rfcdiff) >>>>> >>>>> The following diff contains the capping changes from the last two rounds >>>>> together: >>>>> https://www.rfc-editor.org/authors/rfc9623caps-diff.html >>>>> >>>>> Please review carefully and let us know if any further changes are >>>>> necessary. >>>>> >>>>> Thank you. >>>>> >>>>> RFC Editor/mf >>>>> >>>>>>> On Dec 20, 2024, at 10:08 AM, Michael Welzl <mich...@ifi.uio.no> wrote: >>>>>> >>>>>> Hi Mirja, >>>>>> >>>>>> Many thanks for taking a careful look! I’m sorry, I can’t do any more >>>>>> updates for a while now - perhaps someone else could have a go at these? >>>>>> >>>>>> Answers below: >>>>>> >>>>>> >>>>>>> On Dec 20, 2024, at 8:43 PM, Mirja Kuehlewind >>>>>>> <mirja.kuehlew...@ericsson.com> wrote: >>>>>>> >>>>>>> Hi Michael, >>>>>>> >>>>>>> thanks for the huge amount of work! >>>>>>> >>>>>>> Sorry that I have to say this but I'm not fully convinced regarding the >>>>>>> capitalization of Connection, Property and Messages. I think I would >>>>>>> have preference to keep them lower case in most of the cases, and use >>>>>>> upper case really only if a very specific "implementation instance" is >>>>>>> meant. However, I can fully live with the current approach now as long >>>>>>> as it is unified. >>>>>> >>>>>> First and foremost, I wanted to minimize changes, or at least stay true >>>>>> to the original intention. I think what I did follows that - we have >>>>>> long used capitalization of these terms to distinguish between the >>>>>> “upper layer” and the “lower layer”. For Connection, the -arch draft >>>>>> (9621) even explicitly says this, in two places (search for “capital”). >>>>>> So I think we should keep these as they are. >>>>>> >>>>>> >>>>>>> Still, I have a few comments though where I find something not >>>>>>> completely right in my review: >>>>>>> >>>>>>> First, I agree with Reese on the use of " Cellular data plan" in >>>>>>> RFC9622. This is just an example and normal word in a sentence and does >>>>>>> not relate to any property in this occurrence and therefore should be >>>>>>> lower case. >>>>>> >>>>>> As I explained, I did this to follow what already was the common style >>>>>> in the documents; but this is totally fine with me, and I can’t imagine >>>>>> anyone strongly disagreeing. Let’s lower-case it. >>>>>> >>>>>> >>>>>>> For RFC9623, I did struggle with this occurrence of "System policy" >>>>>>> (this sentence is twice in the doc): >>>>>>> >>>>>>> "Similar to a derived endpoint, the paths should be ranked based on >>>>>>> preference, System Policy, and performance." >>>>>>> >>>>>>> Because it's listed here between preference and performance I think it >>>>>>> should be lower case. Or you could even remove the word "System" and >>>>>>> only use policy as an undefined term to avoid confusion. >>>>>> >>>>>> Ok for me to change. >>>>>> >>>>>> >>>>>>> And for RFC9621, I have these two cases: >>>>>>> >>>>>>> "The Socket API provides a Message interface for datagram protocols" >>>>>>> >>>>>>> It's _a_ undefined message interface. Here message interface is just >>>>>>> used as a specific kind of interface and not _the_ message interface we >>>>>>> use in TAPS. >>>>>> >>>>>> Good catch, I agree. >>>>>> >>>>>> >>>>>>> "This automated selection is constrained by the Properties and >>>>>>> preferences expressed by the application and requires applications to >>>>>>> explicitly set Properties that define any necessary constraints on >>>>>>> protocol, path, and interface selection." >>>>>>> >>>>>>> I would either lower-case "Properties" when noted together with >>>>>>> "preferences" or remove it, because preferences are expressed by >>>>>>> Properties. >>>>>> >>>>>> I don’t really see the problem here; I’m against lower-casing >>>>>> “Properties”, but removing it would be okay. >>>>>> >>>>>> Cheers, >>>>>> Michael >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks again. Just my 2c... >>>>>>> >>>>>>> Mirja >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 20.12.24, 04:52, "Michael Welzl" <mich...@ifi.uio.no >>>>>>> <mailto:mich...@ifi.uio.no>> wrote: >>>>>>> >>>>>>> >>>>>>> Hi ! >>>>>>> >>>>>>> >>>>>>> Here come the new versions! >>>>>>> >>>>>>> >>>>>>> Once these changes are incorporated, I approve publication wherever >>>>>>> it’s missing (as a co-author: RFCs 9622 and 9623). >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Michael >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Dec 20, 2024, at 12:00 AM, Megan Ferguson <mfergu...@amsl.com >>>>>>>> <mailto:mfergu...@amsl.com>> wrote: >>>>>>>> >>>>>>>> Hi Michael, >>>>>>>> >>>>>>>>> I will apply all of these changes to the XML files (the latest >>>>>>>>> version you sent) and send them back to you. >>>>>>>> >>>>>>>> Excellent. We will await the files updated with all of the changes >>>>>>>> before taking any action on our end. >>>>>>>> >>>>>>>> As to the get-together: thanks for the invite! You will have to reach >>>>>>>> out to whoever ends up at the RFC Editor desk at IETF if you would >>>>>>>> like help celebrating this accomplishment :). We were happy to do our >>>>>>>> part and very much appreciate your time and attention in getting this >>>>>>>> cluster ready for publication (no easy feat on Michael’s part)! >>>>>>>> >>>>>>>> RFC Editor/mf >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >> > > AVE! > Philipp S. Tiesel / phils… > -- > {phils}--->---(ph...@in-panik.de)--->---(http://phils.in-panik.de)----, > wenn w eine aube ist dn man au dran dre en | > o Schr an muss hc h (Kurt Schwitters) | > :wq! <----(phone: +49-179-6737439)---<---(jabber: ph...@in-panik.de)----' > När du skickar e-post till Karlstads universitet behandlar vi dina personuppgifter<https://www.kau.se/gdpr>. When you send an e-mail to Karlstad University, we will process your personal data<https://www.kau.se/en/gdpr>. -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
