Dear Yingzhen, I’m fine with the latest changes.
Best regards, Pierre. > On 25 Sep 2025, at 07:03, Yingzhen Qu <[email protected]> wrote: > > Hi authors, > > Can you please review the document? There are a few other documents waiting > for the publication of this one. > > Thanks, > Yingzhen > > On Fri, Sep 19, 2025 at 1:11 PM Kaelin Foody <[email protected] > <mailto:[email protected]>> wrote: >> Hi Bruno, all, >> >> Bruno: Thank you for your response. We have updated your location in the >> document as requested. >> >> Daniel: We have updated your email address in our database. Would you like >> your email and company to be updated in the document as well? >> >> We will await responses to our document-specific questions prior to moving >> this document forward in the publication process; we have included these >> questions at the end of this email for your convenience. >> >> — FILES (please refresh): — >> >> The updated files have been posted here: >> https://www.rfc-editor.org/authors/rfc9855.txt >> https://www.rfc-editor.org/authors/rfc9855.pdf >> https://www.rfc-editor.org/authors/rfc9855.html >> https://www.rfc-editor.org/authors/rfc9855.xml >> >> The relevant diff files have been posted here: >> https://www.rfc-editor.org/authors/rfc9855-auth48diff.html (AUTH48 changes >> only) >> https://www.rfc-editor.org/authors/rfc9855-auth48rfcdiff.html (AUTH 48 >> changes side by side) >> https://www.rfc-editor.org/authors/rfc9855-diff.html (all changes) >> https://www.rfc-editor.org/authors/rfc9855-rfcdiff.html (all changes side by >> side) >> >> The AUTH48 status page for this document is available here: >> https://www.rfc-editor.org/auth48/rfc9855 >> >> Thank you, >> >> Kaelin Foody >> RFC Production Center >> >> > On Sep 17, 2025, at 5:12 AM, [email protected] >> > <mailto:[email protected]> wrote: >> > >> > Greetings, >> > >> > Thanks Kaelin. >> > Looks good. >> > >> > One more minor point >> > >> > OLD: >> > Bruno Decraene >> > Orange >> > Issy-les-Moulineaux >> > France >> > >> > NEW: >> > Bruno Decraene >> > Orange >> > France >> > >> > >> > (at minimum, this is not my current location. Plus I'm not quite sure that >> > indicating the city is quite useful for such a small country). >> > >> > --Bruno >> > -----Original Message----- >> > From: Kaelin Foody <[email protected] >> > <mailto:[email protected]>> >> > Sent: Wednesday, September 10, 2025 5:38 PM >> > To: DECRAENE Bruno INNOV/NET <[email protected] >> > <mailto:[email protected]>> >> > Cc: [email protected] <mailto:[email protected]>; >> > [email protected] <mailto:[email protected]>; [email protected] >> > <mailto:[email protected]>; [email protected] >> > <mailto:[email protected]>; [email protected] >> > <mailto:[email protected]>; [email protected] >> > <mailto:[email protected]>; [email protected] >> > <mailto:[email protected]>; [email protected] >> > <mailto:[email protected]>; [email protected] >> > <mailto:[email protected]>; [email protected] >> > <mailto:[email protected]>; [email protected] >> > <mailto:[email protected]>; danvoyerwork <[email protected] >> > <mailto:[email protected]>> >> > Subject: Re: AUTH48: RFC-to-be 9855 >> > <draft-ietf-rtgwg-segment-routing-ti-lfa-21> for your review >> > >> > -------------------------------------------------------------------------------------------------------------- >> > CAUTION : This email originated outside the company. Do not click on any >> > links or open attachments unless you are expecting them from the sender. >> > >> > ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez >> > pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre >> > l'expéditeur. >> > -------------------------------------------------------------------------------------------------------------- >> > >> > Greetings, >> > >> > Bruno: Thank you for your comments. We have updated the document >> > accordingly. >> > >> > Daniel: We have updated your email address in our database. Would you like >> > your email and company to be updated in the document as well? >> > >> > We have a few other follow-up notes: >> > >> > a) >> > >> >> OLD: >> >> The measurement below indicates that, for link and local SRLG >> >> protection, a 1-SID repair path delivers more than 99% coverage. For >> >> node protection, a 2-SID repair path yields 99% coverage. >> >> […] >> >> The measurements listed in the tables indicate that for link and >> >> local SRLG protection, a 1-SID repair path is sufficient to protect >> >> more than 99% of the prefix in almost all cases. For node >> >> protection, 2-SID repair paths yield 99% coverage. >> >> This seems like a duplicate. I would suggest removing the second >> >> paragraph. >> >> NEW: >> >> The measurement below indicates that, for link and local SRLG >> >> protection, a 1-SID repair path delivers more than 99% coverage. For >> >> node protection, a 2-SID repair path yields 99% coverage. >> >> In addition, text is not strictly correct. It’s not “a 1-SID repair path” >> >> but “a 1-SID or less repair path. Idem for “2-SID. >> >> Hence NEW2: The measurement below indicates that, for link and local >> >> SRLG >> >> protection, a 1-SID or less repair path delivers more than 99% coverage. >> >> For >> >> node protection, a 2-SID or less repair path yields 99% coverage. >> >> Feel free to reword in a better way. >> > >> > We have updated Appendix B as follows. Please review and let us know if >> > this update captures your intended meaning: >> > >> > OLD: >> > The measurement below indicates that, for link and local SRLG protection, >> > a 1-SID repair path delivers more than 99% coverage. For node protection, >> > a 2-SID repair path yields 99% coverage. >> > >> > NEW: >> > The measurement below indicates that, for link and local SRLG protection, >> > a repair path of 1 SID or less delivers more than 99% coverage. For node >> > protection, a repair path of 2 SIDs or less yields 99% coverage. >> > >> > >> > b) >> > >> >> --- >> >> §5.4 >> >> OLD: As mentioned in Section 3, a list of adjacency SIDs can be used to >> >> encode the path between P and Q. However, the PLR can perform additional >> >> computations to compute a list of segments that represent a loop-free >> >> path from P to Q. >> >> Problem: “a list of adjacency SIDs” _is_ (already) “a list of segments”. >> >> Proposed NEW: As mentioned in Section 3, a list of adjacency SIDs can be >> >> used to encode the path between P and Q. However, the PLR can perform >> >> additional computations to compute a shorter list of segments that >> >> represent a loop-free path from P to Q. >> >> (+ ‘shorter’) >> >> Alternatively, we could introduce the term “node SIDs’ to explicit the >> >> difference compared to the list of adjacency SIDs, but this may be harder >> >> to phrase and less general. >> >> e.g, Proposed NEW2: As mentioned in Section 3, a list of adjacency SIDs >> >> can be used to encode the path between P and Q. However, the PLR can >> >> perform additional computations to compute a list of node and adjacency >> >> segments that represent a loop-free path from P to Q. >> >> --- >> > >> > We have updated the document to use the first “Proposed NEW” as seen above. >> > >> > >> > We will await responses to our other remaining questions prior to moving >> > this document forward in the publication process. >> > >> > Please review the document carefully to ensure satisfaction as we do not >> > make changes once it has been published as an RFC. >> > >> > — FILES (please refresh): — >> > >> > The updated files have been posted here: >> > https://www.rfc-editor.org/authors/rfc9855.txt >> > https://www.rfc-editor.org/authors/rfc9855.pdf >> > https://www.rfc-editor.org/authors/rfc9855.html >> > https://www.rfc-editor.org/authors/rfc9855.xml >> > >> > The relevant diff files have been posted here: >> > https://www.rfc-editor.org/authors/rfc9855-auth48diff.html (AUTH48 changes >> > only) >> > https://www.rfc-editor.org/authors/rfc9855-auth48rfcdiff.html (AUTH 48 >> > changes side by side) >> > https://www.rfc-editor.org/authors/rfc9855-diff.html (all changes) >> > https://www.rfc-editor.org/authors/rfc9855-rfcdiff.html (all changes side >> > by side) >> > >> > The AUTH48 status page for this document is available here: >> > https://www.rfc-editor.org/auth48/rfc9855 >> > >> > Thank you, >> > >> > Kaelin Foody >> > RFC Production Center >> > >> > >> >> On Sep 8, 2025, at 8:06 AM, [email protected] >> >> <mailto:[email protected]> wrote: >> >> >> >> All, >> >> The email address used for Daniel Voyer is outdated. >> >> Adding [email protected] <mailto:[email protected]> to this >> >> thread as per https://datatracker.ietf.org/person/[email protected] >> >> From: DECRAENE Bruno INNOV/NET >> >> Sent: Monday, September 8, 2025 1:55 PM >> >> To: [email protected] <mailto:[email protected]> >> >> Cc: [email protected] <mailto:[email protected]>; [email protected] >> >> <mailto:[email protected]>; >> >> [email protected] <mailto:[email protected]>; >> >> [email protected] <mailto:[email protected]>; >> >> [email protected] <mailto:[email protected]>; >> >> [email protected] <mailto:[email protected]>; >> >> [email protected] <mailto:[email protected]>; [email protected] >> >> <mailto:[email protected]>; [email protected] >> >> <mailto:[email protected]>; >> >> [email protected] <mailto:[email protected]> >> >> Subject: RE: AUTH48: RFC-to-be 9855 >> >> <draft-ietf-rtgwg-segment-routing-ti-lfa-21> for your review Hi RFC >> >> Editor, all Thanks for the document. >> >> Please find below some comments. >> >> Some comments are beyond editorial (§7.1, §5.4). Someone please review >> >> and ack. >> >> §5 >> >> In figure 1, the link/line from R2 to N1 is significantly offset from >> >> N1. It looks doable to better align the link & N1 >> >> OLD: >> >> S ------- N1 ----------- D >> >> *\ | \ | >> >> * \ | \ | >> >> * \ | \ | >> >> * N2-----R1****R2 *** R3 >> >> * * >> >> N3 ********* >> >> NEW: >> >> S --------- N1 --------- D >> >> *\ | \ | >> >> * \ | \ | >> >> * \ | \ | >> >> * N2----- R1***R2 *** R3 >> >> * * >> >> N3 ********** >> >> ---- >> >> §5.4 >> >> OLD: post- convergence >> >> NEW: post-convergence >> >> --- >> >> §5.4 >> >> OLD: As mentioned in Section 3, a list of adjacency SIDs can be used to >> >> encode the path between P and Q. However, the PLR can perform additional >> >> computations to compute a list of segments that represent a loop-free >> >> path from P to Q. >> >> Problem: “a list of adjacency SIDs” _is_ (already) “a list of segments”. >> >> Proposed NEW: As mentioned in Section 3, a list of adjacency SIDs can be >> >> used to encode the path between P and Q. However, the PLR can perform >> >> additional computations to compute a shorter list of segments that >> >> represent a loop-free path from P to Q. >> >> (+ ‘shorter’) >> >> Alternatively, we could introduce the term “node SIDs’ to explicit the >> >> difference compared to the list of adjacency SIDs, but this may be harder >> >> to phrase and less general. >> >> e.g, Proposed NEW2: As mentioned in Section 3, a list of adjacency SIDs >> >> can be used to encode the path between P and Q. However, the PLR can >> >> perform additional computations to compute a list of node and adjacency >> >> segments that represent a loop-free path from P to Q. >> >> --- >> >> §7.1 >> >> OLD: If the active segment is a node segment that has been signaled with >> >> penultimate hop popping, and the repair list ends with an adjacency >> >> segment terminating on a node that advertised the "NEXT" operation >> >> [RFC8402] of the active segment, then the active segment MUST be popped >> >> before pushing the repair list. >> >> Problem: the penultimate does not really “advertise’ the NEXT >> >> operation. (penultimate of popping is advertised by the ultimate node) >> >> Proposed NEW: If the active segment is a node segment that has been >> >> signaled with penultimate hop popping, and the repair list ends with an >> >> adjacency segment terminating on the penultimate node of the active >> >> segment, then the active segment MUST be popped before pushing the repair >> >> list. >> >> --- >> >> Appendix A >> >> OLD: >> >> H --- I --- J >> >> | | \ >> >> PE4 | | PE3 >> >> \ | (L) | / >> >> A --- X --- B --- G >> >> / | | \ >> >> PE1 | | PE2 >> >> \ | | / >> >> C --- D --- E --- F >> >> NEW: >> >> H --- I --- J * >> >> | | * >> >> PE4 | | PE3 >> >> \ | (L) | * >> >> * A --- X --- B --- G * >> >> * | | * >> >> PE1 | | PE2 >> >> * | | * >> >> * C --- D --- E --- F * >> >> Note: >> >> - “In Figure 3, we consider a network with all metrics equal to 1 >> >> except the metrics on links used by PE1, PE2, and PE3, which are 1000.” >> >> - In all other Figures (1 & 2), we used a convention to use “**” >> >> for the links having the high metric. I’d propose that we do the same >> >> convention for Figure 3. >> >> --- >> >> Appendix A >> >> “Another consideration to take into account is as follows: While using >> >> the expected post-convergence path” >> >> I’m not familiar with English typographic rules, but I would not have >> >> expected an upper case “W” for “While” >> >> -- >> >> Appendix A >> >> OLD: >> >> The measurement below indicates that, for link and local SRLG >> >> protection, a 1-SID repair path delivers more than 99% coverage. For >> >> node protection, a 2-SID repair path yields 99% coverage. >> >> […] >> >> The measurements listed in the tables indicate that for link and >> >> local SRLG protection, a 1-SID repair path is sufficient to protect >> >> more than 99% of the prefix in almost all cases. For node >> >> protection, 2-SID repair paths yield 99% coverage. >> >> This seems like a duplicate. I would suggest removing the second >> >> paragraph. >> >> NEW: >> >> The measurement below indicates that, for link and local SRLG >> >> protection, a 1-SID repair path delivers more than 99% coverage. For >> >> node protection, a 2-SID repair path yields 99% coverage. >> >> In addition, text is not strictly correct. It’s not “a 1-SID repair >> >> path” but “a 1-SID or less repair path. Idem for “2-SID. >> >> Hence NEW2: >> >> The measurement below indicates that, for link and local SRLG >> >> protection, a 1-SID or less repair path delivers more than 99% >> >> coverage. For >> >> node protection, a 2-SID or less repair path yields 99% coverage. >> >> Feel free to reword in a better way. >> >> -- >> >> Appendix A >> >> Nit picking… I would propose >> >> OLD: 100.0% >> >> NEW: 100% >> >> (in all tables) >> >> (as it’s mathematically not possible to go beyond 100%, the extra decimal >> >> digit is useless, while slightly reduce readability) >> >> Thanks, >> >> Best regards, >> >> --Bruno >> >> -----Original Message----- >> >> From: [email protected] <mailto:[email protected]> >> >> <[email protected] <mailto:[email protected]>> >> >> Sent: Thursday, September 4, 2025 6:19 PM >> >> To: [email protected] <mailto:[email protected]>; >> >> [email protected] <mailto:[email protected]>; [email protected] >> >> <mailto:[email protected]>; >> >> [email protected] <mailto:[email protected]>; >> >> DECRAENE Bruno INNOV/NET >> >> <[email protected] <mailto:[email protected]>>; >> >> [email protected] <mailto:[email protected]> >> >> Cc: [email protected] <mailto:[email protected]>; >> >> [email protected] <mailto:[email protected]>; >> >> [email protected] <mailto:[email protected]>; >> >> [email protected] <mailto:[email protected]>; >> >> [email protected] <mailto:[email protected]>; >> >> [email protected] <mailto:[email protected]> >> >> Subject: AUTH48: RFC-to-be 9855 >> >> <draft-ietf-rtgwg-segment-routing-ti-lfa-21> for your review >> >> >> >> ---------------------------------------------------------------------- >> >> ---------------------------------------- >> >> CAUTION : This email originated outside the company. Do not click on any >> >> links or open attachments unless you are expecting them from the sender. >> >> ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne >> >> cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de >> >> connaitre l'expéditeur. >> >> ---------------------------------------------------------------------- >> >> ---------------------------------------- >> >> *****IMPORTANT***** >> >> Updated 2025/09/04 >> >> 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 >> >> * [email protected] <mailto:[email protected]> (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). >> >> * [email protected] >> >> <mailto:[email protected]>, 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, >> >> [email protected] <mailto:[email protected]> >> >> will be re-added to the CC list and its addition will be noted at >> >> the top of the message. >> >> You may submit your changes in one of two ways: >> >> An update to the provided XML file >> >> — OR — >> >> An explicit list of changes in this format Section # (or indicate >> >> Global) >> >> OLD: >> >> old text >> >> NEW: >> >> new text >> >> You do not need to reply with both an updated XML file and an explicit >> >> list of changes, as either form is sufficient. >> >> We will ask a stream manager to review and approve any changes that seem >> >> beyond editorial in nature, e.g., addition of new text, deletion of text, >> >> and technical changes. Information about stream managers can be found in >> >> the FAQ. Editorial changes do not require approval from a stream manager. >> >> Approving for publication >> >> -------------------------- >> >> To approve your RFC for publication, please reply to this email stating >> >> that you approve this RFC for publication. Please use ‘REPLY ALL’, as >> >> all the parties CCed on this message need to see your approval. >> >> Files >> >> ----- >> >> The files are available here: >> >> https://www.rfc-editor.org/authors/rfc9855.xml >> >> https://www.rfc-editor.org/authors/rfc9855.html >> >> https://www.rfc-editor.org/authors/rfc9855.pdf >> >> >> >> https://www/. >> >> rfc-editor.org >> >> <http://rfc-editor.org/>%2Fauthors%2Frfc9855.txt&data=05%7C02%7Cbruno.decraene%4 >> >> 0orange.com >> >> <http://0orange.com/>%7Cc7a9fd8845a54486865708ddf0805a40%7C90c7a20af34b40bfbc48b >> >> 9253b6f5d20%7C0%7C0%7C638931156315194686%7CUnknown%7CTWFpbGZsb3d8eyJFb >> >> XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI >> >> sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=V5YL9pNkXYGm6J%2FEW%2FJ1zFHOYHLWa >> >> A0SPmc83Ov0FRM%3D&reserved=0 >> >> Diff file of the text: >> >> https://www.rfc-editor.org/authors/rfc9855-diff.html >> >> >> >> https://www.rfc-editor.org/authors/rfc9855-rfcdiff.html(side by side) >> >> Diff of the XML: >> >> https://www.rfc-editor.org/authors/rfc9855-xmldiff1.html >> >> Tracking progress >> >> ----------------- >> >> The details of the AUTH48 status of your document are here: >> >> >> >> https://www/. >> >> rfc-editor.org >> >> <http://rfc-editor.org/>%2Fauth48%2Frfc9855&data=05%7C02%7Cbruno.decraene%40oran >> >> ge.com >> >> <http://ge.com/>%7Cc7a9fd8845a54486865708ddf0805a40%7C90c7a20af34b40bfbc48b9253b >> >> 6f5d20%7C0%7C0%7C638931156315247502%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU >> >> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldU >> >> IjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WheJ1a7FZEcugy1Lc5f8KdHIJbjvnPP60YDOnH >> >> k5P4I%3D&reserved=0 Please let us know if you have any questions. >> >> Thank you for your cooperation, >> >> RFC Editor >> >> -------------------------------------- >> >> RFC9855 (draft-ietf-rtgwg-segment-routing-ti-lfa-21) >> >> Title : Topology Independent Fast Reroute using Segment Routing >> >> Author(s) : A. Bashandy, S. Litkowski, C. Filsfils, P. Francois, >> >> B. Decraene, D. Voyer >> >> WG Chair(s) : Jeff Tantsura, Yingzhen Qu >> >> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde >> >> >> >> ______________________________________________________________________ >> >> ______________________________________ >> >> 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. >> > >> > ____________________________________________________________________________________________________________ >> > 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]
