Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

[Steve Donovan <[e-mail]>]

Lionel,

Please see comments inline.

Regards,

Steve

On 3/26/14 8:15 AM, [e-mail] wrote:
>
> When determining if a request should be throttled, there are three cases:
>
> - Only a Realm report (based on the definition from the meeting)
> matches the message -- In this case the Realm report MUST be used to
> determine if the message is throttled.
> - Only a Host report matches the message -- In this case the Host
> report MUST be used to determine if the message is throttled.
> - Both a Realm and Host report match the message -- In this case the
> Host report MUST be used to determine if the message is throttled and
> throttling based on the Realm report MUST NOT also be applied to the
> message.
>
> I'm ok at the moment with this wording, but I don't think we've
> thought through the implications of prioritizing Host reports over
> Realm reports when both apply.  As such, this is open to change in a
> future version of the draft.
>
> */[LM] OK/*
>
>
SRD> Just to be 100% clear on the first bullet above.  This, I believe,
is where we have confusion and disagreement on this topic.

My proposal is that the Realm report effects 100% of messages that
contain a Realm AVP that matches the Realm report.

The other definition is that the report effects only messages that match
the Realm in the report AND do not have a Destination-Host AVP. 

These are very different definitions and is why it is important to
define what is meant by Realm reports.
>
> >
>
>       > About renaming "Realm" as "Realm-Routed-Request", no strong
>
>       issue as
>
>       > soon as the principle above are kept.
>
> SRD> If we go with your proposal above then there is no name change
> but rather a change in the definition of Realm report.
>
> */[LM] don't think that the current definition needs to be changed.
> However the behavior of the reacting node should be clarified when
> both Host and Realm report type are applicable to a single message./*
>
>
SRD> See above.  Plus, the -01 draft contains BOTH definitions, so it
needs to be updated.
>
> If we go with Ulrich's proposal then we should change the name from
> Realm to RRR (or some other name yet to be suggested).
>
> If we go with three reports then we also need to change the name of
> the existing Realm report to RRR and redefine Realm to match the above
> logic.
>
> */[LM] let's play with only two for now./*
>
> */ /*
>
> > 
>
>       > The need for realm-based type that would apply to any request
>
>       (even
>
>       > if a "Host" exists for a destination-host in the request) was
>
>      
>
>       > challenged and not retained. Ben was supposed to lock you in
>
>       a room
>
>       > and to convince you that this last report type was not
>
>       needed.
>
> This is NOT my recollection of the decision and is NOT what is
> reflected in the minutes.  This is also NOT what you say above.
>
> Here's the relevant portion of the minutes:
>
> Report types - there was consensus that Host and Realm report types
> needed to be retained. Ben suggested that if a node sent a Realm
> report, it needed to be an absolute authority for the realm. Dave did
> not agree that agents needed to be authoritative and felt that clients
> should be able to make their own decisions on conflicting realm
> reports, which Lionel disagreed with. Maria Cruz agreed with both
> proposals because it would be deployment dependent. Steve said that
> the draft should provide guidance that a sender of the realm report
> should be an authority and that realm reports should not contradict.
> It should provide guidance on what the client should do if does
> receive different realm reports. Ben pointed out that, in the case
> where a realm was sending overload reports, individual servers could
> send Reductions of 0% in their reports to provide more information to
> clients.
>
>
> ACTION: Ben and Steve to discuss Realm-Routed-Request and come up with
> a proposal on whether to remove or to incorporate.
>
> ACTION: Next version of DOIC will keep Host and Realm and leave
> Realm-Routed-Request an open issue.
>
> ACTION: Clarify precedence of the host and realm report types and what
> actions to take when they are received.
>
> */[LM] ok/*
>
>
>
>
> >
>
>       > Lionel
>
>       >
>
>       > Envoyé depuis mon Sony Xperia SP d'Orange
>
>       >
>
>       > Steve Donovan <[e-mail]>
> <mailto:[e-mail]> a écrit :
>
>       >
>
>       > Consensus is obviously a fleeting and temporary thing.
>
>       >
>
>       > Let us make sure that we are precise in our definitions of
>
>       the
>
>       > report types we are discussing.
>
>       >
>
>       > Host report - Applies when the destination-host AVP is
>
>       present in
>
>       > the request. Realm-Routed-Request (RRR) - Applies when there
>
>       is no
>
>       > destination-host AVP in the request. Realm - Applies to 100%
>
>       of
>
>       > requests sent to the realm.
>
>       >
>
>       > These are the definitions used in our discussions in London
>
>       and in
>
>       > various places in our email discussions.
>
>       >
>
>       > Can we please agree to use these definitions going forward so
>
>       we are
>
>       > all talking about the same thing.
>
>       >
>
>       > Regards,
>
>       >
>
>       > Steve
>
>       >
>
>       > On 3/25/14 10:27 AM, [e-mail]
> <mailto:[e-mail]> wrote:
>
>       >>
>
>       >> Hi Maria Cruz, All,
>
>       >>
>
>       >>
>
>       >>
>
>       >> In the previous mail, you wrote:
>
>       >>
>
>       >>
>
>       >>
>
>       >> /That is, we have two reports, host and realm. /
>
>       >>
>
>       >> /Host applies when Destination_host is present, and then
>
>       it takes
>
>       >> precedence over Realm. If both are present, only Host is
>
>       applied./
>
>       >>
>
>       >> /Realm applies when only Destination_realm is present./
>
>       >>
>
>       >>
>
>       >>
>
>       >> And I agree with this statement. But I'm not sure that
>
>       this is the
>
>       >> case discussed by Ulrich.
>
>       >>
>
>       >>
>
>       >>
>
>       >> Whatever the name of the realm report type, is there an
>
>       agreement
>
>       >> on the description given above by Maria Cruz and
>
>       discussed in
>
>       >> London?
>
>       >>
>
>       >>
>
>       >>
>
>       >> Regards,
>
>       >>
>
>       >>
>
>       >>
>
>       >> Lionel
>
>       >>
>
>       >>
>
>       >>
>
>       >> *De :*DiME [mailto:[e-mail]] *De la part de*
>
>       Maria
>
>       >> Cruz Bartolome *Envoyé :* mardi 25 mars 2014 16:21 *À :*
>
>       Wiehe,
>
>       >> Ulrich (NSN - DE/Munich); ext Steve Donovan;
>
>       [e-mail] <mailto:[e-mail]> *Objet
>
>       >> :* Re: [Dime] Resolution on action to discuss the need
>
>       for
>
>       >> Realm-Routed-Reports
>
>       >>
>
>       >>
>
>       >>
>
>       >> Dear all,
>
>       >>
>
>       >>
>
>       >>
>
>       >> I support option 1 a well
>
>       >>
>
>       >> Cheers
>
>       >>
>
>       >> /MCruz
>
>       >>
>
>       >>
>
>       >>
>
>       >> *From:*DiME [mailto:[e-mail]] *On Behalf Of
>
>       *Wiehe,
>
>       >> Ulrich (NSN - DE/Munich) *Sent:* martes, 25 de marzo de
>
>       2014 16:15
>
>       >>  *To:* ext Steve Donovan; [e-mail]
> <mailto:[e-mail]> *Subject:* Re:
>
>       [Dime]
>
>       >> Resolution on action to discuss the need for
>
>       Realm-Routed-Reports
>
>       >>
>
>       >>
>
>       >>
>
>       >> Steve,
>
>       >>
>
>       >> Thank you for this summary.
>
>       >>
>
>       >> Please see inline.
>
>       >>
>
>       >>
>
>       >>
>
>       >> Ulrich
>
>       >>
>
>       >>
>
>       >>
>
>       >> *From:*ext Steve Donovan
>
>       [mailto:[e-mail]] *Sent:*
>
>       >> Tuesday, March 25, 2014 2:49 PM *To:* Wiehe, Ulrich (NSN
>
>       -
>
>       >> DE/Munich); [e-mail] <mailto:[e-mail]>
> <mailto:[e-mail]> <mailto:[e-mail]>
>
>       *Subject:* Re:
>
>       >> [Dime] Resolution on action to discuss the need for
>
>       >> Realm-Routed-Reports
>
>       >>
>
>       >>
>
>       >>
>
>       >> Ulrich,
>
>       >>
>
>       >> I mean going backwards from where I thought we were after
>
>       the
>
>       >> London meeting.
>
>       >>
>
>       >> We are clearly out of sync but hopefully we can fix that.
>
>       >>
>
>       >> Here's my understanding of the status of #23 and #55.
>
>       >>
>
>       >> Prior to London meeting:
>
>       >>
>
>       >> #23 status: - Agreement to change the name of existing
>
>       realm
>
>       >> reports to realm-routed-reports (RRR).
>
>       >>
>
>       >> <Ulrich>this includes agreement to keep the (newly
>
>       called)
>
>       >> realm-routed-reports</Ulrich> - Discussions were
>
>       ongoing as to the
>
>       >> need for both realm reports and RRR reports.
>
>       >>
>
>       >> <Ulrich>I would say "...as to the need for realm
>
>       reports in addition
>
>       >> to realm-routed-reports" </Ulrich>
>
>       >>
>
>       >>
>
>       >>
>
>       >> #55 status: - Agreement on adding Realm reports based on
>
>       the
>
>       >> definition that realm reports apply to all traffic sent
>
>       to the
>
>       >> realm.
>
>       >>
>
>       >> <Ulrich>This is what I'm missing. The issue has
>
>       been very briefly
>
>       >> discussed under #34 without conclusion. There was no
>
>       discussion
>
>       >> under #55</Ulrich>
>
>       >>
>
>       >>
>
>       >> - Limited discussion on the interaction between the new
>
>       realm
>
>       >> reports and the existing host and RRR reports.
>
>       >>
>
>       >> After London meeting:
>
>       >>
>
>       >> #23 status: - Tentative agreement in London meeting to
>
>       remove RRR
>
>       >> reports.
>
>       >>
>
>       >> <Ulrich>What was the technical
>
>       argument?</Ulrich>
>
>       >>
>
>       >>
>
>       >> - Ben expressed the strongest concern with this plan. 
>
>       Steve and
>
>       >> Ben took action to discuss and come back with a
>
>       recommendation.
>
>       >>
>
>       >> #55 status: - No change
>
>       >>
>
>       >> Summary: - Tentative consensus reached to move forward
>
>       with two
>
>       >> report types - host and realm, with realm having the new
>
>      
>
>       >> definition. <Ulrich>What was the technical
>
>       argument?</Ulrich>
>
>       >>
>
>       >>
>
>       >> Current status:
>
>       >>
>
>       >> #23 status: - Change the name to RRR - Whether or not to
>
>       remove
>
>       >> RRR and revisit later or keep RRR and revisit later is an
>
>       open
>
>       >> issue.
>
>       >>
>
>       >> #55 status: - My opinion is that we have at least rough
>
>       consensus
>
>       >> on the need to support realm reports.  Others might have
>
>       a
>
>       >> different opinion.
>
>       >>
>
>       >> <Ulrich> There was no comment posted to issue #55,
>
>       also no
>
>       >> proposed solution, so I cannot see where the consensus
>
>       came
>
>       >> from</Ulrich>
>
>       >>
>
>       >>
>
>       >>
>
>       >> Summary: - I believe we have three options:
>
>       >>
>
>       >> 1) Support host and RRR reports 2) Support host and Realm
>
>       reports
>
>       >> -- This was the tentative plan coming out of the London
>
>       meeting
>
>       >>
>
>       >> < Ulrich> There is not even an issue number
>
>       identifying problems
>
>       >> with RRR and proposing to remove RRR</Ulrich>
>
>       >>
>
>       >>
>
>       >> 3) Support host, RRR and Realm reports
>
>       >>
>
>       >> <Ulrich> I support option 1</Ulrich>
>
>       >>
>
>       >>
>
>       >> Regards,
>
>       >>
>
>       >> Steve
>
>       >>
>
>       >> On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich)
>
>       wrote:
>
>       >>
>
>       >> Steve,
>
>       >>
>
>       >> I don't think we are going backwards (we may be out of
>
>       synch
>
>       >> though)
>
>       >>
>
>       >>
>
>       >>
>
>       >> Can you please summarize the status of #23 and #55.
>
>       >>
>
>       >>
>
>       >>
>
>       >> Ulrich
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >> *From:*ext Steve Donovan
>
>       [mailto:[e-mail]] *Sent:*
>
>       >> Monday, March 24, 2014 7:38 PM *To:* Wiehe, Ulrich (NSN -
>
>      
>
>       >> DE/Munich); [e-mail] <mailto:[e-mail]>
> <mailto:[e-mail]> <mailto:[e-mail]>
>
>       *Subject:* Re:
>
>       >> [Dime] Resolution on action to discuss the need for
>
>       >> Realm-Routed-Reports
>
>       >>
>
>       >>
>
>       >>
>
>       >> Ok, we are going backwards on this one.
>
>       >>
>
>       >> I did not include option three because we had moved past
>
>       that
>
>       >> option in our discussions, both on the list (I thought),
>
>       and in
>
>       >> the meeting.
>
>       >>
>
>       >> I believe that we had come to rough consensus on the need
>
>       for a
>
>       >> realm report and the only remaining issue was whether we
>
>       also
>
>       >> included the RRR report type.
>
>       >>
>
>       >> At this point, the only option is to leave all of the
>
>       issues
>
>       >> related to the report types open and attempt to resolve
>
>       them in
>
>       >> the -03 draft.
>
>       >>
>
>       >> Steve
>
>       >>
>
>       >> On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich)
>
>       wrote:
>
>       >>
>
>       >> Steve,
>
>       >>
>
>       >>
>
>       >>
>
>       >> I do not agree.
>
>       >>
>
>       >>
>
>       >>
>
>       >> We should still have the option
>
>       >>
>
>       >> 3) support report type 0 (this is called host report) and
>
>       support
>
>       >> of report type 1 (this has been called relam report but
>
>       people
>
>       >> argued it should better be called realm routed request
>
>       report).
>
>       >>
>
>       >>
>
>       >>
>
>       >> Whether or not we need in addition to type 0 and type 1
>
>       (or as a
>
>       >> replacement of type 1) a
>
>       >> realm-no-matter-whether-destination-host-is
>
>       present-or-not report
>
>       >> is an open issue (see #55).
>
>       >>
>
>       >> There are a lot of open questions  with regard to #55 and
>
>       I have
>
>       >> not seen a conclusion.
>
>       >>
>
>       >> Where I have seen a conclusion is issue #34 and that is
>
>       inline
>
>       >> with option 3).
>
>       >>
>
>       >>
>
>       >>
>
>       >> Unless we conclude on #55, or decide to re-open #34,
>
>       option 3) is
>
>       >> what should go in the -02 draft.
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >> Ulrich
>
>       >>
>
>       >>
>
>       >>
>
>       >> *From:*DiME [mailto:[e-mail]] *On Behalf Of
>
>       *ext
>
>       >> Steve Donovan *Sent:* Monday, March 24, 2014 2:57 PM
>
>       *To:*
>
>       >> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
> <mailto:[e-mail]> *Subject:* Re:
>
>       [Dime]
>
>       >> Resolution on action to discuss the need for
>
>       Realm-Routed-Reports
>
>       >>
>
>       >>
>
>       >>
>
>       >> Ulrich, All,
>
>       >>
>
>       >> We have two options for the -02 draft.
>
>      >>
>
>       >> 1) Support Host and Realm as proposed below, removing RRR
>
>       reports.
>
>       >>  2) Support Host, Realm and RRR reports.
>
>       >>
>
>       >> The default plan is to go with option 1 in the -02 draft,
>
>       as that
>
>       >> was the proposal that came out of the meeting in London. 
>
>       RRR
>
>       >> reports can be added back in if and when we are convinced
>
>       of the
>
>       >> need.
>
>       >>
>
>       >> If there are strong objections to this then I will update
>
>       the -02
>
>       >> draft to reflect all three report types.
>
>       >>
>
>       >> I plan to make these updates Wednesday morning, Dallas,
>
>       Texas
>
>       >> time.
>
>       >>
>
>       >> Either way I do not expect we will have agreed to wording
>
>       on the
>
>       >> interaction between the report types when a reacting node
>
>       has
>
>       >> multiple report types, all of which apply to individual
>
>       requests.
>
>       >> This will need to be addressed in the -03 draft.
>
>       >>
>
>       >> Regards,
>
>       >>
>
>       >> Steve
>
>       >>
>
>       >> On 3/21/14 4:05 PM, Steve Donovan wrote:
>
>       >>
>
>       >> Ulrich,
>
>       >>
>
>       >> The discussion should be captured in the minutes to the
>
>       meeting.
>
>       >> I wasn't able to find them posted yet.
>
>       >>
>
>       >> Jouni, Lionel, what is the status of the minutes for the
>
>       meeting?
>
>       >>
>
>       >> My reading of emails prior to the London meeting is
>
>       different from
>
>       >> yours.  I believe we had come to the conclusion that we
>
>       needed
>
>       >> host and realm (with the definition of realm as outlined
>
>       below).
>
>       >> We were still discussing the need for
>
>       Realm-Routed-Request
>
>       >> reports.
>
>       >>
>
>       >> Regards,
>
>       >>
>
>       >> Steve
>
>       >>
>
>       >> On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich)
>
>       wrote:
>
>       >>
>
>       >> Steve,
>
>       >>
>
>       >>
>
>       >>
>
>       >> I don't know what happend in London.
>
>       >>
>
>       >> Can you please summarize the technical reasons that led
>
>       to the
>
>       >> London agreement.
>
>       >>
>
>       >> E-mail discussions prior to London have clearly directed
>
>       towards a
>
>       >> report type that requests throttling of realm routed
>
>       request
>
>       >> messages (i.e. not containing a destination host) rather
>
>       than a
>
>       >> report type that requests throttling of messages routed
>
>       towards a
>
>       >> realm (no matter whether they contain a destination host
>
>       or not).
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >> Ulrich
>
>       >>
>
>       >>
>
>       >>
>
>       >> *From:*DiME [mailto:[e-mail]] *On Behalf Of
>
>       *ext
>
>       >> Steve Donovan *Sent:* Friday, March 21, 2014 3:33 PM
>
>       *To:*
>
>       >> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
> <mailto:[e-mail]> *Subject:*
>
>       [Dime] Resolution
>
>       >> on action to discuss the need for Realm-Routed-Reports
>
>       >>
>
>       >>
>
>       >>
>
>       >> All,
>
>       >>
>
>       >> Ben and I took the action item to discuss the need for
>
>       the
>
>       >> Realm-Routed-Reports (RRR) report type.
>
>       >>
>
>       >> As you may recall, the consensus coming out of the DIME
>
>       WG meeting
>
>       >> in London was to support two report types:
>
>       >>
>
>       >> - Host -- Impacting requests with a Destination-Host AVP
>
>       matching
>
>       >> the host in the overload report (with the host implicitly
>
>      
>
>       >> determined from the Origin-Host AVP of the answer message
>
>       carrying
>
>       >> the overload report).
>
>       >>
>
>       >> - Realm -- Impacting 100% of the requests with a
>
>       Destination-Realm
>
>       >> AVP matching the realm in the overload report (with the
>
>       realm
>
>       >> implicitly determine from the Origin-Realm of the answer
>
>       message
>
>       >> carrying the overload report).
>
>       >>
>
>       >> The action Ben and I took was to come back with an
>
>       opinion on
>
>       >> whether RRR reports should also be supported.
>
>       >>
>
>       >> My summary of the discussion is that we recommend to NOT
>
>       include
>
>       >> RRR reports in the current version of the base DOIC
>
>       draft.
>
>       >>
>
>       >> We still have some concerns with the granularity of
>
>       control
>
>       >> enabled by having just the two report types but the
>
>       analysis of
>
>       >> whether RRR reports are still needed can occur
>
>       independent of the
>
>       >> base DOIC draft.  If there is a determination that RRRs
>
>       are needed
>
>       >> in time to include in the base draft then it can be
>
>       considered at
>
>       >> that time.
>
>       >>
>
>       >> Based on this, I propose the following
>
>       >>
>
>       >> - Resolution to issue #23 is to remove RRR reports from
>
>       the
>
>       >> document. - Resolution to issue #55 is to add Realm
>
>       reports
>
>       >> (actually to redefine them per the above definition). -
>
>       Resolution
>
>       >> to issue #57 is that it no longer applies (as it deals
>
>       with RRRs).
>
>       >>
>
>       >> There is also need for text describing the interaction
>
>       between
>
>       >> host and the realm reports.  I don't expect we will have
>
>       consensus
>
>       >> on this wording prior to the -02 draft being submitted. 
>
>       To this
>
>       >> end, I'll open a new issue to deal with the need for
>
>       wording on
>
>       >> the interaction.
>
>       >>
>
>       >> Regards,
>
>       >>
>
>       >> Steve
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >> _______________________________________________
>
>       >>
>
>       >> DiME mailing list
>
>       >>
>
>       >> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
> <mailto:[e-mail]>
>
>       >>
>
>       >> https://www.ietf.org/mailman/listinfo/dime
> <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.