Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5273912D856 for ; Mon, 15 Jan 2018 13:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 QTiMxPX_MiGW for ; Mon, 15 Jan 2018 13:10:06 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2D112D77C for ; Mon, 15 Jan 2018 13:10:06 -0800 (PST) Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0FL9V7v043846 for ; Mon, 15 Jan 2018 16:10:05 -0500 Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [192.155.248.73]) by mx0a-001b2d01.pphosted.com with ESMTP id 2fgx91pyu0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 15 Jan 2018 16:10:05 -0500 Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for from ; Mon, 15 Jan 2018 21:10:04 -0000 Received: from us1a3-smtp08.a3.dal06.isc4sb.com (10.146.103.57) by smtp.notes.na.collabserv.com (10.106.227.90) with smtp.notes.na.collabserv.com ESMTP; Mon, 15 Jan 2018 21:10:01 -0000 Received: from us1a3-mail64.a3.dal09.isc4sb.com ([10.142.3.135]) by us1a3-smtp08.a3.dal06.isc4sb.com with ESMTP id 2018011521100136-995231 ; Mon, 15 Jan 2018 21:10:01 +0000 In-Reply-To: <20180115185043.vj3ikpfqhsuycdm4@elstar.local> From: "Wayne Tackabury" To: j.schoenwaelder@jacobs-university.de Cc: ipfix@ietf.org Date: Mon, 15 Jan 2018 21:10:01 +0000 Sensitivity: MIME-Version: 1.0 References: <20180115185043.vj3ikpfqhsuycdm4@elstar.local>, <085c30b9-5797-863e-a63d-a027396f224f@gmail.com> <167798e2-f7a7-6946-8f3c-6bf996514bec@net.in.tum.de> <8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429@PLXRDC01.plxr.local> Importance: Normal X-Priority: 3 (Normal) X-Mailer: IBM Verse Build 15909-1273 | IBM Domino Build SCN1734600_20171212T0033_FP3 January 05, 2018 at 15:38 X-LLNOutbound: False X-Disclaimed: 10555 X-TNEFEvaluated: 1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 x-cbid: 18011521-3107-0000-0000-0000049D0EB3 X-IBM-SpamModules-Scores: BY=0.294031; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.394815; ST=0; TS=0; UL=0; ISC=; MB=0.454028 X-IBM-SpamModules-Versions: BY=3.00008384; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000245; SDB=6.00975528; UDB=6.00494440; IPR=6.00755456; BA=6.00005778; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00019054; XFM=3.00000015; UTC=2018-01-15 21:10:03 X-IBM-AV-DETECTION: SAVI=unsuspicious REMOTE=unsuspicious XFE=unused X-IBM-AV-VERSION: SAVI=2018-01-15 19:58:38 - 6.00007912 x-cbparentid: 18011521-3108-0000-0000-00007DD61069 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-15_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 21:10:12 -0000
Regarding SCTP, a= s of this writing, it is not and can not be mandatory.  Not many comme= rcial collectors support it.  I've found this to be a bit of an "eleph= ant in the room" on the RFC directions.
 
To be perfectly practical, as things have emerged since t= he days of RFC[s] 510x, SCTP has not been made sufficiently stable in linux= kernel and user interfaces that it could support carrier-grade flow convey= ance dependencies.  There are probably other nontechnical barriers to = acceptance. To be sure, this is unfortunate, since SCTP still admirably mee= ts the original design goals.
 
Without getting into it, where I'm aware of implementatio= ns that meed tp make use of the "messaging" benefits of SCTP over UDP, the = less-than-standard path of TCP over some defacto standard port  has be= en used.  Others may know of different implementations, but this is ba= sed on subjective, but voluminous, input from implementations I've seen at = customer sites and discussions with colleagues at different vendor enterpri= ses.  Again, this is not an editorial on technical merit.
 
Regards,
Wayne
 
 
----- Original message -----
From: Juergen Schoenwael= der <j.schoenwaelder@jacobs-university.de>
Sent by: "IPFIX" <ip= fix-bounces@ietf.org>
To: Andrew Feren <andrew.feren@plixer.com>= ;
Cc: 'Marta Seda' <Marta.Seda@calix.com>, "Aitken, Paul" <paul= .aitken@intl.att.com>, "'ipfix@ietf.org'" <ipfix@ietf.org>
Subj= ect: Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion
Date: Mo= n, Jan 15, 2018 1:51 PM
 
I fail to see why this would be the case. (But I agree that renamingidentifiers for the sake of renaming them is having little value.)
/js

On Mon, Jan 15, 2018 at 06:09:20PM +0000, Andrew Feren wrote:> In particular renaming identifiers would break any implementations o= f RFC 7373 "Textual Representation of IP Flow Information Export (IPFIX) Ab= stract Data Types".
>
> -Andrew
>
> =5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> From: IPFIX [ipfix-bounces@ietf.org] on behalf of Gerhard Mu= enz [muenz@net.in.tum.de]
> Sent: Saturday, January 13, 2018 4:43 AM<= br>> To: Benoit Claise; Aitken, Paul; 'Marta Seda'
> Cc: 'ipfix@ie= tf.org'
> Subject: [QUAR] Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discus= sion
>
>
> Marta, all,
>
> A few additional t= houghts regarding your questions:
>
> 1) I would not expect tha= t not following current naming convention hinders implementation of RFC 672= 8. On the other hand, if we change just the names of the identifiers, we lo= se interoperability with older implementations that may exist.
>
&= gt; 2) I think that it is reasonable that destinationIPAddress is mandatory= because network management systems should be able to query the IP address = to which an Exporting Process sends data. As Paul stated, RFC 6728 does not= say how the destination IP address is set.
>
> 3) SCTP is stil= l a mandatory transport for a compliant implementation of an IPFIX device, = not a feature. See: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A=5F=5Ftools= .ietf.org=5Fhtml=5Frfc7011-23section-2D10.1&d=3DDwIGaQ&c=3Djf=5FiaS= HvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR=5FUtUw4WaW=5F=5FJt3CBhpQR6Qa=5Fk= E&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DqunYBh7bv5ABG= GsiP6-CjGVRw8xFMTnuuwuibkkNfBE&e=3D<https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A=5F=5Fl= inkprotect.cudasvc.com=5Furl-3Fa-3Dhttps-3A=5F=5Ftools.ietf.org=5Fhtml=5Frf= c7011-2523section-2D10.1-26c-3DE-2C1-2Cr3o6fj1SXot8TQIPgevXNx5yfL8QvlF982Ch= 9DX27MByjz7bAdEaF9tjDoDzj1XgWtTXYfN1Z9mXiFy81bK1Aq33fYFzGl5W-2D2Dh-5F-2DxeP= oq9GNzzaPGdYj0o-26typo-3D1&d=3DDwIGaQ&c=3Djf=5FiaSHvJObTbx-siA1ZOg&= amp;r=3DeSiUkUZU9l60y0gvR=5FUtUw4WaW=5F=5FJt3CBhpQR6Qa=5FkE&m=3DAqj94EL= pPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DM0CgR7V3IlBqkpQDo2Brx-bewHWnHX= =5Fa5l7YChB32BI&e=3D>
>
> Best regards,
> Gerh= ard
>
>
>
> On 10.01.2018 08:33, Benoit Claise wrot= e:
> Hi,
> Marta, Benoit,
>
> 1. Are there efforts = to update other RFCs to meet the latest YANG best practices?
> Yes. E= x: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A=5F=5Fdatat= racker.ietf.org=5Fdoc=5Fdraft-2Dietf-2Dnetmod-2Drfc7223bis=5F&d=3DDwIGa= Q&c=3Djf=5FiaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR=5FUtUw4WaW=5F= =5FJt3CBhpQR6Qa=5FkE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&am= p;s=3DDml5zgSWzeUBwS1XyKmCG-y3bWePHxpzt3PCej4w=5Fzw&e=3D<https://urldefense.proofpoint= .com/v2/url?u=3Dhttps-3A=5F=5Flinkprotect.cudasvc.com=5Furl-3Fa-3Dhttps-3A= =5F=5Fdatatracker.ietf.org=5Fdoc=5Fdraft-2Dietf-2Dnetmod-2Drfc7223bis=5F-26= c-3DE-2C1-2C990HtCyvSKBHwQOS7jpHkeSpsvC2M7iKDlI-5FbfqIgW2gpaEOYhngASoi8LRRh= uM67bRdHS2Hyi7cVHyXDuiheARWFxSpap-5FiznZ68ZknJgFbizFJolgU-26typo-3D1&d= =3DDwIGaQ&c=3Djf=5FiaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR=5FUtUw= 4WaW=5F=5FJt3CBhpQR6Qa=5FkE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOL= L3H8&s=3DwhhuVEyPDEyPYoboty-rb0h=5FRQBoHKqNmiQoGwpLBlw&e=3D>=
> The goal is to specify NMDA-compliant (draft-ietf-netmod-revised-d= atastores-09<https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A=5F=5Flinkprotec= t.cudasvc.com=5Furl-3Fa-3Dhttps-3A=5F=5Fdatatracker.ietf.org=5Fdoc=5Fdraft-= 2Dietf-2Dnetmod-2Drevised-2Ddatastores=5F-26c-3DE-2C1-2CByKxVFeHf8k0Yb1kzzk= QnQg33VfrR12Hy6dJzQTbkgStXZt3NzfCi7l981VvXCCM3L3iwQ3FF8lz77mT4C5yuZEfVe-2D7= 8uXEs5xDZql2y-2D-2D4iDlmOUQ-2C-26typo-3D1&d=3DDwIGaQ&c=3Djf=5FiaSHv= JObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR=5FUtUw4WaW=5F=5FJt3CBhpQR6Qa=5FkE&= amp;m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DgGNMKyVcGZrZBCb= Vl5XjjnnyJnRDUxt8jU3e24fcQBU&e=3D>) YANG modules
>
>= 2. Since the IPFIX WG closed, there has been little ongoing IPFIX work in = the IETF. Is there a specific need to update RFC 6728 rather than just reco= gnising it as a product of it's time?
> This type of feedback should = come from implementation experience.
>
> Regards, Benoit
>= ; Note that it's > 5 years old.
>
> Also see @PJ inline:
= >
>
> On 09/01/2018 16:01, Benoit Claise wrote:
> Hi M= arta,
> Hello,
> I am reaching out to the IETF IPFIX mailing li= st  on some issues I have run into with respect to RFC 6728 =E2=80=9CC= onfiguration Data Model for the IP Flow Information Export (IPFIX)  an= d Packet Sampling (PSAMP) Protocols=E2=80=9D
>
>
>  = 1.  RFC 6728 doesn=E2=80=99t meet the latest Yang Best Practices (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A=5F= =5Ftools.ietf.org=5Fhtml=5Fdraft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23sectio= n-2D4.3.1&d=3DDwIGaQ&c=3Djf=5FiaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9= l60y0gvR=5FUtUw4WaW=5F=5FJt3CBhpQR6Qa=5FkE&m=3DAqj94ELpPz5BmoxxBT4zFaWh= v6uxVZ5pB5BvoOLL3H8&s=3DSSYo4WM-xFfyPgrSh-cja-jQFQEucW4daULPdwg2zSI&= ;e=3D<https://urldefense.proofpoi= nt.com/v2/url?u=3Dhttps-3A=5F=5Flinkprotect.cudasvc.com=5Furl-3Fa-3Dhttps-3= A=5F=5Furldefense.proofpoint.com=5Fv2=5Furl-253fu-253dhttps-2D3A-5F-5Ftools= .ietf.org-5Fhtml-5Fdraft-2D2Dietf-2D2Dnetmod-2D2Drfc6087bis-2D2D15-2D23sect= ion-2D2D4.3.1-2526d-253dDwMD-2Dg-2526c-253dLFYZ-2Do9-5FHUMeMTSQicvjIg-2526r= -253df8F8yzrqBTw6EPtR1rbibO-5FVFIc-2DcdnjIJ9he-5Fqu7xs-2526m-253d0c5ATjuT0-= 2D4IlDzLYM9h-5FRbPjCBQUv-5F6aExRL-5Ffl-2D5M-2526s-253dHhi7V6njCFNBbSsjC6sPg= NfVu5DA8iQzdzsnA-5FiQBzQ-2526e-253d-26c-3DE-2C1-2C5Zsm8llhIef-5FjTZU2aAY2fj= -5FKvmJs-2DzBz2HIfVEkrhY7UwWsg3UnykcCPzCUM7b-5FL6CTmk-5FVY1-2DTo7t8aTM7RBz2= ayGhe3OrxbBk7-5FOy6I7gQSkKDC8Eig-2C-2C-26typo-3D1&d=3DDwIGaQ&c=3Djf= =5FiaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR=5FUtUw4WaW=5F=5FJt3CBhpQR6= Qa=5FkE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3Doj6Kq-4= SRjuodk73yxC5K1cDKw8XP95L=5FH=5Fm3ErUuQM&e=3D>).   Leaf ide= ntifiers are camel case (e.g., destinationAddress instead of destination-ad= dress).  Are there any ongoing efforts to update RFC 6728 to meet the = latest best practices?
> Not as far as I know.
>
> Regard= s, Benoit
>
>
>   1.
>
>    Id= entifiers SHOULD follow a consistent naming pattern throughout the
> =    module.  Only lower-case letters, numbers, and dashes SHO= ULD be used
>    in identifier names.  Upper-case char= acters and the underscore
>    character MAY be used if the= identifier represents a well-known value
>    that uses th= ese characters.
>
>    Identifiers SHOULD include com= plete words and/or well-known acronyms
>    or abbreviation= s.  Child nodes within a container or list SHOULD NOT
>   &= nbsp;replicate the parent identifier.  YANG identifiers are hierarchic= al
>    and are only meant to be unique within the the set = of sibling nodes
>    defined in the same module namespace.=
>
>    It is permissible to use common identifiers s= uch as "name" or "id" in
>    data definition statements, e= specially if these data nodes share a
>    common data type= .
>
>    Identifiers SHOULD NOT carry any special sem= antics that identify data
>    modelling properties.  = Only YANG statements and YANG extension
>    statements are= designed to convey machine readable data modelling
>    pr= operties.  For example, naming an object "config" or "state" does
&= gt;    not change whether it is configuration data or state data.=  Only
>    defined YANG statements or YANG extension = statements can be used to
>    assign semantics in a machin= e readable format in YANG.
>
>
>   1.  I genera= ted the RFC 6728 yang tree (see attached).  The tcp and udp exporting = processes support a destinationIPAddress (line 400, 455) which is mandatory= .  The type is inet:ip-address.
>
>      * =   A collector may be doing load balancing.  Rather than managing = ip-addresses, the collector may be using DNS (an exporter could resolve fro= m the domain name where the collector is located).
>
> @PJ: Loa= d balancing and DNS are independent. Load balancing IPFIX is probably a bad= idea since templates need to be available on all collectors, and out of st= ep sequence numbers in the data records would cause spurious reports of los= t data. If DNS is used to obtain the collector's address, arguably it shoul= d be a one-time lookup rather than incurring a DNS lookup per export packet= .
>
>
>
>   1.
>
>     &= nbsp;*
>      *   The collector address may be le= arnt via other methods (e.g., through DHCP options)
>     &= nbsp;*   A choice statement to select what method to use seems more ap= propriate than what is presently in RFC 6728.  For example (use some s= horthand)
>
> choice destination-method{
>     =             case destination-address{
>=                     &nbs= p;           leaf destination-address// rw with ty= pe inet:host
>                = ; }
>                 case dh= cp-acquired-address{
>             &nbs= p;                   container= dcp-acquired-address{
>             &n= bsp;                     =               leaf destination-ip-addres= s inet-address //ro
>              = ;   }
> }
>
>           &nb= sp;                     H= owever I can=E2=80=99t augment to ietf-ipfix because destinationIPAddress i= s mandatory.  Can the group suggest methods to (a) change the destinat= ionIPAddress type and (b) allow a choice?
>
> @PJ: The selectio= n could also be done out of band so the exporter need not know how the addr= ess is determined. eg a configuration system could determine the address by= any of these methods or otherwise, and impose that address using the curre= nt model.
>
>
>
>   1.  RFC 6728 mandates= SCTP transport.  I understand the logic behind this (IETF prefers use= of SCTP).  There are situations where sctp is unnecessary and not sup= ported (e.g., point to point connection).  During netconf negotiations= you can announce your feature set (currently sctptransport is not a featur= e).  Is there ongoing work in updating RFC 6728 to include sctptranspo= rt as a feature (so that the device can announce whether or not it supports= sctptransport)?
>
> @PJ Same answer as point (2) above, ie is = this necessary and useful?
>
> P.
>
>
>
&g= t;
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F
> IPFIX mailing list
> IPFIX@ietf.org<mailto:IPFIX@ietf.org>
> = https://urldefense.p= roofpoint.com/v2/url?u=3Dhttps-3A=5F=5Fwww.ietf.org=5Fmailman=5Flistinfo=5F= ipfix&d=3DDwIGaQ&c=3Djf=5FiaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y= 0gvR=5FUtUw4WaW=5F=5FJt3CBhpQR6Qa=5FkE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6ux= VZ5pB5BvoOLL3H8&s=3DzSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e= =3D<https://urldefense.proofpoint.com/v2/url?u= =3Dhttps-3A=5F=5Flinkprotect.cudasvc.com=5Furl-3Fa-3Dhttps-3A=5F=5Fwww.ietf= .org=5Fmailman=5Flistinfo=5Fipfix-26c-3DE-2C1-2CQcSaORG4ENECojkXawtykKdqqGa= KdIQCAXU-5Fk7DUoimbxp4p9KhoEppQlQ1LswK1E5yY5kvIL8XYyqMbCphIEyv8aBgtyyQbbN31= fnbrx9I-2C-26typo-3D1&d=3DDwIGaQ&c=3Djf=5FiaSHvJObTbx-siA1ZOg&r= =3DeSiUkUZU9l60y0gvR=5FUtUw4WaW=5F=5FJt3CBhpQR6Qa=5FkE&m=3DAqj94ELpPz5B= moxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DcQFI-IsxLhklEI0w-JcCksB=5FYNvx9v06C= pqsjQys0N8&e=3D>
>
>

> =5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> IPFIX mailing list=
> IPFIX@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A=5F=5Fw= ww.ietf.org=5Fmailman=5Flistinfo=5Fipfix&d=3DDwIGaQ&c=3Djf=5FiaSHvJ= ObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR=5FUtUw4WaW=5F=5FJt3CBhpQR6Qa=5FkE&a= mp;m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DzSpyB0Ig1-hgDSYs= X7hH1qdwzy0nZuWAMrFjAY3q02U&e=3D


--
Juergen Schoenwae= lder           Jacobs University Bremen gGmbH
P= hone: +49 421 200 3587         Campus Ring 1 | 28759 Br= emen | Germany
Fax:   +49 421 200 3103         = <https://urldefense.proofpo= int.com/v2/url?u=3Dhttps-3A=5F=5Fwww.jacobs-2Duniversity.de=5F&d=3DDwIG= aQ&c=3Djf=5FiaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR=5FUtUw4WaW=5F= =5FJt3CBhpQR6Qa=5FkE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&am= p;s=3DcC8C3QfrkIEC1Vo-QLwKrh955-evz=5FTr3MYoFDTmD1A&e=3D>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
IP= FIX mailing list
IPFIX@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A= =5F=5Fwww.ietf.org=5Fmailman=5Flistinfo=5Fipfix&d=3DDwIGaQ&c=3Djf= =5FiaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR=5FUtUw4WaW=5F=5FJt3CBhpQR6= Qa=5FkE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DzSpyB0I= g1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=3D