[Idr] Re: [iesg] Re: Re: Re: Mohamed Boucadair's Discuss on draft-ietf-idr-vpn-prefix-orf-40: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Wei, all,

Thank you for the follow-up. -44 addresses all the comments I had. These changes are really great.

Thank you for accommodating.

Cheers,
Med

De : Wei Wang <[e-mail]>
Envoyé : lundi 1 juin 2026 03:09
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; Aijun Wang <[e-mail]>; [e-mail]; '【外部账号】 Ketan Talaulikar' <[e-mail]>
Cc : 'The IESG' <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : [iesg] Re: [Idr] Re: Re: Mohamed Boucadair's Discuss on draft-ietf-idr-vpn-prefix-orf-40: (with DISCUSS and COMMENT)

Hi Med,

I have uploaded the -v44 of draft-ietf-idr-vpn-prefix-orf. I hope this version can solve your concerns and discuss points in the newest ballot. Please see the in-line replies with [WW].


Hi Wei, Aijun, Haibo, Gyan, and Jie,



Thank you for the discussion and changes made so far. I updated my ballot

[1][2] to reflect the changes made in 37 vs 40 and 40 vs. 42 [3].



I'm keeping the COMMENT part for which I don't see relevant changes agreed in

the email discussion (search for UPDATE below):



# Keyur included the following in his write-up:



“The third version of the text was clear, but the operators were split in

their opinion on whether the functions was valuable or dangerous.”



I would expect the document to include a discussion of the potential issues

that need assessment for confirmation/information as a part of the experimental

work.



Can we please have such discussion in the document?



UPDATE: "[WAJ] We will try to add one additional section in section 7

"Operational Considerations" to discuss the possible challenges that are arose

from this mechanism."

[WW] We added Section 7.4 Potential Operational Challenges to disscuss the potential issues that the experiment needs to assess. Please see the details in: https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-44



# Experiment Goals

 I suggest to move at least appendix ”Experimental topology” to be in the main body for better visibility of the intended scope.

[WW]We have moved the text in Appendix A.1 to Section 7.1.



 I also suggest that text to be expanded to cover some items that will be assessed and used as objective criteria to declare success or failure. For example, it would be helpful to have some data about:

 * impact on the routing stability

* impact on the CPU vs configuration

* overall efficiency

* tune the quota formula and its optimization

* operational complications

 UPDATE: "[WAJ] We will try to add one general intra-domain topology in the beginning of the section 7, and analyze the above concerns."

[WW] We added Section 7.5 Experimental Assessment Criteria to state the items needs to be assessed in the experiment, and also describe the success criterias of them.



## Also, the following should be part of the assessment in the exp, unless you already have data to back the claims:   However, PEs still need to parse the incoming BGP messages,   which consumes CPU cycles and further burdens the overloaded PE. This is still applicable even with the feature in the draft if the peer does not honor the signal.

[WW] We mentioned this point in Section 3.5, and also list this assessment in Section 7.5.



## The following may have implication on stability. Please consider adding assessing that impact as part of the aspects to be assessed during exp work:

 CURRENT:   Each device makes a local judgment to determine whether   it needs to send a VPN Prefix ORF message to its upstream peer.

 UPDATE: "[WAJ] The above is just "qualitative analysis", not "quantitative analysis".  Is there any inaccurate for the " qualitative analysis "? And, if the peer does not honor the signal, it fallbacks to the existing solution and then is not the fault of the proposed VPN prefix ORF mechanism?" There is not text calling out this issue.

[WW] This point has been mentioned in Section 7.5.



 # Missing citation CURRENT:

*  Provider Edge (PE) - Customer Edge (CE) edge peer Maximum Prefix You may cite rfc9182#section-7.6.3.2 (bgp-max-prefix, warning-threshold, violate-action).

 UPDATE: "[WAJ] Will add the reference.", but I don't see it implemented.
[WW] RFC9182 has been referenced.


Best Regards,
Wei


Original
________________________________
From: mohamed.boucadair <[e-mail]<mailto:[e-mail]>>
Date: 2026-05-20 18:50
To: Aijun Wang <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, '【外部账号】 Ketan Talaulikar' <[e-mail]<mailto:[e-mail]>>
Cc: 'The IESG' <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [Idr] Re: [iesg] Re: Mohamed Boucadair's Discuss on draft-ietf-idr-vpn-prefix-orf-40: (with DISCUSS and COMMENT)

Hi Aijun, all,

Thank you for the changes. I cleared my DISCUSS right now.

Please note that there are some points that were agreed in the thread but for which I don't see the changes were implemented. I listed those in my new ballot. I trust you will take care of those.

Thank you for your patience.

Cheers,
Med

> -----Message d'origine-----
> De : Aijun Wang <[e-mail]<mailto:[e-mail]>>
> Envoyé : mercredi 20 mai 2026 04:06
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>;
> [e-mail]<mailto:[e-mail]>; '【外部账号】 Ketan Talaulikar'
> <[e-mail]<mailto:[e-mail]>>
> Cc : 'The IESG' <[e-mail]<mailto:[e-mail]>>; draft-ietf-idr-vpn-prefix-
> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>
> Objet : RE: [Idr] Re: [iesg] Re: Mohamed Boucadair's Discuss on
> draft-ietf-idr-vpn-prefix-orf-40: (with DISCUSS and COMMENT)
>
>
> Hi, Med:
>
> We have posted the new version and changed the related text to
> less affirmative tense.
> Wish it can address your concern.
>
> Thanks for your review and the discussions！
>
> To Ketan: can we end the IESG Last call and forward it then?
>
> Aijun
>
> -----Original Message-----
> From: [e-mail]<mailto:[e-mail]>
> [mailto:[e-mail]] On Behalf Of
> [e-mail]<mailto:[e-mail]>
> Sent: Monday, May 18, 2026 9:39 PM
> To: [e-mail]<mailto:[e-mail]>; '【外部账号】 Ketan Talaulikar'
> <[e-mail]<mailto:[e-mail]>>
> Cc: 'The IESG' <[e-mail]<mailto:[e-mail]>>; draft-ietf-idr-vpn-prefix-
> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>
> Subject: [Idr] Re: [iesg] Re: Mohamed Boucadair's Discuss on
> draft-ietf-idr-vpn-prefix-orf-40: (with DISCUSS and COMMENT)
>
> Hi Aijun,
>
> Thank you for the follow-up. Focusing on this part:
>
> > [WAJ] ...
> > We can consider to change some rephrases in the document if you
> think
> > they are too affirmative.
>
> Yes, please. Thanks.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>> Envoyé :
> jeudi
> > 14 mai 2026 04:55 À : '【外部账号】 Ketan Talaulikar'
> > <[e-mail]<mailto:[e-mail]>>; BOUCADAIR Mohamed INNOV/NET
> > <[e-mail]<mailto:[e-mail]>> Cc : 'The IESG' <[e-mail]<mailto:[e-mail]>>;
> > draft-ietf-idr-vpn-prefix- [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> > [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]> Objet : [iesg]
> Re:
> > Mohamed Boucadair's Discuss on draft-ietf-idr-
> > vpn-prefix-orf-40: (with DISCUSS and COMMENT)
> >
> >
> > Hi, Med:
> >
> > It seems that you are concerning the efficiency of this
> approach,
> > especially comparing with other existing mechanisms.
> > Let's review the proposal from another point of view:
> >
> > As indicated in
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-vpn-prefix-
> orf-
> > 40%23name-existing-
> >
> solutions&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C48659a74
> >
> 63d34068362508deb1643300%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> >
> 0%7C639143241083331048%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
> >
> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf
> >
> Q%3D%3D%7C0%7C%7C%7C&sdata=sYUKKjHil6Kuf27s2FkgPhjgtRqsX7HZKp0kcAW
> > hFxc%3D&reserved=0, the most relevant solution to such scenario,
> is to
> > configure the PE-CE maximum prefix at each remote side PE, the
> > receiving PE can only act passively for the potential overload
> VPN
> > routes risks.
> > Any misconfiguration on any remote PE can lead to such outrage.
> >
> > Then we think it is necessary to enhance the BGP protocol to let
> it
> > can control or mitigate such outrage actively, especially in the
> > shared BGP sessions scenarios(various VPN circumstances).
> > Some detail responses are inline below.
> >
> > Aijun
> >
> > -----Original Message-----
> > From: [e-mail]<mailto:[e-mail]>
> > [mailto:[e-mail]] On Behalf Of 【外部账号】
> > Ketan Talaulikar
> > Sent: Wednesday, May 13, 2026 4:01 PM
> > To: [e-mail]<mailto:[e-mail]>
> > Cc: The IESG <[e-mail]<mailto:[e-mail]>>; draft-ietf-idr-vpn-prefix-
> [e-mail]<mailto:[e-mail]>;
> > [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>
> > Subject: Re: [iesg] Mohamed Boucadair's Discuss on draft-ietf-
> idr-
> > vpn-prefix-orf-40: (with DISCUSS and COMMENT)
> >
> > Hi Med,
> >
> > To be clear, can you confirm that your comment is specific to
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >
> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw<http://w/>
> ww.ietf.org%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C38b
> f3581c4784707e64308deb6144f21%7C90c7a20af34b40bfbc48b9253b6f5d20%7
> C0%7C0%7C639148395523819563%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG
> kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldU
> IjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=E3yr3JVOPNTtwgEFmyrWtLracIs2mFJSx5
> V3jG1L18g%3D&reserved=0%2Farchive%2Fid%2Fdraft-ietf-idr-vpn-
> prefix-orf-
> > 40.html%23name-vpn-prefix-orf-tlv-
> >
> types&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C48659a7463d3
> >
> 4068362508deb1643300%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> >
> 639143241083349712%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU
> >
> sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D
> >
> %3D%7C0%7C%7C%7C&sdata=wEp%2FkDvBtYFeuhBADPGHR7Bl3giS6HEBlGNHhOF78
> > h4%3D&reserved=0
> > ?
> >
> > Assuming yes, I can't say whether or not the WG will endorse
> further
> > extensions or proposals. That would be something for the WG to
> decide
> > when something comes up. Is it required to preclude this or
> constrain
> > the WG?
> > [WAJ] These TLVs are necessary even for the one-hop VPN Prefix
> ORF
> > message.
> >
> > Is your concern with the FCFS allocation under this registry?
> And if
> > so, perhaps the authors and WG can consider changing the entire
> > codepoint space to IETF Review.
> > [WAJ] This is newly created code point, and has no conflict with
> any
> > other existing code points.
> >
> > Thanks,
> > Ketan
> >
> >
> > On Wed, May 13, 2026 at 8:24 AM <[e-mail]<mailto:[e-mail]>>
> > wrote:
> >
> > > Re-,
> > >
> > >
> > >
> > > Thanks Ketan.
> > >
> > >
> > >
> > > I’m not sure to get the point about the BGP hygiene here.
> > Creating new
> > > registries (read, allow for future extensions that may or may
> > not
> > > come) for a feature to be yet assessed is a bit weird. Does
> the
> > WG
> > > envisage to endorse extensions based on this feature without
> > waiting
> > > for stable/sufficient experience with the base spec?
> >
> > [WAJ] Such new registries are necessary even for the one-hop VPN
> > prefix ORF mechanism.
> >
> > >
> > >
> > >
> > > Cheers,
> > >
> > > Med
> > >
> > >
> > >
> > > *De :* Ketan Talaulikar <[e-mail]<mailto:[e-mail]>> *Envoyé :*
> > mercredi 13
> > > mai 2026 09:11 *À :* BOUCADAIR Mohamed INNOV/NET
> > > <[e-mail]<mailto:[e-mail]>> *Cc :* The IESG
> <[e-mail]<mailto:[e-mail]>>;
> > > [e-mail]<mailto:[e-mail]>;
> > > [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> > [e-mail]<mailto:[e-mail]>
> > > *Objet :* Re: [iesg] Mohamed Boucadair's Discuss on
> > > draft-ietf-idr-vpn-prefix-orf-40: (with DISCUSS and COMMENT)
> > >
> > >
> > >
> > >
> > >
> > > Hi Med,
> > >
> > >
> > >
> > > Thanks for sharing your updated ballot. Please see the inline
> > > responses below.
> > >
> > >
> > >
> > > I request the authors to consider this for the upcoming
> document
> > update.
> > >
> > >
> > >
> > >
> > >
> > > On Wed, May 13, 2026 at 7:47 AM Mohamed Boucadair via
> > Datatracker <
> > > [e-mail]<mailto:[e-mail]>> wrote:
> > >
> > > Mohamed Boucadair has entered the following ballot position
> for
> > > draft-ietf-idr-vpn-prefix-orf-40: Discuss
> > >
> > > When responding, please keep the subject line intact and reply
> > to all
> > > email addresses included in the To and CC lines. (Feel free to
> > cut
> > > this introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> > >
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > www.
> > > ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-
> ballot-
> > posi&d
> > >
> >
> ata=05%7C02%7Cmohamed.boucadair%40orange.com%7C48659a7463d34068362
> > 508d
> > >
> >
> eb1643300%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63914324108
> > 3370
> > >
> >
> 337%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD
> > AwMC
> > >
> >
> IsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd
> > ata=
> > > sypyvGyAVsS%2BXWj8u1dffotyh17NY6U1wjpNXSWIa6w%3D&reserved=0
> > > tions/ for more information about how to handle DISCUSS and
> > COMMENT
> > > positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found
> > here:
> > >
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > data
> > > tracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-vpn-prefix-
> > orf%2F&data=05%7C02
> > >
> >
> %7Cmohamed.boucadair%40orange.com%7C48659a7463d34068362508deb16433
> > 00%7
> > >
> >
> C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639143241083404175%7CU
> > nkno
> > >
> >
> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiO
> > iJXa
> > >
> >
> W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MBzQ4oQ
> > A8Wc
> > > 4ZlpfZGEuxQvSnMitWhUsUdS8LbjC%2BaA%3D&reserved=0
> > >
> > >
> > >
> > > --------------------------------------------------------------
> --
> > ------
> > > DISCUSS:
> > > --------------------------------------------------------------
> --
> > ------
> > >
> > > Hi Wei, Aijun, Haibo, Gyan, and Jie,
> > >
> > > Thank you for the discussion and changes made so far. I
> updated
> > my
> > > ballot [1] to reflect the changes made 37/40 [2].
> > >
> > > # Be less affirmative
> > >
> > > I don’t think it is adequate to be affirmative about the
> > enhancements
> > > in the spec as that need to be further assessed. I suggest to
> > consider
> > > the various affirmative statements in the doc and make those
> as
> > to be
> > > further confirmed as part of the experiment.
> > >
> > > Example of such statements are “The VPN Prefix ORF mechanism
> > improves
> > > upon this by enabling the ..”
> > >
> > > UPDATE: I still see this statement in the document. I don't
> > think we
> > > can claim this compared to controlling the load at the source
> > > (attachment circuit
> > > level)
> > > or by policy. Whether this is an improvement or the mechanism
> > has
> > > positive impact in general is to be assessement. That's the
> > whole
> > > poingt of having this mechanums as Experimental. Please review
> > such
> > > claims in the document and expresss them as "intended" rather
> > than
> > > affirmative.
> >
> > [WAJ] Depending on the policy, or at the attachment circuit
> level
> > can't eliminate the risks of overload VPN routes.
> > The PE itself should have also some risk mitigation mechanism.
> > This is similar as for maximum prefix mechanism, in which, the
> > receiver of overload prefixes can break down the BGP session
> directly.
> > We can consider to change some rephrases in the document if you
> think
> > they are too affirmative.
> >
> > >
> > >
> > >
> > > KT> I see your point. Authors, please consider rephrasing
> those
> > > KT> statements
> > > as intents or goals rather than affirmations.
> > >
> > >
> > >
> > >
> > > # De we really need to create new registries at this stage?
> > >
> > > Given the current state of the technology, I don’t see
> appealing
> > > arguments to create new registries under the BGP registry
> group
> > for a
> > > feature that need further assessment.
> > >
> > >
> > >
> > > KT> Yes, we do need those registries. This ensures an up-to-
> date
> > and
> > > accurate reflection of code points for BGP features. Because
> BGP
> > has a
> > > continuous flow of features, I consider this as necessary
> > hygiene
> > > regardless of the document's intended status.
> > >
> > >
> > >
> > >
> > >
> > > --------------------------------------------------------------
> --
> > ------
> > > COMMENT:
> > > --------------------------------------------------------------
> --
> > ------
> > >
> > > # Keyur included the following in his write-up:
> > >
> > > “The third version of the text was clear, but the operators
> were
> > split
> > > in their opinion on whether the functions was valuable or
> > dangerous.”
> > >
> > > I would expect the document to include a discussion of the
> > potential
> > > issues that need assessment for confirmation/information as a
> > part of
> > > the experimental work.
> > >
> > > Can we please have such discussion in the document?
> >
> > [WAJ] Actually,
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-vpn-prefix-
> orf-
> > 40%23name-general-considerations-for-
> >
> &data=05%7C02%7Cmohamed.boucadair%40orange.com%7C48659a7463d340683
> >
> 62508deb1643300%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63914
> >
> 3241083453858%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi
> >
> OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7
> >
> C0%7C%7C%7C&sdata=vIW1HUhSuMuRrG7gMjRNfF8uMIS1tQ0JmzWiRhchtqE%3D&r
> > eserved=0 has already added some descriptions.
> > If you expect some quantitative results, it should be provided
> fairly
> > via some open test and comparison? But I doubt it can compare
> with the
> > complex policy, error-prone approach.
> > Anyway, we think controlling, or depending only on the remote
> peers'
> > behavior is not enough.
> >
> > >
> > >
> > >
> > > KT> I will leave this to the authors' discretion. I am not
> sure
> > how
> > > KT> much
> > > such discussions (which are essentially individual opinions)
> > help when
> > > captured in a protocol specification (even an experimental
> one).
> > If
> > > you have suggestions for potential issues that can be added
> > (beyond
> > > what came out of the WG and got captured in the document),
> those
> > would
> > > be very welcome.
> >
> > [WAJ] I agree with Ketan.
> >
> > >
> > >
> > >
> > >
> > > # Experiment Goals
> > >
> > > I suggest to move at least appendix ”Experimental topology” to
> > be in
> > > the main body for better visibility of the intended scope. I
> > also
> > > suggest that text to be expanded to cover some items that will
> > be
> > > assessed and used as objective criteria to declare success or
> > failure.
> > > For example, it would be helpful to have some data about:
> > >
> > > * impact on the routing stability
> > > * impact on the CPU vs configuration
> > > * overall efficiency
> > > * tune the quota formula and its optimization
> > > * operational complications
> > >
> > >
> > >
> > > KT> I will leave this to the authors, the WG and seek the WG
> > chairs'
> > > KT> help=
>
> __________________________________________________________________
> __________________________________________
> 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.
> _______________________________________________
> Idr mailing list -- [e-mail]<mailto:[e-mail]>
> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

____________________________________________________________________________________________________________
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.
_______________________________________________
Idr mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

____________________________________________________________________________________________________________
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.