On 3 Dec 2024, at 18:26, Anna Brunström anna.brunst...@kau.se
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 mirja.kuehlew...@ericsson.com
Sent: den 3 december 2024 17:45
To: Megan Ferguson mfergu...@amsl.com; Michael Welzl
mich...@ifi.uio.no; Gorry Fairhurst go...@erg.abdn.ac.uk
Cc: Philipp S. Tiesel phil...@tiesel.net; Colin Perkins
c...@csperkins.org; rfc-edi...@rfc-editor.org; Reese Enghardt
i...@tenghardt.net; Tommy Pauly tpa...@apple.com;
taps-...@ietf.org; taps-cha...@ietf.org; Anna Brunström
anna.brunst...@kau.se; Brian Trammell (IETF) i...@trammell.ch;
Zaheduzzaman Sarker zahed.sarker.i...@gmail.com;
auth48archive@rfc-editor.org
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" <mfergu...@amsl.com
mailto:mfergu...@amsl.com> wrote:
[You don't often get email from mfergu...@amsl.com
mailto:mfergu...@amsl.com . 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
<mich...@ifi.uio.no mailto: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
mailto: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.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
<mich...@ifi.uio.no mailto: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.htmlhttps://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 .
When you send an e-mail to Karlstad University, we will
process your personal datahttps://www.kau.se/en/gdpr .
