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 <[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]> > Sent: den 4 december 2024 11:10 > To: Brian Trammell (IETF) <[email protected]> > Cc: Anna Brunström <[email protected]>; Mirja Kuehlewind > <[email protected]>; Megan Ferguson <[email protected]>; Gorry > Fairhurst <[email protected]>; Philipp S. Tiesel <[email protected]>; > Colin Perkins <[email protected]>; [email protected]; Reese Enghardt > <[email protected]>; Tommy Pauly <[email protected]>; [email protected]; > [email protected]; Zaheduzzaman Sarker <[email protected]>; > [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]> 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]> 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]> >>> Sent: den 3 december 2024 17:45 >>> To: Megan Ferguson <[email protected]>; Michael Welzl >>> <[email protected]>; Gorry Fairhurst <[email protected]> >>> Cc: Philipp S. Tiesel <[email protected]>; Colin Perkins >>> <[email protected]>; [email protected]; Reese Enghardt >>> <[email protected]>; Tommy Pauly <[email protected]>; >>> [email protected]; [email protected]; Anna Brunström >>> <[email protected]>; Brian Trammell (IETF) <[email protected]>; >>> Zaheduzzaman Sarker <[email protected]>; >>> [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]>> wrote: >>> >>> >>> [You don't often get email from [email protected] >>> <mailto:[email protected]>. 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 <[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]>> 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 <[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> ): >>>>>> 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 >>> 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 -- [email protected] To unsubscribe send an email to [email protected]
