Hi Leslie, Renan, and Akbar, Leslie, thank you for responding to clarify the change to the title! We updated the title (but not the abstract) and will move forward.
Renan and Akbar, all our questions have been addressed, and we have received all necessary approvals. We now consider AUTH48 complete: https://www.rfc-editor.org/auth48/rfc9699. Thank you for your attention and guidance during the AUTH48 process! We will move this document forward in the publication process at this time. Thank you and happy holidays! 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) Sincerely, RFC Editor/rv > On Dec 23, 2024, at 7:43 AM, Leslie Daigle (ThinkingCat) > <ldai...@thinkingcat.com> wrote: > > Hi, > I am not Éric, but as co-chair of the Media Ops WG, I would suggest: > Your proposed change for the title would be fine: > 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 > But, let’s NOT do the abstract change proposed: > 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. > Thanks, > Leslie. > On 22 Dec 2024, at 23:36, Rebecca VanRheenen wrote: > Hi Renan and Akbar, > Thank you for your quick replies! > Renan, I updated the sentence regarding Table 2; you’ll see that reflected in > the files below. > Akbar, I marked your approval on the AUTH48 status page for this document > (see https://www.rfc-editor.org/auth48/rfc9699). > The only open issue is the following question for Éric. I received an > out-of-office reply from him saying that he is offline for the holidays and > will return on January 2. If needed, I will follow up with him the week after > his return. > 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. > — 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 and happy holidays! > RFC Editor/rv > On Dec 21, 2024, at 5:15 AM, Renan Krishna <renan.kris...@gmail.com> wrote: > 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 > > -- > Leslie Daigle > Principal, ThinkingCat Enterprises > ldai...@thinkingcat.com -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
