All, This update to the title has been incorporated into our current version of the files as requested. We will update the references in 9621 and 9623 that point to this document as well.
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 (last to current rfcdiff) 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, resolution to the document-specific questions listed there, and responses to our cluster-wide queries prior to moving forward to publication. The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9622 Thank you. RFC Editor/mf > On Dec 5, 2024, at 4:41 AM, Mirja Kuehlewind <mirja.kuehlew...@ericsson.com> > wrote: > > Yes, thanks, that title looks good to me as well. > > > > From: Michael Welzl <mich...@ifi.uio.no> > Date: Thursday, 5. December 2024 at 12:25 > To: Colin Perkins <c...@csperkins.org> > Cc: Reese Enghardt <i...@tenghardt.net>, Megan Ferguson <mfergu...@amsl.com>, > Anna Brunström <anna.brunst...@kau.se>, "Brian Trammell (IETF)" > <i...@trammell.ch>, Mirja Kuehlewind <mirja.kuehlew...@ericsson.com>, Gorry > Fairhurst <go...@erg.abdn.ac.uk>, "Philipp S. Tiesel" <phil...@tiesel.net>, > "rfc-edi...@rfc-editor.org" <rfc-edi...@rfc-editor.org>, Tommy Pauly > <tpa...@apple.com>, "taps-...@ietf.org" <taps-...@ietf.org>, > "taps-cha...@ietf.org" <taps-cha...@ietf.org>, Zaheduzzaman Sarker > <zahed.sarker.i...@gmail.com>, "auth48archive@rfc-editor.org" > <auth48archive@rfc-editor.org> > Subject: Re: AUTH48: RFC-to-be 9622 <draft-ietf-taps-interface-26> for your > review > > Dear all, > > I’m also happy with the last version here - and I also agree with Colin’s > suggestion. I’m not sure it’s bike-shedding, it really seems better to me. > > Cheers, > Michael > > > > >> On 5 Dec 2024, at 12:21, Colin Perkins <c...@csperkins.org> wrote: >> >> Hi, >> I’m also happy with the latest version. >> (Well, I’d suggest “An Abstract Application Programming Interface (API) for >> Transport Services” as the title, but I don’t care that much and we’re >> likely getting into the realm of bike-shedding now…) >> Cheers, >> Colin >> On 5 Dec 2024, at 1:09, Reese Enghardt wrote: >>> Hi all, >>> Thank you so much for all the changes and discussion to align on them! >>> As a co-author, I have reviewed the diffs and the recent HTML version, and >>> I approve of the changes. >>> Best, >>> Reese >>> On 12/4/24 10:03, Megan Ferguson wrote: >>>> All, >>>> Thank you for your replies. We have updated the title and the lists as >>>> discussed below. >>>> 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 (last to >>>> current rfcdiff) >>>> 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, resolution to the document-specific questions listed there, >>>> and responses to our cluster-wide queries prior to moving forward to >>>> publication. >>>> The AUTH48 status page for this document is available here: >>>> https://www.rfc-editor.org/auth48/rfc9622 >>>> Thank you. >>>> RFC Editor/mf >>>> Thank you. >>>>> On Dec 4, 2024, at 3:29 AM, Anna Brunström anna.brunst...@kau.se wrote: >>>>> Hi all, >>>>> The suggestion below looks good to me. >>>>> I also agree to keep the titles of the other documents as is. >>>>> BR, >>>>> Anna >>>>> -----Original Message----- >>>>> From: Michael Welzl mich...@ifi.uio.no >>>>> Sent: den 4 december 2024 11:10 >>>>> To: Brian Trammell (IETF) i...@trammell.ch >>>>> Cc: Anna Brunström anna.brunst...@kau.se; Mirja Kuehlewind >>>>> mirja.kuehlew...@ericsson.com; Megan Ferguson mfergu...@amsl.com; Gorry >>>>> Fairhurst go...@erg.abdn.ac.uk; Philipp S. Tiesel phil...@tiesel.net; >>>>> Colin Perkins c...@csperkins.org; rfc-edi...@rfc-editor.org; Reese >>>>> Enghardt i...@tenghardt.net; Tommy Pauly tpa...@apple.com; >>>>> taps-...@ietf.org; taps-cha...@ietf.org; Zaheduzzaman Sarker >>>>> zahed.sarker.i...@gmail.com; auth48archive@rfc-editor.org >>>>> Subject: Re: AUTH48: RFC-to-be 9622 <draft-ietf-taps-interface-26> for >>>>> your review >>>>> Hi, >>>>> About the title: >>>>> IIRC after all these emails, the main concern from the RFC Editor was >>>>> about the use of “Application Layer Interface” instead of “Application >>>>> Programming Interface”. >>>>> I was okay with changing this, but it seems that I created a mess by >>>>> suggesting “The Transport Services Application Programming Interface” >>>>> instead of only replacing the word “Layer” with “Programming”. No deeper >>>>> reason here, it just spontaneously looked better to me but I’m totally >>>>> okay with the other variant, my bad, and my apologies. >>>>> So, I suggest we go with: "An Abstract Application Programming Interface >>>>> to Transport Services”. Is that okay for folks here? >>>>> BTW, the other two documents have the following titles - and I think they >>>>> should stay as they are: >>>>> Architecture and Requirements for Transport Services >>>>> and: >>>>> Implementing Interfaces to Transport Services >>>>> Cheers, >>>>> Michael >>>>>> On 4 Dec 2024, at 08:23, Brian Trammell (IETF) i...@trammell.ch wrote: >>>>>> Hi all, >>>>>> I am also not thrilled about the title change, and would suggest >>>>>> reverting it. >>>>>> If the more academic style here (indefinite article) strongly violates >>>>>> RFC Editor house style, it remains important to call out in the title >>>>>> that this API is abstract; not doing so risks confusing readers that the >>>>>> point of this specification is to establish a “shape” IMO. >>>>>> Otherwise have reviewed the diffs and the document LGTM. >>>>>> Cheers, >>>>>> Brian >>>>>>> On 3 Dec 2024, at 18:26, Anna Brunström anna.brunst...@kau.se wrote: >>>>>>> Hi all, >>>>>>> As Mirja brought it up, I also find the new title a bit strange. >>>>>>> But this is just a comment from your shepherd, in case you want to >>>>>>> think about the title again. >>>>>>> BR, >>>>>>> Anna >>>>>>> -----Original Message----- >>>>>>> From: Mirja Kuehlewind mirja.kuehlew...@ericsson.com >>>>>>> Sent: den 3 december 2024 17:45 >>>>>>> To: Megan Ferguson mfergu...@amsl.com; Michael Welzl >>>>>>> mich...@ifi.uio.no; Gorry Fairhurst go...@erg.abdn.ac.uk >>>>>>> Cc: Philipp S. Tiesel phil...@tiesel.net; Colin Perkins >>>>>>> c...@csperkins.org; rfc-edi...@rfc-editor.org; Reese Enghardt >>>>>>> i...@tenghardt.net; Tommy Pauly tpa...@apple.com; >>>>>>> taps-...@ietf.org; taps-cha...@ietf.org; Anna Brunström >>>>>>> anna.brunst...@kau.se; Brian Trammell (IETF) i...@trammell.ch; >>>>>>> Zaheduzzaman Sarker zahed.sarker.i...@gmail.com; >>>>>>> auth48archive@rfc-editor.org >>>>>>> Subject: Re: AUTH48: RFC-to-be 9622 <draft-ietf-taps-interface-26> >>>>>>> for your review >>>>>>> Hi all, >>>>>>> thanks for the work.! >>>>>>> I have to say I'm not fully sure about the title change but okay for me >>>>>>> if everybody else is okay. >>>>>>> I reviewed all changes and approve them. >>>>>>> Please note that there is now a superfluous bracket in Appendix C: >>>>>>> OLD >>>>>>> See Section 4 >>>>>>> of [RFC8303]) for 1) further details on >>>>>>> NEW >>>>>>> See Section 4 >>>>>>> of [RFC8303] for 1) further details on >>>>>>> Mirja >>>>>>> On 02.12.24, 19:29, "Megan Ferguson" <mfergu...@amsl.com >>>>>>> mailto:mfergu...@amsl.com> wrote: >>>>>>> [You don't often get email from mfergu...@amsl.com >>>>>>> mailto:mfergu...@amsl.com . Learn why this is important at >>>>>>> https://aka.ms/LearnAboutSenderIdentification >>>>>>> https://aka.ms/LearnAboutSenderIdentification ] >>>>>>> Hi Michael and Gorry, >>>>>>> We have compiled our changes in response to both Michael’s email below >>>>>>> and Gorry’s message about the <> tagging (see the 9621 email thread) in >>>>>>> our postings below. >>>>>>> Just a few notes: >>>>>>> 1. Please review our updates to remove <> as suggested in Gorry’s >>>>>>> mail. We think we’ve understood Gorry’s intent, but let us know if >>>>>>> changes are necessary. In particular, >>>>>>> -Section 11 does not have code, but we believe you’d like the artwork >>>>>>> to stay as it was. Please correct if this assumption is not what was >>>>>>> intended. >>>>>>> -We have removed the <> beginning in Section 7.3 to the end of the doc >>>>>>> (not all terms listed in Gorry’s mail appeared in that section). Please >>>>>>> let us know if any further changes or reversions are necessary. >>>>>>> -We also cut the <> from a comment in the code. Please review and let >>>>>>> us know if this should be reverted. >>>>>>> 2. Regarding the update from Michael’s mail below: >>>>>>>> Section 13: >>>>>>>> I’m not sure about the placement of “either” here. Again, who am I to >>>>>>>> say, I’m not a native speaker… but it might be a mistake? Anyway, the >>>>>>>> sentence is just very long and hard to read. Hence my suggestion: >>>>>>>> OLD: >>>>>>>> While it is not >>>>>>>> necessarily expected that both systems are implemented by the same >>>>>>>> authority, it is expected that the Transport Services Implementation >>>>>>>> is provided as a library either that is selected by the application >>>>>>>> from a trusted party or that it is part of the operating system that >>>>>>>> the application also relies on for other tasks. >>>>>>>> NEW: >>>>>>>> While it is not >>>>>>>> necessarily expected that both systems are implemented by the same >>>>>>>> authority, it is expected that the Transport Services Implementation >>>>>>>> is provided as a library that is selected by the application from a >>>>>>>> trusted party. Alternatively, it could be part of the operating >>>>>>>> system that the application also relies on for other tasks. >>>>>>> Thank you for calling this sentence to our attention as the structure >>>>>>> indeed needs help. We also feel something is off with the verb tense >>>>>>> and “expected” matching up (seems like a future or conditional >>>>>>> situation instead of simple present maybe?). >>>>>>> Please take a look at our suggested rewrite and let us know if this >>>>>>> would work? >>>>>>> Perhaps/Current: >>>>>>> The same authority implementing both systems is not necessarily >>>>>>> expected. >>>>>>> However, there is an expectation that the Transport Services >>>>>>> Implementation would either: >>>>>>> · be provided as a library that is selected by the application >>>>>>> from a >>>>>>> trusted party or >>>>>>> · be part of the operating system that the application also >>>>>>> relies on for other tasks. >>>>>>> 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/rfc9622.txt >>>>>>> https://www.rfc-editor.org/authors/rfc9622.txt >>>>>>> https://www.rfc-editor.org/authors/rfc9622.pdf >>>>>>> https://www.rfc-editor.org/authors/rfc9622.pdf >>>>>>> https://www.rfc-editor.org/authors/rfc9622.html >>>>>>> https://www.rfc-editor.org/authors/rfc9622.html >>>>>>> https://www.rfc-editor.org/authors/rfc9622.xml >>>>>>> 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 >>>>>>> https://www.rfc-editor.org/authors/rfc9622-diff.html (comprehensive >>>>>>> diff) https://www.rfc-editor.org/authors/rfc9622-auth48diff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9622-auth48diff.html (AUTH48 >>>>>>> changes only) >>>>>>> https://www.rfc-editor.org/authors/rfc9622-lastdiff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9622-lastdiff.html (last to >>>>>>> current version only) >>>>>>> https://www.rfc-editor.org/authors/rfc9622-lastrfcdiff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9622-lastrfcdiff.html (last >>>>>>> to current rfcdiff) >>>>>>> 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/rfc9622 >>>>>>> https://www.rfc-editor.org/auth48/rfc9622 >>>>>>> Thank you. >>>>>>> RFC Editor/mf >>>>>>>> On Nov 27, 2024, at 7:09 AM, Michael Welzl <mich...@ifi.uio.no >>>>>>>> mailto:mich...@ifi.uio.no> wrote: >>>>>>>> Dear RFC Editor(s), Megan, everyone, >>>>>>>> Many thanks for the great work! Having carefully read the diff, I only >>>>>>>> have a handful of last suggestions: >>>>>>>> Section 6.2: >>>>>>>> I wonder if this sentence is correct? "At which point, Selection >>>>>>>> Properties can only be read to check the properties used by the >>>>>>>> Connection.” >>>>>>>> If it is, all is well ! (I’m not a native speaker). Else, I suggest: >>>>>>>> OLD: >>>>>>>> At which point, Selection Properties can only be read to check the >>>>>>>> properties used by the Connection. >>>>>>>> NEW: >>>>>>>> At this point, Selection Properties can only be read to check the >>>>>>>> properties used by the Connection. >>>>>>>> Section 9.3.2.2: >>>>>>>> This is an oversight from us that I just noticed now, apologies: >>>>>>>> OLD: >>>>>>>> // Receive the first 1000 bytes, bytes; message is incomplete >>>>>>>> NEW: >>>>>>>> // Receive the first 1000 bytes, bytes; Message is incomplete >>>>>>>> and, just below: >>>>>>>> OLD: >>>>>>>> // Receive the last 500 bytes, bytes; message is incomplete >>>>>>>> NEW: >>>>>>>> // Receive the last 500 bytes, bytes; Message is incomplete >>>>>>>> Section 13: >>>>>>>> I’m not sure about the placement of “either” here. Again, who am I to >>>>>>>> say, I’m not a native speaker… but it might be a mistake? Anyway, the >>>>>>>> sentence is just very long and hard to read. Hence my suggestion: >>>>>>>> OLD: >>>>>>>> While it is not >>>>>>>> necessarily expected that both systems are implemented by the same >>>>>>>> authority, it is expected that the Transport Services Implementation >>>>>>>> is provided as a library either that is selected by the application >>>>>>>> from a trusted party or that it is part of the operating system that >>>>>>>> the application also relies on for other tasks. >>>>>>>> NEW: >>>>>>>> While it is not >>>>>>>> necessarily expected that both systems are implemented by the same >>>>>>>> authority, it is expected that the Transport Services Implementation >>>>>>>> is provided as a library that is selected by the application from a >>>>>>>> trusted party. Alternatively, it could be part of the operating >>>>>>>> system that the application also relies on for other tasks. >>>>>>>> Section 13: >>>>>>>> misplaced space: >>>>>>>> OLD: >>>>>>>> Specifically, Messages that are received partially (see Section >>>>>>>> 9.3.2.2 )could be a source of truncation attacks if applications do >>>>>>>> not distinguish between partial Messages and complete Messages. >>>>>>>> NEW: >>>>>>>> Specifically, Messages that are received partially (see Section >>>>>>>> 9.3.2.2) could be a source of truncation attacks if applications do >>>>>>>> not distinguish between partial Messages and complete Messages. >>>>>>>> Cheers, >>>>>>>> Michael >>>>>>>>> On 25 Nov 2024, at 16:38, Megan Ferguson <mfergu...@amsl.com >>>>>>>>> mailto:mfergu...@amsl.com> wrote: >>>>>>>>> Michael and Philipp, >>>>>>>>> Thank you for your replies. We have updated the document as requested >>>>>>>>> and now list questions 39, 41, and 42 as the only issues in need of >>>>>>>>> resolution from our initial email. Just a reminder that further >>>>>>>>> cluster-wide questions as well as capitalization questions will be >>>>>>>>> forthcoming. >>>>>>>>> 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/rfc9622.txt >>>>>>>>> https://www.rfc-editor.org/authors/rfc9622.txt >>>>>>>>> https://www.rfc-editor.org/authors/rfc9622.pdf >>>>>>>>> https://www.rfc-editor.org/authors/rfc9622.pdf >>>>>>>>> https://www.rfc-editor.org/authors/rfc9622.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9622.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9622.xml >>>>>>>>> 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 >>>>>>>>> https://www.rfc-editor.org/authors/rfc9622-diff.html >>>>>>>>> (comprehensive >>>>>>>>> diff) https://www.rfc-editor.org/authors/rfc9622-auth48diff.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9622-auth48diff.html >>>>>>>>> (AUTH48 changes only) >>>>>>>>> https://www.rfc-editor.org/authors/rfc9622-lastdiff.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9622-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/rfc9622 >>>>>>>>> https://www.rfc-editor.org/auth48/rfc9622 >>>>>>>>> Thank you. >>>>>>>>> RFC Editor/mf >>>>>>>>>> On Nov 23, 2024, at 4:38 AM, Michael Welzl <mich...@ifi.uio.no >>>>>>>>>> mailto:mich...@ifi.uio.no> wrote: >>>>>>>>>> Dear all, >>>>>>>>>> Many thanks Megan and everyone from me as well - and thanks to >>>>>>>>>> Philipp for his answer! >>>>>>>>>> I would just like to suggest a change to Philipp’s response to >>>>>>>>>> question 22, please see below: >>>>>>>>>>>> Question 22: >>>>>>>>>>>> >>>>>>>>>>>> We didn’t see clarification on what “this” refers to: >>>>>>>>>>>>> Original: >>>>>>>>>>>>> This can be used by the system to disable the coalescing of >>>>>>>>>>>>> multiple small Messages into larger packets (Nagle's algorithm);.. >>>>>>>>>>>>> a) How may we clarify the use of "This"? >>>>>>>>>>> This means “Choosing this capacity profile”. >>>>>>>>>>> I suggest to update as follows: >>>>>>>>>>> OLD: >>>>>>>>>>> This can be used by the system >>>>>>>>>>> to disable the coalescing of multiple small Messages into larger >>>>>>>>>>> packets (Nagle's algorithm); >>>>>>>>>>> NEW: >>>>>>>>>>> Transport system implementations SHOULD disable the coalescing of >>>>>>>>>>> multiple small Messages into larger packets (Nagle algorithm (see >>>>>>>>>>> Section 4.2.3.4 of [RFC1122])); >>>>>>>>>> Indeed, it means choosing this (really, value of the) capacity >>>>>>>>>> profile, as Philipp says. However, I don’t think we want (or even >>>>>>>>>> can) enter a discussion about the use of uppercase SHOULD at this >>>>>>>>>> point. Instead, let me suggest the following: >>>>>>>>>> ORIGINAL: >>>>>>>>>> This can be used by the system >>>>>>>>>> to disable the coalescing of multiple small Messages into larger >>>>>>>>>> packets (Nagle's algorithm); >>>>>>>>>> PRESENT (according to >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9622.htmlhttps://www.rfc-editor.org/authors/rfc9622.html >>>>>>>>>> ): >>>>>>>>>> This can be used by the system to disable the coalescing of >>>>>>>>>> multiple small Messages into larger packets (Nagle algorithm (see >>>>>>>>>> Section >>>>>>>>>> 4.2.3.4 of [RFC1122])); >>>>>>>>>> NEW: >>>>>>>>>> The "Low Latency/Interactive” value of the capacity profile can be >>>>>>>>>> used by the system to disable the coalescing of multiple small >>>>>>>>>> Messages into larger packets (Nagle algorithm, see Section 4.2.3.4 >>>>>>>>>> of [RFC1122]); >>>>>>>>>> This suggested update avoids the SHOULD, but it also suggests to >>>>>>>>>> avoid the double brackets. I don’t have a strong opinion about the >>>>>>>>>> double brackets, but if the use of the comma instead of the double >>>>>>>>>> brackets is okay with the RFC Editor style, then I think this would >>>>>>>>>> look better. >>>>>>>>>> Many thanks again, everyone! >>>>>>>>>> Cheers, >>>>>>>>>> Michael >>>>>>> När du skickar e-post till Karlstads universitet behandlar vi dina >>>>>>> personuppgifterhttps://www.kau.se/gdpr . >>>>>>> When you send an e-mail to Karlstad University, we will process your >>>>>>> personal datahttps://www.kau.se/en/gdpr . >>>>> När du skickar e-post till Karlstads universitet behandlar vi dina >>>>> personuppgifterhttps://www.kau.se/gdpr . >>>>> When you send an e-mail to Karlstad University, we will process your >>>>> personal datahttps://www.kau.se/en/gdpr . -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
