Anna, Thank you for your reply and careful review. We have updated as requested and marked your status as “Approved” at the AUTH48 status page (see https://www.rfc-editor.org/auth48/C508).
As we believe we have received all necessary approvals for this document cluster, we have changed the state of each document to "AUTH48-DONE" and will move them forward in the publication process at this time. Thank you all for your time and attention during AUTH48 and congratulations on its completion! RFC Editor/mf 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 > On Jan 14, 2025, at 2:10 PM, Anna Brunström <anna.brunst...@kau.se> wrote: > > 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
