Dear Megan, dear all, I have carefully looked at all these updates; in my opinion, everything is just perfect now (including the question you ask below: yes your suggestion, which, as I see, you have incorporated, is great). Many, many thanks for all your hard work!
I approve of publication of this document now. Cheers, Michael > On Dec 2, 2024, at 7:26 PM, Megan Ferguson <mfergu...@amsl.com> wrote: > > 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.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 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 Nov 27, 2024, at 7:09 AM, Michael Welzl <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> 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.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) >>> >>> 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 >>> >>> Thank you. >>> >>> RFC Editor/mf >>> >>>> On Nov 23, 2024, at 4:38 AM, Michael Welzl <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.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 >>>> >>> >> > > > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
