From nobody Mon Mar 29 06:04:24 2021 Return-Path: X-Original-To: explicit-meas@ietfa.amsl.com Delivered-To: explicit-meas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212963A1164; Mon, 29 Mar 2021 06:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HupBQIvO_N5w; Mon, 29 Mar 2021 06:04:17 -0700 (PDT) Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 426DD3A1166; Mon, 29 Mar 2021 06:04:17 -0700 (PDT) Received: by mail-yb1-xb33.google.com with SMTP id l15so13755501ybm.0; Mon, 29 Mar 2021 06:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BgVYwPGT/ot4JaqROQ8c+KVkAZWIyicV6yM1zyNlyjI=; b=KzJ2aYrIZ9DR3fzL1z1I7Elt20dNlwCkqaHnduVoJeuxOf6yBO9vf45IMp5HIY4f9C Pgve8DsaJsUiybi81bZqsqrvrHx1VAT7ZVCKVNOowl0STEsgGJ1YfEmMK9mmiwQ3qBlW C4cE1ULDGMFpvcxet8D/fPieaVK5ri3HodJ6wNB7dLX7EGVklvihQfDIl3kklTDYvbPe IlgL3DuGcrFarZZ4c+oRj3HplEGdOv+wxCscDAkIjul4FSSwo2WV/qvmJsbOcf+gvFsx IkMqijDP/28P5cwBKVBcVsFYvxSrJ7GNGmiQ3QbmlbfAr2g8jUMaHNsQJ3i47PyayzxY LkEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BgVYwPGT/ot4JaqROQ8c+KVkAZWIyicV6yM1zyNlyjI=; b=T3MsUrXrOyZGwKX2JGrMMvhv5j+sYqq2BHWckpfuBfh794R/HnuY/e4m5fqwr/vlDZ ZkY3kLuJRAkqqofC4qJv0aEsSkXVmVE5fBItEPBcm/1pfSGq0FWivwCoPs3f1GpFWA/k /Dzi0625Z1bFkJPCTgQfnYI7YmrG2TwHbWxXnn0B+51v+WUWq5dJku+Lu2zaBChxjakw +pZIoArXceaqEDMB0NPzKTq5R2esvnpYObzurn0k3n7p9Rwwn9yHmuOmJ0WEUt1HSXHM 6b9ILDgYQbV/CQDXVi1SPt+GbKQEFxuNpOdgJ6A+1u/5UntqBnJthhg0I7OIc1fD/K3W MJdg== X-Gm-Message-State: AOAM533hGieG/SZ+kVF1WIxLV9iKQURMoSEG58F+dtwzQJsJBsP7/jz5 sOT007fu7yj0sMrLJk9V6tGH2Jm00acMUmCYZzE= X-Google-Smtp-Source: ABdhPJxys3BOIXXDX4DgRCkQnMERq0r4UOTnA3LlRa5M4IfYA+hyXKU8RSemeYWZraEO0cCKMHZCsEHsscziCrbBCqI= X-Received: by 2002:a25:6814:: with SMTP id d20mr37979161ybc.53.1617023054713; Mon, 29 Mar 2021 06:04:14 -0700 (PDT) MIME-Version: 1.0 References: <8f60ffc8e0fd4376ba911c03f5c43039@TELMBXD14BA020.telecomitalia.local> <56398ea2e37a4a6ca53e85eb39add9a2@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Mon, 29 Mar 2021 08:03:48 -0500 Message-ID: To: Ian Swett Cc: "Lubashev, Igor" , "explicit-meas@ietf.org" , "tsvwg@ietf.org" , "IETF IPPM WG (ippm@ietf.org)" , "alexandre.ferrieux@orange.com" , "HAMCHAOUI Isabelle IMT/OLN" , Cociglio Mauro , "quic@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c516a405beac8445" Archived-At: Subject: Re: [Explicit-meas] Comparing Alternate Marking and Explicit Flow Measurements (Spin bit, ...) X-BeenThere: explicit-meas@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This mailing list is intended for discussions relating to Explicit Flow Measurements Techniques." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2021 13:04:22 -0000 --000000000000c516a405beac8445 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Ian, On Mon, Mar 29, 2021 at 7:01 AM Ian Swett wrote: > Thanks for the maprg slides Igor, it's great to hear you'd enable this if > it was standardized. > > > I didn't notice that you're an IPPM co-chair - congratulations to you, and to IPPM! > Has Akamai conducted any privacy analysis it would be willing to share > with the IETF? For this to be widely deployed, I think that will need to > be done, similar to the spin bit. > Exactly, because (please see below) > On Sat, Mar 27, 2021 at 4:29 PM Lubashev, Igor > wrote: > >> Thank you, Mauro. >> >> I would like to point out to IPPM WG that some of the proposed >> measurement techniques have already been implemented and had been runnin= g >> on the Internet in 2019 and 2020. Namely, Akamai has implemented Loss B= its >> (L+Q) and enabled them on a large portion of QIUC traffic served to Oran= ge >> Telecom users in several countries, while Orange implemented observers t= hat >> collected and analyzed the measurements. We have discussed the >> measurements and techniques in MAPRG during IETF-105 (and at other WGs a= nd >> meetings). >> >> Here is our IETF-105 MAPRG presentation discussing the data >> https://datatracker.ietf.org/meeting/105/materials/slides-105-maprg-pack= et-loss-signaling-for-encrypted-protocols-01 >> . >> >> In short, we found that unidirectional observations of QUIC traffic with >> L+Q bits alone to be effective for measuring both upstream and downstrea= m >> packet loss and characterizing the magnitude of packet reordering. >> >> During the last meeting Ian asked whether Akamai would implement and >> enable these measurements techniques for QUIC on the large scale, if all >> the relevant drafts get standardized by IETF. The answer is that, yes, = we >> would. We are very interested in doing what it takes to improve Interne= t >> performance for the users, and we would work hard to implement technique= s >> that can help network operators to improve QOS on their networks. >> >> - Igor >> >> > -----Original Message----- >> > From: Cociglio Mauro >> > Sent: Tuesday, March 16, 2021 9:48 AM >> > To: IETF IPPM WG (ippm@ietf.org) ; >> explicit-meas@ietf.org >> > Cc: quic@ietf.org; tsvwg@ietf.org >> > Subject: [ippm] Comparing Alternate Marking and Explicit Flow >> > Measurements (Spin bit, ...) >> > >> > Hi. >> > Last Friday during the IPPM meeting, after the "Explicit Flow >> Measurements" >> > draft presentation >> > ( >> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-mdt-ippm- >> > explicit-flow-measurements-01__;!!GjvTz_vk!CC-VjNQml5au1pXfCN50J-D- >> > O99Zvrz686frIu4shWxPEipwQd7TTuOM3NTyNCU$ ), Greg Mirsky raised an >> > issue that I think is very important. >> > The question is about differences and similarities between the two >> types of >> > production traffic packet marking for performance measurements, propos= ed >> > in IETF and initiated in the IPPM WG: Alternate Marking and Explicit >> Flow >> > Measurements. >> > >> > The first technique known as Alternate Marking or AM/PM (Alternate >> > Marking Performance Monitoring) is defined, in general terms, in RFC83= 21 >> > (the point-to-point version) and RFC8889 (the multipoint version). >> > It is essentially a Telco measurement, born to measure packet delay an= d >> loss >> > between the input and output of a network, or between 2 internal point= s >> of >> > the network, in order to identify and localize a problem. It is a >> network >> > measure and it is the network operator that performs the marking by >> > modifying packets on the fly. >> > The strength of this technique comes from the decoupling of marking an= d >> > measurement. We can mark all traffic, using a fixed marking interval >> (typically >> > "big": from 1 second up to 5 minutes), then we decide what to measure >> > based on the resources I want to use. In case of packet loss measureme= nt >> > we can start from a single packet counter for all traffic for each >> measurement >> > point (possibility described in RFC8889), to have a network >> measurement, to >> > arrive to a counter for each point-to-point connection you want to >> monitor >> > (as described in RFC8321). >> > In order to obtain the measurement it is necessary to compare the data >> > collected from at least 2 measurement points (counters for packet loss= , >> > timestamps for delay). Then a "communication" between measurement >> > points, or with a Network Measurement Center, is needed. >> > There are already commercial implementations of this technique (also f= or >> > IPv4) and IETF drafts that are standardizing it for various protocols >> (IPv6, >> > MPLS, Segment Routing, BIER, ...). >> > The Alternate Marking methodology is evolving into the draft "Big Data >> > AltMark" ( >> https://urldefense.com/v3/__https://tools.ietf.org/html/draft- >> > c2f-ippm-big-data-alt-mark-01__;!!GjvTz_vk!CC-VjNQml5au1pXfCN50J-D- >> > O99Zvrz686frIu4shWxPEipwQd7TTuOM_yNIIgs$ ) that defines point-to-point >> > flows measurements applying post processing to performance data >> collected >> > by sampling a single network multipoint flow. >> > >> > The second marking technique for performance monitoring of packet >> > networks has been called Explicit Flow Measurements (EFM), and is more >> > recent because it's born with the Spin bit RTT measurement. And it cam= e >> > about primarily to have an end-to-end performance measure, from the >> > terminal, on which an application is running, to the server at the >> opposite >> > end of the network. EFM can be seen as complementary measures to >> > Alternate Marking. >> > > One question on this. As a QUIC WG member I was under the impression the > spin bit would enable measurement within networks, but I agree that it is > best as an end-to-end measurement. However, network endpoints can and > do(ie: qlog) export metrics and traces to provide detailed information > that's much richer than spin or loss bits, which makes me less clear on t= he > value of EFM. Igor indicated it worked as intended, but there is the > separate question of whether it provides enough value on top of endpoint > logging and Alternate Marking. > Brian Trammell and I have both been chatting with the TSV ADs about topics that the PLUS BOF was relevant to. My recollection from https://datatracker.ietf.org/doc/minutes-96-plus/ was that most of the concern expressed by the SEC types in the room was about endpoints sending information to network entities that the user was not aware of (and, truth be told, that one concern detailed PLUS forevermore). (*) (*) corrections on that point are welcome, but I'd be surprised if anyone offered one. It wasn't a close BOF result. It's obvious to me that relying on qlog plus delivery of qlog output to network elements would be useful, and a lot more likely to be accurate than inferences from a heavily encrypted byte stream, but please ask very early in the process whether there's a similar concern about unwitting (from the user's perspective) leakage to operators, or just bite the bullet and do the privacy analysis now. And Good Luck. Best, Spencer > > It requires certain characteristics of the protocols to which it can be >> applied, >> > which are client-server, and it is particularly convenient for >> protocols that >> > prevent the marking of packets on the fly (e.g. QUIC), because the >> marking >> > occurs only on the end-points of the connection. >> > The disadvantage with respect to the previous technique is that it >> always >> > works for client-server point-to-point connection, it is not possible = to >> > aggregate measurements saving on monitoring resources as described in >> > RFC8889. The advantage is that it can also work with a single monitori= ng >> > point, even if having more points enhances it and allows intradomain >> > measurements. With a single measurement point you can obtain end-to-en= d >> > measures (Spin bit, Delay bit for delay and Loss bit, rT loss bit for >> packet loss) >> > or end-to-observer measures (sQuare bit and Reflection bit for packet >> loss). >> > End-to-observer measurements and scalability considerations make it >> > particularly convenient to place a measurement point on the client (se= e >> > >> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-cnbf-ippm- >> > user-devices-explicit-monitoring-01__;!!GjvTz_vk!CC-VjNQml5au1pXfCN50J= - >> > D-O99Zvrz686frIu4shWxPEipwQd7TTuOMvZGbbWs$ ). >> > >> > Best Regards. >> > >> > Mauro >> > _____________________ >> > Mauro Cociglio >> > TIM - Telecom Italia >> > Via G. Reiss Romoli, 274 >> > 10148 - Torino (Italy) >> > Tel.: +390112285028 <+39%20011%20228%205028> >> > Mobile: +393357669751 <+39%20335%20766%209751> >> > _____________________ >> > >> > >> > TIM - Uso Interno - Tutti i diritti riservati. >> > >> > Questo messaggio e i suoi allegati sono indirizzati esclusivamente all= e >> > 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 pregat= i >> 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 t= he >> > sender by return e-mail, Thanks. >> > >> > Rispetta l'ambiente. Non stampare questa mail se non =C3=A8 necessario= . >> > >> > _______________________________________________ >> > ippm mailing list >> > ippm@ietf.org >> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm= _ >> > _;!!GjvTz_vk!CC-VjNQml5au1pXfCN50J-D- >> > O99Zvrz686frIu4shWxPEipwQd7TTuOMMXmeW4s$ >> > --000000000000c516a405beac8445 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Ian,=C2=A0

On Mon, Mar 29, 2021 at 7:01 AM Ian Swe= tt <ianswett=3D40google.c= om@dmarc.ietf.org> wrote:
Thanks for the maprg sli= des Igor, it's great to hear you'd enable this if it was standardiz= ed.

<Taking off my WG chair hat>
=

I didn't notice that you're an IPP= M co-chair - congratulations to you, and to IPPM!=C2=A0
=C2=A0
Has Akamai conducted any privacy analysis it would be will= ing to share with the IETF?=C2=A0 For this to be widely deployed, I think t= hat will need to be done, similar to the spin bit.

Exactly, because (please see below)
=C2=A0
On Sat, Mar 27, 2021 at 4:29 PM Lubashev, Igo= r <ilubashe@aka= mai.com> wrote:
Thank you, Mauro.

I would like to point out to IPPM WG that some of the proposed measurement = techniques have already been implemented and had been running on the Intern= et in 2019 and 2020.=C2=A0 Namely, Akamai has implemented Loss Bits (L+Q) a= nd enabled them on a large portion of QIUC traffic served to Orange Telecom= users in several countries, while Orange implemented observers that collec= ted and analyzed the measurements.=C2=A0 We have discussed the measurements= and techniques in MAPRG during IETF-105 (and at other WGs and meetings).
Here is our IETF-105 MAPRG presentation discussing the data https://datatracker.ietf.org/meeting/105/materials/slides-105-maprg-packet= -loss-signaling-for-encrypted-protocols-01.

In short, we found that unidirectional observations of QUIC traffic with L+= Q bits alone to be effective for measuring both upstream and downstream pac= ket loss and characterizing the magnitude of packet reordering.

During the last meeting Ian asked whether Akamai would implement and enable= these measurements techniques for QUIC on the large scale, if all the rele= vant drafts get standardized by IETF.=C2=A0 The answer is that, yes, we wou= ld.=C2=A0 We are very interested in doing what it takes to improve Internet= performance for the users, and we would work hard to implement techniques = that can help network operators to improve QOS on their networks.

- Igor

> -----Original Message-----
> From: Cociglio Mauro <mauro.cociglio=3D40telecomitalia.it@dmarc.ietf.or= g>
> Sent: Tuesday, March 16, 2021 9:48 AM
> To: IETF IPPM WG (i= ppm@ietf.org) <ip= pm@ietf.org>; explicit-meas@ietf.org
> Cc: quic@ietf.org; tsvwg@ietf.org<= br> > Subject: [ippm] Comparing Alternate Marking and Explicit Flow
> Measurements (Spin bit, ...)
>
> Hi.
> Last Friday during the IPPM meeting, =C2=A0after the "Explicit Fl= ow Measurements"
> draft presentation
> (https://urldefense.com/= v3/__https://tools.ietf.org/html/draft-mdt-ippm-
> explicit-flow-measurements-01__;!!GjvTz_vk!CC-VjNQml5au1pXfCN50J-D- > O99Zvrz686frIu4shWxPEipwQd7TTuOM3NTyNCU$ ), Greg Mirsky raised an
> issue that I think is very important.
> The question is about differences and similarities between the two typ= es of
> production traffic packet marking for performance measurements, propos= ed
> in IETF and initiated in the IPPM WG: Alternate Marking and Explicit F= low
> Measurements.
>
> The first technique known as Alternate Marking or AM/PM (Alternate
> Marking Performance Monitoring) is defined, in general terms, in RFC83= 21
> (the point-to-point version) and RFC8889 (the multipoint version).
> It is essentially a Telco measurement, born to measure packet delay an= d loss
> between the input and output of a network, or between 2 internal point= s of
> the network, in order to identify and localize a problem. It is a netw= ork
> measure and it is the network operator that performs the marking by > modifying packets on the fly.
> The strength of this technique comes from the decoupling of marking an= d
> measurement. We can mark all traffic, using a fixed marking interval (= typically
> "big": from 1 second up to 5 minutes), then we decide what t= o measure
> based on the resources I want to use. In case of packet loss measureme= nt
> we can start from a single packet counter for all traffic for each mea= surement
> point (possibility described in RFC8889), to have a network measuremen= t, to
> arrive to a counter for each point-to-point connection you want to mon= itor
> (as described in RFC8321).
> In order to obtain the measurement it is necessary to compare the data=
> collected from at least 2 measurement points (counters for packet loss= ,
> timestamps for delay). Then a "communication" between measur= ement
> points, or with a Network Measurement Center, is needed.
> There are already commercial implementations of this technique (also f= or
> IPv4) and IETF drafts that are standardizing it for various protocols = (IPv6,
> MPLS, Segment Routing, BIER, ...).
> The Alternate Marking methodology is evolving into the draft "Big= Data
> AltMark" (https://urldefense= .com/v3/__https://tools.ietf.org/html/draft-
> c2f-ippm-big-data-alt-mark-01__;!!GjvTz_vk!CC-VjNQml5au1pXfCN50J-D- > O99Zvrz686frIu4shWxPEipwQd7TTuOM_yNIIgs$ ) that defines point-to-point=
> flows measurements applying post processing to performance data collec= ted
> by sampling a single network multipoint flow.
>
> The second marking technique for performance monitoring of packet
> networks has been called Explicit Flow Measurements (EFM), and is more=
> recent because it's born with the Spin bit RTT measurement. And it= came
> about primarily to have an end-to-end performance measure, from the > terminal, on which an application is running, to the server at the opp= osite
> end of the network. EFM can be seen as complementary measures to
> Alternate Marking.

One question on= this.=C2=A0 As a QUIC WG member I was under the impression the spin bit wo= uld enable measurement within networks, but I agree that it is best as an e= nd-to-end measurement.=C2=A0 However, network endpoints can and do(ie: qlog= ) export metrics and traces to provide detailed information that's much= richer than spin or loss bits, which makes me less clear on the value of E= FM.=C2=A0 Igor indicated it worked as intended, but there is the separate q= uestion of whether it provides enough value on top of endpoint logging and = Alternate Marking.

Brian = Trammell and I have both been chatting with the TSV ADs about topics that t= he PLUS BOF was relevant to. My recollection from=C2=A0https://datatracker.ietf.org/doc/= minutes-96-plus/ was that most of the concern expressed by the SEC type= s in the room was about endpoints sending information to network entities t= hat the user was not aware of (and, truth be told, that one concern detaile= d PLUS forevermore). (*)

(*) corrections on that p= oint are welcome, but I'd be surprised if anyone offered one. It wasn&#= 39;t a close BOF result.=C2=A0

It's obvious to= me that relying on qlog plus delivery of qlog output to network elements w= ould be useful, and a lot more likely to be accurate than inferences from a= heavily encrypted byte stream, but please ask very early in the process wh= ether there's a similar concern about unwitting (from the user's pe= rspective) leakage to operators, or just bite the bullet and do the privacy= analysis now.

And Good Luck.=C2=A0

=
Best,

Spencer
=C2=A0
> It = requires certain characteristics of the protocols to which it can be applie= d,
> which are client-server, and it is particularly convenient for protoco= ls that
> prevent the marking of packets on the fly (e.g. QUIC), because the mar= king
> occurs only on the end-points of the connection.
> The disadvantage with respect to the previous technique is that it alw= ays
> works for client-server point-to-point connection, it is not possible = to
> aggregate measurements saving on monitoring resources as described in<= br> > RFC8889. The advantage is that it can also work with a single monitori= ng
> point, even if having more points enhances it and allows intradomain > measurements. With a single measurement point you can obtain end-to-en= d
> measures (Spin bit, Delay bit for delay and Loss bit, rT loss bit for = packet loss)
> or end-to-observer measures (sQuare bit and Reflection bit for packet = loss).
> End-to-observer measurements and scalability considerations make it > particularly convenient to place a measurement point on the client (se= e
> https://urldefense.com/= v3/__https://tools.ietf.org/html/draft-cnbf-ippm-
> user-devices-explicit-monitoring-01__;!!GjvTz_vk!CC-VjNQml5au1pXfCN50J= -
> D-O99Zvrz686frIu4shWxPEipwQd7TTuOMvZGbbWs$ ).
>
> Best Regards.
>
> Mauro
> _____________________
> Mauro Cociglio
> TIM - Telecom Italia
> Via G. Reiss Romoli, 274
> 10148 - Torino (Italy)
> Tel.: +390112285028
> Mobile: +393357669751
> _____________________
>
>
> TIM - Uso Interno - Tutti i diritti riservati.
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente all= e
> persone indicate. La diffusione, copia o qualsiasi altra azione deriva= nte dalla
> conoscenza di queste informazioni sono rigorosamente vietate. Qualora<= br> > abbiate ricevuto questo documento per errore siete cortesemente pregat= i di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privil= eged
> information intended for the addressee(s) only. Dissemination, copying= ,
> printing or use by anybody else is unauthorised. If you are not the in= tended
> recipient, please delete this message and any attachments and advise t= he
> sender by return e-mail, Thanks.
>
> Rispetta l'ambiente. Non stampare questa mail se non =C3=A8 necess= ario.
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org > https://urldefense.com/v= 3/__https://www.ietf.org/mailman/listinfo/ippm_
> _;!!GjvTz_vk!CC-VjNQml5au1pXfCN50J-D-
> O99Zvrz686frIu4shWxPEipwQd7TTuOMMXmeW4s$
--000000000000c516a405beac8445--