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.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) The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9817 Thank you, RFC Editor/kf > On Jul 16, 2025, at 5:41 AM, Rio, Miguel <miguel....@ucl.ac.uk> wrote: > > Hi all, > I approve this RFC for publication. > Miguel > From: Griffin, David <d.grif...@ucl.ac.uk> > Date: Wednesday, 16 July 2025 at 10:39 > To: Kunze, Ike <ike.ku...@comsys.rwth-aachen.de>, rfc-edi...@rfc-editor.org > <rfc-edi...@rfc-editor.org>, Wehrle, Klaus <kl...@comsys.rwth-aachen.de>, > marie-jose.montpe...@mcgill.ca <marie-jose.montpe...@mcgill.ca>, > xavier.de...@interdigital.com<xavier.de...@interdigital.com>, Rio, Miguel > <miguel....@ucl.ac.uk>, d...@dapadot-tech.eu <d...@dapadot-tech.eu> > Cc: i...@irtf.org <i...@irtf.org>, je...@foxmail.com <je...@foxmail.com>, > auth48archive@rfc-editor.org <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>" <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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fsearch&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730088362%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CQT6ArQ%2FpDeXrHYd%2FSizHUsn%2FQ%2BU1xHZUtoUOX1hpOM%3D&reserved=0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fsearch&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730134262%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=SEcF1mGGDnWOke0NzbwZQnkA%2FMPBqijBqS0h2XNEoqs%3D&reserved=0>. >> --> >> >> >> >> >> 2) <!-- [rfced] Please ensure that the guidelines listed in Section 2.1 of >> RFC 5743 have been adhered to in this document. See >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc5743.html%23section-2.1&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730166639%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IRPEHiUxKNkd242ry%2Fp3k4YAnoYGVRV2L%2BTut%2Frq07I%3D&reserved=0 >> >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc5743.html%23section-2.1&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730196451%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=onJnUIxZE3V1Gbj3moFuG2xI1zFilcxkffwlsPSpewE%3D&reserved=0>. >> --> >> >> >> >> >> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.ox.ac.uk%2Fmedia%2F6354%2Fstoyanov2020mtpsa.pdf&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730230825%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=upYqLvCxYm4qB5r6eb2fOMsrogoJHjRTf6XiVzd3pF8%3D&reserved=0 >> >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.ox.ac.uk%2Fmedia%2F6354%2Fstoyanov2020mtpsa.pdf&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730260251%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=d4dPsQ%2FUefuWafsNqzpSX2hJBh7iZ%2FUKjyVVSqPEn%2Fo%3D&reserved=0> >> Perhaps: >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdl.acm.org%2Fdoi%2F10.1145%2F3426744.3431329&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730305556%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=i1cO%2B2mrNe%2FH7NMoAsBplXsOHX1ZeMMLnh1KUqbT41U%3D&reserved=0 >> >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdl.acm.org%2Fdoi%2F10.1145%2F3426744.3431329&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730336309%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=r9ucPAsDc796vD9Zo4nQgYVdg6dl8S3qWZNst0CduEs%3D&reserved=0> >> >> >> 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, >> <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.3gpp.org%2Fftp%2Ftsg_sa%2FTSG_SA%2FDocs%2FSP-&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730366926%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=L%2FOndgrzd5BNoqa9n59BtcwRA168b7%2F0%2FlzT6j8EQbg%3D&reserved=0 >> >> <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.3gpp.org%2Fftp%2Ftsg_sa%2FTSG_SA%2FDocs%2FSP-&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730396155%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UBR9odbtafy8F0rspA%2BrjSQDjzoXVj4TLS2OjipzV3M%3D&reserved=0> >> 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-> >> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730425811%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=kYXy0ks7zUpb%2BF%2BSeE2L80BKOG81HEZi1b7KfZstXAk%3D&reserved=0> >> >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language%26gt&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730477961%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=G4VBsmj5Bhor4b9EBc9htCFmUxeGp%2BsJtnY0dsx6igs%3D&reserved=0;> >> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20250214092458%2Fhttps%3A%2F%2Fwww.nist.gov%2Fnist-research-library%2Fnist-technical-series-publications-author-instructions%23table1&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730536342%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=acVf4ciQ7dDv0sIlZDX59nUMcZKfUzD3ldUlHvdGLYw%3D&reserved=0> >> >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20250214092458%2Fhttps%3A%2F%2Fwww.nist.gov%2Fnist-research-library%2Fnist-technical-series-publications-author-instructions%23table1%26gt&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730600716%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9aBQCkz1Hirlmdc2alNKXkpbecvhrXfeSX6zbz9TMY0%3D&reserved=0;> >> 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> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730643396%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dEDHWzlANJ2YzSrLCNCsY6eofHMMljDj1U9KMC56duA%3D&reserved=0 >> >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730681539%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=C%2BK7aliYwnUyra52HUy%2BsGFkVPNFlZVqKOFJHAAbvVQ%3D&reserved=0>). >> >> >> 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>). >> >> >> * 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>>. >> >> >> * 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> (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>, 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> >> >> >> * The archive itself: >> https://mailarchive.ietf.org/arch/browse/auth48archive/<https://mailarchive.ietf.org/arch/browse/auth48archive/> >> >> >> * 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> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9817.xml&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730715784%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2tj7lKEWdLKbSyvl5uBh8bUFWMO%2F5yG2x0J3RogAlxU%3D&reserved=0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9817.xml&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730761467%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pDeoJMYLj9buJudBkGJZ7TpRMHYV6GelV4wHanBUTps%3D&reserved=0> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9817.html&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730800808%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vFyvBHUoALodegXLB3CHU35aX8z2ESldHqz8Vi%2BAZGI%3D&reserved=0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9817.html&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730858417%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=42o2J6jGwO1NlUmD1mNXjBUFCq%2FpzqtrsczG2FhEyrI%3D&reserved=0> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9817.pdf&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730904724%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=PMSEd32%2FX8MM53nkgFhWTudgWyaX%2FkT848jA3jJQ7hc%3D&reserved=0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9817.pdf&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730945169%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qUZ9FVhDBXST0JZZCb09Wt0wikO42NIm4Cqv8LpQtBE%3D&reserved=0> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9817.txt&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555730984166%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MvfBkgEXheL%2FiIBApLbs9w8j1rfE2i2Eysg3to8dYCo%3D&reserved=0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9817.txt&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555731032204%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=O7mnKj10ZqRyWH42rZrOPeEk9A1svQzwjI6med4lTpw%3D&reserved=0> >> >> >> Diff file of the text: >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9817-diff.html&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555731079308%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=a0r6Lnj%2FETN%2FNTkg8MwqHlVMYPkAdfHnCQibP9ECU8A%3D&reserved=0 >> >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9817-diff.html&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555731126513%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2B1C0IUIjx4MSLDMu39kbn0EXpXQyfTKF1SHxzIwdV%2FI%3D&reserved=0> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9817-rfcdiff.html&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555731177489%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CgKezKWWX8BtSbvVUGGNeU31tApnsswMOEDtvlutaQs%3D&reserved=0 >> >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9817-rfcdiff.html&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555731222320%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RHDzFjSbJ1zYA530V3qN%2B59sVzt49UZBskhOUF0e7Qc%3D&reserved=0> >> (side by side) >> >> >> Diff of the XML: >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9817-xmldiff1.html&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555731301110%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FbwyNbwrdmiE392NbgbzeCooF4prF5GXSzCdUYAwm2E%3D&reserved=0 >> >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9817-xmldiff1.html&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555731351585%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=PAUByU3sHLNQagR%2B6e1ZO3xAYcWjtVFjCYm4yr2FGGk%3D&reserved=0> >> >> >> >> >> Tracking progress >> ----------------- >> >> >> The details of the AUTH48 status of your document are here: >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9817&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555731390447%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=adqhfFFwH8pDkKKt%2BjU8hfgyC6CEvAo7IxCf20babB0%3D&reserved=0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9817&data=05%7C02%7Cmiguel.rio%40ucl.ac.uk%7C83e41b10a6e542a4d2a008ddc44ca9e8%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C638882555731423149%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=j%2FXWtuMvdIKwOox%2F5eAzo61keyoHGe0PhjOWJYiVMaA%3D&reserved=0> >> >> >> 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 >> >> >> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
