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. --> 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. --> 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 Perhaps: 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- 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- 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> 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> 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 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/). 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). * 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>. * 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 (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, 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 * The archive itself: 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 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.html https://www.rfc-editor.org/authors/rfc9817.pdf 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-rfcdiff.html (side by side) Diff of the XML: 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 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
