Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion

Benoit Claise <bclaise@cisco.com> Mon, 15 January 2018 21:18 UTC

Return-Path: <bclaise@cisco.com>
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 31A4412EC2F for <ipfix@ietfa.amsl.com>; Mon, 15 Jan 2018 13:18:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.528
X-Spam-Level:
X-Spam-Status: No, score=-13.528 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 U6FaKo5A4CHb for <ipfix@ietfa.amsl.com>; Mon, 15 Jan 2018 13:18:34 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DAE3120713 for <ipfix@ietf.org>; Mon, 15 Jan 2018 13:18:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44593; q=dns/txt; s=iport; t=1516051113; x=1517260713; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=rIbqj41pXrsV65DqMD8PM76jyLBHNvsv6nz2P4FLRe4=; b=lYZSMTC1q2LLG4Pfvb+PGUicr7Bi5nAEMxNd2DHqqF9strmXFRzfciHu LOVxRqxWj+NWsOTGJHY/2LZIVBMIqoR/4Yf6PcYeueqSt/fazJAUqjcBe MfyO1yenSiMzOAdz5LdxnJA7f+LG5BGLcaf3RaFdt/VlUZI8aHxFdt9di w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQAFGl1a/xbLJq1SBwMZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgkqBXXQnhBOLGI9tlyyCFgoYAQ2FFQKFEhYBAQEBAQEBAQF?= =?us-ascii?q?rKIUjAQEBBAEBGAlEBwsFCQIJAg4CAQMBAQEBIAEGAwICGwwfCQgGAQwGAgEBi?= =?us-ascii?q?i8Qik6dcIInJokkAQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWII4FpKYMFgUmBZgE?= =?us-ascii?q?BAhmBKzsQAQsbglCCZQWKcIc3kT2IDI0/ghlniSWHa4poglaBXogJgTwmBS2BU?= =?us-ascii?q?DIaCBsVPYIqCYJXgXhANwEBAQGNCAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,365,1511827200"; d="scan'208,217";a="1415674"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2018 21:18:30 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0FLIURQ030690; Mon, 15 Jan 2018 21:18:30 GMT
To: Wayne Tackabury <wtackabury@us.ibm.com>, j.schoenwaelder@jacobs-university.de
Cc: ipfix@ietf.org
References: <20180115185043.vj3ikpfqhsuycdm4@elstar.local> <085c30b9-5797-863e-a63d-a027396f224f@gmail.com> <a3fc69e8-5773-5785-09ca-409c6a07db57@gmail.com> <A3625616CA873B4DAA779ABEFA624F1C8BE3CA@gbcdcmbx03.intl.att.com> <c20055e4-d9a1-0652-8221-ce54387dedea@cisco.com> <167798e2-f7a7-6946-8f3c-6bf996514bec@net.in.tum.de> <8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429@PLXRDC01.plxr.local> <OF39D57ECE.E528A80C-ON00258216.00736598-00258216.00744614@notes.na.collabserv.com>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <e57a8a17-ca0a-be95-b865-a38ca1f60acb@cisco.com>
Date: Mon, 15 Jan 2018 22:18:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <OF39D57ECE.E528A80C-ON00258216.00736598-00258216.00744614@notes.na.collabserv.com>
Content-Type: multipart/alternative; boundary="------------2B03182A9B4EFD4EF83D802A"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipfix/SkhQ4CmgdNrUXVlbbawCIRQZsbE>
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 <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipfix/>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jan 2018 21:18:39 -0000

On 1/15/2018 10:10 PM, Wayne Tackabury wrote:
> Regarding SCTP, as of this writing, it is not and can not be 
> mandatory.  Not many commercial collectors support it.  I've found 
> this to be a bit of an "elephant in the room" on the RFC directions.
No disagreement.
http://www.claise.be/2015/06/from-netflow-to-ipfix-via-psamp-13-years-of-standardization-explained-2/

Regards, B.
> To be perfectly practical, as things have emerged since the 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 
> conveyance dependencies. There are probably other nontechnical 
> barriers to acceptance. To be sure, this is unfortunate, since SCTP 
> still admirably meets the original design goals.
> Without getting into it, where I'm aware of implementations 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 
> been used.  Others may know of different implementations, but this is 
> based on subjective, but voluminous, input from implementations I've 
> seen at customer sites and discussions with colleagues at different 
> vendor enterprises.  Again, this is not an editorial on technical merit.
> Regards,
> Wayne
>
>     ----- Original message -----
>     From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>;
>     Sent by: "IPFIX" <ipfix-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>;
>     Subject: Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion
>     Date: Mon, Jan 15, 2018 1:51 PM
>     I fail to see why this would be the case. (But I agree that renaming
>     identifiers 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 of RFC 7373 "Textual Representation of IP Flow
>     Information Export (IPFIX) Abstract Data Types".
>     >
>     > -Andrew
>     >
>     > ________________________________
>     > From: IPFIX [ipfix-bounces@ietf.org] on behalf of Gerhard Muenz
>     [muenz@net.in.tum.de]
>     > Sent: Saturday, January 13, 2018 4:43 AM
>     > To: Benoit Claise; Aitken, Paul; 'Marta Seda'
>     > Cc: 'ipfix@ietf.org';
>     > Subject: [QUAR] Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion
>     >
>     >
>     > Marta, all,
>     >
>     > A few additional thoughts regarding your questions:
>     >
>     > 1) I would not expect that not following current naming
>     convention hinders implementation of RFC 6728. On the other hand,
>     if we change just the names of the identifiers, we lose
>     interoperability with older implementations that may exist.
>     >
>     > 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 still a mandatory transport for a compliant
>     implementation of an IPFIX device, not a feature. See:
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7011-23section-2D10.1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=qunYBh7bv5ABGGsiP6-CjGVRw8xFMTnuuwuibkkNfBE&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__tools.ietf.org_html_rfc7011-2523section-2D10.1-26c-3DE-2C1-2Cr3o6fj1SXot8TQIPgevXNx5yfL8QvlF982Ch9DX27MByjz7bAdEaF9tjDoDzj1XgWtTXYfN1Z9mXiFy81bK1Aq33fYFzGl5W-2D2Dh-5F-2DxePoq9GNzzaPGdYj0o-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=M0CgR7V3IlBqkpQDo2Brx-bewHWnHX_a5l7YChB32BI&e=>
>     >
>     > Best regards,
>     > Gerhard
>     >
>     >
>     >
>     > On 10.01.2018 08:33, Benoit Claise wrote:
>     > Hi,
>     > Marta, Benoit,
>     >
>     > 1. Are there efforts to update other RFCs to meet the latest
>     YANG best practices?
>     > Yes. Ex:
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drfc7223bis_&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=Dml5zgSWzeUBwS1XyKmCG-y3bWePHxpzt3PCej4w_zw&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drfc7223bis_-26c-3DE-2C1-2C990HtCyvSKBHwQOS7jpHkeSpsvC2M7iKDlI-5FbfqIgW2gpaEOYhngASoi8LRRhuM67bRdHS2Hyi7cVHyXDuiheARWFxSpap-5FiznZ68ZknJgFbizFJolgU-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=whhuVEyPDEyPYoboty-rb0h_RQBoHKqNmiQoGwpLBlw&e=>
>     > The goal is to specify NMDA-compliant
>     (draft-ietf-netmod-revised-datastores-09<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drevised-2Ddatastores_-26c-3DE-2C1-2CByKxVFeHf8k0Yb1kzzkQnQg33VfrR12Hy6dJzQTbkgStXZt3NzfCi7l981VvXCCM3L3iwQ3FF8lz77mT4C5yuZEfVe-2D78uXEs5xDZql2y-2D-2D4iDlmOUQ-2C-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=gGNMKyVcGZrZBCbVl5XjjnnyJnRDUxt8jU3e24fcQBU&e=>;)
>     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 recognising 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 Marta,
>     > Hello,
>     > I am reaching out to the IETF IPFIX mailing list  on some issues
>     I have run into with respect to RFC 6728 “Configuration Data Model
>     for the IP Flow Information Export (IPFIX)  and Packet Sampling
>     (PSAMP) Protocols”
>     >
>     >
>     >   1.  RFC 6728 doesn’t meet the latest Yang Best Practices
>     (https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23section-2D4.3.1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=SSYo4WM-xFfyPgrSh-cja-jQFQEucW4daULPdwg2zSI&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__urldefense.proofpoint.com_v2_url-253fu-253dhttps-2D3A-5F-5Ftools.ietf.org-5Fhtml-5Fdraft-2D2Dietf-2D2Dnetmod-2D2Drfc6087bis-2D2D15-2D23section-2D2D4.3.1-2526d-253dDwMD-2Dg-2526c-253dLFYZ-2Do9-5FHUMeMTSQicvjIg-2526r-253df8F8yzrqBTw6EPtR1rbibO-5FVFIc-2DcdnjIJ9he-5Fqu7xs-2526m-253d0c5ATjuT0-2D4IlDzLYM9h-5FRbPjCBQUv-5F6aExRL-5Ffl-2D5M-2526s-253dHhi7V6njCFNBbSsjC6sPgNfVu5DA8iQzdzsnA-5FiQBzQ-2526e-253d-26c-3DE-2C1-2C5Zsm8llhIef-5FjTZU2aAY2fj-5FKvmJs-2DzBz2HIfVEkrhY7UwWsg3UnykcCPzCUM7b-5FL6CTmk-5FVY1-2DTo7t8aTM7RBz2ayGhe3OrxbBk7-5FOy6I7gQSkKDC8Eig-2C-2C-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=oj6Kq-4SRjuodk73yxC5K1cDKw8XP95L_H_m3ErUuQM&e=>;).
>       Leaf identifiers are camel case (e.g., destinationAddress
>     instead of destination-address).  Are there any ongoing efforts to
>     update RFC 6728 to meet the latest best practices?
>     > Not as far as I know.
>     >
>     > Regards, Benoit
>     >
>     >
>     >   1.
>     >
>     >    Identifiers SHOULD follow a consistent naming pattern
>     throughout the
>     >    module.  Only lower-case letters, numbers, and dashes SHOULD
>     be used
>     >    in identifier names.  Upper-case characters and the underscore
>     >    character MAY be used if the identifier represents a
>     well-known value
>     >    that uses these characters.
>     >
>     >    Identifiers SHOULD include complete words and/or well-known
>     acronyms
>     >    or abbreviations.  Child nodes within a container or list
>     SHOULD NOT
>     >    replicate the parent identifier.  YANG identifiers are
>     hierarchical
>     >    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 such as "name" or
>     "id" in
>     >    data definition statements, especially if these data nodes
>     share a
>     >    common data type.
>     >
>     >    Identifiers SHOULD NOT carry any special semantics that
>     identify data
>     >    modelling properties.  Only YANG statements and YANG extension
>     >    statements are designed to convey machine readable data modelling
>     >    properties.  For example, naming an object "config" or
>     "state" does
>     >    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 machine readable format in YANG.
>     >
>     >
>     >   1.  I generated 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 from the domain name where the collector is located).
>     >
>     > @PJ: Load 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 step sequence numbers in the data
>     records would cause spurious reports of lost data. If DNS is used
>     to obtain the collector's address, arguably it should be a
>     one-time lookup rather than incurring a DNS lookup per export packet.
>     >
>     >
>     >
>     >   1.
>     >
>     >      *
>     >      *   The collector address may be learnt via other methods
>     (e.g., through DHCP options)
>     >      *   A choice statement to select what method to use seems
>     more appropriate than what is presently in RFC 6728.  For example
>     (use some shorthand)
>     >
>     > choice destination-method{
>     >                 case destination-address{
>     >                                 leaf destination-address// rw
>     with type inet:host
>     >                 }
>     >                 case dhcp-acquired-address{
>     >                                 container dcp-acquired-address{
>     >                                                 leaf
>     destination-ip-address inet-address //ro
>     >                 }
>     > }
>     >
>     >                                 However I can’t augment to
>     ietf-ipfix because destinationIPAddress is mandatory.  Can the
>     group suggest methods to (a) change the destinationIPAddress type
>     and (b) allow a choice?
>     >
>     > @PJ: The selection could also be done out of band so the
>     exporter need not know how the address is determined. eg a
>     configuration system could determine the address by any of these
>     methods or otherwise, and impose that address using the current 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 supported (e.g., point to point
>     connection).  During netconf negotiations you can announce your
>     feature set (currently sctptransport is not a feature).  Is there
>     ongoing work in updating RFC 6728 to include sctptransport 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.
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > IPFIX mailing list
>     > IPFIX@ietf.org<mailto:IPFIX@ietf.org>
>     >
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipfix&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=zSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__www.ietf.org_mailman_listinfo_ipfix-26c-3DE-2C1-2CQcSaORG4ENECojkXawtykKdqqGaKdIQCAXU-5Fk7DUoimbxp4p9KhoEppQlQ1LswK1E5yY5kvIL8XYyqMbCphIEyv8aBgtyyQbbN31fnbrx9I-2C-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=cQFI-IsxLhklEI0w-JcCksB_YNvx9v06CpqsjQys0N8&e=>
>     >
>     >
>
>     > _______________________________________________
>     > IPFIX mailing list
>     > IPFIX@ietf.org
>     >
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipfix&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=zSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=
>
>
>     --
>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>     Fax:   +49 421 200 3103        
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=cC8C3QfrkIEC1Vo-QLwKrh955-evz_Tr3MYoFDTmD1A&e=>
>
>     _______________________________________________
>     IPFIX mailing list
>     IPFIX@ietf.org
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipfix&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=zSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=
>
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix