Hi Rebecca, Many thanks for your mail. Here is the additional updated edit from our side:
> The data in table 2 has been extracted from [METRIC_6]’s table V. May we update the sentence to clarify this? Agreed! OLD: The following Table 2 [METRICS_6] shows a taxonomy of applications with their associated required response times and bandwidths. NEW: Table 2 shows a taxonomy of applications with their associated required response times and bandwidths (this data is from Table V in [METRICS_6]). Best regards, Renan On Fri, Dec 20, 2024 at 8:56 PM Rebecca VanRheenen <rvanrhee...@amsl.com> wrote: > Hi Éric* and Renan, > > Thank you for your replies. Renan, we marked your approval on the AUTH48 > status page for this document (see > https://www.rfc-editor.org/auth48/rfc9699). We will assume your assent to > any further changes submitted by your coauthor unless we hear objection at > that time. > > We have a couple of followup questions: > > 1) *Éric, you wrote > > Indeed, let’s remove MOPS and its expansion from title and abstract > > To clarify, are you suggesting that we update the document title to remove > “Media Operations”? The acronym MOPS is not used in either the document > title or abstract; it was only used in the abbreviated title (appears in > the running header in the pdf output). The abstract contains the word > “media”, but not “Media Operations”. Should the word “media” be removed > from the abstract? > > Current (document title): > Media Operations Use Case for an Extended Reality Application on Edge > Computing Infrastructure > > Perhaps: > Use Case for an Extended Reality Application on Edge > Computing Infrastructure > > Current (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. > > Perhaps: > This document explores the issues involved in the use of edge > computing resources to operationalize a use case that involves > an Extended Reality (XR) application. > > > 2) Renan, about this question and your reply: > > > 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. > > —> > > Renan: > > The data in table 2 has been extracted from [METRIC_6]’s table V. > > May we update the sentence to clarify this? > > Original: > The following Table 2 [METRICS_6] shows a taxonomy of applications > with their associated required response times and bandwidths. > > Perhaps: > Table 2 shows a taxonomy of applications with their > associated required response times and bandwidths (this data is from > Table V in [METRICS_6]). > > > — FILES (please refresh) — > > Updated XML file: > https://www.rfc-editor.org/authors/rfc9699.xml > > Updated output files: > https://www.rfc-editor.org/authors/rfc9699.txt > https://www.rfc-editor.org/authors/rfc9699.pdf > https://www.rfc-editor.org/authors/rfc9699.html > > Diff file showing all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9699-auth48diff.html > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9699-diff.html > https://www.rfc-editor.org/authors/rfc9699-rfcdiff.html (side-by-side > diff) > https://www.rfc-editor.org/authors/rfc9699-alt-diff.html (diff showing > changes where text is moved or deleted) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9699 > > Thank you, > RFC Editor/rv > > > > 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 > > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
