Hi Megan, all, Happy New Year!
Thanks for adding all the detailed edits Megan! I checked the updated files, only a few comments, see below. With the two corrections below, I approve the documents. Thanks again for all the great editing work and for your patience with all the updates! Best Regards, Anna For RFC 9623 there were two updates that did not get entered quite correct. OLD: The function that implements custom framing logic will be referred to as the "Framer Implementation", which may be provided by a Transport Services Implementation or the application itself. NEW: The function that implements custom framing logic will be referred to as the "Framer implementation", which may be provided by a Transport Services Implementation or the application itself. --- "Framer implementation" should have lower case for "implementation". OLD: Clone: Calling Clone on a UDP connection creates a new connection with equivalent parameters. The two Connection objects are otherwise independent. NEW: Clone: Calling Clone on a UDP connection creates a new UDP connection with equivalent parameters. The two associated Connection objects are otherwise independent. --- "UDP" and "associated" did not get added. Also one unimportant nit in the update for RFC 9621 that I am not sure if it was missed or intentional: "The normative requirements described in this section allow Transport Services APIs and the Transport Services Implementations to provide this functionality without causing incompatibility or introducing security vulnerabilities." I had removed "the" in front of "Transport Services Implementations" when changing it to plural, but update only if you think it is needed and worthwhile. -----Original Message----- From: Megan Ferguson <mfergu...@staff.rfc-editor.org> Sent: den 8 januari 2025 23:39 To: Michael Welzl <mich...@ifi.uio.no>; Anna Brunström <anna.brunst...@kau.se>; Gorry Fairhurst <go...@erg.abdn.ac.uk>; Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com> Cc: Philipp S. Tiesel <phil...@tiesel.net>; Mirja Kuehlewind <mirja.kuehlew...@ericsson.com>; Brian Trammell <i...@trammell.ch>; Tommy Pauly <tpa...@apple.com>; Colin Perkins <c...@csperkins.org>; Reese Enghardt <i...@tenghardt.net>; rfc-edi...@rfc-editor.org; taps-...@ietf.org; taps-cha...@ietf.org; auth48archive@rfc-editor.org Subject: Re: Cluster-Wide Questions for Cluster 508: ...: Comments for 9623 Authors, [Note that this message has been sent from a new email address on our end.] Happy new year! We have updated as requested by Anna (and confirmed by Gorry and Michael, respectively). *Anna - As these updates were especially detailed, we ask that you review and confirm our implementation of the changes and/or let us know if further changes are necessary. We believe we have all other necessary approvals, and we will move forward in the publication process upon Anna’s approval (unless we hear otherwise at this time). The AUTH48 status page for this cluster of documents is available here: https://www.rfc-editor.org/auth48/C508 RFC-to-be 9621: --------------- 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/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 AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9621 RFC-to-be 9622: --------------- 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 (ditto but rfcdiff) The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9622 RFC-to-be 9623: --------------- 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/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 AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9623 Thank you. RFC Editor/mf > On Dec 30, 2024, at 4:39 AM, Michael Welzl <mich...@ifi.uio.no> wrote: > > Dear all, > > I agree with all of Anna’s edits below. > > Anna, see below: > >> On Dec 29, 2024, at 7:14 PM, Anna Brunström <anna.brunst...@kau.se> wrote: >> >> Hi Michael, >> >> Thanks for the further clarifications below. I then think we should update >> Section 10.5 to be consistent with the rest of the document and the defined >> principles. The text for UDP and UDP Multicast receive is very similar and I >> found it confusing that we use “UDP connection” but “UDP Multicast Receive >> Connection”. I think we should be consistent throughout the document and not >> just within each subsection. My suggested edits for Section 10.5 as well as >> two small nits for the SCTP part are indicated below. > > Many thanks, these are all good, and much appreciated. > > >> This is the last of my comments for 9623. And to be clear, I think you did >> an excellent job with all the capitalization work! > > Many thanks, this means a lot to me, it really does. > > >> My suggested edits are just final polishing after reading with fresh >> eyes. So still owe you lots of beer J > > Haha :-) > > Cheers, > Michael > > >> >> Best Regards, >> Anna >> >> OLD: >> Initiate: Calling Initiate on a UDP Multicast Receive Connection causes an >> immediate EstablishmentError. This is an unsupported operation. >> NEW: >> Initiate: Calling Initiate on a UDP Multicast Receive connection causes an >> immediate EstablishmentError. This is an unsupported operation. >> >> OLD: >> InitiateWithSend: Calling InitiateWithSend on a UDP Multicast Receive >> Connection causes an immediate EstablishmentError. This is an unsupported >> operation. >> NEW: >> InitiateWithSend: Calling InitiateWithSend on a UDP Multicast Receive >> connection causes an immediate EstablishmentError. This is an unsupported >> operation. >> >> OLD: >> Ready: A UDP Multicast Receive Connection is ready once the system has >> received traffic for the appropriate group and port. >> NEW: >> Ready: A UDP Multicast Receive connection is ready once the system has >> received traffic for the appropriate group and port. >> >> OLD: >> EstablishmentError: UDP Multicast Receive Connections generate an >> EstablishmentError indicating that joining a multicast group failed if >> Initiate is called. >> NEW: >> EstablishmentError: UDP Multicast Receive connections cause an >> EstablishmentError indicating that joining a multicast group failed if >> Initiate is called. >> >> OLD: >> ConnectionError: The only ConnectionError generated by a UDP Multicast >> Receive Connection is in response to an Abort action. >> NEW: >> ConnectionError: The only ConnectionError caused by a UDP Multicast Receive >> connection is in response to an Abort action. >> >> OLD: >> Clone: Calling Clone on a UDP Multicast Receive Connection creates a new >> Connection with equivalent parameters. The two Connections are otherwise >> independent. >> NEW: >> Clone: Calling Clone on a UDP Multicast Receive connection creates a new >> UDP Multicast Receive connection with equivalent parameters. The two >> associated Connection objects are otherwise independent. >> >> OLD: >> Send: SEND.UDP. Calling Send on a UDP Multicast Receive Connection causes >> an immediate SendError. This is an unsupported operation. >> NEW: >> Send: SEND.UDP. Calling Send on a UDP Multicast Receive connection causes >> an immediate SendError. This is an unsupported operation. >> >> OLD: >> Receive: RECEIVE.UDP. The Receive action in a UDP Multicast Receive >> Connection only delivers complete Messages to Received, each of which >> represents a single datagram received in a UDP packet. >> NEW: >> Receive: RECEIVE.UDP. UDP Multicast Receive only delivers complete >> Messages to Received, each of which represents a single datagram received in >> a UDP packet. >> >> OLD: >> Close: Calling Close on a UDP Multicast Receive Connection (ABORT.UDP) >> releases the local port reservation and leaves the group. The Connection >> then issues a Closed event. >> NEW: >> Close: Calling Close on a UDP Multicast Receive connection (ABORT.UDP) >> releases the local port reservation and leaves the group. A Closed event is >> then issued. >> >> OLD: >> Abort: Calling Abort on a UDP Multicast Receive Connection (ABORT.UDP) is >> identical to calling Close except that the Connection will send a >> ConnectionError event rather than a Closed event. >> NEW: >> Abort: Calling Abort on a UDP Multicast Receive connection (ABORT.UDP) is >> identical to calling Close except that a ConnectionError event rather than a >> Closed event is issued. >> >> OLD: >> CloseGroup: Calling CloseGroup on a UDP Multicast Receive Connection >> (ABORT.UDP) is identical to calling Close on this Connection and on all >> Connections in the same ConnectionGroup. >> NEW: >> CloseGroup: Calling CloseGroup on a UDP Multicast Receive connection >> (ABORT.UDP) is identical to calling Close on its Connection object and on >> all Connections in the same ConnectionGroup. >> >> OLD: >> AbortGroup: Calling AbortGroup on a UDP Multicast Receive Connection >> (ABORT.UDP) is identical to calling Close on this Connection and on all >> Connections in the same ConnectionGroup. >> NEW: >> AbortGroup: Calling AbortGroup on a UDP Multicast Receive connection >> (ABORT.UDP) is identical to calling Close on its Connection object and on >> all Connections in the same ConnectionGroup. >> >> OLD: >> Else, the Connection object is one out of several Connection objects that >> are assigned to the same SCTP association, and RESET_STREAM.SCTP must be >> called, which informs the peer that the stream will no longer be used for >> mapping and can be used by future Initiate, InitiateWithSend, or Listen >> action. >> NEW: >> Else, the Connection object is one out of several Connection objects that >> are assigned to the same SCTP association, and RESET_STREAM.SCTP must be >> called, which informs the peer that the stream will no longer be used for >> mapping and can be used by a future Initiate, InitiateWithSend, or Listen >> action. >> --- I am not a native speaker, but I think there is an “a” missing in front >> of “future”. The text was changed to use “action” in singular instead of >> “calls” so I am guessing it was missed in the update. >> >> OLD: >> The resulting local RESET_STREAM-EVENT.SCTP informs the Transport Services >> System that the stream id can now be reused by the next Initiate, >> InitiateWithSend, or Listen actions, and invokes a Closed event toward the >> application. >> NEW: >> The resulting local RESET_STREAM-EVENT.SCTP informs the Transport Services >> System that the stream id can now be reused by the next Initiate, >> InitiateWithSend, or Listen action, and invokes a Closed event toward the >> application. >> --- I think this sentence should have “action” in singular. >> >> >> From: Michael Welzl <mich...@ifi.uio.no> >> Sent: den 28 december 2024 14:04 >> To: Anna Brunström <anna.brunst...@kau.se> >> Cc: Megan Ferguson <mfergu...@amsl.com>; Philipp S. Tiesel >> <phil...@tiesel.net>; 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: ...: Comments >> for 9623 >> >> Dear Anna, dear all, >> >> In short: I agree with all changes suggested by Anna in this email. >> >> More below: >> >> >> >> On Dec 27, 2024, at 7:37 PM, Anna Brunström <anna.brunst...@kau.se> wrote: >> >> Hi, >> >> Now finally, the comments for Section 10 in -impl. Here I think some of the >> fixes created some problems. I take the first instance I encountered as an >> example: >> >> "Calling Clone on a TCP connection creates a new Connection with equivalent >> parameters. These Connections, and Connections generated via later calls to >> Clone on an Established Connection, form a Connection Group." >> >> The change to "TCP connection" is of course correct, but the problem comes >> when that connection is then referred to as "These Connections" and now all >> of a sudden is a "Connection" rather than a "connection". It is also unclear >> if the "new Connection" should be a "Connection" or "connection", both could >> be possible. The root cause is that the text is a bit compressed and you do >> not call Clone on a TCP connection, but on a Connection object mapped to a >> TCP connection, so it gets a bit messy when now trying to distinguish and >> keeping track of what refers to what. In the SCTP section the mapping is >> explicitly mentioned, but in most other parts we use a more compressed text. >> >> Yes, I agree: there is some ambiguity in the text due to this compressed >> writing style. >> >> >> I have tried to fix the text for TCP and UDP to get consistent references >> without major edits in my suggested modifications below. Sorry about the >> somewhat long list of suggested updates this late in the process. I tried to >> keep track that the updates looked good overall and agreed with all the >> principles used, but I had not looked closely enough on the details in >> Section 10 until doing my final check today. >> >> I am also unsure why "UDP Multicast Receive Connection" is used and not "UDP >> Multicast Receive connection" in Section 10.5? Is there something special >> about UDP Multicast Receive that suggests it should not follow the general >> principles and "UDP Multicast Receive connection" is not the correct term? >> Perhaps it was just missed in the updates of the capitalization, but there >> is one instance where it is modified in the opposite direction, from >> "connection" to "Connection" suggesting it is a deliberate choice. >> >> There isn’t anything special about it; as you will have seen in my answers >> to Reese, my decisions were guided by the “layer above / layer below” logic >> but also: >> - how often do certain terms already appear in a certain form in all >> documents? (the goal being to minimize changes) >> - how is it written in the -arch document? (which should probably >> take precedence over the others) >> >> I thought it’s okay to go with such choices rather than “correctness” in >> some cases due to the aforementioned ambiguity. Trying to be 100% correct is >> really tricky here - on the one hand, I see the argument to use >> “connections” everywhere, but on the other, there are statements in section >> 10.5 such as: "UDP Multicast Receive Connections generate an >> EstablishmentError indicating that joining a multicast group failed if >> Initiate is called.” - which, surely, UDP per se doesn’t do in this exact >> form. So, that would be for the “Connection” instead. >> >> So It may be that I changed this on the basis of what’s more common instead, >> when this may have been a mistake. Looking at the previous version: >> https://ietf-tapswg.github.io/api-drafts/draft-ietf-taps-impl.html >> it seems to me that I just tried to make this uniform, and “Connection” was >> a more common use in the text. >> >> I hope this helps - and I’m sorry for any errors that I have introduced! >> >> Cheers, >> Michael >> >> >> >> >> Would be good if Michael can clarify the intentions with Section 10.5 before >> I suggest edits for that section. Also check my suggested updates below and >> see if you agree as you made the original edits. >> >> BR, >> Anna >> >> OLD: >> Clone: Calling Clone on a TCP connection creates a new Connection with >> equivalent parameters. These Connections, and Connections generated via >> later calls to Clone on an Established Connection, form a Connection Group. >> NEW: >> Clone: Calling Clone on a TCP connection creates a new TCP connection with >> equivalent parameters. The two associated Connection objects, and >> Connections generated via later calls to Clone on an Established Connection, >> form a Connection Group. >> >> OLD: >> Close: Calling Close on a TCP connection indicates that the Connection >> should be gracefully closed (CLOSE.TCP) by sending a FIN to the peer. It >> will then still be possible to receive data until the peer closes or aborts >> the TCP connection. The Closed event will be issued upon reception of a FIN. >> NEW: >> Close: Calling Close on a TCP connection indicates that the TCP connection >> should be gracefully closed (CLOSE.TCP) by sending a FIN to the peer. It >> will then still be possible to receive data until the peer closes or aborts >> the TCP connection. The Closed event will be issued upon reception of a FIN. >> --- As written, I think "the Connection" must refer back to "a TCP >> connection" and therefore also should be lower case. I added "TCP" just to >> avoid any confusion. The similar argument applies to several of the >> suggested modifications below. >> >> OLD: >> Abort: Calling Abort on a TCP connection indicates that the Connection >> should be immediately closed by sending a RST to the peer (ABORT.TCP). >> NEW: >> Abort: Calling Abort on a TCP connection indicates that the TCP connection >> should be immediately closed by sending a RST to the peer (ABORT.TCP). >> >> OLD: >> CloseGroup: Calling CloseGroup on a TCP connection (CLOSE.TCP) is identical >> to calling Close on this Connection and on all Connections in the same >> ConnectionGroup. >> NEW: >> CloseGroup: Calling CloseGroup on a TCP connection (CLOSE.TCP) is identical >> to calling Close on its Connection object and on all Connections in the >> same ConnectionGroup. >> >> OLD: >> AbortGroup: Calling AbortGroup on a TCP connection (ABORT.TCP) is identical >> to calling Abort on this Connection and on all Connections in the same >> ConnectionGroup. >> NEW: >> AbortGroup: Calling AbortGroup on a TCP connection (ABORT.TCP) is identical >> to calling Abort on its Connection object and on all Connections in the same >> ConnectionGroup. >> >> OLD: >> InitiateWithSend: Early data on a UDP connection does not have any special >> meaning. The data is sent whenever the Connection is Ready. >> NEW: >> InitiateWithSend: Early data on a UDP connection does not have any special >> meaning. The data is sent whenever the UDP connection is Ready. >> >> OLD: >> ConnectionReceived: UDP Listeners will deliver new connections once they >> have received traffic from a new Remote Endpoint. >> NEW: >> ConnectionReceived: UDP Listeners will deliver new Connections once they >> have received traffic from a new Remote Endpoint. >> --- Here I think we are talking about delivering new Connection objects so >> should be upper case. >> >> OLD: >> Clone: Calling Clone on a UDP connection creates a new Connection with >> equivalent parameters. The two Connections are otherwise independent. >> NEW: >> Clone: Calling Clone on a UDP connection creates a new UDP connection with >> equivalent parameters. The two associated Connection objects are otherwise >> independent. >> >> OLD: >> Close: Calling Close on a UDP connection (ABORT.UDP) releases the local >> port reservation. The Connection then issues a Closed event. >> NEW: >> Close: Calling Close on a UDP connection (ABORT.UDP) releases the local >> port reservation. A Closed event is then issued. >> >> OLD: >> Abort: Calling Abort on a UDP connection (ABORT.UDP) is identical to >> calling Close except that the Connection will send a ConnectionError event >> rather than a Closed event. >> NEW: >> Abort: Calling Abort on a UDP connection (ABORT.UDP) is identical to >> calling Close except that a ConnectionError event rather than a Closed event >> is issued. >> >> OLD: >> CloseGroup: Calling CloseGroup on a UDP connection (ABORT.UDP) is identical >> to calling Close on this Connection and on all Connections in the same >> ConnectionGroup. >> NEW: >> CloseGroup: Calling CloseGroup on a UDP connection (ABORT.UDP) is identical >> to calling Close on its Connection object and on all Connections in the same >> ConnectionGroup. >> >> OLD: >> AbortGroup: Calling AbortGroup on a UDP connection (ABORT.UDP) is identical >> to calling Close on this Connection and on all Connections in the same >> ConnectionGroup. >> NEW: >> AbortGroup: Calling AbortGroup on a UDP connection (ABORT.UDP) is identical >> to calling Close on its Connection object and on all Connections in the same >> ConnectionGroup. >> >> >> >> >> -----Original Message----- >> From: Anna Brunström >> Sent: den 27 december 2024 17:14 >> 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: ...: Comments >> for 9623 >> >> Hi, >> >> Now moving to -impl. I am splitting my comments in two parts, first all >> comments excluding comments on Section 10 with the protocol mappings. I will >> take Section 10 separately as there is where I think the capitalization >> created some problems, as the original text was less precise, and my >> co-authors may want to check those updates. >> >> OLD: >> Candidate Racing involves attempting multiple options for Connection >> establishment and choosing the first option to succeed as the Protocol Stack >> to use for the connection. >> NEW: >> Candidate Racing involves attempting multiple options for Connection >> establishment and choosing the first option to succeed as the Protocol Stack >> to use for the Connection. >> --- Connection here refers to the Connection object returned to the user and >> should be capitalized. >> >> OLD: >> 2. Protocol Options >> NEW: >> 2. Protocol options >> --- Protocol options is not a term defined anywhere and is mostly used in >> lower case in the document. We have Protocol Option Racing in -arch, but not >> as a capitalized term used in the text, just defined as an action and >> capitalized as all terms including Application and Protocol Instance. And it >> is not the same term anyway. >> >> OLD: >> Protocol Options are next checked in order. >> NEW: >> Protocol options are next checked in order. >> --- See comment above. >> >> OLD: >> The primary goal of the Candidate Racing process is to successfully >> negotiate a Protocol Stack to an Endpoint over an interface to connect a >> single leaf node of the tree with as little delay and as few unnecessary >> connections attempts as possible. >> NEW: >> The primary goal of the Candidate Racing process is to successfully >> negotiate a Protocol Stack to an Endpoint over an interface to connect a >> single leaf node of the tree with as little delay and as few unnecessary >> connection attempts as possible. >> --- Typo in "connections attempts" >> >> OLD: >> The function that implements custom framing logic will be referred to as the >> "framer "Framer implementation", which may be provided by a Transport >> Services implementation or the application itself. >> NEW: >> The function that implements custom framing logic will be referred to as the >> "framer "Framer implementation", which may be provided by a Transport >> Services Implementation or the application itself. >> --- Implementation should be capitalized. >> >> OLD: >> TCP can cache cookies for use in TFO >> NEW: >> TCP can cache cookies for use in TFO. >> --- The period got lost in the update (I assume it was a mistake as the >> bullet above has one). >> >> BR, >> Anna >> >> >> -----Original Message----- >> From: Anna Brunström >> Sent: den 27 december 2024 16:13 >> 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: ...: Comments >> for 9621 >> >> 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". >> >> >> -----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>. >> >> När du skickar e-post till Karlstads universitet behandlar vi dina >> personuppgifter. >> When you send an e-mail to Karlstad University, we will process your >> personal data. >> > 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
