Such a relief - many thanks to everyone!!! Best regards, Michael Welzl
> On 15 Jan 2025, at 20:20, Megan Ferguson <mfergu...@staff.rfc-editor.org> > wrote: > > 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
