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. > > > 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/rfc9699.xml > https://www.rfc-editor.org/authors/rfc9699.html > https://www.rfc-editor.org/authors/rfc9699.pdf > https://www.rfc-editor.org/authors/rfc9699.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9699-diff.html > https://www.rfc-editor.org/authors/rfc9699-rfcdiff.html (side by side) > > Alt-diff of the text (allows you to more easily view changes > where text has been deleted or moved): > https://www.rfc-editor.org/authors/rfc9699-alt-diff.html > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9699-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9699 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9699 (draft-ietf-mops-ar-use-case-18) > > Title : Media Operations Use Case for an Extended Reality > Application on Edge Computing Infrastructure > Author(s) : R. Krishna, A. Rahman > WG Chair(s) : Leslie Daigle, Kyle Rose > > Area Director(s) : Warren Kumari, Mahesh Jethanandani > > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
