From nobody Wed Oct 8 17:35:23 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 149FD1A8028 for ; Wed, 8 Oct 2014 17:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.668 X-Spam-Level: ** X-Spam-Status: No, score=2.668 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.982] 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 wq5HHYT3Oxr2 for ; Wed, 8 Oct 2014 17:35:20 -0700 (PDT) Received: from minorthreat.org (ec2-54-68-221-247.us-west-2.compute.amazonaws.com [54.68.221.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338921A87AE for ; Wed, 8 Oct 2014 17:35:17 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by minorthreat.org (8.14.9/8.14.9) with ESMTP id s990YuNl053128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 9 Oct 2014 00:34:57 GMT (envelope-from joelja@bogus.com) Message-ID: <5435D840.1090108@bogus.com> Date: Wed, 08 Oct 2014 17:35:12 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: "ipfix-chairs@tools.ietf.org" , IPFIX Working Group Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XBOI8pJ80hprGOJA30TK571QvtKC5mPUX" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/1ChI5URDo07Mpsf59pi24qBvFUQ Subject: [IPFIX] Considering the circumstances under which we wind 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: Thu, 09 Oct 2014 00:35:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XBOI8pJ80hprGOJA30TK571QvtKC5mPUX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Gentle-people, Benoit and i have been discussing the status of the IPFIX with respect to our charter-items and milestones. We are approaching the point where were should consider when to declare victory and wind down the working ground activity, or look at alternative scenarios. As it stands it looks we're in pretty code shape. At this point, we have one outstanding working group document. draft-ietf-ipfix-mib-variable-export and two potentially ipfix related documents with respect to the former I am confident that we can get adequate review for the document either through this mailing list or the opsawg depending on the timeline and willingness of the authors. I would have no trouble sponsoring the document. I would like to hear the thoughts of the chairs and other participants about where we think this should go. Thanks joel --XBOI8pJ80hprGOJA30TK571QvtKC5mPUX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlQ12EAACgkQ8AA1q7Z/VrIVpACdHtDu3Pl0YIyGXRTYMXaqZEjN pWAAnRMU0vdIhJ7XPB00yNKSJhMNG8rw =RUV2 -----END PGP SIGNATURE----- --XBOI8pJ80hprGOJA30TK571QvtKC5mPUX-- From nobody Wed Oct 8 19:11:20 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 1353C1A8A01 for ; Wed, 8 Oct 2014 19:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.591 X-Spam-Level: X-Spam-Status: No, score=-7.591 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, TVD_FW_GRAPHIC_NAME_MID=0.095] 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 64ibZa0yj6xd for ; Wed, 8 Oct 2014 19:11:14 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B0CF1A8A10 for ; Wed, 8 Oct 2014 19:11:14 -0700 (PDT) Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 8 Oct 2014 22:11:13 -0400 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 8 Oct 2014 22:11:10 -0400 Received: from b01cxnp22034.gho.pok.ibm.com (b01cxnp22034.gho.pok.ibm.com [9.57.198.24]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id C93936E804A; Wed, 8 Oct 2014 21:59:53 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by b01cxnp22034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s992B1Ox8651026; Thu, 9 Oct 2014 02:11:09 GMT Received: from d01av05.pok.ibm.com (localhost [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s992AaJJ019553; Wed, 8 Oct 2014 22:10:36 -0400 Received: from d01ml263.pok.ibm.com (d01ml263.pok.ibm.com [9.63.8.130]) by d01av05.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s992AaBS019126; Wed, 8 Oct 2014 22:10:36 -0400 In-Reply-To: <5435D840.1090108@bogus.com> References: <5435D840.1090108@bogus.com> X-KeepSent: C95ECD06:F38EA63B-85257D6C:000B8807; type=4; name=$KeepSent To: IPFIX Working Group , "IPFIX" , "ipfix-chairs@tools.ietf.org" X-Mailer: IBM Notes Release 9.0.1 October 14, 2013 Message-ID: From: Wayne Tackabury Date: Wed, 8 Oct 2014 22:10:11 -0400 X-MIMETrack: Serialize by Router on D01ML263/01/M/IBM(Release 9.0.1FP1|April 03, 2014) at 10/08/2014 22:10:37 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBF7FFDF980E978f9e8a93df938690918c0ABBF7FFDF980E97" X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14100902-0025-0000-0000-000000B3EEB2 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/iMzESqf6wo7TYSFH8p7T-8Tnozk Subject: Re: [IPFIX] Considering the circumstances under which we wind 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: Thu, 09 Oct 2014 02:11:18 -0000 --0__=0ABBF7FFDF980E978f9e8a93df938690918c0ABBF7FFDF980E97 Content-type: multipart/alternative; Boundary="1__=0ABBF7FFDF980E978f9e8a93df938690918c0ABBF7FFDF980E97" --1__=0ABBF7FFDF980E978f9e8a93df938690918c0ABBF7FFDF980E97 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Hi Joel: While I have nothing to weigh in on with the residual working group document (that all sounds reasonable), from the sounds of it, we can definitively answer a question I'd asked on the list a while back and hadn't heard back on....namely, that we can count on there not being wg= meeting needs at future IETF's. (as a matter of general course, anyway= s.) Let me know if that's not a correct assumption. :) Regards, Wayne Tackabury IBM Security Software Group From: joel jaeggli To: "ipfix-chairs@tools.ietf.org" , IPFIX Working Group Date: 10/08/2014 08:35 PM Subject: [IPFIX] Considering the circumstances under which we wind down= the ipfix working group. Sent by: "IPFIX" Gentle-people, Benoit and i have been discussing the status of the IPFIX with respect to our charter-items and milestones. We are approaching the point where= were should consider when to declare victory and wind down the working ground activity, or look at alternative scenarios. As it stands it look= s we're in pretty code shape. At this point, we have one outstanding working group document. draft-ietf-ipfix-mib-variable-export and two potentially ipfix related documents with respect to the former I am confident that we can get adequate review for the document either through this mailing list or the opsawg= depending on the timeline and willingness of the authors. I would have= no trouble sponsoring the document. I would like to hear the thoughts of the chairs and other participants about where we think this should go. Thanks joel [attachment "signature.asc" deleted by Wayne Tackabury/Waltham/IBM] _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix = --1__=0ABBF7FFDF980E978f9e8a93df938690918c0ABBF7FFDF980E97 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Hi Joel:

While I have nothing to weigh in o= n with the residual working group document (that all sounds reasonable)= , from the sounds of it, we can definitively answer a question I'd aske= d on the list a while back and hadn't heard back on....namely, that we = can count on there not being wg meeting needs at future IETF's.  (= as a matter of general course, anyways.)

Let me know if that's not a correc= t assumption. :)

Regards,
Wayne Tackabury
IBM Security Software Group=

3D"Inactivejoel jaeggli ---10/08/2014 08:35:31 PM---Gentle-people, Beno= it and i have been discussing the status of the IPFIX with respect

From: joel jaeggli <joelja@bogus.com>=
To: "ipfix-chairs@tools.ietf.org"= <ipfix-chairs@tools.ietf.org>, IPFIX Working Group <ipfix@iet= f.org>
Date: 10/08/2014 08:35 PM
Subject: = [IPFIX] Considering the circumstan= ces under which we wind down the ipfix working group.
Sent by: = "IPFIX" <ipfix-bounce= s@ietf.org>




Gentle-people,

Benoit and i have been discussing the status of the IPFIX with respect<= br> to our charter-items and milestones. We are approaching the point where=
were should consider when to declare victory and wind down the working<= br> ground activity, or look at alternative scenarios. As it stands it look= s
we're in pretty code shape.

At this point, we have one outstanding working group document.

draft-ietf-ipfix-mib-variable-export

and two potentially ipfix related documents

with respect to the former I am confident that we can get adequate
review for the  document either through this mailing list or the o= psawg
depending on the timeline  and willingness of the authors. I would= have
no trouble sponsoring the document.

I would like to hear the thoughts of the chairs and other participants<= br> about where we think this should go.

Thanks
joel

[attachment "signature.asc" deleted by Wayne Tackabury/Waltha= m/IBM] _______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

= --1__=0ABBF7FFDF980E978f9e8a93df938690918c0ABBF7FFDF980E97-- --0__=0ABBF7FFDF980E978f9e8a93df938690918c0ABBF7FFDF980E97 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBF7FFDF980E978f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF7FFDF980E978f9e8a93df938690918c0ABBF7FFDF980E97-- From nobody Sun Oct 12 15:10:39 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 CA92D1A9110 for ; Sun, 12 Oct 2014 15:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.687 X-Spam-Level: X-Spam-Status: No, score=-3.687 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 BONGNUrQfFVM for ; Sun, 12 Oct 2014 15:10:34 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A9911A910E for ; Sun, 12 Oct 2014 15:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1413151834; x=1444687834; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=p3GjXxtVMV/NYoAN/iOgbiBLMWUAlZnPyzHJbs1+YtE=; b=Docg4cx0hvRqZhe6jMrtDycV0bVrVkWIh9h9Dxuajza7970e5MYxMoX4 vcWXWf1mwP6nGX3eTv1FzSRFsomyD2Bf6BW/D9MuHaaQaGee8LaNLSFS6 0fl4cr9EOfsEFqUU+374RkRq1DbN6qGdfDTPiLY1R22EB9P2eTrg6xS3o 4=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="282536000" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 13 Oct 2014 11:10:30 +1300 Message-ID: <543AFC55.8030009@auckland.ac.nz> Date: Mon, 13 Oct 2014 11:10:29 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: draft-ietf-ipfix-mib-variable-export@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/VsRNeorOHrsgTm9eBE7943o2ktw Cc: IPFIX Working Group Subject: [IPFIX] What's the current state of draft-ietf-ipfix-mib-variable-export 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, 12 Oct 2014 22:10:37 -0000 Hi Paul, Colin and Benoit: Draft cutoff date for IETF 91 is 27 October, i.e. real soon now. Brian Trammell posted a partial review of it back on 15 August - are you likely to publish a new version before 27 October? Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From nobody Mon Oct 13 08:12:32 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 7F4BC1A1A5C for ; Mon, 13 Oct 2014 04:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 Sih8n6u_uTag for ; Mon, 13 Oct 2014 04:24:53 -0700 (PDT) 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 27A5E1A1ADC for ; Mon, 13 Oct 2014 04:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=339; q=dns/txt; s=iport; t=1413199493; x=1414409093; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1P4nKwx16DeAIZeA2nq0tn/CnaF/tTYlyufChgmJ/Tc=; b=CCL53t5htQI2qw5OY8XEL09tnrVfa9s2zjw7cYGkO4lcrXrm9fPSiFlG ItZL5Vn3nrKPCNxuwqAbDt8YtA2S1jt+QZZXmkQErpAmOnyk9oVP1a+Fk CwfX0G/QgOrfGpZzG1V74S75cNl4POCt3WX5JB+U35joU5YXm5ZgbEKO4 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAOK1O1StJssW/2dsb2JhbABbDtN8gyECgTIBfYQDAQEEOEABEAsOCgkWDwkDAgECAUUGAQwBBwEBiDrEFwEBAQEBAQEBAQEBAQEBAQEBAQEBGJBFB4RLAQSdS4dmjiuDN0E8gnkBAQE X-IronPort-AV: E=Sophos;i="5.04,709,1406592000"; d="scan'208";a="209614836" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 13 Oct 2014 11:24:50 +0000 Received: from [10.147.1.29] (dhcp-10-147-1-29.cisco.com [10.147.1.29]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9DBOoU9027716; Mon, 13 Oct 2014 11:24:50 GMT Message-ID: <543BB683.1030301@cisco.com> Date: Mon, 13 Oct 2014 12:24:51 +0100 From: Paul Aitken 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: Nevil Brownlee , draft-ietf-ipfix-mib-variable-export@tools.ietf.org References: <543AFC55.8030009@auckland.ac.nz> In-Reply-To: <543AFC55.8030009@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/LkLewHtQpg5hVNV-ryL_6zHMXGE X-Mailman-Approved-At: Mon, 13 Oct 2014 08:12:21 -0700 Cc: IPFIX Working Group Subject: Re: [IPFIX] What's the current state of draft-ietf-ipfix-mib-variable-export 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, 13 Oct 2014 11:24:54 -0000 Yes, I will work on this. P. On 12/10/2014 23:10, Nevil Brownlee wrote: > > Hi Paul, Colin and Benoit: > > Draft cutoff date for IETF 91 is 27 October, i.e. real soon now. > Brian Trammell posted a partial review of it back on 15 August - are > you likely to publish a new version before 27 October? > > Cheers, Nevil > From nobody Wed Oct 15 06:44:51 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 1FD371A1A75 for ; Wed, 15 Oct 2014 06:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, 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 OxYRqNFr8tu4 for ; Wed, 15 Oct 2014 06:44:27 -0700 (PDT) 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 2693F1A6FCF for ; Wed, 15 Oct 2014 06:44:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EEAECAC1; Wed, 15 Oct 2014 15:44:20 +0200 (CEST) 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 xNiAjhHX5ob6; Wed, 15 Oct 2014 15:44:19 +0200 (CEST) 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, 15 Oct 2014 15:44:20 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C3F020035; Wed, 15 Oct 2014 15:44:20 +0200 (CEST) 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 81t6haeGFKpa; Wed, 15 Oct 2014 15:44:19 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0291420036; Wed, 15 Oct 2014 15:44:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 829782EF91E4; Wed, 15 Oct 2014 15:44:17 +0200 (CEST) Date: Wed, 15 Oct 2014 15:44:17 +0200 From: Juergen Schoenwaelder To: Nevil Brownlee Message-ID: <20141015134417.GC73924@elstar.local> Mail-Followup-To: Nevil Brownlee , draft-ietf-ipfix-mib-variable-export@tools.ietf.org, IPFIX Working Group References: <543AFC55.8030009@auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <543AFC55.8030009@auckland.ac.nz> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/NukSDkL-A_QuVXY94Wu-21U1Ck0 Cc: draft-ietf-ipfix-mib-variable-export@tools.ietf.org, IPFIX Working Group Subject: Re: [IPFIX] What's the current state of draft-ietf-ipfix-mib-variable-export 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, 15 Oct 2014 13:44:28 -0000 On Mon, Oct 13, 2014 at 11:10:29AM +1300, Nevil Brownlee wrote: > > Hi Paul, Colin and Benoit: > > Draft cutoff date for IETF 91 is 27 October, i.e. real soon now. > Brian Trammell posted a partial review of it back on 15 August - are you > likely to publish a new version before 27 October? > Nevial, I have to review this document (or an update should there be one soon) but this document is of low priority for me given the other things going on in the IETF in which I am involved. Time is finite. /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 Sat Oct 25 00:08:15 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 626911A6FFC for ; Sat, 25 Oct 2014 00:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 f0ebiRtWIakE for ; Sat, 25 Oct 2014 00:08:09 -0700 (PDT) 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 346351A7005 for ; Sat, 25 Oct 2014 00:08:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKX57928; Sat, 25 Oct 2014 07:08:07 +0000 (GMT) Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 25 Oct 2014 08:08:06 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.57]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.03.0158.001; Sat, 25 Oct 2014 15:07:51 +0800 From: "Hedanping (Ana)" To: "ipfix@ietf.org" Thread-Topic: New Version Notification for draft-fu-ipfix-network-security-00.txt Thread-Index: AQHP8B5wo0Ary2vA1kS5YXHM/WNia5xAYwzA Date: Sat, 25 Oct 2014 07:07:51 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D8E14CD@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/IS5Jm1yHI3BQxBEg7a2e2rprZAk Subject: [IPFIX] FW: New Version Notification for draft-fu-ipfix-network-security-00.txt 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, 25 Oct 2014 07:08:13 -0000 SGVsbG8gYWxsLA0KDQpXZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgdG8gZXh0ZW5kIElQRklYIElF cyBmb3Igb2JzZXJ2aW5nIG5ldHdvcmsgc2VjdXJpdHkgaXNzdWVzLg0KV2VsY29tZSB5b3VyIGZl ZWRiYWNrLg0KDQpUaGFua3MsDQoNCktpbmQgUmVnYXJkcw0KQW5hIChEYW5waW5nKQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFtt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVy IDI1LCAyMDE0IDI6MzkgUE0NClRvOiBIZWRhbnBpbmcgKEFuYSk7IFpoYW5nZGFjaGVuZyAoRGFj aGVuZyk7IEZ1dGlhbmZ1OyBaaGFuZ2RhY2hlbmcgKERhY2hlbmcpOyBGdXRpYW5mdTsgSGVkYW5w aW5nIChBbmEpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWZ1 LWlwZml4LW5ldHdvcmstc2VjdXJpdHktMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWZ1LWlwZml4LW5ldHdvcmstc2VjdXJpdHktMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IERhbnBpbmcgSGUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBv c2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtZnUtaXBmaXgtbmV0d29yay1zZWN1cml0eQ0KUmV2aXNp b246CTAwDQpUaXRsZToJCUlQRklYIEluZm9ybWF0aW9uIEVsZW1lbnRzIGZvciBpbnNwZWN0aW5n IG5ldHdvcmsgc2VjdXJpdHkgaXNzdWVzDQpEb2N1bWVudCBkYXRlOgkyMDE0LTEwLTI1DQpHcm91 cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMw0KVVJMOiAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZ1LWlwZml4LW5ldHdvcmst c2VjdXJpdHktMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtZnUtaXBmaXgtbmV0d29yay1zZWN1cml0eS8NCkh0bWxpemVkOiAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mdS1pcGZpeC1uZXR3b3JrLXNlY3Vy aXR5LTAwDQoNCg0KQWJzdHJhY3Q6DQogICBJUEZJWCBwcm90b2NvbCBoYXMgYmVlbiB1c2VkIHRv IGNhcnJ5IEluZm9ybWF0aW9uIEVsZW1lbnRzLCB3aGljaCBhcmUNCiAgIGRlZmluZWQgdG8gbWVh c3VyZSB0aGUgdHJhZmZpYyBpbmZvcm1hdGlvbiBhbmQgaW5mb3JtYXRpb24gcmVsYXRlZCB0bw0K ICAgdGhlIHRyYWZmaWMgb2JzZXJ2YXRpb24gcG9pbnQsIHRyYWZmaWMgbWV0ZXJpbmcgcHJvY2Vz cyBhbmQgdGhlDQogICBleHBvcnRpbmcgcHJvY2Vzcy4gIE5ldHdvcmsgb3IgZGV2aWNlIHN0YXR1 cyBhcmUgY2hlY2tlZCB0aHJvdWdoDQogICBhbmFseXNpbmcgbmVjY2Vzc2FyeSBvYnNlcnZlZCBp bmZvcm1hdGlvbi4gIEFsdGhvdWdoIG1vc3Qgb2YgdGhlDQogICBleGlzdGluZyBJbmZvcm1hdGlv biBFbGVtZW50cyBhcmUgdXNlZnVsIGZvciBuZXR3b3JrIHNlY3VyaXR5DQogICBpbnNwZWN0aW9u LCB0aGV5IGFyZSBzdGlsbCBub3Qgc3VmZmljaWVudCB0byBkZXRlcm1pbmUgdGhlIHJlYXNvbnMN CiAgIGJlaGluZCBvYnNlcnZlZCBldmVudHMgc3VjaCBhcyBmb3IgRERPUyBhdHRhY2ssIElDTVAg YXR0YWNrLCBhbmQNCiAgIGZyYWdtZW50IGF0dGFjay4gIFRvIGFsbG93IGFkbWluaXN0cmF0b3Jz IG1ha2luZyBlZmZlY3RpdmUgYW5kIHF1aWNrDQogICByZXNwb25zZSB0byB0aGUgYXR0YWNrcywg dGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSBzdGFuZGFyZA0KICAgSW5mb3JtYXRpb24gRWxlbWVu dHMgYW5kIGRlc2NyaWJlcyB0aGUgZm9ybWF0cyBmb3IgaW5zcGVjdGluZyBuZXR3b3JrDQogICBz ZWN1cml0eS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Sun Oct 26 08:47:37 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 513481A8985; Sun, 26 Oct 2014 08:47:35 -0700 (PDT) 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] 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 bhTAF-TXkfhw; Sun, 26 Oct 2014 08:47:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A141A8916; Sun, 26 Oct 2014 08:47:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141026154734.2431.93423.idtracker@ietfa.amsl.com> Date: Sun, 26 Oct 2014 08:47:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/su9p5LTTURawHiTUpDUmc7HXfC4 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-07.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 15:47:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Exporting MIB Variables using the IPFIX Protocol Authors : Paul Aitken Benoit Claise Colin McDowall Juergen Schoenwaelder Filename : draft-ietf-ipfix-mib-variable-export-07.txt Pages : 76 Date : 2014-10-26 Abstract: This document specifies a way to complement IPFIX Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing Management Information Base objects that are already fully specified. An IPFIX Options Template and method are specified, which are used to export the extra information required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-mib-variable-export/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-mib-variable-export-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 26 08:51:05 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 5034B1A8914 for ; Sun, 26 Oct 2014 08:51:03 -0700 (PDT) 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 HNtQyC5M9y5V for ; Sun, 26 Oct 2014 08:51:01 -0700 (PDT) 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 C6FD01A00CD for ; Sun, 26 Oct 2014 08:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7286; q=dns/txt; s=iport; t=1414338661; x=1415548261; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=IgVX4mD8wDeBGtCb68eSPNuPrK47J4XxAs7PubPmtIY=; b=L/W+YOst1AkqdnTD9T69DoE0EPl7NAMZX5AQW4GOxyaOHtlL8orleRQT 7GgUZ2YAY2unVCxuxosw/XRwlBxe2hfSXByIielX4oABxK6SBxMN7ta7n haM2OiU0WOUZ7KoRM3VTdtXpwRpQLVvva3pIeQm9gkitxK96OvfOdvpQp Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAAIXTVStJssW/2dsb2JhbABc2HwCgRwBfYQDAQEDATgzDQYLCw4TFg8JAwIBAgFFBgEMCAEBF4gdCcdcAQEBAQEBAQECAQEBAQEBAQEakQ+ESwEEj2mJKYRPgTGGOzuOB4N4PYJ6AQEB X-IronPort-AV: E=Sophos;i="5.04,790,1406592000"; d="scan'208";a="225314209" 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; 26 Oct 2014 15:50:59 +0000 Received: from [10.61.104.193] (dhcp-10-61-104-193.cisco.com [10.61.104.193]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9QFow0n010868; Sun, 26 Oct 2014 15:50:58 GMT Message-ID: <544D1861.4020702@cisco.com> Date: Sun, 26 Oct 2014 15:50:57 +0000 From: Paul Aitken 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: Brian Trammell , "ipfix@ietf.org Group" References: <9192668E-3CB8-4874-8FB0-520EE585048F@trammell.ch> In-Reply-To: <9192668E-3CB8-4874-8FB0-520EE585048F@trammell.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/3TmK7mYqRWwY3kvYJeDzBI0oPoU Subject: Re: [IPFIX] Partial review of 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: Sun, 26 Oct 2014 15:51:03 -0000 Brian, thanks for reviewing the draft. Feedback inline... > Greetings, all, > > I've taken a look at the MIB variable export draft; apologies for the lateness of this review. > > I am by no means an SNMP expert, and do not intend to become enough of one to be able to adequately review this document, so this review should be read with the caveat that I expect the document will receive adequate review from SNMP/SMI experts to catch any problems on that side of the fence. I've also therefore presumed that all unfamiliar terminology (e.g. "Conceptual Rows") is defined in the SNMP world. Juergen Schoenwaelder is a co-author of this draft as an SNMP expert for exactly these reasons. > The general approach -- using options data records to enhance template records on a per-information-element basis -- seems sound. Indexed MIB variables make this a bit more complicated than it otherwise would be but as far as I can tell the method for addressing this seems sound as well. > > I'm a little concerned by the complexity of the proposed solution. However, I can't really separate accidental from essential complexity because I don't have a feel for how much of it is necessary in order to bolt the SNMP data model onto the side of the IPFIX protocol. So I presume the authors have made some effort to define the least complicated way to do so. Recall that we proposed a couple of more complicated solutions in earlier versions of this draft; the current proposal is as straightforward and IPFIX compliant as we can make it. > Given the large scope, I'm also concerned about scope creep. It's implicit but not explicitly clear in section 2 that the primary goal of this document is (1) to allow the correlation of SNMP- and IPFIX-MP- sourced data by exporting them together and (2) to allow SNMP push data from SNMP-only devices to be more easily integrated into IPFIX-based collection infrastructures. Although this was already stated in the Abstract, I've added a clear list of goals to the end of section 1: Therefore the primary goals of this document are: o to specify a way to complement IPFIX Data Records with Management Information Base (MIB) objects; o to avoid the need to define new IPFIX Information Elements for existing Management Information Base objects that are already fully specified; o to allow the correlation of SNMP- and IPFIX-MP- sourced data by exporting them together; o to allow SNMP push data from SNMP-only devices to be more easily integrated into IPFIX-based collection infrastructures. > 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. Where existing IPFIX IEs have been already been created for MIBs, there will now be two ways to represent the exported data. It would be up to the metering or exporting process to decide which is the most appropriate. We can't mandate one over the other because existing exporters might prefer to use the IPFIX IEs while new devices exporting several MIBs would prefer not to be obliged to convert some of them into the equivalent IPFIX IEs. 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. Expressed another way, we've already created duplication; now we have to live with it. > The template management characteristics of the proposed mechanism still need some work as well. > > Section 5.7 should consider SCTP features for template management explicitly: that MIB Field Options Data Records MUST be exported reliably. MIB Field Options Data Records MUST also be exported on the same stream as the templates with which they are associated. Even though reliability is implied by the requirement to place a MIB Field ODR in the same Message with its associated Template. Thanks; I've clarified that in section 5.7: When exporting over an SCTP transport [RFC4960], the MIB Field Options Data Records MUST be exported reliably and in the same SCTP stream as their associated Templates. > This may cause problems with environments with restricted Message sizes (i.e., UDP transport over IPv4 with unknown path MTU (576), even UDP transport over non-Jumbo Ethernet (1460), as the MIB Field ODRs for a given template may be quite large. The document should provide guidance as to what to do in this case. If the Message exceeds the MTU then you're stuck. Exceptionally in the case of reliable SCTP transport we could allow the MIB Field Options Template, MIB Field Options Data, Data Template, and Data Records, to be exported individually in that order, so I've added a new section: 5.7.1. Large Messages The requirement to export the MIB Field Options Template and MIB Field Options Data Records in the same IPFIX Message as any (Option) Template Record that uses a mibObjectValue Information Element may result in very large IPFIX Messages. In environments with restricted Message sizes, and only when a reliable SCTP transport is being used, the MIB Field Options Template, MIB Field Options Data, Data Template, and Data Records, MAY be exported in separate Messages in the same SCTP stream, provided that their order is maintained. > Note also that over UDP this implies the MIB Field ODPs will need to be resent with every template. Given the side of MIB Field ODPs this may imply significantly increased overhead compared with RFC 7011 IPFIX. Indeed. > The document ignores template withdrawal and ID reuse. Personally, I'm okay with this feature being mutually exclusive with template withdrawal and ID reuse, because withdrawal and reuse are impossible to implement in a way that guarantees interoperability and unambiguous interpretation of data values when not used with a reliable or selectively-reliable transport, and significantly complicate template management in any case. But the document either needs to state that this feature may not be used with withdrawal and ID reuse, or needs to explain what happens to MIB Field ODP state when a template is withdrawn. I've added a new section 5.7.2 to cover this: 5.7.2. Template Withdrawal and Reuse Data Records containing mibObjectValue Information Elements MUST NOT be exported if their corresponding Data Template or MIB Field Options Template has been withdrawn, since the MIB Field Options Template MUST be exported in the same IPFIX Message as the Data Template which it annotates. MIB Field Options Template IDs MUST NOT be reused while they are required by any existing Data Templates. Thanks, P. From nobody Mon Oct 27 05:07:23 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 0F3A61A9163 for ; Mon, 27 Oct 2014 05:07:18 -0700 (PDT) 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 nYZRpKt8JEQE for ; Mon, 27 Oct 2014 05:07:13 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 07B2F1A914B for ; Mon, 27 Oct 2014 05:07:13 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::8] (unknown [IPv6:2001:67c:10ec:2a49:8000::8]) by trammell.ch (Postfix) with ESMTPSA id 6D48D1A00E2; Mon, 27 Oct 2014 13:07:11 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_6333185F-EDF9-4DD5-B25F-4653D1EFE156"; 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: <544D1861.4020702@cisco.com> Date: Mon, 27 Oct 2014 13:07:13 +0100 Message-Id: <3DC6B555-C109-47F3-9EE8-705CA999EC12@trammell.ch> References: <9192668E-3CB8-4874-8FB0-520EE585048F@trammell.ch> <544D1861.4020702@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/D4jMiDafyYSagjxwtmWiBQIQBuI Cc: "ipfix@ietf.org Group" Subject: Re: [IPFIX] Partial review of 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: Mon, 27 Oct 2014 12:07:18 -0000 --Apple-Mail=_6333185F-EDF9-4DD5-B25F-4653D1EFE156 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 26 Oct 2014, at 16:50, Paul Aitken wrote: > Brian, thanks for reviewing the draft. Feedback inline... >=20 >> Greetings, all, >>=20 >> I've taken a look at the MIB variable export draft; apologies for the = lateness of this review. >>=20 >> I am by no means an SNMP expert, and do not intend to become enough = of one to be able to adequately review this document, so this review = should be read with the caveat that I expect the document will receive = adequate review from SNMP/SMI experts to catch any problems on that side = of the fence. I've also therefore presumed that all unfamiliar = terminology (e.g. "Conceptual Rows") is defined in the SNMP world. >=20 > Juergen Schoenwaelder is a co-author of this draft as an SNMP expert = for exactly these reasons. >=20 >=20 >> The general approach -- using options data records to enhance = template records on a per-information-element basis -- seems sound. = Indexed MIB variables make this a bit more complicated than it otherwise = would be but as far as I can tell the method for addressing this seems = sound as well. >>=20 >> I'm a little concerned by the complexity of the proposed solution. = However, I can't really separate accidental from essential complexity = because I don't have a feel for how much of it is necessary in order to = bolt the SNMP data model onto the side of the IPFIX protocol. So I = presume the authors have made some effort to define the least = complicated way to do so. >=20 > Recall that we proposed a couple of more complicated solutions in = earlier versions of this draft; the current proposal is as = straightforward and IPFIX compliant as we can make it. Yep, I'm happy with this. Just reacting more to the complexity that = comes with indexing in MIB objects. >> Given the large scope, I'm also concerned about scope creep. It's = implicit but not explicitly clear in section 2 that the primary goal of = this document is (1) to allow the correlation of SNMP- and IPFIX-MP- = sourced data by exporting them together and (2) to allow SNMP push data = from SNMP-only devices to be more easily integrated into IPFIX-based = collection infrastructures. >=20 > Although this was already stated in the Abstract, I've added a clear = list of goals to the end of section 1: >=20 > Therefore the primary goals of this document are: >=20 > o to specify a way to complement IPFIX Data Records with Management > Information Base (MIB) objects; >=20 > o to avoid the need to define new IPFIX Information Elements for > existing Management Information Base objects that are already > fully specified; >=20 > o to allow the correlation of SNMP- and IPFIX-MP- sourced data by > exporting them together; >=20 > o to allow SNMP push data from SNMP-only devices to be more easily > integrated into IPFIX-based collection infrastructures. Thanks for moving this into the Intro as well, this addresses my = concern. >> 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. >=20 > The mechanism _can_ be used like that. Can be, yes. Is it the express intention of the authors of the draft to = do so? > Where existing IPFIX IEs have been already been created for MIBs, = there will now be two ways to represent the exported data. It would be = up to the metering or exporting process to decide which is the most = appropriate. We can't mandate one over the other because existing = exporters might prefer to use the IPFIX IEs while new devices exporting = several MIBs would prefer not to be obliged to convert some of them into = the equivalent IPFIX IEs. So I kind of get the intention here... > 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. > 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 >> The template management characteristics of the proposed mechanism = still need some work as well. >>=20 >> Section 5.7 should consider SCTP features for template management = explicitly: that MIB Field Options Data Records MUST be exported = reliably. MIB Field Options Data Records MUST also be exported on the = same stream as the templates with which they are associated. Even though = reliability is implied by the requirement to place a MIB Field ODR in = the same Message with its associated Template. >=20 > Thanks; I've clarified that in section 5.7: >=20 > When exporting over an SCTP transport [RFC4960], the MIB Field > Options Data Records MUST be exported reliably and in the same SCTP > stream as their associated Templates. Excellent, thanks. >> This may cause problems with environments with restricted Message = sizes (i.e., UDP transport over IPv4 with unknown path MTU (576), even = UDP transport over non-Jumbo Ethernet (1460), as the MIB Field ODRs for = a given template may be quite large. The document should provide = guidance as to what to do in this case. >=20 > If the Message exceeds the MTU then you're stuck. Exceptionally in the = case of reliable SCTP transport we could allow the MIB Field Options = Template, MIB Field Options Data, Data Template, and Data Records, to be = exported individually in that order, so I've added a new section: >=20 > 5.7.1. Large Messages >=20 > The requirement to export the MIB Field Options Template and MIB > Field Options Data Records in the same IPFIX Message as any (Option) > Template Record that uses a mibObjectValue Information Element may > result in very large IPFIX Messages. >=20 > In environments with restricted Message sizes, and only when a > reliable SCTP transport is being used, the MIB Field Options > Template, MIB Field Options Data, Data Template, and Data Records, > MAY be exported in separate Messages in the same SCTP stream, > provided that their order is maintained. Yep, looks good, thanks. >> Note also that over UDP this implies the MIB Field ODPs will need to = be resent with every template. Given the side of MIB Field ODPs this may = imply significantly increased overhead compared with RFC 7011 IPFIX. >=20 > Indeed. >=20 >=20 >> The document ignores template withdrawal and ID reuse. Personally, = I'm okay with this feature being mutually exclusive with template = withdrawal and ID reuse, because withdrawal and reuse are impossible to = implement in a way that guarantees interoperability and unambiguous = interpretation of data values when not used with a reliable or = selectively-reliable transport, and significantly complicate template = management in any case. But the document either needs to state that this = feature may not be used with withdrawal and ID reuse, or needs to = explain what happens to MIB Field ODP state when a template is = withdrawn. >=20 > I've added a new section 5.7.2 to cover this: >=20 > 5.7.2. Template Withdrawal and Reuse >=20 > Data Records containing mibObjectValue Information Elements MUST NOT > be exported if their corresponding Data Template or MIB Field = Options > Template has been withdrawn, since the MIB Field Options Template > MUST be exported in the same IPFIX Message as the Data Template = which > it annotates. >=20 > MIB Field Options Template IDs MUST NOT be reused while they are > required by any existing Data Templates. Thanks. Cheers, Brian --Apple-Mail=_6333185F-EDF9-4DD5-B25F-4653D1EFE156 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 iQEcBAEBCgAGBQJUTjVxAAoJENt3nsOmbNJcUgkH/jlUByXuL069KMPlNvzW6OA/ UdSbu1S+9nJO+sOb2Z9B+kK249pPbAAR7Dgj12Mys7yy7WcBI0PzDi0S+U1MGs0a OiAJNRMPG9amXeZbCpGQCu950TJ7Lmb6Yne7+ZPWTcYUjiK2PwuX0NdegPmMSTeB cMwH7Vj1GiQRbu2+rAmujEbhzesGy3TLgXRNFs5i0TSFjqo2VT2kZLsFMAP1/fNf YRq24u8GyX7C/B13iwldnp/fOOGrCgSzYIJOzs6aHQAtY7aErXnXjKcydvbUdYEL V+cTXYZ3vLHljTb7Rzw3UR980WbLsUw/hdJusZQl3uBDqbpB8UVLdOlhwyaikQU= =Gfi8 -----END PGP SIGNATURE----- --Apple-Mail=_6333185F-EDF9-4DD5-B25F-4653D1EFE156-- From nobody Mon Oct 27 05:37: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 6121B1A9100 for ; Mon, 27 Oct 2014 05:36:58 -0700 (PDT) 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 k1GpQO-BHcSM for ; Mon, 27 Oct 2014 05:36:57 -0700 (PDT) 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 34A121A90EA for ; Mon, 27 Oct 2014 05:36:57 -0700 (PDT) Received: from PLXRDC01.plxr.local ([::1]) by PLXRDC01.plxr.local ([::1]) with mapi id 14.03.0210.002; Mon, 27 Oct 2014 08:36:41 -0400 From: Rocco Caputo To: Brian Trammell Thread-Topic: [IPFIX] Partial review of draft-ietf-ipfix-mib-variable-export-06 Thread-Index: AQHP8TSw+BlgxZ5aRkeiHjRk5kw5qJxEHbqAgAAISwA= Date: Mon, 27 Oct 2014 12:36:41 +0000 Message-ID: <00BF608C-14A4-4989-9F7E-DAB83745431F@plixer.com> References: <9192668E-3CB8-4874-8FB0-520EE585048F@trammell.ch> <544D1861.4020702@cisco.com> <3DC6B555-C109-47F3-9EE8-705CA999EC12@trammell.ch> In-Reply-To: <3DC6B555-C109-47F3-9EE8-705CA999EC12@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.179.11.69] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1733D1EDF080FE4E88A028D0C4886B24@plixer.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/KGfEl0DVMzYgYM3XbqA6wTW47AY Cc: Paul Aitken , "ipfix@ietf.org Group" Subject: Re: [IPFIX] Partial review of 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: Mon, 27 Oct 2014 12:36:58 -0000 > On Oct 27, 2014, at 08:07, Brian Trammell wrote: >=20 >=20 > On 26 Oct 2014, at 16:50, Paul Aitken wrote: >=20 >> Collectors should understand the equivalence and map the IPFIX IE and th= e MIB object to the same internal entity, so there should be no difficultly= in comparing or combining data. >=20 > ...but it strikes me as a little unkind to publish this document as a "yo= u can do this, collectors will handle the mess" without at least an appendi= x linking IEs in the present IANA registry to commonly-used MIB objects. Bu= t I'll step back and let people who write collectors for customers other th= an themselves comment on this statement. Collector processes are under constant pressure to scale higher. As descri= bed here, the mapping seems to centralize a burden that could remain distri= buted. It also seems that exporters can statically map the data they're co= nfigured to export, while collectors developed for heterogeneous enterprise= -scale environments must dynamically be capable of handling everything the = protocol can provide. --=20 Rocco Caputo = From nobody Thu Oct 30 07:02:50 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 D1E611AD3B0 for ; Thu, 30 Oct 2014 07:02:46 -0700 (PDT) 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 sdY95kiMX8fR for ; Thu, 30 Oct 2014 07:02:38 -0700 (PDT) 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 0206C1AD378 for ; Thu, 30 Oct 2014 07:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8815; q=dns/txt; s=iport; t=1414677702; x=1415887302; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=585gRnRNs9l7ktrp5PII9L82VEUorEmFu/msvKk7uKk=; b=Ijrdc8NJPkPbyKOR0qYQYwPJDoJqZhDL63P49BZZOr5G4nBM8e1zlUkl q3SY6u4eE2KTnPhOPI0kQyYUFIWmWnSNjIcldkurFasik2+BptItxchMU dAKoozRFeLIgetCnAD3jDL5LxoRUfyUOZS+QQL6OL5tctPK8iQORVwqn7 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkEAL5DUlStJssW/2dsb2JhbABchDrVJwKBOAEBAQEBfYQCAQEBAwE4Mw0BBQsLDgoJFg8JAwIBAgFFBg0BBQIBAReIHQnJUwEBAQEBAQEDAQEBAQEBAQEBARiREAeESwEEmRqEUIExhj47jhWDeD0vgksBAQE X-IronPort-AV: E=Sophos;i="5.07,286,1413244800"; d="scan'208";a="226225373" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 30 Oct 2014 14:01:39 +0000 Received: from [10.61.109.115] (dhcp-10-61-109-115.cisco.com [10.61.109.115]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9UE1c9e026401; Thu, 30 Oct 2014 14:01:38 GMT Message-ID: <545244C1.6020801@cisco.com> Date: Thu, 30 Oct 2014 14:01:37 +0000 From: Paul Aitken 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: Brian Trammell References: <9192668E-3CB8-4874-8FB0-520EE585048F@trammell.ch> <544D1861.4020702@cisco.com> <3DC6B555-C109-47F3-9EE8-705CA999EC12@trammell.ch> In-Reply-To: <3DC6B555-C109-47F3-9EE8-705CA999EC12@trammell.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/RLijPM-3616mwKXWMEgIlcPye3Y Cc: "ipfix@ietf.org Group" Subject: Re: [IPFIX] Partial review of 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: Thu, 30 Oct 2014 14:02:47 -0000 Brian, > On 26 Oct 2014, at 16:50, Paul Aitken wrote: > >> Brian, thanks for reviewing the draft. Feedback inline... >> >>> Greetings, all, >>> >>> I've taken a look at the MIB variable export draft; apologies for the lateness of this review. >>> >>> I am by no means an SNMP expert, and do not intend to become enough of one to be able to adequately review this document, so this review should be read with the caveat that I expect the document will receive adequate review from SNMP/SMI experts to catch any problems on that side of the fence. I've also therefore presumed that all unfamiliar terminology (e.g. "Conceptual Rows") is defined in the SNMP world. >> Juergen Schoenwaelder is a co-author of this draft as an SNMP expert for exactly these reasons. >> >> >>> The general approach -- using options data records to enhance template records on a per-information-element basis -- seems sound. Indexed MIB variables make this a bit more complicated than it otherwise would be but as far as I can tell the method for addressing this seems sound as well. >>> >>> I'm a little concerned by the complexity of the proposed solution. However, I can't really separate accidental from essential complexity because I don't have a feel for how much of it is necessary in order to bolt the SNMP data model onto the side of the IPFIX protocol. So I presume the authors have made some effort to define the least complicated way to do so. >> Recall that we proposed a couple of more complicated solutions in earlier versions of this draft; the current proposal is as straightforward and IPFIX compliant as we can make it. > Yep, I'm happy with this. Just reacting more to the complexity that comes with indexing in MIB objects. > >>> Given the large scope, I'm also concerned about scope creep. It's implicit but not explicitly clear in section 2 that the primary goal of this document is (1) to allow the correlation of SNMP- and IPFIX-MP- sourced data by exporting them together and (2) to allow SNMP push data from SNMP-only devices to be more easily integrated into IPFIX-based collection infrastructures. >> Although this was already stated in the Abstract, I've added a clear list of goals to the end of section 1: >> >> Therefore the primary goals of this document are: >> >> o to specify a way to complement IPFIX Data Records with Management >> Information Base (MIB) objects; >> >> o to avoid the need to define new IPFIX Information Elements for >> existing Management Information Base objects that are already >> fully specified; >> >> o to allow the correlation of SNMP- and IPFIX-MP- sourced data by >> exporting them together; >> >> o to allow SNMP push data from SNMP-only devices to be more easily >> integrated into IPFIX-based collection infrastructures. > Thanks for moving this into the Intro as well, this addresses my concern. > >>> 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? >> Where existing IPFIX IEs have been already been created for MIBs, there will now be two ways to represent the exported data. It would be up to the metering or exporting process to decide which is the most appropriate. We can't mandate one over the other because existing exporters might prefer to use the IPFIX IEs while new devices exporting several MIBs would prefer not to be obliged to convert some of them into the equivalent IPFIX IEs. > So I kind of get the intention here... > >> 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. If the WG wants an appendix, then it should be straightforward to add one. Unfortunately I'm pressed for time before the current meeting, so I can't do it immediately. >> 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? Thanks, P. >>> The template management characteristics of the proposed mechanism still need some work as well. >>> >>> Section 5.7 should consider SCTP features for template management explicitly: that MIB Field Options Data Records MUST be exported reliably. MIB Field Options Data Records MUST also be exported on the same stream as the templates with which they are associated. Even though reliability is implied by the requirement to place a MIB Field ODR in the same Message with its associated Template. >> Thanks; I've clarified that in section 5.7: >> >> When exporting over an SCTP transport [RFC4960], the MIB Field >> Options Data Records MUST be exported reliably and in the same SCTP >> stream as their associated Templates. > Excellent, thanks. > >>> This may cause problems with environments with restricted Message sizes (i.e., UDP transport over IPv4 with unknown path MTU (576), even UDP transport over non-Jumbo Ethernet (1460), as the MIB Field ODRs for a given template may be quite large. The document should provide guidance as to what to do in this case. >> If the Message exceeds the MTU then you're stuck. Exceptionally in the case of reliable SCTP transport we could allow the MIB Field Options Template, MIB Field Options Data, Data Template, and Data Records, to be exported individually in that order, so I've added a new section: >> >> 5.7.1. Large Messages >> >> The requirement to export the MIB Field Options Template and MIB >> Field Options Data Records in the same IPFIX Message as any (Option) >> Template Record that uses a mibObjectValue Information Element may >> result in very large IPFIX Messages. >> >> In environments with restricted Message sizes, and only when a >> reliable SCTP transport is being used, the MIB Field Options >> Template, MIB Field Options Data, Data Template, and Data Records, >> MAY be exported in separate Messages in the same SCTP stream, >> provided that their order is maintained. > Yep, looks good, thanks. > >>> Note also that over UDP this implies the MIB Field ODPs will need to be resent with every template. Given the side of MIB Field ODPs this may imply significantly increased overhead compared with RFC 7011 IPFIX. >> Indeed. >> >> >>> The document ignores template withdrawal and ID reuse. Personally, I'm okay with this feature being mutually exclusive with template withdrawal and ID reuse, because withdrawal and reuse are impossible to implement in a way that guarantees interoperability and unambiguous interpretation of data values when not used with a reliable or selectively-reliable transport, and significantly complicate template management in any case. But the document either needs to state that this feature may not be used with withdrawal and ID reuse, or needs to explain what happens to MIB Field ODP state when a template is withdrawn. >> I've added a new section 5.7.2 to cover this: >> >> 5.7.2. Template Withdrawal and Reuse >> >> Data Records containing mibObjectValue Information Elements MUST NOT >> be exported if their corresponding Data Template or MIB Field Options >> Template has been withdrawn, since the MIB Field Options Template >> MUST be exported in the same IPFIX Message as the Data Template which >> it annotates. >> >> MIB Field Options Template IDs MUST NOT be reused while they are >> required by any existing Data Templates. > Thanks. > > Cheers, > > Brian >