On Dec 20, 2024, at 10:26 AM, Eric Vyncke (evyncke)
<evyncke=40cisco....@dmarc.ietf.org> wrote:
Indeed, let’s remove MOPS and its expansion from title and
abstract
-éric
From: Renan Krishna <renan.kris...@gmail.com>
Date: Friday, 20 December 2024 at 16:21
To: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>
Cc: akbar.rah...@ericsson.com <akbar.rah...@ericsson.com>,
mops-...@ietf.org <mops-...@ietf.org>, mops-cha...@ietf.org
<mops-cha...@ietf.org>, st...@stewe.org <st...@stewe.org>, Eric
Vyncke (evyncke) <evyn...@cisco.com>, auth48archive@rfc-editor.org
<auth48archive@rfc-editor.org>
Subject: Re: AUTH48: RFC-to-be 9699 <draft-ietf-mops-ar-use-case-18>
for your review
Dear RFC Editors,
Following is our response to the questions raised by RFC Editors:
Please
let us know if this is OK?
1) <!-- [rfced] How may we update the abbreviated title to better
align
with the
document title? The acronym MOPS does not appear elsewhere in the
document, and the document title uses "Extended Reality" rather than
"AR".
Note: The abbreviated title only appears in the pdf output (in the
running
header at the top of each page).
OLD:
MOPS AR Use Case
NEW:
XR Use Case
-->
2) <!-- [rfced] The document title uses "a Use Case" and "Extended
Reality
Application" (singular), while the abstract uses "use cases" and
"Extended Reality (XR) applications" (plural). Please review and let
us
know if any updates are needed.
OLD:
Document title:
Media Operations Use Case for an Extended Reality Application on
Edge
Computing Infrastructure
Abstract:
This document explores the issues involved in the use of Edge
Computing resources to operationalize media use cases that
involve
Extended Reality (XR) applications.
...
In particular, this document
discusses those applications that run on devices ...
-->
NEW:
Document title:
Media Operations Use Case for an Extended Reality Application on
Edge
Computing Infrastructure
Abstract:
This document explores the issues involved in the use of Edge
Computing resources to operationalize a media use case that
involves
an Extended Reality (XR) application.
...
In particular, this document
discusses an application that can run on devices ...
-->
3) <!-- [rfced] Please review the placement of this sentence in the
abstract. Would it be helpful to move this sentence to be the last
sentence in the abstract? Or do you prefer the current location?
Agreed, the following sentence should be moved to be the last
sentence in
the abstract.
OLD:
The intended audience for this document are network operators who
are
interested in providing edge computing resources to
operationalize
the requirements of such applications.
-->
4) <!-- [rfced] Please insert any keywords (beyond those that appear
in
the title) for use on https://www.rfc-editor.org/search. -->
“low-latency”
“managed-cloud”
“offload”
5) <!-- [rfced] Section 1: Will readers understand what "This"
refers to in
the
second sentence below? The first sentence is included for context.
OLD:
Some XR applications
such as AR require a real-time processing of video streams to
recognize specific objects. This is then used to overlay
information
on the video being displayed to the user.
NEW:
Some XR applications
such as AR require a real-time processing of video streams to
recognize specific objects. This processing is then used to
overlay
information
on the video being displayed to the user.
-->
6) <!-- [rfced] Section 1: May we update "XR applications such as
AR" and
"XR
applications such as AR and VR" as follows for clarity?
Yes please!
OLD:
Some XR applications
such as AR require a real-time processing of video streams to
recognize specific objects.
...
In addition, XR
applications such as AR and VR will also require generation of
new
video frames to be played to the user.
NEW:
Some XR applications
(such as AR applications) require real-time processing of video
streams
to
recognize specific objects.
...
In addition, other XR
applications (such as AR and VR applications) will also require
generation
of new video frames to be played to the user.
-->
7) <!-- [rfced] Section 1: May we combine these sentences as follows
to
improve
readability?
Agreed!
OLD:
Examples of form factors include Head Mounted Displays
(HMD) such as Optical-see through HMDs and video-see-through HMDs
and
Hand-held displays. Smart phones with video cameras and location
sensing capabilities using systems such as a global navigation
satellite system (GNSS) are another example of such devices.
NEW:
Examples of form factors include the following: 1) head-mounted
displays
(HMDs), such as optical see-through HMDs and video see-through
HMDs, 2)
hand-held displays, and 3) smartphones with video cameras and
location-
sensing capabilities using systems such as a global navigation
satellite system (GNSS).
-->
8) <!-- [rfced] Section 1: Is "motivates" the correct word choice
here?
Would
"addresses", "examines", or something similar be better?
OLD:
This document motivates these issues
with a use-case that is presented in the following sections.
NEW:
This document examines these issues
with a use-case that is presented in the following sections.
-->
9) <!-- [rfced] Section 2: We updated "application with XR systems'
characteristics" as "application with characteristics of an XR
system". Would it be helpful to further update in one of the ways
shown
below?
OLD:
A use case is now described that involves an application with XR
systems' characteristics.
Current:
This use case involves an application with characteristics of an
XR system.
NEW:
This use case involves an XR application running on a mobile
device.
-->
10) <!-- [rfced] Section 2.2: Will readers know what "the previous
step" is?
OLD:
The XR application must generate a high-quality video that has
the
properties described in the previous step and overlay the video
on
the XR device's display
NEW:
The XR application must generate a high-quality video that has
the
properties described above and overlay the video on
the XR device's display
-->
11) <!-- [rfced] Section 3: Should this sentence mention solutions
in
addition to
challenges? We note the title of the section is "Technical
Challenges and
Solutions".
OLD:
This section will
discuss the challenges such applications can face as a
consequence.
NEW:
This section
discusses the challenges such applications can face as a
consequence and
offers some solutions.
-->
12) <!-- [rfced] Section 3: Is "indicates" the best word choice
here? Would
"recommends", "suggests", or something similar be better?
OLD:
Towards this end, a 3GPP study indicates an Ultra
Reliable Low Latency of 0.1ms to 1ms for communication between an
Edge server and User Equipment (UE) [URLLC].
NEW:
Towards this end, a 3GPP study suggests an Ultra
Reliable Low Latency of 0.1ms to 1ms for communication between an
Edge server and User Equipment (UE) [URLLC].
-->
13) <!-- [rfced] Section 3: Please review the placement of the
sentence
starting
with "Such operational parameters" in the last paragraph of this
section. Would it be helpful to incorporate this sentence into the
first
sentence of the paragraph?
OLD:
However, heavy-tailed nature of several operational parameters
makes
prediction-based adaptation by ABR algorithms sub-optimal
[ABR_2].
...
Such operational parameters include but are not limited
to buffer occupancy, throughput, client-server latency, and
variable
transmission times.
NEW:
However, the heavy-tailed nature of several operational
parameters
(e.g., buffer occupancy, throughput, client-server latency, and
variable
transmission times) makes prediction-based adaptation by ABR
algorithms
sub-optimal
[ABR_2].
-->
14) <!-- [rfced] Section 3: Will readers understand what "This"
refers to
in the
second sentence below? The first sentence is included for context.
OLD:
Other subtle issues with these distributions include
the "expectation paradox" [HEAVY_TAIL_1] where the longer the
wait
for an event, the longer a further need to wait and the issue of
mismatch between the size and count of events [HEAVY_TAIL_1].
This
makes designing an algorithm for adaptation error-prone and
challenging.
NEW:
Other subtle issues with these
distributions include the "expectation paradox" [HEAVY_TAIL_1]
(the
longer the wait for an event, the longer a further need to wait)
and
the mismatch between the size and count of events [HEAVY_TAIL_1].
These issues make designing an algorithm for adaptation
error-prone and
challenging.
-->
15) <!-- [rfced] Section 4.1: Would it be helpful to point readers
to a
specific
section here?
OLD:
As discussed earlier, the parameters that capture the
characteristics
of XR application behavior are heavy-tailed.
NEW:
As discussed in Sections 1 and 3, the parameters that capture the
characteristics
of XR application behavior are heavy-tailed.
-->
16) <!-- [rfced] Section 4.1: We are having trouble understanding
"distribution of
arrival times between XR application invocation". Perhaps
"invocation"
should be "invocations" (plural), or perhaps a word missing
("between XR
application invocation and X")? Please review.
OLD:
Examples of such
parameters include the distribution of arrival times between XR
application invocation, the amount of data transferred, and the
inter-arrival times of packets within a session.
NEW:
Examples of such
parameters include the distribution of arrival times between XR
application invocations, the amount of data transferred, and the
inter-arrival times of packets within a session.
-->
17) <!-- [rfced] Section 4.1: Please note that RFC 9450 is not a
DETNET WG
document; it is a RAW WG document (see
https://datatracker.ietf.org/doc/rfc9450/). In addition, [RFC8939],
[RFC9023], and [RFC9450] have been published, so they are no longer
"being developed". How may we updated this sentence?
OLD:
Providing Edge server support for the techniques being developed
at
the DETNET Working Group at the IETF [RFC8939], [RFC9023],
[RFC9450]
could guarantee performance of XR applications.
NEW:
Providing support for Edge servers in techniques
such as those described in [RFC8939], [RFC9023], and [RFC9450]
could guarantee performance of XR applications.
-->
18) <!-- [rfced] Section 4.1: Is [RFC2210] is the correct citation
here, or
should
it be [RFC2112]? We ask because we see only one instance of
"quality of
service" in the text of RFC 2210, and the title of RFC 2112 is
"Specification of Guaranteed Quality of Service".
OLD:
Another option for the network operators could be to deploy
equipment that
supports differentiated services [RFC2475] or per-connection
quality-
of-service guarantees [RFC2210].
NEW:
Another option for the network operators could be to deploy
equipment that
supports differentiated services [RFC2475] or per-connection
quality-
of-service guarantees using the RSVP protocol [RFC2210].
-->
19) <!-- [rfced] Section 4.1: May we move the following sentence to
appear
before Table 1 rather than after it?
Agreed- please move the following sentence to appear
before Table 1 rather than after it
Original:
Thus, the provisioning of edge servers in terms of the number of
servers, the topology, where to place them, the assignment of
link
capacity, CPUs and GPUs should keep the above factors in mind.
-->
20) <!-- [rfced] Section 4.2: What is the relationship between Table
2 and
[METRICS_6]? We do not see the table in [METRIC_6].
The data in table 2 has been extracted from [METRIC_6]’s table V.
Original:
The following Table 2 [METRICS_6] shows a taxonomy of
applications
with their associated required response times and bandwidths.
-->
21) <!-- [rfced] Section 4.2: FYI - We updated "section 5.1" to
"Section
4.1"
here. Also, because Table 1 appears in Section 4.1, we updated to
only
mention Section 4.1.
Agreed!
Original:
Additionally, the required bandwidth for our use case as
discussed in section 5.1, Table 1, is 200Mbps-1000Mbps.
Current:
Additionally, the required bandwidth for our use case
is 200 to 1000 Mbps (see Section 4.1).
-->
22) <!-- [rfced] Section 7: We do not see explicit mention of
"streaming
applications" in [DIST], [NIST1], [CWE], and [NIST2]. Please confirm
that
these citations and the phrasing of the text are correct.
Agreed!
OLD:
The security issues for the presented use case are similar to
other
streaming applications [DIST], [NIST1], [CWE], [NIST2].
NEW:
The security issues for the presented use case are similar to
those
described in [DIST], [NIST1], [CWE], and [NIST2].
-->
23) <!-- [rfced] Section 8 (Informative References)
a) We added DOIs and URLs to some reference entries. Please review
for
correctness.
b) FYI - We updated the title of this reference entry as follows.
Let us
know
any concerns.
Agreed!
OLDl:
[AUGMENTED]
Schmalstieg, D. S. and T.H. Hollerer, "Augmented
Reality", Addison Wesley, 2016.
NEW:
[AUGMENTED]
Schmalstieg, D. and T. Höllerer, "Augmented Reality:
Principles and Practice", Addison-Wesley Professional,
2016, <https://www.oreilly.com/library/view/augmented-
reality-principles/9780133153217/>.
c) FYI - We updated the date in this reference entry from 2020 to
2022 per
https://arxiv.org/pdf/2001.10488. Let us know any concerns.
Agreed! 2022 edition is the revised version of the 2020 edition, so
the
updated version is OK.
OLD:
[HEAVY_TAIL_2]
Taleb, N., "The Statistical Consequences of Fat
Tails",
STEM Academic Press, 2020.
NEW:
[HEAVY_TAIL_2]
Taleb, N., "Statistical Consequences of Fat Tails:
Real
World Preasymptotics, Epistemology, and Applications",
Revised Edition, STEM Academic Press, 2022,
<https://arxiv.org/pdf/2001.10488> .
d) FYI - We updated the date from 1982 to 2007 in this reference
entry to
match the most current version of the book. Let us know any
concerns.
Agreed!
See:
https://www.wiley.com/en-us/A+Primer+in+Data+Reduction%3A+An+Introductory+Statistics+Textbook-p-9780471101352
OLD:
[HEAVY_TAIL_3]
Ehrenberg, A., "A Primer in Data Reduction.", John
Wiley,
London, 1982.
NEW:
[HEAVY_TAIL_3]
Ehrenberg, A., "A Primer in Data Reduction: An
Introductory Statistics Textbook", John Wiley and
Sons,
2007,
<https://www.wiley.com/en-us/A+Primer+in+Data+Reduct
ion%3A+An+Introductory+Statistics+Textbook-
p-9780471101352>.
e) FYI - We updated the title of this reference entry as follows
(i.e.,
added
"gDLS:"). Let us know any concerns.
Agreed!
OLD:
[SLAM_2] Sweeny, C., Fragoso, V., Hollerer, T., and M. Turk, "A
scalable solution to the generalized pose and scale
problem", In European Conference on Computer Vision,
pp.
16-31, 2014.
NEW:
[SLAM_2] Sweeny, C., Fragoso, V., Höllerer, T., and M. Turk,
"gDLS:
A Scalable Solution to the Generalized Pose and Scale
Problem", Computer Vision - ECCV 2014, pp. 16-31,
DOI 10.1007/978-3-319-10593-2_2, 2014,
<https://link.springer.com/
chapter/10.1007/978-3-319-10593-2_2>.
-->
24) <!-- [rfced] We note inconsistencies in the terms listed below.
If no
objections, we will update to the form on the right (i.e., the
lowercase
form). We see a mix of uppercase and lowercase use, but lowercase
seems
more common. In addition, the lowercase form aligns with usage in
several
other RFCs (e.g., RFC 9556).
No Objection!
Edge Computing vs. Edge computing vs. edge computing
Edge device vs. Edge Device vs. edge device
Edge server vs. edge server
Edge vs. edge
-->
25) <!-- [rfced] FYI - We added expansions for the following
abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Reviewed, each expansion is correct.
Software-Defined Networking (SDN)
Graphics Processing Units (GPUs)
-->
26) <!-- [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.
Note that our script did not flag any words in particular, but this
should
still be reviewed as a best practice.
In addition, please consider whether "tradition" should be updated
for
clarity.
While the NIST website
<
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.
Agreed!
OLD:
As seen from the table, the XR application such as our use case
transmit a
larger amount of data per unit time as compared to traditional video
applications.
NEW:
As seen from the table, the XR application such as our use case
transmit a
larger amount of data per unit time as compared to regular video
applications.
-->
Best regards,
Renan
On Tue, Dec 10, 2024 at 4:56 AM <rfc-edi...@rfc-editor.org> wrote:
*****IMPORTANT*****
Updated 2024/12/09
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
