I’m fine with these changes and approve this. Thanks!
Cheers, Michael > On Dec 5, 2024, at 6:38 PM, Megan Ferguson <mfergu...@amsl.com> wrote: > > All, > > This update to the title has been incorporated into our current version of > the files as requested. We will update the references in 9621 and 9623 that > point to this document as well. > > 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 (last to current > rfcdiff) > > Please contact us with any further updates/questions/comments you may have. > > We will await approvals from each of the parties listed on the AUTH48 status > page, resolution to the document-specific questions listed there, and > responses to our cluster-wide queries prior to moving forward to publication. > > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9622 > > Thank you. > > RFC Editor/mf > >> On Dec 5, 2024, at 4:41 AM, Mirja Kuehlewind <mirja.kuehlew...@ericsson.com> >> wrote: >> >> Yes, thanks, that title looks good to me as well. >> >> >> >> From: Michael Welzl <mich...@ifi.uio.no> >> Date: Thursday, 5. December 2024 at 12:25 >> To: Colin Perkins <c...@csperkins.org> >> Cc: Reese Enghardt <i...@tenghardt.net>, Megan Ferguson >> <mfergu...@amsl.com>, Anna Brunström <anna.brunst...@kau.se>, "Brian >> Trammell (IETF)" <i...@trammell.ch>, Mirja Kuehlewind >> <mirja.kuehlew...@ericsson.com>, Gorry Fairhurst <go...@erg.abdn.ac.uk>, >> "Philipp S. Tiesel" <phil...@tiesel.net>, "rfc-edi...@rfc-editor.org" >> <rfc-edi...@rfc-editor.org>, Tommy Pauly <tpa...@apple.com>, >> "taps-...@ietf.org" <taps-...@ietf.org>, "taps-cha...@ietf.org" >> <taps-cha...@ietf.org>, Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com>, >> "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org> >> Subject: Re: AUTH48: RFC-to-be 9622 <draft-ietf-taps-interface-26> for your >> review >> >> Dear all, >> >> I’m also happy with the last version here - and I also agree with Colin’s >> suggestion. I’m not sure it’s bike-shedding, it really seems better to me. >> >> Cheers, >> Michael >> >> >> >> >>> On 5 Dec 2024, at 12:21, Colin Perkins <c...@csperkins.org> wrote: >>> >>> Hi, >>> I’m also happy with the latest version. >>> (Well, I’d suggest “An Abstract Application Programming Interface (API) for >>> Transport Services” as the title, but I don’t care that much and we’re >>> likely getting into the realm of bike-shedding now…) >>> Cheers, >>> Colin >>> On 5 Dec 2024, at 1:09, Reese Enghardt wrote: >>>> Hi all, >>>> Thank you so much for all the changes and discussion to align on them! >>>> As a co-author, I have reviewed the diffs and the recent HTML version, and >>>> I approve of the changes. >>>> Best, >>>> Reese >>>> On 12/4/24 10:03, Megan Ferguson wrote: >>>>> All, >>>>> Thank you for your replies. We have updated the title and the lists as >>>>> discussed below. >>>>> 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 (last to >>>>> current rfcdiff) >>>>> Please contact us with any further updates/questions/comments you may >>>>> have. >>>>> We will await approvals from each of the parties listed on the AUTH48 >>>>> status page, resolution to the document-specific questions listed there, >>>>> and responses to our cluster-wide queries prior to moving forward to >>>>> publication. >>>>> The AUTH48 status page for this document is available here: >>>>> https://www.rfc-editor.org/auth48/rfc9622 >>>>> Thank you. >>>>> RFC Editor/mf >>>>> Thank you. >>>>>> On Dec 4, 2024, at 3:29 AM, Anna Brunström anna.brunst...@kau.se wrote: >>>>>> Hi all, >>>>>> The suggestion below looks good to me. >>>>>> I also agree to keep the titles of the other documents as is. >>>>>> BR, >>>>>> Anna >>>>>> -----Original Message----- >>>>>> From: Michael Welzl mich...@ifi.uio.no >>>>>> Sent: den 4 december 2024 11:10 >>>>>> To: Brian Trammell (IETF) i...@trammell.ch >>>>>> Cc: Anna Brunström anna.brunst...@kau.se; Mirja Kuehlewind >>>>>> mirja.kuehlew...@ericsson.com; Megan Ferguson mfergu...@amsl.com; Gorry >>>>>> Fairhurst go...@erg.abdn.ac.uk; Philipp S. Tiesel phil...@tiesel.net; >>>>>> Colin Perkins c...@csperkins.org; rfc-edi...@rfc-editor.org; Reese >>>>>> Enghardt i...@tenghardt.net; Tommy Pauly tpa...@apple.com; >>>>>> taps-...@ietf.org; taps-cha...@ietf.org; Zaheduzzaman Sarker >>>>>> zahed.sarker.i...@gmail.com; auth48archive@rfc-editor.org >>>>>> Subject: Re: AUTH48: RFC-to-be 9622 <draft-ietf-taps-interface-26> for >>>>>> your review >>>>>> Hi, >>>>>> About the title: >>>>>> IIRC after all these emails, the main concern from the RFC Editor was >>>>>> about the use of “Application Layer Interface” instead of “Application >>>>>> Programming Interface”. >>>>>> I was okay with changing this, but it seems that I created a mess by >>>>>> suggesting “The Transport Services Application Programming Interface” >>>>>> instead of only replacing the word “Layer” with “Programming”. No deeper >>>>>> reason here, it just spontaneously looked better to me but I’m totally >>>>>> okay with the other variant, my bad, and my apologies. >>>>>> So, I suggest we go with: "An Abstract Application Programming Interface >>>>>> to Transport Services”. Is that okay for folks here? >>>>>> BTW, the other two documents have the following titles - and I think >>>>>> they should stay as they are: >>>>>> Architecture and Requirements for Transport Services >>>>>> and: >>>>>> Implementing Interfaces to Transport Services >>>>>> Cheers, >>>>>> Michael >>>>>>> On 4 Dec 2024, at 08:23, Brian Trammell (IETF) i...@trammell.ch wrote: >>>>>>> Hi all, >>>>>>> I am also not thrilled about the title change, and would suggest >>>>>>> reverting it. >>>>>>> If the more academic style here (indefinite article) strongly violates >>>>>>> RFC Editor house style, it remains important to call out in the title >>>>>>> that this API is abstract; not doing so risks confusing readers that >>>>>>> the point of this specification is to establish a “shape” IMO. >>>>>>> Otherwise have reviewed the diffs and the document LGTM. >>>>>>> Cheers, >>>>>>> Brian >>>>>>>> On 3 Dec 2024, at 18:26, Anna Brunström anna.brunst...@kau.se wrote: >>>>>>>> Hi all, >>>>>>>> As Mirja brought it up, I also find the new title a bit strange. >>>>>>>> But this is just a comment from your shepherd, in case you want to >>>>>>>> think about the title again. >>>>>>>> BR, >>>>>>>> Anna >>>>>>>> -----Original Message----- >>>>>>>> From: Mirja Kuehlewind mirja.kuehlew...@ericsson.com >>>>>>>> Sent: den 3 december 2024 17:45 >>>>>>>> To: Megan Ferguson mfergu...@amsl.com; Michael Welzl >>>>>>>> mich...@ifi.uio.no; Gorry Fairhurst go...@erg.abdn.ac.uk >>>>>>>> Cc: Philipp S. Tiesel phil...@tiesel.net; Colin Perkins >>>>>>>> c...@csperkins.org; rfc-edi...@rfc-editor.org; Reese Enghardt >>>>>>>> i...@tenghardt.net; Tommy Pauly tpa...@apple.com; >>>>>>>> taps-...@ietf.org; taps-cha...@ietf.org; Anna Brunström >>>>>>>> anna.brunst...@kau.se; Brian Trammell (IETF) i...@trammell.ch; >>>>>>>> Zaheduzzaman Sarker zahed.sarker.i...@gmail.com; >>>>>>>> auth48archive@rfc-editor.org >>>>>>>> Subject: Re: AUTH48: RFC-to-be 9622 <draft-ietf-taps-interface-26> >>>>>>>> for your review >>>>>>>> Hi all, >>>>>>>> thanks for the work.! >>>>>>>> I have to say I'm not fully sure about the title change but okay for >>>>>>>> me if everybody else is okay. >>>>>>>> I reviewed all changes and approve them. >>>>>>>> Please note that there is now a superfluous bracket in Appendix C: >>>>>>>> OLD >>>>>>>> See Section 4 >>>>>>>> of [RFC8303]) for 1) further details on >>>>>>>> NEW >>>>>>>> See Section 4 >>>>>>>> of [RFC8303] for 1) further details on >>>>>>>> Mirja >>>>>>>> On 02.12.24, 19:29, "Megan Ferguson" <mfergu...@amsl.com >>>>>>>> mailto:mfergu...@amsl.com> wrote: >>>>>>>> [You don't often get email from mfergu...@amsl.com >>>>>>>> mailto:mfergu...@amsl.com . Learn why this is important at >>>>>>>> https://aka.ms/LearnAboutSenderIdentification >>>>>>>> https://aka.ms/LearnAboutSenderIdentification ] >>>>>>>> Hi Michael and Gorry, >>>>>>>> We have compiled our changes in response to both Michael’s email below >>>>>>>> and Gorry’s message about the <> tagging (see the 9621 email thread) >>>>>>>> in our postings below. >>>>>>>> Just a few notes: >>>>>>>> 1. Please review our updates to remove <> as suggested in Gorry’s >>>>>>>> mail. We think we’ve understood Gorry’s intent, but let us know if >>>>>>>> changes are necessary. In particular, >>>>>>>> -Section 11 does not have code, but we believe you’d like the artwork >>>>>>>> to stay as it was. Please correct if this assumption is not what was >>>>>>>> intended. >>>>>>>> -We have removed the <> beginning in Section 7.3 to the end of the doc >>>>>>>> (not all terms listed in Gorry’s mail appeared in that section). >>>>>>>> Please let us know if any further changes or reversions are necessary. >>>>>>>> -We also cut the <> from a comment in the code. Please review and let >>>>>>>> us know if this should be reverted. >>>>>>>> 2. Regarding the update from Michael’s mail below: >>>>>>>>> Section 13: >>>>>>>>> I’m not sure about the placement of “either” here. Again, who am I to >>>>>>>>> say, I’m not a native speaker… but it might be a mistake? Anyway, the >>>>>>>>> sentence is just very long and hard to read. Hence my suggestion: >>>>>>>>> OLD: >>>>>>>>> While it is not >>>>>>>>> necessarily expected that both systems are implemented by the same >>>>>>>>> authority, it is expected that the Transport Services Implementation >>>>>>>>> is provided as a library either that is selected by the application >>>>>>>>> from a trusted party or that it is part of the operating system that >>>>>>>>> the application also relies on for other tasks. >>>>>>>>> NEW: >>>>>>>>> While it is not >>>>>>>>> necessarily expected that both systems are implemented by the same >>>>>>>>> authority, it is expected that the Transport Services Implementation >>>>>>>>> is provided as a library that is selected by the application from a >>>>>>>>> trusted party. Alternatively, it could be part of the operating >>>>>>>>> system that the application also relies on for other tasks. >>>>>>>> Thank you for calling this sentence to our attention as the structure >>>>>>>> indeed needs help. We also feel something is off with the verb tense >>>>>>>> and “expected” matching up (seems like a future or conditional >>>>>>>> situation instead of simple present maybe?). >>>>>>>> Please take a look at our suggested rewrite and let us know if this >>>>>>>> would work? >>>>>>>> Perhaps/Current: >>>>>>>> The same authority implementing both systems is not necessarily >>>>>>>> expected. >>>>>>>> However, there is an expectation that the Transport Services >>>>>>>> Implementation would either: >>>>>>>> · be provided as a library that is selected by the application >>>>>>>> from a >>>>>>>> trusted party or >>>>>>>> · be part of the operating system that the application also >>>>>>>> relies on for other tasks. >>>>>>>> Please review the files carefully as we do not make changes after >>>>>>>> publication. >>>>>>>> The files have been posted here (please refresh): >>>>>>>> https://www.rfc-editor.org/authors/rfc9622.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9622.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9622.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9622.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9622.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9622.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9622.xml >>>>>>>> https://www.rfc-editor.org/authors/rfc9622.xml >>>>>>>> The relevant diff files have been posted here (please refresh): >>>>>>>> https://www.rfc-editor.org/authors/rfc9622-diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9622-diff.html (comprehensive >>>>>>>> diff) https://www.rfc-editor.org/authors/rfc9622-auth48diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9622-auth48diff.html (AUTH48 >>>>>>>> changes only) >>>>>>>> https://www.rfc-editor.org/authors/rfc9622-lastdiff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9622-lastdiff.html (last to >>>>>>>> current version only) >>>>>>>> https://www.rfc-editor.org/authors/rfc9622-lastrfcdiff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9622-lastrfcdiff.html (last >>>>>>>> to current rfcdiff) >>>>>>>> Please contact us with any further updates/questions/comments you may >>>>>>>> have. >>>>>>>> We will await approvals from each of the parties listed on the AUTH48 >>>>>>>> status page prior to moving forward to publication. >>>>>>>> The AUTH48 status page for this document is available here: >>>>>>>> https://www.rfc-editor.org/auth48/rfc9622 >>>>>>>> https://www.rfc-editor.org/auth48/rfc9622 >>>>>>>> Thank you. >>>>>>>> RFC Editor/mf >>>>>>>>> On Nov 27, 2024, at 7:09 AM, Michael Welzl <mich...@ifi.uio.no >>>>>>>>> mailto:mich...@ifi.uio.no> wrote: >>>>>>>>> Dear RFC Editor(s), Megan, everyone, >>>>>>>>> Many thanks for the great work! Having carefully read the diff, I >>>>>>>>> only have a handful of last suggestions: >>>>>>>>> Section 6.2: >>>>>>>>> I wonder if this sentence is correct? "At which point, Selection >>>>>>>>> Properties can only be read to check the properties used by the >>>>>>>>> Connection.” >>>>>>>>> If it is, all is well ! (I’m not a native speaker). Else, I suggest: >>>>>>>>> OLD: >>>>>>>>> At which point, Selection Properties can only be read to check the >>>>>>>>> properties used by the Connection. >>>>>>>>> NEW: >>>>>>>>> At this point, Selection Properties can only be read to check the >>>>>>>>> properties used by the Connection. >>>>>>>>> Section 9.3.2.2: >>>>>>>>> This is an oversight from us that I just noticed now, apologies: >>>>>>>>> OLD: >>>>>>>>> // Receive the first 1000 bytes, bytes; message is incomplete >>>>>>>>> NEW: >>>>>>>>> // Receive the first 1000 bytes, bytes; Message is incomplete >>>>>>>>> and, just below: >>>>>>>>> OLD: >>>>>>>>> // Receive the last 500 bytes, bytes; message is incomplete >>>>>>>>> NEW: >>>>>>>>> // Receive the last 500 bytes, bytes; Message is incomplete >>>>>>>>> Section 13: >>>>>>>>> I’m not sure about the placement of “either” here. Again, who am I to >>>>>>>>> say, I’m not a native speaker… but it might be a mistake? Anyway, the >>>>>>>>> sentence is just very long and hard to read. Hence my suggestion: >>>>>>>>> OLD: >>>>>>>>> While it is not >>>>>>>>> necessarily expected that both systems are implemented by the same >>>>>>>>> authority, it is expected that the Transport Services Implementation >>>>>>>>> is provided as a library either that is selected by the application >>>>>>>>> from a trusted party or that it is part of the operating system that >>>>>>>>> the application also relies on for other tasks. >>>>>>>>> NEW: >>>>>>>>> While it is not >>>>>>>>> necessarily expected that both systems are implemented by the same >>>>>>>>> authority, it is expected that the Transport Services Implementation >>>>>>>>> is provided as a library that is selected by the application from a >>>>>>>>> trusted party. Alternatively, it could be part of the operating >>>>>>>>> system that the application also relies on for other tasks. >>>>>>>>> Section 13: >>>>>>>>> misplaced space: >>>>>>>>> OLD: >>>>>>>>> Specifically, Messages that are received partially (see Section >>>>>>>>> 9.3.2.2 )could be a source of truncation attacks if applications do >>>>>>>>> not distinguish between partial Messages and complete Messages. >>>>>>>>> NEW: >>>>>>>>> Specifically, Messages that are received partially (see Section >>>>>>>>> 9.3.2.2) could be a source of truncation attacks if applications do >>>>>>>>> not distinguish between partial Messages and complete Messages. >>>>>>>>> Cheers, >>>>>>>>> Michael >>>>>>>>>> On 25 Nov 2024, at 16:38, Megan Ferguson <mfergu...@amsl.com >>>>>>>>>> mailto:mfergu...@amsl.com> wrote: >>>>>>>>>> Michael and Philipp, >>>>>>>>>> Thank you for your replies. We have updated the document as >>>>>>>>>> requested and now list questions 39, 41, and 42 as the only issues >>>>>>>>>> in need of resolution from our initial email. Just a reminder that >>>>>>>>>> further cluster-wide questions as well as capitalization questions >>>>>>>>>> will be forthcoming. >>>>>>>>>> Please review the files carefully as we do not make changes after >>>>>>>>>> publication. >>>>>>>>>> The files have been posted here (please refresh): >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9622.txt >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9622.txt >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9622.pdf >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9622.pdf >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9622.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9622.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9622.xml >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9622.xml >>>>>>>>>> The relevant diff files have been posted here (please refresh): >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9622-diff.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9622-diff.html >>>>>>>>>> (comprehensive >>>>>>>>>> diff) https://www.rfc-editor.org/authors/rfc9622-auth48diff.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9622-auth48diff.html >>>>>>>>>> (AUTH48 changes only) >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9622-lastdiff.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9622-lastdiff.html (last to >>>>>>>>>> current version only) >>>>>>>>>> Please contact us with any further updates/questions/comments you >>>>>>>>>> may have. >>>>>>>>>> We will await approvals from each of the parties listed on the >>>>>>>>>> AUTH48 status page prior to moving forward to publication. >>>>>>>>>> The AUTH48 status page for this document is available here: >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9622 >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9622 >>>>>>>>>> Thank you. >>>>>>>>>> RFC Editor/mf >>>>>>>>>>> On Nov 23, 2024, at 4:38 AM, Michael Welzl <mich...@ifi.uio.no >>>>>>>>>>> mailto:mich...@ifi.uio.no> wrote: >>>>>>>>>>> Dear all, >>>>>>>>>>> Many thanks Megan and everyone from me as well - and thanks to >>>>>>>>>>> Philipp for his answer! >>>>>>>>>>> I would just like to suggest a change to Philipp’s response to >>>>>>>>>>> question 22, please see below: >>>>>>>>>>>>> Question 22: >>>>>>>>>>>>> >>>>>>>>>>>>> We didn’t see clarification on what “this” refers to: >>>>>>>>>>>>>> Original: >>>>>>>>>>>>>> This can be used by the system to disable the coalescing of >>>>>>>>>>>>>> multiple small Messages into larger packets (Nagle's >>>>>>>>>>>>>> algorithm);.. >>>>>>>>>>>>>> a) How may we clarify the use of "This"? >>>>>>>>>>>> This means “Choosing this capacity profile”. >>>>>>>>>>>> I suggest to update as follows: >>>>>>>>>>>> OLD: >>>>>>>>>>>> This can be used by the system >>>>>>>>>>>> to disable the coalescing of multiple small Messages into larger >>>>>>>>>>>> packets (Nagle's algorithm); >>>>>>>>>>>> NEW: >>>>>>>>>>>> Transport system implementations SHOULD disable the coalescing of >>>>>>>>>>>> multiple small Messages into larger packets (Nagle algorithm (see >>>>>>>>>>>> Section 4.2.3.4 of [RFC1122])); >>>>>>>>>>> Indeed, it means choosing this (really, value of the) capacity >>>>>>>>>>> profile, as Philipp says. However, I don’t think we want (or even >>>>>>>>>>> can) enter a discussion about the use of uppercase SHOULD at this >>>>>>>>>>> point. Instead, let me suggest the following: >>>>>>>>>>> ORIGINAL: >>>>>>>>>>> This can be used by the system >>>>>>>>>>> to disable the coalescing of multiple small Messages into larger >>>>>>>>>>> packets (Nagle's algorithm); >>>>>>>>>>> PRESENT (according to >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9622.htmlhttps://www.rfc-editor.org/authors/rfc9622.html >>>>>>>>>>> ): >>>>>>>>>>> This can be used by the system to disable the coalescing of >>>>>>>>>>> multiple small Messages into larger packets (Nagle algorithm (see >>>>>>>>>>> Section >>>>>>>>>>> 4.2.3.4 of [RFC1122])); >>>>>>>>>>> NEW: >>>>>>>>>>> The "Low Latency/Interactive” value of the capacity profile can be >>>>>>>>>>> used by the system to disable the coalescing of multiple small >>>>>>>>>>> Messages into larger packets (Nagle algorithm, see Section 4.2.3.4 >>>>>>>>>>> of [RFC1122]); >>>>>>>>>>> This suggested update avoids the SHOULD, but it also suggests to >>>>>>>>>>> avoid the double brackets. I don’t have a strong opinion about the >>>>>>>>>>> double brackets, but if the use of the comma instead of the double >>>>>>>>>>> brackets is okay with the RFC Editor style, then I think this would >>>>>>>>>>> look better. >>>>>>>>>>> Many thanks again, everyone! >>>>>>>>>>> Cheers, >>>>>>>>>>> Michael >>>>>>>> När du skickar e-post till Karlstads universitet behandlar vi dina >>>>>>>> personuppgifterhttps://www.kau.se/gdpr . >>>>>>>> When you send an e-mail to Karlstad University, we will process your >>>>>>>> personal datahttps://www.kau.se/en/gdpr . >>>>>> När du skickar e-post till Karlstads universitet behandlar vi dina >>>>>> personuppgifterhttps://www.kau.se/gdpr . >>>>>> When you send an e-mail to Karlstad University, we will process your >>>>>> personal datahttps://www.kau.se/en/gdpr . > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
