Dear RFC Editors, We will respond to the questions and review the document in the next couple of weeks. Best regards, Renan
On Thu, Dec 19, 2024 at 10:58 PM Rebecca VanRheenen <rvanrhee...@amsl.com> wrote: > 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, rfc-edi...@rfc-editor.org 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, 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
