Dear RFC Editor, considering the already mentioned changes by the co-authors, I approve this RFC for publication. No further change requests from my side.
Best Regards klaus > Am 15.07.2025 um 03:16 schrieb rfc-edi...@rfc-editor.org: > > 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
