Hi, Just in case: as an editor, I confirm that I agree with Mirja’s suggestion below (and Gorry Fairhurst also agreed in a private email).
Cheers, Michael > On 4 Dec 2024, at 08:27, Mirja Kuehlewind <[email protected]> > wrote: > > Hi Megan, > > please see my answer below for your question, marked with [MK]. > > Mirja > > On 03.12.24, 18:59, "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> ] > > > Mirja and Anna, > > > Thank you for your replies. We have updated the errant parenthesis Mirja > pointed out (and added this change to our previous version of diffs (see > below)). > > > We will await any further comments on title changes that may be forthcoming. > > > A further question: We see several uses of “DSCP Assured Forwarding” followed > by a list. May we insert spaces and “and” between the items in those lists > (e.g., AF41, AF42, AF43, and AF44)? Or should they stay as they are? > > [MK] You can add the spaces, however, please don't add the "e.g." as this is > an exhaustive (and different) list in each case. I guess you can also add an > "and" but not sure that is really needed. > > > > > 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 > > > Thank you. > > > RFC Editor/mf > > > > >> On Dec 3, 2024, at 10:26 AM, 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> >> <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.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 >> personuppgifter<https://www.kau.se/gdpr> <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> <https://www.kau.se/en/gdpr;>. > > > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
