On 27/12/2024 15:13, Anna Brunström wrote:
Hi again,
Below are a few details for -arch. With the changes below, I approve the
document.
BR,
Anna
OLD:
Instead, it provides the Protocol Stack with additional information to allow it
to make better use of modern Transport Services, while simplifying the
application's role in parsing data.
NEW:
Instead, it provides the Protocol Stack with additional information to allow it
to make better use of modern transport protocols, while simplifying the
application's role in parsing data.
--- This change to upper case did not come out right, as it does not refer to
the Transport Services offered in the API, but the realization in the stack.
Changed to transport protocols to avoid any confusion.
OLD:
The normative requirements described in this section allow Transport Services
APIs and the Transport Services Implementation to provide this functionality
without causing incompatibility or introducing security vulnerabilities.
NEW:
The normative requirements described in this section allow Transport Services
APIs and Transport Services Implementations to provide this functionality
without causing incompatibility or introducing security vulnerabilities.
--- If there are multiple Transport Services APIs there are multiple Transport
Services Implementations.
OLD:
A single stack can be simple (e.g., one application stream carried TCP running
over IP) or complex (e.g,. multiple application streams carried over a
multipath transport protocol using multiple subflows over IP).
NEW:
A single stack can be simple (e.g., one application stream carried over TCP
running over IP) or complex (e.g,. multiple application streams carried over a
multipath transport protocol using multiple subflows over IP).
--- There must a be a word missing in "carried TCP", so added "over".
I looked at these changes to ARCH and these look fine to me also.
Gorry
-----Original Message-----
From: Anna Brunström
Sent: den 27 december 2024 15:42
To: Megan Ferguson <mfergu...@amsl.com>; Philipp S. Tiesel <phil...@tiesel.net>
Cc: Michael Welzl <mich...@ifi.uio.no>; Mirja Kuehlewind <mirja.kuehlew...@ericsson.com>; Brian Trammell
<i...@trammell.ch>; Tommy Pauly <tpa...@apple.com>; Colin Perkins <c...@csperkins.org>; Gorry Fairhurst
<go...@erg.abdn.ac.uk>; Reese Enghardt <i...@tenghardt.net>; Zaheduzzaman Sarker
<zahed.sarker.i...@gmail.com>; rfc-edi...@rfc-editor.org; taps-...@ietf.org; taps-cha...@ietf.org;
auth48archive@rfc-editor.org
Subject: RE: Cluster-Wide Questions for Cluster 508: RFCs 9621, 9622, and 9623
(draft-ietf-taps-arch-19, draft-ietf-taps-interface-26, and
draft-ietf-taps-impl-18)
Hi all,
Thanks for all the efforts with the documents, and special thanks to Megan and
Michael for your huge efforts of course!
Too many deadlines before Christmas, but I have now managed to go through all
the updates, and in particular all the capitalization changes. While I agree
with all the principles discussed, I detected a few places where it did not
work out right, as well as some other nits. To make it simpler and keep things
in order, let me split up my feedback in multiple mails.
Let me start here with one cluster wide alignment that apply also to -api. We
use in the -arch document the term Candidate Protocol Stack, consistently with
capitalization in multiple places, but this has not been applied in -impl or
-api. Following the principles used, I think we should align the other two
documents. The following changes below are needed to align them.
In 9622:
OLD:
Once Initiate is called, the candidate Protocol Stack(s) can cause one or more
candidate transport-layer connections to be created to the specified Remote
Endpoint.
NEW:
Once Initiate is called, the Candidate Protocol Stack(s) can cause one or more
candidate transport-layer connections to be created to the specified Remote
Endpoint.
OLD:
The Ready event occurs after Initiate has established a transport-layer
connection on at least one usable candidate Protocol Stack over at least one
Candidate Path.
NEW:
The Ready event occurs after Initiate has established a transport-layer
connection on at least one usable Candidate Protocol Stack over at least one
Candidate Path.
In 9623:
OLD:
During the process of establishment (Section 4), the Connection will not
necessarily be immediately bound to a transport protocol instance, since
multiple candidate Protocol Stacks might be raced.
NEW:
During the process of establishment (Section 4), the Connection will not
necessarily be immediately bound to a transport protocol instance, since
multiple Candidate Protocol Stacks might be raced.
OLD:
Cached protocol state is primarily used during Connection establishment for a
single Protocol Stack, but it may be used to influence an implementation's
preference between several candidate Protocol Stacks.
NEW:
Cached protocol state is primarily used during Connection establishment for a
single Protocol Stack, but it may be used to influence an implementation's
preference between several Candidate Protocol Stacks.
This was the only comment that applies to -api, which was already approved by
the authors. I will come back with my other comments in separate emails.
Best,
Anna
-----Original Message-----
From: Megan Ferguson <mfergu...@amsl.com>
Sent: den 23 december 2024 17:07
To: Philipp S. Tiesel <phil...@tiesel.net>; Anna Brunström
<anna.brunst...@kau.se>
Cc: Michael Welzl <mich...@ifi.uio.no>; Mirja Kuehlewind <mirja.kuehlew...@ericsson.com>; Brian Trammell
<i...@trammell.ch>; Tommy Pauly <tpa...@apple.com>; Colin Perkins <c...@csperkins.org>; Gorry Fairhurst
<go...@erg.abdn.ac.uk>; Reese Enghardt <i...@tenghardt.net>; Zaheduzzaman Sarker
<zahed.sarker.i...@gmail.com>; rfc-edi...@rfc-editor.org; taps-...@ietf.org; taps-cha...@ietf.org;
auth48archive@rfc-editor.org
Subject: Re: Cluster-Wide Questions for Cluster 508: RFCs 9621, 9622, and 9623
(draft-ietf-taps-arch-19, draft-ietf-taps-interface-26, and
draft-ietf-taps-impl-18)
Hi Philipp and *Anna,
Philipp - thank you for your reply; we have updated your status to “Approved”
for RFC-to-be 9623.
*Anna - once we hear your approvals for RFCs-to-be 9621 and 9623, this document
set will be ready to move forward in the publication process. We look forward
to hearing from you at your earliest convenience as our 2024 publication window
is soon to close.
The AUTH48 status page for this document set is viewable at:
https://www.rfc-editor.org/auth48/C508
Thank you.
RFC Editor/mf
On Dec 22, 2024, at 6:42 AM, Philipp S. Tiesel <phil...@tiesel.net> wrote:
Hi,
first to all, but especially to Megan and Michael a very big thank you!
I am fine with the edits and the current versions and authorise publication of
RFC-to-be 9623.
AVE!
Philipp
On 21. Dec 2024, at 03:15, Megan Ferguson <mfergu...@amsl.com> wrote:
Michael,
Thanks for sending. We have updated and moved RFC-to-be 9622 to AUTH48-DONE to
await the other two documents.
Thank you.
RFC Editor/mf
On Dec 20, 2024, at 6:20 PM, Michael Welzl <mich...@ifi.uio.no> wrote:
I see that 9622 lacks my approval: I’m ok eith the latest changes and approve
publication!
Sent from my phone
Am 21.12.2024 um 02:55 schrieb Megan Ferguson <mfergu...@amsl.com>:
Greetings,
Just a final reminder for the year that this document set awaits author
actions. See the email thread below as well as the AUTH48 status page:
https://www.rfc-editor.org/auth48/C508
Note that time is running out to move forward with a 2024 publication date due
to holidays etc. Please contact us at your earliest convenience with approvals
and/or updates.
Thank you.
RFC Editor/mf
On Dec 20, 2024, at 11:04 AM, Megan Ferguson <mfergu...@amsl.com> wrote:
Michael and Mirja,
Thanks for replies and explanations. We have updated the files and rolled
these changes into the current versions of the diffs so as to keep access to
the previous capping updates and all of the capping changes together where
possible (to hopefully keep everyone in the loop).
Notes:
-Mirja’s first point that Michael suggests leaving as was: we have made no
changes as this sounds acceptable to Mirja and Michael’s preference.
-9622: we lowercased “Cellular data plan” in one instance.
-9623: we updated to use only “policy” instead of “System Policy”.
-9621: we have lowercased a single instance of “Message” and removed
“Properties” as seemed agreeable to both Mirja and Michael.
Please review and confirm that these updates appear as desired.
The AUTH48 status page for the entire cluster is viewable here:
https://www.rfc-editor.org/auth48/C508
Each document’s updated files and diffs are available as listed below:
The files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9621.txt
https://www.rfc-editor.org/authors/rfc9621.pdf
https://www.rfc-editor.org/authors/rfc9621.html
https://www.rfc-editor.org/authors/rfc9621.xml
The relevant diff files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9621-diff.html
(comprehensive diff)
https://www.rfc-editor.org/authors/rfc9621-auth48diff.html (AUTH48
changes only)
https://www.rfc-editor.org/authors/rfc9621-lastdiff.html (last to
current version only)
https://www.rfc-editor.org/authors/rfc9621-lastrfcdiff.html (ditto
but rfcdiff)
The following diff contains the capping changes from the last two rounds
together:
https://www.rfc-editor.org/authors/rfc9621caps-diff.html
——
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 (ditto
but rfcdiff)
——
The files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9623.txt
https://www.rfc-editor.org/authors/rfc9623.pdf
https://www.rfc-editor.org/authors/rfc9623.html
https://www.rfc-editor.org/authors/rfc9623.xml
The relevant diff files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9623-diff.html
(comprehensive diff)
https://www.rfc-editor.org/authors/rfc9623-auth48diff.html (AUTH48
changes only)
https://www.rfc-editor.org/authors/rfc9623-lastdiff.html (last to
current version only)
https://www.rfc-editor.org/authors/rfc9623-lastrfcdiff.html (ditto
but rfcdiff)
The following diff contains the capping changes from the last two rounds
together:
https://www.rfc-editor.org/authors/rfc9623caps-diff.html
Please review carefully and let us know if any further changes are necessary.
Thank you.
RFC Editor/mf
On Dec 20, 2024, at 10:08 AM, Michael Welzl <mich...@ifi.uio.no> wrote:
Hi Mirja,
Many thanks for taking a careful look! I’m sorry, I can’t do any more updates
for a while now - perhaps someone else could have a go at these?
Answers below:
On Dec 20, 2024, at 8:43 PM, Mirja Kuehlewind <mirja.kuehlew...@ericsson.com>
wrote:
Hi Michael,
thanks for the huge amount of work!
Sorry that I have to say this but I'm not fully convinced regarding the capitalization of
Connection, Property and Messages. I think I would have preference to keep them lower
case in most of the cases, and use upper case really only if a very specific
"implementation instance" is meant. However, I can fully live with the current
approach now as long as it is unified.
First and foremost, I wanted to minimize changes, or at least stay true to the
original intention. I think what I did follows that - we have long used
capitalization of these terms to distinguish between the “upper layer” and the
“lower layer”. For Connection, the -arch draft (9621) even explicitly says
this, in two places (search for “capital”).
So I think we should keep these as they are.
Still, I have a few comments though where I find something not completely right
in my review:
First, I agree with Reese on the use of " Cellular data plan" in RFC9622. This
is just an example and normal word in a sentence and does not relate to any property in
this occurrence and therefore should be lower case.
As I explained, I did this to follow what already was the common style in the
documents; but this is totally fine with me, and I can’t imagine anyone
strongly disagreeing. Let’s lower-case it.
For RFC9623, I did struggle with this occurrence of "System policy" (this
sentence is twice in the doc):
"Similar to a derived endpoint, the paths should be ranked based on preference,
System Policy, and performance."
Because it's listed here between preference and performance I think it should be lower
case. Or you could even remove the word "System" and only use policy as an
undefined term to avoid confusion.
Ok for me to change.
And for RFC9621, I have these two cases:
"The Socket API provides a Message interface for datagram protocols"
It's _a_ undefined message interface. Here message interface is just used as a
specific kind of interface and not _the_ message interface we use in TAPS.
Good catch, I agree.
"This automated selection is constrained by the Properties and preferences expressed
by the application and requires applications to explicitly set Properties that define any
necessary constraints on protocol, path, and interface selection."
I would either lower-case "Properties" when noted together with "preferences"
or remove it, because preferences are expressed by Properties.
I don’t really see the problem here; I’m against lower-casing “Properties”, but
removing it would be okay.
Cheers,
Michael
Thanks again. Just my 2c...
Mirja
On 20.12.24, 04:52, "Michael Welzl" <mich...@ifi.uio.no
<mailto:mich...@ifi.uio.no>> wrote:
Hi !
Here come the new versions!
Once these changes are incorporated, I approve publication wherever it’s
missing (as a co-author: RFCs 9622 and 9623).
Cheers,
Michael
On Dec 20, 2024, at 12:00 AM, Megan Ferguson <mfergu...@amsl.com
<mailto:mfergu...@amsl.com>> wrote:
Hi Michael,
I will apply all of these changes to the XML files (the latest version you
sent) and send them back to you.
Excellent. We will await the files updated with all of the changes before
taking any action on our end.
As to the get-together: thanks for the invite! You will have to reach out to
whoever ends up at the RFC Editor desk at IETF if you would like help
celebrating this accomplishment :). We were happy to do our part and very much
appreciate your time and attention in getting this cluster ready for
publication (no easy feat on Michael’s part)!
RFC Editor/mf
AVE!
Philipp S. Tiesel / phils…
--
{phils}--->---(ph...@in-panik.de)--->---(http://phils.in-panik.de)----,
wenn w eine aube ist dn man au dran dre en |
o Schr an muss hc h (Kurt Schwitters) |
:wq! <----(phone: +49-179-6737439)---<---(jabber: ph...@in-panik.de)----'
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 -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
