Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion
Benoit Claise <[email protected]> Mon, 15 Jan 2018 22:18:29 +0100
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============7351827771104188074== Content-Type: multipart/alternative; boundary="------------2B03182A9B4EFD4EF83D802A" Content-Language: en-US This is a multi-part message in MIME format. --------------2B03182A9B4EFD4EF83D802A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 1/15/2018 10:10 PM, Wayne Tackabury wrote: > Regarding SCTP, as of this writing, it is not and can not be=20 > mandatory.=C2=A0 Not many commercial collectors support it.=C2=A0 I've = found=20 > 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=20 > RFC[s] 510x, SCTP has not been made sufficiently stable in linux=20 > kernel and user interfaces that it could support carrier-grade flow=20 > conveyance dependencies. There are probably other nontechnical=20 > barriers to acceptance. To be sure, this is unfortunate, since SCTP=20 > still admirably meets the original design goals. > Without getting into it, where I'm aware of implementations that meed=20 > tp make use of the "messaging" benefits of SCTP over UDP, the=20 > less-than-standard path of TCP over some defacto standard port=C2=A0 ha= s=20 > been used.=C2=A0 Others may know of different implementations, but this= is=20 > based on subjective, but voluminous, input from implementations I've=20 > seen at customer sites and discussions with colleagues at different=20 > vendor enterprises.=C2=A0 Again, this is not an editorial on technical = merit. > Regards, > Wayne > > ----- Original message ----- > From: Juergen Schoenwaelder <[email protected]> > Sent by: "IPFIX" <[email protected]> > To: Andrew Feren <[email protected]> > Cc: 'Marta Seda' <[email protected]>, "Aitken, Paul" > <[email protected]>, "'[email protected]'" <[email protected]> > 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 renamin= g > 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 [[email protected]] on behalf of Gerhard Muenz > [[email protected]] > > Sent: Saturday, January 13, 2018 4:43 AM > > To: Benoit Claise; Aitken, Paul; 'Marta Seda' > > Cc: '[email protected]' > > 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=3Dhttps-3A__tools.ietf.o= rg_html_rfc7011-23section-2D10.1&d=3DDwIGaQ&c=3Djf_iaSHvJObTbx-siA1ZOg&r=3D= eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv= 6uxVZ5pB5BvoOLL3H8&s=3DqunYBh7bv5ABGGsiP6-CjGVRw8xFMTnuuwuibkkNfBE&e=3D<h= ttps://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__linkprotect.cudasvc= =2Ecom_url-3Fa-3Dhttps-3A__tools.ietf.org_html_rfc7011-2523section-2D10.1= -26c-3DE-2C1-2Cr3o6fj1SXot8TQIPgevXNx5yfL8QvlF982Ch9DX27MByjz7bAdEaF9tjDo= Dzj1XgWtTXYfN1Z9mXiFy81bK1Aq33fYFzGl5W-2D2Dh-5F-2DxePoq9GNzzaPGdYj0o-26ty= po-3D1&d=3DDwIGaQ&c=3Djf_iaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR_UtUw4W= aW__Jt3CBhpQR6Qa_kE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DM= 0CgR7V3IlBqkpQDo2Brx-bewHWnHX_a5l7YChB32BI&e=3D> > > > > 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=3Dhttps-3A__datatracker.= ietf.org_doc_draft-2Dietf-2Dnetmod-2Drfc7223bis_&d=3DDwIGaQ&c=3Djf_iaSHvJ= ObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=3DAqj94EL= pPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DDml5zgSWzeUBwS1XyKmCG-y3bWePHxpz= t3PCej4w_zw&e=3D<https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__l= inkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__datatracker.ietf.org_doc_draft= -2Dietf-2Dnetmod-2Drfc7223bis_-26c-3DE-2C1-2C990HtCyvSKBHwQOS7jpHkeSpsvC2= M7iKDlI-5FbfqIgW2gpaEOYhngASoi8LRRhuM67bRdHS2Hyi7cVHyXDuiheARWFxSpap-5Fiz= nZ68ZknJgFbizFJolgU-26typo-3D1&d=3DDwIGaQ&c=3Djf_iaSHvJObTbx-siA1ZOg&r=3D= eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv= 6uxVZ5pB5BvoOLL3H8&s=3DwhhuVEyPDEyPYoboty-rb0h_RQBoHKqNmiQoGwpLBlw&e=3D> > > The goal is to specify NMDA-compliant > (draft-ietf-netmod-revised-datastores-09<https://urldefense.proofpo= int.com/v2/url?u=3Dhttps-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__= datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drevised-2Ddatastores_-26= c-3DE-2C1-2CByKxVFeHf8k0Yb1kzzkQnQg33VfrR12Hy6dJzQTbkgStXZt3NzfCi7l981VvX= CCM3L3iwQ3FF8lz77mT4C5yuZEfVe-2D78uXEs5xDZql2y-2D-2D4iDlmOUQ-2C-26typo-3D= 1&d=3DDwIGaQ&c=3Djf_iaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR_UtUw4WaW__J= t3CBhpQR6Qa_kE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DgGNMKy= VcGZrZBCbVl5XjjnnyJnRDUxt8jU3e24fcQBU&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 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 =C2=A0on some is= sues > I have run into with respect to RFC 6728 =E2=80=9CConfiguration Dat= a Model > for the IP Flow Information Export (IPFIX) =C2=A0and Packet Samplin= g > (PSAMP) Protocols=E2=80=9D > > > > > > =C2=A0 1. =C2=A0RFC 6728 doesn=E2=80=99t meet the latest Yang Bes= t Practices > (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.= org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23section-2D4.3.1&d=3DDw= IGaQ&c=3Djf_iaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR= 6Qa_kE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DSSYo4WM-xFfyPg= rSh-cja-jQFQEucW4daULPdwg2zSI&e=3D<https://urldefense.proofpoint.com/v2/u= rl?u=3Dhttps-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__urldefense.p= roofpoint.com_v2_url-253fu-253dhttps-2D3A-5F-5Ftools.ietf.org-5Fhtml-5Fdr= aft-2D2Dietf-2D2Dnetmod-2D2Drfc6087bis-2D2D15-2D23section-2D2D4.3.1-2526d= -253dDwMD-2Dg-2526c-253dLFYZ-2Do9-5FHUMeMTSQicvjIg-2526r-253df8F8yzrqBTw6= EPtR1rbibO-5FVFIc-2DcdnjIJ9he-5Fqu7xs-2526m-253d0c5ATjuT0-2D4IlDzLYM9h-5F= RbPjCBQUv-5F6aExRL-5Ffl-2D5M-2526s-253dHhi7V6njCFNBbSsjC6sPgNfVu5DA8iQzdz= snA-5FiQBzQ-2526e-253d-26c-3DE-2C1-2C5Zsm8llhIef-5FjTZU2aAY2fj-5FKvmJs-2D= zBz2HIfVEkrhY7UwWsg3UnykcCPzCUM7b-5FL6CTmk-5FVY1-2DTo7t8aTM7RBz2ayGhe3Orx= bBk7-5FOy6I7gQSkKDC8Eig-2C-2C-26typo-3D1&d=3DDwIGaQ&c=3Djf_iaSHvJObTbx-si= A1ZOg&r=3DeSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=3DAqj94ELpPz5Bmox= xBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3Doj6Kq-4SRjuodk73yxC5K1cDKw8XP95L_H_m3ErU= uQM&e=3D>). > =C2=A0 Leaf identifiers are camel case (e.g., destinationAddress > instead of destination-address). =C2=A0Are there any ongoing effort= s to > update RFC 6728 to meet the latest best practices? > > Not as far as I know. > > > > Regards, Benoit > > > > > > =C2=A0 1. > > > > =C2=A0 =C2=A0Identifiers SHOULD follow a consistent naming patter= n > throughout the > > =C2=A0 =C2=A0module. =C2=A0Only lower-case letters, numbers, and = dashes SHOULD > be used > > =C2=A0 =C2=A0in identifier names. =C2=A0Upper-case characters and= the underscore > > =C2=A0 =C2=A0character MAY be used if the identifier represents a= > well-known value > > =C2=A0 =C2=A0that uses these characters. > > > > =C2=A0 =C2=A0Identifiers SHOULD include complete words and/or wel= l-known > acronyms > > =C2=A0 =C2=A0or abbreviations. =C2=A0Child nodes within a contain= er or list > SHOULD NOT > > =C2=A0 =C2=A0replicate the parent identifier. =C2=A0YANG identifi= ers are > hierarchical > > =C2=A0 =C2=A0and are only meant to be unique within the the set o= f sibling > nodes > > =C2=A0 =C2=A0defined in the same module namespace. > > > > =C2=A0 =C2=A0It is permissible to use common identifiers such as = "name" or > "id" in > > =C2=A0 =C2=A0data definition statements, especially if these data= nodes > share a > > =C2=A0 =C2=A0common data type. > > > > =C2=A0 =C2=A0Identifiers SHOULD NOT carry any special semantics t= hat > identify data > > =C2=A0 =C2=A0modelling properties. =C2=A0Only YANG statements and= YANG extension > > =C2=A0 =C2=A0statements are designed to convey machine readable d= ata modelling > > =C2=A0 =C2=A0properties. =C2=A0For example, naming an object "con= fig" or > "state" does > > =C2=A0 =C2=A0not change whether it is configuration data or state= data. =C2=A0Only > > =C2=A0 =C2=A0defined YANG statements or YANG extension statements= can be > used to > > =C2=A0 =C2=A0assign semantics in a machine readable format in YAN= G. > > > > > > =C2=A0 1. =C2=A0I generated the RFC 6728 yang tree (see attached)= =2E =C2=A0The > tcp and udp exporting processes support a destinationIPAddress > (line 400, 455) which is mandatory. =C2=A0The type is inet:ip-addre= ss. > > > > =C2=A0 =C2=A0 =C2=A0* =C2=A0 A collector may be doing load balanc= ing. =C2=A0Rather 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 packe= t. > > > > > > > > =C2=A0 1. > > > > =C2=A0 =C2=A0 =C2=A0* > > =C2=A0 =C2=A0 =C2=A0* =C2=A0 The collector address may be learnt = via other methods > (e.g., through DHCP options) > > =C2=A0 =C2=A0 =C2=A0* =C2=A0 A choice statement to select what me= thod to use seems > more appropriate than what is presently in RFC 6728. =C2=A0For exam= ple > (use some shorthand) > > > > choice destination-method{ > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case dest= ination-address{ > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf destination-address// = rw > with type inet:host > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case dhcp= -acquired-address{ > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container dcp-acquired-addr= ess{ > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf > destination-ip-address inet-address //ro > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } > > } > > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 However I can=E2=80=99t aug= ment to > ietf-ipfix because destinationIPAddress is mandatory. =C2=A0Can 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 mod= el. > > > > > > > > =C2=A0 1. =C2=A0RFC 6728 mandates SCTP transport. =C2=A0I underst= and the logic > behind this (IETF prefers use of SCTP). =C2=A0There are situations > where sctp is unnecessary and not supported (e.g., point to point > connection). =C2=A0During netconf negotiations you can announce you= r > feature set (currently sctptransport is not a feature). =C2=A0Is th= ere > 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 usef= ul? > > > > P. > > > > > > > > > > _______________________________________________ > > IPFIX mailing list > > [email protected]<mailto:[email protected]> > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_ipfix&d=3DDwIGaQ&c=3Djf_iaSHvJObTbx-siA1ZOg&r=3DeSiUkUZ= U9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5p= B5BvoOLL3H8&s=3DzSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=3D<https://= urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__linkprotect.cudasvc.com_ur= l-3Fa-3Dhttps-3A__www.ietf.org_mailman_listinfo_ipfix-26c-3DE-2C1-2CQcSaO= RG4ENECojkXawtykKdqqGaKdIQCAXU-5Fk7DUoimbxp4p9KhoEppQlQ1LswK1E5yY5kvIL8XY= yqMbCphIEyv8aBgtyyQbbN31fnbrx9I-2C-26typo-3D1&d=3DDwIGaQ&c=3Djf_iaSHvJObT= bx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=3DAqj94ELpPz= 5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DcQFI-IsxLhklEI0w-JcCksB_YNvx9v06Cpq= sjQys0N8&e=3D> > > > > > > > _______________________________________________ > > IPFIX mailing list > > [email protected] > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_ipfix&d=3DDwIGaQ&c=3Djf_iaSHvJObTbx-siA1ZOg&r=3DeSiUkUZ= U9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5p= B5BvoOLL3H8&s=3DzSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=3D > > > -- > Juergen Schoenwaelder =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs Uni= versity Bremen gGmbH > Phone: +49 421 200 3587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Campus Ring 1 |= 28759 Bremen | Germany > Fax: =C2=A0 +49 421 200 3103 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.jacobs-= 2Duniversity.de_&d=3DDwIGaQ&c=3Djf_iaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0= gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOL= L3H8&s=3DcC8C3QfrkIEC1Vo-QLwKrh955-evz_Tr3MYoFDTmD1A&e=3D> > > _______________________________________________ > IPFIX mailing list > [email protected] > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_ipfix&d=3DDwIGaQ&c=3Djf_iaSHvJObTbx-siA1ZOg&r=3DeSiUkUZ= U9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5p= B5BvoOLL3H8&s=3DzSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=3D > > > > > _______________________________________________ > IPFIX mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipfix --------------2B03182A9B4EFD4EF83D802A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On 1/15/2018 10:10 PM, Wayne Tackabury wrote:<br> </div> <blockquote type="cite" cite="mid:OF39D57ECE.E528A80C-ON00258216.00736598-00258216.00744614@notes.na.collabserv.com"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt"> <div dir="ltr">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.</div> </div> </blockquote> No disagreement.<br> <a class="moz-txt-link-freetext" href="http://www.claise.be/2015/06/from-netflow-to-ipfix-via-psamp-13-years-of-standardization-explained-2/">http://www.claise.be/2015/06/from-netflow-to-ipfix-via-psamp-13-years-of-standardization-explained-2/</a><br> <br> Regards, B.<br> <blockquote type="cite" cite="mid:OF39D57ECE.E528A80C-ON00258216.00736598-00258216.00744614@notes.na.collabserv.com"> <div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt"> <div dir="ltr"> </div> <div dir="ltr">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.</div> <div dir="ltr"> </div> <div dir="ltr">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.</div> <div dir="ltr"> </div> <div dir="ltr">Regards,</div> <div dir="ltr">Wayne</div> <div dir="ltr"> </div> <div dir="ltr"> </div> <blockquote data-history-content-modified="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px">----- Original message -----<br> From: Juergen Schoenwaelder <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a><br> Sent by: "IPFIX" <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a><br> To: Andrew Feren <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a><br> Cc: 'Marta Seda' <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>, "Aitken, Paul" <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>, <a class="moz-txt-link-rfc2396E" href="mailto:'[email protected]'">"'[email protected]'"</a> <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a><br> Subject: Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion<br> Date: Mon, Jan 15, 2018 1:51 PM<br> <div><font size="2" face="Default Monospace,Courier New,Courier,monospace">I fail to see why this would be the case. (But I agree that renaming<br> identifiers for the sake of renaming them is having little value.)<br> <br> /js<br> <br> On Mon, Jan 15, 2018 at 06:09:20PM +0000, Andrew Feren wrote:<br> > In particular renaming identifiers would break any implementations of RFC 7373 "Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types".<br> ><br> > -Andrew<br> ><br> > ________________________________<br> > From: IPFIX [<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>] on behalf of Gerhard Muenz [<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>]<br> > Sent: Saturday, January 13, 2018 4:43 AM<br> > To: Benoit Claise; Aitken, Paul; 'Marta Seda'<br> > Cc: '<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>'<br> > Subject: [QUAR] Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion<br> ><br> ><br> > Marta, all,<br> ><br> > A few additional thoughts regarding your questions:<br> ><br> > 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.<br> ><br> > 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.<br> ><br> > 3) SCTP is still a mandatory transport for a compliant implementation of an IPFIX device, not a feature. See: <a href="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=" target="_blank" moz-do-not-send="true">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=</a><<a href="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=" target="_blank" moz-do-not-send="true">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=</a>><br> ><br> > Best regards,<br> > Gerhard<br> ><br> ><br> ><br> > On 10.01.2018 08:33, Benoit Claise wrote:<br> > Hi,<br> > Marta, Benoit,<br> ><br> > 1. Are there efforts to update other RFCs to meet the latest YANG best practices?<br> > Yes. Ex: <a href="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=" target="_blank" moz-do-not-send="true">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=</a><<a href="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=" target="_blank" moz-do-not-send="true">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=</a>><br> > The goal is to specify NMDA-compliant (draft-ietf-netmod-revised-datastores-09<<a href="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=" target="_blank" moz-do-not-send="true">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=</a>>) YANG modules<br> ><br> > 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?<br> > This type of feedback should come from implementation experience.<br> ><br> > Regards, Benoit<br> > Note that it's > 5 years old.<br> ><br> > Also see @PJ inline:<br> ><br> ><br> > On 09/01/2018 16:01, Benoit Claise wrote:<br> > Hi Marta,<br> > Hello,<br> > 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”<br> ><br> ><br> > 1. RFC 6728 doesn’t meet the latest Yang Best Practices (<a href="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=" target="_blank" moz-do-not-send="true">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=</a><<a href="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=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5B voOLL3H8&s=oj6Kq-4SRjuodk73yxC5K1cDKw8XP95L_H_m3ErUuQM&e=" target="_blank" moz-do-not-send="true">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__Jt3CBhpQ R6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=oj6Kq-4SRjuodk73yxC5K1cDKw8XP95L_H_m3ErUuQM&e=</a>>). 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?<br> > Not as far as I know.<br> ><br> > Regards, Benoit<br> ><br> ><br> > 1.<br> ><br> > Identifiers SHOULD follow a consistent naming pattern throughout the<br> > module. Only lower-case letters, numbers, and dashes SHOULD be used<br> > in identifier names. Upper-case characters and the underscore<br> > character MAY be used if the identifier represents a well-known value<br> > that uses these characters.<br> ><br> > Identifiers SHOULD include complete words and/or well-known acronyms<br> > or abbreviations. Child nodes within a container or list SHOULD NOT<br> > replicate the parent identifier. YANG identifiers are hierarchical<br> > and are only meant to be unique within the the set of sibling nodes<br> > defined in the same module namespace.<br> ><br> > It is permissible to use common identifiers such as "name" or "id" in<br> > data definition statements, especially if these data nodes share a<br> > common data type.<br> ><br> > Identifiers SHOULD NOT carry any special semantics that identify data<br> > modelling properties. Only YANG statements and YANG extension<br> > statements are designed to convey machine readable data modelling<br> > properties. For example, naming an object "config" or "state" does<br> > not change whether it is configuration data or state data. Only<br> > defined YANG statements or YANG extension statements can be used to<br> > assign semantics in a machine readable format in YANG.<br> ><br> ><br> > 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.<br> ><br> > * 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).<br> ><br> > @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.<br> ><br> ><br> ><br> > 1.<br> ><br> > *<br> > * The collector address may be learnt via other methods (e.g., through DHCP options)<br> > * A choice statement to select what method to use seems more appropriate than what is presently in RFC 6728. For example (use some shorthand)<br> ><br> > choice destination-method{<br> > case destination-address{<br> > leaf destination-address// rw with type inet:host<br> > }<br> > case dhcp-acquired-address{<br> > container dcp-acquired-address{<br> > leaf destination-ip-address inet-address //ro<br> > }<br> > }<br> ><br> > 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?<br> ><br> > @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.<br> ><br> ><br> ><br> > 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)?<br> ><br> > @PJ Same answer as point (2) above, ie is this necessary and useful?<br> ><br> > P.<br> ><br> ><br> ><br> ><br> > _______________________________________________<br> > IPFIX mailing list<br> > <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a><<a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">mailto:[email protected]</a>><br> > <a href="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=" target="_blank" moz-do-not-send="true">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=</a><<a href="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=" target="_blank" moz-do-not-send="true">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=</a>><br> ><br> ><br> <br> > _______________________________________________<br> > IPFIX mailing list<br> > <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a><br> > <a href="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=" target="_blank" moz-do-not-send="true">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=</a><br> <br> <br> --<br> Juergen Schoenwaelder Jacobs University Bremen gGmbH<br> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany<br> Fax: +49 421 200 3103 <<a href="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=" target="_blank" moz-do-not-send="true">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=</a>><br> <br> _______________________________________________<br> IPFIX mailing list<br> <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a><br> <a href="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=" target="_blank" moz-do-not-send="true">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=</a></font><br> </div> </blockquote> <div dir="ltr"> </div> </div> <br> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ IPFIX mailing list <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/ipfix">https://www.ietf.org/mailman/listinfo/ipfix</a> </pre> </blockquote> <br> </body> </html> --------------2B03182A9B4EFD4EF83D802A-- --===============7351827771104188074== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipfix --===============7351827771104188074==--