From nobody Mon Apr 7 01:39:45 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 319CF1A02C0 for ; Mon, 7 Apr 2014 01:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 tgoj9xYai91v for ; Mon, 7 Apr 2014 01:39:37 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFC61A00FB for ; Mon, 7 Apr 2014 01:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=104; q=dns/txt; s=iport; t=1396859970; x=1398069570; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=7amDtUuvfbttWQqbcl+9JRcgcB0SvlVsMONEnzK3Wis=; b=WHfQDQtU/q0c6Jz4CWgltbub2ue8KQbcpRt4jGfCgenfKzX2Kv3ZgZv7 jEoNWQ0OpCo2c4fC5ckgiECtRFcEqI47WQIelRaqOIxhIMSd0G6exAf+E YPNupw8Dd5eP3+YyZ9L8j0wkBVUkqpPFEi2NXogvkXWjdQkeFcEuzgI1s A=; X-IronPort-AV: E=Sophos;i="4.97,808,1389744000"; d="scan'208";a="9717281" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-4.cisco.com with ESMTP; 07 Apr 2014 08:39:29 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s378dSWb010961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Apr 2014 08:39:29 GMT Received: from [10.147.1.9] (dhcp-10-147-1-9.cisco.com [10.147.1.9]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s378dQgn025414; Mon, 7 Apr 2014 09:39:27 +0100 (BST) Message-ID: <53426443.5020609@cisco.com> Date: Mon, 07 Apr 2014 09:39:31 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "ipfix-chairs@tools.ietf.org" , IETF IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/QeJEklaIMLCSRmpSQ42Gvs7xHCc Subject: [IPFIX] WGLC for 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, 07 Apr 2014 08:39:42 -0000 IPFIX chairs, when will you start the WGLC for draft-ietf-ipfix-mib-variable-export ? Thanks, P. From nobody Mon Apr 7 14:21:57 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 A581A1A02CD for ; Mon, 7 Apr 2014 14:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.112 X-Spam-Level: X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 1xPHsWN1zKAA for ; Mon, 7 Apr 2014 14:21:42 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id B31131A0656 for ; Mon, 7 Apr 2014 14:21:25 -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=1396905681; x=1428441681; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=OhF6obuo9l5C7iRxFMVgn9qLi+gn9+EN2yG8xZLgDsI=; b=BTmu0kFwbuMCcWbW7tAOzIRON7X1BSnrQ4ZGnV8/1GJLZEEFCatYWPlt SP0Z023sPLztE4foIklAQKCnCwBkoPC5wk9N1KmrTZlekToJRmtSWBHMS n7+jIH6Pem5lIOpWdspZFNbAtxZnEqrh6ZbUwX5XjuOzpBNvMhxLnGLD1 o=; X-IronPort-AV: E=Sophos;i="4.97,813,1389697200"; d="scan'208";a="245929469" 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; 08 Apr 2014 09:21:14 +1200 Message-ID: <534316C9.5040304@auckland.ac.nz> Date: Tue, 08 Apr 2014 09:21:13 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Paul Aitken , "ipfix-chairs@tools.ietf.org" , IETF IPFIX Working Group References: <53426443.5020609@cisco.com> In-Reply-To: <53426443.5020609@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/C8k2-D-WLCadWV4MWeZim5tl47w Subject: Re: [IPFIX] WGLC for 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, 07 Apr 2014 21:21:51 -0000 Hi Paul: WGLC for the MIB Variables draft closed last week. I'm waiting for a few expected reviews so I can do its write-up and submit it to IESG. Cheers, Nevil On 7/04/14 8:39 PM, Paul Aitken wrote: > IPFIX chairs, when will you start the WGLC for > draft-ietf-ipfix-mib-variable-export ? > > Thanks, > P. > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- --------------------------------------------------------------------- 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 Apr 14 08:58:59 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 AA0331A0535 for ; Mon, 14 Apr 2014 08:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 kMN-oTLrbSA9 for ; Mon, 14 Apr 2014 08:58:54 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9435F1A01C8 for ; Mon, 14 Apr 2014 08:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=665; q=dns/txt; s=iport; t=1397491132; x=1398700732; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=zOLjQI+YLYdiHlvOX6n0WJpswkXQFixQ7/TxoBrFLs8=; b=BtVxj/jAK8oauYY/T7HeCT2QiA8ZKXJuh3fj+BS6m2aoaTOpx0tHSpw5 JqVo5CL+6gDq9fUGZZyN5NNmwfE6nUE8caL4se+UcuH5YyPPcVPD/enYD QRthqT+KfS6wT50m5bIEIJHsHrkbxgbZsCF9ECg47m4pReujgWOSve5Nv k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAHIETFOQ/khL/2dsb2JhbABZDoJ4O7xEhzWBJBZ0giUBAQEEAQEBNTYKEQsOCgkWDwkDAgECARUwBgEMBgIBAYd4DctKEwSOdYQ4AQOYYYZUi2+CcUE X-IronPort-AV: E=Sophos;i="4.97,857,1389744000"; d="scan'208";a="13257542" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-3.cisco.com with ESMTP; 14 Apr 2014 15:58:51 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3EFwo9R003769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2014 15:58:51 GMT Received: from [10.61.103.182] (dhcp-10-61-103-182.cisco.com [10.61.103.182]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s3EFwjfn011089; Mon, 14 Apr 2014 16:58:46 +0100 (BST) Message-ID: <534C05B5.2080502@cisco.com> Date: Mon, 14 Apr 2014 16:58:45 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nevil Brownlee , "ipfix-chairs@tools.ietf.org" , IETF IPFIX Working Group References: <53426443.5020609@cisco.com> <534316C9.5040304@auckland.ac.nz> In-Reply-To: <534316C9.5040304@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/xtAhmyR5_WaGy3ngw3NrKL7zLWc Subject: Re: [IPFIX] WGLC for 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, 14 Apr 2014 15:58:57 -0000 Nevil, when was the WGLC announced? I don't see it in in my email, nor in the IPFIX WG archive. Thanks, P. On 07/04/2014 22:21, Nevil Brownlee wrote: > > Hi Paul: > > WGLC for the MIB Variables draft closed last week. I'm waiting > for a few expected reviews so I can do its write-up and submit it > to IESG. > > Cheers, Nevil > > > On 7/04/14 8:39 PM, Paul Aitken wrote: >> IPFIX chairs, when will you start the WGLC for >> draft-ietf-ipfix-mib-variable-export ? >> >> Thanks, >> P. >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > From nobody Mon Apr 14 09:07:22 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 A2D661A0515; Mon, 14 Apr 2014 09:07:20 -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 XSho1G8BnJ4R; Mon, 14 Apr 2014 09:07:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB111A02CB; Mon, 14 Apr 2014 09:07:19 -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.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140414160719.436.50928.idtracker@ietfa.amsl.com> Date: Mon, 14 Apr 2014 09:07:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/MFge98kim9mGnxpSPUUy5LFHkkQ Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-03.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: Mon, 14 Apr 2014 16:07:20 -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 : Textual Representation of IPFIX Abstract Data Types Author : Brian Trammell Filename : draft-ietf-ipfix-text-adt-03.txt Pages : 13 Date : 2014-04-14 Abstract: This document defines UTF-8 representations for IPFIX abstract data types, to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-text-adt-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-text-adt-03 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 Mon Apr 14 17:01: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 651B71A0692 for ; Mon, 14 Apr 2014 17:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.427 X-Spam-Level: X-Spam-Status: No, score=0.427 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 x6GMJIlDGG2S for ; Mon, 14 Apr 2014 17:01:15 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 963201A0686 for ; Mon, 14 Apr 2014 17:01:15 -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=1397520073; x=1429056073; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=UePzvoMY403vEmZ/LsTrZ27lj2zASx9x18P7oHR4jtw=; b=DiVT1wlpkxWw1JdJSgxNZw07qAI1E7jE4iKRnMxlN53IW3nJ/LQieUxy heF4R3VauJ6qJmTWZWPJrfuJnoVOEcHkj9w9Lj0QDzDx1c6ZC492D5F/6 N7y4A89sTIL9Cm9KYVN/92JOa8JWvqPRHGbkh32l3f8n65+XMIXf1FyDl s=; X-IronPort-AV: E=Sophos;i="4.97,860,1389697200"; d="scan'208";a="247347866" 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; 15 Apr 2014 12:01:12 +1200 Message-ID: <534C76C7.9030108@auckland.ac.nz> Date: Tue, 15 Apr 2014 12:01:11 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/2rU_dI3bw7RSIxUehWeSUf0WtwU Subject: [IPFIX] WGLC for draft-ietf-ipfix-mib-variable-export-05 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: Tue, 15 Apr 2014 00:01:20 -0000 Hi all: Sorry to be a little slow with this - the dust has settled from IETF-89, and I've almost managed to catch up. The WG Last Call for our MIB Variable Export draft starts now, and will end on Wednesday, 30 April. Please read it, and - better still - post reviews of it to the IPFIX list! Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From nobody Wed Apr 16 08:23: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 C6C4A1A01BB; Wed, 16 Apr 2014 08:23:38 -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 E1NibqwPO86r; Wed, 16 Apr 2014 08:23:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A782A1A017C; Wed, 16 Apr 2014 08:23:37 -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.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140416152337.29887.23.idtracker@ietfa.amsl.com> Date: Wed, 16 Apr 2014 08:23:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/gSHTqvRLx8O1W6ntSZpZACKpFI0 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-04.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: Wed, 16 Apr 2014 15:23:39 -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 : Textual Representation of IPFIX Abstract Data Types Author : Brian Trammell Filename : draft-ietf-ipfix-text-adt-04.txt Pages : 13 Date : 2014-04-16 Abstract: This document defines UTF-8 representations for IPFIX abstract data types, to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-text-adt-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-text-adt-04 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 Fri Apr 18 09:21: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 5E4511A0222 for ; Fri, 18 Apr 2014 09:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] 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 rfe7mfEtRw46 for ; Fri, 18 Apr 2014 09:21:32 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id E93C31A013F for ; Fri, 18 Apr 2014 09:21:31 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 680CB1084; Fri, 18 Apr 2014 18:21:26 +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 LSnuWJ4Zi4CD; Fri, 18 Apr 2014 18:21:24 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 18 Apr 2014 18:21:24 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20BAA2002C; Fri, 18 Apr 2014 18:21:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id V-izdI47RuB1; Fri, 18 Apr 2014 18:21:20 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A44920013; Fri, 18 Apr 2014 18:21:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 35BE22C8EA78; Fri, 18 Apr 2014 18:21:17 +0200 (CEST) Date: Fri, 18 Apr 2014 18:21:17 +0200 From: Juergen Schoenwaelder To: Nevil Brownlee Message-ID: <20140418162115.GA3046@elstar.local> Mail-Followup-To: Nevil Brownlee , IPFIX Working Group References: <534C76C7.9030108@auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534C76C7.9030108@auckland.ac.nz> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/qKP9zZZqrMkaskherdxPsviWaB4 Cc: IPFIX Working Group Subject: Re: [IPFIX] WGLC for draft-ietf-ipfix-mib-variable-export-05 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: Fri, 18 Apr 2014 16:21:37 -0000 On Tue, Apr 15, 2014 at 12:01:11PM +1200, Nevil Brownlee wrote: > > Hi all: > > Sorry to be a little slow with this - the dust has settled from IETF-89, > and I've almost managed to catch up. > > The WG Last Call for our MIB Variable Export draft starts now, > and will end on Wednesday, 30 April. > > Please read it, and - better still - post reviews of it to the IPFIX list! > I have reviewed the document and I believe it is not ready. The main points: - Terminology needs to be aligned with SMIv2 - I spotted several errors in the examples - Major issues with the IE definitions in section 10 - I also believe the introductionary text needs to improve. /js I have reviewed draft-ietf-ipfix-mib-export-05 and I think it is not ready and requires improvements. 1) The introduction contains details of the solution. I think it should instead contain the motivation and the architectural model currently in section 2. The new introduction should then be followed by a terminology section before an overview of the solution is provided (so that the terminology is defined). This is primarily text reorganization. 2) I have trouble to understand the Figure "Architectural Overview". I think this should be removed. Figure 4 is more useful and it is at the right place in the document. 3) I have terminology issues in several places. For example, RFC 2578 uses the term 'columnar object' for what this document seems to call 'indexed object'. Why is it useful to call Flow Records Data Records? Using two terms for the same thing may just adds potential for confusion. I also think more SMIv2 terms must be imported, such as MIB module, MIB object, columnar object, ... 4) There is a statement that providing index information for columnar objects is optional. I have some difficulty to understand why this is useful. What does "a MIB object is used purely as type information" mean? How can an exporting process not have access to index information of a columnar object? 5) The terminology sections says a "MIB Object Identifier" is an ASCII character string of a certain format but it seems later a BER encoded representation is used for mibObjectIdentifier. This seems inconsistent. 6) "exporting a value from a MIB does not imply that the SNMP process on the device supports that MIB" Proper wording would be something like this: "exporting a value of a MIB object defined in a certain MIB module does not imply that the SNMP prcess on the device supports that MIB module" Similarly, "exporting MIBs in IPFIX" should be "exporting values of MIB objects". The paragraph on page 9 is also the first occurance of the term "MIB Field" - without a clear definition what this means. 7) This text needs rewrite: Since these values are statically defined in the MIB they are not expected to change frequently. However the additional information about the MIB may help a Collecting Process that does not have access to the MIB. NEW Type information is statically defined in a MIB module, it is not expected to change. However, the additional information about the MIB Object may help a Collecting Process that does not have access to the MIB module. 8) Is it mibTypeOption of mibSubTypeOption? Both words are used, or are these different things? 9) I fail to parse/understand these statements: Forf each of these the options this draft specifies exactly which mibObjectValue to use. [...] If the SYNTAX clause contains a Textual Convention or Subtyping the mibObjectSyntax Information Element SHOULD be used to export this detail to the Collecting Process. 10) It escapes me how mibObjectValueSequence and mibObjectValueTable are used / encoded. And why does the first one use an ASN.1 type name while the second uses an SMIv2 conceptual term? This seems inconsistent, either call them mibObjectValueSequence and mibObjectValueSequenceOf or mibObjectValueRow and mibObjectValueTable. 11) This text is unclear and needs a rewrite. I think I understand what you are trying to communicate but the wording needs improvements. (And it is a MIB module here, not a MIB.) This holds true even if the data carried inside the mibObjectValue or mibObjectIdentifier may be related to an enterprise specific MIB. The OID itself encodes if the Object is in an Enterprise specific MIB Module. 12) What does "Field Length (mib)" stand for? Is there anything special or is this just a plain normal "Field Length"? If so, I would rather remove the "(mib)" annotation. 13) I suggest to replace "more information about MIB indexing, extra data from the MIB" with "additional information about the MIB Object definition" 14) Rewrite "... a reference to a MIB that ..." - I think you mean a MIB Object. Rewrite "may not have access to the MIB" -> "may not have access to the MIB module". And then I am getting lost here: [..] It also allows the IPFIX Field Types to be extended with any MIB Variable already defined purely through IPFIX. It is not clear what is communicated here. 15) Section 4.4.6 has more inaccurate usages of the term "MIB" but more important, I wonder what actually the OID is that is being shipped in mibObjectIdentifier. Is it the OID assigned to the object type definition or is it the OID of the instance of an object type? Have I overlooked where this is clearly defined? 16) Terminology: "MIB Sequence Object's INDEX clause" -> "INDEX clause of a conceptual row object". 17) s/then the MIB context MUST/then the context MUST/ MIB context is not a defined term. There are only SNMP contexts. (Perhaps they should have been MIB contexts but this is a different story.) 18) s/the exported to export/the exporter to export/ 19) Section 4.8 is rather confusing, primarily because the terminology is not aligned with SMIv2 terminology. This affects almost all sentences. In SMIv2, terms like "MIB SEQUENCE Objects" do not exist. SMIv2 calls this a 'conceptual row object'. This section needs to be rewritten to align with SMIv2 terminology (this means getting rid of almost all occurrences of 'sequence' (in any capitalization)). Terms such as "full OID" are ambiguous unless you say what the OID is supposed to refer to. The first item in 4.8 talks about ingoring the indexing of columnar objects and later says "a columnar object may be used purely as a data type. I have a difficulty to understand how that would be useful. On page 33, a paragraph refers to section 7.7. of RFC 2578 and I am confused what it tries to say here. So far, I assumed that the OIDs all refer to columnar objects or conceptual row objects and include no instance identifiers. I do not understand the last paragraph before section 5. 20) The first enumerated item in Section 5.1 says "flowStartSeconds from [RFC7012]" but then RFC 7012 does not define this anymore (but its predecessor RFC 5102 did). Since Section 5.2 has the same text, the same issue needs to be resolved there. 21) Sections 5.1. and 5.2 both contain references to themselfs "(see Section 5.x)" which does not seem to make much sense. Last sentence on page 38: s/this identical/this is identical/ 22) I looked up the definition of cpmCPUTotal1minRev and it turns out that this is a columnar object (which makes sense since you can have multiple CPUs). Since you do not export information about which CPU the load value is coming from, how useful is the information and does this make a good example? 23) Section 5.3. needs a title change. It is about exporting a subset of a conceptual row. Perhaps something like this: 5.3. Exporting a Conceptual Row: The OSPF Neighbor Sequence The last sentence on page 40 refers to Table 7 but I assume you mean Table 5. 24) The BER encoding of 1.3.6.1.2.1.14.10.1 is 06082B060102010E0A01 (10 octets) and not the 22 octets shown in Figure 28. 25) Section 5.4. also needs a better title, e.g. 5.4. Exporting an Augmented Conceptual Row: ifTable and ifXTable The text in section 5.4 confuses ifXEntry and IfXEntry. A possible rewrite: The ifTable defined in the IF-MIB [RFC2863] is augmented by the ifXTable (defined in the same MIB module). The OID of the ifEntry is 1.3.6.1.2.1.2.2.1 while the OID of the augmenting ifXEntry is 1.3.6.1.2.1.31.1.1.1. This example demonstrates how columnar objects from the base conceptual row and the augmenting row can be exported in a single mibObjectValueSequence data record. 26) Why is the Field Length of mibObjectValueOctetString (on page 46) 16 octets? The ifName's restriction is 255 octets. And should this not be variable length? 27) page 47: s/VLAN=11/VLAN=10/ On page 48, I am surprised that ifType and ifMTU are both 16-bit fields. Does the template not say they are 4 octets long? 28) Section 5.5. also needs a new title and the terminology used is wrong as well. Perhaps it is: 5.5. Exporting a Columnar Object: ipIfStatsInForwDatagrams Please do not write 'ipIfStatsTable SEQUENCE'. The correct SMIv2 term is conceptual table. (And also note that the ASN.1 type of a table is a SEQUENCE OF and not a SEQUENCE.) The template in Figure 33 says the interface index is two octets. This may be true for a certain exporter but may not be generally true - it may be worth to be explicit about the assumption made here that all possible interfaces are numbered such that they fit into 16 bits. The BER encodings and the corresponding VLEN fields are all wrong in Figure 35: 1.3.6.1.2.1.4.31.3.1.1 -> 060A2B06010201041F030101 (12 octets) 1.3.6.1.2.1.4.31.3.1.2 -> 060A2B06010201041F030102 (12 octets) 1.3.6.1.2.1.4.31.3.1.12 -> 060A2B06010201041F03010c (12 octets) 29) Section 5.6. needs a better title. This is about a columnar object where the index information is provided by IPFIX information elements. 5.6. Exporting a Columnar Object index by IEs: ifOutQLen s/be done be/be done by/ The text below Table 8 needs to be rewritten, e.g. The ifOutQLen MIB object defined in the IF-MIB [RFC2863] provides the length of the output packet queue. This columnar object is part of the ifEntry conceptual row and indexed by the interface index (ifIndex). I am not sure I agree on the second paragraph on page 53. I tend to believe that the index information must be provided for generic applications to make sense out of the data. The BER encoding and the corresponding VLEN in Figure 39 is wrong: 1.3.6.1.2.1.2.2.1.21 -> 06092B0601020102020115 (11 octets) 30) I find the example in section 5.7 rather strange. Why would one export the ifIndex value using mibSubIdentifier and not by including the ifIndex proper? There does not seem to be any savings and this mibSubIdentifier approach of course is only applicable where the number of sub-identifier is constant for all conceptual rows. Since I do not see that this approach is needed nor that it adds any value in terms of more compact encodings, I would actually prefer this to be removed and perhaps even be disallowed. The BER encoding of the ifOutQLen OID is wrong, see above for the correct value. (The caption of Figure 44 is kind of strange because it says "using ifIndex" but then the example is about not using ifIndex but instead an opaque number.) This section 5.7. should really be removed I think. 31) In section 5.8, s/ospfNbarEntry/ospfNbrEntry/ The OID encoding and the VLEN field in Figure 46 is wrong: 1.3.6.1.2.1.14.10.1 -> 06082B060102010E0A01 (10 octets) RFC 3411 uses '800002b804616263'H as an snmpEngineID in examples. 32) What is the meaning of this: If a Collecting Process receives a MIB Object Identifier that it cannot decode, it SHOULD log an error. What does 'cannot decode' mean? I mean, a simple collector may just store the records in some file / database. So what is expected here? And why is it an error and not a warning? I am also not sure what the last paragraph in section 7 tells me. What does 'purely semantic information' mean? For me, if you miss the semantics, the data has no value. But I understand that IPFIX people have a very different terminology at times. 33) It is unclear to me how the export of conceptual rows deals with non-existing variables (aka table holes). Is there a mechanism in IPFIX to indicate that a certain field of a flow record does not have a value? Issues with section 10: a) In the SMIv2, we distinguish between Counter32 and Counter64 and I think this difference important to capture since the rollover is different. The I-D seems to map both to mibObjectValueCounter. b) The descriptions all use the phrase "from a MIB" but I think it should be "of a MIB object". c) The SMIv2 type is IpAddress and not IPAddress. d) The definition of mibObjectValueCounter says "Data Type Semantics: totalCounter". I think this is wrong since SMIv2 counters do not start with zero. Furthermore, a Counter32 rolls over after 32-bit and not after 64-bit (but mibObjectValueCounter is an unsigned64). e) The definition of mibObjectValueGauge "Data Type Semantics: totalCounter". I think this is wrong, a Gauge32 is not a counter. And it might be useful to call this mibObjectValueGauge32. f) Why did you call mibObjectValueTime not mibObjectValueTimeTicks? The "Abstract Data Type: dateTimeMilliseconds" also seems to be wrong since TimeTicks are _not_ measured in milliseconds since 1970-01-01T00:00. You may want to use unsigned32 and spell out the semantics. g) mibObjectValueUnsigned used the "Abstract Data Type: unsigned64" which is wrong since there is only a 32-bit unsigned type in the SMIv2. I suggest to use unsigned32 and to rename this to mibObjectValueUnsigned32. h) The phrase "a complete MIB 'SEQUENCE OF X' or conceptual table value" reads strange. Similarly, "a MIB SEQUENCE or a row from a conceptual table" reads strange. Perhaps simply use "a complete conceptual table" and "a row of a conceptual table". i) The lest sentence of the Description in 10.1.11 seems to be missing some words. j) The description of 10.2.2 is somewhat confusing: "... that serves as INDEX MIB Objects of Information Elements for a mibField". In SMIv2, the INDEX is associated with a conceptual row. k) What does "sampled by SNMP" mean? Do you hook into the instrumentation or do you access things via the SNMP agent? l) p74: s/the MIB the Flow/the MIB when the Flow/ (Note that you are talking about a flow here and not about a data record. I think this is goodness and proves that a new term is not needed.) m) Replace the Description in 10.3.4 with this: Description: The textual name of the MIB module that defines a MIB Object. n) I do not understand what mibObjectSyntax would contain for an object representing a conceptual table or a conceptual row. For say ifEntry, would it be just "SEQUENCE { ifIndex InterfaceIndex, ifDescr DisplayString, -- lots of stuff left out }"? And what would it be for the object representing the conceptual table? Or do you just mean what is literally in the SYNTAX clause, excluding the referenced ASN.1 type definitions? For other MIB Objects, do you include subtyping information such as range of length restrictions? What about named number enumerations of the BITS construct, you include the whole definition (mind you that RowStatus is really long). o) Remove "( also known as snmpEngineID) that" since it is potentially misleading. Explanation: Every SNMP engine has a unique snmpEngineID. The combination of a snmpEngineID value and a context names provides the SNMP context. Note that an SNMP engine may provide access to a non-local context, in which case the values of snmpEngineID and contextEngineID would be different. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Apr 18 14:30: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 95D631A04BC for ; Fri, 18 Apr 2014 14:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 k4elX3J4-JGF for ; Fri, 18 Apr 2014 14:30:28 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 94CEA1A04F6 for ; Fri, 18 Apr 2014 14:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=272; q=dns/txt; s=iport; t=1397856624; x=1399066224; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=YcZjkRhhRjWY0KwS3uORJTrLbxeY7+yuKuGn4y9GZ0Y=; b=HBKE2x1V0+o1TkCi0UbjNB/WqOpIWHwyPCpeCMhW0L1C07vwODUdUJYe tAHKOYKt7wfGLlLDtbxxZTCM6+0ka5B2rxT8DLvqzH6C3udxNYuCDp1re wZI6jan1II2LcTBfJPoWeMbm5KKb1aHWxQpEBK1T9D7M2XVmmXVTCelfT I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEAO+YUVOtJssW/2dsb2JhbABakUO4FnSCZDMNPRYYAwIBAgFLDQgBAYg9mmqyOBeTIQEDmG6GWIt3gzI X-IronPort-AV: E=Sophos;i="4.97,886,1389744000"; d="scan'208";a="15197507" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 18 Apr 2014 21:30:22 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3ILUMI4011202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Apr 2014 21:30:22 GMT Received: from [10.61.100.185] (dhcp-10-61-100-185.cisco.com [10.61.100.185]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s3ILULvI009920 for ; Fri, 18 Apr 2014 22:30:22 +0100 (BST) Message-ID: <53519965.2090702@cisco.com> Date: Fri, 18 Apr 2014 22:30:13 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/MkRMDMryaGzRTRrpmifXVjhn7W0 Subject: [IPFIX] IPFIX layer 2 packet count 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, 18 Apr 2014 21:30:31 -0000 Dear IPFIX experts, There are some layer 2 octet count IEs, but no layer 2 frame count IE. Is it acceptable to report the number of layer 2 frames with Information Element #2 "packetDeltaCount" ? If not, then I'll request new delta + total IEs. Thanks, P. From nobody Fri Apr 18 14:44:45 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 D4DAC1A01CE for ; Fri, 18 Apr 2014 14:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 vFWFPROT8hFD for ; Fri, 18 Apr 2014 14:44:34 -0700 (PDT) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id 9049B1A007B for ; Fri, 18 Apr 2014 14:44:34 -0700 (PDT) Received: from [10.1.14.85] (64.140.243.154) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 18 Apr 2014 17:44:29 -0400 Message-ID: <53519CBD.2070404@plixer.com> Date: Fri, 18 Apr 2014 17:44:29 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Paul Aitken , IETF IPFIX Working Group References: <53519965.2090702@cisco.com> In-Reply-To: <53519965.2090702@cisco.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/5Bs3HaWTSOemHTMSrjy7R2Po_jA Subject: Re: [IPFIX] IPFIX layer 2 packet count 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, 18 Apr 2014 21:44:37 -0000 Hi Paul, On 04/18/2014 05:30 PM, Paul Aitken wrote: > Dear IPFIX experts, > > There are some layer 2 octet count IEs, but no layer 2 frame count IE. > > Is it acceptable to report the number of layer 2 frames with > Information Element #2 "packetDeltaCount" ? Seems OK to me. At least I don't see what new information two new IES would communicate. Is there a situation where a hypothetical flow with both packetDeltaCount(2) and frameDeltaCount(#TBD) would have different values? -Andrew > > If not, then I'll request new delta + total IEs. > > Thanks, > P. > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From nobody Fri Apr 18 14:50:48 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 13F3C1A01CE for ; Fri, 18 Apr 2014 14:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 7OflJV54c0db for ; Fri, 18 Apr 2014 14:50:44 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 242A11A02F9 for ; Fri, 18 Apr 2014 14:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=275; q=dns/txt; s=iport; t=1397857840; x=1399067440; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Bgotfu1NNOjarNcLNpUI9KBweKYGi8UswYBNm+IPVNI=; b=AvQsIssUOzqMCARhCcdMuY1TEUdqaq5sypY1XY4AtYCaP+uEpkmRfAb0 0Kh8WfmUOKHjrrSB2AWx0spihd3dSzGFjGITmrJnbtXY4GoKJv8r8kruw 9GMjBur9f4WqLXAZVxMjNB0gPlFhSXJk/y5gi5TvCymdvho3A1/tNBW7x Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEAOGcUVOtJssW/2dsb2JhbABakUO2Y4EzdIIlAQEBAwE4QAYLCyEWDwkDAgECAUUGAQwIAQGINQjNHBeOaYQ4AQOYboZYi3eDMg X-IronPort-AV: E=Sophos;i="4.97,886,1389744000"; d="scan'208";a="19302264" 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; 18 Apr 2014 21:50:39 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3ILod5f031027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Apr 2014 21:50:39 GMT Received: from [10.61.100.185] (dhcp-10-61-100-185.cisco.com [10.61.100.185]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s3ILob3V010781; Fri, 18 Apr 2014 22:50:38 +0100 (BST) Message-ID: <53519E24.3020706@cisco.com> Date: Fri, 18 Apr 2014 22:50:28 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Andrew Feren , IETF IPFIX Working Group References: <53519965.2090702@cisco.com> <53519CBD.2070404@plixer.com> In-Reply-To: <53519CBD.2070404@plixer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/BZdQB1D0XOLjz53xgc8N2XHJiK8 Subject: Re: [IPFIX] IPFIX layer 2 packet count 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, 18 Apr 2014 21:50:46 -0000 Andrew, > Is there a situation where a hypothetical flow with both > packetDeltaCount(2) and frameDeltaCount(#TBD) would have different values? If any of the observed layer 2 frames don't contain layer 3 packets, frameDeltaCount would be > packetDeltaCount. P. From nobody Sat Apr 19 00:04: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 771C81A0085 for ; Sat, 19 Apr 2014 00:04:44 -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 D6N_iBL7DHjz for ; Sat, 19 Apr 2014 00:04:40 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id D320A1A0221 for ; Sat, 19 Apr 2014 00:04:39 -0700 (PDT) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) by trammell.ch (Postfix) with ESMTPSA id 1A0151A002A; Sat, 19 Apr 2014 09:04:02 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_2A01B11B-2973-4C62-86AB-D160517E3BCF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Brian Trammell In-Reply-To: <53519E24.3020706@cisco.com> Date: Sat, 19 Apr 2014 09:04:01 +0200 Message-Id: References: <53519965.2090702@cisco.com> <53519CBD.2070404@plixer.com> <53519E24.3020706@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/2It6nGUgCQMBWhDqdd-avW5XRPI Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX layer 2 packet count 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, 19 Apr 2014 07:04:44 -0000 --Apple-Mail=_2A01B11B-2973-4C62-86AB-D160517E3BCF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Paul, all, Given that we did the same thing with transportPacketDeltaCount (i.e. = only packets with transport layer content), where (for TCP) = transportPacketDeltaCount < packetDeltaCount less bare SYNs/ACKs (or = other transport layer control), it makes a lot of sense to have new = frame count IEs. We'd probably want the description to note that this should only be = exported by EPs attached to MPs that can actually see layer 2 (i.e., = that aren't working only on the IP layer and above)... though on second = thought that's a little obvious... For naming, layer2PacketDeltaCount would be more consistent with other = IE naming, but I think frameDeltaCount is a better, more precise name. = So I'm good with either actually. Thanks, cheers, Brian On 18 Apr 2014, at 23:50, Paul Aitken wrote: > Andrew, >=20 >> Is there a situation where a hypothetical flow with both = packetDeltaCount(2) and frameDeltaCount(#TBD) would have different = values? >=20 > If any of the observed layer 2 frames don't contain layer 3 packets, = frameDeltaCount would be > packetDeltaCount. >=20 > P. >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --Apple-Mail=_2A01B11B-2973-4C62-86AB-D160517E3BCF 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 iQEcBAEBCgAGBQJTUh/hAAoJENt3nsOmbNJc6S4IAJS4gRxHBeD78/8XkRiLuBuC Zons2svK6YiGEK6Ne/cjXbCLnwBkpri8iB00KiNF1hNKy/+E8hvkiZ26Tr0+wgPE Ca2pissBfvpHnhFnHmDn3Kz+HwzKzrpCkxy4TyfGDEn0GP/xbneLDcrp2MmLZeel fRdhXM3qS9jP5rKVcibsNIWjmZAN3NSLrLYIEolYJkjuTl+0VPKyDJDCDhVAlWoh 4Xi+pR12Qg+JFf4/A+0CFOuFY6Y7b3mURsM7rCxakuz6s1OxWS+Vsq0LSoyeOnGi Y9NYvCBwK7MuRdPXC3IHmnT89F9wF6RQ3W5eUOYTDiLtnubZJh4XXQtcdWhpOZo= =nO3B -----END PGP SIGNATURE----- --Apple-Mail=_2A01B11B-2973-4C62-86AB-D160517E3BCF-- From nobody Fri Apr 25 06:32:27 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 4D68F1A0494 for ; Fri, 25 Apr 2014 06:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.772 X-Spam-Level: X-Spam-Status: No, score=-8.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 qe61p-K0tHVj for ; Fri, 25 Apr 2014 06:32:21 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 973C41A01D1 for ; Fri, 25 Apr 2014 06:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37704; q=dns/txt; s=iport; t=1398432736; x=1399642336; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=KkG0fsnmQlqNdn2AXAYcLYjJiyh7qGsGlnd/EUFRaSg=; b=mm2x7qwL7TvasPK5tx9OZcDohadpNYnOLCNQQrlANi09BSnklDe27LIM 6IGXN4OsEO2vmmaQB5Xd4U9wTl7a9tN+WGgUycqNND15z7vDOEwoQozCi r0E3rkWA6TkVCF01hPqdjJPug2tfKE8fLmzC3chCiLYYniik9NIgAwUtr E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAPJiWlOtJssW/2dsb2JhbABZDoNHiRmyY4h6gSV0giUBAQEDARoDClERCw4TFgEOCQMCAQIBRQYBDAgBAYg1CA3KcReJN4UphDkBA5UTg3KBOIUjjAGCcUI7 X-IronPort-AV: E=Sophos; i="4.97,927,1389744000"; d="scan'208,217"; a="26986266" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 25 Apr 2014 13:32:14 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3PDWCdp017711; Fri, 25 Apr 2014 13:32:12 GMT Message-ID: <535A63DC.3090308@cisco.com> Date: Fri, 25 Apr 2014 15:32:12 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nevil Brownlee , IPFIX Working Group References: <534C76C7.9030108@auckland.ac.nz> In-Reply-To: <534C76C7.9030108@auckland.ac.nz> Content-Type: multipart/alternative; boundary="------------080804080705040804010304" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/yXh5eePTvqCUMOIxkAKwrUsXexc Subject: Re: [IPFIX] WGLC for draft-ietf-ipfix-mib-variable-export-05 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, 25 Apr 2014 13:32:25 -0000 This is a multi-part message in MIME format. --------------080804080705040804010304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear all, I stopped my review at section 4.4.2 (spent a couple of hours already), and I'm afraid the draft is not ready. Here is my feedback. - Section 1 For example, in the IPFIX information model [RFC7012 ], Information Elements coming from the SNMP world have already been specified, e.g., ingressInterface and egressInterface both refer to the ifIndex defined in [RFC2863 ]. As Jürgen noted, RFC 7012 doesn't specify the IPFIX information elements any longer. This is done in the IANA registry. - Section 2 In the best case, assuming very tight integration of an IPFIX Collector with and SNMP polling engine, SNMP data is retrieved shortly after Data Records have been received, which implies a delay of the sum of the active or inactive timeouts (if not null) plus the time to export the Flow Record to the Collector. For active and inactive timeouts, provide a reference to RFC 5470 , section 5.1.1. "Flow Expiration" Even if RFC 5470 doesn't call them active and inactive timeouts (btw, don't change that, these are well known terms), this is a good reference. - Section 2 This draft does not specify SNMP notifications, even if the specifications in this document could potentially allow this. draft -> document Same remark for: For each of these the options this draft specifies exactly which mibObjectValue to use. This draft defines two forms of indexing that can be used for SEQUENCE MIB Objects. - Section 2 The simple and application-wide data types specified in SMIv2 [RFC2578 ], along with a new Textual Conventions Remove the s - Section 3 mibObjectValue Refers to any and all of the mibObjectValue Information Elements generically. Any restriction or requirement in this document that refers to mibObjectValue applies to the following Information Elements defined inSection 10.1 : mibObjectValueInteger, mibObjectValueOctetString, mibObjectValueOID, mibObjectValueBITS, mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTime, mibObjectValueUnsigned, mibObjectValueTable and mibObjectValueSequence. Change mibObjectValue to mibObjectValue Information Elements. This is how it's used in some sentences in the rest of the document. However, I also see: mibObjectValue Field or mibObjectValue field I don't know what the term field refers to. Please change this to mibObjectValue Information Elements - Section 4 The Exporting process MAY extract the data values for mibObjectValue fields from a Process that resides on the same device or MAY capture/ create the data required to match the definition of the MIB Object. In particular exporting a value from a MIB does not imply that the SNMP process on the Device supports that MIB. Why is Process capitalized? Also MAY to may. This is not a RFC 2119 keyword required for the implementation. - Section 4 The main issue that arises from exporting MIBs in IPFIX is that MIB Object Identifiers do not fit into the standard IPFIX Template format [RFC7011 ], as this only provides a 16-bit Information Element identifier and the length of the Information Element. I would remove "and the length of the Information Element", which doesn't add anything to this sentence - Section 4 One approach to this problem would be to extend the IPFIX standard to allow extended field specifiers so metadata about Fields can be included in Data Templates. Fields -> field - Section 4 However, future versions of IPFIX MAY export the required MIB metadata as part of newer set versions. MAY -> may. Please review all RFC 2119 keywords - Section 4 This is a standard IPFIX Option Template Set that MUST include a minimum set of required fields (seeSection 4.2.1 ) and MAY include extra fields to provide more meta information about one of the mibObjectValue fields. While you're not yet in the specifications in Section 4, I would not introduce MUST and MAY here. This also contradicts the REQUIRED and RECOMMENDED in section 4.2.1 Please group the RFC 2119 keywords in section 4.2.1 - Throughout the document Option Template -> Options Template Note: IIRC, there were inconsistencies in RFC 5101, which were corrected in RFC 7011 - Major issue: I confused by mibFieldOption Is this a IE or an Options Template? The TOC shows: 4.2. MIB Field Options - Specifications and Required Fields . 11 4.2.1 . mibFieldOption . . . . . . . . . . . . . . . . . . .12 4.2.2 . mibSubFieldOption . . . . . . . . . . . . . . . . . .13 4.2.3 . mibTypeOption . . . . . . . . . . . . . . . . . . . .13 4.3 . IPFIX and MIB Data Model . . . . . . . . . . . . . . . .14 4.4 . MIB Field Option Template Formats . . . . . . . . . . . .15 4.4.1 . Data Template containing a mibObject Field . . . . .15 4.4.2 . mibFieldOption Template . . . . . . . . . . . . . . .17 4.4.3 . mibFieldOption Data Records . . . . . . . . . . . . .18 4.4.4 . Option Template containing a mibObject Field . . . .19 4.4.5 . mibFieldOption Template with Semantics Fields . . . .20 4.4.6. mibFieldOption Template with extra MIB Object Details 21 It's not clear! This document also defines three standard Option Templates (see Section 4.2 ) that are used as part of the mechanism to export MIB Object meta data: o mibFieldOption (Section 4.2.1 ) o mibSubFieldOption (Section 4.2.2 ) o mibTypeOption (Section 4.2.3 ) Ok, so these are Options Templates. If this is the case, change the TOC section titles Then I see in figure 1 +------------------------+ | mibFieldOptionTemplate | +------------------------+ What is a mibFieldOptionTemplate ? This document defines a mibFieldOption Template to export the extra meta information required for a mibObjectValue field. Well, this one above is wrong. This should be Options Template, right? Then I see 2. A mibFieldOption Template Set The mibFieldOption Template describes which metadata will be sent for each mibObjectValue being exported. These should be Options Template Set, right? Then, I look at 4.2.1. mibFieldOption Three fields are REQUIRED to unambiguously export a standalone mibObjectValue Field with a mibFieldOption: Then I look at 4.4.2. mibFieldOption Template The mibFieldOption Template is a Standard Option Template which defines the Fields that will be exported to provide enough metadata about a mibObjectValue so that the Collector can tie the data values in the mibObjectValue back to the definition of the MIB Object. And I finally understand that mibFieldOption is an Options Template. What is very confusing to me is that mibFieldOption is apparently simply an Options Template, like we have defined in IPFIX (http://tools.ietf.org/html/rfc7011#section-4.1) or PSAMP (http://tools.ietf.org/html/rfc5476#section-6.5.1) However, this Options Template is called like an IPFIX IE: mibFieldOption This should be called "MIB Field Options Template" throughout the document. OLD: This document also defines three standard Option Templates (see Section 4.2 ) that are used as part of the mechanism to export MIB Object meta data: o mibFieldOption (Section 4.2.1 ) o mibSubFieldOption (Section 4.2.2 ) o mibTypeOption (Section 4.2.3 ) NEW: This document also defines three standard Option Templates (see Section 4.2 ) that are used as part of the mechanism to export MIB Object meta data: o MIB Field Options Template (Section 4.2.1 ) o MIB SubField Options Template (Section 4.2.2 ) o MIB Type Options Template (Section 4.2.3 ) - Major: Why do we have ... http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.1 http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4.2 ... with slightly different specifications? As I mentioned previously, there are also some conflicting spec rules at the beginning of the section 4 - 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 258 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope field count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: Example of tcpCurrEstab mibFieldOption Template Set This is not an Template Set, but an Options Template Set. Same remark for all the examples. - Section 4.2 Why a single in this sentence? For each mibObjectValue field that is defined in an IPFIX Template, a single mibFieldOption Data Record MUST be exported that provides the required minimum information to define the MIB object that is being exported (seeSection 4.2.1 ). What if we export with UDP? We might want to re-export this metadata information, without which the collector can't interpret the data. This contradicts: Note that the ID of an identical mibFieldOptionTemplate which has already been exported MAY be reused without exporting the Template again. - Section 4.2 This mibFieldOption Data is defined in a template referred to in this document as a mibFieldOption Template with the format specified in Section 4.4 . What's mibFieldOption Data? Template -> Options Template - Section 4.2 _ A Template that uses a mibObjectValue Field MUST be exported prior to the corresponding mibFieldOption Data Records._ It is RECOMMENDED that these are all exported in the same IPFIX Message. Note that this places an implicit size constraint on the export. _ These MUST all be exported prior to the corresponding Data Records which depend upon them._ i.e. referring to Figure 1, the export order MUST be: The two underlined sentences are redundant. - Major While the following are optional, they are nevertheless RECOMMENDED in certain circumstances as they are per field: You don't explain those circumstances - I arrived at section 4.3, I'm not clear when I need to use mibSubFieldOption ormibTypeOption For mibSubFieldOption, this only thing I read so far is: To export a mibObjectValue that is contained in a mibObjectValueSequence Field with a mibSubFieldOption three fields are REQUIRED: Not too clear. - Major, Section 4.4.1 Multiple mibFieldOption that refer to a single mibObjectValue MUST NOT be exported. What is Multiple mibFieldOption? Multiple Data Records. No Multiple different Data Records. I agree Multiple Options Template Records. No Multiple different Options Template Records. I agree - Major, Section 4.4.1 OLD: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = Existing IPFIX Field | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectValueInteger | Field Length (mib) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: IPFIX Template Set using mibObjectValue Field NEW: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = Existing IPFIX Field | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = | Field Length (mib) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: IPFIX Template Set using mibObjectValue Field Then you have to explain that could be mibObjectValueInteger, mibObjectValueOctetString, mibObjectValueOID, mibObjectValueBITS, mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTime, mibObjectValueUnsigned, mibObjectValueTable and mibObjectValueSequence. I stopped my review at section 4.4.2, but plenty of my feedback would apparently be equivalent for the rest of the draft. Regards, Benoit > > Hi all: > > Sorry to be a little slow with this - the dust has settled from IETF-89, > and I've almost managed to catch up. > > The WG Last Call for our MIB Variable Export draft starts now, > and will end on Wednesday, 30 April. > > Please read it, and - better still - post reviews of it to the IPFIX > list! > > Cheers, Nevil > --------------080804080705040804010304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

I stopped my review at section 4.4.2 (spent a couple of hours already), and I'm afraid the draft is not ready.
Here is my feedback.

- Section 1
   For example,
   in the IPFIX information model [RFC7012], Information Elements coming
   from the SNMP world have already been specified, e.g.,
   ingressInterface and egressInterface both refer to the ifIndex
   defined in [RFC2863].
As Jürgen noted, RFC 7012 doesn't specify the IPFIX information elements any longer.
This is done in the IANA registry.

- Section 2

      In the best case, assuming very tight integration of
      an IPFIX Collector with and SNMP polling engine, SNMP data is
      retrieved shortly after Data Records have been received, which
      implies a delay of the sum of the active or inactive timeouts (if
      not null) plus the time to export the Flow Record to the
      Collector.
For active and inactive timeouts, provide a reference to RFC 5470 , section 5.1.1. "Flow Expiration"
Even if RFC 5470 doesn't call them active and inactive timeouts (btw, don't change that, these are well known terms), this is a good reference.

-  Section 2
   This draft does not specify SNMP notifications, even if the
   specifications in this document could potentially allow this.

draft -> document
Same remark for: 

   For each of these the options this draft specifies exactly which
   mibObjectValue to use.

   This draft defines two forms of indexing that can be used for
   SEQUENCE MIB Objects.

- Section 2

   The
   simple and application-wide data types specified in SMIv2 [RFC2578],
   along with a new Textual Conventions

Remove the s 

- Section 3

 mibObjectValue

      Refers to any and all of the mibObjectValue Information Elements
      generically.  Any restriction or requirement in this document that
      refers to mibObjectValue applies to the following Information
      Elements defined in Section 10.1: mibObjectValueInteger,
      mibObjectValueOctetString, mibObjectValueOID, mibObjectValueBITS,
      mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTime,
      mibObjectValueUnsigned, mibObjectValueTable and
      mibObjectValueSequence.

Change mibObjectValue to mibObjectValue Information Elements.
This is how it's used in some sentences in the rest of the document.
However, I also see:  mibObjectValue Field or mibObjectValue field
I don't know what the term field refers to. Please change this to mibObjectValue Information Elements

- Section 4

   The Exporting process MAY extract the data values for mibObjectValue
   fields from a Process that resides on the same device or MAY capture/
   create the data required to match the definition of the MIB Object.
   In particular exporting a value from a MIB does not imply that the
   SNMP process on the Device supports that MIB.
 
Why is Process capitalized?
Also MAY to may. This is not a RFC 2119 keyword required for the implementation.

- Section 4
   The main issue that arises from exporting MIBs in IPFIX is that MIB
   Object Identifiers do not fit into the standard IPFIX Template format
   [RFC7011], as this only provides a 16-bit Information Element
   identifier and the length of the Information Element.  

I would remove "and the length of the Information Element", which doesn't add anything to this sentence

- Section 4

   One approach to this problem would be to extend the IPFIX standard to
   allow extended field specifiers so metadata about Fields can be
   included in Data Templates.

Fields -> field

- Section 4

   However, future versions of IPFIX MAY export the required MIB
   metadata as part of newer set versions.

MAY -> may.
Please review all RFC 2119 keywords

- Section 4
   This is a
   standard IPFIX Option Template Set that MUST include a minimum set of
   required fields (see Section 4.2.1) and MAY include extra fields to
   provide more meta information about one of the mibObjectValue fields.

While you're not yet in the specifications in Section 4, I would not introduce MUST and MAY here.
This also contradicts the REQUIRED and RECOMMENDED in section 4.2.1
Please group the RFC 2119 keywords in section 4.2.1

- Throughout the document
Option Template -> Options Template 
Note: IIRC, there were inconsistencies in RFC 5101, which were corrected in RFC 7011

- Major issue: I confused by mibFieldOption
Is this a IE or an Options Template?

The TOC shows:
   4.2.  MIB Field Options - Specifications and Required Fields  .  11
       4.2.1.  mibFieldOption  . . . . . . . . . . . . . . . . . . .  12
       4.2.2.  mibSubFieldOption . . . . . . . . . . . . . . . . . .  13
       4.2.3.  mibTypeOption . . . . . . . . . . . . . . . . . . . .  13
     4.3.  IPFIX and MIB Data Model  . . . . . . . . . . . . . . . .  14
     4.4.  MIB Field Option Template Formats . . . . . . . . . . . .  15
       4.4.1.  Data Template containing a mibObject Field  . . . . .  15
       4.4.2.  mibFieldOption Template . . . . . . . . . . . . . . .  17
       4.4.3.  mibFieldOption Data Records . . . . . . . . . . . . .  18
       4.4.4.  Option Template containing a mibObject Field  . . . .  19
       4.4.5.  mibFieldOption Template with Semantics Fields . . . .  20
       4.4.6.  mibFieldOption Template with extra MIB Object Details  21

It's not clear!

  This document also defines three standard Option Templates (see
   Section 4.2) that are used as part of the mechanism to export MIB
   Object meta data:

   o  mibFieldOption (Section 4.2.1)

   o  mibSubFieldOption (Section 4.2.2)

   o  mibTypeOption (Section 4.2.3)

Ok, so these are Options Templates.
If this is the case, change the TOC section titles

Then I see in figure 1
                                       +------------------------+
                                       | mibFieldOptionTemplate |
                                       +------------------------+
What is a mibFieldOptionTemplate ?

   This document defines a mibFieldOption Template to export the extra
   meta information required for a mibObjectValue field. 

Well, this one above is wrong. This should be Options Template, right?

Then I see
  2.  A mibFieldOption Template Set

          The mibFieldOption Template describes which metadata will be
          sent for each mibObjectValue being exported.

These should be Options Template Set, right?

Then, I look at

    4.2.1.  mibFieldOption

   Three fields are REQUIRED to unambiguously export a standalone
   mibObjectValue Field with a mibFieldOption:

Then I look at 

    4.4.2.  mibFieldOption Template
   The mibFieldOption Template is a Standard Option Template which
   defines the Fields that will be exported to provide enough metadata
   about a mibObjectValue so that the Collector can tie the data values
   in the mibObjectValue back to the definition of the MIB Object.

And I finally understand that mibFieldOption is an Options Template.

What is very confusing to me is that mibFieldOption is apparently simply an Options Template, like we have defined in IPFIX (http://tools.ietf.org/html/rfc7011#section-4.1) or  PSAMP (http://tools.ietf.org/html/rfc5476#section-6.5.1) 
However, this Options Template is called like an IPFIX IE: mibFieldOption
This should be called "MIB Field Options Template" throughout the document. 

OLD:
   This document also defines three standard Option Templates (see
   Section 4.2) that are used as part of the mechanism to export MIB
   Object meta data:

   o  mibFieldOption (Section 4.2.1)

   o  mibSubFieldOption (Section 4.2.2)

   o  mibTypeOption (Section 4.2.3)

NEW:
   This document also defines three standard Option Templates (see
   Section 4.2) that are used as part of the mechanism to export MIB
   Object meta data:

   o  MIB Field Options Template (Section 4.2.1)

   o  MIB SubField Options Template (Section 4.2.2)

   o  MIB Type Options Template (Section 4.2.3)


- Major: Why do we have ...
http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.1
http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4.2
... with slightly different specifications?
As I mentioned previously, there are also some conflicting spec rules at the beginning of the section 4

-

    0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Set ID = 3           |          Length = 26          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Template ID = 258      |        Field Count = 4        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Scope field count = 2        |0| IE = templateId             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Field Length = 2       |0| IE = informationElementIndex|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Field Length = 2       |0| IE = mibObjectIdentifier    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Field Length = 65535   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 19: Example of tcpCurrEstab mibFieldOption Template Set

This is not an Template Set, but an Options Template Set.
Same remark for all the examples.

- Section 4.2

Why a single in this sentence?
   For each mibObjectValue field that is defined in an IPFIX Template, a
   single mibFieldOption Data Record MUST be exported that provides the
   required minimum information to define the MIB object that is being
   exported (see Section 4.2.1).

What if we export with UDP? We might want to re-export this metadata information, without which the collector can't interpret the data.
This contradicts:
   Note that the ID of an identical mibFieldOptionTemplate which has
   already been exported MAY be reused without exporting the Template
   again.

- Section 4.2

   This mibFieldOption Data is defined in a template referred to in this
   document as a mibFieldOption Template with the format specified in
   Section 4.4.

What's mibFieldOption Data?
Template -> Options Template

- Section 4.2

   A Template that uses a mibObjectValue Field MUST be exported prior to
   the corresponding mibFieldOption Data Records.  It is RECOMMENDED
   that these are all exported in the same IPFIX Message.  Note that
   this places an implicit size constraint on the export.

   These MUST all be exported prior to the corresponding Data Records
   which depend upon them.  i.e. referring to Figure 1, the export order
   MUST be:

The two underlined sentences are redundant.

- Major
   While the following are optional, they are nevertheless RECOMMENDED
   in certain circumstances as they are per field:

You don't explain those circumstances

- I arrived at section 4.3, I'm not clear when I need to use mibSubFieldOption or mibTypeOption 

For mibSubFieldOption, this only thing I read so far is: 
   To export a mibObjectValue that is contained in a
   mibObjectValueSequence Field with a mibSubFieldOption three fields
   are REQUIRED:

Not too clear.

- Major, Section 4.4.1

   Multiple
   mibFieldOption that refer to a single mibObjectValue MUST NOT be
   exported.

What is Multiple mibFieldOption?
Multiple Data Records. No
Multiple different Data Records. I agree
Multiple Options Template Records. No
Multiple different Options Template Records. I agree
 
- Major, Section 4.4.1

OLD:
    0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Set ID = 2           |          Length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Template ID             |         Field Count = 2       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0| IE = Existing IPFIX Field   |        Field Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0| IE = mibObjectValueInteger  |        Field Length (mib)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 5: IPFIX Template Set using mibObjectValue Field


NEW:
    0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Set ID = 2           |          Length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Template ID             |         Field Count = 2       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0| IE = Existing IPFIX Field   |        Field Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0| IE = <mibObjectValue>      |        Field Length (mib)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 5: IPFIX Template Set using mibObjectValue Field

Then you have to explain that <mibObjectValue> could be 
     mibObjectValueInteger,
      mibObjectValueOctetString, mibObjectValueOID, mibObjectValueBITS,
      mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTime,
      mibObjectValueUnsigned, mibObjectValueTable and
      mibObjectValueSequence.


I stopped my review at section 4.4.2, but plenty of my feedback would apparently be equivalent for the rest of the draft.


Regards, Benoit


Hi all:

Sorry to be a little slow with this - the dust has settled from IETF-89,
and I've almost managed to catch up.

The WG Last Call for our MIB Variable Export draft starts now,
and will end on Wednesday, 30 April.

Please read it, and - better still - post reviews of it to the IPFIX list!

Cheers, Nevil


--------------080804080705040804010304-- From nobody Fri Apr 25 06:35:02 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 8D4D21A04B6 for ; Fri, 25 Apr 2014 06:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 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, RP_MATCHES_RCVD=-0.272, 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 fdyCpH-mMDVQ for ; Fri, 25 Apr 2014 06:34:54 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4579E1A04B1 for ; Fri, 25 Apr 2014 06:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42785; q=dns/txt; s=iport; t=1398432887; x=1399642487; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=GWrmRIo+jdSsbvH9YIK0RrBKPxoa4i4raMaFwRwx5AE=; b=R324jnHWPlHfwiwhnRm4FgrI3VttWM17LHLPfZz74MtwmbY+3HYvmn/h j7RxbFnSJlkDOUGvHvriQkMDkaUZsk3/WVDRO1glnNo2RZK24QTU8GMIf xxZ7O/Z1hhJhiCTvHpB0F1utxheV4P97IOJzfzphPdieHlDMKoJ5V8feV U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEADxjWlOtJssW/2dsb2JhbABZDoNHiRmyY4h6gSV0giUBAQEDARoBAgpACwYRCw4KCRYBAQ0JAwIBAgFFBgEMCAEBF4geCA3KcReOYIQ5AQOZBYE4hSOMAYJxQjs X-IronPort-AV: E=Sophos; i="4.97,927,1389744000"; d="scan'208,217"; a="26330734" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 25 Apr 2014 13:34:44 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3PDYixp022156; Fri, 25 Apr 2014 13:34:44 GMT Message-ID: <535A6474.5030706@cisco.com> Date: Fri, 25 Apr 2014 15:34:44 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nevil Brownlee , IPFIX Working Group References: <534C76C7.9030108@auckland.ac.nz> <20140418162115.GA3046@elstar.local> In-Reply-To: <20140418162115.GA3046@elstar.local> Content-Type: multipart/alternative; boundary="------------070600040808040100070808" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/vcF14SDlU7pMCHFspUAG3_CWSaY Subject: Re: [IPFIX] WGLC for draft-ietf-ipfix-mib-variable-export-05 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, 25 Apr 2014 13:35:00 -0000 This is a multi-part message in MIME format. --------------070600040808040100070808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Some feedback on the sections I already reviewed. Note that I agree with Juergen's feedback. > On Tue, Apr 15, 2014 at 12:01:11PM +1200, Nevil Brownlee wrote: >> Hi all: >> >> Sorry to be a little slow with this - the dust has settled from IETF-89, >> and I've almost managed to catch up. >> >> The WG Last Call for our MIB Variable Export draft starts now, >> and will end on Wednesday, 30 April. >> >> Please read it, and - better still - post reviews of it to the IPFIX list! >> > I have reviewed the document and I believe it is not ready. The main > points: > > - Terminology needs to be aligned with SMIv2 > - I spotted several errors in the examples > - Major issues with the IE definitions in section 10 > - I also believe the introductionary text needs to improve. > > /js > > I have reviewed draft-ietf-ipfix-mib-export-05 and I think it is not > ready and requires improvements. > > 1) The introduction contains details of the solution. I think it > should instead contain the motivation and the architectural model > currently in section 2. The new introduction should then be > followed by a terminology section before an overview of the > solution is provided (so that the terminology is defined). This is > primarily text reorganization. The following text could be cut/pasted from the Introduction to a new section "High Level Solution Overview", somewhere after the terminology section: This document specifies a method for creating IPFIX Option Templates that are used to export the extra data required to describe MIB variables (seeSection 4.1 ). This allows IPFIX Templates to contain any combination of fields defined by traditional IPFIX Information Element(s) and/or MIB Object Identifier(s). The MIB Object Identifiers can reference either non- indexed or indexed MIB object(s). Enterprise-specific MIB Object Identifiers are also supported. This document also defines three standard Option Templates (see Section 4.2 ) that are used as part of the mechanism to export MIB Object meta data: o mibFieldOption (Section 4.2.1 ) o mibSubFieldOption (Section 4.2.2 ) o mibTypeOption (Section 4.2.3 ) This document defines three classes of new IPFIX Information Elements. These are used to export values from the MIB, export required Object Identifier information, and optionally export type data from a MIB Module: o mibObjectValue Information Elements (Section 10.1 ) o mibFieldOption Information Elements (Section 10.2 ) o mibTypeInformation Information Elements (Section 10.3 ) > > 2) I have trouble to understand the Figure "Architectural Overview". > I think this should be removed. Figure 4 is more useful and it is > at the right place in the document. Agreed. > > 3) I have terminology issues in several places. For example, RFC 2578 > uses the term 'columnar object' for what this document seems to > call 'indexed object'. Why is it useful to call Flow Records Data > Records? Using two terms for the same thing may just adds potential > for confusion. From RFC 7011: +------------------+---------------------------------------------+ | | Contents | | +--------------------+------------------------+ | Set | Template | Record | +------------------+--------------------+------------------------+ | Data Set | / | Data Record(s) | +------------------+--------------------+------------------------+ | Template Set | Template Record(s) | / | +------------------+--------------------+------------------------+ | Options Template | Options Template | / | | Set | Record(s) | | +------------------+--------------------+------------------------+ Figure A: Terminology Summary Table Section 3 provides: This document prefers the more generic term "Data Record" (as opposed to "Flow Record") in relation to the export of MIB objects. So flow record should be changed to data records throughout the doc. > I also think more SMIv2 terms must be imported, such > as MIB module, MIB object, columnar object, ... > > 4) There is a statement that providing index information for columnar > objects is optional. I have some difficulty to understand why this > is useful. What does "a MIB object is used purely as type > information" mean? How can an exporting process not have access to > index information of a columnar object? > > 5) The terminology sections says a "MIB Object Identifier" is an ASCII > character string of a certain format but it seems later a BER > encoded representation is used for mibObjectIdentifier. This seems > inconsistent. > > 6) "exporting a value from a MIB does not imply that the SNMP process > on the device supports that MIB" > > Proper wording would be something like this: > > "exporting a value of a MIB object defined in a certain MIB module > does not imply that the SNMP prcess on the device supports that > MIB module" > > Similarly, "exporting MIBs in IPFIX" should be "exporting values of > MIB objects". > > The paragraph on page 9 is also the first occurance of the term > "MIB Field" - without a clear definition what this means. > > 7) This text needs rewrite: > > Since these values are statically defined in the MIB they are not > expected to change frequently. However the additional information > about the MIB may help a Collecting Process that does not have access > to the MIB. > > NEW > > Type information is statically defined in a MIB module, it is not > expected to change. However, the additional information about the > MIB Object may help a Collecting Process that does not have access > to the MIB module. > > 8) Is it mibTypeOption of mibSubTypeOption? Both words are used, or > are these different things? > > 9) I fail to parse/understand these statements: > > Forf each of these the options this draft specifies exactly which > mibObjectValue to use. > > [...] > > If the SYNTAX clause contains a Textual Convention or Subtyping the > mibObjectSyntax Information Element SHOULD be used to export this > detail to the Collecting Process. > > 10) It escapes me how mibObjectValueSequence and mibObjectValueTable > are used / encoded. And why does the first one use an ASN.1 type > name while the second uses an SMIv2 conceptual term? This seems > inconsistent, either call them mibObjectValueSequence and > mibObjectValueSequenceOf or mibObjectValueRow and > mibObjectValueTable. > > 11) This text is unclear and needs a rewrite. I think I understand > what you are trying to communicate but the wording needs > improvements. (And it is a MIB module here, not a MIB.) > > This holds true even if the data carried inside the mibObjectValue or > mibObjectIdentifier may be related to an enterprise specific MIB. > The OID itself encodes if the Object is in an Enterprise specific MIB > Module. > > 12) What does "Field Length (mib)" stand for? Is there anything > special or is this just a plain normal "Field Length"? If so, I > would rather remove the "(mib)" annotation. > > 13) I suggest to replace "more information about MIB indexing, extra > data from the MIB" with "additional information about the MIB > Object definition" > > 14) Rewrite "... a reference to a MIB that ..." - I think you mean a > MIB Object. > > Rewrite "may not have access to the MIB" -> "may not have access to > the MIB module". > > And then I am getting lost here: > > [..] It also allows the IPFIX Field Types to be extended with > any MIB Variable already defined purely through IPFIX. > > It is not clear what is communicated here. Regards, Benoit > > 15) Section 4.4.6 has more inaccurate usages of the term "MIB" but > more important, I wonder what actually the OID is that is being > shipped in mibObjectIdentifier. Is it the OID assigned to the > object type definition or is it the OID of the instance of an > object type? Have I overlooked where this is clearly defined? > > 16) Terminology: "MIB Sequence Object's INDEX clause" -> "INDEX > clause of a conceptual row object". > > 17) s/then the MIB context MUST/then the context MUST/ > > MIB context is not a defined term. There are only SNMP contexts. > (Perhaps they should have been MIB contexts but this is a > different story.) > > 18) s/the exported to export/the exporter to export/ > > 19) Section 4.8 is rather confusing, primarily because the terminology > is not aligned with SMIv2 terminology. This affects almost all > sentences. In SMIv2, terms like "MIB SEQUENCE Objects" do not > exist. SMIv2 calls this a 'conceptual row object'. This section > needs to be rewritten to align with SMIv2 terminology (this means > getting rid of almost all occurrences of 'sequence' (in any > capitalization)). Terms such as "full OID" are ambiguous unless > you say what the OID is supposed to refer to. > > The first item in 4.8 talks about ingoring the indexing of > columnar objects and later says "a columnar object may be used > purely as a data type. I have a difficulty to understand how that > would be useful. > > On page 33, a paragraph refers to section 7.7. of RFC 2578 and I > am confused what it tries to say here. So far, I assumed that the > OIDs all refer to columnar objects or conceptual row objects and > include no instance identifiers. > > I do not understand the last paragraph before section 5. > > 20) The first enumerated item in Section 5.1 says "flowStartSeconds > from [RFC7012]" but then RFC 7012 does not define this anymore > (but its predecessor RFC 5102 did). Since Section 5.2 has the same > text, the same issue needs to be resolved there. > > 21) Sections 5.1. and 5.2 both contain references to themselfs "(see > Section 5.x)" which does not seem to make much sense. Last sentence > on page 38: s/this identical/this is identical/ > > 22) I looked up the definition of cpmCPUTotal1minRev and it turns out > that this is a columnar object (which makes sense since you can > have multiple CPUs). Since you do not export information about > which CPU the load value is coming from, how useful is the > information and does this make a good example? > > 23) Section 5.3. needs a title change. It is about exporting a subset > of a conceptual row. Perhaps something like this: > > 5.3. Exporting a Conceptual Row: The OSPF Neighbor Sequence > > The last sentence on page 40 refers to Table 7 but I assume you > mean Table 5. > > 24) The BER encoding of 1.3.6.1.2.1.14.10.1 is 06082B060102010E0A01 > (10 octets) and not the 22 octets shown in Figure 28. > > 25) Section 5.4. also needs a better title, e.g. > > 5.4. Exporting an Augmented Conceptual Row: ifTable and ifXTable > > The text in section 5.4 confuses ifXEntry and IfXEntry. A possible > rewrite: > > The ifTable defined in the IF-MIB [RFC2863] is augmented by the > ifXTable (defined in the same MIB module). The OID of the > ifEntry is 1.3.6.1.2.1.2.2.1 while the OID of the augmenting > ifXEntry is 1.3.6.1.2.1.31.1.1.1. This example demonstrates how > columnar objects from the base conceptual row and the augmenting > row can be exported in a single mibObjectValueSequence data > record. > > 26) Why is the Field Length of mibObjectValueOctetString (on page 46) > 16 octets? The ifName's restriction is 255 octets. And should this > not be variable length? > > 27) page 47: s/VLAN=11/VLAN=10/ > > On page 48, I am surprised that ifType and ifMTU are both 16-bit > fields. Does the template not say they are 4 octets long? > > 28) Section 5.5. also needs a new title and the terminology used is > wrong as well. Perhaps it is: > > 5.5. Exporting a Columnar Object: ipIfStatsInForwDatagrams > > Please do not write 'ipIfStatsTable SEQUENCE'. The correct SMIv2 > term is conceptual table. (And also note that the ASN.1 type of a > table is a SEQUENCE OF and not a SEQUENCE.) > > The template in Figure 33 says the interface index is two octets. > This may be true for a certain exporter but may not be generally > true - it may be worth to be explicit about the assumption made > here that all possible interfaces are numbered such that they fit > into 16 bits. > > The BER encodings and the corresponding VLEN fields are all wrong > in Figure 35: > > 1.3.6.1.2.1.4.31.3.1.1 -> 060A2B06010201041F030101 (12 octets) > > 1.3.6.1.2.1.4.31.3.1.2 -> 060A2B06010201041F030102 (12 octets) > > 1.3.6.1.2.1.4.31.3.1.12 -> 060A2B06010201041F03010c (12 octets) > > 29) Section 5.6. needs a better title. This is about a columnar object > where the index information is provided by IPFIX information > elements. > > 5.6. Exporting a Columnar Object index by IEs: ifOutQLen > > s/be done be/be done by/ > > The text below Table 8 needs to be rewritten, e.g. > > The ifOutQLen MIB object defined in the IF-MIB [RFC2863] provides > the length of the output packet queue. This columnar object is > part of the ifEntry conceptual row and indexed by the interface > index (ifIndex). > > I am not sure I agree on the second paragraph on page 53. I tend > to believe that the index information must be provided for generic > applications to make sense out of the data. > > The BER encoding and the corresponding VLEN in Figure 39 is wrong: > > 1.3.6.1.2.1.2.2.1.21 -> 06092B0601020102020115 (11 octets) > > 30) I find the example in section 5.7 rather strange. Why would one > export the ifIndex value using mibSubIdentifier and not by > including the ifIndex proper? There does not seem to be any > savings and this mibSubIdentifier approach of course is only > applicable where the number of sub-identifier is constant for all > conceptual rows. Since I do not see that this approach is needed > nor that it adds any value in terms of more compact encodings, > I would actually prefer this to be removed and perhaps even be > disallowed. > > The BER encoding of the ifOutQLen OID is wrong, see above for the > correct value. > > (The caption of Figure 44 is kind of strange because it says > "using ifIndex" but then the example is about not using ifIndex > but instead an opaque number.) > > This section 5.7. should really be removed I think. > > 31) In section 5.8, > > s/ospfNbarEntry/ospfNbrEntry/ > > The OID encoding and the VLEN field in Figure 46 is wrong: > > 1.3.6.1.2.1.14.10.1 -> 06082B060102010E0A01 (10 octets) > > RFC 3411 uses '800002b804616263'H as an snmpEngineID in examples. > > 32) What is the meaning of this: > > If a Collecting Process receives a MIB Object Identifier that it > cannot decode, it SHOULD log an error. > > What does 'cannot decode' mean? I mean, a simple collector may > just store the records in some file / database. So what is > expected here? And why is it an error and not a warning? > > I am also not sure what the last paragraph in section 7 tells me. > What does 'purely semantic information' mean? For me, if you miss > the semantics, the data has no value. But I understand that IPFIX > people have a very different terminology at times. > > 33) It is unclear to me how the export of conceptual rows deals with > non-existing variables (aka table holes). Is there a mechanism in > IPFIX to indicate that a certain field of a flow record does not > have a value? > > Issues with section 10: > > a) In the SMIv2, we distinguish between Counter32 and Counter64 and > I think this difference important to capture since the rollover > is different. The I-D seems to map both to mibObjectValueCounter. > > b) The descriptions all use the phrase "from a MIB" but I think it > should be "of a MIB object". > > c) The SMIv2 type is IpAddress and not IPAddress. > > d) The definition of mibObjectValueCounter says "Data Type Semantics: > totalCounter". I think this is wrong since SMIv2 counters do not > start with zero. Furthermore, a Counter32 rolls over after 32-bit > and not after 64-bit (but mibObjectValueCounter is an unsigned64). > > e) The definition of mibObjectValueGauge "Data Type Semantics: > totalCounter". I think this is wrong, a Gauge32 is not a counter. > And it might be useful to call this mibObjectValueGauge32. > > f) Why did you call mibObjectValueTime not mibObjectValueTimeTicks? > The "Abstract Data Type: dateTimeMilliseconds" also seems to be > wrong since TimeTicks are _not_ measured in milliseconds since > 1970-01-01T00:00. You may want to use unsigned32 and spell out the > semantics. > > g) mibObjectValueUnsigned used the "Abstract Data Type: unsigned64" > which is wrong since there is only a 32-bit unsigned type in the > SMIv2. I suggest to use unsigned32 and to rename this to > mibObjectValueUnsigned32. > > h) The phrase "a complete MIB 'SEQUENCE OF X' or conceptual table > value" reads strange. Similarly, "a MIB SEQUENCE or a row from a > conceptual table" reads strange. Perhaps simply use "a complete > conceptual table" and "a row of a conceptual table". > > i) The lest sentence of the Description in 10.1.11 seems to be missing > some words. > > j) The description of 10.2.2 is somewhat confusing: "... that serves > as INDEX MIB Objects of Information Elements for a mibField". In > SMIv2, the INDEX is associated with a conceptual row. > > k) What does "sampled by SNMP" mean? Do you hook into the > instrumentation or do you access things via the SNMP agent? > > l) p74: s/the MIB the Flow/the MIB when the Flow/ > > (Note that you are talking about a flow here and not about a data > record. I think this is goodness and proves that a new term is not > needed.) > > m) Replace the Description in 10.3.4 with this: > > Description: The textual name of the MIB module that defines a MIB > Object. > > n) I do not understand what mibObjectSyntax would contain for an object > representing a conceptual table or a conceptual row. For say ifEntry, > would it be just "SEQUENCE { > ifIndex InterfaceIndex, > ifDescr DisplayString, > -- lots of stuff left out > }"? And what would it be for the object representing the conceptual > table? Or do you just mean what is literally in the SYNTAX clause, > excluding the referenced ASN.1 type definitions? > > For other MIB Objects, do you include subtyping information such as > range of length restrictions? What about named number enumerations > of the BITS construct, you include the whole definition (mind you > that RowStatus is really long). > > o) Remove "( also known as snmpEngineID) that" since it is potentially > misleading. > > Explanation: Every SNMP engine has a unique snmpEngineID. The > combination of a snmpEngineID value and a context names provides > the SNMP context. Note that an SNMP engine may provide access to a > non-local context, in which case the values of snmpEngineID and > contextEngineID would be different. > > --------------070600040808040100070808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Some feedback on the sections I already reviewed.
Note that I agree with Juergen's feedback.
On Tue, Apr 15, 2014 at 12:01:11PM +1200, Nevil Brownlee wrote:

Hi all:

Sorry to be a little slow with this - the dust has settled from IETF-89,
and I've almost managed to catch up.

The WG Last Call for our MIB Variable Export draft starts now,
and will end on Wednesday, 30 April.

Please read it, and - better still - post reviews of it to the IPFIX list!


I have reviewed the document and I believe it is not ready. The main
points:

- Terminology needs to be aligned with SMIv2
- I spotted several errors in the examples
- Major issues with the IE definitions in section 10
- I also believe the introductionary text needs to improve.

/js

I have reviewed draft-ietf-ipfix-mib-export-05 and I think it is not
ready and requires improvements.

1) The introduction contains details of the solution. I think it
   should instead contain the motivation and the architectural model
   currently in section 2. The new introduction should then be
   followed by a terminology section before an overview of the
   solution is provided (so that the terminology is defined). This is
   primarily text reorganization.
The following text could be cut/pasted from the Introduction to a new section "High Level Solution Overview", somewhere after the terminology section:
   This document specifies a method for creating IPFIX Option Templates
   that are used to export the extra data required to describe MIB
   variables (see Section 4.1).

   This allows IPFIX Templates to contain any combination of fields
   defined by traditional IPFIX Information Element(s) and/or MIB Object
   Identifier(s).  The MIB Object Identifiers can reference either non-
   indexed or indexed MIB object(s).  Enterprise-specific MIB Object
   Identifiers are also supported.

   This document also defines three standard Option Templates (see
   Section 4.2) that are used as part of the mechanism to export MIB
   Object meta data:

   o  mibFieldOption (Section 4.2.1)

   o  mibSubFieldOption (Section 4.2.2)

   o  mibTypeOption (Section 4.2.3)

   This document defines three classes of new IPFIX Information
   Elements.  These are used to export values from the MIB, export
   required Object Identifier information, and optionally export type
   data from a MIB Module:

   o  mibObjectValue Information Elements (Section 10.1)

   o  mibFieldOption Information Elements (Section 10.2)

   o  mibTypeInformation Information Elements (Section 10.3)


2) I have trouble to understand the Figure "Architectural Overview".
   I think this should be removed. Figure 4 is more useful and it is
   at the right place in the document.
Agreed.

3) I have terminology issues in several places. For example, RFC 2578
   uses the term 'columnar object' for what this document seems to
   call 'indexed object'. Why is it useful to call Flow Records Data
   Records? Using two terms for the same thing may just adds potential
   for confusion.
From RFC 7011:
    +------------------+---------------------------------------------+
    |                  |                 Contents                    |
    |                  +--------------------+------------------------+
    |       Set        |      Template      |         Record         |
    +------------------+--------------------+------------------------+
    |     Data Set     |          /         |     Data Record(s)     |
    +------------------+--------------------+------------------------+
    |   Template Set   | Template Record(s) |           /            |
    +------------------+--------------------+------------------------+
    | Options Template |  Options Template  |           /            |
    |       Set        |      Record(s)     |                        |
    +------------------+--------------------+------------------------+

                    Figure A: Terminology Summary Table
Section 3 provides:
   This document prefers the more generic term "Data Record" (as opposed
   to "Flow Record") in relation to the export of MIB objects.
So flow record should be changed to data records throughout the doc.
I also think more SMIv2 terms must be imported, such
   as MIB module, MIB object, columnar object, ...

4) There is a statement that providing index information for columnar
   objects is optional. I have some difficulty to understand why this
   is useful. What does "a MIB object is used purely as type
   information" mean? How can an exporting process not have access to
   index information of a columnar object?

5) The terminology sections says a "MIB Object Identifier" is an ASCII
   character string of a certain format but it seems later a BER
   encoded representation is used for mibObjectIdentifier. This seems
   inconsistent.

6) "exporting a value from a MIB does not imply that the SNMP process
   on the device supports that MIB"

   Proper wording would be something like this:

   "exporting a value of a MIB object defined in a certain MIB module
   does not imply that the SNMP prcess on the device supports that
   MIB module"

   Similarly, "exporting MIBs in IPFIX" should be "exporting values of
   MIB objects".

   The paragraph on page 9 is also the first occurance of the term
   "MIB Field" - without a clear definition what this means.

7) This text needs rewrite:

   Since these values are statically defined in the MIB they are not
   expected to change frequently.  However the additional information
   about the MIB may help a Collecting Process that does not have access
   to the MIB.

   NEW

   Type information is statically defined in a MIB module, it is not
   expected to change.  However, the additional information about the
   MIB Object may help a Collecting Process that does not have access
   to the MIB module.

8) Is it mibTypeOption of mibSubTypeOption? Both words are used, or
   are these different things?

9) I fail to parse/understand these statements:

     Forf each of these the options this draft specifies exactly which
     mibObjectValue to use.

   [...]

     If the SYNTAX clause contains a Textual Convention or Subtyping the
     mibObjectSyntax Information Element SHOULD be used to export this
     detail to the Collecting Process.

10) It escapes me how mibObjectValueSequence and mibObjectValueTable
    are used / encoded. And why does the first one use an ASN.1 type
    name while the second uses an SMIv2 conceptual term? This seems
    inconsistent, either call them mibObjectValueSequence and
    mibObjectValueSequenceOf or mibObjectValueRow and
    mibObjectValueTable.

11) This text is unclear and needs a rewrite. I think I understand
    what you are trying to communicate but the wording needs
    improvements. (And it is a MIB module here, not a MIB.)

     This holds true even if the data carried inside the mibObjectValue or
     mibObjectIdentifier may be related to an enterprise specific MIB.
     The OID itself encodes if the Object is in an Enterprise specific MIB
     Module.

12) What does "Field Length (mib)" stand for? Is there anything
    special or is this just a plain normal "Field Length"? If so, I
    would rather remove the "(mib)" annotation.

13) I suggest to replace "more information about MIB indexing, extra
    data from the MIB" with "additional information about the MIB
    Object definition"

14) Rewrite "... a reference to a MIB that ..." - I think you mean a
    MIB Object.

    Rewrite "may not have access to the MIB" -> "may not have access to
    the MIB module".

    And then I am getting lost here:

      [..] It also allows the IPFIX Field Types to be extended with
      any MIB Variable already defined purely through IPFIX.

    It is not clear what is communicated here.

Regards, Benoit

15) Section 4.4.6 has more inaccurate usages of the term "MIB" but
    more important, I wonder what actually the OID is that is being
    shipped in mibObjectIdentifier. Is it the OID assigned to the
    object type definition or is it the OID of the instance of an
    object type? Have I overlooked where this is clearly defined?

16) Terminology: "MIB Sequence Object's INDEX clause" -> "INDEX
    clause of a conceptual row object".

17) s/then the MIB context MUST/then the context MUST/

    MIB context is not a defined term. There are only SNMP contexts.
    (Perhaps they should have been MIB contexts but this is a
    different story.)

18) s/the exported to export/the exporter to export/

19) Section 4.8 is rather confusing, primarily because the terminology
    is not aligned with SMIv2 terminology. This affects almost all
    sentences. In SMIv2, terms like "MIB SEQUENCE Objects" do not
    exist. SMIv2 calls this a 'conceptual row object'. This section
    needs to be rewritten to align with SMIv2 terminology (this means
    getting rid of almost all occurrences of 'sequence' (in any
    capitalization)). Terms such as "full OID" are ambiguous unless
    you say what the OID is supposed to refer to.

    The first item in 4.8 talks about ingoring the indexing of
    columnar objects and later says "a columnar object may be used
    purely as a data type. I have a difficulty to understand how that
    would be useful.

    On page 33, a paragraph refers to section 7.7. of RFC 2578 and I
    am confused what it tries to say here. So far, I assumed that the
    OIDs all refer to columnar objects or conceptual row objects and
    include no instance identifiers.

    I do not understand the last paragraph before section 5.

20) The first enumerated item in Section 5.1 says "flowStartSeconds
    from [RFC7012]" but then RFC 7012 does not define this anymore
    (but its predecessor RFC 5102 did). Since Section 5.2 has the same
    text, the same issue needs to be resolved there.

21) Sections 5.1. and 5.2 both contain references to themselfs "(see
    Section 5.x)" which does not seem to make much sense. Last sentence
    on page 38: s/this identical/this is identical/

22) I looked up the definition of cpmCPUTotal1minRev and it turns out
    that this is a columnar object (which makes sense since you can
    have multiple CPUs). Since you do not export information about
    which CPU the load value is coming from, how useful is the
    information and does this make a good example?

23) Section 5.3. needs a title change. It is about exporting a subset
    of a conceptual row. Perhaps something like this:

    5.3.  Exporting a Conceptual Row: The OSPF Neighbor Sequence

    The last sentence on page 40 refers to Table 7 but I assume you
    mean Table 5.

24) The BER encoding of 1.3.6.1.2.1.14.10.1 is 06082B060102010E0A01
    (10 octets) and not the 22 octets shown in Figure 28.

25) Section 5.4. also needs a better title, e.g.

    5.4.  Exporting an Augmented Conceptual Row: ifTable and ifXTable

    The text in section 5.4 confuses ifXEntry and IfXEntry. A possible
    rewrite:

      The ifTable defined in the IF-MIB [RFC2863] is augmented by the
      ifXTable (defined in the same MIB module). The OID of the
      ifEntry is 1.3.6.1.2.1.2.2.1 while the OID of the augmenting
      ifXEntry is 1.3.6.1.2.1.31.1.1.1. This example demonstrates how
      columnar objects from the base conceptual row and the augmenting
      row can be exported in a single mibObjectValueSequence data
      record.

26) Why is the Field Length of mibObjectValueOctetString (on page 46)
    16 octets? The ifName's restriction is 255 octets. And should this
    not be variable length?

27) page 47: s/VLAN=11/VLAN=10/

    On page 48, I am surprised that ifType and ifMTU are both 16-bit
    fields. Does the template not say they are 4 octets long?

28) Section 5.5. also needs a new title and the terminology used is
    wrong as well. Perhaps it is:

    5.5.  Exporting a Columnar Object: ipIfStatsInForwDatagrams

    Please do not write 'ipIfStatsTable SEQUENCE'. The correct SMIv2
    term is conceptual table. (And also note that the ASN.1 type of a
    table is a SEQUENCE OF and not a SEQUENCE.)

    The template in Figure 33 says the interface index is two octets.
    This may be true for a certain exporter but may not be generally
    true - it may be worth to be explicit about the assumption made
    here that all possible interfaces are numbered such that they fit
    into 16 bits.

    The BER encodings and the corresponding VLEN fields are all wrong
    in Figure 35:

    1.3.6.1.2.1.4.31.3.1.1  -> 060A2B06010201041F030101 (12 octets)

    1.3.6.1.2.1.4.31.3.1.2  -> 060A2B06010201041F030102 (12 octets)

    1.3.6.1.2.1.4.31.3.1.12 -> 060A2B06010201041F03010c (12 octets)

29) Section 5.6. needs a better title. This is about a columnar object
    where the index information is provided by IPFIX information
    elements. 

    5.6.  Exporting a Columnar Object index by IEs: ifOutQLen

    s/be done be/be done by/

    The text below Table 8 needs to be rewritten, e.g.

    The ifOutQLen MIB object defined in the IF-MIB [RFC2863] provides
    the length of the output packet queue. This columnar object is
    part of the ifEntry conceptual row and indexed by the interface
    index (ifIndex).

    I am not sure I agree on the second paragraph on page 53. I tend
    to believe that the index information must be provided for generic
    applications to make sense out of the data.

    The BER encoding and the corresponding VLEN in Figure 39 is wrong:

    1.3.6.1.2.1.2.2.1.21 -> 06092B0601020102020115 (11 octets)

30) I find the example in section 5.7 rather strange. Why would one
    export the ifIndex value using mibSubIdentifier and not by
    including the ifIndex proper? There does not seem to be any
    savings and this mibSubIdentifier approach of course is only
    applicable where the number of sub-identifier is constant for all
    conceptual rows. Since I do not see that this approach is needed
    nor that it adds any value in terms of more compact encodings,
    I would actually prefer this to be removed and perhaps even be
    disallowed.

    The BER encoding of the ifOutQLen OID is wrong, see above for the
    correct value.

    (The caption of Figure 44 is kind of strange because it says
     "using ifIndex" but then the example is about not using ifIndex
     but instead an opaque number.)

    This section 5.7. should really be removed I think.

31) In section 5.8,

    s/ospfNbarEntry/ospfNbrEntry/

    The OID encoding and the VLEN field in Figure 46 is wrong:

    1.3.6.1.2.1.14.10.1 -> 06082B060102010E0A01 (10 octets)

    RFC 3411 uses '800002b804616263'H as an snmpEngineID in examples.

32) What is the meaning of this:

      If a Collecting Process receives a MIB Object Identifier that it
      cannot decode, it SHOULD log an error.

    What does 'cannot decode' mean? I mean, a simple collector may
    just store the records in some file / database. So what is
    expected here? And why is it an error and not a warning?

    I am also not sure what the last paragraph in section 7 tells me.
    What does 'purely semantic information' mean? For me, if you miss
    the semantics, the data has no value. But I understand that IPFIX
    people have a very different terminology at times.

33) It is unclear to me how the export of conceptual rows deals with
    non-existing variables (aka table holes). Is there a mechanism in
    IPFIX to indicate that a certain field of a flow record does not
    have a value?

Issues with section 10:

a) In the SMIv2, we distinguish between Counter32 and Counter64 and
   I think this difference important to capture since the rollover
   is different. The I-D seems to map both to mibObjectValueCounter.

b) The descriptions all use the phrase "from a MIB" but I think it
   should be "of a MIB object".

c) The SMIv2 type is IpAddress and not IPAddress.

d) The definition of mibObjectValueCounter says "Data Type Semantics:
   totalCounter". I think this is wrong since SMIv2 counters do not
   start with zero. Furthermore, a Counter32 rolls over after 32-bit
   and not after 64-bit (but mibObjectValueCounter is an unsigned64).

e) The definition of mibObjectValueGauge "Data Type Semantics:
   totalCounter". I think this is wrong, a Gauge32 is not a counter.
   And it might be useful to call this mibObjectValueGauge32.

f) Why did you call mibObjectValueTime not mibObjectValueTimeTicks?
   The "Abstract Data Type: dateTimeMilliseconds" also seems to be
   wrong since TimeTicks are _not_ measured in milliseconds since
   1970-01-01T00:00. You may want to use unsigned32 and spell out the
   semantics.

g) mibObjectValueUnsigned used the "Abstract Data Type: unsigned64"
   which is wrong since there is only a 32-bit unsigned type in the
   SMIv2. I suggest to use unsigned32 and to rename this to
   mibObjectValueUnsigned32.

h) The phrase "a complete MIB 'SEQUENCE OF X' or conceptual table
   value" reads strange. Similarly, "a MIB SEQUENCE or a row from a
   conceptual table" reads strange. Perhaps simply use "a complete
   conceptual table" and "a row of a conceptual table".

i) The lest sentence of the Description in 10.1.11 seems to be missing
   some words.

j) The description of 10.2.2 is somewhat confusing: "... that serves
   as INDEX MIB Objects of Information Elements for a mibField". In
   SMIv2, the INDEX is associated with a conceptual row.

k) What does "sampled by SNMP" mean? Do you hook into the
   instrumentation or do you access things via the SNMP agent?

l) p74: s/the MIB the Flow/the MIB when the Flow/

   (Note that you are talking about a flow here and not about a data
   record. I think this is goodness and proves that a new term is not
   needed.)

m) Replace the Description in 10.3.4 with this:

      Description: The textual name of the MIB module that defines a MIB
      Object.

n) I do not understand what mibObjectSyntax would contain for an object
   representing a conceptual table or a conceptual row. For say ifEntry,
   would it be just "SEQUENCE {
        ifIndex                 InterfaceIndex,
	ifDescr                 DisplayString,
	-- lots of stuff left out
   }"? And what would it be for the object representing the conceptual
   table? Or do you just mean what is literally in the SYNTAX clause,
   excluding the referenced ASN.1 type definitions?

   For other MIB Objects, do you include subtyping information such as
   range of length restrictions? What about named number enumerations
   of the BITS construct, you include the whole definition (mind you
   that RowStatus is really long).

o) Remove "( also known as snmpEngineID) that" since it is potentially
   misleading.

   Explanation: Every SNMP engine has a unique snmpEngineID. The
   combination of a snmpEngineID value and a context names provides
   the SNMP context. Note that an SNMP engine may provide access to a
   non-local context, in which case the values of snmpEngineID and
   contextEngineID would be different.

--------------070600040808040100070808--