From nobody Fri Dec 12 12:06:08 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFD11A1B8B for ; Fri, 12 Dec 2014 12:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 WFLK9K98QNTM for ; Fri, 12 Dec 2014 12:06:05 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 6BA4C1A8716 for ; Fri, 12 Dec 2014 12:06:04 -0800 (PST) Received: from mbp.local (162-228-221-189.lightspeed.sntcca.sbcglobal.net [162.228.221.189]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id sBCK5x7l059108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 12 Dec 2014 20:05:59 GMT (envelope-from joelja@bogus.com) Message-ID: <548B4AA0.4000905@bogus.com> Date: Fri, 12 Dec 2014 12:05:52 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: IPFIX Working Group References: <5435D840.1090108@bogus.com> <5487A31D.5040304@bogus.com> In-Reply-To: <5487A31D.5040304@bogus.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DxukSXGXQT9NQdI0fixBJPgLM5IG0bjtC" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/q4rL5IydUsz11Zk9Vfj7a2fDLNs Cc: "ipfix-chairs@tools.ietf.org" Subject: [IPFIX] Winding down the ipfix working group. X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 20:06:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DxukSXGXQT9NQdI0fixBJPgLM5IG0bjtC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Greetings, The chairs and my co-AD and I have decided it's time to window down the ipfix working group. Our major milestones are completed and we should be pleased with the results. We have one remaining active document draft-ietf-ipfix-mib-variable-export which I will be happy to AD sponsor. Barring significant commentary to contrary I will close the working-group on friday december 19th and we will retain the mailing list for some time after that. Thanks and congratulations. Joel --DxukSXGXQT9NQdI0fixBJPgLM5IG0bjtC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlSLSqAACgkQ8AA1q7Z/VrLmogCdHiefFrFwVLu5XGUy4xj9mLcC go0AoIKFHr0SynHP8pVbA5DPwPU27i6n =7qiq -----END PGP SIGNATURE----- --DxukSXGXQT9NQdI0fixBJPgLM5IG0bjtC-- From nobody Fri Dec 12 15:13:33 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18B01A0075 for ; Fri, 12 Dec 2014 15:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 oyBDAnWuHyX7 for ; Fri, 12 Dec 2014 15:13:30 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC301A000D for ; Fri, 12 Dec 2014 15:13:30 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id sBCMgjD9007377; Fri, 12 Dec 2014 15:13:27 -0800 Received: from brmwp-exchub02.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 1r89cur255-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Dec 2014 15:13:27 -0800 Received: from brm-excashub-2.corp.brocade.com (172.16.187.74) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 12 Dec 2014 16:13:26 -0700 Received: from EMEAWP-CASH02.corp.brocade.com (172.29.19.10) by brm-excashub-2.corp.brocade.com (172.16.187.74) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 12 Dec 2014 16:13:25 -0700 Received: from EMEA-EXCH01.corp.brocade.com ([fe80::18c9:7b21:74fd:7e48]) by EMEAWP-CASH02.corp.brocade.com ([fe80::548c:8759:5d5e:1c0b%12]) with mapi; Sat, 13 Dec 2014 00:13:24 +0100 From: Paul Aitken To: "ipfix@ietf.org" Date: Sat, 13 Dec 2014 00:13:20 +0100 Thread-Topic: [IPFIX] Winding down the ipfix working group. Thread-Index: AdAWWeL/eX1X3uoyTfOwPh/kzqqfbAAAp/tg Message-ID: <23B7BE54EACBED43957AB709C564F7B701853E1EC5@EMEA-EXCH01.corp.brocade.com> References: <5435D840.1090108@bogus.com> <5487A31D.5040304@bogus.com> <548B4AA0.4000905@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_23B7BE54EACBED43957AB709C564F7B701853E1EC5EMEAEXCH01cor_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-12_07:2014-12-12,2014-12-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412120205 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/XGRtd3ER75NF3p4uRnHMv09aJuU Cc: "joelja@gmail.com" , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] Winding down the ipfix working group. X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 23:13:32 -0000 --_000_23B7BE54EACBED43957AB709C564F7B701853E1EC5EMEAEXCH01cor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm9lbCwgQWxsLA0KDQpJ4oCZbSB3YWl0aW5nIGZvciBXRyByZXZpZXcgb2YgZHJhZnQtaWV0Zi1p cGZpeC1taWItdmFyaWFibGUtZXhwb3J0LTA3DQotcHJpbmNpcGFsbHkgZnJvbSBCcmlhbiBUcmFt bWVsbCBhbmQgSnVlcmdlbiBTY2hvZW53YWVsZGVyLg0KDQpQLg0KDQoNCkZyb206IGpvZWwgamFl Z2dsaSA8am9lbGphQGJvZ3VzLmNvbTxtYWlsdG86am9lbGphQGJvZ3VzLmNvbT4+DQpEYXRlOiAx MiBEZWNlbWJlciAyMDE0IGF0IDIwOjA1DQpTdWJqZWN0OiBbSVBGSVhdIFdpbmRpbmcgZG93biB0 aGUgaXBmaXggd29ya2luZyBncm91cC4NClRvOiBJUEZJWCBXb3JraW5nIEdyb3VwIDxpcGZpeEBp ZXRmLm9yZzxtYWlsdG86aXBmaXhAaWV0Zi5vcmc+Pg0KQ2M6ICJpcGZpeC1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc8bWFpbHRvOmlwZml4LWNoYWlyc0B0b29scy5pZXRmLm9yZz4iIDxpcGZpeC1jaGFp cnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmlwZml4LWNoYWlyc0B0b29scy5pZXRmLm9yZz4+DQoN Cg0KDQpHcmVldGluZ3MsDQoNClRoZSBjaGFpcnMgYW5kIG15IGNvLUFEIGFuZCBJIGhhdmUgZGVj aWRlZCBpdCdzIHRpbWUgdG8gd2luZG93IGRvd24gdGhlDQppcGZpeCB3b3JraW5nIGdyb3VwLiBP dXIgbWFqb3IgbWlsZXN0b25lcyBhcmUgY29tcGxldGVkIGFuZCB3ZSBzaG91bGQgYmUNCnBsZWFz ZWQgd2l0aCB0aGUgcmVzdWx0cy4NCg0KV2UgaGF2ZSBvbmUgcmVtYWluaW5nIGFjdGl2ZSBkb2N1 bWVudA0KDQpkcmFmdC1pZXRmLWlwZml4LW1pYi12YXJpYWJsZS1leHBvcnQNCg0Kd2hpY2ggSSB3 aWxsIGJlIGhhcHB5IHRvIEFEIHNwb25zb3IuIEJhcnJpbmcgc2lnbmlmaWNhbnQgY29tbWVudGFy eSB0bw0KY29udHJhcnkgSSB3aWxsIGNsb3NlIHRoZSB3b3JraW5nLWdyb3VwIG9uIGZyaWRheSBk ZWNlbWJlciAxOXRoIGFuZCB3ZQ0Kd2lsbCByZXRhaW4gdGhlIG1haWxpbmcgbGlzdCBmb3Igc29t ZSB0aW1lIGFmdGVyIHRoYXQuDQoNClRoYW5rcyBhbmQgY29uZ3JhdHVsYXRpb25zLg0KSm9lbA0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJUEZJ WCBtYWlsaW5nIGxpc3QNCklQRklYQGlldGYub3JnPG1haWx0bzpJUEZJWEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBmaXgNCg0K --_000_23B7BE54EACBED43957AB709C564F7B701853E1EC5EMEAEXCH01cor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNs YXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5Kb2VsLCBBbGwsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5J4oCZbSB3YWl0aW5nIGZvciBXRyByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1pcGZpeC1taWItdmFyaWFibGUtZXhwb3J0LTA3PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiAtcHJp bmNpcGFsbHkgZnJvbSBCcmlhbiBUcmFtbWVsbCBhbmQgSnVlcmdlbiBTY2hvZW53YWVsZGVyLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+UC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+RnJvbTogPGI+am9lbCBqYWVn Z2xpPC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvZWxqYUBib2d1cy5jb20iPmpvZWxqYUBib2d1 cy5jb208L2E+Jmd0Ozxicj5EYXRlOiAxMiBEZWNlbWJlciAyMDE0IGF0IDIwOjA1PGJyPlN1Ympl Y3Q6IFtJUEZJWF0gV2luZGluZyBkb3duIHRoZSBpcGZpeCB3b3JraW5nIGdyb3VwLjxicj5Ubzog SVBGSVggV29ya2luZyBHcm91cCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlwZml4QGlldGYub3JnIj5p cGZpeEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPkNjOiAmcXVvdDs8YSBocmVmPSJtYWlsdG86aXBmaXgt Y2hhaXJzQHRvb2xzLmlldGYub3JnIj5pcGZpeC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aXBmaXgtY2hhaXJzQHRvb2xzLmlldGYub3JnIj5pcGZp eC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj48YnI+PGJyPjxicj5HcmVldGluZ3Ms PGJyPjxicj5UaGUgY2hhaXJzIGFuZCBteSBjby1BRCBhbmQgSSBoYXZlIGRlY2lkZWQgaXQncyB0 aW1lIHRvIHdpbmRvdyBkb3duIHRoZTxicj5pcGZpeCB3b3JraW5nIGdyb3VwLiBPdXIgbWFqb3Ig bWlsZXN0b25lcyBhcmUgY29tcGxldGVkIGFuZCB3ZSBzaG91bGQgYmU8YnI+cGxlYXNlZCB3aXRo IHRoZSByZXN1bHRzLjxicj48YnI+V2UgaGF2ZSBvbmUgcmVtYWluaW5nIGFjdGl2ZSBkb2N1bWVu dDxicj48YnI+ZHJhZnQtaWV0Zi1pcGZpeC1taWItdmFyaWFibGUtZXhwb3J0PGJyPjxicj53aGlj aCBJIHdpbGwgYmUgaGFwcHkgdG8gQUQgc3BvbnNvci4gQmFycmluZyBzaWduaWZpY2FudCBjb21t ZW50YXJ5IHRvPGJyPmNvbnRyYXJ5IEkgd2lsbCBjbG9zZSB0aGUgd29ya2luZy1ncm91cCBvbiBm cmlkYXkgZGVjZW1iZXIgMTl0aCBhbmQgd2U8YnI+d2lsbCByZXRhaW4gdGhlIG1haWxpbmcgbGlz dCBmb3Igc29tZSB0aW1lIGFmdGVyIHRoYXQuPGJyPjxicj5UaGFua3MgYW5kIGNvbmdyYXR1bGF0 aW9ucy48YnI+PHNwYW4gY2xhc3M9aG9lbnpiPjxzcGFuIHN0eWxlPSdjb2xvcjojODg4ODg4Jz5K b2VsPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6Izg4ODg4OCc+PGJyPjxicj48L3Nw YW4+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy PklQRklYIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86SVBGSVhAaWV0Zi5vcmciPklQ RklYQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwZml4IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcGZpeDwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_23B7BE54EACBED43957AB709C564F7B701853E1EC5EMEAEXCH01cor_-- From nobody Fri Dec 12 15:16:16 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9C71A0032 for ; Fri, 12 Dec 2014 15:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 UPUyNQ2Jbl3B for ; Fri, 12 Dec 2014 15:16:13 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6811A0025 for ; Fri, 12 Dec 2014 15:16:12 -0800 (PST) Received: from pps.filterd (m0048192 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id sBCMSARA021480; Fri, 12 Dec 2014 15:16:12 -0800 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1r7wm6sqst-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Dec 2014 15:16:11 -0800 Received: from BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) by HQ1WP-EXCHUB02.corp.brocade.com (10.70.38.101) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 12 Dec 2014 15:16:10 -0800 Received: from EMEAWP-CASH02.corp.brocade.com (172.29.19.10) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 12 Dec 2014 16:16:10 -0700 Received: from EMEA-EXCH01.corp.brocade.com ([fe80::18c9:7b21:74fd:7e48]) by EMEAWP-CASH02.corp.brocade.com ([fe80::548c:8759:5d5e:1c0b%12]) with mapi; Sat, 13 Dec 2014 00:16:08 +0100 From: Paul Aitken To: "rocco@plixer.com" Date: Sat, 13 Dec 2014 00:16:06 +0100 Thread-Topic: draft-ietf-ipfix-mib-variable-export-06 Thread-Index: AdAWX7KqCVQzQzoSRqq9E5UFd+xmrQ== Message-ID: <23B7BE54EACBED43957AB709C564F7B701853E1EC6@EMEA-EXCH01.corp.brocade.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_23B7BE54EACBED43957AB709C564F7B701853E1EC6EMEAEXCH01cor_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-12_07:2014-12-12,2014-12-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412120207 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/TtxFLRHsCKX__UiX6hrt8t6ooFU Cc: "ipfix@ietf.org" Subject: [IPFIX] draft-ietf-ipfix-mib-variable-export-06 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 23:16:15 -0000 --_000_23B7BE54EACBED43957AB709C564F7B701853E1EC6EMEAEXCH01cor_ Content-Type: text/plain; charset="us-ascii" Rocco, Thanks for the feedback. What change, if any, would you like to see in the draft? Thanks, P. > On Oct 27, 2014, at 08:07, Brian Trammell wrote: > > > On 26 Oct 2014, at 16:50, Paul Aitken wrote: > >> Collectors should understand the equivalence and map the IPFIX IE and the MIB object to the same internal entity, so there should be no difficultly in comparing or combining data. > > ...but it strikes me as a little unkind to publish this document as a "you can do this, collectors will handle the mess" without at least an appendix linking IEs in the present IANA registry to commonly-used MIB objects. But I'll step back and let people who write collectors for customers other than themselves comment on this statement. Collector processes are under constant pressure to scale higher. As described here, the mapping seems to centralize a burden that could remain distributed. It also seems that exporters can statically map the data they're configured to export, while collectors developed for heterogeneous enterprise-scale environments must dynamically be capable of handling everything the protocol can provide. -- Rocco Caputo --_000_23B7BE54EACBED43957AB709C564F7B701853E1EC6EMEAEXCH01cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Rocco,

 

Thanks = for the feedback.

 

<= p class=3DMsoNormal>What change, if any, would you like to see in the draft= ?

 

Thanks,

P.

 

 

> On Oct 27, 2014, at 08:07, Brian Trammell <ietf = at trammell.ch> wrote:

>

>

> On= 26 Oct 2014, at 16:50, Paul Aitken <paitken at cisco.com> wrote:

>

&g= t;> Collectors should understand the equivalence and map the IPFIX IE an= d the MIB object to the same internal entity, so there should be no difficu= ltly in comparing or combining data.

>= ;

> ...but it strikes me as a little= unkind to publish this document as a "you can do this, collectors wil= l handle the mess" without at least an appendix linking IEs in the pre= sent IANA registry to commonly-used MIB objects. But I'll step back and let= people who write collectors for customers other than themselves comment on= this statement.

 

Collector processes are under constant pressure to scale= higher.  As described here, the mapping seems to centralize a burden = that could remain distributed.  It also seems that exporters can stati= cally map the data they're configured to export, while collectors developed= for heterogeneous enterprise-scale environments must dynamically be capabl= e of handling everything the protocol can provide.

 

--

Rocco Caputo <rocco at plixer.com>

<= /div>= --_000_23B7BE54EACBED43957AB709C564F7B701853E1EC6EMEAEXCH01cor_-- From nobody Sat Dec 13 13:32:17 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA9C1A1A11 for ; Sat, 13 Dec 2014 13:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 6PSJr-VZLkft for ; Sat, 13 Dec 2014 13:32:13 -0800 (PST) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id CC2D21A1A0C for ; Sat, 13 Dec 2014 13:32:11 -0800 (PST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) by trammell.ch (Postfix) with ESMTPSA id D81F31A006A; Sat, 13 Dec 2014 22:32:08 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_420EF801-6962-4FCB-8B9B-797A0480442F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Trammell In-Reply-To: <23B7BE54EACBED43957AB709C564F7B701853E1EC5@EMEA-EXCH01.corp.brocade.com> Date: Sat, 13 Dec 2014 22:32:07 +0100 Message-Id: References: <5435D840.1090108@bogus.com> <5487A31D.5040304@bogus.com> <548B4AA0.4000905@bogus.com> <23B7BE54EACBED43957AB709C564F7B701853E1EC5@EMEA-EXCH01.corp.brocade.com> To: Paul Aitken X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/nQb3hK7g0UaWMDEFqpsVrcDC0Gg Cc: "joelja@gmail.com" , "ipfix@ietf.org" , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] Winding down the ipfix working group. X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 21:32:15 -0000 --Apple-Mail=_420EF801-6962-4FCB-8B9B-797A0480442F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 hi Paul, all, AFAIC, I sent in my review on 15 August 2014, edits were made 26 Oct, I = followed up 27 Oct. The *document* is basically good to go, I see that = there are a couple of outstanding questions from Paul's 30 Oct message; = sorry for missing these... >>>> What the mechanism in the document should _not_ be used for is to = expand the IPFIX information model to also include the contents of all = the various MIBs, such that SMI IEs could be used alongside IPFIX IEs to = export information from non-SNMP sources of data. Otherwise we've = created Yet Another Representation for lots of common IEs already in the = IPFIX IE registry, which would significantly complicate the comparison = and combination of data at collectors. The document needs to make this = explicit, either in section 1 or 2. >>> The mechanism _can_ be used like that. >> Can be, yes. Is it the express intention of the authors of the draft = to do so? >=20 > Authors aside, what does the WG want? Ultimately the goal is to avoid = creating new IPFIX IEs for each MIB that needs exported. Does that = require considering MIBs as part of the info model? So I've thought about this a bit and I *think* we agree here: this = mechanism exists so that things which are already in MIBs can be = exported via IPFIX without having to define new IEs. Personally, I'd be happy if we didn't start deprecating things already = in the native registry in favor of things in MIBs, and if the IE Doctors = don't tell someone who wants an IE that they can't have it because it's = in MIB X. I don't believe it's necessary to write any of that down = though. >>> Expressed another way, we've already created duplication; now we = have to live with it. >> Actually this seems to be closer to "we've already created = duplication, so we can happily create more," which seems dangerous for = sustainable interop. >=20 > What change, if any, would you like to see in the draft? As long as it's clear that the mechanism is intended to glue MIBs to = IPFIX, none. Cheers, Brian On 13 Dec 2014, at 00:13, Paul Aitken wrote: > Joel, All, > =20 > I=92m waiting for WG review of draft-ietf-ipfix-mib-variable-export-07 > -principally from Brian Trammell and Juergen Schoenwaelder. > =20 > P. > =20 > =20 > From: joel jaeggli > Date: 12 December 2014 at 20:05 > Subject: [IPFIX] Winding down the ipfix working group. > To: IPFIX Working Group > Cc: "ipfix-chairs@tools.ietf.org" >=20 >=20 >=20 > Greetings, >=20 > The chairs and my co-AD and I have decided it's time to window down = the > ipfix working group. Our major milestones are completed and we should = be > pleased with the results. >=20 > We have one remaining active document >=20 > draft-ietf-ipfix-mib-variable-export >=20 > which I will be happy to AD sponsor. Barring significant commentary to > contrary I will close the working-group on friday december 19th and we > will retain the mailing list for some time after that. >=20 > Thanks and congratulations. > Joel >=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix >=20 > =20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --Apple-Mail=_420EF801-6962-4FCB-8B9B-797A0480442F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUjLBXAAoJENt3nsOmbNJcE/8IAIUGX0lNQOhSzSIr257gO5BR NuKDAQS8b85bIDfiAD9yr3GQ9uRLsVQt9/U4ZO/j7eysKcyDw6SBTLoBPQov4KlH plTjzgySwy1glfgnGF3Zx9kurQDdbIrC4K5hX+hPEgDdi9kVSiv8B3ieco5teqIo Gdh83YbSBSJTc1cRW5Ao/OwUa7kuUnwUyKC5vkSirezfYEa4VNnU08zE+9c16708 8a/dKX5LbQm6FKLA52xuiRnWwDvMzZYA2vPEEWJMZaaWDf40pnCr6Z+vm8YBHWy5 HOd/lDrJnZ0BsfGI19u5GmJaAhEPyfrQ7orpbclzlfCwReVkeD1vZl4Q/iwLCik= =a2xJ -----END PGP SIGNATURE----- --Apple-Mail=_420EF801-6962-4FCB-8B9B-797A0480442F-- From nobody Sun Dec 14 00:46:47 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1921A6F15 for ; Sun, 14 Dec 2014 00:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4mdmkkY8JOi3 for ; Sun, 14 Dec 2014 00:46:45 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178421A6F12 for ; Sun, 14 Dec 2014 00:46:44 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUHAGFNjVTGmAcV/2dsb2JhbABagmQigSoEgwKwCAEBAQEBAQaYMAIcdBYBAQEBAQF8hAwBAQEBAxIREToLDAQCAQgNBAQBAQMCBh0DAgICMBQBCAgCBAENBQgaiAoBsDiKSJVOAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhhF+JQRYbBwaCYi6BEwWOAo5+iygig2xugUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,574,1413259200"; d="scan'208";a="96340381" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Dec 2014 03:46:43 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 14 Dec 2014 03:46:43 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Sun, 14 Dec 2014 09:46:42 +0100 From: "Romascanu, Dan (Dan)" To: joel jaeggli , IPFIX Working Group Thread-Topic: [IPFIX] Winding down the ipfix working group. Thread-Index: AQHQFkcU2czS9gEZS0K6ksynGSDcs5yOyBrQ Date: Sun, 14 Dec 2014 08:46:41 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C92F0DE@AZ-FFEXMB04.global.avaya.com> References: <5435D840.1090108@bogus.com> <5487A31D.5040304@bogus.com> <548B4AA0.4000905@bogus.com> In-Reply-To: <548B4AA0.4000905@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/KBoU_6HXPXKaYqkSf0ioXivX0wA Cc: "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] Winding down the ipfix working group. X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 08:46:46 -0000 VGhpcyBXRyBoYXMgZG9uZSBhbiBhbWF6aW5nIGpvYi4gDQoNCkNvbmdyYXR1bGF0aW9ucyBhbmQg dGhhbmtzIHRvIGFsbCB0aGUgcGFydGljaXBhbnRzIGR1cmluZyB0aGUgeWVhcnMuIA0KDQpSZWdh cmRzLA0KDQpEYW4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElQ RklYIFttYWlsdG86aXBmaXgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGpvZWwgamFl Z2dsaQ0KPiBTZW50OiBGcmlkYXksIERlY2VtYmVyIDEyLCAyMDE0IDEwOjA2IFBNDQo+IFRvOiBJ UEZJWCBXb3JraW5nIEdyb3VwDQo+IENjOiBpcGZpeC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4g U3ViamVjdDogW0lQRklYXSBXaW5kaW5nIGRvd24gdGhlIGlwZml4IHdvcmtpbmcgZ3JvdXAuDQo+ IA0KPiANCj4gR3JlZXRpbmdzLA0KPiANCj4gVGhlIGNoYWlycyBhbmQgbXkgY28tQUQgYW5kIEkg aGF2ZSBkZWNpZGVkIGl0J3MgdGltZSB0byB3aW5kb3cgZG93biB0aGUNCj4gaXBmaXggd29ya2lu ZyBncm91cC4gT3VyIG1ham9yIG1pbGVzdG9uZXMgYXJlIGNvbXBsZXRlZCBhbmQgd2Ugc2hvdWxk IGJlDQo+IHBsZWFzZWQgd2l0aCB0aGUgcmVzdWx0cy4NCj4gDQo+IFdlIGhhdmUgb25lIHJlbWFp bmluZyBhY3RpdmUgZG9jdW1lbnQNCj4gDQo+IGRyYWZ0LWlldGYtaXBmaXgtbWliLXZhcmlhYmxl LWV4cG9ydA0KPiANCj4gd2hpY2ggSSB3aWxsIGJlIGhhcHB5IHRvIEFEIHNwb25zb3IuIEJhcnJp bmcgc2lnbmlmaWNhbnQgY29tbWVudGFyeSB0bw0KPiBjb250cmFyeSBJIHdpbGwgY2xvc2UgdGhl IHdvcmtpbmctZ3JvdXAgb24gZnJpZGF5IGRlY2VtYmVyIDE5dGggYW5kIHdlIHdpbGwNCj4gcmV0 YWluIHRoZSBtYWlsaW5nIGxpc3QgZm9yIHNvbWUgdGltZSBhZnRlciB0aGF0Lg0KPiANCj4gVGhh bmtzIGFuZCBjb25ncmF0dWxhdGlvbnMuDQo+IEpvZWwNCg0K From nobody Mon Dec 15 03:22:41 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D201A1B16 for ; Mon, 15 Dec 2014 03:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 g5ALRMNBfE7v for ; Mon, 15 Dec 2014 03:22:36 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A288C1A1B1A for ; Mon, 15 Dec 2014 03:22:36 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id sBFAaEve029715; Mon, 15 Dec 2014 03:22:34 -0800 Received: from brmwp-exchub02.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 1r85tn4tcr-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Dec 2014 03:22:34 -0800 Received: from BRMWP-EXMB12.corp.brocade.com (172.16.59.130) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 15 Dec 2014 04:22:33 -0700 Received: from EMEAWP-CASH01.corp.brocade.com (172.29.18.10) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 15 Dec 2014 04:22:32 -0700 Received: from EMEA-EXCH01.corp.brocade.com ([fe80::18c9:7b21:74fd:7e48]) by EMEAWP-CASH01.corp.brocade.com ([::1]) with mapi; Mon, 15 Dec 2014 12:22:31 +0100 From: Paul Aitken To: Brian Trammell Date: Mon, 15 Dec 2014 12:22:29 +0100 Thread-Topic: [IPFIX] Winding down the ipfix working group. Thread-Index: AdAXHEKwRRNEnIV0TIy+wahbqK8JBQBNGiig Message-ID: <23B7BE54EACBED43957AB709C564F7B701853E214C@EMEA-EXCH01.corp.brocade.com> References: <5435D840.1090108@bogus.com> <5487A31D.5040304@bogus.com> <548B4AA0.4000905@bogus.com> <23B7BE54EACBED43957AB709C564F7B701853E1EC5@EMEA-EXCH01.corp.brocade.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-15_01:2014-12-13,2014-12-14,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412150107 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/TTVbveXgdRPdX4Mqp1TXN_ZEHEI Cc: "joelja@gmail.com" , "ipfix@ietf.org" , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] Winding down the ipfix working group. X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 11:22:39 -0000 Brian, please see inline... Thanks, P. > -----Original Message----- > From: Brian Trammell [mailto:ietf@trammell.ch] > Sent: 13 December 2014 21:32 > To: Paul Aitken > Cc: ipfix@ietf.org; joelja@gmail.com; ipfix-chairs@tools.ietf.org > Subject: Re: [IPFIX] Winding down the ipfix working group. > > hi Paul, all, > > AFAIC, I sent in my review on 15 August 2014, edits were made 26 Oct, I > followed up 27 Oct. The *document* is basically good to go, I see that there are > a couple of outstanding questions from Paul's 30 Oct message; sorry for missing > these... > >>>>> What the mechanism in the document should _not_ be used for is to >>>>> expand the IPFIX information model to also include the contents of all the >>>>> various MIBs, such that SMI IEs could be used alongside IPFIX IEs to export >>>>> information from non-SNMP sources of data. Otherwise we've created Yet >>>>> Another Representation for lots of common IEs already in the IPFIX IE registry, >>>>> which would significantly complicate the comparison and combination of data >>>>> at collectors. The document needs to make this explicit, either in section 1 or 2. >>>> The mechanism _can_ be used like that. >>> Can be, yes. Is it the express intention of the authors of the draft to do so? >> >> Authors aside, what does the WG want? Ultimately the goal is to avoid >> creating new IPFIX IEs for each MIB that needs exported. Does that require >> considering MIBs as part of the info model? > > So I've thought about this a bit and I *think* we agree here: this mechanism > exists so that things which are already in MIBs can be exported via IPFIX without > having to define new IEs. Exactly. > Personally, I'd be happy if we didn't start deprecating things already in the native > registry in favor of things in MIBs, Agreed; this document does not deprecate any existing IEs. - which means there are now two ways of exporting some things (as IE and as MIB). Collectors should already have architectures which understand this equivalence (effectively a presentation layer) since there are already some equivalent (duplicate) IEs (Andrew Feren had a list), and the list will surely grow as enterprise-specific IEs are transitioned to IANA. So I consider this to be a pre-existing issue which was not introduced by this document. Therefore I don't see a need to document the existing IE / MIB equivalences in the document. Please shout if you disagree. > and if the IE Doctors don't tell someone who > wants an IE that they can't have it because it's in MIB X. I think it'll be on a case-by-case basis. Hopefully they'll encourage the use of MIB export. However if the use case involves exporting lots of other IEs and no other MIBs, then a new IE would seem justified for simplicity. Remember that the point of the draft is to avoid overloading the IANA registry with new IEs which are equivalent to existing MIBs. > I don't believe it's necessary to write any of that down though. +1 > >>> Expressed another way, we've already created duplication; now we have to live with it. > >> Actually this seems to be closer to "we've already created duplication, so we can happily create more," which seems dangerous for sustainable interop. > > > > What change, if any, would you like to see in the draft? > > > As long as it's clear that the mechanism is intended to glue MIBs to IPFIX, none. Great, thanks! P. > > Cheers, > > Brian > > On 13 Dec 2014, at 00:13, Paul Aitken wrote: > > > Joel, All, > > > > I'm waiting for WG review of draft-ietf-ipfix-mib-variable-export-07 > > -principally from Brian Trammell and Juergen Schoenwaelder. > > > > P. > > > > > > From: joel jaeggli > > Date: 12 December 2014 at 20:05 > > Subject: [IPFIX] Winding down the ipfix working group. > > To: IPFIX Working Group > > Cc: "ipfix-chairs@tools.ietf.org" > > > > > > > > Greetings, > > > > The chairs and my co-AD and I have decided it's time to window down > > the ipfix working group. Our major milestones are completed and we > > should be pleased with the results. > > > > We have one remaining active document > > > > draft-ietf-ipfix-mib-variable-export > > > > which I will be happy to AD sponsor. Barring significant commentary to > > contrary I will close the working-group on friday december 19th and we > > will retain the mailing list for some time after that. > > > > Thanks and congratulations. > > Joel > > > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix > > > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix From nobody Mon Dec 15 03:28:10 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6969A1A1AEC for ; Mon, 15 Dec 2014 03:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 c9wD4rMCJSDc for ; Mon, 15 Dec 2014 03:28:05 -0800 (PST) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6D34D1A1AC1 for ; Mon, 15 Dec 2014 03:28:05 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::108d] (unknown [IPv6:2001:67c:10ec:2a49:8000::108d]) by trammell.ch (Postfix) with ESMTPSA id DC2661A0272; Mon, 15 Dec 2014 12:27:33 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Brian Trammell In-Reply-To: <23B7BE54EACBED43957AB709C564F7B701853E214C@EMEA-EXCH01.corp.brocade.com> Date: Mon, 15 Dec 2014 12:27:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5435D840.1090108@bogus.com> <5487A31D.5040304@bogus.com> <548B4AA0.4000905@bogus.com> <23B7BE54EACBED43957AB709C564F7B701853E1EC5@EMEA-EXCH01.corp.brocade.com> <23B7BE54EACBED43957AB709C564F7B701853E214C@EMEA-EXCH01.corp.brocade.com> To: Paul Aitken X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/E65_EMtsDAHkY7UtZbrZQaZufbY Cc: "joelja@gmail.com" , "ipfix@ietf.org" , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] Winding down the ipfix working group. X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 11:28:08 -0000 > On 15 Dec 2014, at 12:22, Paul Aitken wrote: >=20 > Brian, please see inline... >=20 > Thanks, > P. >=20 >=20 >> -----Original Message----- >> From: Brian Trammell [mailto:ietf@trammell.ch] >> Sent: 13 December 2014 21:32 >> To: Paul Aitken >> Cc: ipfix@ietf.org; joelja@gmail.com; ipfix-chairs@tools.ietf.org >> Subject: Re: [IPFIX] Winding down the ipfix working group. >>=20 >> hi Paul, all, >>=20 >> AFAIC, I sent in my review on 15 August 2014, edits were made 26 Oct, = I >> followed up 27 Oct. The *document* is basically good to go, I see = that there are >> a couple of outstanding questions from Paul's 30 Oct message; sorry = for missing >> these... >>=20 >>>>>> What the mechanism in the document should _not_ be used for is to >>>>>> expand the IPFIX information model to also include the contents = of all the >>>>>> various MIBs, such that SMI IEs could be used alongside IPFIX IEs = to export >>>>>> information from non-SNMP sources of data. Otherwise we've = created Yet >>>>>> Another Representation for lots of common IEs already in the = IPFIX IE registry, >>>>>> which would significantly complicate the comparison and = combination of data >>>>>> at collectors. The document needs to make this explicit, either = in section 1 or 2. >>>>> The mechanism _can_ be used like that. >>>> Can be, yes. Is it the express intention of the authors of the = draft to do so? >>>=20 >>> Authors aside, what does the WG want? Ultimately the goal is to = avoid >>> creating new IPFIX IEs for each MIB that needs exported. Does that = require >>> considering MIBs as part of the info model? >>=20 >> So I've thought about this a bit and I *think* we agree here: this = mechanism >> exists so that things which are already in MIBs can be exported via = IPFIX without >> having to define new IEs. >=20 > Exactly. >=20 >=20 >> Personally, I'd be happy if we didn't start deprecating things = already in the native >> registry in favor of things in MIBs, >=20 > Agreed; this document does not deprecate any existing IEs. >=20 > - which means there are now two ways of exporting some things (as IE = and as MIB). Collectors should already have architectures which = understand this equivalence (effectively a presentation layer) since = there are already some equivalent (duplicate) IEs (Andrew Feren had a = list), and the list will surely grow as enterprise-specific IEs are = transitioned to IANA. So I consider this to be a pre-existing issue = which was not introduced by this document. Okay, now I get your point. Agreed. > Therefore I don't see a need to document the existing IE / MIB = equivalences in the document. Please shout if you disagree. At this point I'm happy to leave this as an article for future work = should anyone want to pick it up and run with it. Let's ship it and declare victory (pending Juergen's SNMP-and-MIB-expert = review). :) Cheers, Brian >> and if the IE Doctors don't tell someone who >> wants an IE that they can't have it because it's in MIB X. >=20 > I think it'll be on a case-by-case basis. Hopefully they'll encourage = the use of MIB export. However if the use case involves exporting lots = of other IEs and no other MIBs, then a new IE would seem justified for = simplicity. > Remember that the point of the draft is to avoid overloading the IANA = registry with new IEs which are equivalent to existing MIBs. >=20 >=20 >> I don't believe it's necessary to write any of that down though. >=20 > +1 >=20 >=20 >>>>> Expressed another way, we've already created duplication; now we = have to live with it. >>>> Actually this seems to be closer to "we've already created = duplication, so we can happily create more," which seems dangerous for = sustainable interop. >>>=20 >>> What change, if any, would you like to see in the draft? >>=20 >>=20 >> As long as it's clear that the mechanism is intended to glue MIBs to = IPFIX, none. >=20 > Great, thanks! >=20 > P. >=20 >=20 >>=20 >> Cheers, >>=20 >> Brian >>=20 >> On 13 Dec 2014, at 00:13, Paul Aitken wrote: >>=20 >>> Joel, All, >>>=20 >>> I'm waiting for WG review of draft-ietf-ipfix-mib-variable-export-07 >>> -principally from Brian Trammell and Juergen Schoenwaelder. >>>=20 >>> P. >>>=20 >>>=20 >>> From: joel jaeggli >>> Date: 12 December 2014 at 20:05 >>> Subject: [IPFIX] Winding down the ipfix working group. >>> To: IPFIX Working Group >>> Cc: "ipfix-chairs@tools.ietf.org" >>>=20 >>>=20 >>>=20 >>> Greetings, >>>=20 >>> The chairs and my co-AD and I have decided it's time to window down >>> the ipfix working group. Our major milestones are completed and we >>> should be pleased with the results. >>>=20 >>> We have one remaining active document >>>=20 >>> draft-ietf-ipfix-mib-variable-export >>>=20 >>> which I will be happy to AD sponsor. Barring significant commentary = to >>> contrary I will close the working-group on friday december 19th and = we >>> will retain the mailing list for some time after that. >>>=20 >>> Thanks and congratulations. >>> Joel >>>=20 >>>=20 >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >>>=20 >>>=20 >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix From nobody Mon Dec 15 03:48:33 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE1A1A1B53 for ; Mon, 15 Dec 2014 03:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Nm2pDgyuOTJS for ; Mon, 15 Dec 2014 03:48:30 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE751A1B4F for ; Mon, 15 Dec 2014 03:48:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1212; q=dns/txt; s=iport; t=1418644110; x=1419853710; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7Xq7n5vNWpHFFr/Ll7nM4N/n/z7YfT1f69hXZwrvhAA=; b=H4oFNphJuyPFj94ytUUxv/UGke2M4YNMqkuAbWV0Ypi2U6S3w1tE4gKZ XMClB36ZdOD+q6vUMvft9gfU3zP/SSl1Y4nrQOXtw+y0NtpPBhqpvulD8 6md1u3Ao43oLE2iwhRArfP0He+D/HaEMelztOZyzWhaA9CK0jCe+PTi90 E=; X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208";a="270758053" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 15 Dec 2014 11:48:28 +0000 Received: from [64.103.108.123] (dhcp-bdlk10-data-vlan301-64-103-108-123.cisco.com [64.103.108.123]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBFBmRgC000920; Mon, 15 Dec 2014 11:48:27 GMT Message-ID: <548ECA8F.7030209@cisco.com> Date: Mon, 15 Dec 2014 11:48:31 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: joel jaeggli , IPFIX Working Group References: <5435D840.1090108@bogus.com> <5487A31D.5040304@bogus.com> <548B4AA0.4000905@bogus.com> <9904FB1B0159DA42B0B887B7FA8119CA5C92F0DE@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C92F0DE@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/UxhfQGxyEXNVqe6iwhR6EaZ3B6Q Cc: "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] Winding down the ipfix working group. X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 11:48:32 -0000 As many of you know I have concerns about closing IPFIX. Whilst IPFIX may have completed sufficient of its work in support of network management, the protocol has much to offer in terms of use as a mass data collection protocol particularly in the IOT space. I thus have some reservations about terminating the work as opposed to moving it to another area. - Stewart >> -----Original Message----- >> From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of joel jaeggli >> Sent: Friday, December 12, 2014 10:06 PM >> To: IPFIX Working Group >> Cc: ipfix-chairs@tools.ietf.org >> Subject: [IPFIX] Winding down the ipfix working group. >> >> >> Greetings, >> >> The chairs and my co-AD and I have decided it's time to window down the >> ipfix working group. Our major milestones are completed and we should be >> pleased with the results. >> >> We have one remaining active document >> >> draft-ietf-ipfix-mib-variable-export >> >> which I will be happy to AD sponsor. Barring significant commentary to >> contrary I will close the working-group on friday december 19th and we will >> retain the mailing list for some time after that. >> >> Thanks and congratulations. >> Joel From nobody Mon Dec 15 03:58:11 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92D51A1B2C for ; Mon, 15 Dec 2014 03:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Npm77Yd0jIDJ for ; Mon, 15 Dec 2014 03:58:02 -0800 (PST) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB161A1B64 for ; Mon, 15 Dec 2014 03:58:01 -0800 (PST) Received: from PLXRDC01.plxr.local ([::1]) by PLXRDC01.plxr.local ([::1]) with mapi id 14.03.0210.002; Mon, 15 Dec 2014 06:57:13 -0500 From: Andrew Feren To: "" Thread-Topic: [IPFIX] Winding down the ipfix working group. Thread-Index: AQHQFkb6C3v5vjWBhEqXL4BHivfn/5yPHDmAgAHFI4D//66bog== Date: Mon, 15 Dec 2014 11:57:13 +0000 Message-ID: <08A9E6AF-F505-4D5D-AC9C-E35D2AF8E08D@plixer.com> References: <5435D840.1090108@bogus.com> <5487A31D.5040304@bogus.com> <548B4AA0.4000905@bogus.com> <9904FB1B0159DA42B0B887B7FA8119CA5C92F0DE@AZ-FFEXMB04.global.avaya.com>, <548ECA8F.7030209@cisco.com> In-Reply-To: <548ECA8F.7030209@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_08A9E6AFF5054D5DAC9CE35D2AF8E08Dplixercom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/ta4FY9Qp4_nbe7Ew4Vs6fdF5LFk Cc: joel jaeggli , IPFIX Working Group , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] Winding down the ipfix working group. X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 11:58:09 -0000 --_000_08A9E6AFF5054D5DAC9CE35D2AF8E08Dplixercom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are you talking about adding IEs or something more? If more than just new IEs can you give an example? I've used IPFIX for tra= nsport of more than just network management information. I'm curious what i= s missing for your use cases. -Andrew On Dec 15, 2014, at 6:47 AM, Stewart Bryant > wrote: As many of you know I have concerns about closing IPFIX. Whilst IPFIX may have completed sufficient of its work in support of network management, the protocol has much to offer in terms of use as a mass data collection protocol particularly in the IOT space. I thus have some reservations about terminating the work as opposed to moving it to another area. - Stewart -----Original Message----- From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of joel jaeggli Sent: Friday, December 12, 2014 10:06 PM To: IPFIX Working Group Cc: ipfix-chairs@tools.ietf.org Subject: [IPFIX] Winding down the ipfix working group. Greetings, The chairs and my co-AD and I have decided it's time to window down the ipfix working group. Our major milestones are completed and we should be pleased with the results. We have one remaining active document draft-ietf-ipfix-mib-variable-export which I will be happy to AD sponsor. Barring significant commentary to contrary I will close the working-group on friday december 19th and we will retain the mailing list for some time after that. Thanks and congratulations. Joel _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --_000_08A9E6AFF5054D5DAC9CE35D2AF8E08Dplixercom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Are you talk= ing about adding IEs or something more?

If more than= just new IEs can you give an example?  I've used IPFIX for transport = of more than just network management information. I'm curious what is missi= ng for your use cases. 

-Andrew

On Dec 15, 2014, at 6:47 AM, Stewart Bryant <stbryant@cisco.com> wrote:

As many of you know I have concerns about closing IPFIX.<= br>
Whilst IPFIX may have completed sufficient of its work in support
of network management, the protocol has much to offer in terms=
of use as a mass data collection protocol particularly in the IOT spa= ce.
I thus have some reservations about terminating the work as opposed to moving it to another area.

- Stewart

-----Original Message-----
From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of joel jaeggli
Sent: Friday, December 12, 2014 10:06 PM
To: IPFIX Working Group
Cc: ipfix-chairs@tools.ietf.org
Subject: [IPFIX] Winding down the ipfix wor= king group.


Greetings,

The chairs and my co-AD and I have decided = it's time to window down the
ipfix working group. Our major milestones a= re completed and we should be
pleased with the results.

We have one remaining active document

draft-ietf-ipfix-mib-variable-export=

which I will be happy to AD sponsor. Barrin= g significant commentary to
contrary I will close the working-group on = friday december 19th and we will
retain the mailing list for some time after= that.

Thanks and congratulations.
Joel

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.i= etf.org/mailman/listinfo/ipfix
--_000_08A9E6AFF5054D5DAC9CE35D2AF8E08Dplixercom_-- From nobody Mon Dec 15 04:53:38 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699F81A1B78 for ; Mon, 15 Dec 2014 04:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 O7ATehpAu0my for ; Mon, 15 Dec 2014 04:53:35 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3FC1A1B75 for ; Mon, 15 Dec 2014 04:53:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11067; q=dns/txt; s=iport; t=1418648013; x=1419857613; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=nwFfBmbvv2OfmFrW0YsrtUjsne93CbSGxmrhueNHdTs=; b=g287+Y8HDfyX6hYo9SQE8mPXy8OdKhADWx0IeSMhY5aX9sZG4hZ10FGk ddNGwE4Yu2+voaQrHekDLmMo46P1v982Db+5PeYAe9G3wV9T0IHwk3VZG piXIyJlagDeo8juJbVdcTRLkwGfhPcRHRcVcDNhR3IwqHo5zqu/g1TZbx c=; X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="scan'208,217";a="275555322" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 15 Dec 2014 12:53:32 +0000 Received: from [64.103.108.123] (dhcp-bdlk10-data-vlan301-64-103-108-123.cisco.com [64.103.108.123]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBFCrVgE000487; Mon, 15 Dec 2014 12:53:31 GMT Message-ID: <548ED9CF.8070309@cisco.com> Date: Mon, 15 Dec 2014 12:53:35 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andrew Feren References: <5435D840.1090108@bogus.com> <5487A31D.5040304@bogus.com> <548B4AA0.4000905@bogus.com> <9904FB1B0159DA42B0B887B7FA8119CA5C92F0DE@AZ-FFEXMB04.global.avaya.com>, <548ECA8F.7030209@cisco.com> <08A9E6AF-F505-4D5D-AC9C-E35D2AF8E08D@plixer.com> In-Reply-To: <08A9E6AF-F505-4D5D-AC9C-E35D2AF8E08D@plixer.com> Content-Type: multipart/alternative; boundary="------------070508060507050004020302" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/Ih1j3fS9F59Sx2OU0r9OuYzj_Oc Cc: joel jaeggli , IPFIX Working Group , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] Winding down the ipfix working group. X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 12:53:37 -0000 This is a multi-part message in MIME format. --------------070508060507050004020302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 15/12/2014 11:57, Andrew Feren wrote: > Are you talking about adding IEs or something more? > > If more than just new IEs can you give an example? I've used IPFIX > for transport of more than just network management information. I'm > curious what is missing for your use cases. > Well a bit off the cuff, but how about pre-registered templates rather than refreshed templates so that IOT devices don't need to use energy or bandwidth to transmit them? Are there any additional protocol considerations associated with privacy, authentication and resilience when IPFIX is used over the wide area? For example authenticated data merging? - Stewart > -Andrew > > On Dec 15, 2014, at 6:47 AM, Stewart Bryant > wrote: > >> As many of you know I have concerns about closing IPFIX. >> >> Whilst IPFIX may have completed sufficient of its work in support >> of network management, the protocol has much to offer in terms >> of use as a mass data collection protocol particularly in the IOT space. >> I thus have some reservations about terminating the work as >> opposed to moving it to another area. >> >> - Stewart >> >>>> -----Original Message----- >>>> From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of joel jaeggli >>>> Sent: Friday, December 12, 2014 10:06 PM >>>> To: IPFIX Working Group >>>> Cc: ipfix-chairs@tools.ietf.org >>>> Subject: [IPFIX] Winding down the ipfix working group. >>>> >>>> >>>> Greetings, >>>> >>>> The chairs and my co-AD and I have decided it's time to window down the >>>> ipfix working group. Our major milestones are completed and we >>>> should be >>>> pleased with the results. >>>> >>>> We have one remaining active document >>>> >>>> draft-ietf-ipfix-mib-variable-export >>>> >>>> which I will be happy to AD sponsor. Barring significant commentary to >>>> contrary I will close the working-group on friday december 19th and >>>> we will >>>> retain the mailing list for some time after that. >>>> >>>> Thanks and congratulations. >>>> Joel >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------070508060507050004020302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 15/12/2014 11:57, Andrew Feren wrote:
Are you talking about adding IEs or something more?

If more than just new IEs can you give an example?  I've used IPFIX for transport of more than just network management information. I'm curious what is missing for your use cases. 


Well a bit off the cuff, but how about pre-registered templates rather than refreshed templates so that IOT devices don't need to use energy or bandwidth to transmit them?

Are there any additional protocol considerations associated with privacy, authentication and resilience when IPFIX is used over the wide area? For example authenticated data merging?

- Stewart


-Andrew

On Dec 15, 2014, at 6:47 AM, Stewart Bryant <stbryant@cisco.com> wrote:

As many of you know I have concerns about closing IPFIX.

Whilst IPFIX may have completed sufficient of its work in support
of network management, the protocol has much to offer in terms
of use as a mass data collection protocol particularly in the IOT space.
I thus have some reservations about terminating the work as
opposed to moving it to another area.

- Stewart

-----Original Message-----
From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of joel jaeggli
Sent: Friday, December 12, 2014 10:06 PM
To: IPFIX Working Group
Cc: ipfix-chairs@tools.ietf.org
Subject: [IPFIX] Winding down the ipfix working group.


Greetings,

The chairs and my co-AD and I have decided it's time to window down the
ipfix working group. Our major milestones are completed and we should be
pleased with the results.

We have one remaining active document

draft-ietf-ipfix-mib-variable-export

which I will be happy to AD sponsor. Barring significant commentary to
contrary I will close the working-group on friday december 19th and we will
retain the mailing list for some time after that.

Thanks and congratulations.
Joel

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------070508060507050004020302-- From nobody Tue Dec 16 22:39:26 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AE41A044D for ; Tue, 16 Dec 2014 22:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 IeNwi7XNw4S5 for ; Tue, 16 Dec 2014 22:39:20 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 0F8811A039D for ; Tue, 16 Dec 2014 22:39:19 -0800 (PST) Received: from mbp.local ([IPv6:2601:9:7681:2d01:4897:9f29:74ea:535a]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id sBH6d8pr022665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 Dec 2014 06:39:09 GMT (envelope-from joelja@bogus.com) Message-ID: <5491250B.9030303@bogus.com> Date: Tue, 16 Dec 2014 22:39:07 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: stbryant@cisco.com, Andrew Feren References: <5435D840.1090108@bogus.com> <5487A31D.5040304@bogus.com> <548B4AA0.4000905@bogus.com> <9904FB1B0159DA42B0B887B7FA8119CA5C92F0DE@AZ-FFEXMB04.global.avaya.com>, <548ECA8F.7030209@cisco.com> <08A9E6AF-F505-4D5D-AC9C-E35D2AF8E08D@plixer.com> <548ED9CF.8070309@cisco.com> In-Reply-To: <548ED9CF.8070309@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p7XtUf9utvUSIJ00BhsF9aijXwj2EHsnW" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/mhtXjjbXlPu-EOJp5YLJXcsR0pY Cc: IPFIX Working Group , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] Winding down the ipfix working group. X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 06:39:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --p7XtUf9utvUSIJ00BhsF9aijXwj2EHsnW Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/15/14 4:53 AM, Stewart Bryant wrote: > On 15/12/2014 11:57, Andrew Feren wrote: >> Are you talking about adding IEs or something more? >> IE's at least can be handled via expert review. if you needed new one's for a particular application that work might be best done in connection with the area of work requiring the IEs (as mibs or information models ar= e). >> If more than just new IEs can you give an example? I've used IPFIX >> for transport of more than just network management information. I'm >> curious what is missing for your use cases.=20 >> > > Well a bit off the cuff, but how about pre-registered templates rather > than refreshed templates so that IOT devices don't need to use energy > or bandwidth to transmit them? > > Are there any additional protocol considerations associated with > privacy, authentication and resilience when IPFIX is used over the > wide area? For example authenticated data merging? useful food for thought. thanks joel > - Stewart > > >> -Andrew >> >> On Dec 15, 2014, at 6:47 AM, Stewart Bryant > > wrote: >> >>> As many of you know I have concerns about closing IPFIX. >>> >>> Whilst IPFIX may have completed sufficient of its work in support >>> of network management, the protocol has much to offer in terms >>> of use as a mass data collection protocol particularly in the IOT spa= ce. >>> I thus have some reservations about terminating the work as >>> opposed to moving it to another area. >>> >>> - Stewart >>> >>>>> -----Original Message----- >>>>> From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of joel jaegg= li >>>>> Sent: Friday, December 12, 2014 10:06 PM >>>>> To: IPFIX Working Group >>>>> Cc: ipfix-chairs@tools.ietf.org >>>>> Subject: [IPFIX] Winding down the ipfix working group. >>>>> >>>>> >>>>> Greetings, >>>>> >>>>> The chairs and my co-AD and I have decided it's time to window >>>>> down the >>>>> ipfix working group. Our major milestones are completed and we >>>>> should be >>>>> pleased with the results. >>>>> >>>>> We have one remaining active document >>>>> >>>>> draft-ietf-ipfix-mib-variable-export >>>>> >>>>> which I will be happy to AD sponsor. Barring significant commentary= to >>>>> contrary I will close the working-group on friday december 19th >>>>> and we will >>>>> retain the mailing list for some time after that. >>>>> >>>>> Thanks and congratulations. >>>>> Joel >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix > > > --=20 > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > --p7XtUf9utvUSIJ00BhsF9aijXwj2EHsnW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlSRJQwACgkQ8AA1q7Z/VrKo2QCeP7lHc3I6dfVwW1B72XorbCO4 e+0AnRjBncHg9Tpza0oaF+lWe/o4SfD7 =Risc -----END PGP SIGNATURE----- --p7XtUf9utvUSIJ00BhsF9aijXwj2EHsnW-- From nobody Wed Dec 17 01:06:46 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178C41A1BDC for ; Wed, 17 Dec 2014 01:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 gD1rAI7Mzga1 for ; Wed, 17 Dec 2014 01:06:41 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5CE11A2119 for ; Wed, 17 Dec 2014 01:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12719; q=dns/txt; s=iport; t=1418807201; x=1420016801; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=a40AhfUMNVdczhMmHnAOu3NaD1kXWQksjTbVHtSe/HA=; b=VZZCzVX2j+ZvZDvQ5+tK+p7Gk5IAXPFh5qz33/LS98m2AKwSc6+wGEtu LT119p6hLBYR5+oq+ZJ+KqY2/E0MA7wzmxuPsx8sQp8F304drk+GxZCrk qlEU/rtyXl0T7H2Yyfg/NvJ/3jtoegUOjLRYynVzQDnW0aZ9M9Lc6WDsz M=; X-IronPort-AV: E=Sophos;i="5.07,592,1413244800"; d="scan'208,217";a="277397530" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 17 Dec 2014 09:06:36 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBH96aSo026054; Wed, 17 Dec 2014 09:06:36 GMT Message-ID: <5491479B.6060305@cisco.com> Date: Wed, 17 Dec 2014 10:06:35 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: stbryant@cisco.com, Andrew Feren References: <5435D840.1090108@bogus.com> <5487A31D.5040304@bogus.com> <548B4AA0.4000905@bogus.com> <9904FB1B0159DA42B0B887B7FA8119CA5C92F0DE@AZ-FFEXMB04.global.avaya.com>, <548ECA8F.7030209@cisco.com> <08A9E6AF-F505-4D5D-AC9C-E35D2AF8E08D@plixer.com> <548ED9CF.8070309@cisco.com> In-Reply-To: <548ED9CF.8070309@cisco.com> Content-Type: multipart/alternative; boundary="------------030900060207000201000209" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/GQg2tqrL5wqWaW762onOTmsgamQ Cc: joel jaeggli , IPFIX Working Group , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] Winding down the ipfix working group. X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 09:06:44 -0000 This is a multi-part message in MIME format. --------------030900060207000201000209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 15/12/2014 13:53, Stewart Bryant wrote: > On 15/12/2014 11:57, Andrew Feren wrote: >> Are you talking about adding IEs or something more? >> >> If more than just new IEs can you give an example? I've used IPFIX >> for transport of more than just network management information. I'm >> curious what is missing for your use cases. >> > > Well a bit off the cuff, but how about pre-registered templates rather > than refreshed templates so that IOT devices don't need to use energy > or bandwidth to transmit them? So going back to NetFlow v5? :-) As you know, we had to move away from v5 to v9 to solve a real problem. Regards, Benoit > Are there any additional protocol considerations associated with > privacy, authentication and resilience when IPFIX is used over the > wide area? For example authenticated data merging? > > - Stewart > > >> -Andrew >> >> On Dec 15, 2014, at 6:47 AM, Stewart Bryant > > wrote: >> >>> As many of you know I have concerns about closing IPFIX. >>> >>> Whilst IPFIX may have completed sufficient of its work in support >>> of network management, the protocol has much to offer in terms >>> of use as a mass data collection protocol particularly in the IOT space. >>> I thus have some reservations about terminating the work as >>> opposed to moving it to another area. >>> >>> - Stewart >>> >>>>> -----Original Message----- >>>>> From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of joel jaeggli >>>>> Sent: Friday, December 12, 2014 10:06 PM >>>>> To: IPFIX Working Group >>>>> Cc: ipfix-chairs@tools.ietf.org >>>>> Subject: [IPFIX] Winding down the ipfix working group. >>>>> >>>>> >>>>> Greetings, >>>>> >>>>> The chairs and my co-AD and I have decided it's time to window >>>>> down the >>>>> ipfix working group. Our major milestones are completed and we >>>>> should be >>>>> pleased with the results. >>>>> >>>>> We have one remaining active document >>>>> >>>>> draft-ietf-ipfix-mib-variable-export >>>>> >>>>> which I will be happy to AD sponsor. Barring significant commentary to >>>>> contrary I will close the working-group on friday december 19th >>>>> and we will >>>>> retain the mailing list for some time after that. >>>>> >>>>> Thanks and congratulations. >>>>> Joel >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------030900060207000201000209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 15/12/2014 13:53, Stewart Bryant wrote:
On 15/12/2014 11:57, Andrew Feren wrote:
Are you talking about adding IEs or something more?

If more than just new IEs can you give an example?  I've used IPFIX for transport of more than just network management information. I'm curious what is missing for your use cases. 


Well a bit off the cuff, but how about pre-registered templates rather than refreshed templates so that IOT devices don't need to use energy or bandwidth to transmit them?
So going back to NetFlow v5? :-)
As you know, we had to move away from v5 to v9 to solve a real problem.

Regards, Benoit

Are there any additional protocol considerations associated with privacy, authentication and resilience when IPFIX is used over the wide area? For example authenticated data merging?

- Stewart


-Andrew

On Dec 15, 2014, at 6:47 AM, Stewart Bryant <stbryant@cisco.com> wrote:

As many of you know I have concerns about closing IPFIX.

Whilst IPFIX may have completed sufficient of its work in support
of network management, the protocol has much to offer in terms
of use as a mass data collection protocol particularly in the IOT space.
I thus have some reservations about terminating the work as
opposed to moving it to another area.

- Stewart

-----Original Message-----
From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of joel jaeggli
Sent: Friday, December 12, 2014 10:06 PM
To: IPFIX Working Group
Cc: ipfix-chairs@tools.ietf.org
Subject: [IPFIX] Winding down the ipfix working group.


Greetings,

The chairs and my co-AD and I have decided it's time to window down the
ipfix working group. Our major milestones are completed and we should be
pleased with the results.

We have one remaining active document

draft-ietf-ipfix-mib-variable-export

which I will be happy to AD sponsor. Barring significant commentary to
contrary I will close the working-group on friday december 19th and we will
retain the mailing list for some time after that.

Thanks and congratulations.
Joel

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html




_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------030900060207000201000209-- From nobody Wed Dec 17 01:08:19 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4C11A1BBB for ; Wed, 17 Dec 2014 01:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 gIqA4B2iVLzO for ; Wed, 17 Dec 2014 01:08:11 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 067AD1A6FB0 for ; Wed, 17 Dec 2014 01:07:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1474; q=dns/txt; s=iport; t=1418807239; x=1420016839; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=T6mxC3hIF4/8Topu2kRnpKV6td4PYSyVcU1GK2+4IL0=; b=O9UJlKuS/20+8yI4HzLebJwVlHi+u/M6YLEygUlm+QHVj4avqG647Lgx 6IJ/VXFEruAllrjw0/K501IU6BhzgG4PEMF7ppFw7Ao5amBAZ37rJECtE +CZVKMXHqtdJk8jqHRD1eHVDtqAEVotkBEbBii2oXwx43rxHPMk0pEudh Q=; X-IronPort-AV: E=Sophos;i="5.07,592,1413244800"; d="scan'208";a="273247815" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 17 Dec 2014 09:07:17 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBH97GTd022504; Wed, 17 Dec 2014 09:07:17 GMT Message-ID: <549147C4.6000300@cisco.com> Date: Wed, 17 Dec 2014 10:07:16 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: stbryant@cisco.com, joel jaeggli , IPFIX Working Group References: <5435D840.1090108@bogus.com> <5487A31D.5040304@bogus.com> <548B4AA0.4000905@bogus.com> <9904FB1B0159DA42B0B887B7FA8119CA5C92F0DE@AZ-FFEXMB04.global.avaya.com> <548ECA8F.7030209@cisco.com> In-Reply-To: <548ECA8F.7030209@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/VrblsxEtR9fxvmeEsmTowwtQVcs Cc: "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] Winding down the ipfix working group. X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 09:08:15 -0000 Stewart, > As many of you know I have concerns about closing IPFIX. > > Whilst IPFIX may have completed sufficient of its work in support > of network management, the protocol has much to offer in terms > of use as a mass data collection protocol particularly in the IOT space. > I thus have some reservations about terminating the work as > opposed to moving it to another area. OPSAWG could be used if necessary. Regards, Benoit > > - Stewart > >>> -----Original Message----- >>> From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of joel jaeggli >>> Sent: Friday, December 12, 2014 10:06 PM >>> To: IPFIX Working Group >>> Cc: ipfix-chairs@tools.ietf.org >>> Subject: [IPFIX] Winding down the ipfix working group. >>> >>> >>> Greetings, >>> >>> The chairs and my co-AD and I have decided it's time to window down the >>> ipfix working group. Our major milestones are completed and we >>> should be >>> pleased with the results. >>> >>> We have one remaining active document >>> >>> draft-ietf-ipfix-mib-variable-export >>> >>> which I will be happy to AD sponsor. Barring significant commentary to >>> contrary I will close the working-group on friday december 19th and >>> we will >>> retain the mailing list for some time after that. >>> >>> Thanks and congratulations. >>> Joel > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > From nobody Wed Dec 17 02:37:14 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C2A1A86F0 for ; Wed, 17 Dec 2014 02:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 LFaHC5ycBjhe for ; Wed, 17 Dec 2014 02:37:09 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8741A6F61 for ; Wed, 17 Dec 2014 02:37:08 -0800 (PST) Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id sBH9xw09006595; Wed, 17 Dec 2014 02:37:06 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1raph0teug-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 17 Dec 2014 02:37:06 -0800 Received: from BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.101) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 17 Dec 2014 02:37:05 -0800 Received: from BRMWP-EXMB11.corp.brocade.com (172.16.59.77) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 17 Dec 2014 03:37:05 -0700 Received: from EMEAWP-CASH02.corp.brocade.com (172.29.19.10) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 17 Dec 2014 03:37:04 -0700 Received: from EMEA-EXCH01.corp.brocade.com ([fe80::18c9:7b21:74fd:7e48]) by EMEAWP-CASH02.corp.brocade.com ([fe80::548c:8759:5d5e:1c0b%12]) with mapi; Wed, 17 Dec 2014 11:37:03 +0100 From: Paul Aitken To: Benoit Claise , "stbryant@cisco.com" , Andrew Feren Date: Wed, 17 Dec 2014 11:37:01 +0100 Thread-Topic: [IPFIX] Winding down the ipfix working group. Thread-Index: AdAZ2Myfv5i9gI49S1iDmBrn5qREGwABJrAg Message-ID: <23B7BE54EACBED43957AB709C564F7B701853E2971@EMEA-EXCH01.corp.brocade.com> References: <5435D840.1090108@bogus.com> <5487A31D.5040304@bogus.com> <548B4AA0.4000905@bogus.com> <9904FB1B0159DA42B0B887B7FA8119CA5C92F0DE@AZ-FFEXMB04.global.avaya.com>, <548ECA8F.7030209@cisco.com> <08A9E6AF-F505-4D5D-AC9C-E35D2AF8E08D@plixer.com> <548ED9CF.8070309@cisco.com> <5491479B.6060305@cisco.com> In-Reply-To: <5491479B.6060305@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-17_03:2014-12-17,2014-12-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412170107 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/mRodJXLCpnlFPtroOK2auXctZhI Cc: joel jaeggli , IPFIX Working Group , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] Winding down the ipfix working group. X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 10:37:11 -0000 Benoit, All, >> Well a bit off the cuff, but how about pre-registered templates rather than refreshed templates so that IOT devices don't need to use energy or bandwidth to transmit them? > > So going back to NetFlow v5? :-) > As you know, we had to move away from v5 to v9 to solve a real problem. Templates generally consume only a tiny portion of the export bandwidth, so they're a non-issue for hard-wired devices in an enterprise or data-centre setting. However, if a device isn't able to maintain an SCTP or TCP connection (eg because it's a low-power device which exports infrequently and powers down between exports, or it's a mobile device which goes out of range), then the exporter would need to re-send the template at the start of each export. In the worst case the template could be sent with each data record (assuming export over UDP), at which point templates become a significant portion of the export bandwidth. I've seen a packet capture from a device which actually does that. So I could imagine a use-case where pre-registered templates are useful. The exporter would only send data records, and the collector would have to obtain the necessary template(s) from a repository. However if the exporter sends the repository URL rather than the template then it's possible that there would be no export saving at all. If the exporter sends a template ID then we'd have to consider how the collector discovers where the repository is located and authentication of the received templates. If it's a central repository then we have to think about authentication for addition of new templates and whether modifications are allowed. If it was a real use case with actual demand behind it then it could be addressed in one draft which could be AD sponsored. However since it seems to be a theoretical idea with no demand, there seems to be no justification in keeping the WG open just for this. It could be an interesting NMRG project. P. From nobody Wed Dec 17 04:15:00 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE441A8955 for ; Wed, 17 Dec 2014 04:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 y72Msa9qt3SB for ; Wed, 17 Dec 2014 04:14:55 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C2E1A1A7D for ; Wed, 17 Dec 2014 04:14:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2863; q=dns/txt; s=iport; t=1418818495; x=1420028095; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=qJYIIga3y5PkFc3/y75QmB+WZ/XIHPAsxn6wBf9AYHc=; b=eHpknH9u7kAa4C4aHM1DkhSx1QPcHsjMD61Ekv0GueOCpRSAzyyzxqwH iT1hf/U45kOQUeW1J8AeyqvNu39axtvmZ26//FEYNPVfc++bBL1q2GRNk p3U0GB2YTcl+riRV6h3231983VjRusPfh9oiziSbmge8xhOPMqDuOKdT/ Y=; X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="277569356" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 17 Dec 2014 12:14:53 +0000 Received: from [10.61.196.146] ([10.61.196.146]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBHCEruK017621; Wed, 17 Dec 2014 12:14:53 GMT Message-ID: <549173BE.8050901@cisco.com> Date: Wed, 17 Dec 2014 12:14:54 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Aitken , Benoit Claise , Andrew Feren References: <5435D840.1090108@bogus.com> <5487A31D.5040304@bogus.com> <548B4AA0.4000905@bogus.com> <9904FB1B0159DA42B0B887B7FA8119CA5C92F0DE@AZ-FFEXMB04.global.avaya.com>, <548ECA8F.7030209@cisco.com> <08A9E6AF-F505-4D5D-AC9C-E35D2AF8E08D@plixer.com> <548ED9CF.8070309@cisco.com> <5491479B.6060305@cisco.com> <23B7BE54EACBED43957AB709C564F7B701853E2971@EMEA-EXCH01.corp.brocade.com> In-Reply-To: <23B7BE54EACBED43957AB709C564F7B701853E2971@EMEA-EXCH01.corp.brocade.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/jfA5m924iw_qpunKhjNz43cVSmk Cc: joel jaeggli , IPFIX Working Group , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] Winding down the ipfix working group. X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 12:14:59 -0000 On 17/12/2014 10:37, Paul Aitken wrote: > Benoit, All, > >>> Well a bit off the cuff, but how about pre-registered templates rather than refreshed templates so that IOT devices don't need to use energy or bandwidth to transmit them? >> So going back to NetFlow v5? :-) >> As you know, we had to move away from v5 to v9 to solve a real problem. > Templates generally consume only a tiny portion of the export bandwidth, so they're a non-issue for hard-wired devices in an enterprise or data-centre setting. > > However, if a device isn't able to maintain an SCTP or TCP connection (eg because it's a low-power device which exports infrequently and powers down between exports, or it's a mobile device which goes out of range), then the exporter would need to re-send the template at the start of each export. In the worst case the template could be sent with each data record (assuming export over UDP), at which point templates become a significant portion of the export bandwidth. I've seen a packet capture from a device which actually does that. > > So I could imagine a use-case where pre-registered templates are useful. The exporter would only send data records, and the collector would have to obtain the necessary template(s) from a repository. > > However if the exporter sends the repository URL rather than the template then it's possible that there would be no export saving at all. If the exporter sends a template ID then we'd have to consider how the collector discovers where the repository is located and authentication of the received templates. If it's a central repository then we have to think about authentication for addition of new templates and whether modifications are allowed. > > If it was a real use case with actual demand behind it then it could be addressed in one draft which could be AD sponsored. However since it seems to be a theoretical idea with no demand, there seems to be no justification in keeping the WG open just for this. > > It could be an interesting NMRG project. > > P. > . > I think my overall point is that IPFIX may have completed it's work as an NM protocol, but it has significant potential as a collection protocol in other applications. If we give the message that it is in maintenance or that we have no IETF interest in further development then we know what will happen: a new protocol will be needlessly developed from scratch. With that in mind, mild hibernation might be a better approach. We do after all have WG in that state. Paul understands the application application issue, but I am not convinced that a single draft developed in isolation somewhere will produce an adequate solution. In terms of global templates, I would think that a global template ID of 32bits, extensible in 32bit quanta to 128 bits would suffice for a while. Stewart From nobody Wed Dec 17 06:18:40 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DB21A1B42 for ; Wed, 17 Dec 2014 06:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 OJKNEqZl4OqS for ; Wed, 17 Dec 2014 06:18:37 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45CF1A1AA4 for ; Wed, 17 Dec 2014 06:18:36 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2B7BB703 for ; Wed, 17 Dec 2014 15:18:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 0tcnAdfYgbp8 for ; Wed, 17 Dec 2014 15:18:19 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 17 Dec 2014 15:18:34 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D6012002C for ; Wed, 17 Dec 2014 15:18:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FqwZWTPZCUWr; Wed, 17 Dec 2014 15:18:33 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A8D4720017; Wed, 17 Dec 2014 15:18:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BF6242FF917F; Wed, 17 Dec 2014 15:18:31 +0100 (CET) Date: Wed, 17 Dec 2014 15:18:30 +0100 From: Juergen Schoenwaelder To: ipfix@ietf.org Message-ID: <20141217141829.GA67945@elstar.local> Mail-Followup-To: ipfix@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/bwkTaNW5QpEzU9XNWBuX24HXw-k Subject: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 14:18:39 -0000 Hi, here is my review of draft-ietf-ipfix-mib-variable-export-07. Most of the comments are editorial or bug fixes. There is only one real technical concern related to the encoding of BITS. The current I-D uses a 64-bit unsigned integer, which limits things to 64 bit positions. The SMIv2 does not have this limit - it only warns about bit positions in excess of 128. - RFC4293 is listed as a normative reference but as far as I can tell it is only used in an example. I suggest to make this an informative reference. - p3: 2nd paragraph Introduction: I am not sure the statement "there are no dependencies between the SMIv2 and the SNMP protocol" is correct. Perhaps the simplest fix is to simply delete the whole paragraph. - p4: 1st paragraph Motivation: The 2nd sentence is hard to follow. - p5: s/does not specify SNMP notifications/does not specify how to carry SNMP notifications in IPFIX/ - p9: s/in a certain MIB/in a certain MIB module/ - p10: s/may be also be/may also be/ - p10: s/described by the MIB./described by the MIB module./ - p14: s/when when/when/ - p14: s/references sections/referenced sections/ The fact that every listed item refers to two sections may be a bit confusing, perhaps change to o mibIndexIndicator (defined in Section 5.8.5, example in Section 11.2.2.3) - p20: It took me a while to spot the difference between Fig. 7 and Fig.8 (I did not immediately spot that the fields are swapped). Perhaps mention this more explicitly in the last paragraph on p19? Figure 7 shows an IPFIX Options Template Set using Scope Existing IFPIX IE and a Non Scope mibObjectValueInteger IE, while Figure 8 shows an IPFIX Options Template Set using a Scope mibObjectValueInteger IE and a Non Scope Existing IFPIX IE. - p12: s/name of the MIB/name of the MIB module/ - p26: s/present the same order/present in the same order/ - p32: s/not defined as possible/not possible/ - p37: s/CISCO-PROCESS_MIB/CISCO-PROCESS-MIB/ - p45: s/ifMTU/ifMtu/ (this shows up several time, do a global replace) - p46: Why is the Field Length of mibObjectValueOctetString set to 16? The interface names in general have variable length. - p47: why 'ifName = ""'? - p52: s/index by IEs:/indexed by IEs:/ - p58: The VLEN and the OID value seem to be wrong. I think this should be VLEN=10 and the OID value 06082B060102010E0A01. - p61: I would have named SNMPtotalCounter simply snmpCounter and I would have named SNMPgauge snmpGauge. If this change is adopted, then these names needs to be changed in several places. - p64: The encoding of mibObjectValueBits may need to specify how the bit positions are counted. That said, there is an issue here with using unsigned64. RFC 2578 does not restrict the bit positions, it only warns that using bit positions in excess of 128 may cause interoperability problems. The IPFIX I-D essentially limits this to 64 bits. The obvious solution is to follow the SNMP encoding rules that encode bits into an octet string (an octetArray in IPFIX speak). - p67: s/as defined in a MIB// - p68: OLD Description: A non-negative sub-identifier. One Sub number from an Object Identifier (OID). NEW Description: A non-negative sub-identifier of an Object Identifier (OID). - p69: s/was retrieved from SNMP/was retrieved from the MIB/ - p70: s/could be sampled by SNMP/has been sampled/ - p70: s/SNMP sampling time/sampling time/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Dec 17 07:06:14 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499341A8AAC for ; Wed, 17 Dec 2014 07:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 Gpel5j9ML2wI for ; Wed, 17 Dec 2014 07:06:00 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3671A8A9E for ; Wed, 17 Dec 2014 07:06:00 -0800 (PST) Received: from pps.filterd (m0048192 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id sBHETclu021485; Wed, 17 Dec 2014 07:05:59 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1rax1n9jt0-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 17 Dec 2014 07:05:59 -0800 Received: from BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.101) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 17 Dec 2014 07:05:57 -0800 Received: from BRMWP-EXMB12.corp.brocade.com (172.16.59.130) by BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 17 Dec 2014 08:05:57 -0700 Received: from EMEAWP-CASH02.corp.brocade.com (172.29.19.10) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 17 Dec 2014 08:05:56 -0700 Received: from EMEA-EXCH01.corp.brocade.com ([fe80::18c9:7b21:74fd:7e48]) by EMEAWP-CASH02.corp.brocade.com ([fe80::548c:8759:5d5e:1c0b%12]) with mapi; Wed, 17 Dec 2014 16:05:55 +0100 From: Paul Aitken To: Juergen Schoenwaelder , "ipfix@ietf.org" Date: Wed, 17 Dec 2014 16:05:52 +0100 Thread-Topic: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07 Thread-Index: AdAaBF4AnY0Vd+m1SO6RBJ1L54xa8gAAj7/g Message-ID: <23B7BE54EACBED43957AB709C564F7B701853E2B2A@EMEA-EXCH01.corp.brocade.com> References: <20141217141829.GA67945@elstar.local> In-Reply-To: <20141217141829.GA67945@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-17_04:2014-12-17,2014-12-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412170149 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/ntehJgW-SDV7xIwkZNy8zD9is_o Subject: Re: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 15:06:11 -0000 Thanks for this Juergen. I'll produce an updated version for the editorial issues. For the BITS issue, the largest IPFIX types are currently 64 bits (ie, signed64 / unsigned64). Although we could request a 128-bit type, we're simply moving the absolute limit along without solving the underlying issue. Do you know what size the largest BITS object is today? Would it be acceptable to limit the size that can be exported in IPFIX to the first 64 or 128 bits? Thanks, P. > here is my review of draft-ietf-ipfix-mib-variable-export-07. Most of the > comments are editorial or bug fixes. There is only one real technical concern > related to the encoding of BITS. The current I-D uses a 64-bit unsigned integer, > which limits things to 64 bit positions. The SMIv2 does not have this limit - it only > warns about bit positions in excess of 128. From nobody Wed Dec 17 07:49:01 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7781A1B7E for ; Wed, 17 Dec 2014 07:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 C-OH0zng3cOi for ; Wed, 17 Dec 2014 07:48:50 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710A91A8A46 for ; Wed, 17 Dec 2014 07:48:28 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7202F75E; Wed, 17 Dec 2014 16:48:27 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id xE5_GfNjDV0q; Wed, 17 Dec 2014 16:48:12 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 17 Dec 2014 16:48:26 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C5B1B2002C; Wed, 17 Dec 2014 16:48:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mKjgxgr7WgSu; Wed, 17 Dec 2014 16:48:26 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F379420017; Wed, 17 Dec 2014 16:48:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EF53A2FF9A8A; Wed, 17 Dec 2014 16:48:24 +0100 (CET) Date: Wed, 17 Dec 2014 16:48:24 +0100 From: Juergen Schoenwaelder To: Paul Aitken Message-ID: <20141217154824.GA68303@elstar.local> Mail-Followup-To: Paul Aitken , "ipfix@ietf.org" References: <20141217141829.GA67945@elstar.local> <23B7BE54EACBED43957AB709C564F7B701853E2B2A@EMEA-EXCH01.corp.brocade.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23B7BE54EACBED43957AB709C564F7B701853E2B2A@EMEA-EXCH01.corp.brocade.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/F3O_6Qkcwqim-V2DvDYHPGAkzb4 Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 15:48:52 -0000 On Wed, Dec 17, 2014 at 04:05:52PM +0100, Paul Aitken wrote: > Thanks for this Juergen. I'll produce an updated version for the editorial issues. > > For the BITS issue, the largest IPFIX types are currently 64 bits (ie, signed64 / unsigned64). Although we could request a 128-bit type, we're simply moving the absolute limit along without solving the underlying issue. SNMP encodes the bits into an octet string - an octetArray in IPFIX. Could this be done here as well? > Do you know what size the largest BITS object is today? Would it be > acceptable to limit the size that can be exported in IPFIX to the > first 64 or 128 bits? The first question can't be answered so I can't answer the second. It would be best, though, if IPFIX would not have to introduce a limit. Would an octetArray not work? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Dec 17 07:51:31 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B8C1A1A42 for ; Wed, 17 Dec 2014 07:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 o_UxdorwBQph for ; Wed, 17 Dec 2014 07:51:27 -0800 (PST) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id DADB51A1B76 for ; Wed, 17 Dec 2014 07:51:26 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::108d] (unknown [IPv6:2001:67c:10ec:2a49:8000::108d]) by trammell.ch (Postfix) with ESMTPSA id C58471A0856; Wed, 17 Dec 2014 16:50:55 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Brian Trammell In-Reply-To: <20141217154824.GA68303@elstar.local> Date: Wed, 17 Dec 2014 16:50:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <95AF6490-C189-4D89-9577-6ACCB0E4DE76@trammell.ch> References: <20141217141829.GA67945@elstar.local> <23B7BE54EACBED43957AB709C564F7B701853E2B2A@EMEA-EXCH01.corp.brocade.com> <20141217154824.GA68303@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/AuX_NqxlzzoqGiWs2P1GTpQqe-M Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 15:51:29 -0000 If BITS really isn't intended to encode integers with numeric or flag = semantics, then yes, it should be encoded as an octetArray. Cheers, Brian =20 > On 17 Dec 2014, at 16:48, Juergen Schoenwaelder = wrote: >=20 > On Wed, Dec 17, 2014 at 04:05:52PM +0100, Paul Aitken wrote: >> Thanks for this Juergen. I'll produce an updated version for the = editorial issues. >>=20 >> For the BITS issue, the largest IPFIX types are currently 64 bits = (ie, signed64 / unsigned64). Although we could request a 128-bit type, = we're simply moving the absolute limit along without solving the = underlying issue. >=20 > SNMP encodes the bits into an octet string - an octetArray in > IPFIX. Could this be done here as well? >=20 >> Do you know what size the largest BITS object is today? Would it be >> acceptable to limit the size that can be exported in IPFIX to the >> first 64 or 128 bits? >=20 > The first question can't be answered so I can't answer the second. It > would be best, though, if IPFIX would not have to introduce a limit. > Would an octetArray not work? >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From nobody Wed Dec 17 14:18:33 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756151A8821 for ; Wed, 17 Dec 2014 14:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 bhLXFU4I7lg8 for ; Wed, 17 Dec 2014 14:18:30 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10ED71A87EB for ; Wed, 17 Dec 2014 14:18:30 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id sBHLZuae001086; Wed, 17 Dec 2014 14:18:29 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1rbcan8xn1-6 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 17 Dec 2014 14:18:29 -0800 Received: from BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.101) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 17 Dec 2014 14:18:27 -0800 Received: from BRMWP-EXMB12.corp.brocade.com (172.16.59.130) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 17 Dec 2014 15:18:25 -0700 Received: from EMEAWP-CASH02.corp.brocade.com (172.29.19.10) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 17 Dec 2014 15:18:24 -0700 Received: from EMEA-EXCH01.corp.brocade.com ([fe80::18c9:7b21:74fd:7e48]) by EMEAWP-CASH02.corp.brocade.com ([fe80::548c:8759:5d5e:1c0b%12]) with mapi; Wed, 17 Dec 2014 23:18:23 +0100 From: Paul Aitken To: Brian Trammell , Juergen Schoenwaelder Date: Wed, 17 Dec 2014 23:18:21 +0100 Thread-Topic: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07 Thread-Index: AdAaEULhxhBQlkQkQ+2ZMSAZCdL2iQANc8dQ Message-ID: <23B7BE54EACBED43957AB709C564F7B701853E2C75@EMEA-EXCH01.corp.brocade.com> References: <20141217141829.GA67945@elstar.local> <23B7BE54EACBED43957AB709C564F7B701853E2B2A@EMEA-EXCH01.corp.brocade.com> <20141217154824.GA68303@elstar.local> <95AF6490-C189-4D89-9577-6ACCB0E4DE76@trammell.ch> In-Reply-To: <95AF6490-C189-4D89-9577-6ACCB0E4DE76@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-17_06:2014-12-17,2014-12-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412170213 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/BcQbsS5hXIM1JxnrjUcPaMgkyJY Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 22:18:32 -0000 Juergen, Brian, thanks both - that's what I'll do. P. > If BITS really isn't intended to encode integers with numeric or flag > semantics, then yes, it should be encoded as an octetArray. > > Cheers, > > Brian > > > On 17 Dec 2014, at 16:48, Juergen Schoenwaelder > wrote: > > > > On Wed, Dec 17, 2014 at 04:05:52PM +0100, Paul Aitken wrote: > >> Thanks for this Juergen. I'll produce an updated version for the editorial issues. > >> > >> For the BITS issue, the largest IPFIX types are currently 64 bits (ie, > >> signed64 / unsigned64). Although we could request a 128-bit type, we're > >> simply moving the absolute limit along without solving the underlying issue. > > > > SNMP encodes the bits into an octet string - an octetArray in IPFIX. > > Could this be done here as well? > > > >> Do you know what size the largest BITS object is today? Would it be > >> acceptable to limit the size that can be exported in IPFIX to the > >> first 64 or 128 bits? > > > > The first question can't be answered so I can't answer the second. It > > would be best, though, if IPFIX would not have to introduce a limit. > > Would an octetArray not work? > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix From nobody Wed Dec 24 22:30:14 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437F81A8720 for ; Wed, 24 Dec 2014 22:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ULnkSTnPSa9N for ; Wed, 24 Dec 2014 22:30:09 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5671A004C for ; Wed, 24 Dec 2014 22:30:08 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQL67287; Thu, 25 Dec 2014 06:30:06 +0000 (GMT) Received: from SZXEML453-HUB.china.huawei.com (10.82.67.196) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 25 Dec 2014 06:30:05 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.153]) by SZXEML453-HUB.china.huawei.com ([10.82.67.196]) with mapi id 14.03.0158.001; Thu, 25 Dec 2014 14:30:00 +0800 From: "Hedanping (Ana)" To: "ipfix@ietf.org" , "ipfix-chairs@tools.ietf.org" , "stbryant@cisco.com" , Paul Aitken , Benoit Claise , Andrew Feren Thread-Topic: Comments needed for draft-fu-ipfix-network-security-00 Thread-Index: AdAgDDK1FVa1OpepS8CUXrZ5IZppbA== Date: Thu, 25 Dec 2014 06:29:59 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D90DB24@szxeml557-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.95.23] Content-Type: multipart/alternative; boundary="_000_77FA386512F0D748BC7C02C36EB1106D90DB24szxeml557mbschina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/o54ztPEgojZ5NZVc4TRPORV3_TM Cc: "draft-fu-ipfix-network-security@tools.ietf.org" Subject: [IPFIX] Comments needed for draft-fu-ipfix-network-security-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 06:30:12 -0000 --_000_77FA386512F0D748BC7C02C36EB1106D90DB24szxeml557mbschina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, We wrote a draft to extend standard Information Elements for inspecting net= work security (e.g. the fragment attack in ICMP, TCP and UDP; and DDOS atta= ck). Compared with packet/Byte based sampling, session based sampling is pr= oposed and will be more useful for efficient and effective security inspect= ion. The link of the draft is as follow, where the proposed IEs are described: https://tools.ietf.org/html/draft-fu-ipfix-network-security-00 Your comments are welcome! Merry holidays and happy new year! Danping --_000_77FA386512F0D748BC7C02C36EB1106D90DB24szxeml557mbschina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

We wrote a draft to extend s= tandard Information Elements for inspecting network security (e.g. the frag= ment attack in ICMP, TCP and UDP; and DDOS attack). Compared with packet/By= te based sampling, session based sampling is proposed and will be more useful for efficient and effective security i= nspection.

 

The link of the draft is as = follow, where the proposed IEs are described:

https://tools.ietf.org/html/= draft-fu-ipfix-network-security-00

 

Your comments are welcome!

 

Merry holidays and happy new= year!

Danping

 

--_000_77FA386512F0D748BC7C02C36EB1106D90DB24szxeml557mbschina_-- From nobody Mon Dec 29 02:43:09 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BFC1A00C5 for ; Mon, 29 Dec 2014 02:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 IUwxnVqtaZ54 for ; Mon, 29 Dec 2014 02:43:01 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46EDC1A00B8 for ; Mon, 29 Dec 2014 02:43:01 -0800 (PST) Received: from pps.filterd (m0048192 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id sBTASj6r010323; Mon, 29 Dec 2014 02:42:51 -0800 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1rk2568dhf-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Dec 2014 02:42:51 -0800 Received: from BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) by HQ1WP-EXCHUB02.corp.brocade.com (10.70.38.101) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 29 Dec 2014 02:42:50 -0800 Received: from BRMWP-EXMB11.corp.brocade.com (172.16.59.77) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 29 Dec 2014 03:42:50 -0700 Received: from EMEAWP-CASH02.corp.brocade.com (172.29.19.10) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 29 Dec 2014 03:42:49 -0700 Received: from EMEA-EXCH01.corp.brocade.com ([fe80::18c9:7b21:74fd:7e48]) by EMEAWP-CASH02.corp.brocade.com ([fe80::548c:8759:5d5e:1c0b%12]) with mapi; Mon, 29 Dec 2014 11:42:47 +0100 From: Paul Aitken To: "Hedanping (Ana)" , "ipfix@ietf.org" , "ipfix-chairs@tools.ietf.org" , "stbryant@cisco.com" , Benoit Claise , Andrew Feren Date: Mon, 29 Dec 2014 11:42:46 +0100 Thread-Topic: Comments needed for draft-fu-ipfix-network-security-00 Thread-Index: AdAgDDK1FVa1OpepS8CUXrZ5IZppbADPbpNg Message-ID: <23B7BE54EACBED43957AB709C564F7B701857F3D09@EMEA-EXCH01.corp.brocade.com> References: <77FA386512F0D748BC7C02C36EB1106D90DB24@szxeml557-mbs.china.huawei.com> In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D90DB24@szxeml557-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_23B7BE54EACBED43957AB709C564F7B701857F3D09EMEAEXCH01cor_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-29_01:2014-12-24,2014-12-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412290109 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/dhrVR8EbV82TfCNZ0tbf-tTiwW8 Cc: "draft-fu-ipfix-network-security@tools.ietf.org" Subject: Re: [IPFIX] Comments needed for draft-fu-ipfix-network-security-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 10:43:05 -0000 --_000_23B7BE54EACBED43957AB709C564F7B701857F3D09EMEAEXCH01cor_ Content-Type: text/plain; charset="us-ascii" Ana, The main purpose of this draft is to request some new IPFIX Information Elements, which can be done through IANA without necessarily requiring a draft or RFC to be written. Eg, use this form: http://www.iana.org/cgi-bin/assignments.pl A draft is valuable if it's necessary to clarify how the new Information Elements should be used together or with existing Information Elements, or to define templates or timeouts which should be used. Section 3 of this document addressed some of this. However in the current case I think that the elements could be requested from IANA even without this information. Section 3.2, upstream/downstream counters: * How will the proposed counters help to distinguish between an attack and access to a recently published web content? Section 3.6, FlowEndReason: * Since the new flowEndReason value is not mentioned in section 5 (IANA), it may easily be overlooked. Section 5, IANA: * For pktUpstreamCount, pktDownstreamCount, octetUpstreamCount, and octetDownstreamCount, it's necessary to define what "upstream" and "downstream" mean. The semantics for these fields may be totalCounter or deltaCounter. * How can a generic applicationErrorCode be standardized? It would be necessary to pair it with information identifying the exact application which generated the error code. However sections 2 and 3.5 suggests this is actually the RFC 2616 HTTP status code - so please name it more appropriately, and in the description clarify that it's the RFC 2616 code. * Why are fragmentIncomplete, fragmentFirstTooShort, fragmentOffestError and fragmentFlagError unsigned32? Perhaps these should be Boolean. However, what value should they take when fragmentation does not apply to the flows? * icmpEchoCount and icmpEchoReplyCount semantics may be totalCounter or deltaCounter. P. From: Hedanping (Ana) [mailto:ana.hedanping@huawei.com] Sent: 25 December 2014 06:30 To: ipfix@ietf.org; ipfix-chairs@tools.ietf.org; stbryant@cisco.com; Paul Aitken; Benoit Claise; Andrew Feren Cc: draft-fu-ipfix-network-security@tools.ietf.org Subject: Comments needed for draft-fu-ipfix-network-security-00 All, We wrote a draft to extend standard Information Elements for inspecting network security (e.g. the fragment attack in ICMP, TCP and UDP; and DDOS attack). Compared with packet/Byte based sampling, session based sampling is proposed and will be more useful for efficient and effective security inspection. The link of the draft is as follow, where the proposed IEs are described: https://tools.ietf.org/html/draft-fu-ipfix-network-security-00 Your comments are welcome! Merry holidays and happy new year! Danping --_000_23B7BE54EACBED43957AB709C564F7B701857F3D09EMEAEXCH01cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ana,=

 

The main purpose of this draft is to re= quest some new IPFIX Information Elements, which can be done through IANA w= ithout necessarily requiring a draft or RFC to be written. Eg, use this for= m: http://www.iana.o= rg/cgi-bin/assignments.pl

 

A draft is= valuable if it’s necessary to clarify how the new Information Elemen= ts should be used together or with existing Information Elements, or to def= ine templates or timeouts which should be used. Section 3 of this document = addressed some of this. However in the current case I think that the elemen= ts could be requested from IANA even without this information.

 

 

Section 3.2, upstream/downstrea= m counters:

 

·        How will the proposed= counters help to distinguish between an attack and access to a recently pu= blished web content?

 

 <= /span>

Section 3.6, FlowEndReason:

 

·        Si= nce the new flowEndReason value is not mentioned in section 5 (IANA), it ma= y easily be overlooked.

 

 

Section 5, IANA:

 

<= ![if !supportLists]>·        For pktU= pstreamCount, pktDownstreamCount, octetUpstreamCount, and octetDownstreamCo= unt, it’s necessary to define what “upstream” and “= downstream” mean. The semantics for these fields may be totalCounter = or deltaCounter.

· &n= bsp;      How can a generic applicationErrorCod= e be standardized? It would be necessary to pair it with information identi= fying the exact application which generated the error code. However section= s 2 and 3.5 suggests this is actually the RFC 2616 HTTP status code –= so please name it more appropriately, and in the description clarify that = it’s the RFC 2616 code.

·        Why are fragmentIncomple= te, fragmentFirstTooShort, fragmentOffestError and fragmentFlagError unsign= ed32? Perhaps these should be Boolean. However, what value should they take= when fragmentation does not apply to the flows?

·        <= /span>icmpE= choCount and icmpEchoReplyCount semantics may be totalCounter or deltaCount= er.

 

 

P.

 

 

<= p class=3DMsoNormal align=3Dleft style=3D'text-align:left'>From: Hedanping = (Ana) [mailto:ana.hedanping@huawei.com]
Sent: 25 December 2014 0= 6:30
To: ipfix@ietf.org; ipfix-chairs@tools.ietf.org; stbryant@ci= sco.com; Paul Aitken; Benoit Claise; Andrew Feren
Cc: draft-fu-ip= fix-network-security@tools.ietf.org
Subject: Comments needed for = draft-fu-ipfix-network-security-00

 

<= p class=3DMsoPlainText>All,=

We wrote a draft to extend standard Information Elements for inspe= cting network security (e.g. the fragment attack in ICMP, TCP and UDP; and = DDOS attack). Compared with packet/Byte based sampling, session based sampl= ing is proposed and will be more useful for efficient and effective securit= y inspection.

 

The link of the draft is as = follow, where the proposed IEs are described:

https://tools.ie= tf.org/html/draft-fu-ipfix-network-security-00

 =

Your comments are welcome!

 

Merry = holidays and happy new year!

<= span style=3D'mso-fareast-language:ZH-CN'>Danping

 

= --_000_23B7BE54EACBED43957AB709C564F7B701857F3D09EMEAEXCH01cor_-- From nobody Wed Dec 31 07:10:46 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3A21A9034 for ; Wed, 31 Dec 2014 07:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.212 X-Spam-Level: X-Spam-Status: No, score=-104.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 Q0PWeF0mZUWU for ; Wed, 31 Dec 2014 07:10:42 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 520281A9033 for ; Wed, 31 Dec 2014 07:10:42 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 7893F180092; Wed, 31 Dec 2014 07:10:37 -0800 (PST) To: bclaise@cisco.com, trammell@tik.ee.ethz.ch, paitken@cisco.com, bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141231151037.7893F180092@rfc-editor.org> Date: Wed, 31 Dec 2014 07:10:37 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/nI1JAZLHN9XDIeausGq9B4GDhvs Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC7011 (4216) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 15:10:44 -0000 The following errata report has been submitted for RFC7011, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7011&eid=4216 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 3.4.2.2 Original Text ------------- Scope Field Count Number of scope fields in this Options Template Record. The Scope Fields are normal Fields, except that they are interpreted as scope at the Collector. A scope field count of N specifies that the first N Field Specifiers in the Template Record are Scope Fields. The Scope Field Count MUST NOT be zero. Corrected Text -------------- Scope Field Scope Fields are normal Fields, except that they are interpreted as scope at the Collector. Scope Field Count Number of scope fields in this Options Template Record. A scope field count of N specifies that the first N Field Specifiers in the Template Record are Scope Fields. The Scope Field Count MUST NOT be zero. Notes ----- Separate out the "Scope Field" definition from "Scope Field Count", since "Scope Field" is used as a defined term throughout the document without a formal definition. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7011 (draft-ietf-ipfix-protocol-rfc5101bis-10) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information Publication Date : September 2013 Author(s) : B. Claise, Ed., B. Trammell, Ed., P. Aitken Category : INTERNET STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG