Re: [Dime] RE : Re: WGLC #1 for draft-ietf-dime-agent-overload-05

[<[e-mail]>]

Ok. We can close this discussion thread.
I will review the last version of the draft.

Lionel

De : Steve Donovan [mailto:[e-mail]]
Envoyé : vendredi 24 juin 2016 16:58
À : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; [e-mail]
Objet : Re: [Dime] RE : Re: WGLC #1 for draft-ietf-dime-agent-overload-05

See my comments inline.
On 6/23/16 4:25 AM, [e-mail]<mailto:[e-mail]> wrote:
Hi Steve,

I know that you have provided a new version of the draft (that I will check) but here are some answers that were already prepared for you ☺

Regards,

Lionel

De : Steve Donovan [mailto:[e-mail]]
Envoyé : mardi 21 juin 2016 23:47
À : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; [e-mail]<mailto:[e-mail]>
Objet : Re: [Dime] RE : Re: WGLC #1 for draft-ietf-dime-agent-overload-05

Lionel,

Thanks for the review.  See my comments inline.

Regards,

Steve
On 6/15/16 4:45 AM, [e-mail]<mailto:[e-mail]> wrote:
Hi,

As indicated, here is a review of the draft for discussion.
The main focus in my review is the alignment with the RFC7683.

Regards,

Lionel

*********
1.  Introduction

[LM] I would start directly the introduction with:

   This document extends the base Diameter endpoint overload
   specification to address the case when Diameter Agents become
   overloaded. [...]

[LM] followed by a brief description of the base mechanism and to better explain then why this document "defines new overload report type".
SRD>  I'd be happy to copy the abstract to the first paragraph of the introduction.  The remainder of the introduction section explains why a new report type is defined.
[LM] ok

3.1.3.  Agent Chains

   There are also deployment scenarios where there can be multiple
   Diameter Agents between Diameter Clients and Diameter Servers.
   Examples of this type of deployment include when there are edge
   agents between Diameter networks.  Another example of this type of
   deployment is when there are multiple sets of servers, each
   supporting a subset of the Diameter traffic.

OLD:

   Examples of this type of deployment include when there are edge
   agents between Diameter networks.

NEW:

   Examples of this type of deployment include when there are edge
   agents between Diameter networks.
SRD> I don't see a suggested change.
[LM] it was a trick ☺
it is proposed:
s/edge agents between Diameter networks/Diameter agents between administrative domains
SRD> I'm ok with this change.


OLD:

   Another example of this type of
   deployment is when there are multiple sets of servers, each
   supporting a subset of the Diameter traffic.

NEW:

   Another example of this type of
   deployment is when when servers of a domain are grouped in pools,
   each pool supporting a subset of the Diameter traffic received by
   front-end proxies.
SRD> This example has already been removed based on previous comments.
[LM] ok

3.2.  Diameter Endpoint Use Cases

[LM] In this section, it would be helpful to clearly see what is different here compared to what is possible with the RFC7683.
For instance, by emphasizing from the beginning the difference between "host" and "peer" reports and between "end-to-end" and "hop-by-hop".
Otherwise, it would be difficult to understand the title "Diameter endpoint use cases" in this document.
SRD> I'm not seeing the concern here.  The section discusses the case when an endpoint would send a peer report.  Can you be more specific in suggested wording?

[LM] the whole RFC7683 is about overload report exchanged between endpoints. e.g.:
   the Diameter overload indication can be conveyed (1)
   end-to-end between servers and clients or (2) between servers and the
   Diameter Agent inside the realm and then between the Diameter Agent
   and the clients



[LM] the section 3.2 in this document starts with "This section outlines use cases for the peer overload report involving Diameter Clients and Diameter Servers." whereas, in the case of server or client, host reports are expected instead of peer report. And the notion of "endpoint" when we deal in section 3.2.1 with "hop-by-hop abatement" is not crystal clear for me. Even less when it is made reference to the rate algorithm without outlining the specificity of the Rate algo compared to the Loss algo.
SRD> If an endpoint wants to use a hop-by-hop abatement algorithm (e.g. rate) then it would send a peer report, not a host report.  That is the use case this section is addressing.


Not really sure, but the suggested text could be something like:


   As per RFC7683, the Diameter overload indication can be conveyed
   end-to-end between servers and clients, eventually via Diameter
   agents. In this case, the client is supposed to be responsible
   for applying overload abatement treatment on the Diameter
   traffic, such as for the loss overload abatement algorithm
   defined in RFC7683.

   However, some abatement algorithms could require that the overload
   abatement treatment need to be rather applied by a peer of the
  reporting node than by the Diameter endpoints. An example of
   such algorithm with hop-by-hop abatement treatment requirement is
   the rate abatement algorithm [I-D.ietf-dime-doic-rate-control].

   In such scenarios, the peer overload reports will be sent by the
   Diameter instead of the host/realm overload reports defined in
   the RFC7683.


At least, it is my understanding of the purpose of this section ☺

5.1.1.  Reacting Node Behavior

   When sending a Diameter request a DOIC node that supports the
   OC_PEER_REPORT feature MUST include an OC-Supported-Features AVP with
   an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set.

[LM] the "MUST" here is not appropriate. A DOIC node MUST insert the OC-Supported-Features AVP as per RFC7683.
It is not a new requirement introduced by this document.
It should rather be: "MUST include in the OC-Supported-Features AVP an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set."
SRD> It isn't saying that it must insert the OC-S-F AVP.  It is saying it must include the OC-S-F AVP with specific conditions.  I don't see the issue.
[LM] do you see an issue with my proposal if I find it clearer?
SRD>  Okay, if you insist. :-)


      Note: The sender of a request can be a Diameter Client or Diameter
      Server that originates the Diamter request or a Diameter Agent
      that relays the request.

[LM] Not sure that the NOTE is required here.
SRD> I'm okay with removing the note.
[LM] ok

   Support for the OC_PEER_REPORT feature does not impact the logic for
   setting of other feature bits in the OC-Feature-Vector AVP.

[LM] not sure it is relevant. If it is, could be more appropriate in section 6.1.1
SRD> I'm okay with removing this as well.
[LM] ok

   When sending a request a DOIC node that supports the OC_PEER_REPORT
   feature MUST include an OC-SourceID AVP in the OC-Supported-Features
   AVP with its own DiameterIdentity.

      Note: This allows the DOIC nodes in the path of the request to
      determine if the indication of support came from a Diameter peer
      or if the request traversed a node that does not support the
      OC_PEER_REPORT feature.

[LM] not required as it is explained in the section defining the OC-SourceID and its use is described in other sections.
SRD> The description of SourceID (we agreed to remove the OC- prefix earlier) doesn't not indicate that it MUST be included.  As such, I think this requirement is needed.
[LM] Sorry. My comment was on the NOTE just above..
SRD> Okay, I can remove it, however, I don't see the harm in it being there.


   When relaying a request that includes an OC-SourceID AVP in the OC-
   Supported-Features AVP, a DOIC node that supports the OC_PEER_REPORT
   feature must remove the received OC-SourceID AVP and replace it with
   an OC-SourceID AVP containing its own Diameter identity.

[LM] if the comments are accepted, the section could be simplified as follow:

NEW:

   When sending a Diameter request, a DOIC node that supports the
   OC_PEER_REPORT feature MUST include in the OC-Supported-Features AVP
   an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set. The
   OC-Supported-Features AVP MUST include an OC-SourceID AVP with the
   DOIC node sending the request.

   When relaying a request that includes an OC-SourceID AVP in the OC-
   Supported-Features AVP, a DOIC node that supuports the OC_PEER_REPORT
   feature must remove the received OC-SourceID AVP and replace it with
   an OC-SourceID AVP containing its own Diameter identity.
SRD>  I propose the following:

   When sending a Diameter request a DOIC node that supports the

   OC_PEER_REPORT feature MUST include an OC-Supported-Features AVP with

   an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set.



   When sending a request a DOIC node that supports the OC_PEER_REPORT

   feature MUST include a SourceID AVP in the OC-Supported-Features AVP

   with its own DiameterIdentity.



      Note: This allows the DOIC nodes in the path of the request to

      determine if the indication of support came from a Diameter peer

      or if the request traversed a node that does not support the

      OC_PEER_REPORT feature.



   When an agent relays a request that includes a SourceID AVP in the

   OC-Supported-Features AVP, a DOIC node that supports the

   OC_PEER_REPORT feature MUST remove the received SourceID AVP and

   replace it with a SourceID AVP containing its own Diameter identity.

[LM] fine but please consider my comments above.
SRD> Let me know if the new draft addresses your concerns.


5.1.2.  Reporting Node Behavior

   When receiving a request a DOIC node that supports the OC_PEER_REPORT
   feature MUST update transaction state with an indication of whether
   or not the peer from which the request was received supports the
   OC_PEER_REPORT feature.

      Note: The transaction state is used when the DOIC node is acting
      as a peer-report reporting node and needs send OC-OLR reports of
      type PEER_REPORT in answer messages.  The peer overload reports
      are only included in answer messages being sent to peers that
      support the OC_PEER_REPORT feature.

[LM] Not sure of the need for the transaction state, that is not really defined in this document, compared to the OCS entry required by the RFC7683.

[LM] the base mechanism is governed by the following requirement in RFC7683:

   A reporting node MUST NOT include the OC-Supported-Features AVP,
   OC-OLR AVP, or any other overload control AVPs defined in extension
   documents in response messages for transactions where the request
   message does not include the OC-Supported-Features AVP.  Lack of the
   OC-Supported-Features AVP in the request message indicates that there
   is no reacting node for the transaction.

[LM] is there any need to modify this requirement?
[LM] the NOTE is not required if you follow the RFC7683
SRD> Are you suggesting using OCS as the way to determine if the peer supports the peer report type?

[LM] the fact is that the Reporting node uses only the OC-Supported-Features AVP and the content or absence of the OC-Feature-Vector AVP to discover the capabilities supported by the peer. After the OCS is used to maintain the current overload state sent to a reacting node. But there is no need I think to maintain a "transaction state" to know "in advance" that a given peer support the peer report type.


   When relaying an answer message, a reporting node that supports the
   OC_PEER_REPORT feature MUST strip any SourceID AVP from the OC-
   Supported-Features AVP.

[LM] I know that it was discussed by Jean but I didn't get the conclusion: does the node strip any existing sourceID and include its own?
SRD> A relay will strip received SourceID information.  It will include its own SourceID based on the requirements statement three paragraphs later.

[LM] OK

   When sending an answer message, a reporting node that supports the
   OC_PEER_REPORT feature MUST determine if the peer to which the answer
   is to be sent supports the OC_PEER_REPORT feature. [...]

[LM] in the rest of the section, the only clarification with the basic mechanism defined in RFC7683 is on how to check the support of peer report. Some "MUST" are not appropriate as implicitly required by the support of RFC7683.
SRD> All of the requirements in this section are specific to the peer report.  I don't see any that are implicitly required by RFC7683.  Can you clarify the concern?

[LM] You are correct.

5.2.1.  Overload Control State

[LM] consistency with RFC7683 is important.
SRD>  Agreed.  In general I agree with your suggestions on this section.  I will clean up the section to make the reference to RFC7683 stronger and only talk about deltas needed for the peer report.  This should make this section much cleaner.  I'll send the resulting text in a separate email.
[LM] OK. thank you

5.2.1.1.  Reporting Node Peer Report OCS


   A DOIC Node that supports the OC_PEER_REPORT feature SHOULD maintain
   Reporting Node Peer Report OCS.  This is used to record overload
   events and build overload reports at the reporting node.

[LM] in the RFC7683, it is said:

  "A reporting node maintains OCS entries per supported Diameter
   application, per supported (and eventually selected) abatement
   algorithm, and per report type.

   An OCS entry is identified by the tuple of Application-ID, report
   type, and abatement algorithm, and it includes the following
   information (the actual information stored is an implementation
   decision):

   o  Sequence number

   o  Validity duration

   o  Expiration time

   o  Input data that is algorithm specific (for example, the reduction
      percentage for the loss abatement algorithm)"

[LM] does it apply for the peer report also? If yes, why do not reuse the text from RFC7683, with a specific reference? Especially, the mean for OCS entry identification and notion of "application" disappear in this document.

   If different abatement specific contents are sent to each peer then
   the reporting node MUST maintain a separate peer node peer report OCS
   entry per peer to which a peer overload report is sent.

      Note: The rate overload abatement algorithm allows for different
      rates to be sent to each peer.

[LM] not sure that it is required if it is said that there is an OCS entry per peer from the beginning.

   The Reporting Node Peer Report OCS entry MAY include the following
   information (the actual information stored is an implementation
   decision):

[LM] see comment above

5.2.1.2.  Reacting Node Peer Report OCS

   A DOIC node that supports the OC_PEER_REPORT feature SHOULD maintain
   Reacting Node Peer Report OCS for each peer with which it
   communicates.  This is used to record overload reports received from
   peer nodes.

   A Reacting Node Peer Report OCS entry is identified by the
   DiameterIdentity of the peer as communicated during the RFC6733
   defined Capability Exchange procedure.

   The Reacting Node Peer Report OCS entry MAY include the following
   information (the actual information stored is an implementation
   decision):

   o  Sequence number

   o  Expiration Time

   o  Abatement Algorithm

   o  Algorithm specific input data (for example, the Reduction
      Percentage for the Loss Abatement Algorithm)

[LM] in RFC7683, we have:

  "A reacting node maintains the following OCS per supported Diameter
   application:

   o  a host-type OCS entry for each Destination-Host to which it sends
      host-type requests and

   o  a realm-type OCS entry for each Destination-Realm to which it
      sends realm-type requests.

   A host-type OCS entry is identified by the pair of Application-ID and
   the node's DiameterIdentity.

   A realm-type OCS entry is identified by the pair of Application-ID
   and realm.

   The host-type and realm-type OCS entries include the following
   information (the actual information stored is an implementation
   decision):

   o  Sequence number (as received in OC-OLR; see Section 7.3)

   o  Time of expiry (derived from OC-Validity-Duration AVP received in
      the OC-OLR AVP and time of reception of the message carrying
      OC-OLR AVP)

   o  Selected abatement algorithm (as received in the OC-Supported-
      Features AVP)

   o  Input data that is abatement algorithm specific (as received in
      the OC-OLR AVP -- for example, OC-Reduction-Percentage for the
      loss abatement algorithm)"

[LM] when adapted to this document, we should have:

   A reacting node maintains the following OCS per supported Diameter
   application:

   o  a peer-type OCS entry for each peer to which it sends
      host-type requests

   A peer-type OCS entry is identified by the pair of Application-ID and
   the peer's DiameterIdentity.

   The peer-type OCS entry include the following
   information (the actual information stored is an implementation
   decision):

   o  Sequence number (as received in OC-OLR; see Section 7.3)

   o  Time of expiry (derived from OC-Validity-Duration AVP received in
      the OC-OLR AVP and time of reception of the message carrying
      OC-OLR AVP)

   o  Selected abatement algorithm (as received in the OC-Supported-
      Features AVP)

   o  Input data that is abatement algorithm specific (as received in
      the OC-OLR AVP -- for example, OC-Reduction-Percentage for the
      loss abatement algorithm)

[LM] is there any reason to deviate from this approach?

5.2.2.  Reporting Node Maintenance of Peer Report OCS

   A reporting node SHOULD create a new Reporting Node Peer Report OCS
   entry Section 5.2.1.1 in an overload condition and sending a peer
   overload report to a peer for the first time.

[LM] "sending" is not part of the OCS entry maintenance

      If the reporting node knows that there are no reacting nodes
      supporting the OC_PEER_REPORT feature then the reporting node can
      choose to not create OCS entries.

   All rules for managing the reporting node OCS entries defined in
   [RFC7683] apply to the peer report.

[LM] I think that there is nothing specific to peer report here. Only the last paragraph could be kept.

5.2.3.  Reacting Node Maintenance of Peer Report OCS

   When a reacting node receives an OC-OLR AVP with a report type of
   peer it MUST determine if the report was generated by the Diameter
   peer from which the report was received.

   If the DiameterID in the SourceID contained in the OLR matches the
   DiameterIdentity of the peer from which the request was received then
   the report was received from a Diameter peer.

[LM] As discussed above, the match is performed per application in RFC7683. Any reason to deviate?

   If a reacting node receives an OC-OLR AVP of type peer and the
   SourceID does not match the ID of the Diameter peer from which the
   request was received then the reacting node MUST ignore the overload
   report.

[LM] s/SourceID/DiemeterIdentity contained in the SourceID AVP
     s/ID of the Diameter peer/DiameterIdentity

   In all cases, if the reacting node is a relay then it MUST strip the
   OC-OLR AVP from the message.

[LM] not part of the OCS entry maintenance.

   If the Peer Report OLR was received from a Diameter peer then the
   reacting node MUST determine if it is for an existing or new overload
   condition.

   The OLR is for an existing overload condition if the reacting node
   has an OCS that matches the received OLR.  For a peer report-type
   this means the DiameterIdentity received in the SourceID AVP matches
   the DiameterIdentity of an existing peer report OLR.

[LM] Based on RFC7683, For peer report, the text could be:

  "The OLR is for an existing overload condition if a reacting node has
   an OCS that matches the received OLR.

   For a peer report, this means it matches the Application-ID and the
   peer's DiameterIdentity in an existing peer OCS entry."

[LM] OK with rest of the section

[LM] No specific comment on the rest of the document.


De : Lionel MORAND<mailto:[e-mail]>
Envoyé : ‎lundi‎ ‎13‎ ‎juin‎ ‎2016 ‎22‎:‎25
À : Steve Donovan<mailto:[e-mail]>, Maria Cruz Bartolome<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>


Hi Steve,

Reviewing the draft, I have additional comments that I will post tomorrow.

Regards,

Lionel

Envoyé de mon Orange Nura 2
Le 13 juin 2016 22:14, Steve Donovan <[e-mail]><mailto:[e-mail]> a écrit :
Lionel,
Jouni,

I've incorporated all of the suggested changes into the draft.  I
believe the time period for the WGLC has expired.  Please advise if I
should publish the new version or if you want to wait for more comments.

Regards,

Steve

On 6/13/16 8:06 AM, [e-mail]<mailto:[e-mail]> wrote:
> Thank you for the useful discussion.
> I'm OK with the output and the proposed changes.
>
> regards,
>
> Lionel
>
>> -----Message d'origine-----
>> De : DiME [mailto:[e-mail]] De la part de Maria Cruz Bartolome
>> Envoyé : vendredi 10 juin 2016 10:02
>> À : Steve Donovan; [e-mail]<mailto:[e-mail]>
>> Objet : Re: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05
>>
>>>>> 2. Clause 5.2.3
>>>>>       "In all cases, if the reacting node is a relay then it MUST strip the
>>>>>        OC-OLR AVP from the message."
>>>>>
>>>>>        But, will the relay react against the overload report received? i.e. is it a
>> "reacting node" or it is just relaying the message?
>>>> SRD> That is determined by the other statements in that section. If
>>>> SRD> the
>>>> SourceID received in the message matches that of a peer then the relay is a
>> reacting node.  If it doesn't match then it is not a reacting node.  Either way, the
>> OC-OLR AVP is stripped.
>>>> MCRUZ> But a relay can't be a "reacting node", can it? A relay does not read
>> or understand any AVP apart from routing related AVPs.
>>> SRD> Yes a relay is the reacting node for any next hop that generates
>>> SRD> a
>>> peer overload report.  As with base DOIC, a relay must be able to handle DOIC
>> AVPs, in addition to the routing AVPs.
>>> MCRUZ> In DOIC this is not explicitly mentioned, and I do not see the need.
>> Moreover, this changes the definition of what a relay is.
>> SRD2> You are correct, it should say agent, not relay.  In my mind an
>> agent that is a relay can also be a reacting node by expanding the definition of
>> routing related AVPs to include DOIC AVPs.  I consider this valid as these AVPs,
>> and the LOAD AVPs all impact routing decisions.  This, however, is somewhat
>> academic as the practical impact of calling an agent that is a reacting node a
>> relay or a proxy isn't meaningful.
>>
>> SRD> I'll change the word in the above clause to agent.
>> MCRUZ> Thanks Steve. I think this change applies to other places in the draft.
>>
>>
>>>>> 8. Clause 4
>>>>>
>>>>> "Any messages that survive throttling due
>>>>>        to host or realm reports should then go through abatement for the
>>>>>        peer overload report."
>>>>>
>>>>>       There is an interaction between PEER and HOST reports. The reduction of
>> traffic towards a HOST reduces as well the traffic through the agents in the path.
>> This should be taken into account when applying reduction for that particular
>> PEER. However, depending on the routing schema it may not be straight forward
>> to identify what is the reduction for each agent path when reducing traffic
>> towards a HOST.
>>>> SRD> The goal of this statement is to say that when a Diameter node
>>>> SRD> is
>>>> applying overload abatement algorithms, the order in which active
>>>> overload reports are applied is host/realm report first and then peer
>>>> report.  In other words, abatement is done for traffic being sent to
>>>> a host and then independent abatement is done for the peer to which
>>>> the request is to be routed.  If these are treated as independent
>>>> actions then I don't understand the issue you are raising.
>>>>
>>>> MCRUZ> If you think the PEER algorithm is RATE, then there is not
>> interaction, as long as when PEER abatement is performed after HOST/REALM,
>> it simply keeps a RATE. However, if the PEER algorithm is LOSS, when performed
>> after HOST/REALM it should be stated that it is the initial traffic (before any
>> HOST/REALM abatement) the one that should be taken into account. Then, I
>> think a clarification is required.
>>> SRD> While it is true that, as stated, the presence of a HOST LOSS
>>> report and a peer LOSS report could result in extra messages being abated, I
>> would prefer to keep the definition of the interaction as simple as possible and
>> not change the requirement. My reasoning is that there is value in keeping it
>> simple, especially given that it a self correcting scenario.  The next hop will see
>> more of a reduction than it was expecting and will subsequently update the
>> requested reduction.  If there isn't consensus on this approach we can do a
>> special case on this scenario.
>>> MCRUZ> I think we need to cover these cases, since having extra throttling
>> even if it is compensated later will cause first unnecessary drop messages and
>> second traffic oscillations. Both things should be avoided.
>> SRD> How about if we add the following:
>>
>>        Any messages that survive throttling due to host or realm reports should then
>> go through abatement for the
>>        peer overload report.  In this scenario, when doing abatement on the PEER
>> report, the reacting node SHOULD
>>        take into consideration the number of messages already throttled by the
>> handling of the HOST/REALM report abatement.
>>
>>            Note: The goal is to avoid traffic oscillations that might result from
>> throttling of messages for both
>>            the HOST/REALM overload reports and the PEER overload reports.  This is
>> especially a concern if both
>>            reports are of type LOSS.
>>
>> MCRUZ> I think this is fine. Thanks
>>
>> _______________________________________________
>> DiME mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/dime
> _________________________________________________________________________________________________________________________
>
> 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.

_________________________________________________________________________________________________________________________



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.


_________________________________________________________________________________________________________________________

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.