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
