Hi Marie-Jose, all, Thank you for your reply. We have made our suggested updates to questions 8-15 and have marked all approvals on the AUTH48 status page here: https://www.rfc-editor.org/auth48/rfc9817
We have now received all necessary approvals and all questions have been resolved. We are ready to move this document forward in the publication process at this time. Please carefully review the document to ensure satisfaction as we do not make changes once it has been published as an RFC. The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9817.txt https://www.rfc-editor.org/authors/rfc9817.pdf https://www.rfc-editor.org/authors/rfc9817.html https://www.rfc-editor.org/authors/rfc9817.xml The relevant diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9817-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9817-auth48diff.html (AUTH48 changes only) https://www.rfc-editor.org/authors/rfc9817-lastdiff.html (last to current version only) https://www.rfc-editor.org/authors/rfc9817-lastrfcdiff.html (last to current side by side) Thank you all for your time and attention during AUTH48. RFC Editor/kf > On Jul 31, 2025, at 2:01 AM, Marie-Jose Montpetit - SLICES-RI > <marie-jose.montpe...@slices-ri.eu> wrote: > > I agree on all the changes for 8-15. > > Thank you > > mjm > >> On Jul 30, 2025, at 11:23 PM, Kaelin Foody <kfo...@staff.rfc-editor.org> >> wrote: >> >> Hi Xavier, Jeffrey, all, >> >> Thanks for your quick responses and clarification. We have noted Jeffrey's >> approval on the AUTH48 status page (see below) and will leave the URL as is. >> >> We will await your responses for questions 8-15. >> >> You may view the AUTH48 status of this document and outstanding questions >> here: >> https://www.rfc-editor.org/auth48/rfc9817 >> >> Thanks, >> RFC Editor/kf >> >>> On Jul 30, 2025, at 12:53 PM, Xavier De Foy <xavier.de...@interdigital.com> >>> wrote: >>> >>> Hi Kaelin, thank you for pointing out the difference in our responses for >>> question #25. I would like to confirm that we (co-authors) agree with the >>> URL that you proposed (in other words, please do not revert back the >>> change). >>> Best Regards, >>> Xavier >>> >>> From: Kaelin Foody <kfo...@staff.rfc-editor.org> >>> Sent: Tuesday, July 29, 2025 22:27 >>> To: Kunze, Ike <ike.ku...@comsys.rwth-aachen.de> >>> Cc: Marie-Jose Montpetit - SLICES-RI <marie-jose.montpe...@slices-ri.eu>; >>> Rio, Miguel <miguel....@ucl.ac.uk>; Dirk Trossen <d...@dapadot-tech.eu>; >>> Griffin, David <d.grif...@ucl.ac.uk>; Wehrle, Klaus >>> <kl...@comsys.rwth-aachen.de>; Xavier De Foy >>> <xavier.de...@interdigital.com>; je...@foxmail.com <je...@foxmail.com>; >>> rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>; i...@irtf.org >>> <i...@irtf.org>; auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> >>> Subject: Re: [Document Shepherd] AUTH48: RFC-to-be 9817 >>> <draft-irtf-coinrg-use-cases-07> for your review Hi Jeffrey (Document >>> Shepherd)* and authors, >>> >>> *Jeffrey, please review and approve the following change at the end of the >>> Introduction. The update can also be viewed at >>> <https://www.rfc-editor.org/authors/rfc9817-auth48diff.html>. >>> >>> Original: >>> This document represents the consensus of COINRG. >>> >>> Current: >>> This document has received review comments at different stages of its >>> development, by >>> experts within and out of COINRG, as detailed in the Acknowledgements >>> section. This document represents the consensus of COINRG. >>> >>> Authors: >>> >>> Thank you for your responses and updated XML files. We have updated our own >>> files to reflect all the changes thus far and can confirm that we are only >>> waiting on responses for questions 8-15. >>> >>> Note that we have received conflicting requests for question 25 (see >>> below). Please discuss and confirm if you prefer the current URL >>> <https://dl.acm.org/doi/10.1145/3426744.3431329> or if the URL should be >>> reverted back to <https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf>. >>> >>>> >>>>> 25) <!--[rfced] References: >>>>> >>>>> a) For [Stoyanov], would you like to change the URL for this reference or >>>>> leave it as is? >>>>> >>>>> Current: https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf >>>>> Perhaps: https://dl.acm.org/doi/10.1145/3426744.3431329 —> >>>>> >>>>> [xdf] I agree with using the proposed URL, thanks. >>>> >>>>> [Dirk] I would prefer leaving it >>> >>> We have received all approvals but will await responses for questions 8-15 >>> before moving forward. >>> >>> You can view the AUTH48 status of this document here: >>> https://www.rfc-editor.org/auth48/rfc9817 >>> >>> The updated files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9817.txt >>> https://www.rfc-editor.org/authors/rfc9817.html >>> https://www.rfc-editor.org/authors/rfc9817.xml >>> >>> The relevant diff files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9817-diff.html (comprehensive diff) >>> https://www.rfc-editor.org/authors/rfc9817-auth48diff.html (AUTH48 changes >>> only) >>> https://www.rfc-editor.org/authors/rfc9817-lastdiff.html (last to current >>> version only) >>> https://www.rfc-editor.org/authors/rfc9817-lastrfcdiff.html (last to >>> current side by side) >>> >>> Thank you. >>> RFC Editor/kf >>> >>>> On Jul 29, 2025, at 5:03 AM, Marie-Jose Montpetit - SLICES-RI >>>> <marie-jose.montpe...@slices-ri.eu> wrote: >>>> >>>> I approve all the changes and will make sure I make mine asap. >>>> >>>>> On Jul 29, 2025, at 10:54 AM, Kunze, Ike >>>>> <ike.ku...@comsys.rwth-aachen.de> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Some additional comments regarding questions 1, 2, 24, 27, and 28 below >>>>> with an updated .xml attached. >>>>> This .xml already contains the changes made by Dirk. >>>>> This should now close questions 1,2,24,27,28. >>>>> >>>>> @Kaelin / RPC team: Could you please confirm that we are only missing >>>>> responses to questions 8-15? >>>>> >>>>> Thanks! >>>>> >>>>> Cheers, >>>>> Ike >>>>> >>>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in >>>>>> the title) for use on https://www.rfc-editor.org/search >>>>>> <https://www.rfc-editor.org/search>. --> >>>>> >>>>> In addition to the suggestions by Dirk, we have added keywords to reflect >>>>> the different use cases. >>>>> >>>>>> 2) <!-- [rfced] Please ensure that the guidelines listed in Section 2.1 >>>>>> of >>>>>> RFC 5743 have been adhered to in this document. See >>>>>> https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1. >>>>>> --> >>>>> >>>>> We have added the following sentence to the introduction: >>>>> This document has received review comments at different stages of its >>>>> development, by experts within and out of COINRG, as detailed in the >>>>> Acknowledgements section. >>>>> >>>>>> 24) <!-- [rfced] Section 7: >>>>> >>>>>> a) In Figure 4 (and throughout Section 7) some words are in all caps, >>>>>> while >>>>>> others are not. Should these partially capitalized phrases be updated to >>>>>> match >>>>>> the other categories that appear in title case? >>>>>> >>>>>> Partially capitalized: >>>>>> VISION(S) for COIN >>>>>> ENABLING TECHNOLOGIES for COIN >>>>>> Distributed Computing FRAMEWORKS and LANGUAGES to COIN >>>>>> >>>>>> Title case: >>>>>> Applicability Areas >>>>>> Transport >>>>>> App Design >>>>>> Data Processing >>>>>> Routing & Forwarding >>>>>> (Industrial) Control >>>>> >>>>>> b) FYI - We have replaced the asterisks in this section with quotation >>>>>> marks >>>>>> to indicate that these terms refer to items in Figure 4. >>>>>> --> >>>>> >>>>> Agreed to Dirk's suggestion, i.e., removing the partially capitalized >>>>> phrases by standard title casing. >>>>> >>>>> >>>>>> 27) <!-- [rfced] Terminology and Abbreviations: >>>>>> >>>>>> a) We note different uses of (COIN) and COIN in the terms below. >>>>>> For consistency and ease of the reader, we suggest removing the >>>>>> parentheses in "(COIN)" when it appears in these instances. Please review >>>>>> and let us know any objections. >>>>>> >>>>>> (COIN) execution environment >>>>>> (COIN) system >>>>>> (COIN) programs >>>>>> (COIN) program instances >>>>>> >>>>>> COIN execution environment >>>>>> COIN system >>>>>> COIN programs >>>>>> COIN program instances >>>>>> >>>>>> >>>>>> b) In general, is there is a specific meaning that is intended when >>>>>> "COIN" >>>>>> is in parentheses? If so, could you add a sentence to define that >>>>>> meaning? For example, why is COIN in parentheses in this text? >>>>>> >>>>>> Section 3.1.2: >>>>>> However, the execution of a (COIN) program may be moved to other >>>>>> (e.g., more suitable) devices, including PNDs, which have exposed the >>>>>> corresponding (COIN) program as individual (COIN) program instances >>>>>> to the (COIN) system by means of a 'service identifier'. >>>>>> >>>>>> We note this convention was also used in >>>>>> draft-irtf-coinrg-coin-terminology >>>>>> (now expired), but it does not seem to be explained. >>>>> >>>>> Dirk's response to b) accurately reflects what I remember. >>>>> In general, we agree to Dirk's suggestion, i.e., removing the brackets; >>>>> the updated xml reflects this change. >>>>> >>>>> >>>>>> d) FYI, we added expansions for the following abbreviations upon first >>>>>> use. >>>>>> Please review each expansion in the document carefully to ensure >>>>>> correctness. >>>>>> >>>>>> Application-Specific Integrated Circuit (ASIC) >>>>>> Graphics Processing Units (GPUs) >>>>>> Information-Centric Network (ICN) >>>>>> Internet of Things (IoT) >>>>>> Java Virtual Machine (JVM) >>>>>> Message Passing Interface (MPI) >>>>>> Quality of Experience (QoE) >>>>>> Remote Direct Memory Access (RDMA) >>>>>> Software-Defined Network (SDN) >>>>>> Standards Development Organization (SDO) >>>>>> User Plane Function (UPF) >>>>>> --> >>>>> >>>>> We have made the following changes: >>>>> >>>>> OLD: >>>>> Information-Centric Network (ICN) >>>>> NEW: >>>>> Information-Centric Networking (ICN) >>>>> >>>>> And we have introduced ICN at an earlier position in the document. >>>>> >>>>> >>>>> >>>>>> 28) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>>>> online >>>>>> Style Guide >>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>>>> and let us know if any changes are needed. Updates of this nature >>>>>> typically >>>>>> result in more precise language, which is helpful for readers. >>>>>> >>>>>> b) In addition, please consider whether instances of "traditional" >>>>>> and "traditionally" should be updated for clarity. While the NIST >>>>>> website >>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> >>>>>> indicates that this term is potentially biased, it is also ambiguous. >>>>>> "Tradition" is a subjective term, as it is not the same for everyone. >>>>>> --> >>>>> >>>>> We have updated all instances of traditional/traditionally. >>>>> >>>>> >>>>> >>>>> On 27.07.25, 11:23, "Dirk Trossen" <d...@dapadot-tech.eu >>>>> <mailto:d...@dapadot-tech.eu>> wrote: >>>>> >>>>> >>>>> Dear all, >>>>> >>>>> >>>>> apologies, my attached reply with comments to the suggested changes and >>>>> those done are attached here - I accidentally sent this to Ike only. >>>>> >>>>> >>>>> I have also attached the XML again. >>>>> >>>>> >>>>> From my side, I am approving this RFC for publication. >>>>> >>>>> >>>>> Many thanks for your efforts, particularly to Ike and the RFC Editor team! >>>>> >>>>> >>>>> Best, >>>>> >>>>> >>>>> Dirk >>>>> >>>>> >>>>> >>>>> >>>>> On 23/07/2025 20:46, Kaelin Foody wrote: >>>>>> Hi Ike, all, >>>>>> >>>>>> Thanks for your replies and the updated XML files. We have updated our >>>>>> own files accordingly. >>>>>> >>>>>> We have added [TIRPITZ-REDUCIO] as an informative reference per your >>>>>> request and have updated Marie-Jose’s email in our database. >>>>>> >>>>>> Thanks for letting us know your timeline; we will await your responses >>>>>> to the remaining questions and Dirk and Marie-Jose’s approvals before >>>>>> moving forward. >>>>>> >>>>>> The AUTH48 status page for this document is available here: >>>>>> https://www.rfc-editor.org/auth48/rfc9817 >>>>>> <https://www.rfc-editor.org/auth48/rfc9817> >>>>>> >>>>>> The files have been posted here (please refresh): >>>>>> https://www.rfc-editor.org/authors/rfc9817.txt >>>>>> <https://www.rfc-editor.org/authors/rfc9817.txt> >>>>>> https://www.rfc-editor.org/authors/rfc9817.pdf >>>>>> <https://www.rfc-editor.org/authors/rfc9817.pdf> >>>>>> https://www.rfc-editor.org/authors/rfc9817.html >>>>>> <https://www.rfc-editor.org/authors/rfc9817.html> >>>>>> https://www.rfc-editor.org/authors/rfc9817.xml >>>>>> <https://www.rfc-editor.org/authors/rfc9817.xml> >>>>>> >>>>>> The relevant diff files have been posted here (please refresh): >>>>>> https://www.rfc-editor.org/authors/rfc9817-diff.html >>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html> (comprehensive >>>>>> diff) >>>>>> https://www.rfc-editor.org/authors/rfc9817-auth48diff.html >>>>>> <https://www.rfc-editor.org/authors/rfc9817-auth48diff.html >(AUTH48 >>>>>> changes only) >>>>>> https://www.rfc-editor.org/authors/rfc9817-lastdiff.html >>>>>> <https://www.rfc-editor.org/authors/rfc9817-lastdiff.html >(last >>>>>> to current version only) >>>>>> https://www.rfc-editor.org/authors/rfc9817-lastrfcdiff.html >>>>>> <https://www.rfc-editor.org/authors/rfc9817-lastrfcdiff.html> (last to >>>>>> current side by side) >>>>>> >>>>>> Thank you, >>>>>> RFC Editor/kf >>>>>> >>>>>>> On Jul 19, 2025, at 10:59 AM, Kunze, Ike >>>>>>> <ike.ku...@comsys.rwth-aachen.de >>>>>>> <mailto:ike.ku...@comsys.rwth-aachen.de>> wrote: >>>>>>> >>>>>>> Correction: >>>>>>> There seems to have been a typo in MJ's mail address. >>>>>>> I have corrected it in the now attached xml and in the list of >>>>>>> recipients of this mail. >>>>>>> The correct mail should be marie-jose.montpe...@slices-ri.eu >>>>>>> <mailto:marie-jose.montpe...@slices-ri.eu> >>>>>>> I have also added MJ's private mail address to facilitate communication >>>>>>> in AUTH48 and maybe double check her professional mail address. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> >>>>>>> On 19.07.25, 16:55, "Kunze, Ike" <ku...@comsys.rwth-aachen.de >>>>>>> <mailto:ku...@comsys.rwth-aachen.de> >>>>>>> <mailto:ku...@comsys.rwth-aachen.de >>>>>>> <mailto:ku...@comsys.rwth-aachen.de>>> wrote: >>>>>>> >>>>>>> >>>>>>> Hi Kaelin, >>>>>>> >>>>>>> >>>>>>> Thank you for the update. >>>>>>> >>>>>>> >>>>>>> I have another author update for you as Marie-José has changed >>>>>>> affiliations, too. >>>>>>> That change is reflected in the attached .xml file and I have included >>>>>>> her current mail address to the mail thread. >>>>>>> >>>>>>> >>>>>>> I have further made a few minor editorial changes as described at the >>>>>>> end of this mail. >>>>>>> Please let me know should you have any additional questions. >>>>>>> >>>>>>> >>>>>>> We plan to hash out the remaining general questions next week and will >>>>>>> get back to you then. >>>>>>> >>>>>>> >>>>>>> Thanks! >>>>>>> Cheers, >>>>>>> Ike >>>>>>> >>>>>>> >>>>>>> 1. In the taxonomy at the end of Section 1: >>>>>>> >>>>>>> >>>>>>> OLD: >>>>>>> Existing Solutions >>>>>>> NEW: >>>>>>> Existing solutions >>>>>>> >>>>>>> >>>>>>> No need for title case here. >>>>>>> >>>>>>> >>>>>>> 2. In the research questions section 4.2.5: >>>>>>> >>>>>>> >>>>>>> OLD: >>>>>>> RQ 4.2.3: Which kinds of COIN programs can be leveraged for >>>>>>> (pre)processing steps and what complexity can they have? >>>>>>> NEW: >>>>>>> RQ 4.2.3: Which kinds of COIN programs can be leveraged for >>>>>>> preprocessing and processing steps and what complexity can they have? >>>>>>> >>>>>>> >>>>>>> OLD: >>>>>>> RQ 4.2.6: How to incorporate the (pre)processing and filtering steps >>>>>>> into the overall system? >>>>>>> NEW: >>>>>>> RQ 4.2.6: How to incorporate the preprocessing, processing, and >>>>>>> filtering steps into the overall system? >>>>>>> >>>>>>> >>>>>>> Align the spelling of (pre)processing with other changes made by the >>>>>>> RFC editor team in AUTH48. >>>>>>> >>>>>>> >>>>>>> 3. In the security considerations section 8: >>>>>>> >>>>>>> >>>>>>> OLD: >>>>>>> However, similar to middlebox deployments, risks for privacy and data >>>>>>> exposure >>>>>>> NEW: >>>>>>> However, similar to middlebox deployments, risks for privacy and the >>>>>>> risk of data exposure >>>>>>> >>>>>>> >>>>>>> Clarify the meaning here. >>>>>>> >>>>>>> >>>>>>> 4. In the security considerations section 8: >>>>>>> >>>>>>> >>>>>>> OLD: >>>>>>> stemming from regulation regarding, lawful interception, data >>>>>>> localization, or AI use >>>>>>> NEW: >>>>>>> stemming from regulation regarding lawful interception, data >>>>>>> localization, or AI use >>>>>>> >>>>>>> >>>>>>> Remove unneeded comma >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 5. Would it be possible to add TIRPITZ-REDUCIO >>>>>>> (https://doi.org/10.1145/3701717.3730547 >>>>>>> <https://doi.org/10.1145/3701717.3730547> >>>>>>> <https://doi.org/10.1145/3701717.3730547> >>>>>>> <https://doi.org/10.1145/3701717.3730547>>) as an additional >>>>>>> reference and make the following change in section 4.2.2.? >>>>>>> Note that this change is not yet reflected in the .xml. >>>>>>> >>>>>>> >>>>>>> OLD: >>>>>>> once the sensor value range becomes interesting (cf. [KUNZE-SIGNAL]) >>>>>>> once the sensor value range becomes interesting (cf. [KUNZE-SIGNAL], >>>>>>> [TIRPITZ-REDUCIO]) >>>>>>> >>>>>>> >>>>>>> The first reference is merely a conceptual description while the latter >>>>>>> shows that it is indeed doable. >>>>>>> >>>>>>> >>>>>>> 6. Section 3.1.2: >>>>>>> >>>>>>> >>>>>>> OLD: >>>>>>> We can already see a trend toward supporting such functionality with >>>>>>> relyiccng on dedicated cloud hardware >>>>>>> NEW: >>>>>>> We can already see a trend toward supporting such functionality that >>>>>>> relies on dedicated cloud hardware >>>>>>> >>>>>>> >>>>>>> Fix an issue that was introduced with the original AUTH48 changes. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 17.07.25, 18:22, "Kaelin Foody" <kfo...@staff.rfc-editor.org >>>>>>> <mailto:kfo...@staff.rfc-editor.org> >>>>>>> <mailto:kfo...@staff.rfc-editor.org >>>>>>> <mailto:kfo...@staff.rfc-editor.org>> >>>>>>> <mailto:kfo...@staff.rfc-editor.org >>>>>>> <mailto:kfo...@staff.rfc-editor.org> >>>>>>> <mailto:kfo...@staff.rfc-editor.org >>>>>>> <mailto:kfo...@staff.rfc-editor.org>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Authors, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thank you for your replies and for explaining how the answers to our >>>>>>> questions have been divided up. Note that we have updated the AUTH48 >>>>>>> status page (see below) to track the approvals we have received to date >>>>>>> as well as to note the questions that have been resolved and those that >>>>>>> remain unanswered: we will not move forward in the publication process >>>>>>> until all questions have been resolved and all parties listed there >>>>>>> have approved. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> We have also made note of Dirk’s new email address in our database for >>>>>>> future communication (e.g., errata mail) for this document. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> We have adopted the XML file submitted by Ike and updated with the >>>>>>> responses from Xavier and David (questions 16, 21, and 25). Please >>>>>>> review carefully as we do not make changes once published. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The files have been posted here (please refresh): >>>>>>> https://www.rfc-editor.org/authors/rfc9817.txt >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.txt> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.txt> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.txt>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.txt> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.txt>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.txt>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.txt&gt;>> >>>>>>> https://www.rfc-editor.org/authors/rfc9817.pdf >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.pdf> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.pdf> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.pdf>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.pdf> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.pdf>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.pdf>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.pdf&gt;>> >>>>>>> https://www.rfc-editor.org/authors/rfc9817.html >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.html> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.html> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.html>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.html> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.html>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.html>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.html&gt;>> >>>>>>> https://www.rfc-editor.org/authors/rfc9817.xml >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.xml> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.xml> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.xml>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.xml> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.xml>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.xml>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817.xml&gt;>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The relevant diff files have been posted here (please refresh): >>>>>>> https://www.rfc-editor.org/authors/rfc9817-diff.html >>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html > >>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html&nbsp;&nbsp;>> >>>>>>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html&nbsp;&nbsp;>> >>>>>>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html&amp;nbsp;&amp;nbsp;&gt;>>(comprehensive >>>>>>> diff) >>>>>>> https://www.rfc-editor.org/authors/rfc9817-auth48diff.html >>>>>>> <https://www.rfc-editor.org/authors/rfc9817-auth48diff.html> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817-auth48diff.html> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817-auth48diff.html>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817-auth48diff.html > >>>>>>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817-auth48diff.html&nbsp;&nbsp;>> >>>>>>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817-auth48diff.html&nbsp;&nbsp;>> >>>>>>> >>>>>>> <https://www.rfc-editor.org/authors/rfc9817-auth48diff.html&amp;nbsp;&amp;nbsp;&gt;>>(AUTH48 >>>>>>> changes only) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The AUTH48 status page for this document is available here: >>>>>>> https://www.rfc-editor.org/auth48/rfc9817 >>>>>>> <https://www.rfc-editor.org/auth48/rfc9817> >>>>>>> <https://www.rfc-editor.org/auth48/rfc9817> >>>>>>> <https://www.rfc-editor.org/auth48/rfc9817>> >>>>>>> <https://www.rfc-editor.org/auth48/rfc9817 > >>>>>>> <https://www.rfc-editor.org/auth48/rfc9817&nbsp;&nbsp;>> >>>>>>> <https://www.rfc-editor.org/auth48/rfc9817&nbsp;&nbsp;>> >>>>>>> <https://www.rfc-editor.org/auth48/rfc9817&amp;nbsp;&amp;nbsp;&gt;>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thank you, >>>>>>> RFC Editor/kf >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Jul 16, 2025, at 5:41 AM, Rio, Miguel <miguel....@ucl.ac.uk >>>>>>>> <mailto:miguel....@ucl.ac.uk> <mailto:miguel....@ucl.ac.uk >>>>>>>> <mailto:miguel....@ucl.ac.uk>> <mailto:miguel....@ucl.ac.uk >>>>>>>> <mailto:miguel....@ucl.ac.uk> <mailto:miguel....@ucl.ac.uk >>>>>>>> <mailto:miguel....@ucl.ac.uk>>>> wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> I approve this RFC for publication. >>>>>>>> Miguel >>>>>>>> From: Griffin, David <d.grif...@ucl.ac.uk <mailto:d.grif...@ucl.ac.uk> >>>>>>>> <mailto:d.grif...@ucl.ac.uk <mailto:d.grif...@ucl.ac.uk>> >>>>>>>> <mailto:d.grif...@ucl.ac.uk <mailto:d.grif...@ucl.ac.uk> >>>>>>>> <mailto:d.grif...@ucl.ac.uk <mailto:d.grif...@ucl.ac.uk>>>> >>>>>>>> Date: Wednesday, 16 July 2025 at 10:39 >>>>>>>> To: Kunze, Ike <ike.ku...@comsys.rwth-aachen.de >>>>>>>> <mailto:ike.ku...@comsys.rwth-aachen.de> >>>>>>>> <mailto:ike.ku...@comsys.rwth-aachen.de >>>>>>>> <mailto:ike.ku...@comsys.rwth-aachen.de>> >>>>>>>> <mailto:ike.ku...@comsys.rwth-aachen.de >>>>>>>> <mailto:ike.ku...@comsys.rwth-aachen.de> >>>>>>>> <mailto:ike.ku...@comsys.rwth-aachen.de >>>>>>>> <mailto:ike.ku...@comsys.rwth-aachen.de>>>>, rfc-edi...@rfc-editor.org >>>>>>>> <mailto:rfc-edi...@rfc-editor.org> <mailto:rfc-edi...@rfc-editor.org >>>>>>>> <mailto:rfc-edi...@rfc-editor.org>> <mailto:rfc-edi...@rfc-editor.org >>>>>>>> <mailto:rfc-edi...@rfc-editor.org> <mailto:rfc-edi...@rfc-editor.org >>>>>>>> <mailto:rfc-edi...@rfc-editor.org>>> <rfc-edi...@rfc-editor.org >>>>>>>> <mailto:rfc-edi...@rfc-editor.org> <mailto:rfc-edi...@rfc-editor.org >>>>>>>> <mailto:rfc-edi...@rfc-editor.org>> <mailto:rfc-edi...@rfc-editor.org >>>>>>>> <mailto:rfc-edi...@rfc-editor.org> <mailto:rfc-edi...@rfc-editor.org >>>>>>>> <mailto:rfc-edi...@rfc-editor.org>>>>, Wehrle, Klaus >>>>>>>> <kl...@comsys.rwth-aachen.de <mailto:kl...@comsys.rwth-aachen.de> >>>>>>>> <mailto:kl...@comsys.rwth-aachen.de >>>>>>>> <mailto:kl...@comsys.rwth-aachen.de>> >>>>>>>> <mailto:kl...@comsys.rwth-aachen.de >>>>>>>> <mailto:kl...@comsys.rwth-aachen.de> >>>>>>>> <mailto:kl...@comsys.rwth-aachen.de >>>>>>>> <mailto:kl...@comsys.rwth-aachen.de>>>>, >>>>>>>> marie-jose.montpe...@mcgill.ca <mailto:marie-jose.montpe...@mcgill.ca> >>>>>>>> <mailto:marie-jose.montpe...@mcgill.ca >>>>>>>> <mailto:marie-jose.montpe...@mcgill.ca>> >>>>>>>> <mailto:marie-jose.montpe...@mcgill.ca >>>>>>>> <mailto:marie-jose.montpe...@mcgill.ca> >>>>>>>> <mailto:marie-jose.montpe...@mcgill.ca >>>>>>>> <mailto:marie-jose.montpe...@mcgill.ca>>> >>>>>>>> <marie-jose.montpe...@mcgill.ca >>>>>>>> <mailto:marie-jose.montpe...@mcgill.ca> >>>>>>>> <mailto:marie-jose.montpe...@mcgill.ca >>>>>>>> <mailto:marie-jose.montpe...@mcgill.ca>> >>>>>>>> <mailto:marie-jose.montpe...@mcgill.ca >>>>>>>> <mailto:marie-jose.montpe...@mcgill.ca> >>>>>>>> <mailto:marie-jose.montpe...@mcgill.ca >>>>>>>> <mailto:marie-jose.montpe...@mcgill.ca>>>>, >>>>>>>> xavier.de...@interdigital.com <mailto:xavier.de...@interdigital.com> >>>>>>>> <mailto:xavier.de...@interdigital.com >>>>>>>> <mailto:xavier.de...@interdigital.com>> >>>>>>>> <mailto:xavier.de...@interdigital.com >>>>>>>> <mailto:xavier.de...@interdigital.com> >>>>>>>> <mailto:xavier.de...@interdigital.com >>>>>>>> <mailto:xavier.de...@interdigital.com>>><xavier.de...@interdigital.com >>>>>>>> <mailto:xavier.de...@interdigital.com> >>>>>>>> <mailto:xavier.de...@interdigital.com >>>>>>>> <mailto:xavier.de...@interdigital.com>> >>>>>>>> <mailto:xavier.de...@interdigital.com >>>>>>>> <mailto:xavier.de...@interdigital.com> >>>>>>>> <mailto:xavier.de...@interdigital.com >>>>>>>> <mailto:xavier.de...@interdigital.com>>>>, Rio, Miguel >>>>>>>> <miguel....@ucl.ac.uk <mailto:miguel....@ucl.ac.uk> >>>>>>>> <mailto:miguel....@ucl.ac.uk <mailto:miguel....@ucl.ac.uk>> >>>>>>>> <mailto:miguel....@ucl.ac.uk <mailto:miguel....@ucl.ac.uk> >>>>>>>> <mailto:miguel....@ucl.ac.uk <mailto:miguel....@ucl.ac.uk>>>>, >>>>>>>> d...@dapadot-tech.eu <mailto:d...@dapadot-tech.eu> >>>>>>>> <mailto:d...@dapadot-tech.eu <mailto:d...@dapadot-tech.eu>> >>>>>>>> <mailto:d...@dapadot-tech.eu <mailto:d...@dapadot-tech.eu> >>>>>>>> <mailto:d...@dapadot-tech.eu <mailto:d...@dapadot-tech.eu>>> >>>>>>>> <d...@dapadot-tech.eu <mailto:d...@dapadot-tech.eu> >>>>>>>> <mailto:d...@dapadot-tech.eu <mailto:d...@dapadot-tech.eu>> >>>>>>>> <mailto:d...@dapadot-tech.eu <mailto:d...@dapadot-tech.eu> >>>>>>>> <mailto:d...@dapadot-tech.eu <mailto:d...@dapadot-tech.eu>>>> >>>>>>>> Cc: i...@irtf.org <mailto:i...@irtf.org> <mailto:i...@irtf.org >>>>>>>> <mailto:i...@irtf.org>> <mailto:i...@irtf.org <mailto:i...@irtf.org> >>>>>>>> <mailto:i...@irtf.org <mailto:i...@irtf.org>>> <i...@irtf.org >>>>>>>> <mailto:i...@irtf.org> <mailto:i...@irtf.org <mailto:i...@irtf.org>> >>>>>>>> <mailto:i...@irtf.org <mailto:i...@irtf.org> <mailto:i...@irtf.org >>>>>>>> <mailto:i...@irtf.org>>>>, je...@foxmail.com >>>>>>>> <mailto:je...@foxmail.com> <mailto:je...@foxmail.com >>>>>>>> <mailto:je...@foxmail.com>> <mailto:je...@foxmail.com >>>>>>>> <mailto:je...@foxmail.com> <mailto:je...@foxmail.com >>>>>>>> <mailto:je...@foxmail.com>>> <je...@foxmail.com >>>>>>>> <mailto:je...@foxmail.com> <mailto:je...@foxmail.com >>>>>>>> <mailto:je...@foxmail.com>> <mailto:je...@foxmail.com >>>>>>>> <mailto:je...@foxmail.com> <mailto:je...@foxmail.com >>>>>>>> <mailto:je...@foxmail.com>>>>, auth48archive@rfc-editor.org >>>>>>>> <mailto:auth48archive@rfc-editor.org> >>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>> <mailto:auth48archive@rfc-editor.org>> >>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>> <mailto:auth48archive@rfc-editor.org> >>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>> <mailto:auth48archive@rfc-editor.org>>> <auth48archive@rfc-editor.org >>>>>>>> <mailto:auth48archive@rfc-editor.org> >>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>> <mailto:auth48archive@rfc-editor.org>> >>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>> <mailto:auth48archive@rfc-editor.org> >>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>> <mailto:auth48archive@rfc-editor.org>>>> >>>>>>>> Subject: Re: AUTH48: RFC-to-be 9817 <draft-irtf-coinrg-use-cases-07> >>>>>>>> for your review >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Re comment 16, we agree with the updated text suggested by the editor. >>>>>>>> >>>>>>>> I approve this RFC for publication. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 15/07/2025 08:56, Kunze, Ike wrote: >>>>>>>>> Dear RPC team, >>>>>>>>> >>>>>>>>> Thank you for preparing our document and for starting AUTH48. >>>>>>>>> Please note that I have included the new email address of Dirk >>>>>>>>> Trossen to the list of recipients; the old one is no longer >>>>>>>>> functional as you have probably also noticed. >>>>>>>>> I have also updated his affiliation in the .xml accordingly. >>>>>>>>> >>>>>>>>> Given that the document is a collaborative effort of all authors with >>>>>>>>> different authors being responsible for different parts of the >>>>>>>>> document, please expect focused responses of individual co-authors to >>>>>>>>> address comments 3 - 23, 25, and 26. >>>>>>>>> We will provide joint responses to comments 1, 2, 24, 27, and 28 in a >>>>>>>>> separate email. >>>>>>>>> >>>>>>>>> At the end of this email, you can find my response to comment 17. >>>>>>>>> >>>>>>>>> Finally, for the record, I approve this RFC for publication. >>>>>>>>> >>>>>>>>> Please do not hesitate to reach out to me should you have any >>>>>>>>> questions. >>>>>>>>> >>>>>>>>> Thanks again! >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Ike >>>>>>>>> >>>>>>>>> >>>>>>>>> <!-- [rfced] For clarity, may we adjust this list as follows? >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> * RQ 4.1.6: Can there be different control levels, e.g., "quite >>>>>>>>> inaccurate & very low latency" (PNDs, deep in the network), "more >>>>>>>>> accurate & higher latency" (more powerful COIN execution >>>>>>>>> environments, farer away), "very accurate & very high latency" >>>>>>>>> (cloud environments, far away)? >>>>>>>>> >>>>>>>>> Option A (without parentheses): >>>>>>>>> * RQ 4.1.6: Can there be different control levels? For example, >>>>>>>>> "quite inaccurate & very low latency" for PNDs deep in the network; >>>>>>>>> "more accurate & higher latency" for more powerful COIN execution >>>>>>>>> environments that are farther away; and "very accurate & very high >>>>>>>>> latency" for cloud environments that are far away. >>>>>>>>> >>>>>>>>> Option B (using a sublist): >>>>>>>>> * RQ 4.1.6: Can there be different control levels? For example: >>>>>>>>> >>>>>>>>> - "quite inaccurate & very low latency" for PNDs deep in the >>>>>>>>> network; >>>>>>>>> - "more accurate & higher latency" for more powerful COIN execution >>>>>>>>> environments that are farther away; and >>>>>>>>> - "very accurate & very high latency" for cloud environments that >>>>>>>>> are far away. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> [IK] Thanks for the suggestions. >>>>>>>>> I have included Option A in the .xml. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 15.07.25, 03:16, "rfc-edi...@rfc-editor.org >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org> <mailto:rfc-edi...@rfc-editor.org >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org>> <mailto:rfc-edi...@rfc-editor.org >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org> <mailto:rfc-edi...@rfc-editor.org >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org>>> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org>>>>" <rfc-edi...@rfc-editor.org >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org> <mailto:rfc-edi...@rfc-editor.org >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org>> <mailto:rfc-edi...@rfc-editor.org >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org> <mailto:rfc-edi...@rfc-editor.org >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org>>> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Authors, >>>>>>>>> >>>>>>>>> >>>>>>>>> While reviewing this document during AUTH48, please resolve >>>>>>>>> the following questions, which are also in the XML file. >>>>>>>>> >>>>>>>>> >>>>>>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear >>>>>>>>> in >>>>>>>>> the title) for use on >>>>>>>>> https://www.rfc-editor.org/search<https://www.rfc-editor.org/search> >>>>>>>>> <https://www.rfc-editor.org/search;> >>>>>>>>> <https://www.rfc-editor.org/search;> >>>>>>>>> <https://www.rfc-editor.org/search;> >>>>>>>>> <https://www.rfc-editor.org/search;> >>>>>>>>> <https://www.rfc-editor.org/search;> >>>>>>>>> <https://www.rfc-editor.org/search;> >>>>>>>>> <https://www.rfc-editor.org/search;>. --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2) <!-- [rfced] Please ensure that the guidelines listed in Section >>>>>>>>> 2.1 of >>>>>>>>> RFC 5743 have been adhered to in this document. See >>>>>>>>> https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1 >>>>>>>>> <https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1> >>>>>>>>> <https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1> >>>>>>>>> <https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1;> >>>>>>>>> <https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1> >>>>>>>>> <https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1;> >>>>>>>>> <https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1;> >>>>>>>>> <https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1;> >>>>>>>>> <https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1> >>>>>>>>> <https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1;> >>>>>>>>> <https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1;> >>>>>>>>> <https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1;> >>>>>>>>> <https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1;> >>>>>>>>> <https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1;> >>>>>>>>> <https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1;> >>>>>>>>> <https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1;>. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 3) <!-- [rfced] May we make this into two sentences as follows for >>>>>>>>> ease of >>>>>>>>> the reader? Also, would you like to change the adjective "compute >>>>>>>>> intensive" >>>>>>>>> to "CPU-intensive", which is used later in this document? >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> Once this application is partitioned into its constituent (COIN) >>>>>>>>> programs and deployed throughout a COIN system, utilizing a COIN >>>>>>>>> execution environment, only the "display" (COIN) program may be left >>>>>>>>> in the headset, while the compute intensive real-time VR content >>>>>>>>> processing (COIN) program can be offloaded to a nearby resource rich >>>>>>>>> home PC or a programmable network device (PND) in the operator's >>>>>>>>> access network, for a better execution (faster and possibly higher >>>>>>>>> resolution generation). >>>>>>>>> >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> Once this application is partitioned into its constituent (COIN) >>>>>>>>> programs and deployed throughout a COIN system utilizing a COIN >>>>>>>>> execution environment, only the display (COIN) program may be left in >>>>>>>>> the headset. Meanwhile, the CPU-intensive real-time VR content >>>>>>>>> processing (COIN) program can be offloaded to a nearby resource rich >>>>>>>>> home PC or a Programmable Network Device (PND) in the operator's >>>>>>>>> access network for a better execution (i.e., faster and possibly >>>>>>>>> higher >>>>>>>>> resolution generation). >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 4) <!-- [rfced] How may we update the following text to clarify the >>>>>>>>> relationship between the "result" and the phrases that follow? >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> The result is the equivalent to 'mobile function offloading', for >>>>>>>>> possible >>>>>>>>> reduction of power consumption (e.g., offloading CPU intensive process >>>>>>>>> functions to a remote server) or for improved end user experience >>>>>>>>> (e.g., >>>>>>>>> moving display functions to a nearby smart TV) by selecting more >>>>>>>>> suitably >>>>>>>>> placed (COIN) program instances in the overall (COIN) system. >>>>>>>>> >>>>>>>>> >>>>>>>>> Option A: >>>>>>>>> The result is the equivalent to mobile function offloading, in that it >>>>>>>>> offers the possible reduction of power consumption (e.g., offloading >>>>>>>>> CPU- >>>>>>>>> intensive process functions to a remote server) or offers an improved >>>>>>>>> end-user experience (e.g., moving display functions to a nearby smart >>>>>>>>> TV) >>>>>>>>> by selecting more suitably placed (COIN) program instances in the >>>>>>>>> overall >>>>>>>>> (COIN) system. >>>>>>>>> >>>>>>>>> >>>>>>>>> Option B (if *both* reducing power consumption and improving the >>>>>>>>> end-user >>>>>>>>> experience are due to selecting more suitably placed program >>>>>>>>> instances): >>>>>>>>> >>>>>>>>> >>>>>>>>> The result is the equivalent to mobile function offloading because, by >>>>>>>>> selecting more suitably placed (COIN) program instances in the overall >>>>>>>>> (COIN) system, it offers a potential reduction of power consumption >>>>>>>>> (e.g., >>>>>>>>> offloading CPU-intensive process functions to a remote server) or an >>>>>>>>> improved end-user experience (e.g., moving display functions to a >>>>>>>>> nearby >>>>>>>>> smart TV). >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 5) <!-- [rfced] We note that the reference [ETSI] uses "Multi-access >>>>>>>>> Edge >>>>>>>>> Computing (MEC)" rather than "Mobile Edge Computing (MEC)" as seen in >>>>>>>>> the >>>>>>>>> text below. May we update this sentence accordingly? >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> The ETSI Mobile Edge Computing (MEC) [ETSI] suite of technologies >>>>>>>>> provides solutions... >>>>>>>>> >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> The ETSI Multi-access Edge Computing (MEC) [ETSI] suite of >>>>>>>>> technologies >>>>>>>>> provides solutions... >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 6) <!-- [rfced] Please clarify this sentence, especially "rather >>>>>>>>> than". >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> Also, the ETSI work does not allow for the >>>>>>>>> dynamic selection and redirection of (COIN) program calls to varying >>>>>>>>> edge resources rather than a single MEC application server. >>>>>>>>> >>>>>>>>> >>>>>>>>> Option A: >>>>>>>>> Also, the ETSI work does not allow for the >>>>>>>>> dynamic selection and redirection of (COIN) program calls to varying >>>>>>>>> edge resources; it does allow for them to a single MEC application >>>>>>>>> server. >>>>>>>>> >>>>>>>>> >>>>>>>>> Option B (stating the reverse): >>>>>>>>> Also, the ETSI work allows for the dynamic selection and >>>>>>>>> redirection of (COIN) program calls to only a single MEC application >>>>>>>>> server, not to varying edge resources. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 7) <!-- [rfced] Seems a closing parenthesis was missing on "(service >>>>>>>>> routing >>>>>>>>> in [APPCENTRES]...". We added it; please review. >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> * The support for service-level routing of requests (service routing >>>>>>>>> in [APPCENTRES] may support higher flexibility when switching from >>>>>>>>> one (COIN) program instance to another, e.g., due to changing >>>>>>>>> constraints for selecting the new (COIN) program instance. Here, >>>>>>>>> PNDs may support service routing solutions by acting as routing >>>>>>>>> overlay nodes to implement the necessary additional lookup >>>>>>>>> functionality and also possibly support the handling of affinity >>>>>>>>> relations, i.e., the forwarding of one packet to the destination >>>>>>>>> of a previous one due to a higher level service relation, as >>>>>>>>> discussed and described in [SarNet2021]. >>>>>>>>> >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> * The support for service-level routing of requests (such as service >>>>>>>>> routing in [APPCENTRES]) may support higher flexibility when switching >>>>>>>>> from one (COIN) program instance to another (e.g., due to changing >>>>>>>>> constraints for selecting the new (COIN) program instance). Here, PNDs >>>>>>>>> may support service routing solutions by acting as routing overlay >>>>>>>>> nodes >>>>>>>>> to implement the necessary additional lookup functionality and also >>>>>>>>> possibly support the handling of affinity relations (i.e., the >>>>>>>>> forwarding of one packet to the destination of a previous one due to a >>>>>>>>> higher level service relation as discussed and described in >>>>>>>>> [SarNet2021]). >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 8) <!-- [rfced] FYI, for readability, we made this into two sentences >>>>>>>>> at >>>>>>>>> "that can benefit". Please review. >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> XR is one example of the multisource- >>>>>>>>> multidestination problem that combines video and haptics in >>>>>>>>> interactive multi-party interactions under strict delay requirements >>>>>>>>> that can benefit from a functional distribution that includes fog >>>>>>>>> computing for local information processing, the edge for aggregation, >>>>>>>>> and the cloud for image processing. >>>>>>>>> >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> XR is one example of the multisource- >>>>>>>>> multidestination problem that combines video and haptics in >>>>>>>>> interactive multiparty interactions under strict delay requirements. >>>>>>>>> As such, XR can benefit from a functional distribution that includes >>>>>>>>> fog computing for local information processing, the edge for >>>>>>>>> aggregation, and the cloud for image processing. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 9) <!-- [rfced] Should "re-rerouting" be updated to "re-routing" here? >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> More importantly, COIN can enable collaborative XR experiences, where >>>>>>>>> multiple users interact in the same virtual space in real-time, >>>>>>>>> regardless >>>>>>>>> of their physical locations, by allowing resource discovery and >>>>>>>>> re-rerouting of XR streams. >>>>>>>>> >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> More importantly, COIN can enable collaborative XR experiences, where >>>>>>>>> multiple users interact in the same virtual space in real time, >>>>>>>>> regardless >>>>>>>>> of their physical locations, by allowing resource discovery and >>>>>>>>> re-routing of XR streams. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 10) <!-- [rfced] For clarity, may we update "not networked or >>>>>>>>> distributed" >>>>>>>>> in the text below to be more descriptive? >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> Hence, implementing such XR solutions necessitates substantial >>>>>>>>> computational power and minimal latency, which, for now, has spurred >>>>>>>>> the >>>>>>>>> development of better headsets not networked or distributed solutions >>>>>>>>> as >>>>>>>>> factors like distance from cloud servers and limited bandwidth can >>>>>>>>> still >>>>>>>>> significantly lower application responsiveness. >>>>>>>>> >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> Hence, implementing such XR solutions necessitates substantial >>>>>>>>> computational power and minimal latency, which, for now, has spurred >>>>>>>>> the >>>>>>>>> development of better headsets, rather than spurring networked or >>>>>>>>> distributed solutions, as factors like distance from cloud servers and >>>>>>>>> limited bandwidth can still significantly lower application >>>>>>>>> responsiveness. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 11) <!-- [rfced] We have added additional punctuation to the text >>>>>>>>> below. Please >>>>>>>>> review these updates and confirm that they do not change your intended >>>>>>>>> meaning. >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> Information Centric Networking (and related) approaches that combine >>>>>>>>> publish subscribe and distributed storage are also very suited for the >>>>>>>>> multisource-multidestination applications of XR. >>>>>>>>> >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> Information-centric networking (and related) approaches that combine, >>>>>>>>> publish, subscribe, and distribute storage are also very suited for >>>>>>>>> the multisource-multidestination applications of XR. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 12) <!-- [rfced] For clarity, may we change 'the discovery of' to >>>>>>>>> 'discovering'? >>>>>>>>> This makes the action parallel with 'using' (in other words, >>>>>>>>> 'they include discovering X and using them to do Y'). >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> Mechanisms aimed at enhancing the computational and storage >>>>>>>>> capacities of >>>>>>>>> mobile devices could also improve XR capabilities as they include the >>>>>>>>> discovery of available servers within the environment and using them >>>>>>>>> opportunistically to enhance the performance of interactive >>>>>>>>> applications >>>>>>>>> and distributed file systems. >>>>>>>>> >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> Mechanisms aimed at enhancing the computational and storage >>>>>>>>> capacities of >>>>>>>>> mobile devices could also improve XR capabilities, as they include >>>>>>>>> discovering available servers within the environment and using them >>>>>>>>> opportunistically to enhance the performance of interactive >>>>>>>>> applications >>>>>>>>> and distributed file systems. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 13) <!-- [rfced] Would "federating systems capabilities" be more >>>>>>>>> clear as >>>>>>>>> "the federation of systems capabilities" here? >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> Yet, there are still very few interactive immersive media applications >>>>>>>>> over networks that allow for federating systems capabilities. >>>>>>>>> >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> Yet, there are still very few interactive immersive media applications >>>>>>>>> over networks that allow for the federation of systems capabilities. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 14) <!-- [rfced] For readability and clarity of RQ 3.2.3 >>>>>>>>> >>>>>>>>> >>>>>>>>> a) Is this about two separate research questions ("the use of >>>>>>>>> distributed AI" >>>>>>>>> and "the creation of semi-permanent datasets")? May they be two >>>>>>>>> separate >>>>>>>>> sentences? >>>>>>>>> >>>>>>>>> >>>>>>>>> b) May we adjust "resulting in" to "result in" to add a clear verb to >>>>>>>>> the >>>>>>>>> second half of this text? >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> * RQ 3.2.3: Can the use of distributed AI algorithms across both >>>>>>>>> data center and edge computers be leveraged for creating optimal >>>>>>>>> function allocation and the creation of semi-permanent datasets >>>>>>>>> and analytics for usage trending and flow management resulting in >>>>>>>>> better localization of XR functions? >>>>>>>>> >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> * RQ 3.2.3: Can the use of distributed AI algorithms across both >>>>>>>>> data center and edge computers be leveraged for creating optimal >>>>>>>>> function allocation? Can the creation of semi-permanent datasets >>>>>>>>> and analytics for usage trending and flow management result in >>>>>>>>> better localization of XR functions? >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 15) <!-- [rfced] For ease of the reader, may we break this one >>>>>>>>> sentence into two? >>>>>>>>> In addition, may we update the verb "optimize" to "optimizing" as >>>>>>>>> follows? >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> * RQ 3.2.4: Can COIN improve the dynamic distribution of control, >>>>>>>>> forwarding, and storage resources and related usage models in XR, >>>>>>>>> such as to integrate local and fog caching with cloud-based pre- >>>>>>>>> rendering, thus jointly optimizing COIN and higher layer protocols >>>>>>>>> to reduce latency and, more generally, manage the quality of XR >>>>>>>>> sessions, e.g., through reduced in-network congestion and improved >>>>>>>>> flow delivery by determining how to prioritize XR data? >>>>>>>>> >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> * RQ 3.2.4: Can COIN improve the dynamic distribution of control, >>>>>>>>> forwarding, and storage resources and related usage models in XR, >>>>>>>>> such as to integrate local and fog caching with cloud-based pre- >>>>>>>>> rendering? Could this jointly optimize COIN and higher layer >>>>>>>>> protocols to >>>>>>>>> reduce latency and, more generally, manage the quality of XR sessions >>>>>>>>> (e.g., through reduced in-network congestion and improved flow >>>>>>>>> delivery >>>>>>>>> by determining how to prioritize XR data)? >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 16) <!--[rfced] FYI, this text has been updated to use person-first >>>>>>>>> language. >>>>>>>>> Please let us know if you prefer otherwise. >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> * Augmentation of the performance with subtitles, audio-description, >>>>>>>>> actor-tagging, language translation, advertisements/product- >>>>>>>>> placement, other enhancements/filters to make the performance >>>>>>>>> accessible to disabled audience members (removal of flashing >>>>>>>>> images for epileptics, alternative color schemes for color-blind >>>>>>>>> audience members, etc.). >>>>>>>>> >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> * Augmentation of the performance with subtitles, audio description, >>>>>>>>> actor tagging, language translation, advertisements and product >>>>>>>>> placement, and other enhancements and filters to make the >>>>>>>>> performance accessible to audience members who are disabled (e.g., >>>>>>>>> the removal of flashing images for audience members who have >>>>>>>>> epilepsy or alternative color schemes for those who have color >>>>>>>>> blindness). >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 17) <!-- [rfced] For clarity, may we adjust this list as follows? >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> * RQ 4.1.6: Can there be different control levels, e.g., "quite >>>>>>>>> inaccurate & very low latency" (PNDs, deep in the network), "more >>>>>>>>> accurate & higher latency" (more powerful COIN execution >>>>>>>>> environments, farer away), "very accurate & very high latency" >>>>>>>>> (cloud environments, far away)? >>>>>>>>> >>>>>>>>> >>>>>>>>> Option A (without parentheses): >>>>>>>>> * RQ 4.1.6: Can there be different control levels? For example, >>>>>>>>> "quite inaccurate & very low latency" for PNDs deep in the network; >>>>>>>>> "more accurate & higher latency" for more powerful COIN execution >>>>>>>>> environments that are farther away; and "very accurate & very high >>>>>>>>> latency" for cloud environments that are far away. >>>>>>>>> >>>>>>>>> >>>>>>>>> Option B (using a sublist): >>>>>>>>> * RQ 4.1.6: Can there be different control levels? For example: >>>>>>>>> >>>>>>>>> >>>>>>>>> - "quite inaccurate & very low latency" for PNDs deep in the >>>>>>>>> network; >>>>>>>>> - "more accurate & higher latency" for more powerful COIN execution >>>>>>>>> environments that are farther away; and >>>>>>>>> - "very accurate & very high latency" for cloud environments that >>>>>>>>> are far away. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 18) <!-- [rfced] Section 5.1.4: To improve readability and avoid >>>>>>>>> overuse >>>>>>>>> of "e.g.," and parentheses, how may these items be updated? >>>>>>>>> >>>>>>>>> >>>>>>>>> i) Does "(e.g., virtualized, distributed)" mean the set of choices >>>>>>>>> are virtualized and/or distributed? >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> * Supporting the selection of a service destination from a set of >>>>>>>>> possible (e.g., virtualized, distributed) choices, e.g., through >>>>>>>>> constraint-based routing decisions (see [APPCENTRES]) in (COIN) >>>>>>>>> program instances to improve the overall end user experience by >>>>>>>>> selecting a 'more suitable' service destination over another, >>>>>>>>> e.g., avoiding/reducing overload situations in specific service >>>>>>>>> destinations. >>>>>>>>> >>>>>>>>> >>>>>>>>> Option A: >>>>>>>>> * Supporting the selection of a service destination from a set of >>>>>>>>> possible choices (virtualized and distributed) in (COIN) program >>>>>>>>> instances (e.g., through constraint-based routing decisions as seen in >>>>>>>>> [APPCENTRES]) to improve the overall end-user experience by selecting >>>>>>>>> a >>>>>>>>> "more suitable" service destination over another (e.g., >>>>>>>>> avoiding/reducing overload situations in specific service >>>>>>>>> destinations). >>>>>>>>> >>>>>>>>> >>>>>>>>> Option B (moving the last two examples to one final sentence): >>>>>>>>> * Supporting the selection of a service destination from a set of >>>>>>>>> possible choices (virtualized and distributed) in (COIN) program >>>>>>>>> instances to improve the overall end-user experience by selecting a >>>>>>>>> "more suitable" service destination over another. (For example, >>>>>>>>> selecting through constraint-based routing decisions as seen in >>>>>>>>> [APPCENTRES] may allow avoiding/reducing overload situations in >>>>>>>>> specific service destinations.) >>>>>>>>> >>>>>>>>> >>>>>>>>> ii) Does "in-network/switch-based" mean "in-network and switch-based"? >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> * Supporting Layer 2 capabilities for multicast (compute >>>>>>>>> interconnection and collective communication in [APPCENTRES]), >>>>>>>>> e.g., through in-network/switch-based replication decisions (and >>>>>>>>> their optimizations) based on dynamic group membership >>>>>>>>> information, may reduce the network utilization and therefore >>>>>>>>> increase the overall system efficiency. >>>>>>>>> >>>>>>>>> >>>>>>>>> Perhaps (moving the example to the end): >>>>>>>>> * Supporting L2 capabilities for multicast (compute interconnection >>>>>>>>> and collective communication as seen in [APPCENTRES]) may >>>>>>>>> reduce the network utilization and therefore increase the overall >>>>>>>>> system efficiency. For example, this support may be >>>>>>>>> through in-network, switch-based replication decisions (and their >>>>>>>>> optimizations) based on dynamic group membership information. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 19) <!-- [rfced] FYI - We have added a subject for "such as exposed >>>>>>>>> through" in >>>>>>>>> the text below. Also, we assumed "InfiBand" was intended as >>>>>>>>> "InfiniBand". >>>>>>>>> Please review. >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> We interpret connected compute resources as operating at a suitable >>>>>>>>> layer, such as Ethernet, InfiBand but also at Layer 3, to allow for >>>>>>>>> the exchange of suitable invocation methods, such as exposed through >>>>>>>>> verb-based or socket-based APIs. >>>>>>>>> >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> We interpret connected compute resources as operating at a suitable >>>>>>>>> layer, such as Ethernet, InfiniBand, but also at Layer 3 (L3), to >>>>>>>>> allow >>>>>>>>> for the exchange of suitable invocation methods, such as those >>>>>>>>> exposed through verb-based or socket-based APIs. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 20) <!-- [rfced] Section 5.2.4. Opportunities: How may we add a >>>>>>>>> verb/outcome >>>>>>>>> to the second part of this list item, in order to be consistent with >>>>>>>>> the >>>>>>>>> rest of the items in this section? >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> * Supporting the enforcement of trust relationships and isolation >>>>>>>>> policies through intermediary (COIN) program instances, e.g., >>>>>>>>> enforcing specific traffic shares or strict isolation of traffic >>>>>>>>> through differentiated queueing. >>>>>>>>> >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> * Supporting the enforcement of trust relationships and isolation >>>>>>>>> policies through intermediary (COIN) program instances (e.g., >>>>>>>>> enforcing specific traffic shares or strict isolation of traffic >>>>>>>>> through differentiated queueing) will allow for [what?]. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 21) <!-- [rfced] May "controller" be plural here in order to be >>>>>>>>> parallel >>>>>>>>> with the other plural list items? >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> Virtual network programming by tenants could bring benefits such as: >>>>>>>>> >>>>>>>>> >>>>>>>>> * A unified programming model, which can facilitate porting COIN >>>>>>>>> programs between data centers, 5G networks, and other fixed and >>>>>>>>> wireless networks, as well as sharing controller, code and >>>>>>>>> expertise. >>>>>>>>> >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> Virtual network programming by tenants could bring benefits such as: >>>>>>>>> >>>>>>>>> >>>>>>>>> * A unified programming model, which can facilitate porting COIN >>>>>>>>> programs between data centers, 5G networks, and other fixed and >>>>>>>>> wireless networks, as well as sharing controllers, code, and >>>>>>>>> expertise. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 22) <!-- [rfced] Section 6.1.4. Opportunities: We are having a >>>>>>>>> difficult time >>>>>>>>> parsing the two items below. How may we revise for clarity? >>>>>>>>> (For example, in the second item, please consider where the first >>>>>>>>> "e.g." >>>>>>>>> phrase end, and how the second "e.g." connects to the preceding text.) >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> * Supporting service-level routing of training requests (service >>>>>>>>> routing in [APPCENTRES]), with AI services being exposed to the >>>>>>>>> network, where (COIN) program instances may support the selection >>>>>>>>> of the most suitable service instance based on control plane >>>>>>>>> information, e.g., on AI worker compute capabilities, being >>>>>>>>> distributed across (COIN) program instances. >>>>>>>>> >>>>>>>>> >>>>>>>>> * Supporting the collective communication primitives, such as all- >>>>>>>>> to-all, scatter-gather, utilized by the (distributed) AI workers >>>>>>>>> to increase the overall network efficiency, e.g., through avoiding >>>>>>>>> endpoint-based replication or even directly performing, e.g., >>>>>>>>> reduce, collective primitive operations in (COIN) program >>>>>>>>> instances placed in topologically advantageous places. >>>>>>>>> >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> * Supporting service-level routing of training requests (such as >>>>>>>>> service >>>>>>>>> routing in [APPCENTRES]) with AI services being exposed to the >>>>>>>>> network, and where (COIN) program instances may support the selection >>>>>>>>> of the most suitable service instance based on control plane >>>>>>>>> information (e.g., on AI worker compute capabilities being >>>>>>>>> distributed across (COIN) program instances). >>>>>>>>> >>>>>>>>> >>>>>>>>> * Supporting the collective communication primitives, such as all- >>>>>>>>> to-all and scatter-gather, utilized by the (distributed) AI >>>>>>>>> workers may increase the overall network efficiency (e.g., >>>>>>>>> through avoiding endpoint-based replication or even directly >>>>>>>>> performing (or reducing) collective primitive operations) in (COIN) >>>>>>>>> program instances placed in topologically advantageous places. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 23) <!-- [rfced] Please clarify the final phrase; what is the subject >>>>>>>>> of >>>>>>>>> "reduce"? In other words, what educe in a central (COIN) program >>>>>>>>> >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> * RQ 6.1.1: What are the communication patterns that may be >>>>>>>>> supported by collective communication solutions, where those >>>>>>>>> solutions directly utilize (COIN) program instance capabilities >>>>>>>>> within the network (e.g., reduce in a central (COIN) program >>>>>>>>> instance)? >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 24) <!-- [rfced] Section 7: >>>>>>>>> >>>>>>>>> >>>>>>>>> a) In Figure 4 (and throughout Section 7) some words are in all caps, >>>>>>>>> while >>>>>>>>> others are not. Should these partially capitalized phrases be updated >>>>>>>>> to match >>>>>>>>> the other categories that appear in title case? >>>>>>>>> >>>>>>>>> >>>>>>>>> Partially capitalized: >>>>>>>>> VISION(S) for COIN >>>>>>>>> ENABLING TECHNOLOGIES for COIN >>>>>>>>> Distributed Computing FRAMEWORKS and LANGUAGES to COIN >>>>>>>>> >>>>>>>>> >>>>>>>>> Title case: >>>>>>>>> Applicability Areas >>>>>>>>> Transport >>>>>>>>> App Design >>>>>>>>> Data Processing >>>>>>>>> Routing & Forwarding >>>>>>>>> (Industrial) Control >>>>>>>>> >>>>>>>>> >>>>>>>>> b) FYI - We have replaced the asterisks in this section with >>>>>>>>> quotation marks >>>>>>>>> to indicate that these terms refer to items in Figure 4. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 25) <!--[rfced] References: >>>>>>>>> >>>>>>>>> >>>>>>>>> a) For [Stoyanov], would you like to change the URL for this >>>>>>>>> reference or leave it as is? >>>>>>>>> >>>>>>>>> >>>>>>>>> Current: https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf >>>>>>>>> <https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf> >>>>>>>>> <https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf> >>>>>>>>> <https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf;> >>>>>>>>> <https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf> >>>>>>>>> <https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf;> >>>>>>>>> <https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf;> >>>>>>>>> <https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf;> >>>>>>>>> <https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf> >>>>>>>>> <https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf;> >>>>>>>>> <https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf;> >>>>>>>>> <https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf;> >>>>>>>>> <https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf;> >>>>>>>>> <https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf;> >>>>>>>>> <https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf;> >>>>>>>>> <https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf;> >>>>>>>>> Perhaps: https://dl.acm.org/doi/10.1145/3426744.3431329 >>>>>>>>> <https://dl.acm.org/doi/10.1145/3426744.3431329> >>>>>>>>> <https://dl.acm.org/doi/10.1145/3426744.3431329> >>>>>>>>> <https://dl.acm.org/doi/10.1145/3426744.3431329;> >>>>>>>>> <https://dl.acm.org/doi/10.1145/3426744.3431329> >>>>>>>>> <https://dl.acm.org/doi/10.1145/3426744.3431329;> >>>>>>>>> <https://dl.acm.org/doi/10.1145/3426744.3431329;> >>>>>>>>> <https://dl.acm.org/doi/10.1145/3426744.3431329;> >>>>>>>>> <https://dl.acm.org/doi/10.1145/3426744.3431329> >>>>>>>>> <https://dl.acm.org/doi/10.1145/3426744.3431329;> >>>>>>>>> <https://dl.acm.org/doi/10.1145/3426744.3431329;> >>>>>>>>> <https://dl.acm.org/doi/10.1145/3426744.3431329;> >>>>>>>>> <https://dl.acm.org/doi/10.1145/3426744.3431329;> >>>>>>>>> <https://dl.acm.org/doi/10.1145/3426744.3431329;> >>>>>>>>> <https://dl.acm.org/doi/10.1145/3426744.3431329;> >>>>>>>>> <https://dl.acm.org/doi/10.1145/3426744.3431329;> >>>>>>>>> >>>>>>>>> >>>>>>>>> b) For [SA2-5GLAN], the URL provided returns a "403 - Forbidden" >>>>>>>>> error. We were unable to find an alternative source for this >>>>>>>>> reference. Please review and let us know how to update. >>>>>>>>> >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> [SA2-5GLAN] >>>>>>>>> 3GPP-5glan, "SP-181129, Work Item Description, >>>>>>>>> Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and >>>>>>>>> LAN Services", 3GPP , 2021, >>>>>>>>> <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP- >>>>>>>>> <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-> >>>>>>>>> <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-> >>>>>>>>> <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-;> >>>>>>>>> <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-> >>>>>>>>> <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-;> >>>>>>>>> <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-;> >>>>>>>>> <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-;> >>>>>>>>> <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-> >>>>>>>>> <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-;> >>>>>>>>> <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-;> >>>>>>>>> <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-;> >>>>>>>>> <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-;> >>>>>>>>> <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-;> >>>>>>>>> <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-;> >>>>>>>>> <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-;> >>>>>>>>> 181120.zip>. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 26) <!--[rfced] We see that draft-trossen-icnrg-ip-icn-5glan >>>>>>>>> was replaced by draft-trossen-icnrg-internet-icn-5glan. Would you >>>>>>>>> like this reference to be updated to the latter? >>>>>>>>> >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> [ICN-5GLAN] >>>>>>>>> Trossen, D., Wang, C., Robitzsch, S., Reed, M., AL-Naday, >>>>>>>>> M., and J. Riihijarvi, "IP-based Services over ICN in 5G >>>>>>>>> LAN Environments", Work in Progress, Internet-Draft, >>>>>>>>> draft-trossen-icnrg-ip-icn-5glan-00, 6 June 2019, >>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-trossen- >>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-trossen-> >>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-trossen-> >>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-trossen->> >>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-trossen-> >>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-trossen->> >>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-trossen->> >>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-trossen-&gt;>> >>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-trossen-> >>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-trossen->> >>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-trossen->> >>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-trossen-&gt;>> >>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-trossen->> >>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-trossen-&gt;>> >>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-trossen-&gt;>> >>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-trossen-&amp;gt;&gt;>> >>>>>>>>> icnrg-ip-icn-5glan-00>. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 27) <!-- [rfced] Terminology and Abbreviations: >>>>>>>>> >>>>>>>>> >>>>>>>>> a) We note different uses of (COIN) and COIN in the terms below. >>>>>>>>> For consistency and ease of the reader, we suggest removing the >>>>>>>>> parentheses in "(COIN)" when it appears in these instances. Please >>>>>>>>> review >>>>>>>>> and let us know any objections. >>>>>>>>> >>>>>>>>> >>>>>>>>> (COIN) execution environment >>>>>>>>> (COIN) system >>>>>>>>> (COIN) programs >>>>>>>>> (COIN) program instances >>>>>>>>> >>>>>>>>> >>>>>>>>> COIN execution environment >>>>>>>>> COIN system >>>>>>>>> COIN programs >>>>>>>>> COIN program instances >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> b) In general, is there is a specific meaning that is intended when >>>>>>>>> "COIN" >>>>>>>>> is in parentheses? If so, could you add a sentence to define that >>>>>>>>> meaning? For example, why is COIN in parentheses in this text? >>>>>>>>> >>>>>>>>> >>>>>>>>> Section 3.1.2: >>>>>>>>> However, the execution of a (COIN) program may be moved to other >>>>>>>>> (e.g., more suitable) devices, including PNDs, which have exposed the >>>>>>>>> corresponding (COIN) program as individual (COIN) program instances >>>>>>>>> to the (COIN) system by means of a 'service identifier'. >>>>>>>>> >>>>>>>>> >>>>>>>>> We note this convention was also used in >>>>>>>>> draft-irtf-coinrg-coin-terminology >>>>>>>>> (now expired), but it does not seem to be explained. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> c) How should 'CN' be expanded here? >>>>>>>>> >>>>>>>>> >>>>>>>>> Works such as those in [SILKROAD] utilize ASICs to replace >>>>>>>>> server-based >>>>>>>>> load balancing with significant cost reductions, thus showcasing the >>>>>>>>> potential for in-network CN operations. >>>>>>>>> >>>>>>>>> >>>>>>>>> d) FYI, we added expansions for the following abbreviations upon >>>>>>>>> first use. >>>>>>>>> Please review each expansion in the document carefully to ensure >>>>>>>>> correctness. >>>>>>>>> >>>>>>>>> >>>>>>>>> Application-Specific Integrated Circuit (ASIC) >>>>>>>>> Graphics Processing Units (GPUs) >>>>>>>>> Information-Centric Network (ICN) >>>>>>>>> Internet of Things (IoT) >>>>>>>>> Java Virtual Machine (JVM) >>>>>>>>> Message Passing Interface (MPI) >>>>>>>>> Quality of Experience (QoE) >>>>>>>>> Remote Direct Memory Access (RDMA) >>>>>>>>> Software-Defined Network (SDN) >>>>>>>>> Standards Development Organization (SDO) >>>>>>>>> User Plane Function (UPF) >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 28) <!-- [rfced] Please review the "Inclusive Language" portion of >>>>>>>>> the online >>>>>>>>> Style Guide >>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language;> >>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language;> >>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language;> >>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language;> >>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language;> >>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language;> >>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language;> >>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>> >>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>> >>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>> >>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>> >>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>> >>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>> >>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>> >>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>> >>>>>>>>> and let us know if any changes are needed. Updates of this nature >>>>>>>>> typically >>>>>>>>> result in more precise language, which is helpful for readers. >>>>>>>>> >>>>>>>>> >>>>>>>>> a) For example, please consider whether "native" should be updated >>>>>>>>> here: >>>>>>>>> >>>>>>>>> >>>>>>>>> so-called 'cloud-native' applications for applications developed >>>>>>>>> >>>>>>>>> >>>>>>>>> b) In addition, please consider whether instances of "traditional" >>>>>>>>> and "traditionally" should be updated for clarity. While the NIST >>>>>>>>> website >>>>>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> >>>>>>>>> >>>>>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1;> >>>>>>>>> >>>>>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1;> >>>>>>>>> >>>>>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1;> >>>>>>>>> >>>>>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1;> >>>>>>>>> >>>>>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1;> >>>>>>>>> >>>>>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1;> >>>>>>>>> >>>>>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1;> >>>>>>>>> >>>>>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>> >>>>>>>>> >>>>>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>> >>>>>>>>> >>>>>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>> >>>>>>>>> >>>>>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>> >>>>>>>>> >>>>>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>> >>>>>>>>> >>>>>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>> >>>>>>>>> >>>>>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>> >>>>>>>>> >>>>>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>> >>>>>>>>> indicates that this term is potentially biased, it is also ambiguous. >>>>>>>>> "Tradition" is a subjective term, as it is not the same for everyone. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you. >>>>>>>>> >>>>>>>>> >>>>>>>>> RFC Editor/kf/ar >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Jul 14, 2025, rfc-edi...@rfc-editor.org >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org> <mailto:rfc-edi...@rfc-editor.org >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org>> <mailto:rfc-edi...@rfc-editor.org >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org> <mailto:rfc-edi...@rfc-editor.org >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org>>> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> *****IMPORTANT***** >>>>>>>>> >>>>>>>>> >>>>>>>>> Updated 2025/07/14 >>>>>>>>> >>>>>>>>> >>>>>>>>> RFC Author(s): >>>>>>>>> -------------- >>>>>>>>> >>>>>>>>> >>>>>>>>> Instructions for Completing AUTH48 >>>>>>>>> >>>>>>>>> >>>>>>>>> Your document has now entered AUTH48. Once it has been reviewed and >>>>>>>>> approved by you and all coauthors, it will be published as an RFC. >>>>>>>>> If an author is no longer available, there are several remedies >>>>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/ >>>>>>>>> <https://www.rfc-editor.org/faq/> <https://www.rfc-editor.org/faq/> >>>>>>>>> <https://www.rfc-editor.org/faq/;> <https://www.rfc-editor.org/faq/> >>>>>>>>> <https://www.rfc-editor.org/faq/;> <https://www.rfc-editor.org/faq/;> >>>>>>>>> <https://www.rfc-editor.org/faq/;> <https://www.rfc-editor.org/faq/> >>>>>>>>> <https://www.rfc-editor.org/faq/;> <https://www.rfc-editor.org/faq/;> >>>>>>>>> <https://www.rfc-editor.org/faq/;> <https://www.rfc-editor.org/faq/;> >>>>>>>>> <https://www.rfc-editor.org/faq/;> <https://www.rfc-editor.org/faq/;> >>>>>>>>> <https://www.rfc-editor.org/faq/;>). >>>>>>>>> >>>>>>>>> >>>>>>>>> You and you coauthors are responsible for engaging other parties >>>>>>>>> (e.g., Contributors or Working Group) as necessary before providing >>>>>>>>> your approval. >>>>>>>>> >>>>>>>>> >>>>>>>>> Planning your review >>>>>>>>> --------------------- >>>>>>>>> >>>>>>>>> >>>>>>>>> Please review the following aspects of your document: >>>>>>>>> >>>>>>>>> >>>>>>>>> * RFC Editor questions >>>>>>>>> >>>>>>>>> >>>>>>>>> Please review and resolve any questions raised by the RFC Editor >>>>>>>>> that have been included in the XML file as comments marked as >>>>>>>>> follows: >>>>>>>>> >>>>>>>>> >>>>>>>>> <!-- [rfced] ... --> >>>>>>>>> >>>>>>>>> >>>>>>>>> These questions will also be sent in a subsequent email. >>>>>>>>> >>>>>>>>> >>>>>>>>> * Changes submitted by coauthors >>>>>>>>> >>>>>>>>> >>>>>>>>> Please ensure that you review any changes submitted by your >>>>>>>>> coauthors. We assume that if you do not speak up that you >>>>>>>>> agree to changes submitted by your coauthors. >>>>>>>>> >>>>>>>>> >>>>>>>>> * Content >>>>>>>>> >>>>>>>>> >>>>>>>>> Please review the full content of the document, as this cannot >>>>>>>>> change once the RFC is published. Please pay particular attention to: >>>>>>>>> - IANA considerations updates (if applicable) >>>>>>>>> - contact information >>>>>>>>> - references >>>>>>>>> >>>>>>>>> >>>>>>>>> * Copyright notices and legends >>>>>>>>> >>>>>>>>> >>>>>>>>> Please review the copyright notice and legends as defined in >>>>>>>>> RFC 5378 and the Trust Legal Provisions >>>>>>>>> (TLP – https://trustee.ietf.org/license-info >>>>>>>>> <https://trustee.ietf.org/license-info> >>>>>>>>> <https://trustee.ietf.org/license-info> >>>>>>>>> <https://trustee.ietf.org/license-info>> >>>>>>>>> <https://trustee.ietf.org/license-info> >>>>>>>>> <https://trustee.ietf.org/license-info>> >>>>>>>>> <https://trustee.ietf.org/license-info>> >>>>>>>>> <https://trustee.ietf.org/license-info&gt;>> >>>>>>>>> <https://trustee.ietf.org/license-info> >>>>>>>>> <https://trustee.ietf.org/license-info>> >>>>>>>>> <https://trustee.ietf.org/license-info>> >>>>>>>>> <https://trustee.ietf.org/license-info&gt;>> >>>>>>>>> <https://trustee.ietf.org/license-info>> >>>>>>>>> <https://trustee.ietf.org/license-info&gt;>> >>>>>>>>> <https://trustee.ietf.org/license-info&gt;>> >>>>>>>>> <https://trustee.ietf.org/license-info&amp;gt;&gt;>>). >>>>>>>>> >>>>>>>>> >>>>>>>>> * Semantic markup >>>>>>>>> >>>>>>>>> >>>>>>>>> Please review the markup in the XML file to ensure that elements of >>>>>>>>> content are correctly tagged. For example, ensure that <sourcecode> >>>>>>>>> and <artwork> are set correctly. See details at >>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary> >>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>> >>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>> >>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary&gt;>> >>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>> >>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary&gt;>> >>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary&gt;>> >>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary&amp;gt;&gt;>> >>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>> >>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary&gt;>> >>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary&gt;>> >>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary&amp;gt;&gt;>> >>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary&gt;>> >>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary&amp;gt;&gt;>> >>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary&amp;gt;&gt;>> >>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary&amp;amp;gt;&amp;gt;&gt;>>. >>>>>>>>> >>>>>>>>> >>>>>>>>> * Formatted output >>>>>>>>> >>>>>>>>> >>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>>>>>> formatted output, as generated from the markup in the XML file, is >>>>>>>>> reasonable. Please note that the TXT will have formatting >>>>>>>>> limitations compared to the PDF and HTML. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Submitting changes >>>>>>>>> ------------------ >>>>>>>>> >>>>>>>>> >>>>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>>>>>>> the parties CCed on this message need to see your changes. The parties >>>>>>>>> include: >>>>>>>>> >>>>>>>>> >>>>>>>>> * your coauthors >>>>>>>>> >>>>>>>>> >>>>>>>>> * rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org>>> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org >>>>>>>>> <mailto:rfc-edi...@rfc-editor.org>>>> (the RPC team) >>>>>>>>> >>>>>>>>> >>>>>>>>> * other document participants, depending on the stream (e.g., >>>>>>>>> IETF Stream participants are your working group chairs, the >>>>>>>>> responsible ADs, and the document shepherd). >>>>>>>>> >>>>>>>>> >>>>>>>>> * auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org> >>>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>>> <mailto:auth48archive@rfc-editor.org>> >>>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>>> <mailto:auth48archive@rfc-editor.org> >>>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>>> <mailto:auth48archive@rfc-editor.org>>> >>>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>>> <mailto:auth48archive@rfc-editor.org> >>>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>>> <mailto:auth48archive@rfc-editor.org>> >>>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>>> <mailto:auth48archive@rfc-editor.org> >>>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>>> <mailto:auth48archive@rfc-editor.org>>>>, which is a new archival >>>>>>>>> mailing list >>>>>>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>>>>>> list: >>>>>>>>> >>>>>>>>> >>>>>>>>> * More info: >>>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc<https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc> >>>>>>>>> >>>>>>>>> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc<https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc>> >>>>>>>>> >>>>>>>>> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc<https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc>> >>>>>>>>> >>>>>>>>> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc&lt;https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc&gt;>> >>>>>>>>> >>>>>>>>> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc<https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc>> >>>>>>>>> >>>>>>>>> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc&lt;https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc&gt;>> >>>>>>>>> >>>>>>>>> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc&lt;https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc&gt;>> >>>>>>>>> >>>>>>>>> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc&amp;lt;https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc&amp;gt;&gt;>> >>>>>>>>> >>>>>>>>> >>>>>>>>> * The archive itself: >>>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/<https://mailarchive.ietf.org/arch/browse/auth48archive/> >>>>>>>>> >>>>>>>>> <https://mailarchive.ietf.org/arch/browse/auth48archive/<https://mailarchive.ietf.org/arch/browse/auth48archive/>> >>>>>>>>> >>>>>>>>> <https://mailarchive.ietf.org/arch/browse/auth48archive/<https://mailarchive.ietf.org/arch/browse/auth48archive/>> >>>>>>>>> >>>>>>>>> <https://mailarchive.ietf.org/arch/browse/auth48archive/&lt;https://mailarchive.ietf.org/arch/browse/auth48archive/&gt;>> >>>>>>>>> >>>>>>>>> <https://mailarchive.ietf.org/arch/browse/auth48archive/<https://mailarchive.ietf.org/arch/browse/auth48archive/>> >>>>>>>>> >>>>>>>>> <https://mailarchive.ietf.org/arch/browse/auth48archive/&lt;https://mailarchive.ietf.org/arch/browse/auth48archive/&gt;>> >>>>>>>>> >>>>>>>>> <https://mailarchive.ietf.org/arch/browse/auth48archive/&lt;https://mailarchive.ietf.org/arch/browse/auth48archive/&gt;>> >>>>>>>>> >>>>>>>>> <https://mailarchive.ietf.org/arch/browse/auth48archive/&amp;lt;https://mailarchive.ietf.org/arch/browse/auth48archive/&amp;gt;&gt;>> >>>>>>>>> >>>>>>>>> >>>>>>>>> * Note: If only absolutely necessary, you may temporarily opt out >>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>>>>>>> If needed, please add a note at the top of the message that you >>>>>>>>> have dropped the address. When the discussion is concluded, >>>>>>>>> auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org> >>>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>>> <mailto:auth48archive@rfc-editor.org>> >>>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>>> <mailto:auth48archive@rfc-editor.org> >>>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>>> <mailto:auth48archive@rfc-editor.org>>> >>>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>>> <mailto:auth48archive@rfc-editor.org> >>>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>>> <mailto:auth48archive@rfc-editor.org>> >>>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>>> <mailto:auth48archive@rfc-editor.org> >>>>>>>>> <mailto:auth48archive@rfc-editor.org >>>>>>>>> <mailto:auth48archive@rfc-editor.org>>>> will be re-added to the CC >>>>>>>>> list and >>>>>>>>> its addition will be noted at the top of the message. >>>>>>>>> >>>>>>>>> >>>>>>>>> You may submit your changes in one of two ways: >>>>>>>>> >>>>>>>>> >>>>>>>>> An update to the provided XML file >>>>>>>>> — OR — >>>>>>>>> An explicit list of changes in this format >>>>>>>>> >>>>>>>>> >>>>>>>>> Section # (or indicate Global) >>>>>>>>> >>>>>>>>> >>>>>>>>> OLD: >>>>>>>>> old text >>>>>>>>> >>>>>>>>> >>>>>>>>> NEW: >>>>>>>>> new text >>>>>>>>> >>>>>>>>> >>>>>>>>> You do not need to reply with both an updated XML file and an explicit >>>>>>>>> list of changes, as either form is sufficient. >>>>>>>>> >>>>>>>>> >>>>>>>>> We will ask a stream manager to review and approve any changes that >>>>>>>>> seem >>>>>>>>> beyond editorial in nature, e.g., addition of new text, deletion of >>>>>>>>> text, >>>>>>>>> and technical changes. Information about stream managers can be found >>>>>>>>> in >>>>>>>>> the FAQ. Editorial changes do not require approval from a stream >>>>>>>>> manager. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Approving for publication >>>>>>>>> -------------------------- >>>>>>>>> >>>>>>>>> >>>>>>>>> To approve your RFC for publication, please reply to this email >>>>>>>>> stating >>>>>>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>>>>>>> as all the parties CCed on this message need to see your approval. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Files >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> >>>>>>>>> The files are available here: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9817.xml<https://www.rfc-editor.org/authors/rfc9817.xml> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.xml;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.xml;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.xml;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.xml;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.xml;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.xml;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.xml;> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9817.html<https://www.rfc-editor.org/authors/rfc9817.html> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.html;> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9817.pdf<https://www.rfc-editor.org/authors/rfc9817.pdf> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.pdf;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.pdf;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.pdf;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.pdf;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.pdf;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.pdf;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.pdf;> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9817.txt<https://www.rfc-editor.org/authors/rfc9817.txt> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.txt;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.txt;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.txt;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.txt;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.txt;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.txt;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817.txt;> >>>>>>>>> >>>>>>>>> >>>>>>>>> Diff file of the text: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9817-diff.html >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-diff.html;> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9817-rfcdiff.html >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-rfcdiff.html> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-rfcdiff.html> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-rfcdiff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-rfcdiff.html> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-rfcdiff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-rfcdiff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-rfcdiff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-rfcdiff.html> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-rfcdiff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-rfcdiff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-rfcdiff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-rfcdiff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-rfcdiff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-rfcdiff.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-rfcdiff.html;> (side by >>>>>>>>> side) >>>>>>>>> >>>>>>>>> >>>>>>>>> Diff of the XML: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9817-xmldiff1.html >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-xmldiff1.html> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-xmldiff1.html> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-xmldiff1.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-xmldiff1.html> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-xmldiff1.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-xmldiff1.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-xmldiff1.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-xmldiff1.html> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-xmldiff1.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-xmldiff1.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-xmldiff1.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-xmldiff1.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-xmldiff1.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-xmldiff1.html;> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9817-xmldiff1.html;> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Tracking progress >>>>>>>>> ----------------- >>>>>>>>> >>>>>>>>> >>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>> https://www.rfc-editor.org/auth48/rfc9817<https://www.rfc-editor.org/auth48/rfc9817> >>>>>>>>> <https://www.rfc-editor.org/auth48/rfc9817;> >>>>>>>>> <https://www.rfc-editor.org/auth48/rfc9817;> >>>>>>>>> <https://www.rfc-editor.org/auth48/rfc9817;> >>>>>>>>> <https://www.rfc-editor.org/auth48/rfc9817;> >>>>>>>>> <https://www.rfc-editor.org/auth48/rfc9817;> >>>>>>>>> <https://www.rfc-editor.org/auth48/rfc9817;> >>>>>>>>> <https://www.rfc-editor.org/auth48/rfc9817;> >>>>>>>>> >>>>>>>>> >>>>>>>>> Please let us know if you have any questions. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you for your cooperation, >>>>>>>>> >>>>>>>>> >>>>>>>>> RFC Editor >>>>>>>>> >>>>>>>>> >>>>>>>>> -------------------------------------- >>>>>>>>> RFC9817 (draft-irtf-coinrg-use-cases-07) >>>>>>>>> >>>>>>>>> >>>>>>>>> Title : Use Cases for In-Network Computing >>>>>>>>> Author(s) : I. Kunze, K. Wehrle, D. Trossen, M.-J. Montpetit, X. de >>>>>>>>> Foy, D. Griffin, M. Rio >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> <rfc9817.xml> >>>> >>> >>> >>> >>> >>> >>> Media Over Wireless: Networks for Ubiquitous Video This e-mail is intended >>> only for the use of the individual or entity to which it is addressed, and >>> may contain information that is privileged, confidential and/or otherwise >>> protected from disclosure to anyone other than its intended recipient. >>> Unintended transmission shall not constitute waiver of any privilege or >>> confidentiality obligation. If you received this communication in error, >>> please do not review, copy or distribute it, notify me immediately by >>> email, and delete the original message and any attachments. Unless >>> expressly stated in this e-mail, nothing in this message or any attachment >>> should be construed as a digital or electronic signature. >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
