Subject: Re: [Dots] Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS and COMMENT)

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 4 Jan 2021 16:07:36 +0000

Hi Med,

This text is an improvement to me, thanks.

Although the introduction still doesn't seem to state the precise reason why the DOTS client cannot open a regular channel to the DOTs server (e.g. paragraph 2 of the introduction), or I am missing it.

My assumption of the deployment is that the DOTS client is within the outbound DOS attack ISP's network.  Is the specific issue that this document is addressing that the DOTs server may be behind a NAT and hence not be publicly addressable?  Or are there also other reasons why a Call Home architecture is required?  I appreciate that there may be reasons why a Call Home architecture is preferred and potentially simplifies the management of the CPE devices.

Regards,
Rob

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of
> [email-masked]
> Sent: 23 December 2020 13:54
> To: Roman Danyliw <[email-masked]>; Rob Wilton (rwilton)
> <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> Valery Smyslov <[email-masked]>; [email-masked]
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-
> 11: (with DISCUSS and COMMENT)
> 
> Hi Roman, all,
> 
> We updated the draft to take into account your suggestions. The
> introduction and applicability sections were reworked accordingly. We also
> kept in mind Rob's comment when updating these two sections.
> 
> The new version and a diff can be found at:
> 
> Htmlized:       https://tools.ietf.org/html/draft-ietf-dots-signal-call-
> home-12
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-
> call-home-12
> 
> Please let us know if this version addresses your DISCUSS.
> 
> Also, this version integrates the inputs from the Barry/Eric/Erik and
> directorate reviews.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Roman Danyliw [mailto:[email-masked]]
> > Envoyé : vendredi 18 décembre 2020 17:58
> > À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>; The
> > IESG <[email-masked]>
> > Cc : [email-masked]; dots-
> > [email-masked]; Valery Smyslov <[email-masked]>; [email-masked]
> > Objet : RE: Roman Danyliw's Discuss on draft-ietf-dots-signal-call-
> > home-11: (with DISCUSS and COMMENT)
> >
> > Hi Med!
> >
> > > -----Original Message-----
> > > From: Dots <[email-masked]> On Behalf Of
> > > [email-masked]
> > > Sent: Wednesday, December 16, 2020 1:14 AM
> > > To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> > > Cc: [email-masked]; dots-
> > [email-masked];
> > > Valery Smyslov <[email-masked]>; [email-masked]
> > > Subject: Re: [Dots] Roman Danyliw's Discuss on
> > > draft-ietf-dots-signal-call-
> > > home-11: (with DISCUSS and COMMENT)
> > >
> > > Hi Roman,
> > >
> > > Thank you for the review.
> > >
> > > Please see inline for the DISCUSS part. Will see if/what changes
> > are
> > > needed for the COMMENT part.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : Roman Danyliw via Datatracker [mailto:[email-masked]]
> > Envoyé :
> > > > mardi 15 décembre 2020 21:01 À : The IESG <[email-masked]> Cc :
> > > > [email-masked]; dots-
> > [email-masked];
> > > > [email-masked]; Valery Smyslov <[email-masked]>;
> > > > [email-masked] Objet : Roman Danyliw's Discuss on
> > > > draft-ietf-dots-signal-call-home-
> > > > 11: (with DISCUSS and COMMENT)
> > > >
> > > > Roman Danyliw has entered the following ballot position for
> > > > draft-ietf-dots-signal-call-home-11: 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://www.ietf.org/iesg/statement/discuss-
> > > > criteria.html
> > > > for more information about IESG DISCUSS and COMMENT positions.
> > > >
> > > >
> > > > The document, along with other ballot positions, can be found
> > here:
> > > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-
> > home/
> > > >
> > > >
> > > >
> > > > ----------------------------------------------------------------
> > ----
> > > > --
> > > > DISCUSS:
> > > > ----------------------------------------------------------------
> > ----
> > > > --
> > > >
> > > > It seems to me there is a missing operational guidance or
> > > > undocumented deployment assumptions.  Since the motivational use
> > > > case seems to be home networks (per Section 1.1), I assumed that
> > the
> > > > call home servers are running primarily consumer grade routers
> > not
> > > > managed by professional IT expertise.
> > >
> > > [Med] The generalized applicability scope is what is sketched in
> > > Section 3. The solution is meant to block attacks close to their
> > source. This can be:
> > > - the home case,
> > > - an enterprise network,
> > > - a transit provider filtering attacks from leaf networks,
> > > - a provider filtering attacks from data centers,
> > > - etc.
> > >
> > > For the particular case of home networks, this can be part of
> > services
> > > supported by a ISP-managed CPE or a managed security service
> > subscribed by the user.
> > >
> > > We could mention that in the document, but we didn't because this
> > are
> > > deployment-specific. Really.
> > >
> > > Other than the introduction, we don't want to overload the
> > document
> > > with home-specific considerations.
> >
> > I still think we need a bit more precision.  I don't dispute the
> > general utility of this approach to a variety of environments.  I do
> > see the two sentences in the entire document which say that this is
> > a general purpose approach:
> >
> > Abstract: The DOTS signal channel Call Home is not specific to home
> > networks;
> >    the solution targets any deployment in which it is required to
> > block
> >    DDoS attack traffic closer to the source(s) of a DDoS attack.
> >
> > Section 3: "The aforementioned problems may be encountered in other
> > deployments
> >    than those discussed in Section 1.1 (e.g., data centers,
> > enterprise
> >    networks)."
> >
> > However, I will reiterate that almost no consideration is made to
> > distinguish these use cases in the narrative text.  The entire
> > motivation for the work in Section 1.0 is through the lens of
> > networks not managed by professionals (home networks).  Furthermore,
> > the explanation of the solution in Section 1.1, 5.1 and Appendix A
> > is done through the lens of a "home network".  For this reason, I'm
> > pushing to make sure the edges of that deployment environment are
> > covered.
> >
> > I would assert that most of the behavior described below requires
> > that professional IT expertise (let me know if you think I have it
> > wrong).  I'm looking primarily for a few pieces of clarifying text:
> > (1) a suggestion/acknowledgement that CPEs using this spec in the
> > home environment are likely to be managed, provisioned, issued (?)
> > by an ISP (this addresses where there professional IT expertise is
> > coming from)
> > (2) assuming (1) is true, distinguishing the various
> > MUST/SHOULD/MAYs admin behaviors that involve the ISP vs. the actual
> > humans on the home network
> >
> > Note: everything else below is just more detailed commentary on this
> > theme above.  I'd summarize everything I've said here by saying I
> > think we need more finesse in describing the operational
> > considerations and who is expected to take responsibility for them
> > (realizing there will be a diversity of environments).  However,
> > since there are multiple use cases, IMO, they deserve unique
> > consideration when they are different from each other.
> >
> > >   If that assumption is true
> > > > (and it should be documented if that is the case), then I find
> > many
> > > > of the operational recommendations not congruent with that
> > environment.
> > > > Specifically, the degree of interaction and tuning seems outside
> > the
> > > > realm of expertise of someone without IT training and
> > capabilities
> > > > of home network ecosystem.  In particular:
> > > >
> > > > -- Section 1.2
> > > > The Call Home DOTS server uses the DDoS attack traffic
> > information to
> > > >    identify the compromised device in its domain that is
> > responsible
> > > > for
> > > >    launching the DDoS attack, optionally notifies a network
> > > >    administrator, and takes appropriate mitigation action(s).
> > > >
> > > > How would such notification work?
> > >
> > > [Med] This will depend on the deployment (home, enterprise, DC,
> > access
> > > provider, peer transit provider, etc.). This can be using DOTS
> > (the
> > > administrator has a call home dots server app), a push from the
> > app
> > > use for managing the CPE, syslog, snmp, netconf, an SMS, etc.
> >
> > I understand this answer in the context of the enterprise use case.
> > How would this happen for the home user (non-professional IT
> > person)?
> >
> > If this an instance where if the CPE is managed on behalf a the
> > user, perhaps saying an out-of-scope mechanisms (app, SMS) needs to
> > be provided for the end-user (home user)?
> >
> > > As you can see a variety of tools can be considered as a function
> > of
> > > the local deployment case. None of them is called out in the text
> > as
> > > this is deployment- specific. Not all of them are applicable for
> > each deployment case.
> >
> > Make sense.  Perhaps some details distinguishing the guidance per
> > the use cases could help.
> >
> > > >
> > > > -- Section 1.2 and 5.1.  Leaves credentials configuration as out
> > of
> > > > scope.
> > >
> > > [Med] That is aligned with how credentials are handled in the base
> > > spec (RFC8782).
> > >
> > > > Section 1.2 references [I-D.ietf-dots-server-discovery] for
> > > > provisioning.  In turn, Section 1 of [I-D.ietf.server-discovery]
> > > > also declares this problem out of scope by saying “This document
> > > > assumes that security credentials to authenticate DOTS server(s)
> > are
> > > > pre-provisioned to a DOTS client using a mechanism such as (but
> > not
> > > > limited to) those discussed in [RFC8572] or [I-D.ietf-anima-
> > > > bootstrapping-keyinfra]”.  However, RFC8572 seems to rely on
> > NETCONF
> > > > and RESTCONF which seems like a rather uncommon feature of home
> > > > routers.  BRKSI relies on a manufacturer supplied/contracted
> > > > infrastructure and keystores that also seem uncommon for
> > consumer
> > > > grade equipment.
> > >
> > > [Med] These are not meant to be recommendations. These examples
> > may be
> > > OK for some deployments, but not appropriate for others.
> > >
> > > >
> > > > -- Section 5.3.1.
> > > > The Call Home DOTS server domain administrator consent MAY be
> > > >    required to block the traffic from the compromised device to
> > the
> > > >    attack target.  An implementation MAY have a configuration
> > knob to
> > > >    block the traffic from the compromised device to the attack
> > target
> > > >    with or without DOTS server domain administrator consent.
> > > >
> > > > The suggestion here seems to be that consumers are acquiring
> > devices
> > > > that can be remotely reconfigured with out a defined trust
> > model?
> > >
> > > [Med] Can you please clarify which suggestion are you referring
> > to?
> >
> > I'm wondering who the "server domain administrator" is and how they
> > are expected to consent in the home user scenario?
> >
> > > The text you quoted is referring to blocking traffic from devices
> > that
> > > are injecting DDoS traffic from within a domain. These devices can
> > be
> > > an IP camera, an infected PC, etc.
> > >
> > > > Some policy or operational context seems appropriate here.
> > > >
> > > > -- Section 5.3.1
> > > > ... notifies the CPE
> > > >    administrator about the compromised device
> > > >
> > > > Notify how?
> > >
> > > [Med] See above.
> >
> > Like I noted above, if I'm a home user, how am I likely to get that
> > notification?
> >
> > > >
> > > > -- Section 8.
> > > > Appropriate
> > > >    filters (e.g., access control lists) can be installed on the
> > Call
> > > >    Home DOTS server and network between the Call Home DOTS
> > agents so
> > > >    that only communications from a trusted Call Home DOTS client
> > to
> > > > the
> > > >    Call Home DOTS server are allowed.
> > > >
> > > > This seems like a level of sophistication beyond your average
> > home
> > > > router user and a place where implementations should consider a
> > > > secure defaults.
> > >
> > > [Med] This filtering can be automatically set based on the
> > configured
> > > list of Call Home DOTS clients. This is a widely used practice
> > (think
> > > about SIP proxy servers, example). No intervention may be required
> > from the user.
> >
> > Agreed.  However, this is assuming that someone is managing that
> > configuration.  My point is that in the home user space that is most
> > likely the ISP, so let's just say that.
> >
> > > >
> > > > -- Section 8.
> > > > Call Home DOTS servers can also seek the consent of DOTS
> > > >    server domain administrator to block the traffic from the
> > > > potentially
> > > >    compromised device to the target (see Section 5.3.1).
> > > >
> > > > What would be the means to gain such consent?
> > >
> > > [Med] This will depend on the deployment case: this can be an
> > action
> > > executed using an app, a confirmation to a notification message,
> > etc.
> > >
> > > >
> > > > -- Section 9.
> > > > Note that a Call Home DOTS server can seek an administrator's
> > > >    consent, validate the request by inspecting the relevant
> > traffic
> > > > for
> > > >    attack signatures, or proceed with both courses of action.
> > > >
> > > > As above.
> > >
> > > [Med] As above :-)
> > >
> > > >
> > > > -- Section 9.
> > > >
> > > >     The DOTS Call Home is only advisory in nature.  Concretely,
> > the
> > > > DOTS
> > > >    Call Home does not impose any action to be enforced within
> > the
> > > >    network hosting an attack source; it is up to the Call Home
> > DOTS
> > > >    server (and/or network administrator) to decide whether and
> > which
> > > >    actions are required.
> > > >
> > > > Such a decisions seems out beyond the ability of your average
> > home
> > > > router user.
> > >
> > > [Med] We don't have the notion of "average home router user" ;-)
> >
> > Agreed.  Probably not us though :-).  My intent was to say that when
> > the actions/decisions are being framed as being for a "network
> > admin", that to me suggests a level expertise outside of the
> > capability of typical end consumer without professional IT
> > decisions.
> >
> > Regards,
> > Roman
> >
> > > >
> > > > -- Section 8  “... explicit policy (e.g., the Call Home DOTS
> > client
> > > > and server are managed by the same administrative entity),
> > > >
> > > > Is there an underlying assumption that the ISP is managing the
> > device?
> > >
> > > [Med] ISP managed devices is one typical deployment case.
> > >
> > > That's said, the text you quoted is not specific to ISPs. It
> > applies,
> > > for example, when gateways are on the path and both the Call Home
> > DOTS
> > > server and Call Home DOTS client will thus be managed by the DC
> > > provider, the enterprise administrator, the access provider, etc.
> > >
> > >
> > >
> > ___________________________________________________________________
> > > ______________________________________________________
> > >
> > > 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.
> > >
> > > _______________________________________________
> > > Dots mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/dots
> 
> __________________________________________________________________________
> _______________________________________________
> 
> 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.

---

From: <[email-masked]>
Date: Mon, 4 Jan 2021 16:26:10 +0000

Hi Rob,

We thought this was covered by the following: 

   Other motivations for introducing the Call Home function are
   discussed in Section 1.1 of [RFC8071].

We preferred that citation vs duplicating the 6 items in this document as well (s/management system/mitigation system). 

I understand from your comment that the link was not evident. If so, will see how to make things better. 

Cheers,
Med

> De : Rob Wilton (rwilton) [mailto:[email-masked]]
> Envoyé : lundi 4 janvier 2021 17:08
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>; Roman
> Danyliw <[email-masked]>; The IESG <[email-masked]>
> Although the introduction still doesn't seem to state the precise
> reason why the DOTS client cannot open a regular channel to the DOTs
> server (e.g. paragraph 2 of the introduction), or I am missing it.
> 
> My assumption of the deployment is that the DOTS client is within
> the outbound DOS attack ISP's network.  Is the specific issue that
> this document is addressing that the DOTs server may be behind a NAT
> and hence not be publicly addressable?  Or are there also other
> reasons why a Call Home architecture is required?  I appreciate that
> there may be reasons why a Call Home architecture is preferred and
> potentially simplifies the management of the CPE devices.
> 
> Regards,
> Rob
> 
> 
> 
> > introduction and applicability sections were reworked accordingly.
> We
> > also kept in mind Rob's comment when updating these two sections.
> >
> > > De : Roman Danyliw [mailto:[email-masked]] Envoyé : vendredi 18
> > > décembre 2020 17:58 À : BOUCADAIR Mohamed TGI/OLN
> > > <[email-masked]>; The IESG <[email-masked]> Cc :
> > > Valery Smyslov <[email-masked]>; [email-masked] Objet : RE:
> Roman
> > > Danyliw's Discuss on draft-ietf-dots-signal-call-
> ____________________________________________________________________
> __
> > ____ _______________________________________________
> >

_________________________________________________________________________________________________________________________

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.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 4 Jan 2021 16:56:22 +0000

Hi Med,

Please see inline ...

> From: [email-masked] <[email-masked]>
> Sent: 04 January 2021 16:26
> To: Rob Wilton (rwilton) <[email-masked]>; Roman Danyliw
> <[email-masked]>; The IESG <[email-masked]>
[RW] 

I had missed the reference.

> 
> We preferred that citation vs duplicating the 6 items in this document as
> well (s/management system/mitigation system).
[RW] 

I agree that a reference is better than copying them all out again here.

> see how to make things better.
[RW] 

So, the desire to want to be able to stop DDOS traffic at source is clear, but it wasn't clear why Call Home is the mechanism needed to achieve that.  Perhaps your sentence could be expanded a bit without copying all the reasons.  E.g., maybe something along the lines of ...

Although Call Home functionality is not always necessary to facilitate DOTS DDOS mitigation in the source network, there are various management and deployment considerations that make Call Home functionality desirable or required in some cases, e.g., as discussed in Section 1.1 of [RFC8071].

Regards,
Rob

---

From: <[email-masked]>
Date: Thu, 7 Jan 2021 14:45:59 +0000

Hi Rob, 

Thank you for the inputs. 

We prepared a text proposal that you can see at: https://tinyurl.com/dots-call-home-latest.

Please let us know if any further modification is needed. 

Cheers,
Med

> Envoyé : lundi 4 janvier 2021 17:56
> > We preferred that citation vs duplicating the 6 items in this
> document
> > as well (s/management system/mitigation system).
> [RW]
> 
> > I understand from your comment that the link was not evident. If
> so,
> > will see how to make things better.
> [RW]
> 
> So, the desire to want to be able to stop DDOS traffic at source is
> clear, but it wasn't clear why Call Home is the mechanism needed to
> achieve that.  Perhaps your sentence could be expanded a bit without
> copying all the reasons.  E.g., maybe something along the lines of
> ...
> 
> Although Call Home functionality is not always necessary to
> facilitate DOTS DDOS mitigation in the source network, there are
> various management and deployment considerations that make Call Home
> functionality desirable or required in some cases, e.g., as

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 7 Jan 2021 22:11:46 +0000

Hi Med!

The new language about "managed CPEs" and the more generalize scope in Section 1 better contextualizes the various interactions I had raised concerns about below.  Thanks for publishing it -12.  I've cleared my ballot.

Regards,
Roman

> Sent: Wednesday, December 23, 2020 8:54 AM
> To: Roman Danyliw <[email-masked]>; Robert Wilton <[email-masked]>; The
> IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; Valery
> Smyslov <[email-masked]>; [email-masked]
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11:
> (with DISCUSS and COMMENT)
> 
> Hi Roman, all,
> 
> We updated the draft to take into account your suggestions. The introduction
> and applicability sections were reworked accordingly. We also kept in mind
> Rob's comment when updating these two sections.
> 
> Htmlized:       https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-12
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-call-home-12
> 
> Also, this version integrates the inputs from the Barry/Eric/Erik and directorate
> reviews.
> 
> Cheers,
> Med
> 
> > De : Roman Danyliw [mailto:[email-masked]] Envoyé : vendredi 18 décembre
> > 2020 17:58 À : BOUCADAIR Mohamed TGI/OLN
> > [email-masked]; dots- [email-masked];
> > Valery Smyslov <[email-masked]>; [email-masked] Objet : RE: Roman
> > see the two sentences in the entire document which say that this is a
> > general purpose approach:
> >
> >    than those discussed in Section 1.1 (e.g., data centers, enterprise
> >    networks)."
> >
> > motivation for the work in Section 1.0 is through the lens of networks
> > not managed by professionals (home networks).  Furthermore, the
> > explanation of the solution in Section 1.1, 5.1 and Appendix A is done
> > through the lens of a "home network".  For this reason, I'm pushing to
> > make sure the edges of that deployment environment are covered.
> >
> > I would assert that most of the behavior described below requires that
> > professional IT expertise (let me know if you think I have it wrong).
> > I'm looking primarily for a few pieces of clarifying text:
> > (1) a suggestion/acknowledgement that CPEs using this spec in the home
> > environment are likely to be managed, provisioned, issued (?) by an
> > ISP (this addresses where there professional IT expertise is coming
> > from)
> > (2) assuming (1) is true, distinguishing the various MUST/SHOULD/MAYs
> > admin behaviors that involve the ISP vs. the actual humans on the home
> > network
> >
> > (realizing there will be a diversity of environments).  However, since
> > there are multiple use cases, IMO, they deserve unique consideration
> > when they are different from each other.
> >
> > How would this happen for the home user (non-professional IT person)?
> >
> > If this an instance where if the CPE is managed on behalf a the user,
> > perhaps saying an out-of-scope mechanisms (app, SMS) needs to be
> > provided for the end-user (home user)?
> >
> > Make sense.  Perhaps some details distinguishing the guidance per the
> > use cases could help.
> >
> > > >
> > the actions/decisions are being framed as being for a "network admin",
> > that to me suggests a level expertise outside of the capability of
> > typical end consumer without professional IT decisions.
> >
> > Regards,
> > Roman
> >
> > > >
> 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.
> 
> information that may be protected by law; they should not be distributed, used
> or copied without authorisation.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 11 Jan 2021 15:37:54 +0000

Hi Med,

Yes, I think that text is helpful and looks good.  Thanks for accommodating.

Regards,
Rob

> Sent: 07 January 2021 14:46