Hi authors, This is a friendly reminder that we await answers to the questions below and your review of the document before continuing with the publication process.
The AUTH48 status page is available here: https://www.rfc-editor.org/auth48/rfc9699 We look forward to hearing from you. Thank you, RFC Editor/rv > On Dec 10, 2024, at 12:01 AM, [email protected] wrote: > > Authors, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the XML file. > > > 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). > > Original: > MOPS AR Use Case > > Perhaps: > 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. > > 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 ... > --> > > > 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? > > Original: > 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. --> > > > 5) <!-- [rfced] Section 1: Will readers understand what "This" refers to in > the > second sentence below? The first sentence is included for context. > > Original: > 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. > > Perhaps: > 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. > > Or: > Some XR applications > such as AR require a real-time processing of video streams to > recognize specific objects. The objects are 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? > > Original: > 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. > > Perhaps: > 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. > > Or: > Some XR applications > (specifically, AR applications) require real-time processing of video > streams to > recognize specific objects. > ... > In addition, other XR > applications (specifically, 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? > > Original: > 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. > > Perhaps: > 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? > > Original: > This document motivates 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? > > Original: > 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. > > Perhaps: > This use case involves an XR application. > > Or: > 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? > > Original: > 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 > > Perhaps: > The XR application must generate a high-quality video that has the > properties described in the previous section and overlay the video on > the XR device's display > > Or: > 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". > > Original: > This section will > discuss the challenges such applications can face as a consequence. > > Perhaps: > 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? > > Original: > 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]. > --> > > > 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? > > Original: > 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. > > Perhaps: > 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. > > Original: > 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. > > Perhaps: > 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? > > Original: > As discussed earlier, the parameters that capture the characteristics > of XR application behavior are heavy-tailed. > > Perhaps: > As discussed in Section 1, 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. > > Original: > 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. > > Perhaps: > 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? > > Original: > 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. > > Perhaps: > 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". > > Original: > Another option for the network operators could be to deploy equipment that > supports differentiated services [RFC2475] or per-connection quality- > of-service guarantees [RFC2210]. > --> > > > 19) <!-- [rfced] Section 4.1: May we 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]. > > 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. > > 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. > > Original: > The security issues for the presented use case are similar to other > streaming applications [DIST], [NIST1], [CWE], [NIST2]. > > Perhaps: > The security issues for the presented use case are similar to those > described in [DIST], [NIST1], [CWE], and [NIST2]. > > Or: > The security issues for the presented use case are similar to those for > other > streaming applications. See [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. > > Original: > [AUGMENTED] > Schmalstieg, D. S. and T.H. Hollerer, "Augmented > Reality", Addison Wesley, 2016. > > Updated: > [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. > > Original: > [HEAVY_TAIL_2] > Taleb, N., "The Statistical Consequences of Fat Tails", > STEM Academic Press, 2020. > > Updated: > [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. > > See: > https://www.wiley.com/en-us/A+Primer+in+Data+Reduction%3A+An+Introductory+Statistics+Textbook-p-9780471101352 > > Original: > [HEAVY_TAIL_3] > Ehrenberg, A., "A Primer in Data Reduction.", John Wiley, > London, 1982. > > Updated: > [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. > > Original: > [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. > > Perhaps: > [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). > > 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. > > 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. > --> > > > Thank you. > > RFC Editor/rv > > > > On Dec 9, 2024, at 8:56 PM, [email protected] 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 > > * [email protected] (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). > > * [email protected], 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, > [email protected] 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 -- [email protected] To unsubscribe send an email to [email protected]
