Hi Michael, all, Thanks for confirming the suggested changes Michael, and sorry for the confusion with the “framer “Framer part. That was my bad. I had the diff file open and cut the old text from there and must have missed removing the old “framer” in this text block.
The intended update is as you wrote below. Best regards, Anna From: Michael Welzl <mich...@ifi.uio.no> Sent: den 28 december 2024 12:45 To: Anna Brunström <anna.brunst...@kau.se> Cc: Megan Ferguson <mfergu...@amsl.com>; Philipp S. Tiesel <phil...@tiesel.net>; 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 Dear all, Many thanks to Anna for this very thorough check! This is just to note that I agree with all suggestions in this email and the other two emails Anna wrote preceding this and included below. Just a very minor note: the fifth OLD / NEW suggestion contains an oddity that confused me at first: 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. … and that oddity is: “framer “Framer This, I think, is just a nit that happened. This double use of framer / Framer neither seems to exist in the original nor in the last version ( https://www.rfc-editor.org/authors/rfc9623.html ). Anyway the intention is to correct the capitalization of “Implementation” after “Transport Services”. So, I think the correct update is: OLD: The function that implements custom framing logic will be referred to as the "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 implementation", which may be provided by a Transport Services Implementation or the application itself. Cheers, Michael On Dec 27, 2024, at 5:14 PM, Anna Brunström <anna.brunst...@kau.se<mailto:anna.brunst...@kau.se>> wrote: 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<mailto:mfergu...@amsl.com>>; Philipp S. Tiesel <phil...@tiesel.net<mailto:phil...@tiesel.net>> Cc: Michael Welzl <mich...@ifi.uio.no<mailto:mich...@ifi.uio.no>>; Mirja Kuehlewind <mirja.kuehlew...@ericsson.com<mailto:mirja.kuehlew...@ericsson.com>>; Brian Trammell <i...@trammell.ch<mailto:i...@trammell.ch>>; Tommy Pauly <tpa...@apple.com<mailto:tpa...@apple.com>>; Colin Perkins <c...@csperkins.org<mailto:c...@csperkins.org>>; Gorry Fairhurst <go...@erg.abdn.ac.uk<mailto:go...@erg.abdn.ac.uk>>; Reese Enghardt <i...@tenghardt.net<mailto:i...@tenghardt.net>>; Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com<mailto:zahed.sarker.i...@gmail.com>>; rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>; taps-...@ietf.org<mailto:taps-...@ietf.org>; taps-cha...@ietf.org<mailto:taps-cha...@ietf.org>; auth48archive@rfc-editor.org<mailto: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<mailto:mfergu...@amsl.com>>; Philipp S. Tiesel <phil...@tiesel.net<mailto:phil...@tiesel.net>> Cc: Michael Welzl <mich...@ifi.uio.no<mailto:mich...@ifi.uio.no>>; Mirja Kuehlewind <mirja.kuehlew...@ericsson.com<mailto:mirja.kuehlew...@ericsson.com>>; Brian Trammell <i...@trammell.ch<mailto:i...@trammell.ch>>; Tommy Pauly <tpa...@apple.com<mailto:tpa...@apple.com>>; Colin Perkins <c...@csperkins.org<mailto:c...@csperkins.org>>; Gorry Fairhurst <go...@erg.abdn.ac.uk<mailto:go...@erg.abdn.ac.uk>>; Reese Enghardt <i...@tenghardt.net<mailto:i...@tenghardt.net>>; Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com<mailto:zahed.sarker.i...@gmail.com>>; rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>; taps-...@ietf.org<mailto:taps-...@ietf.org>; taps-cha...@ietf.org<mailto:taps-cha...@ietf.org>; auth48archive@rfc-editor.org<mailto: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<mailto:mfergu...@amsl.com>> Sent: den 23 december 2024 17:07 To: Philipp S. Tiesel <phil...@tiesel.net<mailto:phil...@tiesel.net>>; Anna Brunström <anna.brunst...@kau.se<mailto:anna.brunst...@kau.se>> Cc: Michael Welzl <mich...@ifi.uio.no<mailto:mich...@ifi.uio.no>>; Mirja Kuehlewind <mirja.kuehlew...@ericsson.com<mailto:mirja.kuehlew...@ericsson.com>>; Brian Trammell <i...@trammell.ch<mailto:i...@trammell.ch>>; Tommy Pauly <tpa...@apple.com<mailto:tpa...@apple.com>>; Colin Perkins <c...@csperkins.org<mailto:c...@csperkins.org>>; Gorry Fairhurst <go...@erg.abdn.ac.uk<mailto:go...@erg.abdn.ac.uk>>; Reese Enghardt <i...@tenghardt.net<mailto:i...@tenghardt.net>>; Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com<mailto:zahed.sarker.i...@gmail.com>>; rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>; taps-...@ietf.org<mailto:taps-...@ietf.org>; taps-cha...@ietf.org<mailto:taps-cha...@ietf.org>; auth48archive@rfc-editor.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:mich...@ifi.uio.no%20%3cmailto: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<mailto:mfergu...@amsl.com%20%3cmailto: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)----<mailto:ph...@in-panik.de)---%3e---(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)----<mailto: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>. 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
