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> 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>; 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
