Hi Will, Fantastic!
Thank you, Sarah Tarrant RFC Production Center > On Mar 24, 2026, at 6:00 PM, Will Hawkins <[email protected]> wrote: > > Sarah, > > Thank you very much for the update and for being able to take care of > the typo in the Acknowledgments. We will stay on standby in case there > are other ways that we can help you as you go through the editing > process. > > Will > > On Tue, Mar 24, 2026 at 11:26 AM Sarah Tarrant > <[email protected]> wrote: >> >> Hi Will, >> >> Thank you for your careful reply. >> >> Regarding the name typo in the Acknowledgements, we can make that change on >> our end -- so no new version is necessary. >> >> Based on Med's response, I do believe we are all set on the references at >> this time. >> >> Sincerely, >> Sarah Tarrant >> RFC Production Center >> >>> On Mar 24, 2026, at 2:20 AM, Will Hawkins <[email protected]> wrote: >>> >>> On Tue, Mar 24, 2026 at 2:43 AM <[email protected]> wrote: >>>> >>>> Hi Will, all, >>>> >>>> I confirm that no change is needed to the references. >>>> >>>> FWIW, as part of the IESG approval process, I have requested that RFC 7497 >>>> is added to the downref registry... which you can see is already >>>> implemented at: https://datatracker.ietf.org/doc/downref. >>>> >>>> For C570 (https://www.rfc-editor.org/auth48/C570), RFC-to-be 9946 is about >>>> to be published. So, all is set for draft-ietf-ippm-asymmetrical-pkts to >>>> be processed :-) >>>> >>> >>> Very helpful -- thank you! We just wanted to make sure that we were >>> following all the rules! >>> >>> Will >>> >>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Will Hawkins <[email protected]> >>>>> Envoyé : mardi 24 mars 2026 04:25 >>>>> À : Sarah Tarrant <[email protected]> >>>>> Cc : [email protected]; [email protected]; >>>>> [email protected]; [email protected]; >>>>> [email protected]; BOUCADAIR Mohamed INNOV/NET >>>>> <[email protected]>; [email protected]; >>>>> [email protected] >>>>> Objet : Re: Document intake questions about <draft-ietf-ippm- >>>>> asymmetrical-pkts-14> >>>>> >>>>> >>>>> Ms. Tarrant, >>>>> >>>>> Thank you for serving as the editor for our draft! We are really >>>>> excited about seeing this RFC in final form. We have collaborated >>>>> on a set of answers to the questions that you posed. I will put >>>>> them inline (for maximum context). Some of our answers are >>>>> questions and we understand that we may have to take actions based >>>>> on your responses. >>>>> We promise to watch closely for your feedback and act quickly -- >>>>> we want to make your job as easy as possible. >>>>> >>>>> Thank you, again, for helping us bring this draft to published >>>>> form! >>>>> >>>>> On Wed, Mar 18, 2026 at 4:02 PM Sarah Tarrant <[email protected] >>>>> editor.org> wrote: >>>>>> >>>>>> Author(s), >>>>>> >>>>>> Congratulations, your document has been successfully added to >>>>> the RFC Editor queue! >>>>>> The team at the RFC Production Center (RPC) is looking forward >>>>> to >>>>>> working with you as your document moves forward toward >>>>> publication. To >>>>>> help reduce processing time and improve editing accuracy, please >>>>>> respond to the questions below. Please confer with your >>>>> coauthors (or >>>>>> authors of other documents if your document is in a >>>>>> cluster) as necessary prior to taking action in order to >>>>> streamline communication. >>>>>> If your document has multiple authors, only one author needs to >>>>> reply >>>>>> to this message. >>>>>> >>>>>> As you read through the rest of this email: >>>>>> >>>>>> * If you need/want to make updates to your document, we >>>>> encourage you >>>>>> to make those changes and resubmit to the Datatracker. This >>>>> allows for >>>>>> the easy creation of diffs, which facilitates review by >>>>> interested parties (e.g., authors, ADs, doc shepherds). >>>>>> * If you feel no updates to the document are necessary, please >>>>> reply >>>>>> with any applicable rationale/comments. >>>>>> >>>>>> >>>>>> Please note that the RPC team will not work on your document >>>>> until we >>>>>> hear from you (that is, your document will remain in AUTH state >>>>> until >>>>>> we receive a reply). Even if you don't have guidance or don't >>>>> feel >>>>>> that you need to make any updates to the document, you need to >>>>> let us >>>>>> know. After we hear from you, your document will start moving >>>>> through >>>>>> the queue. You will be able to review and approve our updates >>>>> during AUTH48. >>>>>> >>>>>> Please feel free to contact us with any questions you may have >>>>> at >>>>>> [email protected]. >>>>>> >>>>>> Thank you! >>>>>> The RPC Team >>>>>> >>>>>> -- >>>>>> >>>>>> 1) As there may have been multiple updates made to the document >>>>> during >>>>>> Last Call, please review the current version of the document: >>>>>> >>>>>> * Is the text in the Abstract still accurate? >>>>>> * Are the Authors' Addresses, Contributors, and Acknowledgments >>>>>> sections current? >>>>>> >>>>> >>>>> The abstract is accurate. There is a minor typo in the >>>>> acknowledgments: >>>>> Fiocolla is spelled Fioccola. We understand that you suggested we >>>>> post updated versions of the draft through Datatracker to make >>>>> changes but wanted to confirm that this type of error warrants a >>>>> new draft revision. >>>>> >>>>>> >>>>>> 2) Please share any style information that could help us with >>>>> editing >>>>>> your document. For example: >>>>>> >>>>>> * Is your document's format or its terminology based on another >>>>>> document, WG style guide, etc.? If so, please provide a pointer >>>>> to >>>>>> that information (e.g., "This document's terminology should >>>>> match DNS >>>>>> terminology in RFC 9499." or "This document uses the style info >>>>> at >>>>>> >>>>> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fhttpwg.org%2Fadmin%2Feditors%2Fstyle- >>>>> guide&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd94b93ab3c63 >>>>> 42565d7808de8954f1f9%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C >>>>> 639099195091626803%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU >>>>> sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D >>>>> %3D%7C0%7C%7C%7C&sdata=%2FcV90oSrnCAn3i0zUihSrVMmmMIszVoFMtQkiMwNa >>>>> d0%3D&reserved=0>."). >>>>>> * Is there a general pattern of capitalization or formatting of >>>>> terms >>>>>> that editors can follow (e.g., "Field names should have initial >>>>> capitalization." >>>>>> or "Parameter names should be in double quotes." or "<tt/> >>>>> should be >>>>>> used for token names." etc.)? >>>>> >>>>> The document builds on RFC 8762 and RFC 8972. Use of STAMP-related >>>>> terms (e.g., Session-Sender) should be consistent with their >>>>> use/definition in the former and STAMP-extension-related terms >>>>> (e.g., >>>>> TLV) should be consistent with their definition/use in the latter. >>>>> >>>>> Capitalization and stylization of field names should be done >>>>> according to the IETF's conventions -- we followed the guidance of >>>>> our AD when preparing the draft. >>>>> >>>>>> >>>>>> >>>>>> 3) Please carefully review the entries and their URLs in the >>>>>> References section with the following in mind. Note that we will >>>>>> update as follows unless we hear otherwise at this time: >>>>>> >>>>>> * References to obsoleted RFCs will be updated to point to the >>>>> current >>>>>> RFC on the topic in accordance with Section 4.8.6 of RFC 7322 >>>>> (RFC >>>>>> Style Guide). >>>>>> >>>>>> * References to I-Ds that have been replaced by another I-D will >>>>> be >>>>>> updated to point to the replacement I-D. >>>>>> >>>>>> * References to documents from other organizations that have >>>>> been >>>>>> superseded will be updated to their superseding version. >>>>>> >>>>>> Note: To check for outdated RFC and I-D references, you can use >>>>> idnits >>>>>> >>>>> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Faut >>>>>> hor- >>>>> tools.ietf.org%2Fidnits&data=05%7C02%7Cmohamed.boucadair%40orange. >>>>>> >>>>> com%7Cd94b93ab3c6342565d7808de8954f1f9%7C90c7a20af34b40bfbc48b9253 >>>>> b6f5 >>>>>> >>>>> d20%7C0%7C0%7C639099195091642549%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e >>>>> U1hc >>>>>> >>>>> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld >>>>> UIjo >>>>>> >>>>> yfQ%3D%3D%7C0%7C%7C%7C&sdata=hPUjgqt%2FE4Yoq0UF8xPeP1zTfiH%2FO9SyE >>>>> fTK6 >>>>>> 3iLSwI%3D&reserved=0>. You can also help the IETF Tools Team by >>>>>> testing idnits3 >>>>>> >>>>> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Faut >>>>>> hor- >>>>> tools.ietf.org%2Fidnits3%2F&data=05%7C02%7Cmohamed.boucadair%40ora >>>>>> >>>>> nge.com%7Cd94b93ab3c6342565d7808de8954f1f9%7C90c7a20af34b40bfbc48b >>>>> 9253 >>>>>> >>>>> b6f5d20%7C0%7C0%7C639099195091652782%7CUnknown%7CTWFpbGZsb3d8eyJFb >>>>> XB0e >>>>>> >>>>> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI >>>>> sIld >>>>>> >>>>> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pZXD%2B4HlELILF8foGc%2FPgdKVL%2Bl >>>>> 4yM4 >>>>>> vsOohp6ugIi8%3D&reserved=0> with your document and reporting any >>>>>> issues to them. >>>>> >>>>> According to idnits, our normative reference to the informational >>>>> 7497 is not appropriate problem. However, according to >>>>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>> www.ietf.org%2Fprocess%2Fprocess%2Finformational-vs- >>>>> experimental%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd9 >>>>> 4b93ab3c6342565d7808de8954f1f9%7C90c7a20af34b40bfbc48b9253b6f5d20% >>>>> 7C0%7C0%7C639099195091662640%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc >>>>> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld >>>>> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=j2bFsvJIe5Ac1t6utCEBQ6ipaA6%2BiDO >>>>> cUo9cwU9EkFM%3D&reserved=0 >>>>> and >>>>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>> datatracker.ietf.org%2Fdoc%2Frfc7322%2F&data=05%7C02%7Cmohamed.bou >>>>> cadair%40orange.com%7Cd94b93ab3c6342565d7808de8954f1f9%7C90c7a20af >>>>> 34b40bfbc48b9253b6f5d20%7C0%7C0%7C639099195091672227%7CUnknown%7CT >>>>> WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4 >>>>> zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2Boq3Mko >>>>> QZoqYxCqAf36Tn52LFaApW%2Bhs5DugN10n0Rs%3D&reserved=0, we believe >>>>> that our reference meets the criteria for normativity (in >>>>> particular, we rely on the definition of terms from that document >>>>> which would make our work impossible to understand without having >>>>> read that document). >>>>> >>>>> During the IETF Last Call, however, we did not explicitly >>>>> reference this downward reference >>>>> (https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fdatatracker.ietf.org%2Fdoc%2Frfc3967%2F&data=05%7C02%7Cmohamed.bo >>>>> ucadair%40orange.com%7Cd94b93ab3c6342565d7808de8954f1f9%7C90c7a20a >>>>> f34b40bfbc48b9253b6f5d20%7C0%7C0%7C639099195091681629%7CUnknown%7C >>>>> TWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW >>>>> 4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QTXALk7u >>>>> 8km8%2BYWngMtbRsNzmsqOOf%2FVHE1fkwmOLY0%3D&reserved=0). >>>>> >>>>> Any advice you have on how to proceed would be greatly >>>>> appreciated. >>>>> >>>>>> >>>>>> >>>>>> 4) Is there any text that requires special handling? For >>>>> example: >>>>>> * Are there any sections that were contentious when the document >>>>> was drafted? >>>>>> * Are any sections that need to be removed before publication >>>>> marked >>>>>> as such (e.g., Implementation Status sections (per RFC 7942)). >>>>>> * Are there any instances of repeated text/sections that should >>>>> be >>>>>> edited the same way? >>>>>> >>>>> >>>>> There is an implementation section that should be removed (6). >>>>> There are IANA allocations that need to be made (8). >>>>> >>>>>> >>>>>> 5) This document contains SVG. What tool did you use to make the >>>>> svg? >>>>>> >>>>>> The RPC cannot update SVG diagrams, so please ensure that: >>>>>> >>>>>> * the SVG figures match the ASCII art used in the text output as >>>>>> closely as possible, and >>>>>> * the figures fit on the pages of the PDF output. >>>>> >>>>> All diagrams in the XML source code of the document are contained >>>>> in artsets. As such, there is an ASCII version and an SVG version >>>>> of each diagram. We believe that the inclusion of both forms of >>>>> the artwork should give editors maximum flexibility. SVG versions >>>>> of the diagrams were constructed using aasvg. >>>>> >>>>>> >>>>>> >>>>>> 6) This document is part of Cluster 570: >>>>>> >>>>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>> www. >>>>>> rfc- >>>>> editor.org%2Fcluster_info.php%3Fcid%3DC570&data=05%7C02%7Cmohamed. >>>>>> >>>>> boucadair%40orange.com%7Cd94b93ab3c6342565d7808de8954f1f9%7C90c7a2 >>>>> 0af3 >>>>>> >>>>> 4b40bfbc48b9253b6f5d20%7C0%7C0%7C639099195091691107%7CUnknown%7CTW >>>>> FpbG >>>>>> >>>>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >>>>> IkFO >>>>>> >>>>> IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nprh3f22XC4AOf%2Bm >>>>> mLpQ >>>>>> P721atRPEvzvn3j4UHSK53g%3D&reserved=0 >>>>>> >>>>>> * To help the reader understand the content of the cluster, is >>>>> there a >>>>>> document in the cluster that should be read first? Next? If so, >>>>> please >>>>>> provide the order and we will provide RFC numbers for the >>>>> documents accordingly. >>>>>> If order is not important, please let us know. >>>>>> * Is there any text that has been repeated within the cluster >>>>> document >>>>>> that should be edited in the same way (for instance, parallel >>>>>> introductory text or Security Considerations)? >>>>>> * For more information about clusters, see >>>>>> >>>>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>> www. >>>>>> rfc- >>>>> editor.org%2Fabout%2Fclusters%2F&data=05%7C02%7Cmohamed.boucadair% >>>>>> >>>>> 40orange.com%7Cd94b93ab3c6342565d7808de8954f1f9%7C90c7a20af34b40bf >>>>> bc48 >>>>>> >>>>> b9253b6f5d20%7C0%7C0%7C639099195091700488%7CUnknown%7CTWFpbGZsb3d8 >>>>> eyJF >>>>>> >>>>> bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW >>>>> FpbC >>>>>> >>>>> IsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FSyZuoqeSA84LiEdEU%2BDUhpoG9 >>>>> V7PD >>>>>> nGCn1tnWRThik%3D&reserved=0 >>>>>> * For a list of all current clusters, see: >>>>>> >>>>> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw >>>>> ww.r >>>>>> fc- >>>>> editor.org%2Fall_clusters.php&data=05%7C02%7Cmohamed.boucadair%40o >>>>> r >>>>>> >>>>> ange.com%7Cd94b93ab3c6342565d7808de8954f1f9%7C90c7a20af34b40bfbc48 >>>>> b925 >>>>>> >>>>> 3b6f5d20%7C0%7C0%7C639099195091710036%7CUnknown%7CTWFpbGZsb3d8eyJF >>>>> bXB0 >>>>>> >>>>> eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbC >>>>> IsIl >>>>>> >>>>> dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ECtt6Q4ym1XZii48F1e%2FZ9oPBGwQ4D >>>>> aUQW >>>>>> dkokLadtE%3D&reserved=0 >>>>> >>>>> RFC 8762 and RFC 8972 establish, broadly, the context for the >>>>> protocol mechanisms defined by this draft. The former should be >>>>> read before the latter. RFC 7497 establishes, broadly, the context >>>>> for the operational deployment of the protocol mechanisms defined >>>>> by this draft to perform active measurement of the capacity of a >>>>> network. >>>>> >>>>> >>>>> Thank you, again, for helping us! We will keep our eyes peeled for >>>>> responses from you and take the appropriate action! >>>>> >>>>> Sincerely, >>>>> Will (for all the authors) >>>>> >>>>>> >>>>>> >>>>>> 7) Is there anything else that the RPC should be aware of while >>>>>> editing this document? >>>>>> >>>>>>> On Mar 18, 2026, at 2:59 PM, [email protected] wrote: >>>>>>> >>>>>>> Author(s), >>>>>>> >>>>>>> Your document draft-ietf-ippm-asymmetrical-pkts-14, which has >>>>> been >>>>>>> approved for publication as an RFC, has been added to the RFC >>>>> Editor >>>>>>> queue >>>>> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fwww.rfc- >>>>> editor.org%2Fcurrent_queue.php&data=05%7C02%7Cmohamed.boucadair%40 >>>>> orange.com%7Cd94b93ab3c6342565d7808de8954f1f9%7C90c7a20af34b40bfbc >>>>> 48b9253b6f5d20%7C0%7C0%7C639099195091719925%7CUnknown%7CTWFpbGZsb3 >>>>> d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO >>>>> IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=C9ZH2eSZfqu2XY4QVS >>>>> cqhHGTYI71aMo7gh1MfSjCs28%3D&reserved=0>. >>>>>>> >>>>>>> If your XML file was submitted using the I-D submission tool >>>>>>> >>>>> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fd >>>>>>> >>>>> atatracker.ietf.org%2Fsubmit%2F&data=05%7C02%7Cmohamed.boucadair%4 >>>>> 0orange.com%7Cd94b93ab3c6342565d7808de8954f1f9%7C90c7a20af34b40bfb >>>>> c48b9253b6f5d20%7C0%7C0%7C639099195091729312%7CUnknown%7CTWFpbGZsb >>>>> 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >>>>> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=J5VMUHEjuBG5nCZeK >>>>> b1ixzm6dk4muh6XxgfAfO3fY%2BY%3D&reserved=0>, we have already >>>>> retrieved it and have started working on it. >>>>>>> >>>>>>> If you did not submit the file via the I-D submission tool, or >>>>> if >>>>>>> you have an updated version (e.g., updated contact >>>>> information), >>>>>>> please send us the file at this time by attaching it in your >>>>> reply >>>>>>> to this message and specifying any differences between the >>>>> approved >>>>>>> I-D and the file that you are providing. >>>>>>> >>>>>>> You will receive a separate message from us asking for style >>>>> input. >>>>>>> Please respond to that message. When we have received your >>>>>>> response, your document will then move through the queue. The >>>>> first >>>>>>> step that we take as your document moves through the queue is >>>>>>> converting it to RFCXML (if it is not already in RFCXML) and >>>>>>> applying the formatting steps listed at >>>>> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fwww.rfc-editor.org%2Fpubprocess%2Fhow-we- >>>>> update%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd94b93ab >>>>> 3c6342565d7808de8954f1f9%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C >>>>> 0%7C639099195091739256%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR >>>>> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf >>>>> Q%3D%3D%7C0%7C%7C%7C&sdata=Fhy%2F4wR%2FYJ3rhYz2MFovBtdr0QwkePThXuG >>>>> pAtlApTE%3D&reserved=0>. >>>>>>> Next, we will edit for clarity and apply the style guide >>>>>>> >>>>> (<https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F% >>>>> 2Fwww.rfc- >>>>> editor.org%2Fstyleguide%2F&data=05%7C02%7Cmohamed.boucadair%40oran >>>>> ge.com%7Cd94b93ab3c6342565d7808de8954f1f9%7C90c7a20af34b40bfbc48b9 >>>>> 253b6f5d20%7C0%7C0%7C639099195091748917%7CUnknown%7CTWFpbGZsb3d8ey >>>>> JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi >>>>> TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2Fec76YiZbEvCsmSI%2F% >>>>> 2FQFmfqIStXUCjHmHzjUyh%2BuwFI%3D&reserved=0>). >>>>>>> >>>>>>> You can check the status of your document at >>>>>>> >>>>> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fwww.rfc- >>>>> editor.org%2Fcurrent_queue.php&data=05%7C02%7Cmohamed.boucadair%40 >>>>> orange.com%7Cd94b93ab3c6342565d7808de8954f1f9%7C90c7a20af34b40bfbc >>>>> 48b9253b6f5d20%7C0%7C0%7C639099195091762264%7CUnknown%7CTWFpbGZsb3 >>>>> d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO >>>>> IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=SRtaJkI4MLT74xrccY >>>>> 1AQ4JaS8ymcfCpq04hG7M8PQk%3D&reserved=0>. >>>>>>> >>>>>>> You will receive automatic notifications as your document >>>>> changes >>>>>>> queue state (for more information about these states, please >>>>> see >>>>>>> >>>>> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>> Fw >>>>>>> ww.rfc- >>>>> editor.org%2Fabout%2Fqueue%2F&data=05%7C02%7Cmohamed.boucadai >>>>>>> >>>>> r%40orange.com%7Cd94b93ab3c6342565d7808de8954f1f9%7C90c7a20af34b40 >>>>> bfbc48b9253b6f5d20%7C0%7C0%7C639099195091775536%7CUnknown%7CTWFpbG >>>>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >>>>> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MS4c70J6uqNX9R >>>>> KGxqMgBte0eqnnlV8GcGRpb8Wu%2FNw%3D&reserved=0>). When we have >>>>> completed our edits, we will move your document to AUTH48 state >>>>> and ask you to perform a final review of the document. >>>>>>> >>>>>>> Please let us know if you have any questions. >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> The RFC Editor Team >>>>>>> >>>>>> >>>> ____________________________________________________________________________________________________________ >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>>> recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >>>> electroniques etant susceptibles d'alteration, >>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou >>>> falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or privileged >>>> information that may be protected by law; >>>> they should not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and >>>> delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have been >>>> modified, changed or falsified. >>>> Thank you. >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
