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]
