Subject: [ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv

From: Tommy Pauly <[email-masked]>
Date: Mon, 08 Jul 2019 15:47:17 -0700

Hello IPPM,

This message begins an adoption call for draft-mirsky-ippm-stamp-option-tlv, "Simple Two-way Active Measurement Protocol Optional Extensions”. The document has been discussed on the list recently, with good input and reviews from the group. We’d like to get the working group’s input on if this document should be adopted and worked on by the group.

The current status and text of the document can be found here:

https://datatracker.ietf.org/doc/draft-mirsky-ippm-stamp-option-tlv/ <https://datatracker.ietf.org/doc/draft-mirsky-ippm-stamp-option-tlv/>
https://tools.ietf.org/html/draft-mirsky-ippm-stamp-option-tlv-05 <https://tools.ietf.org/html/draft-mirsky-ippm-stamp-option-tlv-05>

Please respond to this email by Tuesday, July 23 to indicate whether or not you think IPPM should adopt and work on the extensions and extension mechanism described in this draft.

Best,
Tommy (as IPPM co-chair)

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 8 Jul 2019 16:12:00 -0700

yes/support

Cheers,
Jeff
On Jul 8, 2019, 3:53 PM -0700, Tommy Pauly <tpauly=[email-masked]>, wrote:
> https://datatracker.ietf.org/doc/draft-mirsky-ippm-stamp-option-tlv/
> https://tools.ietf.org/html/draft-mirsky-ippm-stamp-option-tlv-05
>
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: <[email-masked]>
Date: Tue, 9 Jul 2019 17:01:30 +0800 (CST)

Hi all,

I support WG adoption of this draft as co-author.

Cheers,

Xiao Min

原始邮件

发件人：TommyPauly <tpauly=[email-masked]>
收件人：IETF IPPM WG <[email-masked]>;
抄送人：[email-masked] <[email-masked]>;
日 期 ：2019年07月09日 06:48
主 题 ：[ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv

Hello IPPM,

Best,Tommy (as IPPM co-chair)

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 9 Jul 2019 09:15:35 +0000

Yes, I support WG adoption of this draft.

Tianran

From: ippm [mailto:[email-masked]] On Behalf Of Tommy Pauly
Sent: Tuesday, July 09, 2019 6:47 AM
To: IETF IPPM WG <[email-masked]>
Cc: [email-masked]
Subject: [ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv

Hello IPPM,

Best,
Tommy (as IPPM co-chair)

---

From: <[email-masked]>
Date: Tue, 9 Jul 2019 19:06:02 +0800 (CST)

I support WG adoption of this draft.

郭俊 guojun

软件开发工程师  Development
Engineer
分组南京软件开发一部/有线研究院/有线产品经营部 Packet Nanjing Software Development Dept. I/Wireline Product Operation Division

南京市雨花台区紫荆花路68号中兴通讯南京研发中心一期
T: +86 755 xxxxxxxx F:+86 755 xxxxxxxx 
M: +86 18105183663
E: [email-masked] 
www.zte.com.cn

原始邮件

日 期 ：2019年07月09日 06:53

Hello IPPM,

---

From: Henrik Nydell <[email-masked]>
Date: Tue, 9 Jul 2019 13:32:40 +0200

Yes, support as co-author

Cheers
Henrik

On Tue, Jul 9, 2019 at 1:23 PM <[email-masked]> wrote:

> 软件开发工程师  Development Engineer
> *发件人：*TommyPauly <tpauly=[email-masked]>
> *收件人：*IETF IPPM WG <[email-masked]>;
> *抄送人：[email-masked] <
> [email-masked]>;
> *日 期 ：*2019年07月09日 06:53
> *主 题 ：**[ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv*
> This message begins an adoption call for
> draft-mirsky-ippm-stamp-option-tlv, "Simple Two-way Active Measurement
> Protocol Optional Extensions”. The document has been discussed on the list
> recently, with good input and reviews from the group. We’d like to get the
> working group’s input on if this document should be adopted and worked on
> by the group.
>
> Please respond to this email by *Tuesday, July 23* to indicate whether or
> not you think IPPM should adopt and work on the extensions and extension
> mechanism described in this draft.
>
> Best,
> Tommy (as IPPM co-chair)
>
>
>

-- 
--
*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: Giuseppe Fioccola <[email-masked]>
Date: Tue, 9 Jul 2019 12:23:36 +0000

Yes, I support its adoption.
Regards,

Giuseppe

Sent: Tuesday, July 9, 2019 12:47 AM

Hello IPPM,

Best,
Tommy (as IPPM co-chair)

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 9 Jul 2019 07:58:12 -0700

Dear All,
yes/support adoption of the draft (as co-author).

Regards,
Greg

---

From: Jai Kumar <[email-masked]>
Date: Tue, 09 Jul 2019 10:18:51 -0700

Yes/Support.

-Jai

From: ippm <[email-masked]> on behalf of Tommy Pauly <tpauly=[email-masked]>
Date: Monday, July 8, 2019 at 3:53 PM
To: IETF IPPM WG <[email-masked]>
Cc: <[email-masked]>
Subject: [ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv

Hello IPPM,

Best,
Tommy (as IPPM co-chair)

_______________________________________________ ippm mailing list [email-masked] https://www.ietf.org/mailman/listinfo/ippm

---

From: Cociglio Mauro <[email-masked]>
Date: Wed, 10 Jul 2019 07:33:38 +0000

Hi all.
Yes, I support the adoption.
Regards.
Mauro
_____________________
Mauro Cociglio
TIM - CT.TA.EI
Via G. Reiss Romoli, 274
10148 - Torino (Italy)
Tel.: +390112285028
Mobile: +393357669751
_____________________

Da: ippm [mailto:[email-masked]] Per conto di Tommy Pauly
Inviato: martedì 9 luglio 2019 00:47
A: IETF IPPM WG <[email-masked]>
Cc: [email-masked]
Oggetto: [EXT] [ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv

Hello IPPM,

Best,
Tommy (as IPPM co-chair)

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. 

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: David Sinicrope <[email-masked]>
Date: Wed, 10 Jul 2019 12:45:54 +0200

I support WG adoption of the draft.  The issues it addresses are practical, valid and in need of solution.

-Dave

> On Jul 9, 2019, at 12:47 AM, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> Hello IPPM,
>

---

From: David Sinicrope <[email-masked]>
Date: Wed, 10 Jul 2019 12:48:42 +0200

The Broadband Forum has related work on WT-390i2 - Performance Measurement between Customer Equipment and IP Edge using STAMP that intends to make normative reference to this document once it completes the IETF process.

Please let me know if you have any questions.
Thanks!
Dave Sinicrope
IETF Liaison Manager to Broadband Forum

---

From: "Foote, Footer (Nokia - CA)" <[email-masked]>
Date: Mon, 15 Jul 2019 11:15:15 +0000

Morning All!

Yes, support adoption of the draft (as co-author).

Footer

From: [email-masked] <[email-masked]>
Sent: Monday, 8 July 2019 18:47
To: IETF IPPM WG <[email-masked]>
Cc: [email-masked]
Subject: Adoption call for draft-mirsky-ippm-stamp-option-tlv

Hello IPPM,

Best,
Tommy (as IPPM co-chair)

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 15 Jul 2019 10:48:05 -0400

Hi Authors,
There were couple of items discussed on the mailing list and have added
them below for convenience. Like to see them addressed in the adopted draft.

Thanks,

Rakesh

------------------------------

Regarding the size of the padding, yes, it's good to use the same size
payload for query and response.

However, the STAMP payload with TLV extension
(draft-mirsky-ippm-stamp-option-tlv-01) has slightly different padding size
of 30 MBZ vs 27 ( or > 29)in draft-ietf-ippm-stamp. Is there a way to make
them compatible? Does it mean that for STAMP with TLV, Server Octets is set
to 1, but it says MBZ 0 for all 30 bytes.. If the responder supports Server
Octets and see the size > 27, it may find the Server Octet size of 0
confusing?

--------------------------

The direct measurement TLV proposed in the draft may not be hardware
friendly for actual data traffic loss measurement due to the need to search
the presence of the TLV and the counter offset not always fixed due to the
variable length payload. Also, it overloads the delay measurement probes
just for measuring packet loss which complicates the implementation.

GIM>> The Direct Loss TLV is intended to immediately follow the STAMP test
packet and thus its location is known. We'll work on the text to guide
implementations to be more HW friendly and support efficient testing.

<RG> Revised format looks like following:

       0                   1                   2                   3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                        Sequence Number                        |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                          Timestamp                            |

      |                                                               |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |         Error Estimate        |                               |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |

      |                                                               |

      |                                                               |

      |                         MBZ (30 octets)                       |

      |                                                               |

      |                                                               |

      |                                                               |

      |                                                               |

*      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*

*      |    Direct Measurement Type    |           Length              |*

*      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*

*      |             Session-Sender Tx counter  (S_TxC)                |*

*      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*

*      |             Session-Reflector Rx counter  (R_RxC)             |*

*      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*

*      |             Session-Reflector Tx counter  (R_TxC)             |*

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |             Type              |           Length              |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      ~                            Value                              ~

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 16 Jul 2019 03:05:14 +0000

Hi Rakesh,

I am not clear why the direct loss test need to be hardware friendly.
It seems the STAMP is end to end over UDP. It could be CPU processing.

Tianran

From: ippm [mailto:[email-masked]] On Behalf Of Rakesh Gandhi
Sent: Monday, July 15, 2019 10:48 PM
To: Tommy Pauly <tpauly=[email-masked]>
Cc: [email-masked]; IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv

Hi Authors,
There were couple of items discussed on the mailing list and have added them below for convenience. Like to see them addressed in the adopted draft.

Thanks,
Rakesh

------------------------------
Regarding the size of the padding, yes, it's good to use the same size payload for query and response.
However, the STAMP payload with TLV extension (draft-mirsky-ippm-stamp-option-tlv-01) has slightly different padding size of 30 MBZ vs 27 ( or > 29)in draft-ietf-ippm-stamp. Is there a way to make them compatible? Does it mean that for STAMP with TLV, Server Octets is set to 1, but it says MBZ 0 for all 30 bytes.. If the responder supports Server Octets and see the size > 27, it may find the Server Octet size of 0 confusing?

The direct measurement TLV proposed in the draft may not be hardware friendly for actual data traffic loss measurement due to the need to search the presence of the TLV and the counter offset not always fixed due to the variable length payload. Also, it overloads the delay measurement probes just for measuring packet loss which complicates the implementation.
GIM>> The Direct Loss TLV is intended to immediately follow the STAMP test packet and thus its location is known. We'll work on the text to guide implementations to be more HW friendly and support efficient testing.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sequence Number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Timestamp                            |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Error Estimate        |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                                                               |
      |                                                               |
      |                         MBZ (30 octets)                       |
      |                                                               |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Direct Measurement Type    |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Session-Sender Tx counter  (S_TxC)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Session-Reflector Rx counter  (R_RxC)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Session-Reflector Tx counter  (R_TxC)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                            Value                              ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

On Mon, Jul 8, 2019 at 6:53 PM Tommy Pauly <tpauly=[email-masked]<mailto:[email-masked]>> wrote:
Hello IPPM,

Best,
Tommy (as IPPM co-chair)
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

---

From: Rakesh Gandhi <[email-masked]>
Date: Tue, 16 Jul 2019 08:27:39 -0400

Hi Tianran,
Yes, in some use-cases the TLV can carry the counters from the CPU
processing (e.g. control-plane). In other use-cases, as the counters for
the direct-mode LM (for actual data traffic) are in the hardware itself,
the hardware can counter-stamp the probe packets just like time-stamping
for DM

Thanks,
Rakesh

On Mon, Jul 15, 2019 at 11:05 PM Tianran Zhou <[email-masked]>
wrote:

> *From:* ippm [mailto:[email-masked]] *On Behalf Of *Rakesh Gandhi
> *Sent:* Monday, July 15, 2019 10:48 PM
> *To:* Tommy Pauly <tpauly=[email-masked]>
> *Cc:* [email-masked]; IETF IPPM WG <
> [email-masked]>
> *Subject:* Re: [ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv
>
>
>
> Hi Authors,
>
>      * |*   * Direct Measurement Type*   * |*          * Length*
>              * |*
>
>      * |*            * Session-Sender Tx counter* * (S_TxC)*
>               *|*
>
>      * |*            * Session-Reflector Rx counter* * (R_RxC)*
>             * |*
>
>      * |*            * Session-Reflector Tx counter* * (R_TxC)*
>             * |*
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 16 Jul 2019 08:19:22 -0700

Hi Rakesh,
I think that there could be various methods to optimize PM OAM ranging from
HW-based to CPU-centric with a number of "bump on a wire" solutions.

Regards,
Greg

On Tue, Jul 16, 2019 at 5:27 AM Rakesh Gandhi <[email-masked]>
wrote:

>> GIM>> The Direct Loss TLV is intended to immediately follow the STAMP
>> test packet and thus its location is known. We'll work on the text to guide
>> Please respond to this email by *Tuesday, July 23* to indicate whether
>> or not you think IPPM should adopt and work on the extensions and extension

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 16 Jul 2019 08:24:43 -0700

Hi Rakesh,
thank you for your insightful comments that have helped us to improve the
specification. Unfortunately, I couldn't find the summary of the questions
we've discussed. Could you kindly re-send them?

Regards,
Greg

On Mon, Jul 15, 2019 at 7:48 AM Rakesh Gandhi <[email-masked]>
wrote:

> them below for convenience. Like to see them addressed in the adopted draft

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 17 Jul 2019 01:21:47 +0000

Hi Rakesh,

I think my point is that since stamp tlv may not be optimal for the hardware processing, it’s better not to apply it in that case. So I do not think it’s necessary to consider the hardware capability.
On the other hand, stamp only takes small part of the traffic, it will not badly impact the forwarding performance.
The timestamp is another story. Slow path processing will introduce the “observer effect”. So that the measurement will not be accurate.

Thanks,
Tianran

From: Rakesh Gandhi [mailto:[email-masked]]
Sent: Tuesday, July 16, 2019 8:28 PM
To: Tianran Zhou <[email-masked]>
Cc: Tommy Pauly <tpauly=[email-masked]>; [email-masked]; IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv

Hi Tianran,
Yes, in some use-cases the TLV can carry the counters from the CPU processing (e.g. control-plane). In other use-cases, as the counters for the direct-mode LM (for actual data traffic) are in the hardware itself, the hardware can counter-stamp the probe packets just like time-stamping for DM

Thanks,
Rakesh

On Mon, Jul 15, 2019 at 11:05 PM Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rakesh,

Tianran

From: ippm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Rakesh Gandhi
Sent: Monday, July 15, 2019 10:48 PM
To: Tommy Pauly <tpauly=[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; IETF IPPM WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv

Hi Authors,

Thanks,
Rakesh

       0                   1                   2                   3

Best,
Tommy (as IPPM co-chair)

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Sat, 20 Jul 2019 18:44:54 +0000

Hi Tiaran,

Please see inline with <RG>..

From: ippm <[email-masked]> on behalf of Tianran Zhou <[email-masked]>
Date: Tuesday, July 16, 2019 at 9:23 PM
To: Rakesh Gandhi <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Tommy Pauly <tpauly=[email-masked]>, IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv

Hi Rakesh,

<RG> I think with a simple rule of having the Direct Loss TLV as the first one, this should be applicable.

<RG> Some ASIC may not be able to load the entire payload data to modify it (especially with many TLVs including padding TLVs and LM TLV happens to be the last one).

Thanks,
Rakesh

Thanks,
Tianran

Hi Tianran,

Thanks,
Rakesh

Tianran

Hi Authors,

Thanks,
Rakesh

       0                   1                   2                   3

Best,
Tommy (as IPPM co-chair)

---

From: Rakesh Gandhi <[email-masked]>
Date: Sat, 20 Jul 2019 14:48:30 -0400

Hi Greg,

Following comment was shared on the list:

However, the STAMP payload with TLV extension
(draft-mirsky-ippm-stamp-option-tlv-01) has slightly different padding size
of 30 MBZ vs 27 ( or > 29) in draft-ietf-ippm-stamp. Is there a way to make
them compatible? Does it mean that for STAMP with TLV, Server Octets is set
to 1, but it says MBZ 0 for all 30 bytes.. If the responder supports Server
Octets and see the size > 27 (when using the TLVs), it may find the Server
Octet size of 0 confusing?

Thanks,

Rakesh

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 24 Jul 2019 15:11:02 -0400

Thanks to everyone for your feedback! This document is now adopted.

Authors, please submit draft-ietf-ippm-stamp-option-tlv when ready with recent updates.

Best,
Tommy

> On Jul 8, 2019, at 6:47 PM, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> Hello IPPM,
>

---

From: J Ignacio Alvarez-Hamelin <[email-masked]>
Date: Wed, 24 Jul 2019 16:33:01 -0300

I support this draft.

Regards,

	Ignacio

_______________________________________________________________

Dr. Ing. José Ignacio Alvarez-Hamelin
CONICET and Facultad de Ingeniería, Universidad de Buenos Aires
Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina
+54 (11) 5285 0716 / 5285 0705
e-mail: [email-masked]
web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
_______________________________________________________________

> On 8 Jul 2019, at 19:47, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> Hello IPPM,
>