Subject: [ippm] Magnus Westerlund's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS and COMMENT)

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Wed, 04 Sep 2019 06:54:08 -0700

Magnus Westerlund has entered the following ballot position for
draft-ietf-ippm-stamp-07: 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-ippm-stamp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Two very much discussing discusses. However, I would really like to hear the
answer to these concerns before clearing.

1. Section 4.3: Is the HMAC field size of 16 bytes hard coded? If there ever
would exist a need to deploy another integrity solution, even if the actual
algorithm used to construct the tag can be agreed by the management, there
appear to exist a hard look in to use 16-byte tags. Have this issue been
considered?

        2. Section 6:
        The possible impact of the
   STAMP test packets on the network MUST be thoroughly analyzed, and
   the use of STAMP for each case MUST be agreed by all users on the
   network before starting the STAMP test session.

        I assume some potential issues are know, shouldn't they really be
        listed here in the security consideration to further motivate why the
        analysis needs to happen.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

        1. Section 4:
        Before using numbers from the User Ports range, the possible impact
   on the network MUST be carefully studied and agreed by all users of
   the network.

        Is the above sentence missing to list an important assumption? Is the
        assumption that by using the registred destination port an operator
        that sees to much STAMP traffic can simply filter it out and that way
        deal with the traffic, something which is not possible when using an
        locally decided port? If that is the case, this assumption should
        probably be noted.

        2. Section 3 and 4, and 4.1.1: What is a STAMP Session? Is that a
        measurment session between one specific and sender and a specific
        reflector for a time duration?  The defenition of the session do matter
        if one intended to enable a single sender to use multiple reflectors,
        and if that can be a single session or always multiple indepdendent
        ones. Would appreciate a definition what a session is. If it is
        possible to send STAMP traffic using a multicast or broadcast address
        should be made explicit.

        3.  Section 4.1.1.:
        Timestamp is eight octets long field.  STAMP node MUST support
      Network Time Protocol (NTP) version 4 64-bit timestamp format
      [RFC5905], the format used in [RFC5357].  STAMP node MAY support
      IEEE 1588v2 Precision Time Protocol truncated 64-bit timestamp
      format [IEEE.1588.2008], the format used in [RFC8186].

        Is the clock source here something that may be relevant or simply
        information the management functions should capture. I think there is a
        similar issue to that of RTP faced when it comes to understand what the
        timestamp actually represent and thus be used correctly. RTP clock
        source specification is RFC 7273
        (https://datatracker.ietf.org/doc/rfc7273/)

        4. Section 4.1:
           Because STAMP supports symmetrical test packets, STAMP Session-Sender
   packet has a minimum size of 44 octets in unauthenticated mode, see
   Figure 2, and 112 octets in the authenticated mode, see Figure 4.

        The above text implies some potential for UDP payload size variability
        for the STAMP packets. However, the actual definition appear to have
        fixed sizes. Can you please clarify if I have missed something that
        enables the STAMP packet to have variable size?

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 10 Sep 2019 12:43:45 -0700

Hi Magnus,
thank you for the review and thoughtful, pointed questions. Please find my
answers in-line under GIM>> tag.

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/
GIM>> Indeed, this specification defines the use of only one algorithm and
only 16 bytes-long HMAC field. Your question prompted the discussion among
authors and we believe that in a future specification it would be feasible
to extend supporting a number of algorithms and different lengths of HMAC
field both being defined through extension to STAMP YANG data model.

>         analysis needs to happen.
GIM>> This is in reference to using numbers from the User range as the
destination port number. Would adding the reference to the case of using
the port numbers from the User range address your concern? Or rather refer
to Section 4, as it includes more discussion (see below)?

GIM>> That is a very good point but our primary motivation for this
cautionary note (or strong warning) was that by allowing STAMP to use port
numbers from the User range, ports that may be already assigned to
protocols, creates a DDOS attack vector. As for the filtering STAMP traffic
out, I think that even if the destination port is one from the Dynamic
range, for a relatively long test session it can be filtered out.

>         possible to send STAMP traffic using a multicast or broadcast
GIM>> Your interpretation is correct, STAMP session is implicitly defined
as p2p. And that is what reflected in the STAMP YANG model. Would the
following text make it clearer:
NEW TEXT:
   In this document, a measurement session also referred to as
   STAMP session, is the session between one specific Session-Sender and
   one particular Session-Reflector for a time duration.

>         (https://datatracker.ietf.org/doc/rfc7273/)
GIM>> NTP and PTP encodings have a different interpretation of the Fraction
field of the Timestamp field. In my experience, PTP format is native for
the data plane, while NTP is more used at the control plane. Original
extension to TWAMP has been described in RFC 8186
<https://datatracker.ietf.org/doc/rfc8186/>.

>         enables the STAMP packet to have variable size?
GIM>> I think that the text can be improved by characterizing the listed
sizes as "base". The variable length of a test packet in STAMP is supported
by using Extra Padding TLV defined in draft-ietf-ippm-stamp-option-tlv
<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/>. Below
is the proposed update:
OLD TEXT:
   Because STAMP supports symmetrical test packets, STAMP Session-Sender
   packet has a minimum size of 44 octets in unauthenticated mode, see
   Figure 2, and 112 octets in the authenticated mode, see Figure 4.
NEW TEXT:
   STAMP supports symmetrical test packets.  The base STAMP Session-
   Sender packet has a minimum size of 44 octets in unauthenticated
   mode, see Figure 2, and 112 octets in the authenticated mode, see
   Figure 4.  The variable length of a test packet in STAMP is supported
   by using Extra Padding TLV defined in
   [I-D.ietf-ippm-stamp-option-tlv].

With the new reference, should I-D.ietf-ippm-stamp-option-tlv be moved to
the Normative References list or may remain in the Informative list?

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Sep 2019 07:53:19 +0000

Hi Greg,

Thanks for the reply. See inline for my comments and response. 

On Tue, 2019-09-10 at 12:43 -0700, Greg Mirsky wrote:
> Hi Magnus,
> thank you for the review and thoughtful, pointed questions. Please
> find my answers in-line under GIM>> tag.
> 
> Regards,
> Greg
> 
> > Please refer to 
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> GIM>> Indeed, this specification defines the use of only one
> algorithm and only 16 bytes-long HMAC field. Your question prompted
> the discussion among authors and we believe that in a future
> specification it would be feasible to extend supporting a number of
> algorithms and different lengths of HMAC field both being defined
> through extension to STAMP YANG data model.

So if I understand this (taking a discussion with Mirja about keeping
things as simple as possible) the solution is to basically is when need
arises define a new STAMP version, and then use YANG to coordinate
which version is used for the measurement. If that is a correct re-
interpretation of your response then I am fine with it. 

> GIM>> This is in reference to using numbers from the User range as
> the destination port number. Would adding the reference to the case
> of using the port numbers from the User range address your concern?
> Or rather refer to Section 4, as it includes more discussion (see 
> below)? 

Okay, I don't really care where the discussion happens. But I don't
find any real discussion and listing of the concerns with using user or
dynamic ports for STAMP Sessions? With the formulation you use, I would
expect at least some list of potential concerns that needs to be
evaluated in the context of the particular usage of STAMP. 

> cautionary note (or strong warning) was that by allowing STAMP to use
> port numbers from the User range, ports that may be already assigned
> to protocols, creates a DDOS attack vector. As for the filtering
> STAMP traffic out, I think that even if the destination port is one
> from the Dynamic range, for a relatively long test session it can be
> filtered out.

So if that is the only? concern then write it out. I would expect that
the higher layer management protocol that creates a measurement session
to actually ensure that the STAMP endpoint actually have the port
numbers they attempt to use. Isn't that a reasonable requirement to put
on the solution? 

My thinking with the filtering out concern was that in cases where one
runs STAMP measurement sessions, if the measurement interfer with
critical traffic an action for an on-path node that can actually
identify the STAMP traffic was to filer it out. And that may be
considered trivial when the well known port is used, but if a user or
dynamic port is used, then that requries a managment system to provide
the on-path node with the necessary information, i.e. 3/5 tuple for the
STAMP flows. 

> GIM>> Your interpretation is correct, STAMP session is implicitly
> defined as p2p. And that is what reflected in the STAMP YANG model.
> Would the following text make it clearer:
> NEW TEXT:

Yes, please include that definition. Question would it be clearer to
replace ".. is the session betweeen .." with ".. is the bi-directional
packet flows between .."? 

> GIM>> NTP and PTP encodings have a different interpretation of the
> Fraction field of the Timestamp field. In my experience, PTP format
> is native for the data plane, while NTP is more used at the control
> plane. Original extension to TWAMP has been described in RFC 8186.

I think you missunderstood. When I talk about clock source, I am
actually referring to identifying the particular clock that the node
use to derive the included timestamp from. 

And likely this is a moot point in this document where the clock source
information belongs in the management layer, e.g. in the YANG data
model. 

> GIM>> I think that the text can be improved by characterizing the
> listed sizes as "base". The variable length of a test packet in STAMP
> is supported by using Extra Padding TLV defined in draft-ietf-ippm-
> stamp-option-tlv. Below is the proposed update:
> OLD TEXT:
> With the new reference, should I-D.ietf-ippm-stamp-option-tlv be
> moved to the Normative References list or may remain in the
> Informative list?

From my perspective, the fact that optional TLV may occur following the
base headers appears quite important. Here comes a question of
intention form the WG. Is it intended that one can have STAMP endpoints
that do not even support receiving packets larger than the base? 

In other words there will be two main versions already now, one that
supports some TLV and can at least handle the TLV skip forward and
ignore the content and one that will throw a fit over the TLVs? If that
is not the intention I think the fact that TLV's may occur should be
moved into this specification and have it as a normative reference.

I guess the answer is that you have backwards comaptibility reasons for
not allowing TLVs at all in some sessions, or? 

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Henrik Nydell <[email-masked]>
Date: Wed, 11 Sep 2019 10:30:06 +0200

See below for PTP/NTP comment

> information belongs in the management layer, e.g. in the YANG data

In section 4.1.1 of draft-ietf-ippm-stamp there is a definition of the
Z-bit in the error correction field that denotes if the clock source is NTP
or PTP

-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[email-masked]
<http://accedian.com>
<https://www.facebook.com/accedian/>  <https://twitter.com/Accedian>
<https://www.linkedin.com/company/accedian-networks?originalSubdomain=ca>
<http://www.accedian.com>
*accedian.com <http://accedian.com>*

-- 

Avis de confidentialité

Les
 informations contenues dans le présent 
message et dans toute pièce qui 
lui est jointe sont confidentielles et 
peuvent être protégées par le 
secret professionnel. Ces informations sont 
à l’usage exclusif de son ou
 de ses destinataires. Si vous recevez ce 
message par erreur, veuillez 
s’il vous plait communiquer immédiatement 
avec l’expéditeur et en 
détruire tout exemplaire. De plus, il vous est 
strictement interdit de 
le divulguer, de le distribuer ou de le reproduire 
sans l’autorisation 
de l’expéditeur. Merci.

Confidentiality notice

This

 e-mail message and any attachment hereto contain confidential 
information 
which may be privileged and which is intended for the 
exclusive use of its 
addressee(s). If you receive this message in error,
 please inform sender 
immediately and destroy any copy thereof. 
Furthermore, any disclosure, 
distribution or copying of this message 
and/or any attachment hereto 
without the consent of the sender is 
strictly prohibited. Thank you.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Sep 2019 09:36:50 +0000

Hi Henrik,

On Wed, 2019-09-11 at 10:30 +0200, Henrik Nydell wrote:
> > > >         Is the clock source here something that may be relevant
> > or
> > > > simply
> > > >         timestamp actually represent and thus be used
> > correctly.
> > > > RTP clock
> In section 4.1.1 of draft-ietf-ippm-stamp there is a definition of
> the Z-bit in the error correction field that denotes if the clock
> source is NTP or PTP
>  

Yes, to be clear I have no issue with if the format is NTP or PTP. That
was not my comment. It was a comment if the protocol should identify
which particular NTP or PTP server the node is using. For example for a
node on my network having NTP based clock it matters if that NTP server
is sth1.ntp.se which is a stratum 1 server distributing certified
swedish time, or if I use europe.pool.ntp.org where I would use any NTP
server part of the pool indicating that they are in europe. 

However, I am convinced that information is of interest the information
should be in the management layer. 

Cheers

Magnus Westerlund

---

From: Henrik Nydell <[email-masked]>
Date: Wed, 11 Sep 2019 13:00:50 +0200

Understood, yes I believe that is above the STAMP itself. It can be added
as an optional TLV to STAMP if it is desirable to fetch this type of
information from the reflector endpoints.

-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[email-masked]
<http://accedian.com>

-- 

Avis de confidentialité

Les

Confidentiality notice

This

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 11 Sep 2019 08:25:06 -0700

Hi Magnus,
thank you for the clarification of the question. As Henrik already noted,
in an effort to characterize the source of ingress and egress timestamps at
the Session-Reflector we've introduced the Timestamp Information TLV
(Section 4.3 in draft-ietf-ippm-stamp-option-tlv). It does not provide the
name/location of the clock master/synchronization source, only a clock
synchronization protocol and the method by which the timestamp is obtained.
Much appreciate your comments, suggestions to make that TLV more useful.

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 11 Sep 2019 11:33:34 -0700

Hi Magnus,
thank you for clarifications and further detailing your comments,
questions. Please find my answers and notes below in-lined under the GIM2>>
tag.

Regards,
Greg

> interpretation of your response then I am fine with it.
GIM2>> The direction from the WG was to keep the base specification as
simple  as possible (and that was the reason to split TLV extensions into a
separate document).

> evaluated in the context of the particular usage of STAMP.
GIM2>> Per Berry's suggestion, I'm adding a new section, Operational
Considerations, to list possible scenarios and possible issues with using
destination ports from the User range and from the Dynamic range. I hope to
finish it in a couple days. Will share on this discussion thread promptly.

> numbers they attempt to use. Isn't that a reasonable requirement to put
GIM2>> Agree with your suggestion. Will put in the new section. If STAMP is
managed by a centralized system, whether it is proprietary OSS/BSS or an
orchestrator that uses YANG data models, the system will be able to
coordinate selection of port numbers on the Session-Sender and
Session-Reflector. But some systems may use EMS or CLI and that is where
human coordination may be required.

> the on-path node with the necessary information, i.e. 3/5 tuple for the
GIM2>> I think that a transit node can identify a flow as the STAMP flow
only if the destination port is the STAMP default UDP destination port
number, 862. In case a STAMP session has the destination port number as one
of port numbers from the User range, IP/UDP encapsulation of STAMP packets
would be indistinguishable from packets originated by the application that
is assigned that port number. Thus, filtering out on only destination port
number may negatively affect service, legitimate service. Because of that,
I think that filtering will have to use more information. On the other
hand, if the test flow does not exceed agreed rate, then any filtering test
packets out, in my opinion, is counter-productive, as it hides some issues
in the networks rather than letting the OAM tools to expose them, localize,
and characterize.

> packet flows between .."?
GIM2>> I agree, defining a session as a session makes is somewhat
repetitive. Thank you.
Below is the updated text:
   In this document, a measurement session also referred to as
   STAMP session, is the bi-directional packet flow between one specific
   Session-Sender and one particular Session-Reflector for a time
   duration.

> information belongs in the management layer, e.g. in the YANG data
GIM2>> Timestamp Information TLV (draft-ietf-ippm-stamp-option-tlv
<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/?include_text=1>)
provides information about the clock synchronization protocol and the
method by wich the timestamp has been acquired at a Session-Reflector. We
may extend it to list the name/locatior of the master clock.

> moved into this specification and have it as a normative reference.
GIM2>> Will move the reference to the Normative section. With TLV being
normative, I'd expect that the intelligent implementation of this draft, of
the base STAMP specification, will accept any valid STAMP packet though not
process extensions. But the base STAMP Session-Reflector will return the
base reflected packet.

> not allowing TLVs at all in some sessions, or?
GIM2>> Yes, that and the principle "keep it simple".

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Sep 2019 15:29:37 +0000

On Wed, 2019-09-11 at 11:33 -0700, Greg Mirsky wrote:
> questions. Please find my answers and notes below in-lined under the
> GIM2>> tag.
> 
> Regards,
> Greg
> 
> > > > 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
> > > > -------------------------------------------------------------
> > ----
> > > > -----
> > > > DISCUSS:
> > > > -------------------------------------------------------------
> > ----
> > > > -----
> > > > 
> > > > Two very much discussing discusses. However, I would really
> > like to
> > > > hear the
> > > > 1. Section 4.3: Is the HMAC field size of 16 bytes hard coded?
> > If
> > > > there ever
> > > > would exist a need to deploy another integrity solution, even
> > if
> > > > the actual
> > > > appear to exist a hard look in to use 16-byte tags. Have this
> > issue
> > > > been
> > > > considered?
> > > 
> GIM2>> The direction from the WG was to keep the base specification
> as simple  as possible (and that was the reason to split TLV
> extensions into a separate document). 

Yes, understood. 

> > > >    STAMP test packets on the network MUST be thoroughly
> > analyzed,
> > > > and
> > > >    the use of STAMP for each case MUST be agreed by all users
> > on
> > > > the
> Considerations, to list possible scenarios and possible issues with
> using destination ports from the User range and from the Dynamic
> range. I hope to finish it in a couple days. Will share on this
> discussion thread promptly. 

Great!

Looking forward to review it when written. 

> > > > 
> > > > -------------------------------------------------------------
> > ----
> > > > -----
> > > > COMMENT:
> > > > -------------------------------------------------------------
> > ----
> > > > -----
> > > > 
> > > >         1. Section 4:
> > > >    on the network MUST be carefully studied and agreed by all
> > users
> > > > of
> > > >    the network.
> > > > 
> > > >         assumption that by using the registred destination port
> > an
> > > > operator
> > > >         that sees to much STAMP traffic can simply filter it
> > out
> > > > and that way
> > > >         deal with the traffic, something which is not possible
> > when
> > > > using an
> > > >         locally decided port? If that is the case, this
> > assumption
> > > > should
> > > >         probably be noted.
> > > 
> GIM2>> Agree with your suggestion. Will put in the new section. If
> STAMP is managed by a centralized system, whether it is proprietary
> OSS/BSS or an orchestrator that uses YANG data models, the system
> will be able to coordinate selection of port numbers on the Session-
> Sender and Session-Reflector. But some systems may use EMS or CLI and
> that is where human coordination may be required. 

Good, then likely this is resolved when your text is ready. 

> GIM2>> I think that a transit node can identify a flow as the STAMP
> flow only if the destination port is the STAMP default UDP
> destination port number, 862. In case a STAMP session has the
> destination port number as one of port numbers from the User range,
> IP/UDP encapsulation of STAMP packets would be indistinguishable from
> packets originated by the application that is assigned that port
> number. Thus, filtering out on only destination port number may
> negatively affect service, legitimate service. Because of that, I
> think that filtering will have to use more information. On the other
> hand, if the test flow does not exceed agreed rate, then any
> filtering test packets out, in my opinion, is counter-productive, as
> it hides some issues in the networks rather than letting the OAM
> tools to expose them, localize, and characterize.

Ok. This was primarily to understand if this was in scope or not. But
it sounds like this is not really in scope for how to manage it. 

> > 
> > > >         2. Section 3 and 4, and 4.1.1: What is a STAMP Session?
> > Is
> > > > that a
> > > >         measurment session between one specific and sender and
> > a
> > > > specific
> > > >         if one intended to enable a single sender to use
> > multiple
> > > > reflectors,
> > > >         ones. Would appreciate a definition what a session is.
> > If
> > > > it is
> > >    STAMP session, is the session between one specific Session-
> > Sender
> > > and

Looks good to me. 

> GIM2>> Timestamp Information TLV (draft-ietf-ippm-stamp-option-tlv)
> method by wich the timestamp has been acquired at a Session-
> Reflector. We may extend it to list the name/locatior of the master
> clock.

Ok. sounds reasonable. 

> > 
> > > >         4. Section 4.1:
> > > >            Because STAMP supports symmetrical test packets,
> > STAMP
> > > > Session-Sender
> > > >    packet has a minimum size of 44 octets in unauthenticated
> > mode,
> > > > see
> > > >    Figure 2, and 112 octets in the authenticated mode, see
> > Figure
> > > > 4.
> > > > 
> > > >         The above text implies some potential for UDP payload
> > size
> > > > variability
> > >    Because STAMP supports symmetrical test packets, STAMP
> > Session-
> > > Sender
> > >    packet has a minimum size of 44 octets in unauthenticated
> > mode,
> > > see
> GIM2>> Will move the reference to the Normative section. With TLV
> being normative, I'd expect that the intelligent implementation of
> this draft, of the base STAMP specification, will accept any valid
> STAMP packet though not process extensions. But the base STAMP
> Session-Reflector will return the base reflected packet.  

I think that is very reasonable approach. Are you close to complete the
stamp-option-tlv document, or will the missref cause any issue? 

> GIM2>> Yes, that and the principle "keep it simple". 

Thanks,

To me it looks like with some text changes all my issues are addressed.

Cheers

Magnus Westerlund

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 24 Sep 2019 13:39:02 -0700

Hi Magnus,
a new section, Operational Considerations, has been added to address
Barry's DISCUSS:

5.  Operational Considerations

   STAMP is intended to be used on production networks to enable the
   operator to assess service level agreements based on packet delay,
   delay variation, and loss.  When using STAMP over the Internet,
   especially when STAMP test packets are transmitted with the
   destination UDP port number from the User Ports range, the possible
   impact of the STAMP test packets MUST be thoroughly analyzed.  The
   use of STAMP for each case MUST be agreed by users of nodes hosting
   the Session-Sender and Session-Reflector before starting the STAMP
   test session.

   Also, the use of the well-known port number as the destination UDP
   port number in STAMP test packets transmitted by a Session-Sender
   would not impede the ability to measure performance in an Equal Cost
   Multipath environment and analysis in Section 5.3 [RFC8545] fully
   applies to STAMP.

Would it address your concern?

The new version of the draft
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-08> has been
published. It includes all the updates we've discussed.

Much appreciate your consideration of the new version, comments, and
questions.

Kind regards,
Greg

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 26 Sep 2019 08:41:23 +0000

Hi Greg,

This clarifies it sufficiently. I have cleared my discuss. 

Thanks

Magnus

On Tue, 2019-09-24 at 13:39 -0700, Greg Mirsky wrote:
> Hi Magnus,
> a new section, Operational Considerations, has been added to address Barry's
> DISCUSS:
> 
> The new version of the draft has been published. It includes all the updates
> we've discussed.
> 
-- 
Cheers

Magnus Westerlund

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 26 Sep 2019 08:08:10 -0700

Hi Magnus,
thank you for all your comments, discussion, and patience.

Kind regards,
Greg

On Thu, Sep 26, 2019 at 1:41 AM Magnus Westerlund <
[email-masked]> wrote:

> Barry's