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 <[email protected]> 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.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, 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 > <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 [email protected] > <mailto:[email protected]> 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 [email protected] <mailto:[email protected]> > Sent: den 4 december 2024 11:10 > To: Brian Trammell (IETF) [email protected] <mailto:[email protected]> > Cc: Anna Brunström [email protected] <mailto:[email protected]>; > Mirja Kuehlewind [email protected] > <mailto:[email protected]>; Megan Ferguson [email protected] > <mailto:[email protected]>; Gorry Fairhurst [email protected] > <mailto:[email protected]>; Philipp S. Tiesel [email protected] > <mailto:[email protected]>; Colin Perkins [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; Reese Enghardt [email protected] > <mailto:[email protected]>; Tommy Pauly [email protected] > <mailto:[email protected]>; [email protected] <mailto:[email protected]>; > [email protected] <mailto:[email protected]>; Zaheduzzaman Sarker > [email protected] <mailto:[email protected]>; > [email protected] <mailto:[email protected]> > 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) [email protected] > <mailto:[email protected]> 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 [email protected] > <mailto:[email protected]> 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 [email protected] > <mailto:[email protected]> > Sent: den 3 december 2024 17:45 > To: Megan Ferguson [email protected] <mailto:[email protected]>; Michael > Welzl > [email protected] <mailto:[email protected]>; Gorry Fairhurst > [email protected] <mailto:[email protected]> > Cc: Philipp S. Tiesel [email protected] <mailto:[email protected]>; Colin > Perkins > [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; Reese Enghardt > [email protected] <mailto:[email protected]>; Tommy Pauly [email protected] > <mailto:[email protected]>; > [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; Anna Brunström > [email protected] <mailto:[email protected]>; Brian Trammell (IETF) > [email protected] <mailto:[email protected]>; > Zaheduzzaman Sarker [email protected] > <mailto:[email protected]>; > [email protected] <mailto:[email protected]> > 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" <[email protected] > <mailto:[email protected]> mailto:[email protected] > <mailto:[email protected]>> wrote: > > [You don't often get email from [email protected] <mailto:[email protected]> > mailto:[email protected] <mailto:[email protected]> . Learn why this is > important at > https://aka.ms/LearnAboutSenderIdentification > 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: > > 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. > > 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.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.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.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> > 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> > 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> > 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> > 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> > 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> > 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 <[email protected] > <mailto:[email protected]> mailto:[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]> mailto:[email protected] > <mailto:[email protected]>> 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.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.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.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> > 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> > 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> > 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> > 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> > 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 <[email protected] > <mailto:[email protected]> mailto:[email protected] > <mailto:[email protected]>> 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.html > <https://www.rfc-editor.org/authors/rfc9622.html> > https://www.rfc-editor.org/authors/rfc9622.html > <https://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 <https://www.kau.se/gdpr> . > When you send an e-mail to Karlstad University, we will process your personal > datahttps://www.kau.se/en/gdpr <https://www.kau.se/en/gdpr> . > > När du skickar e-post till Karlstads universitet behandlar vi dina > personuppgifterhttps://www.kau.se/gdpr <https://www.kau.se/gdpr> . > When you send an e-mail to Karlstad University, we will process your personal > datahttps://www.kau.se/en/gdpr <https://www.kau.se/en/gdpr> . >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
