On 02/12/2024 18:26, Megan Ferguson 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
I have checked the diff and I have no further comments, thanks for your
work. As an author, I approve this.
Gorry
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
