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://www.rfc-editor.org/search
<https://www.rfc-editor.org/search>. -->
2) <!-- [rfced] Please ensure that the guidelines listed in Section 2.1 of
RFC 5743 have been adhered to in this document. See
https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1
<https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1>.
-->
3) <!-- [rfced] May we make this into two sentences as follows for ease of
the reader? Also, would you like to change the adjective "compute intensive"
to "CPU-intensive", which is used later in this document?
Original:
Once this application is partitioned into its constituent (COIN)
programs and deployed throughout a COIN system, utilizing a COIN
execution environment, only the "display" (COIN) program may be left
in the headset, while the compute intensive real-time VR content
processing (COIN) program can be offloaded to a nearby resource rich
home PC or a programmable network device (PND) in the operator's
access network, for a better execution (faster and possibly higher
resolution generation).
Perhaps:
Once this application is partitioned into its constituent (COIN)
programs and deployed throughout a COIN system utilizing a COIN
execution environment, only the display (COIN) program may be left in
the headset. Meanwhile, the CPU-intensive real-time VR content
processing (COIN) program can be offloaded to a nearby resource rich
home PC or a Programmable Network Device (PND) in the operator's
access network for a better execution (i.e., faster and possibly higher
resolution generation).
-->
4) <!-- [rfced] How may we update the following text to clarify the
relationship between the "result" and the phrases that follow?
Original:
The result is the equivalent to 'mobile function offloading', for possible
reduction of power consumption (e.g., offloading CPU intensive process
functions to a remote server) or for improved end user experience (e.g.,
moving display functions to a nearby smart TV) by selecting more suitably
placed (COIN) program instances in the overall (COIN) system.
Option A:
The result is the equivalent to mobile function offloading, in that it
offers the possible reduction of power consumption (e.g., offloading CPU-
intensive process functions to a remote server) or offers an improved
end-user experience (e.g., moving display functions to a nearby smart TV)
by selecting more suitably placed (COIN) program instances in the overall
(COIN) system.
Option B (if *both* reducing power consumption and improving the end-user
experience are due to selecting more suitably placed program instances):
The result is the equivalent to mobile function offloading because, by
selecting more suitably placed (COIN) program instances in the overall
(COIN) system, it offers a potential reduction of power consumption (e.g.,
offloading CPU-intensive process functions to a remote server) or an
improved end-user experience (e.g., moving display functions to a nearby
smart TV).
-->
5) <!-- [rfced] We note that the reference [ETSI] uses "Multi-access Edge
Computing (MEC)" rather than "Mobile Edge Computing (MEC)" as seen in the
text below. May we update this sentence accordingly?
Original:
The ETSI Mobile Edge Computing (MEC) [ETSI] suite of technologies
provides solutions...
Perhaps:
The ETSI Multi-access Edge Computing (MEC) [ETSI] suite of technologies
provides solutions...
-->
6) <!-- [rfced] Please clarify this sentence, especially "rather than".
Original:
Also, the ETSI work does not allow for the
dynamic selection and redirection of (COIN) program calls to varying
edge resources rather than a single MEC application server.
Option A:
Also, the ETSI work does not allow for the
dynamic selection and redirection of (COIN) program calls to varying
edge resources; it does allow for them to a single MEC application server.
Option B (stating the reverse):
Also, the ETSI work allows for the dynamic selection and
redirection of (COIN) program calls to only a single MEC application
server, not to varying edge resources.
-->
7) <!-- [rfced] Seems a closing parenthesis was missing on "(service routing
in [APPCENTRES]...". We added it; please review.
Original:
* The support for service-level routing of requests (service routing
in [APPCENTRES] may support higher flexibility when switching from
one (COIN) program instance to another, e.g., due to changing
constraints for selecting the new (COIN) program instance. Here,
PNDs may support service routing solutions by acting as routing
overlay nodes to implement the necessary additional lookup
functionality and also possibly support the handling of affinity
relations, i.e., the forwarding of one packet to the destination
of a previous one due to a higher level service relation, as
discussed and described in [SarNet2021].
Current:
* The support for service-level routing of requests (such as service
routing in [APPCENTRES]) may support higher flexibility when switching
from one (COIN) program instance to another (e.g., due to changing
constraints for selecting the new (COIN) program instance). Here, PNDs
may support service routing solutions by acting as routing overlay nodes
to implement the necessary additional lookup functionality and also
possibly support the handling of affinity relations (i.e., the
forwarding of one packet to the destination of a previous one due to a
higher level service relation as discussed and described in
[SarNet2021]).
-->
8) <!-- [rfced] FYI, for readability, we made this into two sentences at
"that can benefit". Please review.
Original:
XR is one example of the multisource-
multidestination problem that combines video and haptics in
interactive multi-party interactions under strict delay requirements
that can benefit from a functional distribution that includes fog
computing for local information processing, the edge for aggregation,
and the cloud for image processing.
Current:
XR is one example of the multisource-
multidestination problem that combines video and haptics in
interactive multiparty interactions under strict delay requirements.
As such, XR can benefit from a functional distribution that includes
fog computing for local information processing, the edge for
aggregation, and the cloud for image processing.
-->
9) <!-- [rfced] Should "re-rerouting" be updated to "re-routing" here?
Original:
More importantly, COIN can enable collaborative XR experiences, where
multiple users interact in the same virtual space in real-time, regardless
of their physical locations, by allowing resource discovery and
re-rerouting of XR streams.
Perhaps:
More importantly, COIN can enable collaborative XR experiences, where
multiple users interact in the same virtual space in real time, regardless
of their physical locations, by allowing resource discovery and
re-routing of XR streams.
-->
10) <!-- [rfced] For clarity, may we update "not networked or distributed"
in the text below to be more descriptive?
Original:
Hence, implementing such XR solutions necessitates substantial
computational power and minimal latency, which, for now, has spurred the
development of better headsets not networked or distributed solutions as
factors like distance from cloud servers and limited bandwidth can still
significantly lower application responsiveness.
Perhaps:
Hence, implementing such XR solutions necessitates substantial
computational power and minimal latency, which, for now, has spurred the
development of better headsets, rather than spurring networked or
distributed solutions, as factors like distance from cloud servers and
limited bandwidth can still significantly lower application responsiveness.
-->
11) <!-- [rfced] We have added additional punctuation to the text below. Please
review these updates and confirm that they do not change your intended
meaning.
Original:
Information Centric Networking (and related) approaches that combine
publish subscribe and distributed storage are also very suited for the
multisource-multidestination applications of XR.
Current:
Information-centric networking (and related) approaches that combine,
publish, subscribe, and distribute storage are also very suited for
the multisource-multidestination applications of XR.
-->
12) <!-- [rfced] For clarity, may we change 'the discovery of' to 'discovering'?
This makes the action parallel with 'using' (in other words,
'they include discovering X and using them to do Y').
Original:
Mechanisms aimed at enhancing the computational and storage capacities of
mobile devices could also improve XR capabilities as they include the
discovery of available servers within the environment and using them
opportunistically to enhance the performance of interactive applications
and distributed file systems.
Perhaps:
Mechanisms aimed at enhancing the computational and storage capacities of
mobile devices could also improve XR capabilities, as they include
discovering available servers within the environment and using them
opportunistically to enhance the performance of interactive applications
and distributed file systems.
-->
13) <!-- [rfced] Would "federating systems capabilities" be more clear as
"the federation of systems capabilities" here?
Original:
Yet, there are still very few interactive immersive media applications
over networks that allow for federating systems capabilities.
Perhaps:
Yet, there are still very few interactive immersive media applications
over networks that allow for the federation of systems capabilities.
-->
14) <!-- [rfced] For readability and clarity of RQ 3.2.3
a) Is this about two separate research questions ("the use of distributed AI"
and "the creation of semi-permanent datasets")? May they be two separate
sentences?
b) May we adjust "resulting in" to "result in" to add a clear verb to the
second half of this text?
Original:
* RQ 3.2.3: Can the use of distributed AI algorithms across both
data center and edge computers be leveraged for creating optimal
function allocation and the creation of semi-permanent datasets
and analytics for usage trending and flow management resulting in
better localization of XR functions?
Perhaps:
* RQ 3.2.3: Can the use of distributed AI algorithms across both
data center and edge computers be leveraged for creating optimal
function allocation? Can the creation of semi-permanent datasets
and analytics for usage trending and flow management result in
better localization of XR functions?
-->
15) <!-- [rfced] For ease of the reader, may we break this one sentence into
two?
In addition, may we update the verb "optimize" to "optimizing" as follows?
Original:
* RQ 3.2.4: Can COIN improve the dynamic distribution of control,
forwarding, and storage resources and related usage models in XR,
such as to integrate local and fog caching with cloud-based pre-
rendering, thus jointly optimizing COIN and higher layer protocols
to reduce latency and, more generally, manage the quality of XR
sessions, e.g., through reduced in-network congestion and improved
flow delivery by determining how to prioritize XR data?
Perhaps:
* RQ 3.2.4: Can COIN improve the dynamic distribution of control,
forwarding, and storage resources and related usage models in XR,
such as to integrate local and fog caching with cloud-based pre-
rendering? Could this jointly optimize COIN and higher layer protocols to
reduce latency and, more generally, manage the quality of XR sessions
(e.g., through reduced in-network congestion and improved flow delivery
by determining how to prioritize XR data)?
-->
16) <!--[rfced] FYI, this text has been updated to use person-first language.
Please let us know if you prefer otherwise.
Original:
* Augmentation of the performance with subtitles, audio-description,
actor-tagging, language translation, advertisements/product-
placement, other enhancements/filters to make the performance
accessible to disabled audience members (removal of flashing
images for epileptics, alternative color schemes for color-blind
audience members, etc.).
Current:
* Augmentation of the performance with subtitles, audio description,
actor tagging, language translation, advertisements and product
placement, and other enhancements and filters to make the
performance accessible to audience members who are disabled (e.g.,
the removal of flashing images for audience members who have
epilepsy or alternative color schemes for those who have color
blindness).
-->
17) <!-- [rfced] For clarity, may we adjust this list as follows?
Original:
* RQ 4.1.6: Can there be different control levels, e.g., "quite
inaccurate & very low latency" (PNDs, deep in the network), "more
accurate & higher latency" (more powerful COIN execution
environments, farer away), "very accurate & very high latency"
(cloud environments, far away)?
Option A (without parentheses):
* RQ 4.1.6: Can there be different control levels? For example,
"quite inaccurate & very low latency" for PNDs deep in the network;
"more accurate & higher latency" for more powerful COIN execution
environments that are farther away; and "very accurate & very high
latency" for cloud environments that are far away.
Option B (using a sublist):
* RQ 4.1.6: Can there be different control levels? For example:
- "quite inaccurate & very low latency" for PNDs deep in the
network;
- "more accurate & higher latency" for more powerful COIN execution
environments that are farther away; and
- "very accurate & very high latency" for cloud environments that
are far away.
-->
18) <!-- [rfced] Section 5.1.4: To improve readability and avoid overuse
of "e.g.," and parentheses, how may these items be updated?
i) Does "(e.g., virtualized, distributed)" mean the set of choices
are virtualized and/or distributed?
Original:
* Supporting the selection of a service destination from a set of
possible (e.g., virtualized, distributed) choices, e.g., through
constraint-based routing decisions (see [APPCENTRES]) in (COIN)
program instances to improve the overall end user experience by
selecting a 'more suitable' service destination over another,
e.g., avoiding/reducing overload situations in specific service
destinations.
Option A:
* Supporting the selection of a service destination from a set of
possible choices (virtualized and distributed) in (COIN) program
instances (e.g., through constraint-based routing decisions as seen in
[APPCENTRES]) to improve the overall end-user experience by selecting a
"more suitable" service destination over another (e.g.,
avoiding/reducing overload situations in specific service destinations).
Option B (moving the last two examples to one final sentence):
* Supporting the selection of a service destination from a set of
possible choices (virtualized and distributed) in (COIN) program
instances to improve the overall end-user experience by selecting a
"more suitable" service destination over another. (For example,
selecting through constraint-based routing decisions as seen in
[APPCENTRES] may allow avoiding/reducing overload situations in
specific service destinations.)
ii) Does "in-network/switch-based" mean "in-network and switch-based"?
Original:
* Supporting Layer 2 capabilities for multicast (compute
interconnection and collective communication in [APPCENTRES]),
e.g., through in-network/switch-based replication decisions (and
their optimizations) based on dynamic group membership
information, may reduce the network utilization and therefore
increase the overall system efficiency.
Perhaps (moving the example to the end):
* Supporting L2 capabilities for multicast (compute interconnection
and collective communication as seen in [APPCENTRES]) may
reduce the network utilization and therefore increase the overall
system efficiency. For example, this support may be
through in-network, switch-based replication decisions (and their
optimizations) based on dynamic group membership information.
-->
19) <!-- [rfced] FYI - We have added a subject for "such as exposed through" in
the text below. Also, we assumed "InfiBand" was intended as "InfiniBand".
Please review.
Original:
We interpret connected compute resources as operating at a suitable
layer, such as Ethernet, InfiBand but also at Layer 3, to allow for
the exchange of suitable invocation methods, such as exposed through
verb-based or socket-based APIs.
Current:
We interpret connected compute resources as operating at a suitable
layer, such as Ethernet, InfiniBand, but also at Layer 3 (L3), to allow
for the exchange of suitable invocation methods, such as those
exposed through verb-based or socket-based APIs.
-->
20) <!-- [rfced] Section 5.2.4. Opportunities: How may we add a verb/outcome
to the second part of this list item, in order to be consistent with the
rest of the items in this section?
Original:
* Supporting the enforcement of trust relationships and isolation
policies through intermediary (COIN) program instances, e.g.,
enforcing specific traffic shares or strict isolation of traffic
through differentiated queueing.
Perhaps:
* Supporting the enforcement of trust relationships and isolation
policies through intermediary (COIN) program instances (e.g.,
enforcing specific traffic shares or strict isolation of traffic
through differentiated queueing) will allow for [what?].
-->
21) <!-- [rfced] May "controller" be plural here in order to be parallel
with the other plural list items?
Original:
Virtual network programming by tenants could bring benefits such as:
* A unified programming model, which can facilitate porting COIN
programs between data centers, 5G networks, and other fixed and
wireless networks, as well as sharing controller, code and
expertise.
Perhaps:
Virtual network programming by tenants could bring benefits such as:
* A unified programming model, which can facilitate porting COIN
programs between data centers, 5G networks, and other fixed and
wireless networks, as well as sharing controllers, code, and
expertise.
-->
22) <!-- [rfced] Section 6.1.4. Opportunities: We are having a difficult time
parsing the two items below. How may we revise for clarity?
(For example, in the second item, please consider where the first "e.g."
phrase end, and how the second "e.g." connects to the preceding text.)
Original:
* Supporting service-level routing of training requests (service
routing in [APPCENTRES]), with AI services being exposed to the
network, where (COIN) program instances may support the selection
of the most suitable service instance based on control plane
information, e.g., on AI worker compute capabilities, being
distributed across (COIN) program instances.
* Supporting the collective communication primitives, such as all-
to-all, scatter-gather, utilized by the (distributed) AI workers
to increase the overall network efficiency, e.g., through avoiding
endpoint-based replication or even directly performing, e.g.,
reduce, collective primitive operations in (COIN) program
instances placed in topologically advantageous places.
Perhaps:
* Supporting service-level routing of training requests (such as service
routing in [APPCENTRES]) with AI services being exposed to the
network, and where (COIN) program instances may support the selection
of the most suitable service instance based on control plane
information (e.g., on AI worker compute capabilities being
distributed across (COIN) program instances).
* Supporting the collective communication primitives, such as all-
to-all and scatter-gather, utilized by the (distributed) AI
workers may increase the overall network efficiency (e.g.,
through avoiding endpoint-based replication or even directly
performing (or reducing) collective primitive operations) in (COIN)
program instances placed in topologically advantageous places.
-->
23) <!-- [rfced] Please clarify the final phrase; what is the subject of
"reduce"? In other words, what educe in a central (COIN) program
Original:
* RQ 6.1.1: What are the communication patterns that may be
supported by collective communication solutions, where those
solutions directly utilize (COIN) program instance capabilities
within the network (e.g., reduce in a central (COIN) program
instance)?
-->
24) <!-- [rfced] Section 7:
a) In Figure 4 (and throughout Section 7) some words are in all caps, while
others are not. Should these partially capitalized phrases be updated to match
the other categories that appear in title case?
Partially capitalized:
VISION(S) for COIN
ENABLING TECHNOLOGIES for COIN
Distributed Computing FRAMEWORKS and LANGUAGES to COIN
Title case:
Applicability Areas
Transport
App Design
Data Processing
Routing & Forwarding
(Industrial) Control
b) FYI - We have replaced the asterisks in this section with quotation marks
to indicate that these terms refer to items in Figure 4.
-->
25) <!--[rfced] References:
a) For [Stoyanov], would you like to change the URL for this
reference or leave it as is?
Current: https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf
<https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf>
Perhaps: https://dl.acm.org/doi/10.1145/3426744.3431329
<https://dl.acm.org/doi/10.1145/3426744.3431329>
b) For [SA2-5GLAN], the URL provided returns a "403 - Forbidden"
error. We were unable to find an alternative source for this
reference. Please review and let us know how to update.
Current:
[SA2-5GLAN]
3GPP-5glan, "SP-181129, Work Item Description,
Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and
LAN Services", 3GPP , 2021,
<http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-
<http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP->
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://www.rfc-editor.org/styleguide/part2/#inclusive_language>
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
a) For example, please consider whether "native" should be updated here:
so-called 'cloud-native' applications for applications developed
b) In addition, please consider whether instances of "traditional"
and "traditionally" should be updated for clarity. While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>>
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://www.rfc-editor.org/faq/
<https://www.rfc-editor.org/faq/>).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info
<https://trustee.ietf.org/license-info>).
* 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://www.rfc-editor.org/authors/rfc9817.xml
<https://www.rfc-editor.org/authors/rfc9817.xml>
https://www.rfc-editor.org/authors/rfc9817.html
<https://www.rfc-editor.org/authors/rfc9817.html>
https://www.rfc-editor.org/authors/rfc9817.pdf
<https://www.rfc-editor.org/authors/rfc9817.pdf>
https://www.rfc-editor.org/authors/rfc9817.txt
<https://www.rfc-editor.org/authors/rfc9817.txt>
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9817-diff.html
<https://www.rfc-editor.org/authors/rfc9817-diff.html>
https://www.rfc-editor.org/authors/rfc9817-rfcdiff.html
<https://www.rfc-editor.org/authors/rfc9817-rfcdiff.html> (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9817-xmldiff1.html
<https://www.rfc-editor.org/authors/rfc9817-xmldiff1.html>
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9817
<https://www.rfc-editor.org/auth48/rfc9817>
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
