From janovak@cisco.com Mon Nov 1 04:23:38 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B7AA3A681B for ; Mon, 1 Nov 2010 04:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkFeYcohpu74 for ; Mon, 1 Nov 2010 04:23:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DF08F3A67E6 for ; Mon, 1 Nov 2010 04:23:36 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsEAPM/zkyQ/khLgWdsb2JhbAChVhUBARYiIp9gm1uCc4JSBI1i X-IronPort-AV: E=Sophos;i="4.58,273,1286150400"; d="scan'208";a="68015470" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 01 Nov 2010 11:23:37 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oA1BNb0h021232 for ; Mon, 1 Nov 2010 11:23:37 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Nov 2010 12:23:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Nov 2010 12:23:36 +0100 Message-ID: <6674CF9A9F682245A590204F819F78AD031094A9@XMB-AMS-107.cisco.com> In-Reply-To: <201010181432.o9IEWDv2007072@alpd052.aldc.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Fwd: I-D Action:draft-akhter-ipfix-perfmon-00.txt Thread-Index: Actu3rqKhuaUc2clRT2USBwOdVQ4wgK1i9jA References: <201010181432.o9IEWDv2007072@alpd052.aldc.att.com> From: "Jan Novak (janovak)" To: , "Aamer Akhter (aakhter)" X-OriginalArrivalTime: 01 Nov 2010 11:23:37.0428 (UTC) FILETIME=[3A4CD140:01CB79B7] Subject: Re: [IPFIX] Fwd: I-D Action:draft-akhter-ipfix-perfmon-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 11:23:38 -0000 Hi Aamer, Had a quick read - just would have couple of comments on it: Measurement Timing in 4.1.1 - it is referenced several times from other sections but it does not actually contain some definition or at least offer of options regarding some measurement interval (or in the text above it you mention reporting interval - is that one defined in RTP specs then ??) Is the measurement interval the duration of the flow or for a fixed time period and also what and how (using what time interval) is calculated and exported=20 when the flow info is exported from the cache (either after the flow inactivity expiry or due to long flow duration) Observation Point - the term is used/defined in IPIX specs a bit differently so may be it would help to align it with those or rename the term for this draft Jan The climate of Edinburgh is such that the weak succumb young ....=20 and the strong envy them. Dr. Johnson -----Original Message----- From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of Al Morton Sent: 18 October 2010 15:33 To: ipfix@ietf.org; Aamer Akhter (aakhter) Subject: [IPFIX] Fwd: I-D Action:draft-akhter-ipfix-perfmon-00.txt >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-akhter-ipfix-perfmon-00.txt nfo/ipfix From bclaise@cisco.com Thu Nov 4 02:42:26 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA1A3A69CA for ; Thu, 4 Nov 2010 02:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4wH4APkxH5X for ; Thu, 4 Nov 2010 02:42:25 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 032D23A69D1 for ; Thu, 4 Nov 2010 02:42:21 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oA49cYal003145; Thu, 4 Nov 2010 10:38:34 +0100 (CET) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oA49cXfY002454; Thu, 4 Nov 2010 10:38:33 +0100 (CET) Message-ID: <4CD27F19.6060801@cisco.com> Date: Thu, 04 Nov 2010 10:38:33 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Nevil Brownlee References: <4CC8C7F9.8000903@auckland.ac.nz> In-Reply-To: <4CC8C7F9.8000903@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] Agenda for IPFIX meeting at IETF 70 in Beijing X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 09:42:26 -0000 Hi Nevil, I would like to present: http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-02 I believe it will be required in the next charter, as the missing between all the mediation drafts. Regards, Benoit > > Hi all: > > The first (-00.txt) draft of our agenda is now at > http://www.ietf.org/proceedings/79/agenda/ipfix.txt > > Comments/changes/suggestions to me please. > > Also, would authors who want to present drafts - especially 'possible > new work' drafts - please let me know who will be presenting. > > Cheers, Nevil > From n.brownlee@auckland.ac.nz Thu Nov 4 16:37:54 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DDB53A6948 for ; Thu, 4 Nov 2010 16:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHD9LFpqkjvH for ; Thu, 4 Nov 2010 16:37:53 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 108FD3A69F7 for ; Thu, 4 Nov 2010 16:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1288913884; x=1320449884; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4CD343D9.40305@auckland.ac.nz>|Date:=20Fr i,=2005=20Nov=202010=2012:38:01=20+1300|From:=20Nevil=20B rownlee=20|MIME-Version:=201.0 |To:=20IPFIX=20Working=20Group=20 |Subject:=20Agenda=20for=20Beijing |Content-Transfer-Encoding:=207bit; bh=ISY8D+I1JDzh3rT5ZNTc6Jk47rMSvQ9wwzhff0MnU3E=; b=OnYWHcugzHN8ulP9XQq0fe4gxlESP+DXciOpSuP23CZgY5d7qjLQXgC2 wUoDb40YQs6kVi43PtiDPKpqEwgPxCTCnwuTnUGpOBV90XjoO2F8jwxNm pzkwEns0/2WN6Mwi2kYp3Gm6GMriMig5n7ruR1JXi1m4JAybmriUX0LoB c=; X-IronPort-AV: E=Sophos;i="4.58,298,1286103600"; d="scan'208";a="34215510" 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; 05 Nov 2010 12:38:01 +1300 Message-ID: <4CD343D9.40305@auckland.ac.nz> Date: Fri, 05 Nov 2010 12:38:01 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Agenda for Beijing X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 23:37:54 -0000 Hi all: I've posted the (slightly re-worked) agenda to the Meeting Materials page, but it doesn't seem to have updated there. So here it is, appended below. Those who wish to present, please email me your slides by 1000 on Wednesday morning! If you're not in Bejing, we will have a Webex setup, so you should be able to hear the audio and see the slides as presentations are given. However, the Webex at the Beijing venue won;t be able to handle incoming questions; you'll have to use Jabber for that. Which reminds me, it would be a big help to organise a meeting scribe and Jabber scribe *before* the meeting. If you could help with that, do please email me :-) Cheers, Nevil ========================================= IP Flow Information Export WG (ipfix) Agenda for IETF #79, Beijing Wednesday 10 November, 0900-1130, Jade 1 ========================================= Chairs: Juergen Quittek Nevil Brownlee AGENDA: 1. Agenda review = 5 min 2. Update from last meeting / WG Status (Nevil) = 15 min Mediators Problem Statement - published, RFC 5982 Export-per-sctp-Stream - in queue, waiting on sctpstream-reset Mediators-framework - in AD Followup Anonymisation Support - in IETF Last Call Config Model - being reviewed by MIB Doctors Flow Selection Techniques - WGLC done, waiting for -03 3. Current WG drafts = 20 min a) Export of Structured Data in IPFIX draft-ietf-ipfix-structured-data-03, 11 Oct 10 2nd WG LC started 18 Oct 10 d) PSAMP MIB draft-ietf-ipfix-psamp-mib-01.txt, 27 Jul 10 4. What next for IPFIX? Real soon now - say before IETF 80 - we should have completed the current IPFIX work items. We're now ready to consider how IPFIX should develop. This section of the agenda is intended as (the beginning of) our re-chartering discussions ... a) Progressing IPFIX Standards-Track RFCs to Draft Standard = 20 min - Fix errata, add clarification text, would we need anything else? - Would need inter-operation reports from several implementors. Could we hold an interop event concurrent with IETF 80? b) Information Elements - draft-trammell-ipfix-ie-doctors-00 = 15 min 1 Oct 10 Guidelines for Information Elements Could also address questions like sub-registries and versioning c) Protocol for IPFIX Mediations (Benoit Claise) = 15 min draft-claise-ipfix-mediation-protocol-02 25 Oct 10 d) Other new drafts (that export new kinds of information) = 45 min - draft-kashima-ipfix-data-link-layer-monitoring-04 26 Oct 10 Exporting link-layer information - draft-johnson-ipfix-mib-variable-export-00.txt 19 Oct 10 Exporting MIB objects - draft-akhter-ipfix-perfmon-01.txt 25 Oct 10 App and Network Performance measurements - draft-claise-export-application-info-in-ipfix-00 16 Oct 10 Exporting Application Tags 5. Any Other Business = 15 min Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=79 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org -- --------------------------------------------------------------------- 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 bclaise@cisco.com Fri Nov 5 10:31:49 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FA603A68CE for ; Fri, 5 Nov 2010 10:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sn0tOXil6s4 for ; Fri, 5 Nov 2010 10:31:48 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 016F63A6809 for ; Fri, 5 Nov 2010 10:31:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oA5HW0Ie012563 for ; Fri, 5 Nov 2010 18:32:00 +0100 (CET) Received: from [10.61.97.29] (dhcp-10-61-97-29.cisco.com [10.61.97.29]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oA5HVw5f010616 for ; Fri, 5 Nov 2010 18:31:58 +0100 (CET) Message-ID: <4CD43F8E.8010406@cisco.com> Date: Fri, 05 Nov 2010 18:31:58 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <4CBDB0B8.1050906@cisco.com> <20101019152346.GA21718@elstar.local> In-Reply-To: <20101019152346.GA21718@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] Export of MIB variable in IPFIX: new IETF draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 17:31:49 -0000 Hi Juergen, Thanks for your feedback. See inline. > On Tue, Oct 19, 2010 at 04:52:40PM +0200, Benoit Claise wrote: >> Dear all, >> >> Andrew, Paul, and I posted this new draft, "Exporting MIB variables >> using the IPFIX Protocol". >> http://www.ietf.org/staging/draft-johnson-ipfix-mib-variable-export-00.txt >> >> Abstract >> >> This document specifies a way to export Management >> Information Base (MIB) objects within the IPFIX protocol, >> avoiding the need to define new IPFIX Information Elements >> for existing Management Information Base objects that are >> already fully specified. >> >> This method requires an extension to the current IPFIX >> protocol. New Template Set and Options Template Sets are >> specified to allow the export of Simple Network Management >> Protocol (SNMP) MIB Objects. >> >> >> The problem we want to solve is that we keep development two data >> models for a unique information model (*) , i.e. MIB and IPFIX >> information elements, which are overlapping. For example: there is >> an IPFIX information element representing the ifName MIB Object. >> Note that some more advantages are specified in the draft. >> (*) RFC 3444, "On the Difference between Information Models and Data Models" >> >> Please read it and send your feedback. > I do not have time for a detailed review, but some things already > come to mind: > > a) I find text like this in several places: > > An alphanumeric-format variable name which denotes a > variable name expressed as a sequence of decimal numbers or > names separated by periods, as specified by the OBJECT > IDENTIFIER in [RFC2578]. > > As far as I can tell, RFC 2578 does not specify a format with names > separated by periods (and terminology wise 2578 call these "names" > descriptors). Good, we will update this. > b) It is good to see that you require authorization via VACM. However, > this requires that in addition to the variableName the following > is known (see RFC 3415): > > securityModel -- Security Model in use > securityName -- principal who wants access > securityLevel -- Level of Security > viewType -- read, write, or notify view > contextName -- context containing variableName Actually, I know what I want to write, but I'm not sure how to write it ;-) Basically, we can't bypass the SNMP authorization. > c) In the SNMP world, a variable exists in a context. A context is > identified by a contextEngineID and a contextName (see RFC 3411). > I think you need to make sure this is captured somewhere. Yes, we forgot this one. Thanks for your review. Regards, Benoit. > > From a quick read, I have not yet understood how the index handling > works. But I might see if I take more time to read in detail. > > /js > From trammell@tik.ee.ethz.ch Mon Nov 8 01:53:13 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF2A13A692F for ; Mon, 8 Nov 2010 01:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EM6vSrqZ9m0p for ; Mon, 8 Nov 2010 01:53:12 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id D4C293A692C for ; Mon, 8 Nov 2010 01:53:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D6E97D9320 for ; Mon, 8 Nov 2010 10:53:31 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 70UCUDBlklvE for ; Mon, 8 Nov 2010 10:53:31 +0100 (MET) Received: from dhcp-48cb.meeting.ietf.org (dhcp-48cb.meeting.ietf.org [130.129.72.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id D300BD931C for ; Mon, 8 Nov 2010 10:53:30 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Nov 2010 17:53:26 +0800 Message-Id: To: ipfix@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [IPFIX] Structured Data WGLC comments X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 09:53:13 -0000 Greetings, all, I have the following two comments on = draft-ietf-ipfix-structured-data-03. First, I don't necessarily find the repeated examples showing how = variable length Information Elements work to be particularly useful, but = I accept that this might be because I already know how they work. What I _am_ missing, however, are unified diagrams showing how the = structured data Information Elements and variable-length encoding work = together: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | Length (0 to 65535) | Semantic | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Information Element ID | Element Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | basicList content . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Second, Section 5.4 is missing a discussion of when you shouldn't use = Structured Data _at all_: i.e., when there is low or no semantic = variation among records represented by a template. Consequently, I'm not = sure about section 9.3. It seems like although we _could_ use structured = data for biflows, the suggested approach misses the 1. semantic clarity = and 2. export efficiency that were aims of 5103. Beyond these points, I've reviewed the draft, and it looks good. Best regards, Brian= From Internet-Drafts@ietf.org Mon Nov 8 05:45:05 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094CC3A67D1; Mon, 8 Nov 2010 05:45:05 -0800 (PST) X-Quarantine-ID: <9gSJyWAOxFyI> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: unexpected end of preamble X-Spam-Flag: NO X-Spam-Score: -99.236 X-Spam-Level: X-Spam-Status: No, score=-99.236 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599, MISSING_MIME_HB_SEP=2.119, SARE_BOUNDARY_LC=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gSJyWAOxFyI; Mon, 8 Nov 2010 05:45:04 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E793A67AE; Mon, 8 Nov 2010 05:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextpart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no Message-ID: <20101108134502.3057.87402.idtracker@localhost> Date: Mon, 08 Nov 2010 05:45:02 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-psamp-mib-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 13:45:05 -0000 --NextPart 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 : Definitions of Managed Objects for Packet Sampling Author(s) : T. Dietz, et al. Filename : draft-ietf-ipfix-psamp-mib-02.txt Pages : 27 Date : 2010-11-08 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the IPFIX MIB module [RFC5815]. For IPFIX implementations that use packet sampling (PSAMP) techniques as described in [RFC5475], this memo defines the PSAMP MIB module containing managed objects for providing information on applied packet selection functions and their parameters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-psamp-mib-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-psamp-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-08053155.I-D@ietf.org> --NextPart-- From Thomas.Dietz@neclab.eu Mon Nov 8 07:37:43 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375AF3A6807 for ; Mon, 8 Nov 2010 07:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68biQWLVCjpE for ; Mon, 8 Nov 2010 07:37:40 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 977473A689E for ; Mon, 8 Nov 2010 07:37:39 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id C6A492C0001B0; Mon, 8 Nov 2010 16:38:00 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLIAQ+POGGmy; Mon, 8 Nov 2010 16:38:00 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 708572C0001AF; Mon, 8 Nov 2010 16:37:50 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.19]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0255.000; Mon, 8 Nov 2010 16:37:50 +0100 From: Thomas Dietz To: "ipfix@ietf.org" Thread-Topic: New Version Notification for draft-ietf-ipfix-psamp-mib-02 Thread-Index: AQHLf0lk/xsosG8tEEyEwBlnR9PuXZNnti3g Date: Mon, 8 Nov 2010 15:37:49 +0000 Message-ID: <75581E268A48F849916117B977D76D37078E12A9@DAPHNIS.office.hd> References: <20101108133156.8FF4A3A69FE@core3.amsl.com> In-Reply-To: <20101108133156.8FF4A3A69FE@core3.amsl.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.28] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003D_01CB7F63.4750F950" MIME-Version: 1.0 Cc: Juergen Quittek Subject: Re: [IPFIX] New Version Notification for draft-ietf-ipfix-psamp-mib-02 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 15:37:43 -0000 ------=_NextPart_000_003D_01CB7F63.4750F950 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Dear all, I just updated the PSAMP MIB with the information gathered. Usigned64TC from APPLICATION-MIB is now used for unsigned64 values. PsampFloat64 is still there since there seems to be no adequate substitution out there. I did also some minor updates to the security consideration section. That should be finished then. Hope this version now addresses all concerns and open issues. Best Regards, Thomas -- Thomas Dietz NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 Heidelberg, Germany NEC Europe Limited, Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Montag, 8. November 2010 14:32 > To: dietz@neclab.eu > Cc: bclaise@cisco.com; Juergen Quittek > Subject: New Version Notification for draft-ietf-ipfix-psamp-mib-02 > > > A new version of I-D, draft-ietf-ipfix-psamp-mib-02.txt has been > successfully submitted by Thomas Dietz and posted to the IETF repository. > > Filename: draft-ietf-ipfix-psamp-mib > Revision: 02 > Title: Definitions of Managed Objects for Packet Sampling > Creation_date: 2010-11-08 > WG ID: ipfix > Number_of_pages: 27 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes extensions to the IPFIX MIB module > [RFC5815]. For IPFIX implementations that use packet sampling > (PSAMP) techniques as described in [RFC5475], this memo defines the > PSAMP MIB module containing managed objects for providing information > on applied packet selection functions and their parameters. > > > > The IETF Secretariat. > ------=_NextPart_000_003D_01CB7F63.4750F950 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNDCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFNTCCBB2gAwIBAgIED+0gWzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0xMDA0MjAxMjQ5MTVaFw0xMzA0MTkxMjQ5MTVaMGAx CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQD2mMcvPbgraEaWMV6uNCs6t88lhBczgfxybD46mwr8D3VaQLEnqTsBOAf/ Y8ARtq+P6Dkm2MBMXQG+Ebo2qhif6O4dH7whcG9E88F9247R2EJjcXmxMYZWYGQTI2vGw/joerRB waiwfxCXWBTLutbdWEEKL/DG9A1yQRPGJc+jJYfgm0ekYn+WESOLYaBH7G9aIIZQ7en3afhPpbQA Ajh92K240TG+VgBpe1vnDdth28Ps5XeN+otookDZHwwGQYwYrPZJtnhGIyjKMm7OkXL62Rf3aSoI doVUwYYS67RYYNOY0C7qOVyCUF+z4Bkn758sZhZzotiLQVT3AZ625PrvAgMBAAGjggHEMIIBwDAJ BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFH9fxgi2EshupgLF49SzaAX0QFoMMB8GA1UdIwQYMBaAFE8ch3od 4C+Z9r4VqtE1nQ5K5ro2MCEGA1UdEQQaMBiBFlRob21hcy5EaWV0ekBuZWNsYWIuZXUwfQYDVR0f BHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNy bC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2Fj cmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRm bi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8v Y2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN AQEFBQADggEBACnPHI1mIY1TVY9Aj8zsHHxiwMRx02Hp6DLZGYXHGG9IkflrRKNiDIV2LbBDpXVH vojMxTtCt10iwbyVMGaevet/VHYCJSHzrCLkw+GkvuhDU70lNsWw9P+mai7OHa+NQ6im8+4RnY1B yhqidcCt3hIV9B69ax0/KIhIFpiWz/lKZVIghki07I4m8mf1sbvCORKxudH0TVLlRJlX1r8S+8ea 9e+Q8pgXfrsCeyxBV3KAjszRQkqDZsbD7jQHQWokkMPIjbaTjw6V/5SRzmcAy0XlKNOCbldlzmCB jDZTQWdSH/AFDy5L2l4j0Ck0vVlQv+r1F4omsb4BelRq+vHd+lExggQ4MIIENAIBATCBmTCBkDEL MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzAJBgUrDgMCGgUAoIICczAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDExMDgxNTM3NDhaMCMGCSqGSIb3 DQEJBDEWBBSUNakag6P+EGBniwvZn+PDeQKkgDCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQswCQYD VQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9y aWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemll cnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQP7SBbMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCBkDEL MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzCBtwYJKoZIhvcNAQkPMYGpMIGmMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3 DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAL BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG 9w0BAQEFAASCAQAtj3vWF/ISGOdXfNDscuqT8iqhbyRlVtPefV5wVSEkqZXdVif8xyUaIpv9Ld2h 6EpjA5DXv4OpLOUiPPho9I0GRSZ7UlFKB3x5LLTt4dwv8KgNuz/6S+u/i3jvDAiniicNKL/O4h6n MmtQhqBYKVHF7lanFVMahBbvQNP2M1LESGxtTpH26ao09d/6J1/arkkVS9AozPQ2sjXAYspv0Wx3 9BOK2WD8d1E9Y024/NgQfc57z1Fl63IHYi7ShcrT4WUOzSdSHpYM13cu58Wcru2RFx3WwbJhsn5k Cp1jmFLy1kJ/Pz8wz43wyRza+/TDs5Nm4e2reEzWRw9HXEv0URnwAAAAAAAA ------=_NextPart_000_003D_01CB7F63.4750F950-- From paitken@cisco.com Mon Nov 8 08:02:16 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C43853A68DE for ; Mon, 8 Nov 2010 08:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Px4ew-2MOahz for ; Mon, 8 Nov 2010 08:02:15 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id F42373A68D8 for ; Mon, 8 Nov 2010 08:02:14 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,314,1286150400"; d="scan'208";a="179781822" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 08 Nov 2010 16:02:36 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oA8G2ZlC001249; Mon, 8 Nov 2010 16:02:35 GMT Received: from [144.254.153.57] (dhcp-144-254-153-57.cisco.com [144.254.153.57]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id oA8G2W817966; Mon, 8 Nov 2010 16:02:33 GMT Message-ID: <4CD81F1B.9020305@cisco.com> Date: Mon, 08 Nov 2010 16:02:35 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Shingo KASHIMA References: <20101008011733.3192.1AB7FA03@nttv6.net> <4CAE179B.1020102@cisco.com> <20101029171405.F0DD.1AB7FA03@nttv6.net> In-Reply-To: <20101029171405.F0DD.1AB7FA03@nttv6.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group , ipfix-chairs@tools.ietf.org Subject: Re: [IPFIX] draft-kashima-ipfix-data-link-layer-monitoring X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 16:02:16 -0000 Kashima-san, I reviewed the draft. Please find some feedback inline. > 1. Introduction > > While these renovations provide flexibility, scalability, and I think you mean "innovations". > 3. Future Traffic Measurement > > The device (Exporter) filters and/or samples Ethernet frames using > PSAMP Selector, extracts the header of the frame, and exports the > header information encoded by IPFIX protocol to the Collector. Actually the exporter doesn't do this; the metering process does. A combination of MP and exporter is required. > Furthermore, the device (Exporter) filters and samples traffic for > each VPN using a Composite Selector of PSAMP [RFC5475]. This makes > it possible to change the granularity of the traffic monitoring for > each VPN. Same comment again. Also, consider adding some details of the PSAMP process. > 4.2. dataLinkFrameSection > > > Description: > > This Information Element carries n octets from the data link frame > of a selected frame, starting dataLinkFrameOffset octets into the > frame. > > When the dataLinkFrameSectionObservedOctets field corresponding to > this Information Element does not exist, this Information Element > MUST have a variable length and MUST NOT be padded. In this case, > the size of the exported section may be constrained due to > limitations in the IPFIX protocol. I would relax the "MUST have a variable length" to a SHOULD, since fixed length sections may be exported. > When the dataLinkFrameSectionObservedOctets field corresponding to > this Information Element exists, this Information Element MAY have > a fixed length and MAY be padded, or MAY have a variable length. > > The dataLinkFrameSectionObservedOctets expresses how much data was > observed, while the remainder is padding. These two paragraphs follow the one above. I would write them in exactly the opposite order: 3, 2, 1. > Further Information Elements, i.e., dataLinkFrameType and > dataLinkFrameSize are needed to specify the data link type and the > size of the data link frame of this Information Element. A set of > these Information Elements MAY be contained in a structured data > type, as expressed in another IPFIX WG draft. You should specify the draft and include a reference. > 4.4. dataLinkFrameOffset > > > Description: > > This Information Element specifies the offset of the observed > dataLinkFrameSection within the data link frame. If this > Information Element is omitted, it defaults to zero. I thought the intention was to create a generic "offset" field which could be used with any packet section? > 4.5. dataLinkFrameSectionObservedOctets > > > Description: > > This Information Element specifies the observed length of the > dataLinkFrameSection. > > This Information Element is especially needed for NetFlow version > 9 [RFC3954] because NetFlow does not support a variable-length > Information Element. I think it would be better to say "This Information Element specifies the observed length of the dataLinkFrameSection when padding is used", and remove the second paragraph. > 6. IANA Considerations > > > This document requests that the Information Element IDs are allocated > as shown in section 4. > > In addition, the dataLinkFrameType Information Element requires the > creation of new IANA registries. I think only one new registry is needed for this. However, Nevil is leading some discussion whether the values should be defined in the IE description, rather than in separate registries. > Appendix C. Template Formats Example > > > 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 (0x0002) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID (0x0103) | Field Count (0x0006) | The field count is 8. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ingressInterface (0x000A) | Field Length (0x0004) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | egressInterface (0x000E) | Field Length (0x0004) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |observationTimeSeconds (0x0142)| Field Length (0x0008) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | dataLinkFrameSize (0x0138) | Field Length (0x0002) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | dataLinkFrameSection (0x013B) | Field Length (0xFFFF) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | dataLinkFrameType (0x015B) | Field Length (0x0002) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | dataLinkFrameOffset (0x015C) | Field Length (0x0002) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | dataLinkFrameSection (0x015D) | Field Length (0x0002) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Call it "dataLinkFrameSectionOO" (OO = Observed Octets). Else 0x015D looks like the earlier 0x013B. > > Figure C-1: Template Fortmat Example Typo, "Format". Cheers, P. From kashima@nttv6.net Mon Nov 8 10:11:35 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326F63A6824 for ; Mon, 8 Nov 2010 10:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8N+nk5Fo00V for ; Mon, 8 Nov 2010 10:11:33 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id DD8C23A67DF for ; Mon, 8 Nov 2010 10:11:32 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id oA8IBihE022259; Tue, 9 Nov 2010 03:11:49 +0900 (JST) (envelope-from kashima@nttv6.net) Date: Tue, 09 Nov 2010 02:11:10 +0800 From: Shingo KASHIMA To: Paul Aitken In-Reply-To: <4CD81F1B.9020305@cisco.com> References: <20101029171405.F0DD.1AB7FA03@nttv6.net> <4CD81F1B.9020305@cisco.com> Message-Id: <20101109014328.D0A1.1AB7FA03@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (mail.nttv6.net [IPv6:::1]); Tue, 09 Nov 2010 03:11:50 +0900 (JST) Cc: IETF IPFIX Working Group , ipfix-chairs@tools.ietf.org Subject: Re: [IPFIX] draft-kashima-ipfix-data-link-layer-monitoring X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 18:11:35 -0000 Hi Paul, Thanks for your review. Please find tree answer for your comments inline. The answer for the other comments are all "yes, I will revise as your comments". > > Further Information Elements, i.e., dataLinkFrameType and > > dataLinkFrameSize are needed to specify the data link type and the > > size of the data link frame of this Information Element. A set of > > these Information Elements MAY be contained in a structured data > > type, as expressed in another IPFIX WG draft. > > You should specify the draft and include a reference. I will refer to "Export of Structured Data in IPFIX (draft-ietf-ipfix-structured-data-03.txt)". Is that right ? > > 4.4. dataLinkFrameOffset > > > > > > Description: > > > > This Information Element specifies the offset of the observed > > dataLinkFrameSection within the data link frame. If this > > Information Element is omitted, it defaults to zero. > > I thought the intention was to create a generic "offset" field which > could be used with any packet section? I also think a generic offset is better. Then IE name should be changed to "sectionOffset". But we have one problem. We need to revise existing packet section IE's description. Is this possible ? - ipHeaderPacketSection carries a series of octets from the start of the IP header ~~~~~~~~~~~~ - ipPayloadPacketSection carries a series of octets from the start of the IP payload ~~~~~~~~~~~~ - mplsLabelStackSection carries the first n octets from the MPLS label stack ~~~~~~~~~ - mplsPayloadPacketSection carries the first n octets from the MPLS payload ~~~~~~~~~ > > 6. IANA Considerations > > > > > > This document requests that the Information Element IDs are allocated > > as shown in section 4. > > > > In addition, the dataLinkFrameType Information Element requires the > > creation of new IANA registries. > > I think only one new registry is needed for this. However, Nevil is > leading some discussion whether the values should be defined in the IE > description, rather than in separate registries. I see. To be defined in the IE description seems to be simple and good. Best Regards, Shingo. -- Shingo KASHIMA NTT Information Sharing Platform Lab. From paitken@cisco.com Mon Nov 8 14:12:17 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7EB228C0E4 for ; Mon, 8 Nov 2010 14:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RLHOifxFWcK for ; Mon, 8 Nov 2010 14:12:16 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 53D173A68D5 for ; Mon, 8 Nov 2010 14:12:16 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,171,1288569600"; d="scan'208";a="179712708" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Nov 2010 22:12:37 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA8MCau4003587; Mon, 8 Nov 2010 22:12:36 GMT Received: from [10.55.86.206] (dhcp-10-55-86-206.cisco.com [10.55.86.206]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id oA8MCX811086; Mon, 8 Nov 2010 22:12:34 GMT Message-ID: <4CD875D2.5030907@cisco.com> Date: Mon, 08 Nov 2010 22:12:34 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Shingo KASHIMA References: <20101029171405.F0DD.1AB7FA03@nttv6.net> <4CD81F1B.9020305@cisco.com> <20101109014328.D0A1.1AB7FA03@nttv6.net> In-Reply-To: <20101109014328.D0A1.1AB7FA03@nttv6.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group , ipfix-chairs@tools.ietf.org Subject: Re: [IPFIX] draft-kashima-ipfix-data-link-layer-monitoring X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 22:12:17 -0000 Kashima-san, > I will refer to "Export of Structured Data in IPFIX > (draft-ietf-ipfix-structured-data-03.txt)". > Is that right ? Yes, thanks. >>> 4.4. dataLinkFrameOffset >>> >>> >>> Description: >>> >>> This Information Element specifies the offset of the observed >>> dataLinkFrameSection within the data link frame. If this >>> Information Element is omitted, it defaults to zero. >> >> I thought the intention was to create a generic "offset" field which >> could be used with any packet section? > > I also think a generic offset is better. > Then IE name should be changed to "sectionOffset". > > But we have one problem. > We need to revise existing packet section IE's description. > Is this possible ? > - ipHeaderPacketSection > carries a series of octets from the start of the IP header > ~~~~~~~~~~~~ > - ipPayloadPacketSection > carries a series of octets from the start of the IP payload > ~~~~~~~~~~~~ > - mplsLabelStackSection > carries the first n octets from the MPLS label stack > ~~~~~~~~~ > - mplsPayloadPacketSection > carries the first n octets from the MPLS payload > ~~~~~~~~~ This is an excellent question for the working group to consider :-) You may wish to add such a slide to your presentation? >>> 6. IANA Considerations >>> >>> >>> This document requests that the Information Element IDs are allocated >>> as shown in section 4. >>> >>> In addition, the dataLinkFrameType Information Element requires the >>> creation of new IANA registries. >> >> I think only one new registry is needed for this. However, Nevil is >> leading some discussion whether the values should be defined in the IE >> description, rather than in separate registries. > > I see. > To be defined in the IE description seems to be simple and good. Consider what happens when a new value is added: the description is changed. Moving the values into a registry allows the description to remain constant - which is good, because the description is basically the field's specification, which should not change. The values in the registry represent the implementation, which is the changeable part. P. From n.brownlee@auckland.ac.nz Mon Nov 8 17:57:53 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34FC28C0FE for ; Mon, 8 Nov 2010 17:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yI2UUjs0Rc8V for ; Mon, 8 Nov 2010 17:57:51 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 9F56928C0F9 for ; Mon, 8 Nov 2010 17:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1289267895; x=1320803895; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4CD8AA9B.7000808@auckland.ac.nz>|Date:=20 Mon,=2008=20Nov=202010=2017:57:47=20-0800|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20list=20|Subject:=20B eijing=20agenda=20update|Content-Transfer-Encoding:=207bi t; bh=ToRNW5IrgzTBtrd4UFhTZUkVjvjfdRRU7ViB8QXEvIE=; b=uUzExXOV5zYg+lAIXdwlxIKfyv9Qgg2Vtr7XEHhzL0TLpViegSrFwXYx uZ/FCT3cvoSqVTV8w8xGuq+W1hkTxv3cDFVyYXGR5FxUrVb6DEXZcl9hy NZmJjjxHACfrnIZoyEvZd+jgi1XOwN5Xd1Htf0VSYRuWs8meCtrz1LXxu s=; X-IronPort-AV: E=Sophos;i="4.59,172,1288522800"; d="scan'208";a="34637687" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.39.179 - Outgoing - Outgoing-SSL Received: from dhcp-27b3.meeting.ietf.org (HELO [130.129.39.179]) ([130.129.39.179]) by mx2-int.auckland.ac.nz with ESMTP; 09 Nov 2010 14:58:05 +1300 Message-ID: <4CD8AA9B.7000808@auckland.ac.nz> Date: Mon, 08 Nov 2010 17:57:47 -0800 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Beijing agenda update X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 01:57:53 -0000 Hi all: Sorry to be slow with this - my laptop power supply died Sunday afternoon, that's slowed me down a little. Here's a slightly-updated agenda for our IPFIX meeting tomorrow morning. Those presenting, please email a copy of your slides to ipfix-chairs@ietf.org by about 10 pm this evening in Beijing. 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 ========================================= IP Flow Information Export WG (ipfix) Agenda for IETF #79, Beijing [-02] Wednesday 10 November, 0900-1130, Jade 1 ========================================= Chairs: Juergen Quittek Nevil Brownlee AGENDA: 1. Agenda review = 5 min 2. Update from last meeting / WG Status (Nevil) = 15 min Mediators Problem Statement - published, RFC 5982 Export-per-sctp-Stream - in queue, waiting on sctpstream-reset Mediators-framework - in AD Followup Anonymisation Support - in IETF Last Call Config Model - being reviewed by MIB Doctors Flow Selection Techniques - WGLC done, waiting for -03 IANA: sub-registries, versioning 3. Current WG drafts = 15 min a) Export of Structured Data in IPFIX draft-ietf-ipfix-structured-data-03, 11 Oct 10 2nd WG LC started 18 Oct 10 b) PSAMP MIB draft-ietf-ipfix-psamp-mib-02.txt, 8 Nov 10 4. What next for IPFIX? Real soon now - say before IETF 80 - we should have completed the current IPFIX work items. We're now ready to consider how IPFIX should develop. This section of the agenda is intended as (the beginning of) our re-chartering discussions ... a) Mediation-realetd drafts = 20 min - Protocol for IPFIX Mediations (Benoit Claise) draft-claise-ipfix-mediation-protocol-02 25 Oct 10 - Exporting Aggr4egated Flow Data (Brian Trammel) draft-trammell-ipfix-a9n-01.txt 25 Oct 10 b) Progressing IPFIX Standards-Track RFCs to Draft Standard = 20 min - Fix errata, add clarification text, would we need anything else? - Would need inter-operation reports from several implementors. Could we hold an interop event concurrent with IETF 80? c) Information Elements - draft-trammell-ipfix-ie-doctors-00 = 20 min 1 Oct 10 Guidelines for Information Elements Could also address questions like sub-registries and versioning d) Other new drafts (that export new kinds of information) = 45 min - draft-kashima-ipfix-data-link-layer-monitoring-04 26 Oct 10 Exporting link-layer information - draft-johnson-ipfix-mib-variable-export-00.txt 19 Oct 10 Exporting MIB objects - draft-akhter-ipfix-perfmon-01.txt 25 Oct 10 App and Network Performance measurements - draft-claise-export-application-info-in-ipfix-00 16 Oct 10 Exporting Application Tags 5. Any Other Business = 10 min Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=79 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org ------------------ From Internet-Drafts@ietf.org Mon Nov 8 18:16:27 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8CF28C299; Mon, 8 Nov 2010 18:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.863 X-Spam-Level: X-Spam-Status: No, score=-101.863 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djrUp3HuLc3t; Mon, 8 Nov 2010 18:16:25 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 252A228C1F2; Mon, 8 Nov 2010 18:15:34 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no Message-ID: <20101109021534.26008.22080.idtracker@localhost> Date: Mon, 08 Nov 2010 18:15:34 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-psamp-mib-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 02:16:27 -0000 --NextPart 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 : Definitions of Managed Objects for Packet Sampling Author(s) : T. Dietz, et al. Filename : draft-ietf-ipfix-psamp-mib-02.txt Pages : 27 Date : 2010-11-08 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the IPFIX MIB module [RFC5815]. For IPFIX implementations that use packet sampling (PSAMP) techniques as described in [RFC5475], this memo defines the PSAMP MIB module containing managed objects for providing information on applied packet selection functions and their parameters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-psamp-mib-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-psamp-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-08053155.I-D@ietf.org> --NextPart-- From kashima@nttv6.net Mon Nov 8 19:08:57 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE9D328C27E for ; Mon, 8 Nov 2010 19:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXCT1YDmV1y5 for ; Mon, 8 Nov 2010 19:08:55 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 77EA328C261 for ; Mon, 8 Nov 2010 19:08:54 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id oA93932a038044; Tue, 9 Nov 2010 12:09:08 +0900 (JST) (envelope-from kashima@nttv6.net) Date: Tue, 09 Nov 2010 11:08:52 +0800 From: Shingo KASHIMA To: Paul Aitken In-Reply-To: <4CD875D2.5030907@cisco.com> References: <20101109014328.D0A1.1AB7FA03@nttv6.net> <4CD875D2.5030907@cisco.com> Message-Id: <20101109104639.C689.1AB7FA03@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (mail.nttv6.net [IPv6:::1]); Tue, 09 Nov 2010 12:09:09 +0900 (JST) Cc: IETF IPFIX Working Group , ipfix-chairs@tools.ietf.org Subject: Re: [IPFIX] draft-kashima-ipfix-data-link-layer-monitoring X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 03:08:57 -0000 Hi Paul, Thanks for your reply. Please find my answer in-line. On Mon, 08 Nov 2010 22:12:34 +0000 Paul Aitken wrote: > Kashima-san, > > > > I will refer to "Export of Structured Data in IPFIX > > (draft-ietf-ipfix-structured-data-03.txt)". > > Is that right ? > > Yes, thanks. > > > >>> 4.4. dataLinkFrameOffset > >>> > >>> > >>> Description: > >>> > >>> This Information Element specifies the offset of the observed > >>> dataLinkFrameSection within the data link frame. If this > >>> Information Element is omitted, it defaults to zero. > >> > >> I thought the intention was to create a generic "offset" field which > >> could be used with any packet section? > > > > I also think a generic offset is better. > > Then IE name should be changed to "sectionOffset". > > > > But we have one problem. > > We need to revise existing packet section IE's description. > > Is this possible ? > > - ipHeaderPacketSection > > carries a series of octets from the start of the IP header > > ~~~~~~~~~~~~ > > - ipPayloadPacketSection > > carries a series of octets from the start of the IP payload > > ~~~~~~~~~~~~ > > - mplsLabelStackSection > > carries the first n octets from the MPLS label stack > > ~~~~~~~~~ > > - mplsPayloadPacketSection > > carries the first n octets from the MPLS payload > > ~~~~~~~~~ > > This is an excellent question for the working group to consider :-) > You may wish to add such a slide to your presentation? Yes! I will add this point to my presentation. > >>> 6. IANA Considerations > >>> > >>> > >>> This document requests that the Information Element IDs are allocated > >>> as shown in section 4. > >>> > >>> In addition, the dataLinkFrameType Information Element requires the > >>> creation of new IANA registries. > >> > >> I think only one new registry is needed for this. However, Nevil is > >> leading some discussion whether the values should be defined in the IE > >> description, rather than in separate registries. > > > > I see. > > To be defined in the IE description seems to be simple and good. > > Consider what happens when a new value is added: the description is changed. > > Moving the values into a registry allows the description to remain > constant - which is good, because the description is basically the > field's specification, which should not change. > > The values in the registry represent the implementation, which is the > changeable part. I see. Your comment is also reasonable. Then let's see existing IEs. - flowEndReason includes a value list in its description. - biflowDirection includes a value list in its description. Are there IEs which do not include a value list in their description ? Which is IPFIX IEs registries policy, to be defined in the IE description or in separate registries ? We should follow our policy. Or, dataLinkFrameType is a different kind of IE from existing IEs such as flowEndReason and biflowDirection ? Best Regards, Shingo > > P. > -- Shingo KASHIMA NTT Information Sharing Platform Lab. From HKaplan@acmepacket.com Mon Nov 8 22:02:39 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB0A63A69AE for ; Mon, 8 Nov 2010 22:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GknvaeDfnCO5 for ; Mon, 8 Nov 2010 22:02:38 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BD2663A69EE for ; Mon, 8 Nov 2010 22:02:36 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 9 Nov 2010 01:02:55 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 9 Nov 2010 01:02:55 -0500 From: Hadriel Kaplan To: Shingo KASHIMA Date: Tue, 9 Nov 2010 01:02:53 -0500 Thread-Topic: [IPFIX] draft-kashima-ipfix-data-link-layer-monitoring Thread-Index: Act/08AhzRbIGQTjQxKYpa8TgIRxGw== Message-ID: References: <20101109014328.D0A1.1AB7FA03@nttv6.net> <4CD875D2.5030907@cisco.com> <20101109104639.C689.1AB7FA03@nttv6.net> In-Reply-To: <20101109104639.C689.1AB7FA03@nttv6.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF IPFIX Working Group , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] draft-kashima-ipfix-data-link-layer-monitoring X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 06:02:40 -0000 On Nov 8, 2010, at 10:08 PM, Shingo KASHIMA wrote: > Then let's see existing IEs. > - flowEndReason includes a value list in its description. > - biflowDirection includes a value list in its description. > Are there IEs which do not include a value list in their description ? >=20 > Which is IPFIX IEs registries policy, to be defined in the IE > description or in separate registries ? > We should follow our policy. > Or, dataLinkFrameType is a different kind of IE from existing IEs > such as flowEndReason and biflowDirection ? I think he means more like mplsTopLabelType, which has an actual registry f= or its enumeration values. (See http://www.iana.org/assignments/ipfix/ipfix= .xhtml#ipfix-mpls-label-type) -hadriel From n.brownlee@auckland.ac.nz Mon Nov 8 22:19:24 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452543A6875 for ; Mon, 8 Nov 2010 22:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbP1XB7C4Mv1 for ; Mon, 8 Nov 2010 22:19:21 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 032923A690F for ; Mon, 8 Nov 2010 22:18:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1289283511; x=1320819511; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4CD8E7B0.8020408@auckland.ac.nz>|Date:=20 Mon,=2008=20Nov=202010=2022:18:24=20-0800|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20list=20|Subject:=20O ne=20more=20agenda=20item|Content-Transfer-Encoding:=207b it; bh=7lFnCfAtJPLlRUSH/2SPWf9ADilV6MHORljbmRnju5M=; b=DNIgxLUpbAIZ+rCR/XJyYFHZl6uffTWoN1dbRPtpeddd9q9GssIwE3Zu W9hshNEdOr8d4LPstLILjwJL+sznfiOxhdEAhNlMqo6KJCKr47x7e1VPI 2GZ2qwRmsRUUnul1GOCgzGK9LmCGJ4GAbrfGorXTJuhj6S+a379R3ZqWT I=; X-IronPort-AV: E=Sophos;i="4.59,173,1288522800"; d="scan'208";a="34669095" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.39.179 - Outgoing - Outgoing-SSL Received: from dhcp-27b3.meeting.ietf.org (HELO [130.129.39.179]) ([130.129.39.179]) by mx2-int.auckland.ac.nz with ESMTP; 09 Nov 2010 19:18:26 +1300 Message-ID: <4CD8E7B0.8020408@auckland.ac.nz> Date: Mon, 08 Nov 2010 22:18:24 -0800 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] One more agenda item X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 06:19:24 -0000 Hi all: One more draft added to tomorrow's agenda: - draft-kashima-ipfix-short-timer-00 11 Oct 10 Information Elements for Short Timer 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 kashima@nttv6.net Mon Nov 8 22:31:21 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 465523A6804 for ; Mon, 8 Nov 2010 22:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eP46eeVU1HaV for ; Mon, 8 Nov 2010 22:31:18 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 60F1D3A67EF for ; Mon, 8 Nov 2010 22:31:17 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id oA96VR3k039536; Tue, 9 Nov 2010 15:31:33 +0900 (JST) (envelope-from kashima@nttv6.net) Date: Tue, 09 Nov 2010 14:31:15 +0800 From: Shingo KASHIMA To: Hadriel Kaplan In-Reply-To: References: <20101109104639.C689.1AB7FA03@nttv6.net> Message-Id: <20101109141750.9AA4.1AB7FA03@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (mail.nttv6.net [IPv6:::1]); Tue, 09 Nov 2010 15:31:35 +0900 (JST) Cc: IETF IPFIX Working Group , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] draft-kashima-ipfix-data-link-layer-monitoring X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 06:31:21 -0000 Hi Hadriel and all, Thanks for your information. I undarstood IPFIX IEs have two kins of enumeration values. - To be defined as independent type e.g. mplsTopLabelType - To be defined in own description e.g. flowEndReason, biflowDirection On Tue, 9 Nov 2010 01:02:53 -0500 Hadriel Kaplan wrote: > > On Nov 8, 2010, at 10:08 PM, Shingo KASHIMA wrote: > > > Then let's see existing IEs. > > - flowEndReason includes a value list in its description. > > - biflowDirection includes a value list in its description. > > Are there IEs which do not include a value list in their description ? > > > > Which is IPFIX IEs registries policy, to be defined in the IE > > description or in separate registries ? > > We should follow our policy. > > Or, dataLinkFrameType is a different kind of IE from existing IEs > > such as flowEndReason and biflowDirection ? > > I think he means more like mplsTopLabelType, which has an actual registry for its enumeration values. (See http://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mpls-label-type) > > -hadriel -- Shingo KASHIMA NTT Information Sharing Platform Lab. From kashima@nttv6.net Mon Nov 8 22:32:07 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9D43A6973 for ; Mon, 8 Nov 2010 22:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AGSlMjbTpFH for ; Mon, 8 Nov 2010 22:31:28 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 35B8A28C132 for ; Mon, 8 Nov 2010 22:31:26 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id oA96VeeA039539; Tue, 9 Nov 2010 15:31:44 +0900 (JST) (envelope-from kashima@nttv6.net) Date: Tue, 09 Nov 2010 14:31:27 +0800 From: Shingo KASHIMA To: Nevil Brownlee In-Reply-To: <4CD8E7B0.8020408@auckland.ac.nz> References: <4CD8E7B0.8020408@auckland.ac.nz> Message-Id: <20101109142635.9AA7.1AB7FA03@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (mail.nttv6.net [IPv6:::1]); Tue, 09 Nov 2010 15:31:46 +0900 (JST) Cc: IPFIX list Subject: Re: [IPFIX] One more agenda item X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 06:32:07 -0000 Hi Nevil, Thank you for adding my draft ! Cheers, Shingo On Mon, 08 Nov 2010 22:18:24 -0800 Nevil Brownlee wrote: > > Hi all: > > One more draft added to tomorrow's agenda: > > - draft-kashima-ipfix-short-timer-00 > 11 Oct 10 Information Elements for Short Timer > > 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 > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > -- Shingo KASHIMA NTT Information Sharing Platform Lab. From HKaplan@acmepacket.com Tue Nov 9 00:05:29 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAC6A3A693D for ; Tue, 9 Nov 2010 00:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.135 X-Spam-Level: X-Spam-Status: No, score=-1.135 tagged_above=-999 required=5 tests=[AWL=-0.640, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBk8i3yBzReX for ; Tue, 9 Nov 2010 00:05:29 -0800 (PST) Received: from ETMail2.acmepacket.com (unknown [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id BE8333A6886 for ; Tue, 9 Nov 2010 00:05:28 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 9 Nov 2010 03:05:52 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 9 Nov 2010 03:05:51 -0500 From: Hadriel Kaplan To: Shingo KASHIMA Date: Tue, 9 Nov 2010 03:05:50 -0500 Thread-Topic: [IPFIX] draft-kashima-ipfix-data-link-layer-monitoring Thread-Index: Act/5OypfSJ8EldgRROZK6flF4Q/hg== Message-ID: <06C16490-C83B-4333-8B0B-1022DECCF886@acmepacket.com> References: <20101109104639.C689.1AB7FA03@nttv6.net> <20101109141750.9AA4.1AB7FA03@nttv6.net> In-Reply-To: <20101109141750.9AA4.1AB7FA03@nttv6.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAUAAAAFR Cc: IETF IPFIX Working Group , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] draft-kashima-ipfix-data-link-layer-monitoring X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 08:05:30 -0000 Sure, but a dataLinkFrameType wouldn't be a static list known at the time y= ou define the IE for it. For example, new frame types are still being adde= d for libpcap (and libpcap has been around for decades). Methinks you'll w= ant a type-list you can easily expand in the future. -hadriel On Nov 9, 2010, at 1:31 AM, Shingo KASHIMA wrote: >=20 > Hi Hadriel and all, >=20 > Thanks for your information. >=20 > I undarstood IPFIX IEs have two kins of enumeration values. >=20 > - To be defined as independent type > e.g. mplsTopLabelType > - To be defined in own description > e.g. flowEndReason, biflowDirection >=20 > On Tue, 9 Nov 2010 01:02:53 -0500 > Hadriel Kaplan wrote: >=20 >>=20 >> On Nov 8, 2010, at 10:08 PM, Shingo KASHIMA wrote: >>=20 >>> Then let's see existing IEs. >>> - flowEndReason includes a value list in its description. >>> - biflowDirection includes a value list in its description. >>> Are there IEs which do not include a value list in their description ? >>>=20 >>> Which is IPFIX IEs registries policy, to be defined in the IE >>> description or in separate registries ? >>> We should follow our policy. >>> Or, dataLinkFrameType is a different kind of IE from existing IEs >>> such as flowEndReason and biflowDirection ? >>=20 >> I think he means more like mplsTopLabelType, which has an actual registr= y for its enumeration values. (See http://www.iana.org/assignments/ipfix/ip= fix.xhtml#ipfix-mpls-label-type) >>=20 >> -hadriel >=20 > --=20 > Shingo KASHIMA > NTT Information Sharing Platform Lab. >=20 >=20 From inacio@cert.org Tue Nov 9 07:03:54 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7AC3A699D for ; Tue, 9 Nov 2010 07:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwaTrr3tGf8Y for ; Tue, 9 Nov 2010 07:03:53 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by core3.amsl.com (Postfix) with ESMTP id 51DDD3A63CB for ; Tue, 9 Nov 2010 07:03:53 -0800 (PST) Received: from ms01.sei.cmu.edu (ms01.sei.cmu.edu [128.237.22.36]) by plainfield.sei.cmu.edu (8.13.8/8.13.8/1294) with ESMTP id oA9F4GTN006470; Tue, 9 Nov 2010 10:04:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1289315056; bh=O2Bfcn8kTUXW2MsM372XZ7DvhHVj7Y68xsKu7xjV6Ig=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=fDitdVcrljWYSEiuJBx+A10YHCDflQm/9krA1+zX8zbxqFs2DZSlRwDzco5YJcE5e G6fAYjmWVeTB5aDXxduQySMMtkIpGnE7mavD6W2YqC9CyHU03oKmOnfwtYSNxT7ot6 HoS9nHokSYgud/o9l28a+J2CvP12TG3IiZtgW/hM= Received: from owa.sei.cmu.edu (tyranus.sei.cmu.edu [10.64.28.15]) by ms01.sei.cmu.edu (8.13.1/8.13.1/1348) with ESMTP id oA9F4FwR012547; Tue, 9 Nov 2010 10:04:16 -0500 Received: from EXCHANGE.sei.cmu.edu ([10.64.28.12]) by tyranus.sei.cmu.edu ([10.64.28.15]) with mapi; Tue, 9 Nov 2010 10:04:15 -0500 From: Chris Inacio To: Brian Trammell , Benoit Claise Date: Tue, 9 Nov 2010 10:04:19 -0500 Thread-Topic: [IPFIX] Structured Data WGLC comments Thread-Index: AcuAH2BSAl09mOHRSWW2fe23i9eTHA== Message-ID: <71523BFA-2730-4D7D-82AD-E8241BB3A91F@cert.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Structured Data WGLC comments X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 15:03:54 -0000 First off, I agree with Brian's comments. In section 1.1, do you want to keep saying "IP Flow information"? Especial= ly considering the chances of using IPFIX in other IETF activities. Section 2: "Indeed, polling short-live Flows" to "Indeed, polling short-liv= ed Flows". The dangling "Figure F" label on page 22-23 is really annoying. I would like to see a better discussion about how structured data elements = change the TLV tuple contract that is the core of the IPFIX model today. I= personally think that is the largest change with how we will handle these = new data types.=20 Even more importantly for our application, I would really like to see a way= of passing metadata about a structured template as well. Can we expand st= ructured data to include some options elements so that I can do something l= ike say "template 255 is email" "template 256 is IMAP" / "template 257 is = POP3". Something like that. We're really worried about the template issue= withdraw problem that seems to be creeping up on us when we use structured= data. As a point of reference, we have structured data fully implemented in our f= ixbuf library. We're currently converting the DPI capabilities that are in= YAF to use structured data for export. We're still working through the is= sues of how to manage templates using structured data. We have the issue o= f that, for example, if you want capture details on HTTP, then sometimes th= e "referer" field will be present, and sometimes it won't. If we want to e= ncode that efficiently, we need to either change the templates, or have mul= tiples available. If we have multiples, we always want the collector to un= derstand that these N templates are HTTP, otherwise we have to do a lot of = withdraws of templates. I really like structured data, especially if I find more than one HTTP head= er in a network stream (proxying anyone?) because it captures the relations= hip. But right now, I'm not sure how to manage it. I'll try to be on the webex if I can. regards, Chris Inacio inacio@cert.org On Nov 8, 2010, at 4:53 AM, Brian Trammell wrote: > Greetings, all, >=20 > I have the following two comments on draft-ietf-ipfix-structured-data-03. >=20 > First, I don't necessarily find the repeated examples showing how variabl= e length Information Elements work to be particularly useful, but I accept = that this might be because I already know how they work. >=20 > What I _am_ missing, however, are unified diagrams showing how the struct= ured data Information Elements and variable-length encoding work together: >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 255 | Length (0 to 65535) | Semantic | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Information Element ID | Element Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | basicList content . . . | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 >=20 > Second, Section 5.4 is missing a discussion of when you shouldn't use Str= uctured Data _at all_: i.e., when there is low or no semantic variation amo= ng records represented by a template. Consequently, I'm not sure about sect= ion 9.3. It seems like although we _could_ use structured data for biflows,= the suggested approach misses the 1. semantic clarity and 2. export effici= ency that were aims of 5103. >=20 > Beyond these points, I've reviewed the draft, and it looks good. >=20 > Best regards, >=20 > Brian > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From kashima@nttv6.net Tue Nov 9 07:04:53 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363B03A681F for ; Tue, 9 Nov 2010 07:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPO0QIgu7bGS for ; Tue, 9 Nov 2010 07:04:52 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 5C44A3A63CB for ; Tue, 9 Nov 2010 07:04:51 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id oA9F50or042447; Wed, 10 Nov 2010 00:05:08 +0900 (JST) (envelope-from kashima@nttv6.net) Date: Tue, 09 Nov 2010 23:04:28 +0800 From: Shingo KASHIMA To: Hadriel Kaplan In-Reply-To: <06C16490-C83B-4333-8B0B-1022DECCF886@acmepacket.com> References: <20101109141750.9AA4.1AB7FA03@nttv6.net> <06C16490-C83B-4333-8B0B-1022DECCF886@acmepacket.com> Message-Id: <20101109223645.0F08.1AB7FA03@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (mail.nttv6.net [IPv6:::1]); Wed, 10 Nov 2010 00:05:10 +0900 (JST) Cc: IETF IPFIX Working Group , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] draft-kashima-ipfix-data-link-layer-monitoring X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 15:04:53 -0000 Hi Hadriel and all, Thanks for your comments. A dataLinkFrameType seems to be just like mplsTopLabelType. Let's discuss with at tommorow WG meeting. Best Regards, Shingo. On Tue, 9 Nov 2010 03:05:50 -0500 Hadriel Kaplan wrote: > > Sure, but a dataLinkFrameType wouldn't be a static list known at the time you define the IE for it. For example, new frame types are still being added for libpcap (and libpcap has been around for decades). Methinks you'll want a type-list you can easily expand in the future. > > -hadriel > > On Nov 9, 2010, at 1:31 AM, Shingo KASHIMA wrote: > > > > > Hi Hadriel and all, > > > > Thanks for your information. > > > > I undarstood IPFIX IEs have two kins of enumeration values. > > > > - To be defined as independent type > > e.g. mplsTopLabelType > > - To be defined in own description > > e.g. flowEndReason, biflowDirection > > > > On Tue, 9 Nov 2010 01:02:53 -0500 > > Hadriel Kaplan wrote: > > > >> > >> On Nov 8, 2010, at 10:08 PM, Shingo KASHIMA wrote: > >> > >>> Then let's see existing IEs. > >>> - flowEndReason includes a value list in its description. > >>> - biflowDirection includes a value list in its description. > >>> Are there IEs which do not include a value list in their description ? > >>> > >>> Which is IPFIX IEs registries policy, to be defined in the IE > >>> description or in separate registries ? > >>> We should follow our policy. > >>> Or, dataLinkFrameType is a different kind of IE from existing IEs > >>> such as flowEndReason and biflowDirection ? > >> > >> I think he means more like mplsTopLabelType, which has an actual registry for its enumeration values. (See http://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mpls-label-type) > >> > >> -hadriel > > > > -- > > Shingo KASHIMA > > NTT Information Sharing Platform Lab. > > > > > > > -- Shingo KASHIMA NTT Information Sharing Platform Lab. From paitken@cisco.com Tue Nov 9 14:15:25 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5BAC3A692E for ; Tue, 9 Nov 2010 14:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.248 X-Spam-Level: X-Spam-Status: No, score=-9.248 tagged_above=-999 required=5 tests=[AWL=-1.351, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_83=0.6, MANGLED_PENIS=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+DPd16FAqGi for ; Tue, 9 Nov 2010 14:15:17 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5B5B93A696C for ; Tue, 9 Nov 2010 14:15:15 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,175,1288569600"; d="scan'208,217";a="180375925" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 Nov 2010 22:15:40 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA9MFcEZ019469; Tue, 9 Nov 2010 22:15:39 GMT Received: from [10.61.95.154] (ams3-vpn-dhcp8091.cisco.com [10.61.95.154]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id oA9MFX827151; Tue, 9 Nov 2010 22:15:34 GMT Message-ID: <4CD9C807.7060205@cisco.com> Date: Tue, 09 Nov 2010 22:15:35 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: "Benoit Claise (bclaise)" , Brian Trammell , IETF IPFIX Working Group Content-Type: multipart/alternative; boundary="------------060403050408050604060603" Subject: [IPFIX] review of draft-trammell-ipfix-ie-doctors-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 22:15:25 -0000 This is a multi-part message in MIME format. --------------060403050408050604060603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, Benoit, Please find review comments inline. Thanks, P. > IPFIX Working Group B. Trammell > Internet-Draft ETH Zurich > Intended status: BCP B. Claise > Expires: April 4, 2011 Cisco Systems > October 1, 2010 > > > Guidelines for Authors and Reviewers of IPFIX Information Elements > draft-trammell-ipfix-ie-doctors-00.txt > > Abstract > > This document provides guidelines for the definition of IPFIX > Information Elements for addition to the IANA IPFIX Information > Element registry, in order to extend the applicability of the IPFIX > protocol to new operations and management areas. > > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is athttp://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on April 4, 2011. > > Copyright Notice > > Copyright (c) 2010 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > > > Trammell& Claise Expires April 4, 2011 [Page 1] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1. Intended Audience and Usage . . . . . . . . . . . . . . . 3 > 1.2. Overview of relevant IPFIX documents . . . . . . . . . . . 4 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. How to apply IPFIX . . . . . . . . . . . . . . . . . . . . . . 5 > 4. Defining new Information Elements . . . . . . . . . . . . . . 6 > 4.1. Information Element naming . . . . . . . . . . . . . . . . 6 > 4.2. Information Element data types . . . . . . . . . . . . . . 7 > 4.3. Ancillary Information Element properties . . . . . . . . . 7 > 4.4. Internal structure in Information Elements . . . . . . . . 8 > 4.5. Enumerated Values and Subregistries . . . . . . . . . . . 9 > 4.6. Reversibility as per RFC 5103 . . . . . . . . . . . . . . 9 > 5. The Information Element Lifecycle: Revision and Deprecation . 10 > 6. When not to define new Information Elements . . . . . . . . . 12 > 6.1. Maximizing reuse of existing Information Elements . . . . 12 > 6.2. Applying enterprise-specific Information Elements . . . . 13 > 7. Applying IPFIX to non-Flow Applications . . . . . . . . . . . 14 > 8. Defining Recommended Templates . . . . . . . . . . . . . . . . 14 > 9. A Textual Format for Specifying Information Elements and > Templates . . . . . . . . . . . . . . . . . . . . . . . . . . 15 > 9.1. Information Element Specifiers . . . . . . . . . . . . . . 16 > 9.2. Specifying Templates . . . . . . . . . . . . . . . . . . . 18 > 9.3. Specifying IPFIX Structured Data . . . . . . . . . . . . . 18 > 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 > 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 > 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 > 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20 > 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 > 14.1. Normative References . . . . . . . . . . . . . . . . . . . 20 > 14.2. Informative References . . . . . . . . . . . . . . . . . . 21 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 > > > > > > > > > > > > > > > > > > > Trammell& Claise Expires April 4, 2011 [Page 2] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > 1. Introduction > > This document provides guidelines for the extension of the > applicability of the IP Flow Information Export (IPFIX) protocol to > network operations and management purposes outside the initial scope > defined in "IPFIX Applicability Statement" [RFC5472]. These new > applications areis largely defined through the definition of new > Remove "is". > Information Elements beyond those defined in the IPFIX Information > Model [RFC5102] or already added to the IANA IPFIX Information > Element Registry [iana-ipfix-assignments]. New applications may be > further specified through additional RFCs defining and describing > their usage. > Ambiguous "their": seems like new applications, rather than Information Elements. > We intend this document to enable the expansion of the applicability > of IPFIX to new areas by experts in the working group or area > directorate concerned with the technical details of the protocol or > application to be measured or managed using IPFIX. This expansion > would occur with the consultation of IPFIX experts informally called > 'IE-Doctors'. It provides guidelines both for those defining new > Information Elements as well as the IE-Doctors reviewingthem. > Ambiguous "them": seems like "those defining new Information Elements". > 1.1. Intended Audience and Usage > > This document is meant for two separate audiences. For IETF > contributors extending the applicability of IPFIX, it provides a set > of guidelines and best practices to be used in deciding which > Information Elements are necessary for a given application, defining > these Information Elements, and deciding whether an RFC should be > published to further describe the application. For the IPFIX experts > appointed as IE-Doctors, and for IANA personnel changing the > Information Element registry, it defines a set of acceptance criteria > against which these proposed Information Elements should be > evaluated. > > This document is not intended to guide the extension of the IPFIX > protocol itself, e.g. through new export mechanisms, data types, or > the like; these activities should be pursued through the publication > of standards-track RFCs by the IPFIX Working Group. > > This document specifies additional practices beyond those appearing > in the IANA Considerations sections of existing IPFIX documents, > especially the Information Model [RFC5102]. The practices outlined > in this document are intended to guide experts when making changes to > the IANA registry under Expert Review as defined in [RFC5226]. > > > > > > > > Trammell& Claise Expires April 4, 2011 [Page 3] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > 1.2. Overview of relevant IPFIX documents > > [RFC5101] defines the IPFIX Protocol, the IPFIX-specific terminology > used by this document,and the data type encodings for each of the > data types supported by IPFIX. > Not entirely true; it defines the initial set of data types as an extensible registry. There are already drafts proposing new IPFIX data types beyond RFC5101. Therefore the IANA IPFIX registry is the master, rather than any of the IPFIX RFCs. > [RFC5102] defines the initial IPFIX Information Model, as well as > procedures for extending the Information Model. It states that new > Information Elements may be added to the Information Model on Expert > Review basis, and delegates the appointment of experts to an IESG > Area Director. This document is intended to further codify the best > practices to be followed by these experts, in order to improve the > efficiency of this process. > > [RFC5103] defines a method for exporting bidirectional flow > information using IPFIX; this document should be followed when > extending IPFIX to represent information about bidirectional network > interactions in general. Additionally, new Information Elements > should be annotated for their reversibility or lack thereof as per > this document. > Where is this annotation to be recorded? AFAIK there's currently nowhere to do this in the IANA registry, yet there's no requirement to create any other document before creating new IEs. > [RFC5610] defines a method for exporting information about > Information Elements inline within IPFIX. In doing so, it explicitly > defines a set of implicit restrictions on the use of data types and > semantics; these restrictions MUST be observed in the definition of > new Information Elements, as inSection 4.3. > Ambiguous "Section 4.3". 5610 doesn't have a section 4.3. Say "Section 4.3 below.". Throughout the document, please makes it clear whether you're referring to sections in this doc or in other RFCs. > 2. Terminology > > Capitalized terms used in this document that are defined in the > Terminology section of [RFC5101] are to be interpreted as defined > there. > > An "application", as used in this document, refers to a candidate > protocol, task, or domain to which IPFIX export, collection, and/or > storage is applied, beyond those within the IPFIX Applicability > statement [RFC5472]. By this definition, PSAMP [RFC5476] was the > first new IPFIX application after the publication of the IPFIX > protocol [RFC5101]. > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > > > > > > > Trammell& Claise Expires April 4, 2011 [Page 4] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > 3. How to apply IPFIX > > Though originally specified for the export of IP flow information, > the message format, template mechanism, and data model specified by > IPFIX lead to it being applicable to a wide variety of network > management situations. In addition to flow information export, for > which it was designed, and packet information export as specified by > PSAMP [RFC5476], any application with the following characteristics > is a good candidate for an IPFIX application: > > o The application's data flow is fundamentally unidirectional. > IPFIX is a "push" protocol, supporting only the export of > information from a sender (an Exporting Process) to a receiver (a > Collecting Process). Request-response interactions are not > supported by IPFIX. > > o The application handles discrete event information, or information > to be periodically reported. IPFIX is particularly well suited to > representing events, which can be scoped in time. > > oThe application handles information about network entities. > IPFIX's information model is network-oriented, so network > management applications have many opportunities for information > model reuse. > No; this is contrary to the Abstract. I can export anything over IPFIX that I can define an IE for. With suitable IEs, it would even be possible to tunnel other protocols over IPFIX! > o The application requires a small number of arrangements of data > structures relative to the number of records it handles. The > template-driven self-description mechanism used by IPFIX excels at > handling large volumes of identically structured data, compared to > representations which define structure inline with data (such as > XML). > > Most applications meeting these criteria can be supported over IPFIX. > Onceit's been determined that IPFIX is a good fit, the next step is > "it's" = "it is", not "it has". > determining which Information Elements are necessary to represent the > information required by the application. Especially for network- > centric applications, the IPFIX Information Element registry may > already contain all the necessary Information Elements (see > Section 6.1 for guidelines on maximizing Information Element reuse). > > In this case, no additional work within the IETF is necessary: simply > define Templates and start exporting. > > It is expected, however, that most applications will be able to reuse > some existing Information Elements, but must define some additional > Information Elements to support all their requirements; in this case, > see Section 4 for best practices to be followed in defining > Information Elements. > > > > Trammell& Claise Expires April 4, 2011 [Page 5] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > Optionally, a Working Group or individual contributor may choose to > You should detail "Optionally". New IEs don't need an RFC, but some applications may require changes to the IPFIX protocol which do require an RFC. > publish an RFC detailing the new IPFIX application. Such an RFC > should contain discussion of the new application, the Information > Element definitions as in Section 4, as well assuggested Templates Good grief, I can't believe I just read that! Perhaps the fields may be specified, but that's about as far as I'd go. Suggesting templates is something for the implementer to do in his software design, and not something to be specified in, or slavishly copy from, RFCs. More on this below. > and examples of the use of those Templates within the new application > as in Section 8. Section 9 defines a compact textual Information > Element notation to be used in describing these suggested Templates > and/or the use of IPFIX Structured Data > [I-D.ietf-ipfix-structured-data] within the new application. > This last line seems jammed in without reference to the foregoing text. A new paragraph might be better. > 4. Defining new Information Elements > > In many cases, a new application will require nothing more than a new > Information Element or set of Information Elements to be exportable > using IPFIX. An Information Element meeting the following criteria, > as evaluated by appointed IPFIX experts, is eligible for inclusion in > theInformation Element registry: > Xref with [IANA] URL. > o The Information Element MUST be sufficiently unique within the > registry. A proposed Information Elements which is a substantial > Typo. > duplicate of an exiting Information Element is to be represented > using the existing Element. > Yes and no: If a new element simply adds a new value to an existing element, then it can be considered as extending the value registry for that element, which is considerably better than creating a new element for each new value. However, how are implementers to track when new values are added? An exporter and collector may interoperate just fine until the exporter is updated to a newer version of the IPFIX info model, where a certain IE now includes an additional value which the collector doesn't understand. Since both have previously implemented this field and interoperated successfully, how are we to know that this potential failure now exists - other than exhaustively testing every field / value combination? Again, if a new element extends the functionality of an existing element in a small way - while substantially duplicating all the existing functionality of the existing element - then again the new element introduces a lack of interoperability. Potentially these issues may be solved with clear version tracking. > o The Information Element SHOULD contain minimal internal structure; > complex information should be represented with multiple simple > Information Elements to be exported in parallel, as in > Section 4.4. > Or be represented with structured data, if the elements form a structure or other composite unit of data. > o The Information Element SHOULD be generally applicable to the > application at hand, Meaning, don't request irrelevant elements? Why would anyone do that? > which SHOULD be of general interest to the > community. Information Elements representing information about > proprietary or nonstandard applications SHOULD be represented > using enterprise-specific Information Elements as detailed in > section 6.2 of [RFC5101]. > > The definition of new Information Elements requires a descriptive > name, a specification of the data type as one from the IPFIX Data > Type Registry, and a human-readable description written in English. > Also semantics, units, range (which are all eventually discussed below), and reference and requester info. The reference is especially important to allow others to clarify any ambiguity with the new IE. Ideally the requester should be a generic or team email address (rather than a single personal address) where relevant experts can still be reached even if the original requester isn't available or has moved on. > This section provides guidelines on each of these components of an > Information Element definition, referring to existing documentation > such as [RFC5102] as appropriate. > > 4.1. Information Element naming > > Information Element Names should be defined in accordance with > section 2.3 of [RFC5102]; the most important naming conventions are > repeated here for convenience. > > > > Trammell& Claise Expires April 4, 2011 [Page 6] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > o Names of Information Elements should be descriptive. > > o Names of Information Elements MUST be unique within the IPFIX > information model. > > o Names of Information Elements start with non-capitalized letters. > > o Composed names use capital letters for the first letter of each > component (except for the first one). All other letters are non- > capitalized, even for acronyms. Exceptions are made for acronyms > containing non-capitalized letter, such as 'IPv4' and 'IPv6'. > Examples are sourceMacAddress and destinationIPv4Address. > > In addition, new Information Elements pertaining to a specific > protocol SHOULD name the protocol in the first word in order to ease > searching by name (e.g. "sipMethod" for a SIP method, as would be > used in a logging format for SIP based on IPFIX). Similarly, new > Information Elements pertaining to a specific application SHOULD name > the application in the first word. > > 4.2. Information Element data types > > IPFIX provides a set of data types covering most primitives used in > network measurement and management applications. The most > appropriate data type should be chosen for the Information Element > type. > > Because IPFIX provides reduced-length encoding for Information > Elements, unless an integral Information Element is derived from a > fixed-width field in a measured protocol (e.g., tcpSequenceNumber, > which is an unsigned32), it should be defined with the maximum > possible width, generally signed64 or unsigned64. Applications can > Then all new elements would be defined as 64-bits. Perhaps "maximum foreseeable" or "maximum likely" would be better? > then choose to use reduced-size encoding as defined in Section 6.2 of > [RFC5101] in cases where fewer than 2^64 values are necessary. > So why don't we just do away with the size specification and specify only the type (signed, unsigned, ...)? Collectors can presume to allocate 64 bit fields, while the actual size being exported is encoded in the IPFIX template. > Information Elements representing time values should be exported with > appropriate precision. For example, a Information Element for a time > measured at second-level precision should be defined as having a > dateTimeSeconds data type, instead of dateTimeMilliseconds. > > 4.3. Ancillary Information Element properties > > Information Elements with numeric types and special semantics SHOULD > define these semantics with one of the values in the Information > Element Semantics registry, as described in Section 3.2 of [RFC5102], > subject to the restrictions given in Section 3.10 of [RFC5610]; > essentially, the semantics and the type must be consistent. > > > > > Trammell& Claise Expires April 4, 2011 [Page 7] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > When defining Information Elements representing a dimensioned > quantity or entity count, the units of that quantity SHOULD be > defined in the units field.This field takes its values from the > IANA Information Element Units registry. If an Information Element > expresses a quantity in units not yet in this registry, then the unit > must be added to the Units registry at the same time the Information > Element is added to the Information Element registry. > Similar text for both data types and semantics, please. > Additionally, when the range of values an Information Element can > take is smaller than the range implied by its data type, the range > SHOULD be definedwithin the Information Element registry. > More exactly, as part of the IE definition. > 4.4. Internal structure in Information Elements > > Unless defining an Information Element which is a direct copy of a > bitfield or other structured entity (e.g., the tcpControlBits > Information Element for the Flags byte from the TCP header)in a > measured protocol, the definition of Information Elements with > I think it would read better with this text before the parenthesised example. ie, give the example *after* the explanation. > internal structure with the structure defined in the Description > field is discouraged. In this case, the field SHOULD be decomposed > into multiple primitive Information Elements to be used in parallel. > There's a danger here, when there are multiple instances of the field. So instead of exporting multiple instances of a single structured field, "X:Y" like so: { X:Y, X:Y, X:Y } we prefer to export multiple instances of the broken down fields: { X, Y, X, Y, X, Y } - which may make sense, if the collector knows to relate the first X and Y together, the second X with the second Y etc... However, the following is also quite legitimate: { X, X, X, Y, Y, Y } Again it follows the same rule: first X relates to first Y etc. However, now it's a lot less clear that X and Y are related. Yet it's not any less valid. > For more complicated semantics, where the structuremay not haveuse > the IPFIX Structured Data [I-D.ietf-ipfix-structured-data] extension > instead. > Missing text? Where the structure may not have... what? > As an example of information element decomposition, consider an > application-level identifier called an "endpoint", which represents a > {host, port, protocol} tuple. Instead of allocating an opaque, > structured "source endpoint" Information Element, the source endpoint > should be represented by three separate Information Elements: "source > address", "source port", "transport protocol". Indeed, in this > example, the required information elements already exist in the > Information Element registry: sourceIPv4Address or sourceIPv6Address, > sourceTransportPort, protocolIdentifier. Indeed, as well as being > good practice, this normalization down to non-structured Information > Elements also increases opportunities for reuse as in Section 6.1. > This example is perfect for structured data. > The decomposition of data with internal structure SHOULD avoid the > definition of Information Elements with a meaning too specific to be > generally useful, or that would result in either the export of > meaningless data or a multitude of templates to handle different > multiplicities. A specific example of this within the IANA registry > is the following list of assigned IPFIX Information Elements: > mplsTopLabelStackSection, mplsLabelStackSection2, > mplsLabelStackSection3, mplsLabelStackSection4, > mplsLabelStackSection5, mplsLabelStackSection6 > mplsLabelStackSection7, mplsLabelStackSection8, > mplsLabelStackSection9, and mplsLabelStackSection10. The only > > > > Trammell& Claise Expires April 4, 2011 [Page 8] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > distinction between those almost-identical Information Elements is > the position within the MPLS stack. This Information Element design > pattern met an early requirement of the definition of IPFIX which was > not carried forward into the final specification -- namely, that no > semantic dependency was allowed between Information Elements in the > same Record -- and as such SHOULD NOT be followed in the definition > of new Information Elements. In this case, since the size of the > MPLS stack will vary from flow to flow, it should be exported using > IPFIX Structured Data [I-D.ietf-ipfix-structured-data] where > supported, as a basicList of MPLS label entries. > > Note that a Template may contain multiple instances of the same > Information Element; in this case,the each of the Information > Typo. > Elements in the Template are semantically indistinguishable, and > appear in their "natural" order, where natural order is defined > according to application; PSAMP uses this for exporting selectors. > Multiple IEs used in this way are preferable to IEs with internal > structure, but only when there is some natural order, and no semantic > interdependence among the elements. > > 4.5. Enumerated Values and Subregistries > > When defining an Information Element that takes an enumerated value > from a set of values which may change in the future, this enumeration > MUST be defined by an IANA registry or subregistry. For situations > where an existing registry defines the enumeration (e.g., the IANA > Protocol Numbers registry for the protocolIdentifier Information > Element), that registry MUST be used. Otherwise, a new IPFIX > subregistry must be defined for the enumerated value, to be modified > subject to Expert Review [RFC5226]. > There's some ongoing discussion with Nevil as to whether sub-registries should be used, or whether the values can be recorded directly in the element description. Again, the version control issue... > 4.6. Reversibility as per RFC 5103 > > [TODO: fix this para][RFC5103] defines a method for exporting > bidirectional flows using a special Private Enterprise Number to > define reverse-direction variants of IANA Information Elements, and a > set of criteria for determining whether an Information Element may be > reversed using this method. Section 6.1 of [RFC5103] states that CPs > should use the set of criteria therein to determine reversibility. > Since almost all Information Elements are reversible, these criteria > are expressed as to determine the exceptions, i.e. which Information > Elements are NOT reversible. > > To ease the determination of reversibility, future Information > Elements which are NOT reversible SHOULD note this fact in the > description at the time of definition. > Can you include some examples of non-reversible elements? > > > > Trammell& Claise Expires April 4, 2011 [Page 9] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > 5. The Information Element Lifecycle: Revision and Deprecation > > The Information Element status field in the Information Element > Registry is defined in [RFC5102] to allow Information Elements to be > 'deprecated' or 'obsolete'. No Information Elements are as of this > writing deprecated,and but provides no further explanation of these > statuses, [RFC5102] does not define any policy for using them. > This doesn't make sense. > Additionally, no policy is defined for revising Information Element > registry entries or addressing errors therein. To be certain, > changes and deprecations within the Information Element registry are > not encouraged, and should be avoided to the extent possible. > Clarify whether addition of new values is a change. > However, in recognition that change is inevitable, this section is > intended to remedy this situation. > > The primary requirement in the definition of a policy for managing > changes to existing Information Elements is avoidance of > interoperability problems; IPFIX experts appointed to review changes > to the Information Element Registry MUST work to maintain > interoperability above all else. Changes to Information Elements > already in use may only be done in an interoperable way; necessary > changes which cannot be done in a way to allow interoperability with > unchanged implementations MUST result in deprecation. > > A change to an Information Element is held to be interoperable only > when: > > o it involves the correction of an error which is obviously only > editorial; or > > o it corrects an ambiguity in the Information Element's definition, > which itself leads to non-interoperability (e.g., a prior change > to ipv6ExtensionHeaders); or > Cite the errata for this: http://www.rfc-editor.org/errata_search.php?eid=1738 > o it expands the Information Element's data type without changing > how it is represented (e.g., changing unsigned32 to unsigned64, as > with a prior change to selectorId); or > http://www.rfc-editor.org/errata_search.php?eid=2052 > o it defines a previously undefined or reserved enumerated value, or > one or more previously reserved bits in an Information Element > with flag semantics; or > > o it expands the set of permissible values in the Information > Element's range; or > These two changes may NOT be interoperable. eg, an exporter reporting an additional (new) value to a collector which hasn't been updated to understand that new value (though the collector was 100% IPFIX compliant at the time of implementation). Somewhere in here you should discuss version control of the IANA registry, so every change is clearly called out. Find out how other protocols deal with change. > o it harmonizes with an external reference which was itself > corrected. > This is a potentially dangerous change. The correct route may be to deprecate the wrongly defined IE and create a new IE with the correct definition. > A non-interoperable Information Element change may also be made if it > > > > Trammell& Claise Expires April 4, 2011 [Page 10] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > can be reasonably assumedin the eyes of the appointed experts that > no unchanged implementation of the Information Element exists; this > A subjective opinion is NOT sufficient. They should query the IPFIX community as widely as possible. > can be held to happen if a non-interoperable change to an Information > Element defined shortly before is proposed to the IPFIX mailing list > by the original proposer of the Information Element, and no objection > is raised within a reasonable amount of time, to be defined by the > expert reviewers. > Is this by way of an example, or is it by way of limitation? If the former, state "for example". If the latter, state "this can only be held to happen". > If a change ispermissible, it is sent to IANA, which passes it to > Who determines whether a change is permissible? This reads as if the change submitter self-determines? I'd have expected change requests to be sent to IANA which forwards them to the expert(s) who determine permissibility. > the appointed experts for review; if there is no objection to the > change from any appointed expert, IANA makes the change in the > Information Element Registry.Changes that are not permissible MUST > be handled by deprecation. > They can also be rejected outright. Else, by the MUST, a determined individual can completely deprecate the existing info model by requesting a sufficient number of changes. > An Information Element MAY be deprecated and replaced when: > > o the Information Element definition has an error or shortcoming > which cannot be permissibly changed as above; or > > o the deprecation harmonizes with an external reference which was > itself deprecated through that reference's accepted deprecation > method; or > Depending on the external action, the IE may be deprecated and not replaced. > o changes in the IPFIX Protocol or its extensions, or in community > understanding thereof, allow the information represented by the > Information Element to be represented in a more efficient or > convenient way. Deprecation in this circumstance additionally > requires the assent of the IPFIX Working Group, and should be > specified in the Internet Draft(s) defining the protocol change. > > A request for deprecation is sent to IANA, which passes it to the > appointed expertsand a responsible Operations Area Director for > This is new. > review; if there is no objection to the change from any appointed > expert, IANA makes the change in the Information Element Registry > according to its internal procedures. When deprecating an > Information Element, the Information Element description MUST be > updated to explain the deprecation, as well as to refer to any new > Information Elements created to replace the deprecated Information > Element. > > Deprecated Information Elements SHOULD continue to be supported by > Collecting Processes, but SHOULD NOT be exported by Exporting > Processes. The use of deprecated Information Elements SHOULD result > in a log entry or human-readable warning at theExporting and > That's crazy! You're saying that the EP should be updated to report that it's still sending deprecated fields? LOL. If you're going to update it to know that it's sending an obsolete field, your time would clearly be better spent updating it not to export that field any more. > Collecting Processes.After a period of time determined in the eyes > Split to a new paragraph at "After". > of the appointed experts to be reasonable in order to allow deployed > Exporting Processes to be updated to account for the deprecation, a > deprecated Information Element may be made obsolete. Obsolete > > > > Trammell& Claise Expires April 4, 2011 [Page 11] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > Information Elements MUST NOT be supported by either Exporting or > Collecting Processes. The receipt of obsolete Information Elements > SHOULD be logged by the Collecting Process. > ...and? Should the fields and/or records be discarded or processed? (Clue: "Be strict in what you send, but generous in what you receive.") > Names of deprecated Information Elements MUST NOT be reused. Names > of obsolete Information Elements MAY be reused, but this is NOT > RECOMMENDED, as it may cause confusion among users. > Be consistent: if names are the primary reference (rather than the ID numbers, strangely), then don't allow names to be reused at all. > > 6. When not to define new Information Elements > > Also important in defining new applications is avoiding redundancy > and clutter in the Information Element registry. Here we provide > guidelines for reuse of existing Information Elements, as well as > guidelines on using enterprise-specific Information Elements instead > of adding Information Elementsin the registry. > "to" > 6.1. Maximizing reuse of existing Information Elements > > Whenever possible, new applications should prefer usage of existing > IPFIX Information Elements to the creation of new Information > Elements. IPFIX already provides Information Elements for every > common Layer 4 and Layer 3 packet header field in the IETF protocol > suite, basic Layer 2 information, basic counters, timestamps and time > ranges, and so on. When defining a new Information Element similar > to an existing one,reviewers shall ensure that the existing one is > not applicable. > "... the expert reviewers MUST ..." ? > Simply changing the context in which an Information Element will be > used is insufficient reason for the definition of a new Information > Element. For example, an extension of IPFIX to log detailed > information about HTTP transactions alongside network-level > information should not define httpClientAddress and httpServerAddress > Information Elements, preferring instead the use of > sourceIPv[46]Address and destinationIPv[46]Address. > I've got http through a tunnel, proxy or NAT, such that there are two source addresses and two destination addresses. One src/dst pair is for http, the other belongs to the tunnel, proxy or NAT. What do you propose? > Applications dealing with bidirectional interactions should use > Bidirectional Flow Support for IPFIX [RFC5103] to represent these > interactions. > > Specifically, existing timestamp and time range Information Elements > should be reused for any situation requiring simple timestamping of > an event: for single observations, the observationTime* Information > Elements from PSAMP are provided, and for events with a duration, the > flowStart* and flowEnd* Information Elements suffice. This > arrangement allows minimal generic time handling by existing > Collecting Processes and analysis workflows. New timestamp > Information Elements should ONLY be defined for semantically distinct > > > > Trammell& Claise Expires April 4, 2011 [Page 12] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > timing information (e.g., an IPFIX-exported record containing > information about an event to be scheduled in the future). > > In all cases the use of absolute timestamp Information Elements (e.g. > flowStartMilliseconds) is RECOMMENDED, as these Information Elements > allow for maximum flexibility in processing with minimal overhead. > Timestamps based on the export time header in the enclosing IPFIX > Message (e.g. flowStartTimeDeltaMicroseconds) MAY be used if high- > precision timing is important, export bandwidth or storage space is > limited, timestamps comprise a relatively large fraction of record > size, and the application naturally groups records into Messages. > Timestamps based on information which must be exported in a separate > Options Template (e.g. flowStartSysUpTime) MAY be used only in the > context of an existing practice of using runtime-defined epochs for > the given application. > > The best practice in Information Element creation is a conservative > one: don't create a new Information Element unlessyou really need > it. > Of course you really need it. However, does the wider IPFIX community really need it? > 6.2. Applying enterprise-specific Information Elements > > IPFIX provides a mechanism for defining enterprise-specific > Infomation Elements, as in Section 3.2 of [RFC5101]. These are > scoped to a vendor's or organization's Structure of Management > Information (SMI)Private Enterprise Number, and are under complete > control of the organization assigning them. > Cite xref. > For situations in which interoperability is unimportant, new > information SHOULD be exported using enterprise-specific Information > Elements instead of adding new Information Elements to the registry. > These situations include: > > o export of implementation-specific information, or > > o export of information derived in a commercially-sensitive or > proprietary method, or > > o export of information or meta-information specific to a > commercially-sensitive or proprietary application. > > While work within the IETF generally does not fall into these > categories, enterprise-specific Information Elements are also useful > for pre-standardization testing of a new IPFIX application. While > performing initial development and interoperability testing of a new > application, the Information Elements used by the application SHOULD > NOT be submitted to IANA for inclusion in the registry. Instead, > these experimental Information Elements SHOULD be represented as > > > > Trammell& Claise Expires April 4, 2011 [Page 13] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > enterprise-specific until their definitions are finalized, then > transitioned from enterprise-specific to IANA-defined upon > finalization. > > > 7. Applying IPFIX to non-Flow Applications > > At the core of IPFIX is its definition of a Flow, a set of packets > sharing some common properties crossing an observation point within a > certain time window. However, the reliance on this definition does > not preclude the application of IPFIX to domains which are not > obviously handling flow dataaccording to it. Most network > According to what? Perhaps just drop these words? > management data collection tasks, those to which IPFIX is most > applicable, have at their core the movement of packets from one place > to another; by a liberal interpretation of the common properties > defining the flow, then, almost any event handled by these can be > held to concern data records conforming to the IPFIX definition of a > Flow. > Is it strictly necessary to convince oneself that a flow exists in order to use IPFIX? > Non-flow information defining associations or key-value pairs, on the > other hand, are handled by IPFIX Options. Here, the Information > Elements within an Options Template are split into Scope IEs which > define the key, and non-scope IEs which define the values associated > with that key. Unlike Flows, Options are not necessarily scoped in > time; an Option is generally held to be in effect until a new set of > values for a specific set of keys is exported. While Options are > often used by IPFIX to export metadata about the collection > infrastructure, they are applicable to any association information. > IIRC, there was some discussion about time-scoping IPFIX options and templates some years ago. eg, we can export a template, indicating that it will be valid from 6pm until midnight. Or pre-export an option, indicating that a new selectorAlgorithm will be in force from 6am. > An IPFIX application can mix Flow Records and Options in an IPFIX > Message or Message stream, and exploit relationships among the Flow > Keys, values, and Scopes to create interrelated data structures. See > [RFC5473] for an example application of this. > > > 8. Defining Recommended Templates > > New IPFIX applications SHOULD NOT, in the general case, define fixed > templates for export, as this throws away much of the flexibility > afforded by IPFIX. However, fixed template export is permissible in > the case that the export implementation must operate in a resource > constrained environment, and/or that the application is replacing an > existing fixed-format binary export format in a maximally compatible > way.In any case, Collecting Processes for such applications SHOULD > support reordered Templates or Templates with additional Information > Elements. > > An Internet-Draft clarifying the use of new Information Elements > > > > Trammell& Claise Expires April 4, 2011 [Page 14] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > SHOULD include any recommended Templates or Options Templates > necessary for supporting the application, as well as examples of > No it shouldn't, because implementers will blindly follow these and system specifiers will expect exactly these templates / options an no others, in order to be 100% compliant with the RFC / definition. Rather, the ID MUST specify which fields are required in the option / template, if any, and MAY give example options and templates, clearly labelling them as such. > records exported using these Templates. In defining these Templates, > such Internet-Drafts SHOULD mention, subject to rare exceptions as > above: > > o that the order of Information Elements within a Template is not > significant; > > o that Templates on the wire for the application may also contain > additional Information Elements beyond those specified in the > recommended Template; > > o that a stream of IPFIX Messages supporting the application may > also contain Data Records not described by the recommended > Templates; and > > o that any reader of IPFIX Messages supporting the application MUST > accept these conditions. > > Definitions of recommended Templates for flow-like information, where > the Flow Key is well-defined, SHOULD indicate which of the > Information Elements in the recommended Template are Flow Keys. > There's a flowKeyIndicator for that, if it's needed. > Recommended Templates are defined, for example, in [RFC5476] for > PSAMP packet reports (section 6.4) and extended packet reports > (section 6.5). Recommended Options Templates are defined extensively > throughout the IPFIX documents, including in the protocol document > itself [RFC5101] for exporting export statistics; in the file format > [RFC5655] for exporting file metadata; and in Mediator intermediate > process definitions such as [I-D.ietf-ipfix-anon] for intermediate > process metadata. The discussion in these examples is a good model > for recommended template definitions. > In your experience (or a quick poll?) do current IPFIX systems implement these exactly as specified, or does anyone implement them with the caveats described above (eg, in a different order, or with additional fields) ? > However, the bitmap diagrams of these Templates are illustrative but > not particularly readable for more complicated recommended Templates, > provide no support for rapid implementation of new Templates, and do > not adequately convey the optional nature of ordering and additional > Information Elements as above. Therefore, we have defined > RECOMMENDED textual format for specifying Information Elements and > Templates in Internet-Drafts in Section 9. > > > 9. A Textual Format for Specifying Information Elements and Templates > > The extension of IPFIXwill generate a fair amount of documentation > "Any extension of IPFIX may be expected to generate..." > and discussion covering the definition of new Information Elements. > Here we define a simple textual syntax for describing IPFIX > > > > Trammell& Claise Expires April 4, 2011 [Page 15] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > Information Elements and IPFIX Templates, with human readability, > human writability, compactness, and ease of parser/generator > implementation without requiring external XML support as design > goals. It is intended both for use in human communication (e.g., in > new Internet-Drafts containing higher-level descriptions of IPFIX > Templates, or describing sets of new IPFIX Information Elements for > supporting new applications of the protocol) as well as at runtime by > IPFIX implementations. > > 9.1. Information Element Specifiers > > The basis of this format is the textual Information Element > Specifier, or IESpec. An IESpec contains each of the four important > aspects of an Information Element: itsname, its number, its type, > and its size,separated by simple markup based on various types of > No semantics, units, range? > brackets. Fully-qualified IESpecs may be used to specify existing or > new Information Elements within an Information Model, while either > fully-qualified or partial IESpecs may be used to define fields in a > Template. > > Bare words are used for Information Element names, and each aspect of > information associated with an Information Element is associated with > a type of brackets: > > o () parentheses for Information Element numbers, > > o<> angles for Information Element data types, and > > o [] square brackets for Information Element sizes. > > o {} curly braces contain an optional space-separated list of > context identifiers to be associated with an Information Element, > as described in more detail in Section 9.2 > > The symbol + is reserved for Information Element nesting within > structured data elements; these are described in and Section 9.3, > respectively. > > Whitespace in IESpecs is insignificant; spaces can be added after > each element in order, e.g., to align columns for better readability. > > The basic form of a fully-qualified IESpec for an IANA-registered > Information Element is as follows: > > name(number)[size] > As long as all the information is present, is the order important? eg, using the example from below, one might prefer to write: [8] (152) flowStartMilliseconds [8] (153) flowEndMilliseconds [8] (1) octetDeltaCount [8] (2) packetDeltaCount {key} [4] (8) sourceIPv4Address {key} [4] (12) destinationIPv4Address {key} [2] (7) sourceTransportPort {key} [2] (11) destinationTransportPort {key} [1] (4) protocolIdentifier > where 'name' is the name of the Information Element in UTF-8, > 'number' is the Information Element as a decimal integer, 'type' is > > > > Trammell& Claise Expires April 4, 2011 [Page 16] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > the name of the data type as in the IANA informationElementDataTypes > registry, and 'size' is the length of the Information Element in > octets as a decimal integer, where 65535 or the string 'v' signifies > a variable-length Information Element. [size] may be omitted; in this > case, the data type's native or default size is assumed. > > The basic form of a fully-qualified IESpec for an enterprise-specific > Information Element is as follows: > > name(pen/number)[size] > > where 'pen' is the Private Enterprise Number as a decimal integer. > > A fully-qualified IESpec is intended to express enough information > about an Information Element to decode and display Data Records > defined by Templates containing that Information Element. Range, > unit, semantic, and description information, as in [RFC5610], is not > supported by this syntax. > > Example fully-qualified IESpecs follow: > > octetDeltaCount(1)[8] > > octetDeltaCount(1) (unsigned64 is natively 8 octets > long) > > sourceIPv4Address(8) > > wlanSSID(146)[v] > It's 147. > sipRequestURI(35566/403)[65535] > > A partial IESpec is any IESpec that is not fully-qualified; these are > useful when defining templates. A partial IESpec is assumed to take > missing values from its canonical definition, for example, the IANA > registry. At minimum, a partial IESpec must contain a name, or a > number. Any name, number, or type information given with a partial > IESpec must match the values given in the Information Model; however, > size information in a partial IESpec overrides size information in > the Information Model; in this way, IESpecs can be used to express > reduced-length encoding for Information Elements. > > Example partial IESpecs follow: > > o octetDeltaCount > > o octetDeltaCount[4] (reduced-length encoding) > > > > > Trammell& Claise Expires April 4, 2011 [Page 17] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > o (1) > > o (1)[4] (reduced length encoding; note that this is exactly > equivalent to an Information Element specifier in a Template) > > 9.2. Specifying Templates > > A Template can then be defined simply as an ordered, newline- > separated sequence of IESpecs. IESpecs in example Templates > illustrating a new application of IPFIX SHOULD be fully-qualified. > Flow Keys may be optionally annotated by appending the {key} context > to the end of each Flow Key specifier. A template counting packets > and octets per five-tuple with millisecond precision in IESpec syntax > is shown below. > > flowStartMilliseconds(152)[8] > flowEndMilliseconds(153)[8] > octetDeltaCount(1)[8] > packetDeltaCount(2)[8] > sourceIPv4Address(8)[4]{key} > destinationIPv4Address(12)[4]{key} > sourceTransportPort(7)[2]{key} > destinationTransportPort(11)[2]{key} > protocolIdentifier(4)[1]{key} > > An Options Template is specified similarly. Scope is specified > "specified by" > appending the {scope} contextto the end of each IESpec for a Scope > See earlier about ordering. > IE.Due to the way Information Elements are represented in Options > Templates, all {scope} IESpecs must appear before any non-scope > IESpec. The Flow Key Options Template defined in section 4.4 of > [RFC5101] in IESpec syntax is shown below: > Nonsense! That's only true when the IEs are being exported in an option on the wire, because that's how the protocol works. However, when writing them down, they can be any way around that you like. eg, specifications written by people who are unfamiliar with the exact details of the export protocols, but who simply want to use our exporter, sometimes list fields in alphabetical or numerical order. As long as {scope} is clearly indicated at the relevant place, it's up to us as protocol experts to deal with the ordering detail. > templateId(145)[2]{scope} > flowKeyIndicator(173)[8] > > 9.3. Specifying IPFIX Structured Data > > IESpecs can also be used to illustrate the structure of the > information exported using the IPFIX Structured Data extension > [I-D.ietf-ipfix-structured-data]. Here, the semantics of the > structured data elements are specified using contexts, and the > information elements within each structured data element follow the > structured data element, prefixed with + to show they are contained > therein. Arbitrary nesting of structured data elements is possible > by using multiple + signs in the prefix. For example, a basic list > of IP addresses with "one or more" semantics would be expressed using > parially qualified IESpecs as follows: > Typo, "partially". > > > > Trammell& Claise Expires April 4, 2011 [Page 18] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > basicList{oneOrMoreOf} > +sourceIPv4Address(8)[4] > > And an example subTemplateList itself containing a basicList is shown > below: > > subTemplateList{allOf} > +basicList{oneOrMoreOf} > ++sourceIPv4Address(8)[4] > +destinationIPv4Address(12)[4] > > This describes a subTemplateMultilist containing all of the expressed > set of source-destination pairs, where the source address itself > could be one of any number in a basicList (e.g., in the case of SCTP > multihoming). > > The contexts associable with structured data Information Elements are > the semantics, as defined in section 4.4 of > [I-D.ietf-ipfix-structured-data]; a structured data Information > Element without any context is taken to have undefined semantics. > More information on the application of structured data is available > in [I-D.ietf-ipfix-structured-data]. > > > 10. Security Considerations > > The security aspects of new Information Elements must be considered > in order not to give a potential attacker too much information. For > example, the "A Framework for Packet Selection and Reporting" > [RFC5474] concluded in section 12.3.2 that the hash functions private > parameters should not exported within IPFIX. > > If some security considerations are specific to an Information > Element, they MUST be mentioned in the Information Element > description. For example, the ipHeaderPacketSection in the IPFIX > registry mentions: "This Information Element, which may have a > variable length, carries a series of octets from the start of the IP > header of a sampled packet. With sufficient length, this element > also reports octets from the IP payload, subject to [RFC2804].See > the Security Considerations section." > Crucially, the relevant RFC containing the Security Considerations is cited in the registry 'Requester" column. Without that, this text wouldn't make sense. > These security considerations MAY also be stressed in a separate > draft. For example, the "Packet Sampling (PSAMP) Protocols > Specification" [RFC5476] specifies: "In the basic Packet Report, a > PSAMP Device exports some number of contiguous bytes from the start > of the packet, including the packet header (which includes link > layer, network layer and other encapsulation headers) and some > subsequent bytes of the packet payload. The PSAMP Device SHOULD NOT > > > > Trammell& Claise Expires April 4, 2011 [Page 19] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > export the full payload of conversations, as this would mean > wiretapping [RFC2804]. The PSAMP Device MUST respect local privacy > laws." > > > 11. IANA Considerations > > [TODO - collect IANA considerations from the document once we have > them.] > > > 12. Acknowledgements > > [TODO] > TIA ;-) > > 13. Open Issues > > o add examples everywhere (including sipclf) > > o explain the range 0-127. > > o explain thatexisting draft should use temporary IE identifier > Not just existing, but new drafts too. > such as XXX, YYY, and ZZZ both in the text and in the examples, > and a note to IANA: "to be replaced by IANA when the IE identifier > is assigned" > > o TBD (in WG): Do we want the IE-Doctors to be a formal directorate > under the OPS area? What can we take from the experience of PMOL? > > > 14. References > > 14.1. Normative References > > [RFC5101] Claise, B., "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic > Flow Information", RFC 5101, January 2008. > > [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. > Meyer, "Information Model for IP Flow Information Export", > RFC 5102, January 2008. > > [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export > Using IP Flow Information Export (IPFIX)", RFC 5103, > January 2008. > > [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, > > > > Trammell& Claise Expires April 4, 2011 [Page 20] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > "Exporting Type Information for IP Flow Information Export > (IPFIX) Information Elements", RFC 5610, July 2009. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an > IANA Considerations Section in RFCs", BCP 26, RFC 5226, > May 2008. > > 14.2. Informative References > > [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, > May 2000. > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > "Requirements for IP Flow Information Export (IPFIX)", > RFC 3917, October 2004. > > [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB > Documents", BCP 111, RFC 4181, September 2005. > > [RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. > Aitken, "IP Flow Information Export (IPFIX) Implementation > Guidelines", RFC 5153, April 2008. > > [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, > "Architecture for IP Flow Information Export", RFC 5470, > March 2009. > > [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP > Flow Information Export (IPFIX) Testing", RFC 5471, > March 2009. > > [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP > Flow Information Export (IPFIX) Applicability", RFC 5472, > March 2009. > > [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy > in IP Flow Information Export (IPFIX) and Packet Sampling > (PSAMP) Reports", RFC 5473, March 2009. > > [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., > Grossglauser, M., and J. Rexford, "A Framework for Packet > Selection and Reporting", RFC 5474, March 2009. > > [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling > (PSAMP) Protocol Specifications", RFC 5476, March 2009. > > > > Trammell& Claise Expires April 4, 2011 [Page 21] > > Internet-Draft IPFIX IE-DOCTORS October 2010 > > > [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. > Wagner, "Specification of the IP Flow Information Export > (IPFIX) File Format", RFC 5655, October 2009. > > [I-D.ietf-ipfix-structured-data] > Claise, B., Dhandapani, G., Yates, S., and P. Aitken, > "Export of Structured Data in IPFIX", > draft-ietf-ipfix-structured-data-02 (work in progress), > July 2010. > > [I-D.ietf-ipfix-anon] > Boschi, E. and B. Trammell, "IP Flow Anonymisation > Support", draft-ietf-ipfix-anon-03 (work in progress), > April 2010. > > [iana-ipfix-assignments] > Internet Assigned Numbers Authority, "IP Flow Information > Export Information Elements > (http://www.iana.org/assignments/ipfix/ipfix.xml)". > > > Authors' Addresses > > Brian Trammell > Swiss Federal Institute of Technology Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 13 > Email:trammell@tik.ee.ethz.ch > > > Benoit Claise > Cisco Systems, Inc. > De Kleetlaan 6a b1 > 1831 Diagem > Belgium > > Phone: +32 2 704 5622 > Email:bclaise@cisco.com > > > > > > > > > > > Trammell& Claise Expires April 4, 2011 [Page 22] > > > --------------060403050408050604060603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian, Benoit,

Please find review comments inline.

Thanks,
P.

IPFIX Working Group                                          B. Trammell
Internet-Draft                                                ETH Zurich
Intended status: BCP                                           B. Claise
Expires: April 4, 2011                                     Cisco Systems
                                                         October 1, 2010


   Guidelines for Authors and Reviewers of IPFIX Information Elements
                 draft-trammell-ipfix-ie-doctors-00.txt

Abstract

   This document provides guidelines for the definition of IPFIX
   Information Elements for addition to the IANA IPFIX Information
   Element registry, in order to extend the applicability of the IPFIX
   protocol to new operations and management areas.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 4, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Trammell & Claise         Expires April 4, 2011                 [Page 1]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Intended Audience and Usage  . . . . . . . . . . . . . . .  3
     1.2.  Overview of relevant IPFIX documents . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  How to apply IPFIX . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Defining new Information Elements  . . . . . . . . . . . . . .  6
     4.1.  Information Element naming . . . . . . . . . . . . . . . .  6
     4.2.  Information Element data types . . . . . . . . . . . . . .  7
     4.3.  Ancillary Information Element properties . . . . . . . . .  7
     4.4.  Internal structure in Information Elements . . . . . . . .  8
     4.5.  Enumerated Values and Subregistries  . . . . . . . . . . .  9
     4.6.  Reversibility as per RFC 5103  . . . . . . . . . . . . . .  9
   5.  The Information Element Lifecycle: Revision and Deprecation  . 10
   6.  When not to define new Information Elements  . . . . . . . . . 12
     6.1.  Maximizing reuse of existing Information Elements  . . . . 12
     6.2.  Applying enterprise-specific Information Elements  . . . . 13
   7.  Applying IPFIX to non-Flow Applications  . . . . . . . . . . . 14
   8.  Defining Recommended Templates . . . . . . . . . . . . . . . . 14
   9.  A Textual Format for Specifying Information Elements and
       Templates  . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1.  Information Element Specifiers . . . . . . . . . . . . . . 16
     9.2.  Specifying Templates . . . . . . . . . . . . . . . . . . . 18
     9.3.  Specifying IPFIX Structured Data . . . . . . . . . . . . . 18
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   13. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 20
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     14.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22


















Trammell & Claise         Expires April 4, 2011                 [Page 2]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


1.  Introduction

   This document provides guidelines for the extension of the
   applicability of the IP Flow Information Export (IPFIX) protocol to
   network operations and management purposes outside the initial scope
   defined in "IPFIX Applicability Statement" [RFC5472].  These new
   applications are is largely defined through the definition of new

Remove "is".

   Information Elements beyond those defined in the IPFIX Information
   Model [RFC5102] or already added to the IANA IPFIX Information
   Element Registry [iana-ipfix-assignments].  New applications may be
   further specified through additional RFCs defining and describing
   their usage.

Ambiguous "their": seems like new applications, rather than Information Elements.

   We intend this document to enable the expansion of the applicability
   of IPFIX to new areas by experts in the working group or area
   directorate concerned with the technical details of the protocol or
   application to be measured or managed using IPFIX.  This expansion
   would occur with the consultation of IPFIX experts informally called
   'IE-Doctors'.  It provides guidelines both for those defining new
   Information Elements as well as the IE-Doctors reviewing them.

Ambiguous "them": seems like "those defining new Information Elements".

1.1.  Intended Audience and Usage

   This document is meant for two separate audiences.  For IETF
   contributors extending the applicability of IPFIX, it provides a set
   of guidelines and best practices to be used in deciding which
   Information Elements are necessary for a given application, defining
   these Information Elements, and deciding whether an RFC should be
   published to further describe the application.  For the IPFIX experts
   appointed as IE-Doctors, and for IANA personnel changing the
   Information Element registry, it defines a set of acceptance criteria
   against which these proposed Information Elements should be
   evaluated.

   This document is not intended to guide the extension of the IPFIX
   protocol itself, e.g. through new export mechanisms, data types, or
   the like; these activities should be pursued through the publication
   of standards-track RFCs by the IPFIX Working Group.

   This document specifies additional practices beyond those appearing
   in the IANA Considerations sections of existing IPFIX documents,
   especially the Information Model [RFC5102].  The practices outlined
   in this document are intended to guide experts when making changes to
   the IANA registry under Expert Review as defined in [RFC5226].







Trammell & Claise         Expires April 4, 2011                 [Page 3]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


1.2.  Overview of relevant IPFIX documents

   [RFC5101] defines the IPFIX Protocol, the IPFIX-specific terminology
   used by this document, and the data type encodings for each of the
   data types supported by IPFIX.

Not entirely true; it defines the initial set of data types as an extensible registry. There are already drafts proposing new IPFIX data types beyond RFC5101. Therefore the IANA IPFIX registry is the master, rather than any of the IPFIX RFCs.

   [RFC5102] defines the initial IPFIX Information Model, as well as
   procedures for extending the Information Model.  It states that new
   Information Elements may be added to the Information Model on Expert
   Review basis, and delegates the appointment of experts to an IESG
   Area Director.  This document is intended to further codify the best
   practices to be followed by these experts, in order to improve the
   efficiency of this process.

   [RFC5103] defines a method for exporting bidirectional flow
   information using IPFIX; this document should be followed when
   extending IPFIX to represent information about bidirectional network
   interactions in general.  Additionally, new Information Elements
   should be annotated for their reversibility or lack thereof as per
   this document.

Where is this annotation to be recorded? AFAIK there's currently nowhere to do this in the IANA registry, yet there's no requirement to create any other document before creating new IEs.

   [RFC5610] defines a method for exporting information about
   Information Elements inline within IPFIX.  In doing so, it explicitly
   defines a set of implicit restrictions on the use of data types and
   semantics; these restrictions MUST be observed in the definition of
   new Information Elements, as in Section 4.3.

Ambiguous "Section 4.3". 5610 doesn't have a section 4.3. Say "Section 4.3 below.". Throughout the document, please makes it clear whether you're referring to sections in this doc or in other RFCs.

2.  Terminology

   Capitalized terms used in this document that are defined in the
   Terminology section of [RFC5101] are to be interpreted as defined
   there.

   An "application", as used in this document, refers to a candidate
   protocol, task, or domain to which IPFIX export, collection, and/or
   storage is applied, beyond those within the IPFIX Applicability
   statement [RFC5472].  By this definition, PSAMP [RFC5476] was the
   first new IPFIX application after the publication of the IPFIX
   protocol [RFC5101].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].







Trammell & Claise         Expires April 4, 2011                 [Page 4]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


3.  How to apply IPFIX

   Though originally specified for the export of IP flow information,
   the message format, template mechanism, and data model specified by
   IPFIX lead to it being applicable to a wide variety of network
   management situations.  In addition to flow information export, for
   which it was designed, and packet information export as specified by
   PSAMP [RFC5476], any application with the following characteristics
   is a good candidate for an IPFIX application:

   o  The application's data flow is fundamentally unidirectional.
      IPFIX is a "push" protocol, supporting only the export of
      information from a sender (an Exporting Process) to a receiver (a
      Collecting Process).  Request-response interactions are not
      supported by IPFIX.

   o  The application handles discrete event information, or information
      to be periodically reported.  IPFIX is particularly well suited to
      representing events, which can be scoped in time.

   o  The application handles information about network entities.
      IPFIX's information model is network-oriented, so network
      management applications have many opportunities for information
      model reuse.

No; this is contrary to the Abstract. I can export anything over IPFIX that I can define an IE for. With suitable IEs, it would even be possible to tunnel other protocols over IPFIX!

   o  The application requires a small number of arrangements of data
      structures relative to the number of records it handles.  The
      template-driven self-description mechanism used by IPFIX excels at
      handling large volumes of identically structured data, compared to
      representations which define structure inline with data (such as
      XML).

   Most applications meeting these criteria can be supported over IPFIX.
   Once it's been determined that IPFIX is a good fit, the next step is

"it's" = "it is", not "it has".

   determining which Information Elements are necessary to represent the
   information required by the application.  Especially for network-
   centric applications, the IPFIX Information Element registry may
   already contain all the necessary Information Elements (see
   Section 6.1 for guidelines on maximizing Information Element reuse).
  
   In this case, no additional work within the IETF is necessary: simply
   define Templates and start exporting.

   It is expected, however, that most applications will be able to reuse
   some existing Information Elements, but must define some additional
   Information Elements to support all their requirements; in this case,
   see Section 4 for best practices to be followed in defining
   Information Elements.
  


Trammell & Claise         Expires April 4, 2011                 [Page 5]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   Optionally, a Working Group or individual contributor may choose to

You should detail "Optionally". New IEs don't need an RFC, but some applications may require changes to the IPFIX protocol which do require an RFC.

   publish an RFC detailing the new IPFIX application.  Such an RFC
   should contain discussion of the new application, the Information
   Element definitions as in Section 4, as well as suggested Templates

Good grief, I can't believe I just read that!

Perhaps the fields may be specified, but that's about as far as I'd go. Suggesting templates is something for the implementer to do in his software design, and not something to be specified in, or slavishly copy from, RFCs. More on this below.

   and examples of the use of those Templates within the new application
   as in Section 8.  Section 9 defines a compact textual Information
   Element notation to be used in describing these suggested Templates
   and/or the use of IPFIX Structured Data
   [I-D.ietf-ipfix-structured-data] within the new application.

This last line seems jammed in without reference to the foregoing text. A new paragraph might be better.

4.  Defining new Information Elements

   In many cases, a new application will require nothing more than a new
   Information Element or set of Information Elements to be exportable
   using IPFIX.  An Information Element meeting the following criteria,
   as evaluated by appointed IPFIX experts, is eligible for inclusion in
   the Information Element registry:

Xref with [IANA] URL.

   o  The Information Element MUST be sufficiently unique within the
      registry.  A proposed Information Elements which is a substantial

Typo.

      duplicate of an exiting Information Element is to be represented
      using the existing Element.

Yes and no:

If a new element simply adds a new value to an existing element, then it can be considered as extending the value registry for that element, which is considerably better than creating a new element for each new value. However, how are implementers to track when new values are added? An exporter and collector may interoperate just fine until the exporter is updated to a newer version of the IPFIX info model, where a certain IE now includes an additional value which the collector doesn't understand. Since both have previously implemented this field and interoperated successfully, how are we to know that this potential failure now exists - other than exhaustively testing every field / value combination?

Again, if a new element extends the functionality of an existing element in a small way - while substantially duplicating all the existing functionality of the existing element - then again the new element introduces a lack of interoperability.

Potentially these issues may be solved with clear version tracking.

   o  The Information Element SHOULD contain minimal internal structure;
      complex information should be represented with multiple simple
      Information Elements to be exported in parallel, as in
      Section 4.4.

Or be represented with structured data, if the elements form a structure or other composite unit of data.

   o  The Information Element SHOULD be generally applicable to the
      application at hand,

Meaning, don't request irrelevant elements? Why would anyone do that?

 which SHOULD be of general interest to the
      community.  Information Elements representing information about
      proprietary or nonstandard applications SHOULD be represented
      using enterprise-specific Information Elements as detailed in
      section 6.2 of [RFC5101].

   The definition of new Information Elements requires a descriptive
   name, a specification of the data type as one from the IPFIX Data
   Type Registry, and a human-readable description written in English.

Also semantics, units, range (which are all eventually discussed below), and reference and requester info.

The reference is especially important to allow others to clarify any ambiguity with the new IE.

Ideally the requester should be a generic or team email address (rather than a single personal address) where relevant experts can still be reached even if the original requester isn't available or has moved on.

   This section provides guidelines on each of these components of an
   Information Element definition, referring to existing documentation
   such as [RFC5102] as appropriate.

4.1.  Information Element naming

   Information Element Names should be defined in accordance with
   section 2.3 of [RFC5102]; the most important naming conventions are
   repeated here for convenience.



Trammell & Claise         Expires April 4, 2011                 [Page 6]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   o  Names of Information Elements should be descriptive.

   o  Names of Information Elements MUST be unique within the IPFIX
      information model.

   o  Names of Information Elements start with non-capitalized letters.

   o  Composed names use capital letters for the first letter of each
      component (except for the first one).  All other letters are non-
      capitalized, even for acronyms.  Exceptions are made for acronyms
      containing non-capitalized letter, such as 'IPv4' and 'IPv6'.
      Examples are sourceMacAddress and destinationIPv4Address.

   In addition, new Information Elements pertaining to a specific
   protocol SHOULD name the protocol in the first word in order to ease
   searching by name (e.g. "sipMethod" for a SIP method, as would be
   used in a logging format for SIP based on IPFIX).  Similarly, new
   Information Elements pertaining to a specific application SHOULD name
   the application in the first word.

4.2.  Information Element data types

   IPFIX provides a set of data types covering most primitives used in
   network measurement and management applications.  The most
   appropriate data type should be chosen for the Information Element
   type.

   Because IPFIX provides reduced-length encoding for Information
   Elements, unless an integral Information Element is derived from a
   fixed-width field in a measured protocol (e.g., tcpSequenceNumber,
   which is an unsigned32), it should be defined with the maximum
   possible width, generally signed64 or unsigned64.  Applications can

Then all new elements would be defined as 64-bits. Perhaps "maximum foreseeable" or "maximum likely" would be better?

   then choose to use reduced-size encoding as defined in Section 6.2 of
   [RFC5101] in cases where fewer than 2^64 values are necessary.

So why don't we just do away with the size specification and specify only the type (signed, unsigned, ...)? Collectors can presume to allocate 64 bit fields, while the actual size being exported is encoded in the IPFIX template.

   Information Elements representing time values should be exported with
   appropriate precision.  For example, a Information Element for a time
   measured at second-level precision should be defined as having a
   dateTimeSeconds data type, instead of dateTimeMilliseconds.

4.3.  Ancillary Information Element properties

   Information Elements with numeric types and special semantics SHOULD
   define these semantics with one of the values in the Information
   Element Semantics registry, as described in Section 3.2 of [RFC5102],
   subject to the restrictions given in Section 3.10 of [RFC5610];
   essentially, the semantics and the type must be consistent.




Trammell & Claise         Expires April 4, 2011                 [Page 7]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   When defining Information Elements representing a dimensioned
   quantity or entity count, the units of that quantity SHOULD be
   defined in the units field.  This field takes its values from the
   IANA Information Element Units registry.  If an Information Element
   expresses a quantity in units not yet in this registry, then the unit
   must be added to the Units registry at the same time the Information
   Element is added to the Information Element registry.

Similar text for both data types and semantics, please.

   Additionally, when the range of values an Information Element can
   take is smaller than the range implied by its data type, the range
   SHOULD be defined within the Information Element registry.

More exactly, as part of the IE definition.

4.4.  Internal structure in Information Elements

   Unless defining an Information Element which is a direct copy of a
   bitfield or other structured entity (e.g., the tcpControlBits
   Information Element for the Flags byte from the TCP header) in a
   measured protocol, the definition of Information Elements with

I think it would read better with this text before the parenthesised example.
ie, give the example after the explanation.

   internal structure with the structure defined in the Description
   field is discouraged.  In this case, the field SHOULD be decomposed
   into multiple primitive Information Elements to be used in parallel.

There's a danger here, when there are multiple instances of the field. So instead of exporting multiple instances of a single structured field, "X:Y" like so:

     { X:Y, X:Y, X:Y }

we prefer to export multiple instances of the broken down fields:

    { X, Y, X, Y, X, Y }

- which may make sense, if the collector knows to relate the first X and Y together, the second X with the second Y etc...

However, the following is also quite legitimate:

    { X, X, X, Y, Y, Y }

Again it follows the same rule: first X relates to first Y etc. However, now it's a lot less clear that X and Y are related. Yet it's not any less valid.

   For more complicated semantics, where the structure may not have use
   the IPFIX Structured Data [I-D.ietf-ipfix-structured-data] extension
   instead.

Missing text? Where the structure may not have... what? 

   As an example of information element decomposition, consider an
   application-level identifier called an "endpoint", which represents a
   {host, port, protocol} tuple.  Instead of allocating an opaque,
   structured "source endpoint" Information Element, the source endpoint
   should be represented by three separate Information Elements: "source
   address", "source port", "transport protocol".  Indeed, in this
   example, the required information elements already exist in the
   Information Element registry: sourceIPv4Address or sourceIPv6Address,
   sourceTransportPort, protocolIdentifier.  Indeed, as well as being
   good practice, this normalization down to non-structured Information
   Elements also increases opportunities for reuse as in Section 6.1.

This example is perfect for structured data.

   The decomposition of data with internal structure SHOULD avoid the
   definition of Information Elements with a meaning too specific to be
   generally useful, or that would result in either the export of
   meaningless data or a multitude of templates to handle different
   multiplicities.  A specific example of this within the IANA registry
   is the following list of assigned IPFIX Information Elements:
   mplsTopLabelStackSection, mplsLabelStackSection2,
   mplsLabelStackSection3, mplsLabelStackSection4,
   mplsLabelStackSection5, mplsLabelStackSection6
   mplsLabelStackSection7, mplsLabelStackSection8,
   mplsLabelStackSection9, and mplsLabelStackSection10.  The only



Trammell & Claise         Expires April 4, 2011                 [Page 8]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   distinction between those almost-identical Information Elements is
   the position within the MPLS stack.  This Information Element design
   pattern met an early requirement of the definition of IPFIX which was
   not carried forward into the final specification -- namely, that no
   semantic dependency was allowed between Information Elements in the
   same Record -- and as such SHOULD NOT be followed in the definition
   of new Information Elements.  In this case, since the size of the
   MPLS stack will vary from flow to flow, it should be exported using
   IPFIX Structured Data [I-D.ietf-ipfix-structured-data] where
   supported, as a basicList of MPLS label entries.

   Note that a Template may contain multiple instances of the same
   Information Element; in this case, the each of the Information

Typo.

   Elements in the Template are semantically indistinguishable, and
   appear in their "natural" order, where natural order is defined
   according to application; PSAMP uses this for exporting selectors.
   Multiple IEs used in this way are preferable to IEs with internal
   structure, but only when there is some natural order, and no semantic
   interdependence among the elements.

4.5.  Enumerated Values and Subregistries

   When defining an Information Element that takes an enumerated value
   from a set of values which may change in the future, this enumeration
   MUST be defined by an IANA registry or subregistry.  For situations
   where an existing registry defines the enumeration (e.g., the IANA
   Protocol Numbers registry for the protocolIdentifier Information
   Element), that registry MUST be used.  Otherwise, a new IPFIX
   subregistry must be defined for the enumerated value, to be modified
   subject to Expert Review [RFC5226].

There's some ongoing discussion with Nevil as to whether sub-registries should be used, or whether the values can be recorded directly in the element description.

Again, the version control issue...

4.6.  Reversibility as per RFC 5103

   [TODO: fix this para][RFC5103] defines a method for exporting
   bidirectional flows using a special Private Enterprise Number to
   define reverse-direction variants of IANA Information Elements, and a
   set of criteria for determining whether an Information Element may be
   reversed using this method.  Section 6.1 of [RFC5103] states that CPs
   should use the set of criteria therein to determine reversibility.
   Since almost all Information Elements are reversible, these criteria
   are expressed as to determine the exceptions, i.e. which Information
   Elements are NOT reversible.

   To ease the determination of reversibility, future Information
   Elements which are NOT reversible SHOULD note this fact in the
   description at the time of definition.

Can you include some examples of non-reversible elements?




Trammell & Claise         Expires April 4, 2011                 [Page 9]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


5.  The Information Element Lifecycle: Revision and Deprecation

   The Information Element status field in the Information Element
   Registry is defined in [RFC5102] to allow Information Elements to be
   'deprecated' or 'obsolete'.  No Information Elements are as of this
   writing deprecated, and but provides no further explanation of these
   statuses, [RFC5102] does not define any policy for using them.

This doesn't make sense.

   Additionally, no policy is defined for revising Information Element
   registry entries or addressing errors therein.  To be certain,
   changes and deprecations within the Information Element registry are
   not encouraged, and should be avoided to the extent possible.

Clarify whether addition of new values is a change.

   However, in recognition that change is inevitable, this section is
   intended to remedy this situation.

   The primary requirement in the definition of a policy for managing
   changes to existing Information Elements is avoidance of
   interoperability problems; IPFIX experts appointed to review changes
   to the Information Element Registry MUST work to maintain
   interoperability above all else.  Changes to Information Elements
   already in use may only be done in an interoperable way; necessary
   changes which cannot be done in a way to allow interoperability with
   unchanged implementations MUST result in deprecation.

   A change to an Information Element is held to be interoperable only
   when:

   o  it involves the correction of an error which is obviously only
      editorial; or

   o  it corrects an ambiguity in the Information Element's definition,
      which itself leads to non-interoperability (e.g., a prior change
      to ipv6ExtensionHeaders); or

Cite the errata for this:

http://www.rfc-editor.org/errata_search.php?eid=1738

   o  it expands the Information Element's data type without changing
      how it is represented (e.g., changing unsigned32 to unsigned64, as
      with a prior change to selectorId); or

http://www.rfc-editor.org/errata_search.php?eid=2052

   o  it defines a previously undefined or reserved enumerated value, or
      one or more previously reserved bits in an Information Element
      with flag semantics; or

   o  it expands the set of permissible values in the Information
      Element's range; or

These two changes may NOT be interoperable.

eg, an exporter reporting an additional (new) value to a collector which hasn't been updated to understand that new value (though the collector was 100% IPFIX compliant at the time of implementation).

Somewhere in here you should discuss version control of the IANA registry, so every change is clearly called out. Find out how other protocols deal with change.

   o  it harmonizes with an external reference which was itself
      corrected.

This is a potentially dangerous change. The correct route may be to deprecate the wrongly defined IE and create a new IE with the correct definition.

   A non-interoperable Information Element change may also be made if it



Trammell & Claise         Expires April 4, 2011                [Page 10]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   can be reasonably assumed in the eyes of the appointed experts that
   no unchanged implementation of the Information Element exists; this

A subjective opinion is NOT sufficient. They should query the IPFIX community as widely as possible.

   can be held to happen if a non-interoperable change to an Information
   Element defined shortly before is proposed to the IPFIX mailing list
   by the original proposer of the Information Element, and no objection
   is raised within a reasonable amount of time, to be defined by the
   expert reviewers.

Is this by way of an example, or is it by way of limitation? If the former, state "for example". If the latter, state "this can only be held to happen".

   If a change is permissible, it is sent to IANA, which passes it to

Who determines whether a change is permissible? This reads as if the change submitter self-determines? I'd have expected change requests to be sent to IANA which forwards them to the expert(s) who determine permissibility.

   the appointed experts for review; if there is no objection to the
   change from any appointed expert, IANA makes the change in the
   Information Element Registry.  Changes that are not permissible MUST
   be handled by deprecation.

They can also be rejected outright. Else, by the MUST, a determined individual can completely deprecate the existing info model by requesting a sufficient number of changes.

   An Information Element MAY be deprecated and replaced when:

   o  the Information Element definition has an error or shortcoming
      which cannot be permissibly changed as above; or

   o  the deprecation harmonizes with an external reference which was
      itself deprecated through that reference's accepted deprecation
      method; or

Depending on the external action, the IE may be deprecated and not replaced.

   o  changes in the IPFIX Protocol or its extensions, or in community
      understanding thereof, allow the information represented by the
      Information Element to be represented in a more efficient or
      convenient way.  Deprecation in this circumstance additionally
      requires the assent of the IPFIX Working Group, and should be
      specified in the Internet Draft(s) defining the protocol change.

   A request for deprecation is sent to IANA, which passes it to the
   appointed experts and a responsible Operations Area Director for

This is new.

   review; if there is no objection to the change from any appointed
   expert, IANA makes the change in the Information Element Registry
   according to its internal procedures.  When deprecating an
   Information Element, the Information Element description MUST be
   updated to explain the deprecation, as well as to refer to any new
   Information Elements created to replace the deprecated Information
   Element.

   Deprecated Information Elements SHOULD continue to be supported by
   Collecting Processes, but SHOULD NOT be exported by Exporting
   Processes.  The use of deprecated Information Elements SHOULD result
   in a log entry or human-readable warning at the Exporting and

That's crazy! You're saying that the EP should be updated to report that it's still sending deprecated fields? LOL. If you're going to update it to know that it's sending an obsolete field, your time would clearly be better spent updating it not to export that field any more.

   Collecting Processes.  After a period of time determined in the eyes

Split to a new paragraph at "After".

   of the appointed experts to be reasonable in order to allow deployed
   Exporting Processes to be updated to account for the deprecation, a
   deprecated Information Element may be made obsolete.  Obsolete



Trammell & Claise         Expires April 4, 2011                [Page 11]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   Information Elements MUST NOT be supported by either Exporting or
   Collecting Processes.  The receipt of obsolete Information Elements
   SHOULD be logged by the Collecting Process.

...and? Should the fields and/or records be discarded or processed?
(Clue: "Be strict in what you send, but generous in what you receive.")

   Names of deprecated Information Elements MUST NOT be reused.  Names
   of obsolete Information Elements MAY be reused, but this is NOT
   RECOMMENDED, as it may cause confusion among users.

Be consistent: if names are the primary reference (rather than the ID numbers, strangely), then don't allow names to be reused at all.


6.  When not to define new Information Elements

   Also important in defining new applications is avoiding redundancy
   and clutter in the Information Element registry.  Here we provide
   guidelines for reuse of existing Information Elements, as well as
   guidelines on using enterprise-specific Information Elements instead
   of adding Information Elements in the registry.

"to"

6.1.  Maximizing reuse of existing Information Elements

   Whenever possible, new applications should prefer usage of existing
   IPFIX Information Elements to the creation of new Information
   Elements.  IPFIX already provides Information Elements for every
   common Layer 4 and Layer 3 packet header field in the IETF protocol
   suite, basic Layer 2 information, basic counters, timestamps and time
   ranges, and so on.  When defining a new Information Element similar
   to an existing one, reviewers shall ensure that the existing one is
   not applicable.

"... the expert reviewers MUST ..." ?

   Simply changing the context in which an Information Element will be
   used is insufficient reason for the definition of a new Information
   Element.  For example, an extension of IPFIX to log detailed
   information about HTTP transactions alongside network-level
   information should not define httpClientAddress and httpServerAddress
   Information Elements, preferring instead the use of
   sourceIPv[46]Address and destinationIPv[46]Address.

I've got http through a tunnel, proxy or NAT, such that there are two source addresses and two destination addresses.
One src/dst pair is for http, the other belongs to the tunnel, proxy or NAT. What do you propose?

   Applications dealing with bidirectional interactions should use
   Bidirectional Flow Support for IPFIX [RFC5103] to represent these
   interactions.

   Specifically, existing timestamp and time range Information Elements
   should be reused for any situation requiring simple timestamping of
   an event: for single observations, the observationTime* Information
   Elements from PSAMP are provided, and for events with a duration, the
   flowStart* and flowEnd* Information Elements suffice.  This
   arrangement allows minimal generic time handling by existing
   Collecting Processes and analysis workflows.  New timestamp
   Information Elements should ONLY be defined for semantically distinct



Trammell & Claise         Expires April 4, 2011                [Page 12]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   timing information (e.g., an IPFIX-exported record containing
   information about an event to be scheduled in the future).

   In all cases the use of absolute timestamp Information Elements (e.g.
   flowStartMilliseconds) is RECOMMENDED, as these Information Elements
   allow for maximum flexibility in processing with minimal overhead.
   Timestamps based on the export time header in the enclosing IPFIX
   Message (e.g. flowStartTimeDeltaMicroseconds) MAY be used if high-
   precision timing is important, export bandwidth or storage space is
   limited, timestamps comprise a relatively large fraction of record
   size, and the application naturally groups records into Messages.
   Timestamps based on information which must be exported in a separate
   Options Template (e.g. flowStartSysUpTime) MAY be used only in the
   context of an existing practice of using runtime-defined epochs for
   the given application.

   The best practice in Information Element creation is a conservative
   one: don't create a new Information Element unless you really need
   it.

Of course you really need it. However, does the wider IPFIX community really need it?

6.2.  Applying enterprise-specific Information Elements

   IPFIX provides a mechanism for defining enterprise-specific
   Infomation Elements, as in Section 3.2 of [RFC5101].  These are
   scoped to a vendor's or organization's Structure of Management
   Information (SMI) Private Enterprise Number, and are under complete
   control of the organization assigning them.

Cite xref.

   For situations in which interoperability is unimportant, new
   information SHOULD be exported using enterprise-specific Information
   Elements instead of adding new Information Elements to the registry.
   These situations include:

   o  export of implementation-specific information, or

   o  export of information derived in a commercially-sensitive or
      proprietary method, or

   o  export of information or meta-information specific to a
      commercially-sensitive or proprietary application.

   While work within the IETF generally does not fall into these
   categories, enterprise-specific Information Elements are also useful
   for pre-standardization testing of a new IPFIX application.  While
   performing initial development and interoperability testing of a new
   application, the Information Elements used by the application SHOULD
   NOT be submitted to IANA for inclusion in the registry.  Instead,
   these experimental Information Elements SHOULD be represented as



Trammell & Claise         Expires April 4, 2011                [Page 13]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   enterprise-specific until their definitions are finalized, then
   transitioned from enterprise-specific to IANA-defined upon
   finalization.


7.  Applying IPFIX to non-Flow Applications

   At the core of IPFIX is its definition of a Flow, a set of packets
   sharing some common properties crossing an observation point within a
   certain time window.  However, the reliance on this definition does
   not preclude the application of IPFIX to domains which are not
   obviously handling flow data according to it.  Most network

According to what? Perhaps just drop these words?

   management data collection tasks, those to which IPFIX is most
   applicable, have at their core the movement of packets from one place
   to another; by a liberal interpretation of the common properties
   defining the flow, then, almost any event handled by these can be
   held to concern data records conforming to the IPFIX definition of a
   Flow.

Is it strictly necessary to convince oneself that a flow exists in order to use IPFIX?

   Non-flow information defining associations or key-value pairs, on the
   other hand, are handled by IPFIX Options.  Here, the Information
   Elements within an Options Template are split into Scope IEs which
   define the key, and non-scope IEs which define the values associated
   with that key.  Unlike Flows, Options are not necessarily scoped in
   time; an Option is generally held to be in effect until a new set of
   values for a specific set of keys is exported.  While Options are
   often used by IPFIX to export metadata about the collection
   infrastructure, they are applicable to any association information.

IIRC, there was some discussion about time-scoping IPFIX options and templates some years ago. eg, we can export a template, indicating that it will be valid from 6pm until midnight. Or pre-export an option, indicating that a new selectorAlgorithm will be in force from 6am.

   An IPFIX application can mix Flow Records and Options in an IPFIX
   Message or Message stream, and exploit relationships among the Flow
   Keys, values, and Scopes to create interrelated data structures.  See
   [RFC5473] for an example application of this.


8.  Defining Recommended Templates

   New IPFIX applications SHOULD NOT, in the general case, define fixed
   templates for export, as this throws away much of the flexibility
   afforded by IPFIX.  However, fixed template export is permissible in
   the case that the export implementation must operate in a resource
   constrained environment, and/or that the application is replacing an
   existing fixed-format binary export format in a maximally compatible
   way.  In any case, Collecting Processes for such applications SHOULD
   support reordered Templates or Templates with additional Information
   Elements.

   An Internet-Draft clarifying the use of new Information Elements



Trammell & Claise         Expires April 4, 2011                [Page 14]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   SHOULD include any recommended Templates or Options Templates
   necessary for supporting the application, as well as examples of

No it shouldn't, because implementers will blindly follow these and system specifiers will expect exactly these templates / options an no others, in order to be 100% compliant with the RFC / definition.

Rather, the ID MUST specify which fields are required in the option / template, if any, and MAY give example options and templates, clearly labelling them as such.

   records exported using these Templates.  In defining these Templates,
   such Internet-Drafts SHOULD mention, subject to rare exceptions as
   above:

   o  that the order of Information Elements within a Template is not
      significant;

   o  that Templates on the wire for the application may also contain
      additional Information Elements beyond those specified in the
      recommended Template;

   o  that a stream of IPFIX Messages supporting the application may
      also contain Data Records not described by the recommended
      Templates; and

   o  that any reader of IPFIX Messages supporting the application MUST
      accept these conditions.

   Definitions of recommended Templates for flow-like information, where
   the Flow Key is well-defined, SHOULD indicate which of the
   Information Elements in the recommended Template are Flow Keys.

There's a flowKeyIndicator for that, if it's needed.

   Recommended Templates are defined, for example, in [RFC5476] for
   PSAMP packet reports (section 6.4) and extended packet reports
   (section 6.5).  Recommended Options Templates are defined extensively
   throughout the IPFIX documents, including in the protocol document
   itself [RFC5101] for exporting export statistics; in the file format
   [RFC5655] for exporting file metadata; and in Mediator intermediate
   process definitions such as [I-D.ietf-ipfix-anon] for intermediate
   process metadata.  The discussion in these examples is a good model
   for recommended template definitions.

In your experience (or a quick poll?) do current IPFIX systems implement these exactly as specified, or does anyone implement them with the caveats described above (eg, in a different order, or with additional fields) ?

   However, the bitmap diagrams of these Templates are illustrative but
   not particularly readable for more complicated recommended Templates,
   provide no support for rapid implementation of new Templates, and do
   not adequately convey the optional nature of ordering and additional
   Information Elements as above.  Therefore, we have defined
   RECOMMENDED textual format for specifying Information Elements and
   Templates in Internet-Drafts in Section 9.


9.  A Textual Format for Specifying Information Elements and Templates

   The extension of IPFIX will generate a fair amount of documentation

"Any extension of IPFIX may be expected to generate..."

   and discussion covering the definition of new Information Elements.
   Here we define a simple textual syntax for describing IPFIX



Trammell & Claise         Expires April 4, 2011                [Page 15]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   Information Elements and IPFIX Templates, with human readability,
   human writability, compactness, and ease of parser/generator
   implementation without requiring external XML support as design
   goals.  It is intended both for use in human communication (e.g., in
   new Internet-Drafts containing higher-level descriptions of IPFIX
   Templates, or describing sets of new IPFIX Information Elements for
   supporting new applications of the protocol) as well as at runtime by
   IPFIX implementations.

9.1.  Information Element Specifiers

   The basis of this format is the textual Information Element
   Specifier, or IESpec.  An IESpec contains each of the four important
   aspects of an Information Element: its name, its number, its type,
   and its size, separated by simple markup based on various types of

No semantics, units, range?

   brackets.  Fully-qualified IESpecs may be used to specify existing or
   new Information Elements within an Information Model, while either
   fully-qualified or partial IESpecs may be used to define fields in a
   Template.

   Bare words are used for Information Element names, and each aspect of
   information associated with an Information Element is associated with
   a type of brackets:

   o  () parentheses for Information Element numbers,

   o  <> angles for Information Element data types, and

   o  [] square brackets for Information Element sizes.

   o  {} curly braces contain an optional space-separated list of
      context identifiers to be associated with an Information Element,
      as described in more detail in Section 9.2

   The symbol + is reserved for Information Element nesting within
   structured data elements; these are described in and Section 9.3,
   respectively.

   Whitespace in IESpecs is insignificant; spaces can be added after
   each element in order, e.g., to align columns for better readability.

   The basic form of a fully-qualified IESpec for an IANA-registered
   Information Element is as follows:

   name(number)<type>[size]

As long as all the information is present, is the order important? eg, using the example from below, one might prefer to write:

         [8] (152) flowStartMilliseconds    <dateTimeMilliseconds>
         [8] (153) flowEndMilliseconds      <dateTimeMilliseconds>
         [8]   (1) octetDeltaCount          <unsigned64>
         [8]   (2) packetDeltaCount         <unsigned64>
   {key} [4]   (8) sourceIPv4Address        <ipv4Address>
   {key} [4]  (12) destinationIPv4Address   <ipv4Address>
   {key} [2]   (7) sourceTransportPort      <unsigned16>
   {key} [2]  (11) destinationTransportPort <unsigned16>
   {key} [1]   (4) protocolIdentifier       <unsigned8>

   where 'name' is the name of the Information Element in UTF-8,
   'number' is the Information Element as a decimal integer, 'type' is



Trammell & Claise         Expires April 4, 2011                [Page 16]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   the name of the data type as in the IANA informationElementDataTypes
   registry, and 'size' is the length of the Information Element in
   octets as a decimal integer, where 65535 or the string 'v' signifies
   a variable-length Information Element. [size] may be omitted; in this
   case, the data type's native or default size is assumed.

   The basic form of a fully-qualified IESpec for an enterprise-specific
   Information Element is as follows:

   name(pen/number)<type>[size]

   where 'pen' is the Private Enterprise Number as a decimal integer.

   A fully-qualified IESpec is intended to express enough information
   about an Information Element to decode and display Data Records
   defined by Templates containing that Information Element.  Range,
   unit, semantic, and description information, as in [RFC5610], is not
   supported by this syntax.

   Example fully-qualified IESpecs follow:

      octetDeltaCount(1)<unsigned64>[8]

      octetDeltaCount(1)<unsigned64> (unsigned64 is natively 8 octets
      long)

      sourceIPv4Address(8)<ipv4Address>

      wlanSSID(146)<string>[v]

It's 147.

      sipRequestURI(35566/403)<string>[65535]

   A partial IESpec is any IESpec that is not fully-qualified; these are
   useful when defining templates.  A partial IESpec is assumed to take
   missing values from its canonical definition, for example, the IANA
   registry.  At minimum, a partial IESpec must contain a name, or a
   number.  Any name, number, or type information given with a partial
   IESpec must match the values given in the Information Model; however,
   size information in a partial IESpec overrides size information in
   the Information Model; in this way, IESpecs can be used to express
   reduced-length encoding for Information Elements.

   Example partial IESpecs follow:

   o  octetDeltaCount

   o  octetDeltaCount[4] (reduced-length encoding)




Trammell & Claise         Expires April 4, 2011                [Page 17]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   o  (1)

   o  (1)[4] (reduced length encoding; note that this is exactly
      equivalent to an Information Element specifier in a Template)

9.2.  Specifying Templates

   A Template can then be defined simply as an ordered, newline-
   separated sequence of IESpecs.  IESpecs in example Templates
   illustrating a new application of IPFIX SHOULD be fully-qualified.
   Flow Keys may be optionally annotated by appending the {key} context
   to the end of each Flow Key specifier.  A template counting packets
   and octets per five-tuple with millisecond precision in IESpec syntax
   is shown below.

   flowStartMilliseconds(152)<dateTimeMilliseconds>[8]
   flowEndMilliseconds(153)<dateTimeMilliseconds>[8]
   octetDeltaCount(1)<unsigned64>[8]
   packetDeltaCount(2)<unsigned64>[8]
   sourceIPv4Address(8)<ipv4Address>[4]{key}
   destinationIPv4Address(12)<ipv4Address>[4]{key}
   sourceTransportPort(7)<unsigned16>[2]{key}
   destinationTransportPort(11)<unsigned16>[2]{key}
   protocolIdentifier(4)<unsigned8>[1]{key}

   An Options Template is specified similarly.  Scope is specified

"specified by"

   appending the {scope} context to the end of each IESpec for a Scope

See earlier about ordering.

   IE.  Due to the way Information Elements are represented in Options
   Templates, all {scope} IESpecs must appear before any non-scope
   IESpec.  The Flow Key Options Template defined in section 4.4 of
   [RFC5101] in IESpec syntax is shown below:

Nonsense! That's only true when the IEs are being exported in an option on the wire, because that's how the protocol works.
However, when writing them down, they can be any way around that you like.

eg, specifications written by people who are unfamiliar with the exact details of the export protocols, but who simply want to use our exporter, sometimes list fields in alphabetical or numerical order. As long as {scope} is clearly indicated at the relevant place, it's up to us as protocol experts to deal with the ordering detail.

   templateId(145)<unsigned16>[2]{scope}
   flowKeyIndicator(173)<unsigned64>[8]

9.3.  Specifying IPFIX Structured Data

   IESpecs can also be used to illustrate the structure of the
   information exported using the IPFIX Structured Data extension
   [I-D.ietf-ipfix-structured-data].  Here, the semantics of the
   structured data elements are specified using contexts, and the
   information elements within each structured data element follow the
   structured data element, prefixed with + to show they are contained
   therein.  Arbitrary nesting of structured data elements is possible
   by using multiple + signs in the prefix.  For example, a basic list
   of IP addresses with "one or more" semantics would be expressed using
   parially qualified IESpecs as follows:

Typo, "partially".




Trammell & Claise         Expires April 4, 2011                [Page 18]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   basicList{oneOrMoreOf}
   +sourceIPv4Address(8)[4]

   And an example subTemplateList itself containing a basicList is shown
   below:

   subTemplateList{allOf}
   +basicList{oneOrMoreOf}
   ++sourceIPv4Address(8)[4]
   +destinationIPv4Address(12)[4]

   This describes a subTemplateMultilist containing all of the expressed
   set of source-destination pairs, where the source address itself
   could be one of any number in a basicList (e.g., in the case of SCTP
   multihoming).

   The contexts associable with structured data Information Elements are
   the semantics, as defined in section 4.4 of
   [I-D.ietf-ipfix-structured-data]; a structured data Information
   Element without any context is taken to have undefined semantics.
   More information on the application of structured data is available
   in [I-D.ietf-ipfix-structured-data].


10.  Security Considerations

   The security aspects of new Information Elements must be considered
   in order not to give a potential attacker too much information.  For
   example, the "A Framework for Packet Selection and Reporting"
   [RFC5474] concluded in section 12.3.2 that the hash functions private
   parameters should not exported within IPFIX.

   If some security considerations are specific to an Information
   Element, they MUST be mentioned in the Information Element
   description.  For example, the ipHeaderPacketSection in the IPFIX
   registry mentions: "This Information Element, which may have a
   variable length, carries a series of octets from the start of the IP
   header of a sampled packet.  With sufficient length, this element
   also reports octets from the IP payload, subject to [RFC2804].  See
   the Security Considerations section."

Crucially, the relevant RFC containing the Security Considerations is cited in the registry 'Requester" column. Without that, this text wouldn't make sense.

   These security considerations MAY also be stressed in a separate
   draft.  For example, the "Packet Sampling (PSAMP) Protocols
   Specification" [RFC5476] specifies: "In the basic Packet Report, a
   PSAMP Device exports some number of contiguous bytes from the start
   of the packet, including the packet header (which includes link
   layer, network layer and other encapsulation headers) and some
   subsequent bytes of the packet payload.  The PSAMP Device SHOULD NOT



Trammell & Claise         Expires April 4, 2011                [Page 19]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   export the full payload of conversations, as this would mean
   wiretapping [RFC2804].  The PSAMP Device MUST respect local privacy
   laws."


11.  IANA Considerations

   [TODO - collect IANA considerations from the document once we have
   them.]


12.  Acknowledgements

   [TODO]

TIA ;-)


13.  Open Issues

   o  add examples everywhere (including sipclf)

   o  explain the range 0-127.

   o  explain that existing draft should use temporary IE identifier

Not just existing, but new drafts too.

      such as XXX, YYY, and ZZZ both in the text and in the examples,
      and a note to IANA: "to be replaced by IANA when the IE identifier
      is assigned"

   o  TBD (in WG): Do we want the IE-Doctors to be a formal directorate
      under the OPS area?  What can we take from the experience of PMOL?


14.  References

14.1.  Normative References

   [RFC5101]  Claise, B., "Specification of the IP Flow Information
              Export (IPFIX) Protocol for the Exchange of IP Traffic
              Flow Information", RFC 5101, January 2008.

   [RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
              Meyer, "Information Model for IP Flow Information Export",
              RFC 5102, January 2008.

   [RFC5103]  Trammell, B. and E. Boschi, "Bidirectional Flow Export
              Using IP Flow Information Export (IPFIX)", RFC 5103,
              January 2008.

   [RFC5610]  Boschi, E., Trammell, B., Mark, L., and T. Zseby,



Trammell & Claise         Expires April 4, 2011                [Page 20]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


              "Exporting Type Information for IP Flow Information Export
              (IPFIX) Information Elements", RFC 5610, July 2009.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

14.2.  Informative References

   [RFC2804]  IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
              May 2000.

   [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
              "Requirements for IP Flow Information Export (IPFIX)",
              RFC 3917, October 2004.

   [RFC4181]  Heard, C., "Guidelines for Authors and Reviewers of MIB
              Documents", BCP 111, RFC 4181, September 2005.

   [RFC5153]  Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P.
              Aitken, "IP Flow Information Export (IPFIX) Implementation
              Guidelines", RFC 5153, April 2008.

   [RFC5470]  Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
              "Architecture for IP Flow Information Export", RFC 5470,
              March 2009.

   [RFC5471]  Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP
              Flow Information Export (IPFIX) Testing", RFC 5471,
              March 2009.

   [RFC5472]  Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP
              Flow Information Export (IPFIX) Applicability", RFC 5472,
              March 2009.

   [RFC5473]  Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy
              in IP Flow Information Export (IPFIX) and Packet Sampling
              (PSAMP) Reports", RFC 5473, March 2009.

   [RFC5474]  Duffield, N., Chiou, D., Claise, B., Greenberg, A.,
              Grossglauser, M., and J. Rexford, "A Framework for Packet
              Selection and Reporting", RFC 5474, March 2009.

   [RFC5476]  Claise, B., Johnson, A., and J. Quittek, "Packet Sampling
              (PSAMP) Protocol Specifications", RFC 5476, March 2009.



Trammell & Claise         Expires April 4, 2011                [Page 21]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   [RFC5655]  Trammell, B., Boschi, E., Mark, L., Zseby, T., and A.
              Wagner, "Specification of the IP Flow Information Export
              (IPFIX) File Format", RFC 5655, October 2009.

   [I-D.ietf-ipfix-structured-data]
              Claise, B., Dhandapani, G., Yates, S., and P. Aitken,
              "Export of Structured Data in IPFIX",
              draft-ietf-ipfix-structured-data-02 (work in progress),
              July 2010.

   [I-D.ietf-ipfix-anon]
              Boschi, E. and B. Trammell, "IP Flow Anonymisation
              Support", draft-ietf-ipfix-anon-03 (work in progress),
              April 2010.

   [iana-ipfix-assignments]
              Internet Assigned Numbers Authority, "IP Flow Information
              Export Information Elements
              (http://www.iana.org/assignments/ipfix/ipfix.xml)".


Authors' Addresses

   Brian Trammell
   Swiss Federal Institute of Technology Zurich
   Gloriastrasse 35
   8092 Zurich
   Switzerland

   Phone: +41 44 632 70 13
   Email: trammell@tik.ee.ethz.ch


   Benoit Claise
   Cisco Systems, Inc.
   De Kleetlaan 6a b1
   1831 Diagem
   Belgium

   Phone: +32 2 704 5622
   Email: bclaise@cisco.com










Trammell & Claise         Expires April 4, 2011                [Page 22]

--------------060403050408050604060603-- From n.brownlee@auckland.ac.nz Wed Nov 10 19:15:14 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 040273A6960 for ; Wed, 10 Nov 2010 19:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3tNUUKRVFH1 for ; Wed, 10 Nov 2010 19:15:12 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id EB05E3A68FF for ; Wed, 10 Nov 2010 19:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1289445335; x=1320981335; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4CDB5FCD.6070303@auckland.ac.nz>|Date:=20 Wed,=2010=20Nov=202010=2019:15:25=20-0800|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20ipfix-ads@tools.ietf.org,=20IPFIX=20list=20< ipfix@ietf.org>|Subject:=20IPFIX=20Minutes=20and=20one-pa ra=20summery|Content-Transfer-Encoding:=207bit; bh=Fzj6B3N1UHJJG/8GZP3YSCCr4fhPHIYe3d9t5ivzFng=; b=AnaLYUOlkHMdBCL6nAsUdbgI4VPlNgOSi8kgFXM4AMOVfBDTS1JvuKax u3lBzSNiu0a0AcSLEnwQ/FqYAXS0Zx1R/RVhN+DioxGJ1b0boXNVM9MC8 xcmQclLd0nxrq6Hxb8tObpwLQH9V330bU3FUdFSdY4KibR9IFvQo5TZsk c=; X-IronPort-AV: E=Sophos;i="4.59,181,1288522800"; d="scan'208";a="35044932" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.39.179 - Outgoing - Outgoing-SSL Received: from dhcp-27b3.meeting.ietf.org (HELO [130.129.39.179]) ([130.129.39.179]) by mx2-int.auckland.ac.nz with ESMTP; 11 Nov 2010 16:15:30 +1300 Message-ID: <4CDB5FCD.6070303@auckland.ac.nz> Date: Wed, 10 Nov 2010 19:15:25 -0800 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: ipfix-ads@tools.ietf.org, IPFIX list Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] IPFIX Minutes and one-para summery X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 03:15:14 -0000 Hi Dan: Here's a one-paragraph summary of the IPFIX Meeting yesterday: IPFIX met on Wednesday morning. We currently have two uncompleted work items, but expect to submit these to IESG before the end of 2010. Nine 'new' drafts were presented, as possible work items. Two of these would extend our work on IPFIX Mediation, a third would provide a clear set of guidelines for establishing new IPFIX Information Elements. And here is my current DRAFT of the meeting minutes: Minutes of the IPFIX meeting at IETF 79 About 30 people present Scribes: Nevil Brownlee & Benoit Claise Juergen Quittek reported on the IPFIX WG Status. We have one draft in the RFC-Editor Queue, one in AD-Followup and one that's just completed IETF Last Call. The Configuration Model and Flow Selection drafts are in final edit, and should be finished shortly. That leaves two drafts in our current charter, Structured Data and PSAMP MIB. Benoit Claise presented an update on the Structured Data draft, which has generated a lot of mailing list following its WG Last Call. Most of the issues have been resolved, but Brian Trammel and Hadriel Kaplan made further comments. Discussion continues on the list, Juergen Quittek presented the PSAMP MID draft. This only needed textual conventions for 64-bit unsigned integers and real. The MIB Doctors have provided one for Unsigned64, but we will need to create a new one for IEEE 64-bit floating objects. Dan Romascanu pointed out that our Float64 TC should be general, so that other MIBs can use it. The meeting moved on to presentations of current non-charter work. Benoit presented the IPFIX Mediation Protocol draft. This draft provides a clear overview of how a Mediation Function needs to behave. At this stage we have two such functions - Anonymisation and Flow Selection - with Aggregation (see below) as the third. The goal for this draft is to make it simpler to creat new Mediator Functions, each only needs to describe/explain anything that's not covered in te Mediation Protocol document. Brian Trammell presented the Aggregation Draft, pointing out that although the concept is simple, one cannot avoid interactions between temporal and spatial aggregation. An important WG task will be to check the consistency of all the Mediator related drafts, as shown in slide 2 of this presentation; in particular, the Flow Selection draft by no means completes our work on Mediation. The meeting expressed consensus for this work, it will be discussed further on the list. Brian presented a new draft on "IPFIX IE Doctors." This seeks to collect our experience of creating new IEs, and to establish clear rules and conventions for doing that. Aamer Akhter commented that his Performance Measurement draft is an example of how the IE Doctors document would be used. Nevil Brownlee commented that this draft is an important step forward for IPFIX, paving the way for future use of IPFIX by WGs other than IPFIX itself. Hadriel Kaplan commented that we also need a new document, "IPFIX for Dummies." Dan commented that although this is clearly important, it needs to done very carefully, especially for future mission-critical uses. There was clear consensus for having this as a WG item; to be discussed further on the list. Juergen led a discussion on "should we move the IPFIX base standards (RFCs 5101, 5102 and 5103) to Draft Standard. There was consensus that this would be worthwhile if it corrected all the bugs discovered to date in the documents, and added explanatory text to make them easier to understand. We also need to remove 'IP' from the IPFIX Flow definition, since that is proving to be a blocking factor or the ITU-T NGN to reference IPFIX. Juergen pointed out that we should organise an interoperability test to verify that the various IPFIX implementations do interoprate properly, and proposed that we arrange this somewhere (not at IETF) around IETF 80 in March 2011. He asked for anyone interested in helping to prepare a series of tests to please get involved on the list. Five other new drafts were presented: Shingo Kashima presented "IEs for the Data Link Layer." The idea here is to add more IEs at Layer 2. Dan pointed out that we should re-use whatever we can at L2 (don't re-invent it). Several people commented that 5102 already has many IEs at layers other than IP (layer 3). Shingo Kashima presented "IEs for Short Timer" This describes two new IEs that would provide higher resolution for Flow Start and End times. Consensus here was that these would certainly be useful, and could be done by simply requesting them from IANA. Benoit CLaise presented "Exporting MIB Variables" This would provide a simple way to read SNMP variables at times that relate to flows. It would require two new IPFIX Set IDs. Aamer Akhter presented "Flow Performance Measurement" This would provide a way to use IPFIX to transport performance data from remote probes (IPFIX Exporters). Several people pointed out that the IPFIX WG should not define any metrics or ways to measure them. That should be done in other WGs. Benoit Claise presented "Exporting Application Information." The idea here is to develop a set of standard 'Application Identifiers' that would be independent of the ports being used, and which could be used by all implementers. This will clearly require a lot of discussion if it is to be implemented. We did not call for consensus on these five items, but the first four of these are potential WG items; they will continue to be discussed on the list. The meeting finished at 1135. 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 Quittek@neclab.eu Wed Nov 10 22:32:24 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82A1B3A6A32 for ; Wed, 10 Nov 2010 22:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.116 X-Spam-Level: X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FR34UIYn7fXe for ; Wed, 10 Nov 2010 22:32:08 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 7F0A63A6A2D for ; Wed, 10 Nov 2010 22:32:04 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id DF38228000181 for ; Thu, 11 Nov 2010 07:32:32 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6uMYPJkZ-WT for ; Thu, 11 Nov 2010 07:32:32 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 331CF2800015D for ; Thu, 11 Nov 2010 07:32:27 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.241]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0255.000; Thu, 11 Nov 2010 07:32:27 +0100 From: Juergen Quittek To: IETF IPFIX Working Group Thread-Topic: WG last call on draft-ietf-ipfix-psamp-mib-02 Thread-Index: AcuBai1+qVvghx/pQUyE7MhH3EGq0A== Date: Thu, 11 Nov 2010 06:32:25 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.7.0.100913 x-originating-ip: [10.7.0.92] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3372330734_38378826" MIME-Version: 1.0 Subject: [IPFIX] WG last call on draft-ietf-ipfix-psamp-mib-02 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 06:32:24 -0000 --B_3372330734_38378826 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, This is the working group last call on draft-ietf-ipfix-psamp-mib-02. The call starts today and will last until Friday Nov 26. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-psamp-mib-02.txt Please read the draft. Please send your comments to this mailing list. Please also send a message if you are fine with the draft as it is. Thank you, Juergen --B_3372330734_38378826 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ5wYJKoZIhvcNAQcCoIIQ2DCCENQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Do8wggUzMIIEG6ADAgECAgQP7R53MA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTEwMDQyMDEyNDExMloXDTEzMDQxOTEyNDExMlow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANga4Hf5iSjDiva8/BTlatnXFlOWPfqZvY7AU6bt CUKFiaGwytFar7XCwRggHcCeodYaMZoDRSEGY+bRUDvayjNvFTkhL19Fmzxg4MPmQA92tcIb /+IylZD5YkVkw88/6zb6k+T+o875LlLAR79f8gvloaPMbxiB8KwQtdlGB9OiN1k3+7NiESpW myT8WWrWw4F7qc0WLXaWuqv6/3vRo+jJSxyOwefEnzrRojCePJ2ZD4mgPMQvMHPqodDhTvIB BupYoAtW53024WnL/PHH34pQ0Zmclz8u/YocnfMEYoyLDVuJKnQowDF75LVbnKmpXfCscKeb SndFpSANP2TiI2cCAwEAAaOCAb8wggG7MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQU9WUPxjFB AtJOXxJ7agqXozHDy9gwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHAYDVR0R BBUwE4ERUXVpdHRla0BuZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NkcDEu cGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEFBQcB AQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2EuZGZu LmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQADggEB AH9VRaZ978LNoc+eM/2k/OQafNJl4UjKLjiEnH8FCuqnuNXZMAOdcfnMrRKK1bl+FhCy3sjg gsuP4Nam2oSy7RDYWYjLY/MKMPO/MD/PpNSe6gox4948wfjWGmj4Uz3gqgDovQEC2H03jcPX etJqBTipqmfnvMFqozoN5zjiEzJuuLpLMYNPM+E+4pQnLtRAhN94C1e9C7oP66b7as6OgVVC CplE5llnoKM5ngtAFL5G3ygm/rZtptdmaNgRO6jDX1w9AOrsmSPGp+S+YRNonKGEqTolJpul EJB7rMdAUimsUp/qdzvWrhIZ6A3fgzHwFhrIHqVBlDLmu7cQHu/QMUEwggUvMIIEF6ADAgEC AgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVy ZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwg LSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMCREUx GDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmllcyBF dXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK6kKX nTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDBaSa+ nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i/W+u OQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMzVw94 Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQwggHA MBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAvmfa+ FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREEJjAk gSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9oDug OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3Js LmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIv Y3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9j ZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcG CCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEekP3l3 GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWclSZQ4 60jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yyPjzI VPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS09mE WRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkzJNfb fEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUA MHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQL ExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv b3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4t VmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0 iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txP eKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVY J9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYw cAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vydmlj ZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09U X0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu6 9VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0G CSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0Z MfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSF PT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0 hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBn qyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA 9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3Bl IEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlORUNM QUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUCBA/tHncwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTOYB1sA8GKF9VbobWupuGm u0P/IzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDExMTEw NjMyMTRaMA0GCSqGSIb3DQEBAQUABIIBAHd/AFGDuBC8u5yzE+WUGFcoz0+JtTutMEMmUFOW 8GW3p2NXdg9KOdyo0ApF3zpLt4xOhbXJmnGp8obpPhs47QaniJlKUqGDB11E+ticoxEdB4RW /yxBCZtDC46MKfJAxfetxc9RTTO1wOMn/TqaAq40iFi7XppQhrJZ24s5vMzhxihGkQ2y54b8 BrtlDLlhM7fj1PgfD0d8P/IYyAZebcUSPc5LTucDGXoPpkoioHvjcSkNwToo2kCU011YqRkC +fyDOQUaGLUOZNsb3yNUG20xf/TV3wI6haNWUUCD8/g8qj5GMGb7oEDZZaIqF3NKBrWkDEF8 4HqYRRxxkTHGnjo= --B_3372330734_38378826-- From paitken@cisco.com Fri Nov 12 03:50:42 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD35F3A68D4 for ; Fri, 12 Nov 2010 03:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.007 X-Spam-Level: X-Spam-Status: No, score=-8.007 tagged_above=-999 required=5 tests=[AWL=-1.241, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_HTML_URI_LHOST31=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzu8TVONytpM for ; Fri, 12 Nov 2010 03:50:29 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6BA533A69D6 for ; Fri, 12 Nov 2010 03:50:26 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,186,1288569600"; d="scan'208,217";a="181399512" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 Nov 2010 11:50:59 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oACBovhY003381; Fri, 12 Nov 2010 11:50:57 GMT Received: from [10.55.86.17] (dhcp-10-55-86-17.cisco.com [10.55.86.17]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id oACBop824261; Fri, 12 Nov 2010 11:50:51 GMT Message-ID: <4CDD2A1F.9040804@cisco.com> Date: Fri, 12 Nov 2010 11:50:55 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Juergen Quittek , "Benoit Claise (bclaise)" , dietz@neclab.eu Content-Type: multipart/alternative; boundary="------------040504030300000000040707" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-psamp-mib-02 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 11:50:42 -0000 This is a multi-part message in MIME format. --------------040504030300000000040707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, > This is the working group last call on draft-ietf-ipfix-psamp-mib-02. This draft requires additional editorial work. Please find comments inline below. Thanks, P. > Network Working Group T. Dietz, Ed. > Internet-Draft NEC Europe Ltd. > Intended status: Standards Track B. Claise > Expires: May 12, 2011 Cisco Systems, Inc. > J. Quittek > NEC Europe Ltd. > November 8, 2010 > > > Definitions of Managed Objects for Packet Sampling > > > Abstract > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes extensions to the IPFIX MIB module > [RFC5815]. For IPFIX implementations that use packet sampling > (PSAMP) techniques as described in [RFC5475], this memo defines the > PSAMP MIB module containing managed objects for providing information > on applied packet selection functions and their parameters. > > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on May 12, 2011. > > Copyright Notice > > Copyright (c) 2010 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 1] > > Internet-Draft PSAMP MIB November 2010 > > > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > > Table of Contents > > 1. Open Issues/TODOs . . . . . . . . . . . . . . . . . . . . . . 3 > > 2. The Internet-Standard Management Framework . . . . . . . . . . 3 > > 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 4. PSAMP Documents Overview . . . . . . . . . . . . . . . . . . . 4 > > 5. Related IPFIX Documents . . . . . . . . . . . . . . . . . . . 4 > > 6. Structure of the PSAMP MIB module . . . . . . . . . . . . . . 4 > 6.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 5 > 6.2. Packet Selection Functions . . . . . . . . . . . . . . . . 6 > 6.2.1. Systematic Count-based Sampling . . . . . . . . . . . 6 > 6.2.2. Systematic Time-based Sampling . . . . . . . . . . . . 6 > 6.2.3. Random n-out-of-N Sampling . . . . . . . . . . . . . . 7 > 6.2.4. Uniform Probabilistic Sampling . . . . . . . . . . . . 7 > 6.2.5. Property Match Filtering . . . . . . . . . . . . . . . 7 > 6.2.6. Hash-based Filtering . . . . . . . . . . . . . . . . . 8 > > 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 > > 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 > > 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 > > 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 26 > > 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 > 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 > 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 > > > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 2] > > Internet-Draft PSAMP MIB November 2010 > > > 1. Open Issues/TODOs > > o security considerations: check security issues raised by Nick > Duffield on privacy issues with hash parameters etc. I'm surprised to find open issues in WGLC. > 2. The Internet-Standard Management Framework > > For a detailed overview of the documents that describe the current > Internet-Standard Management Framework, please refer to section 7 of > RFC 3410 [RFC3410]. This format is different from the Abstract, where the title isn't given (ie, there's no duplication), eg "section 7 of [RFC3410]". > Managed objects are accessed via a virtual information store, termed > the Management Information Base or MIB. MIB objects are generally > accessed through the Simple Network Management Protocol (SNMP). > Objects in the MIB are defined using the mechanisms defined in the > Structure of Management Information (SMI). This memo specifies MIB > modules that is compliant to the SMIv2, which is described in STD 58, > RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58,RFC 2580 > [RFC2580]. Either "a MIB module which is", or "MIB modules which are". > 3. Introduction > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > This document is a product of the IP Flow Information eXport (IPFIX) > working group. Work on this document was started in the Packet > Sampling (PSAMP) Working Group (WG) and moved to the IPFIX WG when > the PSAMP WG was concluded. > > Its purpose is to define managed objects for monitoring PSAMP Devices > performing packet selection by sampling and hashing as described in > [RFC5475]. > > It is assumed that packet sampling is performed according to the > framework defined in [RFC5474]. > > Managed objects in the PSAMP MIB module are defined as an extension > of the IPFIX MIB module [RFC5815]. Since the IPFIX MIB module is for > monitoring only the same holds true for the PSAMP MIB module defined > in this document. The definition of objects is in line with the > PSAMP information model [RFC5477]. "is only for monitoring," > > Section 6 describes the structure of the PSAMP MIB module and section > 7 contains the formal definition. Security issues are discussed in > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 3] > > Internet-Draft PSAMP MIB November 2010 > > > section 8. What about sections 4 and 5? > 4. PSAMP Documents Overview > > [RFC5474]: "A Framework for Packet Selection and Reporting" describes > the PSAMP framework for network elements to select subsets of packets > by statistical and other methods, and to export a stream of reports > on the selected packets to a Collector. > > [RFC5475]: "Sampling and Filtering Techniques for IP Packet > Selection" describes the set of packet selection techniques supported > by PSAMP. > > [RFC5476]: "Packet Sampling (PSAMP) Protocol Specifications" > specifies the export of packet information from a PSAMP Exporting > Process to a PSAMP Collecting Process. > > [RFC5477]: "Information Model for Packet Sampling Exports" defines an > information and data model for PSAMP. > > This document: "Definitions of Managed Objects for Packet Sampling" > describes the PSAMP Management Information Base. > > > 5. Related IPFIX Documents > > The IPFIX protocol provides network administrators with access to IP > Flow information. The protocol document [RFC5101] specifies how > IPFIX Data Records and Templates are carried via a congestion-aware > transport protocol from IPFIX Exporting Processes to IPFIX Collecting > Processes. This document also specifies the data types used in this > MIB module and their encoding. The IPFIX MIB [RFC5815] is the basis > for this document and is extended by this MIB module. Too confusing. I think you mean: [RFC5101] also specifies the data types used in this MIB module... > > > 6. Structure of the PSAMP MIB module > > The IPFIX MIB module defined in [RFC5815] has the concept of a packet > selection process containing a set of selector function instances. > Selection processes and functions are referenced in the > ipfixSelectionProcessTable of the IPFIX MIB module. This table > identifies an instance of a selector function by an OID. The OID > points to an object that describes the selector function. For simple > selector functions without parameters, the OID refers to an object > that only contains one more object indicating the current I read this several times as "one or more objects...", which doesn't make sense. I suggest: "the OID refers to an object that contains only one additional object indicating ..." BTW I keep wanting to change "that" to "which". > availability of this function. For functions that have one or more "the". > parameters the object has a subtree that in addition to an > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 4] > > Internet-Draft PSAMP MIB November 2010 > > > availability object contains a table with a conceptual column for > each parameter. Entries (conceptual rows) in this table represent > different combinations of parameter values for instances of the > selector function. > > Object ipfixSelectorFunctions in the IPFIX SELECTOR MIB module serves > as home for objects that describe instances of packet selector "as a home" or "as the home" ? > functions. The IPFIX SELECTOR MIB is a very small module that is > also defined in [RFC5815]. Objects under ipfixSelectorFunctions are Remove "also", because it sounds like a duplicate definition (ie, defined here and also in RFC 5815). > maintained by IANA. In the IPFIX SELECTOR module object > ipfixSelectorFunctions contains just a single trivial packet selector > function called ipfixFuncSelectAll that selects every packet and has > no parameter: > > ipfixSelectorMIB > +- ipfixSelectorObjects(1) > +- ipfixSelectorFunctions(1) > +- ipfixFuncSelectAll(1) > +- ipfixFuncSelectAllAvail(1) > > The PSAMP MIB module defined in this document contains six new > objects under ipfixSelectorFunctions. Each of them describes a > packet selector function with one or more parameters. Naming and > ordering of objects is fully in line with the guidelines given in > section 6.1 of [RFC5815]. All functions and their parameters are > already listed in the overview of functions given by the figure in > section 8.2.1 of [RFC5477]. > > In addition, the PSAMP MIB module contains two textual conventions > that define data types used for parameters in the above tables that > cannot be expressed by the basic data types defined by [RFC2578], > unsigned64 and float64. Is this the right place to define these for more general use? > > 6.1. Textual Conventions > > The MIB module defines one textual conventions that defines a data Typo. > type used within this MIB module. Another data type is imported from > the APPLICATION MIB [RFC2564]. Those data types are defined > according to [RFC5101]. Those data types are not integral part of "not an integral" > [RFC2578] but are needed to define objects in this MIB module that > conform to the Information Elements defined for those objects in > [RFC5477]. > > The Unsigned64TC textual convention describes an unsigned integer of > 64 bits. It is imported from the APPLICATION MIB. > > The PsampFloat64 textuanl convention describes a double precision > floating point number. It is encoded accroding to [IEEE.754.1985]. Typo x 2. > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 5] > > Internet-Draft PSAMP MIB November 2010 > > > 6.2. Packet Selection Functions > > In general, different packet selector functions have different > parameters. The PSAMP MIB module contains six objects with subtrees > that provide information on parameters of function instances of > different selector functions. All objects are named and structured > according to section 8.2.1 of [RFC5477]: > > ipfixSelectorFunctions(1) > +-- psampSampCountBased(2) > +- -psampSampTimeBased(3) > +-- psampSampRandOutOfN(4) > +-- psampSampUniProb(5) > +-- psampFiltPropMatch(6) > +-- psampFiltHash(7) Why do you use these strange contracted names, which will surely be confusing to people whose first language isn't English? > > Indexing of these functions in the PSAMP MIB module starts with index > (2). The function ipfixFuncSelectAll with index (1) is already > defined in the IPFIX SELECTOR MIB module. As mentioned in section 6, just above. > > The object tree for each of these functions is described below. > Semantics of all functions and their parameters are described in > detail in [RFC5475]. More information on the Selector Reports can > also be found in section 6.5.2 of [RFC5476]. > > 6.2.1. Systematic Count-based Sampling > > The first selector function is systematic count-based sampling. Its > availability is indicated by object psampSampCountBasedAvail. The > function has two parameters: psampSampCountBasedInterval and > psampSampCountBasedSpace. Different combination of values of these > parameters for different instances of the selector function are > represented by different conceptual rows in table > psampSampCountBasedParamSetEntry: > > psampSampCountBased(2) > +-- psampSampCountBasedAvail(1) > +-- psampSampCountBasedParamSetTable(2) > +-- psampSampCountBasedParamSetEntry(1) [psampSampCountBasedIndex] > +-- psampSampCountBasedIndex(1) > +-- psampSampCountBasedInterval(2) > +-- psampSampCountBasedSpace(3) > > 6.2.2. Systematic Time-based Sampling > > The second selector function is systematic time-based sampling. The > structure of the sub-tree for this function is similar to the > previous one. Parameters are psampSampTimeBasedInterval and Be specific: say "to the psampSampCountBased sub-tree". > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 6] > > Internet-Draft PSAMP MIB November 2010 > > > psampSampTimeBasedSpace. They appear to be the same as for count > based sampling, but their data types are different because they > indicate time values instead of numbers of packets: > > psampSampTimeBased(3) > +-- psampSampTimeBasedAvail(1) > +-- psampSampTimeBasedParamSetTable(2) > +-- psampSampTimeBasedParamSetEntry(1) [psampSampTimeBasedIndex] > +-- psampSampTimeBasedIndex(1) > +-- psampSampTimeBasedInterval(2) > +-- psampSampTimeBasedSpace(3) > > 6.2.3. Random n-out-of-N Sampling > > The third selector function is random n-out-of-N sampling. The > structure of the sub-tree for this function is similar to the > previous one. Parameters are psampSampRandOutOfNSamplingSize and So it's similar to both of the previous ones. > psampSampRandOutOfNPopulation: > > psampSampRandOutOfN(4) > +-- psampSampRandOutOfNAvail(1) > +-- psampSampRandOutOfNParamSetTable(3) Why is this (3) rather than (2) ? > +-- psampSampRandOutOfNParamSetEntry(1) [psampSampRandOutOfNIndex] > +-- psampSampRandOutOfNIndex(1) > +-- psampSampRandOutOfNSamplingSize(2) > +-- psampSampRandOutOfNPopulation(3) > > 6.2.4. Uniform Probabilistic Sampling > > The fourth selector function is uniform probabilistic sampling. It > has just a single parameter called psampSampUniProbProbability: > > psampSampUniProb(5) > +-- psampSampUniProbAvail(1) > +-- psampSampUniProbParamSetTable(3) Why is this (3) rather than (2) ? > +-- psampSampUniProbParamSetEntry(1) [psampSampUniProbIndex] > +-- psampSampUniProbIndex(1) > +-- psampSampUniProbProbability(2) > > 6.2.5. Property Match Filtering > > The fifth selector function is property match filtering. For this > selector function there is a broad variety of possible parameters > that could be used. But as stated in section 8.2.1 of [RFC5477] > there are no agreed parameters specified and the sub-tree for this > function only contains an object indicating the availability of this > function. Paameters cannot be retireved via the PSAMP MIB module: Typo x 2. > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 7] > > Internet-Draft PSAMP MIB November 2010 > > > psampFiltPropMatch(6) > +-- psampFiltPropMatchAvail(1) > > 6.2.6. Hash-based Filtering > > The sixth selector function is hash-based filtering. This function > has more parameters and the actual number may vary with the choice of > the hash function applied. The common parameter set for all hash- > based filtering functions contains 7 parameters: > psampFiltHashInitializerValue, psampFiltHashIpPayloadOffset, > psampFiltHashIpPayloadSize, psampFiltHashSelectedRangeMin, > psampFiltHashSelectedRangeMax, psampFiltHashOutputRangeMin, and > psampFiltHashOutputRangeMax. psampFiltHashFunction isn't mentioned? > > psampFiltHash(7) > +-- psampFiltHashAvail(1) > +-- psampFiltHashCapabilities(2) > +-- psampFiltHashParamSetTable(3) > +-- psampFiltHashParamSetEntry(1) [psampFiltHashIndex] > +-- psampFiltHashIndex(1) > +-- psampFiltHashFunction(2) > +-- psampFiltHashInitializerValue(3) > +-- psampFiltHashIpPayloadOffset(4) > +-- psampFiltHashIpPayloadSize(5) > +-- psampFiltHashSelectedRangeMin(6) > +-- psampFiltHashSelectedRangeMax(7) > +-- psampFiltHashOutputRangeMin(8) > +-- psampFiltHashOutputRangeMax(9) > > Further parameters depend on the applied hash function and are not > specified within the PSAMP MIB module. > > > 7. Definitions > > Have you compiled this MIB? > PSAMP-MIB DEFINITIONS ::= BEGIN > > IMPORTS > MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, mib-2 > FROM SNMPv2-SMI -- RFC2578 > TEXTUAL-CONVENTION, TruthValue > FROM SNMPv2-TC -- RFC2579 > MODULE-COMPLIANCE, OBJECT-GROUP > FROM SNMPv2-CONF -- RFC2580 > Unsigned64TC > FROM APPLICATION-MIB -- RFC2564 > ipfixSelectorFunctions > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 8] > > Internet-Draft PSAMP MIB November 2010 > > > FROM IPFIX-SELECTOR-MIB; > > psampMIB MODULE-IDENTITY > LAST-UPDATED "201011081200Z" -- 08 November 2010 > ORGANIZATION "IETF IPFIX Working Group" > CONTACT-INFO > "WG charter: > http://www.ietf.org/html.charters/ipfix-charter.html > > Mailing Lists: > General Discussion: ipfix@ietf.org > To Subscribe: http://www1.ietf.org/mailman/listinfo/ipfix > Archive: > http://www1.ietf.org/mail-archive/web/ipfix/current/index.html > > Editor: > Thomas Dietz > NEC Europe Ltd. > NEC Laboratories Europe > Network Research Division > Kurfuersten-Anlage 36 > 69115 Heidelberg > Germany > Phone: +49 6221 4342-128 > Email: Thomas.Dietz@nw.neclab.eu > > Benoit Claise > Cisco Systems, Inc. > De Kleetlaan 6a b1 > Degem 1831 > Belgium > Phone: +32 2 704 5622 > Email: bclaise@cisco.com > > Juergen Quittek > NEC Europe Ltd. > NEC Laboratories Europe > Network Research Division > Kurfuersten-Anlage 36 > 69115 Heidelberg > Germany > Phone: +49 6221 4342-115 > Email: quittek@nw.neclab.eu" > DESCRIPTION > "The PSAMP MIB defines managed objects for packet sampling > and filtering. > These objects provide information about managed nodes > supporting packet sampling, including packet sampling > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 9] > > Internet-Draft PSAMP MIB November 2010 > > > capabilities, configuration and statistics. > > Copyright (c) 2010 IETF Trust and the persons identified as > the document authors. All rights reserved. This version > of this MIB module is part of RFC yyyy; see the RFC itself > for full legal notices" > -- RFC Ed.: replace yyyy with actual RFC number & remove this notice Being buried in the MIB, it's possible, even likely, that this will be overlooked. > > -- Revision history > > REVISION "201011081200Z" -- 08 November 2010 > DESCRIPTION > "Initial version, published as RFC yyyy." > -- RFC Ed.: replace yyyy with actual RFC number & remove this notice > > ::= { mib-2 xxx } > -- xxx to be assigned by IANA. This isn't mentioned in the IANA section. > > PsampFloat64 ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "Represents the float64 data type and MUST be encoded as > an IEEE double-precision 64-bit floating point-type, as > specified in IEEE 754." > SYNTAX OCTET STRING (SIZE (8)) > > -- Top level structure of the MIB > > psampObjects OBJECT IDENTIFIER ::= { psampMIB 1 } > psampConformance OBJECT IDENTIFIER ::= { psampMIB 2 } > > > --================================================================== > -- Packet selection sampling methods group of objects > --================================================================== > > --================================================================== > --* Method 1: Systematic count-based Sampling > --================================================================== > > -- Reference: RFC5475, Section 5.1, RFC5476 Section 6.5.2.1 and > -- RFC5477, Section 8.2 > psampSampCountBased OBJECT IDENTIFIER > ::= { ipfixSelectorFunctions 2 } > > psampSampCountBasedAvail OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 10] > > Internet-Draft PSAMP MIB November 2010 > > > STATUS current > DESCRIPTION > "This object indicates the availability of systematic > count-based sampling at the managed node. > > A Selector may be unavailable if it is implemented but > currently disabled due to e.g., administrative reasons, lack > of resources or similar." > DEFVAL { false } > ::= { psampSampCountBased 1 } > > -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ > > psampSampCountBasedParamSetTable OBJECT-TYPE > SYNTAX SEQUENCE OF > PsampSampCountBasedParamSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table lists configurations of systematic count-based > packet sampling. A parameter set describing a > configuration contains two parameters: the sampling > interval length and the space." Either say "and the sampling interval space", or say "the sampling interval length and space." > ::= { psampSampCountBased 2 } > > psampSampCountBasedParamSetEntry OBJECT-TYPE > SYNTAX PsampSampCountBasedParamSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Defines an entry in the psampSampCountBasedParamSetTable." > INDEX { psampSampCountBasedIndex } > ::= { psampSampCountBasedParamSetTable 1 } > > PsampSampCountBasedParamSetEntry ::= > SEQUENCE { > psampSampCountBasedIndex Integer32, > psampSampCountBasedInterval Unsigned32, > psampSampCountBasedSpace Unsigned32 > } > > psampSampCountBasedIndex OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The index of this parameter set in the > psampSampCountBasedParamSetTable.It is used in the Spacing. > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 11] > > Internet-Draft PSAMP MIB November 2010 > > > object ipfixSelectionProcessSelectorFunctionentries of > the ipfixSelectionProcessTable in the IPFIX-MIB as reference > to this parameter set." > ::= { psampSampCountBasedParamSetEntry 1 } > > psampSampCountBasedInterval OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "packets" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object specifies the number of packets that are > consecutively sampled. A value of 100 means that 100 > consecutive packets are sampled." > REFERENCE > "RFC5475, Section 5.1 and RFC5477, Section 8.2" > ::= { psampSampCountBasedParamSetEntry 2 } > > psampSampCountBasedSpace OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "packets" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object specifies the number of packets between two > psampSampCountBasedInterval's. A value of 100 means that > the next interval starts 100 packets (which are not sampled) > after the current psampSampCountBasedInterval is over." > REFERENCE > "RFC5475, Section 5.1 and RFC5477, Section 8.2" > ::= { psampSampCountBasedParamSetEntry 3 } > > --================================================================== > --* Method 2: Systematic time-based Sampling > --================================================================== > > -- Reference: RFC5475, Section 5.1, RFC5476 Section 6.5.2.2 and > -- RFC5477, Section 8.2 > psampSampTimeBased OBJECT IDENTIFIER > ::= { ipfixSelectorFunctions 3 } > > psampSampTimeBasedAvail OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object indicates the availability of systematic > time-based sampling at the managed node. > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 12] > > Internet-Draft PSAMP MIB November 2010 > > > A Selector may be unavailable if it is implemented but > currently disabled due to e.g., administrative reasons, lack > of resources or similar." > DEFVAL { false } > ::= { psampSampTimeBased 1 } > > -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ > > psampSampTimeBasedParamSetTable OBJECT-TYPE > SYNTAX SEQUENCE OF > PsampSampTimeBasedParamSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table lists configurations of systematic time-based > packet sampling. A parameter set describing a configuration > contains two parameters: the sampling interval length and > the space." > ::= { psampSampTimeBased 2 } > > psampSampTimeBasedParamSetEntry OBJECT-TYPE > SYNTAX PsampSampTimeBasedParamSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Defines an entry in the psampSampTimeBasedParamSetTable." > INDEX { psampSampTimeBasedIndex } > ::= { psampSampTimeBasedParamSetTable 1 } > > PsampSampTimeBasedParamSetEntry ::= > SEQUENCE { > psampSampTimeBasedIndex Integer32, > psampSampTimeBasedInterval Unsigned32, > psampSampTimeBasedSpace Unsigned32 > } > > psampSampTimeBasedIndex OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The index of this parameter set in the > psampSampTimeBasedParamSetTable. It is used in the > object ipfixSelectionProcessSelectorFunctionentries of > the ipfixSelectionProcessTable in the IPFIX-MIB as reference > to this parameter set." > ::= { psampSampTimeBasedParamSetEntry 1 } > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 13] > > Internet-Draft PSAMP MIB November 2010 > > > psampSampTimeBasedInterval OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "microseconds" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object specifies the time interval in microseconds > during which all arriving packets are sampled." This description's indentation is slightly different. > REFERENCE > "RFC5475, Section 5.1 and RFC5477, Section 8.2" > ::= { psampSampTimeBasedParamSetEntry 2 } > > psampSampTimeBasedSpace OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "microseconds" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object specifies the time interval in microseconds > between two psampSampTimeBasedInterval's. A value of 100 > means that the next interval starts 100 microseconds (during > which no packets are sampled) after the current > psampSampTimeBasedInterval is over." > REFERENCE > "RFC5475, Section 5.1 and RFC5477, Section 8.2" > ::= { psampSampTimeBasedParamSetEntry 3 } > > --================================================================== > --* Method 3: Random n-out-of-N Sampling > --================================================================== > > -- Reference: RFC5475, Section 5.2.1, RFC5476 Section 6.5.2.3 and > -- RFC5477, Section 8.2 > psampSampRandOutOfN OBJECT IDENTIFIER > ::= { ipfixSelectorFunctions 4 } > > psampSampRandOutOfNAvail OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object indicates the availability of random n-out-of-N > sampling at the managed node. > > A Selector may be unavailable if it is implemented but > currently disabled due to e.g., administrative reasons, lack > of resources or similar." > DEFVAL { false } > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 14] > > Internet-Draft PSAMP MIB November 2010 > > > ::= { psampSampRandOutOfN 1 } > > -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ > > psampSampRandOutOfNParamSetTable OBJECT-TYPE > SYNTAX SEQUENCE OF > PsampSampRandOutOfNParamSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table lists configurations of random n-out-of-N > sampling. A parameter set describing a configuration > contains a two parameter only, the sampling size and the > parent population." > ::= { psampSampRandOutOfN 3 } > > psampSampRandOutOfNParamSetEntry OBJECT-TYPE > SYNTAX PsampSampRandOutOfNParamSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Defines an entry in the psampSampRandOutOfNParamSetTable." > INDEX { psampSampRandOutOfNIndex } > ::= { psampSampRandOutOfNParamSetTable 1 } > > PsampSampRandOutOfNParamSetEntry ::= > SEQUENCE { > psampSampRandOutOfNIndex Integer32, > psampSampRandOutOfNSamplingSize Unsigned32, > psampSampRandOutOfNPopulation Unsigned32 > } > > psampSampRandOutOfNIndex OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The index of this parameter set in the > psampSampRandOutOfNParamSetTable. It is used in the > object ipfixSelectionProcessSelectorFunctionentries of > the ipfixSelectionProcessTable in the IPFIX-MIB as reference > to this parameter set." > ::= { psampSampRandOutOfNParamSetEntry 1 } > > psampSampRandOutOfNSamplingSize OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "packets" > MAX-ACCESS read-only > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 15] > > Internet-Draft PSAMP MIB November 2010 > > > STATUS current > DESCRIPTION > "This object specifies the number of elements taken from the > parent Population for specified in Remove "for". > psampSampRandOutOfNPopulation." > REFERENCE > "RFC5475, Section 5.2.1 and RFC5477, Section 8.2" > ::= { psampSampRandOutOfNParamSetEntry 2 } > > psampSampRandOutOfNPopulation OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "packets" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object specifies the number of elements in the parent > Population." This description's indentation is slightly different. > REFERENCE > "RFC5475, Section 5.2.1 and RFC5477, Section 8.2" > ::= { psampSampRandOutOfNParamSetEntry 3 } > > --================================================================== > --* Method 4: Uniform probabilistic Sampling > --================================================================== > > -- Reference: RFC5475, Section 5.2.2, RFC5476 Section 6.5.2.4 and > -- RFC5477, Section 8.2 > psampSampUniProb OBJECT IDENTIFIER ::= { ipfixSelectorFunctions 5 } > > psampSampUniProbAvail OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object indicates the availability of random uniform > probabilistic sampling at the managed node. > > A Selector may be unavailable if it is implemented but > currently disabled due to e.g., administrative reasons, lack > of resources or similar." > DEFVAL { false } > ::= { psampSampUniProb 1 } > > -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ > > -- Reference: RFC5475, Section 5.2.2.1 and RFC5477, Section 8.2 > psampSampUniProbParamSetTable OBJECT-TYPE > SYNTAX SEQUENCE OF > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 16] > > Internet-Draft PSAMP MIB November 2010 > > > PsampSampUniProbParamSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table lists configurations of random probabilistic > sampling. A parameter set describing a configuration > contains a single parameter only: the sampling probability." > ::= { psampSampUniProb 3 } > > psampSampUniProbParamSetEntry OBJECT-TYPE > SYNTAX PsampSampUniProbParamSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Defines an entry in the psampSampUniProbParamSetTable." > INDEX { psampSampUniProbIndex } > ::= { psampSampUniProbParamSetTable 1 } > > PsampSampUniProbParamSetEntry ::= > SEQUENCE { > psampSampUniProbIndex Integer32, > psampSampUniProbProbability PsampFloat64 > } > > psampSampUniProbIndex OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The index of this parameter set in the The indentation of the first line of this description is slightly different. > psampSampUniProbParamSetTable. It is used in the > object ipfixSelectionProcessSelectorFunctionentries of > the ipfixSelectionProcessTable in the IPFIX-MIB as reference > to this parameter set." > ::= { psampSampUniProbParamSetEntry 1 } > > psampSampUniProbProbability OBJECT-TYPE > SYNTAX PsampFloat64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object specifies the probability that a packet is > sampled, expressed as a value between 0 and 1. The > probability is equal for every packet. A value of 0 means > no packet was sampled since the probability is 0. A value > of 1 means all packets were sampled since the > probability is 1." > REFERENCE > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 17] > > Internet-Draft PSAMP MIB November 2010 > > > "RFC5475, Section 5.2.2.1 and RFC5477, Section 8.2" > ::= { psampSampUniProbParamSetEntry 2 } > > --================================================================== > -- Packet selection filtering methods group of objects > --================================================================== > > --================================================================== > --* Method 5: Property Match filtering > --================================================================== > > -- Reserves Method 5 (see RFC5475, Section 6.1, RFC5476 > -- Section 6.5.2.5 and RFC5477) > psampFiltPropMatch OBJECT IDENTIFIER > ::= { ipfixSelectorFunctions 6 } > > psampFiltPropMatchAvail OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object indicates the availability of property match > filtering at the managed node. > > A Selector may be unavailable if it is implemented but > currently disabled due to e.g., administrative reasons, lack > of resources or similar." > DEFVAL { false } > ::= { psampFiltPropMatch 1 } > > --================================================================== > --* Method 1: Hash filtering Typo: it's method 6. > --================================================================== > > -- Reference: RFC5475, Section 6.2, RFC5476 Section 6.5.2.6 and > -- RFC5477, Section 8.3 > psampFiltHash OBJECT IDENTIFIER ::= { ipfixSelectorFunctions 7 } > > psampFiltHashAvail OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object indicates the availability of hash filtering > at the managed node. > > A Selector may be unavailable if it is implemented but > currently disabled due to e.g., administrative reasons, lack > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 18] > > Internet-Draft PSAMP MIB November 2010 > > > of resources or similar." > DEFVAL { false } > ::= { psampFiltHash 1 } > > psampFiltHashCapabilities OBJECT IDENTIFIER > ::= { psampFiltHash 2 } > > -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ > > -- Reference: RFC5475, Sections 6.2, 3.8, and 7.1 > psampFiltHashParamSetTable OBJECT-TYPE > SYNTAX SEQUENCE OF > PsampFiltHashParamSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table lists configurations of hash filtering. A > parameter set describing a configuration contains eight > parameter describing the hash function." > ::= { psampFiltHash 3 } > > psampFiltHashParamSetEntry OBJECT-TYPE > SYNTAX PsampFiltHashParamSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Defines an entry in the psampFiltHashParamSetTable." > INDEX { psampFiltHashIndex } > ::= { psampFiltHashParamSetTable 1 } > > PsampFiltHashParamSetEntry ::= > SEQUENCE { > psampFiltHashIndex Integer32, > psampFiltHashFunction INTEGER, > psampFiltHashInitializerValue Unsigned64TC, > psampFiltHashIpPayloadOffset Unsigned64TC, > psampFiltHashIpPayloadSize Unsigned64TC, > psampFiltHashSelectedRangeMin Unsigned64TC, > psampFiltHashSelectedRangeMax Unsigned64TC, > psampFiltHashOutputRangeMin Unsigned64TC, > psampFiltHashOutputRangeMax Unsigned64TC > } > > psampFiltHashIndex OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 19] > > Internet-Draft PSAMP MIB November 2010 > > > "The index of this parameter set in the > psampFiltHashParamSetTable. It is used in the > object ipfixSelectionProcessSelectorFunctionentries of > the ipfixSelectionProcessTable in the IPFIX-MIB as reference > to this parameter set." > ::= { psampFiltHashParamSetEntry 1 } > > psampFiltHashFunction OBJECT-TYPE > SYNTAX INTEGER { > crc32(1), > ipsx(2), > bob(3) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The Hash Function used by this filter. The PSAMP-MIB > supports the following Hash Functions: > > crc32(1) > > ipsx(2) > > bob(3) > " > ::= { psampFiltHashParamSetEntry 2 } > > psampFiltHashInitializerValue OBJECT-TYPE > SYNTAX Unsigned64TC > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object specifies the initializer value to the hash > function." > REFERENCE > "RFC5475, Sections 6.2, 3.8, and 7.1" > ::= { psampFiltHashParamSetEntry 3 } > > psampFiltHashIpPayloadOffset OBJECT-TYPE > SYNTAX Unsigned64TC > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object specifies the IP payload offset used by a > Hash-based Selection Selector." > REFERENCE > "RFC5475, Sections 6.2, 3.8, and 7.1" > ::= { psampFiltHashParamSetEntry 4 } > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 20] > > Internet-Draft PSAMP MIB November 2010 > > > psampFiltHashIpPayloadSize OBJECT-TYPE > SYNTAX Unsigned64TC > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object specifies the IP payload size used by a > Hash-based Selection Selector." > REFERENCE > "RFC5475, Sections 6.2, 3.8, and 7.1" > ::= { psampFiltHashParamSetEntry 5 } > > psampFiltHashSelectedRangeMin OBJECT-TYPE > SYNTAX Unsigned64TC > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object specifies the value for the beginning of a hash > function's selected range." > REFERENCE > "RFC5475, Sections 6.2, 3.8, and 7.1" > ::= { psampFiltHashParamSetEntry 6 } > > psampFiltHashSelectedRangeMax OBJECT-TYPE > SYNTAX Unsigned64TC > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object specifies the value for the end of a hash > function's selected range." > REFERENCE > "RFC5475, Sections 6.2, 3.8, and 7.1" > ::= { psampFiltHashParamSetEntry 7 } > > psampFiltHashOutputRangeMin OBJECT-TYPE > SYNTAX Unsigned64TC > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object specifies the value for the beginning of a hash > function's potential output range." > REFERENCE > "RFC5475, Sections 6.2, 3.8, and 7.1" > ::= { psampFiltHashParamSetEntry 8 } > > psampFiltHashOutputRangeMax OBJECT-TYPE > SYNTAX Unsigned64TC > MAX-ACCESS read-only > STATUS current > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 21] > > Internet-Draft PSAMP MIB November 2010 > > > DESCRIPTION > "This object specifies the value for the end of a hash > function's potential output range." > REFERENCE > "RFC5475, Sections 6.2, 3.8, and 7.1" > ::= { psampFiltHashParamSetEntry 9 } > > --================================================================== > -- Conformance information > --================================================================== > > psampCompliances OBJECT IDENTIFIER ::= { psampConformance 1 } > psampGroups OBJECT IDENTIFIER ::= { psampConformance 2 } > > --================================================================== > -- Compliance statements > --================================================================== > > psampCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The implementation of all objects is optional and depends > on the implementation of the corresponding functionality in > the equipment." > MODULE -- this module > GROUP psampGroupSampCountBased > DESCRIPTION > "These objects must be implemented if the corresponding > sampling function is implemented in the equipment." > GROUP psampGroupSampTimeBased > DESCRIPTION > "These objects must be implemented if the corresponding > sampling function is implemented in the equipment." > GROUP psampGroupSampRandOutOfN > DESCRIPTION > "These objects must be implemented if the corresponding > sampling function is implemented in the equipment." > GROUP psampGroupSampUniProb > DESCRIPTION > "These objects must be implemented if the corresponding > sampling function is implemented in the equipment." > GROUP psampGroupFiltPropMatch > DESCRIPTION > "These objects must be implemented if the corresponding > filter function is implemented in the equipment." > GROUP psampGroupFiltHash > DESCRIPTION > "These objects must be implemented if the corresponding > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 22] > > Internet-Draft PSAMP MIB November 2010 > > > filter function is implemented in the equipment." > ::= { psampCompliances 1 } > > --================================================================== > -- MIB groupings > --================================================================== > The indentation of all the descriptions below is slightly different from the previous descriptions above. > psampGroupSampCountBased OBJECT-GROUP > OBJECTS { > psampSampCountBasedAvail, > psampSampCountBasedInterval, > psampSampCountBasedSpace > } > STATUS current > DESCRIPTION > "These objects are needed if count based sampling is > implemented." > ::= { psampGroups 2 } > > psampGroupSampTimeBased OBJECT-GROUP > OBJECTS { > psampSampTimeBasedAvail, > psampSampTimeBasedInterval, > psampSampTimeBasedSpace > } > STATUS current > DESCRIPTION > "These objects are needed if time based sampling is > implemented." > ::= { psampGroups 3 } > > psampGroupSampRandOutOfN OBJECT-GROUP > OBJECTS { > psampSampRandOutOfNAvail, > psampSampRandOutOfNSamplingSize, > psampSampRandOutOfNPopulation > } > STATUS current > DESCRIPTION > "These objects are needed if random n-out-of-N sampling is > implemented." > ::= { psampGroups 4 } > > psampGroupSampUniProb OBJECT-GROUP > OBJECTS { > psampSampUniProbAvail, > psampSampUniProbProbability > } > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 23] > > Internet-Draft PSAMP MIB November 2010 > > > STATUS current > DESCRIPTION > "These objects are needed if uniform probabilistic sampling > is implemented." > ::= { psampGroups 5 } > > psampGroupFiltPropMatch OBJECT-GROUP > OBJECTS { > psampFiltPropMatchAvail > } > STATUS current > DESCRIPTION > "These objects are needed if property match filtering is > implemented." > ::= { psampGroups 6 } > > psampGroupFiltHash OBJECT-GROUP > OBJECTS { > psampFiltHashAvail, > psampFiltHashFunction, > psampFiltHashInitializerValue, > psampFiltHashIpPayloadOffset, > psampFiltHashIpPayloadSize, > psampFiltHashSelectedRangeMin, > psampFiltHashSelectedRangeMax, > psampFiltHashOutputRangeMin, > psampFiltHashOutputRangeMax > } > STATUS current > DESCRIPTION > "These objects are needed if hash filtering is implemented." > ::= { psampGroups 9 } "psampGroups 7". > > END > > > 8. Security Considerations > > There are no management objects defined in this MIB module that have > a MAX-ACCESS clause of read-write and/or read-create. So, if this > MIB module is implemented correctly, then there is no risk that an > intruder can alter or create any management objects of this MIB > module via direct SNMP SET operations. > > Some of the readable objects in this MIB module (i.e., objects with a See below. > MAX-ACCESS other than not-accessible) may be considered sensitive or > vulnerable in some network environments. It is thus important to > control even GET and/or NOTIFY access to these objects and possibly > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 24] > > Internet-Draft PSAMP MIB November 2010 > > > to even encrypt the values of these objects when sending them over > the network via SNMP. These are the tables and objects and their > sensitivity/vulnerability: > > o All tables - they contain configuration data that might be > sensitive because objects in this table may reveal information > about the network infrastructure and device configuration From "Some of" to here, why not just say: All tables in this MIB module may be considered sensitive or vulnerable in some network environments because objects in the tables may reveal information about the network infrastructure and device configuration. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. > > SNMP versions prior to SNMPv3 did not include adequate security. > Even if the network itself is secure (for example by using IPsec), > there is no control as to who on the secure network is allowed to > access and GET/SET (read/change/create/delete) the objects in this > MIB module. > > It is RECOMMENDED that implementers consider the security features as Remove "as". > provided by the SNMPv3 framework (see [RFC3410], section 8), > including full support for the SNMPv3 cryptographic mechanisms (for > authentication and privacy). > > Further, deployment of SNMP versions prior to SNMPv3 is NOT > RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to > enable cryptographic security. It is then a customer/operator > responsibility to ensure that the SNMP entity giving access to an > instance of this MIB module is properly configured to give access to > the objects only to those principals (users) that have legitimate Users are people, so use "who". > rights to indeed GET or SET (change/create/delete) them. Remove "indeed". > 9. IANA Considerations > > The MIB module in this document uses the following IANA-assigned > OBJECT IDENTIFIER values recorded in the SMI Numbers registry: > > Descriptor OBJECT IDENTIFIER value > ---------- ----------------------- > psampMIB { mib-2 xxx } Clearly specify that xxx must be assigned by IANA and also written into the MIB in section 7. Thanks, P. > psampSampCountBased { ipfixSelectorFunctions 2 } > psampSampTimeBased { ipfixSelectorFunctions 3 } > psampSampRandOutOfN { ipfixSelectorFunctions 4 } > psampSampUniProb { ipfixSelectorFunctions 5 } > psampFiltPropMatch { ipfixSelectorFunctions 6 } > psampFiltHash { ipfixSelectorFunctions 7 } > > Other than that this document does not impose any IANA > considerations. > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 25] > > Internet-Draft PSAMP MIB November 2010 > > > 10. Acknowledgment > > This document is a product of the PSAMP and IPFIX working groups. > > > 11. References > > 11.1. Normative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. > Schoenwaelder, Ed., "Structure of Management Information > Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. > > [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. > Schoenwaelder, Ed., "Textual Conventions for SMIv2", > STD 58, RFC 2579, April 1999. > > [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, > "Conformance Statements for SMIv2", STD 58, RFC 2580, > April 1999. > > [RFC2564] Kalbfleisch, C., Krupczak, C., Presuhn, R., and J. > Saperia, "Application Management MIB", RFC 2564, May 1999. > > [RFC5101] Claise, B., "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic > Flow Information", RFC 5101, January 2008. > > [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. > Carle, "Information Model for Packet Sampling Exports", > RFC 5477, March 2009. > > [RFC5815] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, > "Definitions of Managed Objects for IP Flow Information > Export", RFC 5815, April 2010. > > [IEEE.754.1985] > Institute of Electrical and Electronics Engineers, > "Standard for Binary Floating-Point Arithmetic", > IEEE Standard 754, August 1985. > > 11.2. Informative References > > [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, > "Introduction and Applicability Statements for Internet- > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 26] > > Internet-Draft PSAMP MIB November 2010 > > > Standard Management Framework", RFC 3410, December 2002. > > [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., > Grossglauser, M., and J. Rexford, "A Framework for Packet > Selection and Reporting", RFC 5474, March 2009. > > [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. > Raspall, "Sampling and Filtering Techniques for IP Packet > Selection", RFC 5475, March 2009. > > [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling > (PSAMP) Protocol Specifications", RFC 5476, March 2009. > > > Authors' Addresses > > Thomas Dietz (editor) > NEC Europe Ltd. > NEC Laboratories Europe > Kurfuersten-Anlage 36 > Heidelberg 69115 > DE > > Phone: +49 6221 4342-128 > Email: dietz@neclab.eu > > > Benoit Claise > Cisco Systems, Inc. > De Kleetlaan 6a b1 > Degem 1831 > BE > > Phone: +32 2 704 5622 > Email: bclaise@cisco.com > > > Juergen Quittek > NEC Europe Ltd. > NEC Laboratories Europe > Kurfuersten-Anlage 36 > Heidelberg 69115 > DE > > Phone: +49 6221 4342-115 > Email: quittek@neclab.eu > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 27] > > --------------040504030300000000040707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,


> This is the working group last call on draft-ietf-ipfix-psamp-mib-02.

This draft requires additional editorial work.

Please find comments inline below.

Thanks,
P.


> Network Working Group                                      T. Dietz, Ed.
> Internet-Draft                                           NEC Europe Ltd.
> Intended status: Standards Track                               B. Claise
> Expires: May 12, 2011                                Cisco Systems, Inc.
>                                                               J. Quittek
>                                                          NEC Europe Ltd.
>                                                         November 8, 2010
>
>
>            Definitions of Managed Objects for Packet Sampling
>                   <draft-ietf-ipfix-psamp-mib-02.txt>
>
> Abstract
>
>    This memo defines a portion of the Management Information Base (MIB)
>    for use with network management protocols in the Internet community.
>    In particular, it describes extensions to the IPFIX MIB module
>    [RFC5815].  For IPFIX implementations that use packet sampling
>    (PSAMP) techniques as described in [RFC5475], this memo defines the
>    PSAMP MIB module containing managed objects for providing information
>    on applied packet selection functions and their parameters.
>
> Status of this Memo
>
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    This Internet-Draft will expire on May 12, 2011.
>
> Copyright Notice
>
>    Copyright (c) 2010 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt           [Page 1]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>    carefully, as they describe your rights and restrictions with respect
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
>
>
> Table of Contents
>
>    1.  Open Issues/TODOs  . . . . . . . . . . . . . . . . . . . . . .  3
>
>    2.  The Internet-Standard Management Framework . . . . . . . . . .  3
>
>    3.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
>
>    4.  PSAMP Documents Overview . . . . . . . . . . . . . . . . . . .  4
>
>    5.  Related IPFIX Documents  . . . . . . . . . . . . . . . . . . .  4
>
>    6.  Structure of the PSAMP MIB module  . . . . . . . . . . . . . .  4
>      6.1.  Textual Conventions  . . . . . . . . . . . . . . . . . . .  5
>      6.2.  Packet Selection Functions . . . . . . . . . . . . . . . .  6
>        6.2.1.  Systematic Count-based Sampling  . . . . . . . . . . .  6
>        6.2.2.  Systematic Time-based Sampling . . . . . . . . . . . .  6
>        6.2.3.  Random n-out-of-N Sampling . . . . . . . . . . . . . .  7
>        6.2.4.  Uniform Probabilistic Sampling . . . . . . . . . . . .  7
>        6.2.5.  Property Match Filtering . . . . . . . . . . . . . . .  7
>        6.2.6.  Hash-based Filtering . . . . . . . . . . . . . . . . .  8
>
>    7.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  8
>
>    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
>
>    9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
>
>    10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 26
>
>    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
>      11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
>      11.2. Informative References . . . . . . . . . . . . . . . . . . 26
>
>    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
>
>
>
>
>
>
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt           [Page 2]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
> 1.  Open Issues/TODOs
>
>    o  security considerations: check security issues raised by Nick
>       Duffield on privacy issues with hash parameters etc.

I'm surprised to find open issues in WGLC.


> 2.  The Internet-Standard Management Framework
>
>    For a detailed overview of the documents that describe the current
>    Internet-Standard Management Framework, please refer to section 7 of
>    RFC 3410 [RFC3410].

This format is different from the Abstract, where the title isn't given (ie, there's no duplication), eg "section 7 of [RFC3410]".


>    Managed objects are accessed via a virtual information store, termed
>    the Management Information Base or MIB.  MIB objects are generally
>    accessed through the Simple Network Management Protocol (SNMP).
>    Objects in the MIB are defined using the mechanisms defined in the
>    Structure of Management Information (SMI).  This memo specifies MIB
>    modules that is compliant to the SMIv2, which is described in STD 58,
>    RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58,RFC 2580
>    [RFC2580].

Either "a MIB module which is", or "MIB modules which are".


> 3.  Introduction
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in RFC 2119 [RFC2119].
>
>    This document is a product of the IP Flow Information eXport (IPFIX)
>    working group.  Work on this document was started in the Packet
>    Sampling (PSAMP) Working Group (WG) and moved to the IPFIX WG when
>    the PSAMP WG was concluded.
>
>    Its purpose is to define managed objects for monitoring PSAMP Devices
>    performing packet selection by sampling and hashing as described in
>    [RFC5475].
>
>    It is assumed that packet sampling is performed according to the
>    framework defined in [RFC5474].
>
>    Managed objects in the PSAMP MIB module are defined as an extension
>    of the IPFIX MIB module [RFC5815].  Since the IPFIX MIB module is for
>    monitoring only the same holds true for the PSAMP MIB module defined
>    in this document.  The definition of objects is in line with the
>    PSAMP information model [RFC5477].

"is only for monitoring,"


>
>    Section 6 describes the structure of the PSAMP MIB module and section
>    7 contains the formal definition.  Security issues are discussed in
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt           [Page 3]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>    section 8.

What about sections 4 and 5?


> 4.  PSAMP Documents Overview
>
>    [RFC5474]: "A Framework for Packet Selection and Reporting" describes
>    the PSAMP framework for network elements to select subsets of packets
>    by statistical and other methods, and to export a stream of reports
>    on the selected packets to a Collector.
>
>    [RFC5475]: "Sampling and Filtering Techniques for IP Packet
>    Selection" describes the set of packet selection techniques supported
>    by PSAMP.
>
>    [RFC5476]: "Packet Sampling (PSAMP) Protocol Specifications"
>    specifies the export of packet information from a PSAMP Exporting
>    Process to a PSAMP Collecting Process.
>
>    [RFC5477]: "Information Model for Packet Sampling Exports" defines an
>    information and data model for PSAMP.
>
>    This document: "Definitions of Managed Objects for Packet Sampling"
>    describes the PSAMP Management Information Base.
>
>
> 5.  Related IPFIX Documents
>
>    The IPFIX protocol provides network administrators with access to IP
>    Flow information.  The protocol document [RFC5101] specifies how
>    IPFIX Data Records and Templates are carried via a congestion-aware
>    transport protocol from IPFIX Exporting Processes to IPFIX Collecting
>    Processes.  This document also specifies the data types used in this
>    MIB module and their encoding.  The IPFIX MIB [RFC5815] is the basis
>    for this document and is extended by this MIB module.

Too confusing. I think you mean:

  [RFC5101] also specifies the data types used in this MIB module...


>
>
> 6.  Structure of the PSAMP MIB module
>
>    The IPFIX MIB module defined in [RFC5815] has the concept of a packet
>    selection process containing a set of selector function instances.
>    Selection processes and functions are referenced in the
>    ipfixSelectionProcessTable of the IPFIX MIB module.  This table
>    identifies an instance of a selector function by an OID.  The OID
>    points to an object that describes the selector function.  For simple
>    selector functions without parameters, the OID refers to an object
>    that only contains one more object indicating the current

I read this several times as "one or more objects...", which doesn't make sense.

I suggest:

 "the OID refers to an object that contains only one additional object indicating ..."

BTW I keep wanting to change "that" to "which".


>    availability of this function.  For functions that have one or more

"the".


>    parameters the object has a subtree that in addition to an
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt           [Page 4]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>    availability object contains a table with a conceptual column for
>    each parameter.  Entries (conceptual rows) in this table represent
>    different combinations of parameter values for instances of the
>    selector function.
>
>    Object ipfixSelectorFunctions in the IPFIX SELECTOR MIB module serves
>    as home for objects that describe instances of packet selector

"as a home" or "as the home" ?


>    functions.  The IPFIX SELECTOR MIB is a very small module that is
>    also defined in [RFC5815].  Objects under ipfixSelectorFunctions are

Remove "also", because it sounds like a duplicate definition (ie, defined here and also in RFC 5815).


>    maintained by IANA.  In the IPFIX SELECTOR module object
>    ipfixSelectorFunctions contains just a single trivial packet selector
>    function called ipfixFuncSelectAll that selects every packet and has
>    no parameter:
>
>    ipfixSelectorMIB
>    +- ipfixSelectorObjects(1)
>       +- ipfixSelectorFunctions(1)
>          +- ipfixFuncSelectAll(1)
>             +- ipfixFuncSelectAllAvail(1)
>
>    The PSAMP MIB module defined in this document contains six new
>    objects under ipfixSelectorFunctions.  Each of them describes a
>    packet selector function with one or more parameters.  Naming and
>    ordering of objects is fully in line with the guidelines given in
>    section 6.1 of [RFC5815].  All functions and their parameters are
>    already listed in the overview of functions given by the figure in
>    section 8.2.1 of [RFC5477].
>
>    In addition, the PSAMP MIB module contains two textual conventions
>    that define data types used for parameters in the above tables that
>    cannot be expressed by the basic data types defined by [RFC2578],
>    unsigned64 and float64.

Is this the right place to define these for more general use?


>
> 6.1.  Textual Conventions
>
>    The MIB module defines one textual conventions that defines a data

Typo.


>    type used within this MIB module.  Another data type is imported from
>    the APPLICATION MIB [RFC2564].  Those data types are defined
>    according to [RFC5101].  Those data types are not integral part of

"not an integral"


>    [RFC2578] but are needed to define objects in this MIB module that
>    conform to the Information Elements defined for those objects in
>    [RFC5477].
>
>    The Unsigned64TC textual convention describes an unsigned integer of
>    64 bits.  It is imported from the APPLICATION MIB.
>
>    The PsampFloat64 textuanl convention describes a double precision
>    floating point number.  It is encoded accroding to [IEEE.754.1985].

Typo x 2.


>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt           [Page 5]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
> 6.2.  Packet Selection Functions
>
>    In general, different packet selector functions have different
>    parameters.  The PSAMP MIB module contains six objects with subtrees
>    that provide information on parameters of function instances of
>    different selector functions.  All objects are named and structured
>    according to section 8.2.1 of [RFC5477]:
>
>    ipfixSelectorFunctions(1)
>    +-- psampSampCountBased(2)
>    +- -psampSampTimeBased(3)
>    +-- psampSampRandOutOfN(4)
>    +-- psampSampUniProb(5)
>    +-- psampFiltPropMatch(6)
>    +-- psampFiltHash(7)

Why do you use these strange contracted names, which will surely be confusing to people whose first language isn't English?


>
>    Indexing of these functions in the PSAMP MIB module starts with index
>    (2).  The function ipfixFuncSelectAll with index (1) is already
>    defined in the IPFIX SELECTOR MIB module.

As mentioned in section 6, just above.


>
>    The object tree for each of these functions is described below.
>    Semantics of all functions and their parameters are described in
>    detail in [RFC5475].  More information on the Selector Reports can
>    also be found in section 6.5.2 of [RFC5476].
>
> 6.2.1.  Systematic Count-based Sampling
>
>    The first selector function is systematic count-based sampling.  Its
>    availability is indicated by object psampSampCountBasedAvail.  The
>    function has two parameters: psampSampCountBasedInterval and
>    psampSampCountBasedSpace.  Different combination of values of these
>    parameters for different instances of the selector function are
>    represented by different conceptual rows in table
>    psampSampCountBasedParamSetEntry:
>
>    psampSampCountBased(2)
>    +-- psampSampCountBasedAvail(1)
>    +-- psampSampCountBasedParamSetTable(2)
>       +-- psampSampCountBasedParamSetEntry(1) [psampSampCountBasedIndex]
>          +-- psampSampCountBasedIndex(1)
>          +-- psampSampCountBasedInterval(2)
>          +-- psampSampCountBasedSpace(3)
>
> 6.2.2.  Systematic Time-based Sampling
>
>    The second selector function is systematic time-based sampling.  The
>    structure of the sub-tree for this function is similar to the
>    previous one.  Parameters are psampSampTimeBasedInterval and

Be specific: say "to the psampSampCountBased sub-tree".


>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt           [Page 6]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>    psampSampTimeBasedSpace.  They appear to be the same as for count
>    based sampling, but their data types are different because they
>    indicate time values instead of numbers of packets:
>
>    psampSampTimeBased(3)
>    +-- psampSampTimeBasedAvail(1)
>    +-- psampSampTimeBasedParamSetTable(2)
>       +-- psampSampTimeBasedParamSetEntry(1) [psampSampTimeBasedIndex]
>          +-- psampSampTimeBasedIndex(1)
>          +-- psampSampTimeBasedInterval(2)
>          +-- psampSampTimeBasedSpace(3)
>
> 6.2.3.  Random n-out-of-N Sampling
>
>    The third selector function is random n-out-of-N sampling.  The
>    structure of the sub-tree for this function is similar to the
>    previous one.  Parameters are psampSampRandOutOfNSamplingSize and

So it's similar to both of the previous ones.


>    psampSampRandOutOfNPopulation:
>
>    psampSampRandOutOfN(4)
>    +-- psampSampRandOutOfNAvail(1)
>    +-- psampSampRandOutOfNParamSetTable(3)

Why is this (3) rather than (2) ?


>       +-- psampSampRandOutOfNParamSetEntry(1) [psampSampRandOutOfNIndex]
>          +-- psampSampRandOutOfNIndex(1)
>          +-- psampSampRandOutOfNSamplingSize(2)
>          +-- psampSampRandOutOfNPopulation(3)
>
> 6.2.4.  Uniform Probabilistic Sampling
>
>    The fourth selector function is uniform probabilistic sampling.  It
>    has just a single parameter called psampSampUniProbProbability:
>
>    psampSampUniProb(5)
>    +-- psampSampUniProbAvail(1)
>    +-- psampSampUniProbParamSetTable(3)

Why is this (3) rather than (2) ?


>       +-- psampSampUniProbParamSetEntry(1) [psampSampUniProbIndex]
>          +-- psampSampUniProbIndex(1)
>          +-- psampSampUniProbProbability(2)
>
> 6.2.5.  Property Match Filtering
>
>    The fifth selector function is property match filtering.  For this
>    selector function there is a broad variety of possible parameters
>    that could be used.  But as stated in section 8.2.1 of [RFC5477]
>    there are no agreed parameters specified and the sub-tree for this
>    function only contains an object indicating the availability of this
>    function.  Paameters cannot be retireved via the PSAMP MIB module:

Typo x 2.


>
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt           [Page 7]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>    psampFiltPropMatch(6)
>    +-- psampFiltPropMatchAvail(1)
>
> 6.2.6.  Hash-based Filtering
>
>    The sixth selector function is hash-based filtering.  This function
>    has more parameters and the actual number may vary with the choice of
>    the hash function applied.  The common parameter set for all hash-
>    based filtering functions contains 7 parameters:
>    psampFiltHashInitializerValue, psampFiltHashIpPayloadOffset,
>    psampFiltHashIpPayloadSize, psampFiltHashSelectedRangeMin,
>    psampFiltHashSelectedRangeMax, psampFiltHashOutputRangeMin, and
>    psampFiltHashOutputRangeMax.

psampFiltHashFunction isn't mentioned?


>
>    psampFiltHash(7)
>    +-- psampFiltHashAvail(1)
>    +-- psampFiltHashCapabilities(2)
>    +-- psampFiltHashParamSetTable(3)
>       +-- psampFiltHashParamSetEntry(1) [psampFiltHashIndex]
>          +-- psampFiltHashIndex(1)
>          +-- psampFiltHashFunction(2)
>          +-- psampFiltHashInitializerValue(3)
>          +-- psampFiltHashIpPayloadOffset(4)
>          +-- psampFiltHashIpPayloadSize(5)
>          +-- psampFiltHashSelectedRangeMin(6)
>          +-- psampFiltHashSelectedRangeMax(7)
>          +-- psampFiltHashOutputRangeMin(8)
>          +-- psampFiltHashOutputRangeMax(9)
>
>    Further parameters depend on the applied hash function and are not
>    specified within the PSAMP MIB module.
>
>
> 7.  Definitions
>
>

Have you compiled this MIB?


>    PSAMP-MIB DEFINITIONS ::= BEGIN
>
>    IMPORTS
>        MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, mib-2
>            FROM SNMPv2-SMI                  -- RFC2578
>        TEXTUAL-CONVENTION, TruthValue
>            FROM SNMPv2-TC                   -- RFC2579
>        MODULE-COMPLIANCE, OBJECT-GROUP
>            FROM SNMPv2-CONF                 -- RFC2580
>        Unsigned64TC
>            FROM APPLICATION-MIB             -- RFC2564
>        ipfixSelectorFunctions
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt           [Page 8]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>            FROM IPFIX-SELECTOR-MIB;
>
>    psampMIB MODULE-IDENTITY
>        LAST-UPDATED "201011081200Z"         -- 08 November 2010
>        ORGANIZATION "IETF IPFIX Working Group"
>        CONTACT-INFO
>            "WG charter:
>              http://www.ietf.org/html.charters/ipfix-charter.html
>
>            Mailing Lists:
>              General Discussion: ipfix@ietf.org
>              To Subscribe: http://www1.ietf.org/mailman/listinfo/ipfix
>              Archive:
>          http://www1.ietf.org/mail-archive/web/ipfix/current/index.html
>
>            Editor:
>              Thomas Dietz
>              NEC Europe Ltd.
>              NEC Laboratories Europe
>              Network Research Division
>              Kurfuersten-Anlage 36
>              69115 Heidelberg
>              Germany
>              Phone: +49 6221 4342-128
>              Email: Thomas.Dietz@nw.neclab.eu
>
>              Benoit Claise
>              Cisco Systems, Inc.
>              De Kleetlaan 6a b1
>              Degem 1831
>              Belgium
>              Phone:  +32 2 704 5622
>              Email: bclaise@cisco.com
>
>              Juergen Quittek
>              NEC Europe Ltd.
>              NEC Laboratories Europe
>              Network Research Division
>              Kurfuersten-Anlage 36
>              69115 Heidelberg
>              Germany
>              Phone: +49 6221 4342-115
>              Email: quittek@nw.neclab.eu"
>            DESCRIPTION
>            "The PSAMP MIB defines managed objects for packet sampling
>            and filtering.
>            These objects provide information about managed nodes
>            supporting packet sampling, including packet sampling
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt           [Page 9]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>            capabilities, configuration and statistics.
>
>            Copyright (c) 2010 IETF Trust and the persons identified as
>            the document authors.  All rights reserved. This version
>            of this MIB module is part of RFC yyyy; see the RFC itself
>            for full legal notices"
>    -- RFC Ed.: replace yyyy with actual RFC number & remove this notice

Being buried in the MIB, it's possible, even likely, that this will be overlooked.


>
>         --  Revision history
>
>         REVISION     "201011081200Z"         -- 08 November 2010
>         DESCRIPTION
>             "Initial version, published as RFC yyyy."
>    -- RFC Ed.: replace yyyy with actual RFC number & remove this notice
>
>        ::= { mib-2 xxx }
>    -- xxx to be assigned by IANA.

This isn't mentioned in the IANA section.


>
>    PsampFloat64 ::= TEXTUAL-CONVENTION
>        STATUS       current
>        DESCRIPTION
>                "Represents the float64 data type and MUST be encoded as
>                an IEEE double-precision 64-bit floating point-type, as
>                specified in IEEE 754."
>        SYNTAX       OCTET STRING (SIZE (8))
>
>    -- Top level structure of the MIB
>
>    psampObjects     OBJECT IDENTIFIER ::= { psampMIB 1 }
>    psampConformance OBJECT IDENTIFIER ::= { psampMIB 2 }
>
>
>    --==================================================================
>    -- Packet selection sampling methods group of objects
>    --==================================================================
>
>    --==================================================================
>    --* Method 1: Systematic count-based Sampling
>    --==================================================================
>
>    -- Reference: RFC5475, Section 5.1, RFC5476 Section 6.5.2.1 and
>    --            RFC5477, Section 8.2
>    psampSampCountBased OBJECT IDENTIFIER
>        ::= { ipfixSelectorFunctions 2 }
>
>    psampSampCountBasedAvail OBJECT-TYPE
>        SYNTAX      TruthValue
>        MAX-ACCESS  read-only
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 10]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>        STATUS      current
>        DESCRIPTION
>            "This object indicates the availability of systematic
>            count-based sampling at the managed node.
>
>            A Selector may be unavailable if it is implemented but
>            currently disabled due to e.g., administrative reasons, lack
>            of resources or similar."
>        DEFVAL { false }
>        ::= { psampSampCountBased 1 }
>
>    -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++
>
>    psampSampCountBasedParamSetTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF
>                    PsampSampCountBasedParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "This table lists configurations of systematic count-based
>            packet sampling.  A parameter set describing a
>            configuration contains two parameters: the sampling
>            interval length and the space."

Either say "and the sampling interval space", or say "the sampling interval length and space."


>        ::= { psampSampCountBased 2 }
>
>    psampSampCountBasedParamSetEntry OBJECT-TYPE
>        SYNTAX      PsampSampCountBasedParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Defines an entry in the psampSampCountBasedParamSetTable."
>        INDEX { psampSampCountBasedIndex }
>        ::= { psampSampCountBasedParamSetTable 1 }
>
>    PsampSampCountBasedParamSetEntry ::=
>        SEQUENCE {
>            psampSampCountBasedIndex     Integer32,
>            psampSampCountBasedInterval  Unsigned32,
>            psampSampCountBasedSpace     Unsigned32
>        }
>
>    psampSampCountBasedIndex OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The index of this parameter set in the
>            psampSampCountBasedParamSetTable.It is used in the

Spacing.


>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 11]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>            object ipfixSelectionProcessSelectorFunctionentries of
>            the ipfixSelectionProcessTable in the IPFIX-MIB as reference
>            to this parameter set."
>        ::= { psampSampCountBasedParamSetEntry 1 }
>
>    psampSampCountBasedInterval OBJECT-TYPE
>        SYNTAX      Unsigned32
>        UNITS       "packets"
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the number of packets that are
>            consecutively sampled.  A value of 100 means that 100
>            consecutive packets are sampled."
>        REFERENCE
>            "RFC5475, Section 5.1 and RFC5477, Section 8.2"
>        ::= { psampSampCountBasedParamSetEntry 2 }
>
>    psampSampCountBasedSpace OBJECT-TYPE
>        SYNTAX      Unsigned32
>        UNITS       "packets"
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the number of packets between two
>            psampSampCountBasedInterval's.  A value of 100 means that
>            the next interval starts 100 packets (which are not sampled)
>            after the current psampSampCountBasedInterval is over."
>        REFERENCE
>            "RFC5475, Section 5.1 and RFC5477, Section 8.2"
>        ::= { psampSampCountBasedParamSetEntry 3 }
>
>    --==================================================================
>    --* Method 2: Systematic time-based Sampling
>    --==================================================================
>
>    -- Reference: RFC5475, Section 5.1, RFC5476 Section 6.5.2.2 and
>    --            RFC5477, Section 8.2
>    psampSampTimeBased OBJECT IDENTIFIER
>        ::= { ipfixSelectorFunctions 3 }
>
>    psampSampTimeBasedAvail OBJECT-TYPE
>        SYNTAX      TruthValue
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object indicates the availability of systematic
>            time-based sampling at the managed node.
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 12]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>            A Selector may be unavailable if it is implemented but
>            currently disabled due to e.g., administrative reasons, lack
>            of resources or similar."
>        DEFVAL { false }
>        ::= { psampSampTimeBased 1 }
>
>    -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++
>
>    psampSampTimeBasedParamSetTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF
>                    PsampSampTimeBasedParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "This table lists configurations of systematic time-based
>            packet sampling. A parameter set describing a configuration
>            contains two parameters: the sampling interval length and
>            the space."
>        ::= { psampSampTimeBased 2 }
>
>    psampSampTimeBasedParamSetEntry OBJECT-TYPE
>        SYNTAX      PsampSampTimeBasedParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Defines an entry in the psampSampTimeBasedParamSetTable."
>        INDEX { psampSampTimeBasedIndex }
>        ::= { psampSampTimeBasedParamSetTable 1 }
>
>    PsampSampTimeBasedParamSetEntry ::=
>        SEQUENCE {
>            psampSampTimeBasedIndex     Integer32,
>            psampSampTimeBasedInterval  Unsigned32,
>            psampSampTimeBasedSpace     Unsigned32
>        }
>
>    psampSampTimeBasedIndex OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The index of this parameter set in the
>            psampSampTimeBasedParamSetTable. It is used in the
>            object ipfixSelectionProcessSelectorFunctionentries of
>            the ipfixSelectionProcessTable in the IPFIX-MIB as reference
>            to this parameter set."
>        ::= { psampSampTimeBasedParamSetEntry 1 }
>
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 13]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>    psampSampTimeBasedInterval OBJECT-TYPE
>        SYNTAX      Unsigned32
>        UNITS       "microseconds"
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>           "This object specifies the time interval in microseconds
>           during which all arriving packets are sampled."

This description's indentation is slightly different.


>        REFERENCE
>            "RFC5475, Section 5.1 and RFC5477, Section 8.2"
>        ::= { psampSampTimeBasedParamSetEntry 2 }
>
>    psampSampTimeBasedSpace OBJECT-TYPE
>        SYNTAX      Unsigned32
>        UNITS       "microseconds"
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the time interval in microseconds
>            between two psampSampTimeBasedInterval's.  A value of 100
>            means that the next interval starts 100 microseconds (during
>            which no packets are sampled) after the current
>            psampSampTimeBasedInterval is over."
>        REFERENCE
>            "RFC5475, Section 5.1 and RFC5477, Section 8.2"
>        ::= { psampSampTimeBasedParamSetEntry 3 }
>
>    --==================================================================
>    --* Method 3: Random n-out-of-N Sampling
>    --==================================================================
>
>    -- Reference: RFC5475, Section 5.2.1, RFC5476 Section 6.5.2.3 and
>    --            RFC5477, Section 8.2
>    psampSampRandOutOfN OBJECT IDENTIFIER
>        ::= { ipfixSelectorFunctions 4 }
>
>    psampSampRandOutOfNAvail OBJECT-TYPE
>        SYNTAX      TruthValue
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object indicates the availability of random n-out-of-N
>            sampling at the managed node.
>
>            A Selector may be unavailable if it is implemented but
>            currently disabled due to e.g., administrative reasons, lack
>            of resources or similar."
>        DEFVAL { false }
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 14]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>        ::= { psampSampRandOutOfN 1 }
>
>    -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++
>
>    psampSampRandOutOfNParamSetTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF
>                    PsampSampRandOutOfNParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "This table lists configurations of random n-out-of-N
>            sampling.  A parameter set describing a configuration
>            contains a two parameter only, the sampling size and the
>            parent population."
>        ::= { psampSampRandOutOfN 3 }
>
>    psampSampRandOutOfNParamSetEntry OBJECT-TYPE
>        SYNTAX      PsampSampRandOutOfNParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Defines an entry in the psampSampRandOutOfNParamSetTable."
>        INDEX { psampSampRandOutOfNIndex }
>        ::= { psampSampRandOutOfNParamSetTable 1 }
>
>    PsampSampRandOutOfNParamSetEntry ::=
>        SEQUENCE {
>            psampSampRandOutOfNIndex        Integer32,
>            psampSampRandOutOfNSamplingSize Unsigned32,
>            psampSampRandOutOfNPopulation   Unsigned32
>        }
>
>    psampSampRandOutOfNIndex OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The index of this parameter set in the
>            psampSampRandOutOfNParamSetTable.  It is used in the
>            object ipfixSelectionProcessSelectorFunctionentries of
>            the ipfixSelectionProcessTable in the IPFIX-MIB as reference
>            to this parameter set."
>        ::= { psampSampRandOutOfNParamSetEntry 1 }
>
>    psampSampRandOutOfNSamplingSize OBJECT-TYPE
>        SYNTAX      Unsigned32
>        UNITS       "packets"
>        MAX-ACCESS  read-only
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 15]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the number of elements taken from the
>            parent Population for specified in

Remove "for".


>            psampSampRandOutOfNPopulation."
>        REFERENCE
>            "RFC5475, Section 5.2.1 and RFC5477, Section 8.2"
>        ::= { psampSampRandOutOfNParamSetEntry 2 }
>
>    psampSampRandOutOfNPopulation OBJECT-TYPE
>        SYNTAX      Unsigned32
>        UNITS       "packets"
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>           "This object specifies the number of elements in the parent
>           Population."

This description's indentation is slightly different.


>        REFERENCE
>            "RFC5475, Section 5.2.1 and RFC5477, Section 8.2"
>        ::= { psampSampRandOutOfNParamSetEntry 3 }
>
>    --==================================================================
>    --* Method 4: Uniform probabilistic Sampling
>    --==================================================================
>
>    -- Reference: RFC5475, Section 5.2.2, RFC5476 Section 6.5.2.4 and
>    --            RFC5477, Section 8.2
>    psampSampUniProb OBJECT IDENTIFIER ::= { ipfixSelectorFunctions 5 }
>
>    psampSampUniProbAvail OBJECT-TYPE
>        SYNTAX      TruthValue
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object indicates the availability of random uniform
>            probabilistic sampling at the managed node.
>
>            A Selector may be unavailable if it is implemented but
>            currently disabled due to e.g., administrative reasons, lack
>            of resources or similar."
>        DEFVAL { false }
>        ::= { psampSampUniProb 1 }
>
>    -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++
>
>    -- Reference: RFC5475, Section 5.2.2.1 and RFC5477, Section 8.2
>    psampSampUniProbParamSetTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 16]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>                    PsampSampUniProbParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "This table lists configurations of random probabilistic
>            sampling.  A parameter set describing a configuration
>            contains a single parameter only: the sampling probability."
>        ::= { psampSampUniProb 3 }
>
>    psampSampUniProbParamSetEntry OBJECT-TYPE
>        SYNTAX      PsampSampUniProbParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Defines an entry in the psampSampUniProbParamSetTable."
>        INDEX { psampSampUniProbIndex }
>        ::= { psampSampUniProbParamSetTable 1 }
>
>    PsampSampUniProbParamSetEntry ::=
>        SEQUENCE {
>            psampSampUniProbIndex       Integer32,
>            psampSampUniProbProbability PsampFloat64
>        }
>
>    psampSampUniProbIndex OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>           "The index of this parameter set in the

The indentation of the first line of this description is slightly different.


>            psampSampUniProbParamSetTable.  It is used in the
>            object ipfixSelectionProcessSelectorFunctionentries of
>            the ipfixSelectionProcessTable in the IPFIX-MIB as reference
>            to this parameter set."
>        ::= { psampSampUniProbParamSetEntry 1 }
>
>    psampSampUniProbProbability OBJECT-TYPE
>        SYNTAX      PsampFloat64
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the probability that a packet is
>            sampled, expressed as a value between 0 and 1.  The
>            probability is equal for every packet.  A value of 0 means
>            no packet was sampled since the probability is 0. A value
>            of 1 means all packets were sampled since the
>            probability is 1."
>        REFERENCE
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 17]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>            "RFC5475, Section 5.2.2.1 and RFC5477, Section 8.2"
>        ::= { psampSampUniProbParamSetEntry 2 }
>
>    --==================================================================
>    -- Packet selection filtering methods group of objects
>    --==================================================================
>
>    --==================================================================
>    --* Method 5: Property Match filtering
>    --==================================================================
>
>    -- Reserves Method 5 (see RFC5475, Section 6.1, RFC5476
>    -- Section 6.5.2.5 and RFC5477)
>    psampFiltPropMatch OBJECT IDENTIFIER
>        ::= { ipfixSelectorFunctions 6 }
>
>    psampFiltPropMatchAvail OBJECT-TYPE
>        SYNTAX      TruthValue
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object indicates the availability of property match
>            filtering at the managed node.
>
>            A Selector may be unavailable if it is implemented but
>            currently disabled due to e.g., administrative reasons, lack
>            of resources or similar."
>        DEFVAL { false }
>        ::= { psampFiltPropMatch 1 }
>
>    --==================================================================
>    --* Method 1: Hash filtering

Typo: it's method 6.


>    --==================================================================
>
>    -- Reference: RFC5475, Section 6.2, RFC5476 Section 6.5.2.6 and
>    --            RFC5477, Section 8.3
>    psampFiltHash OBJECT IDENTIFIER ::= { ipfixSelectorFunctions 7 }
>
>    psampFiltHashAvail OBJECT-TYPE
>        SYNTAX      TruthValue
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object indicates the availability of hash filtering
>            at the managed node.
>
>            A Selector may be unavailable if it is implemented but
>            currently disabled due to e.g., administrative reasons, lack
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 18]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>            of resources or similar."
>        DEFVAL { false }
>        ::= { psampFiltHash 1 }
>
>    psampFiltHashCapabilities OBJECT IDENTIFIER
>        ::= { psampFiltHash 2 }
>
>    -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++
>
>    -- Reference: RFC5475, Sections 6.2, 3.8, and 7.1
>    psampFiltHashParamSetTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF
>                    PsampFiltHashParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "This table lists configurations of hash filtering. A
>            parameter set describing a configuration contains eight
>            parameter describing the hash function."
>        ::= { psampFiltHash 3 }
>
>    psampFiltHashParamSetEntry OBJECT-TYPE
>        SYNTAX      PsampFiltHashParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Defines an entry in the psampFiltHashParamSetTable."
>        INDEX { psampFiltHashIndex }
>        ::= { psampFiltHashParamSetTable 1 }
>
>    PsampFiltHashParamSetEntry ::=
>        SEQUENCE {
>            psampFiltHashIndex            Integer32,
>            psampFiltHashFunction         INTEGER,
>            psampFiltHashInitializerValue Unsigned64TC,
>            psampFiltHashIpPayloadOffset  Unsigned64TC,
>            psampFiltHashIpPayloadSize    Unsigned64TC,
>            psampFiltHashSelectedRangeMin Unsigned64TC,
>            psampFiltHashSelectedRangeMax Unsigned64TC,
>            psampFiltHashOutputRangeMin   Unsigned64TC,
>            psampFiltHashOutputRangeMax   Unsigned64TC
>        }
>
>    psampFiltHashIndex OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 19]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>            "The index of this parameter set in the
>             psampFiltHashParamSetTable. It is used in the
>            object ipfixSelectionProcessSelectorFunctionentries of
>            the ipfixSelectionProcessTable in the IPFIX-MIB as reference
>            to this parameter set."
>        ::= { psampFiltHashParamSetEntry 1 }
>
>    psampFiltHashFunction OBJECT-TYPE
>        SYNTAX      INTEGER {
>                        crc32(1),
>                        ipsx(2),
>                        bob(3)
>                    }
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The Hash Function used by this filter. The PSAMP-MIB
>            supports the following Hash Functions:
>
>            crc32(1)
>
>            ipsx(2)
>
>            bob(3)
>            "
>        ::= { psampFiltHashParamSetEntry 2 }
>
>    psampFiltHashInitializerValue OBJECT-TYPE
>        SYNTAX      Unsigned64TC
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the initializer value to the hash
>            function."
>        REFERENCE
>            "RFC5475, Sections 6.2, 3.8, and 7.1"
>        ::= { psampFiltHashParamSetEntry 3 }
>
>    psampFiltHashIpPayloadOffset OBJECT-TYPE
>        SYNTAX      Unsigned64TC
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the IP payload offset used by a
>            Hash-based Selection Selector."
>        REFERENCE
>            "RFC5475, Sections 6.2, 3.8, and 7.1"
>        ::= { psampFiltHashParamSetEntry 4 }
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 20]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>    psampFiltHashIpPayloadSize OBJECT-TYPE
>        SYNTAX      Unsigned64TC
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the IP payload size used by a
>            Hash-based Selection Selector."
>        REFERENCE
>            "RFC5475, Sections 6.2, 3.8, and 7.1"
>        ::= { psampFiltHashParamSetEntry 5 }
>
>    psampFiltHashSelectedRangeMin OBJECT-TYPE
>        SYNTAX      Unsigned64TC
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the value for the beginning of a hash
>            function's selected range."
>        REFERENCE
>            "RFC5475, Sections 6.2, 3.8, and 7.1"
>        ::= { psampFiltHashParamSetEntry 6 }
>
>    psampFiltHashSelectedRangeMax OBJECT-TYPE
>        SYNTAX      Unsigned64TC
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the value for the end of a hash
>            function's selected range."
>        REFERENCE
>            "RFC5475, Sections 6.2, 3.8, and 7.1"
>        ::= { psampFiltHashParamSetEntry 7 }
>
>    psampFiltHashOutputRangeMin OBJECT-TYPE
>        SYNTAX      Unsigned64TC
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the value for the beginning of a hash
>            function's potential output range."
>        REFERENCE
>            "RFC5475, Sections 6.2, 3.8, and 7.1"
>        ::= { psampFiltHashParamSetEntry 8 }
>
>    psampFiltHashOutputRangeMax OBJECT-TYPE
>        SYNTAX      Unsigned64TC
>        MAX-ACCESS  read-only
>        STATUS      current
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 21]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>        DESCRIPTION
>            "This object specifies the value for the end of a hash
>            function's potential output range."
>        REFERENCE
>            "RFC5475, Sections 6.2, 3.8, and 7.1"
>        ::= { psampFiltHashParamSetEntry 9 }
>
>    --==================================================================
>    -- Conformance information
>    --==================================================================
>
>    psampCompliances OBJECT IDENTIFIER ::= { psampConformance 1 }
>    psampGroups      OBJECT IDENTIFIER ::= { psampConformance 2 }
>
>    --==================================================================
>    -- Compliance statements
>    --==================================================================
>
>    psampCompliance MODULE-COMPLIANCE
>        STATUS  current
>        DESCRIPTION
>            "The implementation of all objects is optional and depends
>            on the implementation of the corresponding functionality in
>            the equipment."
>        MODULE  -- this module
>            GROUP psampGroupSampCountBased
>            DESCRIPTION
>                "These objects must be implemented if the corresponding
>                sampling function is implemented in the equipment."
>            GROUP psampGroupSampTimeBased
>            DESCRIPTION
>                "These objects must be implemented if the corresponding
>                sampling function is implemented in the equipment."
>            GROUP psampGroupSampRandOutOfN
>            DESCRIPTION
>                "These objects must be implemented if the corresponding
>                sampling function is implemented in the equipment."
>            GROUP psampGroupSampUniProb
>            DESCRIPTION
>                "These objects must be implemented if the corresponding
>                sampling function is implemented in the equipment."
>            GROUP psampGroupFiltPropMatch
>            DESCRIPTION
>                "These objects must be implemented if the corresponding
>                filter function is implemented in the equipment."
>            GROUP psampGroupFiltHash
>            DESCRIPTION
>                "These objects must be implemented if the corresponding
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 22]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>                filter function is implemented in the equipment."
>        ::= { psampCompliances 1 }
>
>    --==================================================================
>    -- MIB groupings
>    --==================================================================
>

The indentation of all the descriptions below is slightly different from the previous descriptions above.


>    psampGroupSampCountBased OBJECT-GROUP
>        OBJECTS {
>                  psampSampCountBasedAvail,
>                  psampSampCountBasedInterval,
>                  psampSampCountBasedSpace
>                }
>        STATUS  current
>        DESCRIPTION
>           "These objects are needed if count based sampling is
>           implemented."
>        ::= { psampGroups 2 }
>
>    psampGroupSampTimeBased OBJECT-GROUP
>        OBJECTS {
>                  psampSampTimeBasedAvail,
>                  psampSampTimeBasedInterval,
>                  psampSampTimeBasedSpace
>                }
>        STATUS  current
>        DESCRIPTION
>           "These objects are needed if time based sampling is
>           implemented."
>        ::= { psampGroups 3 }
>
>    psampGroupSampRandOutOfN OBJECT-GROUP
>        OBJECTS {
>                  psampSampRandOutOfNAvail,
>                  psampSampRandOutOfNSamplingSize,
>                  psampSampRandOutOfNPopulation
>                }
>        STATUS  current
>        DESCRIPTION
>           "These objects are needed if random n-out-of-N sampling is
>           implemented."
>        ::= { psampGroups 4 }
>
>    psampGroupSampUniProb OBJECT-GROUP
>        OBJECTS {
>                  psampSampUniProbAvail,
>                  psampSampUniProbProbability
>                }
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 23]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>        STATUS  current
>        DESCRIPTION
>           "These objects are needed if uniform probabilistic sampling
>           is implemented."
>        ::= { psampGroups 5 }
>
>    psampGroupFiltPropMatch OBJECT-GROUP
>        OBJECTS {
>                  psampFiltPropMatchAvail
>                }
>        STATUS  current
>        DESCRIPTION
>           "These objects are needed if property match filtering is
>           implemented."
>        ::= { psampGroups 6 }
>
>    psampGroupFiltHash OBJECT-GROUP
>        OBJECTS {
>                  psampFiltHashAvail,
>                  psampFiltHashFunction,
>                  psampFiltHashInitializerValue,
>                  psampFiltHashIpPayloadOffset,
>                  psampFiltHashIpPayloadSize,
>                  psampFiltHashSelectedRangeMin,
>                  psampFiltHashSelectedRangeMax,
>                  psampFiltHashOutputRangeMin,
>                  psampFiltHashOutputRangeMax
>                }
>        STATUS  current
>        DESCRIPTION
>           "These objects are needed if hash filtering is implemented."
>        ::= { psampGroups 9 }

"psampGroups 7".


>
>    END
>
>
> 8.  Security Considerations
>
>    There are no management objects defined in this MIB module that have
>    a MAX-ACCESS clause of read-write and/or read-create.  So, if this
>    MIB module is implemented correctly, then there is no risk that an
>    intruder can alter or create any management objects of this MIB
>    module via direct SNMP SET operations.
>
>    Some of the readable objects in this MIB module (i.e., objects with a

See below.


>    MAX-ACCESS other than not-accessible) may be considered sensitive or
>    vulnerable in some network environments.  It is thus important to
>    control even GET and/or NOTIFY access to these objects and possibly
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 24]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>    to even encrypt the values of these objects when sending them over
>    the network via SNMP.  These are the tables and objects and their
>    sensitivity/vulnerability:
>
>    o  All tables - they contain configuration data that might be
>       sensitive because objects in this table may reveal information
>       about the network infrastructure and device configuration

>From "Some of" to here, why not just say:

All tables in this MIB module may be considered sensitive or vulnerable
in some network environments because objects in the tables may reveal information
about the network infrastructure and device configuration. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP.


>
>    SNMP versions prior to SNMPv3 did not include adequate security.
>    Even if the network itself is secure (for example by using IPsec),
>    there is no control as to who on the secure network is allowed to
>    access and GET/SET (read/change/create/delete) the objects in this
>    MIB module.
>
>    It is RECOMMENDED that implementers consider the security features as

Remove "as".


>    provided by the SNMPv3 framework (see [RFC3410], section 8),
>    including full support for the SNMPv3 cryptographic mechanisms (for
>    authentication and privacy).
>
>    Further, deployment of SNMP versions prior to SNMPv3 is NOT
>    RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
>    enable cryptographic security.  It is then a customer/operator
>    responsibility to ensure that the SNMP entity giving access to an
>    instance of this MIB module is properly configured to give access to
>    the objects only to those principals (users) that have legitimate

Users are people, so use "who".


>    rights to indeed GET or SET (change/create/delete) them.

Remove "indeed".


> 9.  IANA Considerations
>
>    The MIB module in this document uses the following IANA-assigned
>    OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
>
>            Descriptor             OBJECT IDENTIFIER value
>            ----------             -----------------------
>            psampMIB               { mib-2 xxx }

Clearly specify that xxx must be assigned by IANA and also written into the MIB in section 7.


Thanks,
P.


>            psampSampCountBased    { ipfixSelectorFunctions 2 }
>            psampSampTimeBased     { ipfixSelectorFunctions 3 }
>            psampSampRandOutOfN    { ipfixSelectorFunctions 4 }
>            psampSampUniProb       { ipfixSelectorFunctions 5 }
>            psampFiltPropMatch     { ipfixSelectorFunctions 6 }
>            psampFiltHash          { ipfixSelectorFunctions 7 }
>
>    Other than that this document does not impose any IANA
>    considerations.
>
>
>
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 25]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
> 10.  Acknowledgment
>
>    This document is a product of the PSAMP and IPFIX working groups.
>
>
> 11.  References
>
> 11.1.  Normative References
>
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>    [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
>               Schoenwaelder, Ed., "Structure of Management Information
>               Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
>
>    [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
>               Schoenwaelder, Ed., "Textual Conventions for SMIv2",
>               STD 58, RFC 2579, April 1999.
>
>    [RFC2580]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
>               "Conformance Statements for SMIv2", STD 58, RFC 2580,
>               April 1999.
>
>    [RFC2564]  Kalbfleisch, C., Krupczak, C., Presuhn, R., and J.
>               Saperia, "Application Management MIB", RFC 2564, May 1999.
>
>    [RFC5101]  Claise, B., "Specification of the IP Flow Information
>               Export (IPFIX) Protocol for the Exchange of IP Traffic
>               Flow Information", RFC 5101, January 2008.
>
>    [RFC5477]  Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
>               Carle, "Information Model for Packet Sampling Exports",
>               RFC 5477, March 2009.
>
>    [RFC5815]  Dietz, T., Kobayashi, A., Claise, B., and G. Muenz,
>               "Definitions of Managed Objects for IP Flow Information
>               Export", RFC 5815, April 2010.
>
>    [IEEE.754.1985]
>               Institute of Electrical and Electronics Engineers,
>               "Standard for Binary Floating-Point Arithmetic",
>               IEEE Standard 754, August 1985.
>
> 11.2.  Informative References
>
>    [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
>               "Introduction and Applicability Statements for Internet-
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 26]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>               Standard Management Framework", RFC 3410, December 2002.
>
>    [RFC5474]  Duffield, N., Chiou, D., Claise, B., Greenberg, A.,
>               Grossglauser, M., and J. Rexford, "A Framework for Packet
>               Selection and Reporting", RFC 5474, March 2009.
>
>    [RFC5475]  Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F.
>               Raspall, "Sampling and Filtering Techniques for IP Packet
>               Selection", RFC 5475, March 2009.
>
>    [RFC5476]  Claise, B., Johnson, A., and J. Quittek, "Packet Sampling
>               (PSAMP) Protocol Specifications", RFC 5476, March 2009.
>
>
> Authors' Addresses
>
>    Thomas Dietz (editor)
>    NEC Europe Ltd.
>    NEC Laboratories Europe
>    Kurfuersten-Anlage 36
>    Heidelberg  69115
>    DE
>
>    Phone: +49 6221 4342-128
>    Email: dietz@neclab.eu
>
>
>    Benoit Claise
>    Cisco Systems, Inc.
>    De Kleetlaan 6a b1
>    Degem  1831
>    BE
>
>    Phone: +32 2 704 5622
>    Email: bclaise@cisco.com
>
>
>    Juergen Quittek
>    NEC Europe Ltd.
>    NEC Laboratories Europe
>    Kurfuersten-Anlage 36
>    Heidelberg  69115
>    DE
>
>    Phone: +49 6221 4342-115
>    Email: quittek@neclab.eu
>
>
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 27]
>
>

--------------040504030300000000040707-- From j.schoenwaelder@jacobs-university.de Tue Nov 16 04:35:00 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58ACB3A6A73 for ; Tue, 16 Nov 2010 04:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.158 X-Spam-Level: X-Spam-Status: No, score=-103.158 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yM3jqiS9JCMj for ; Tue, 16 Nov 2010 04:34:59 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2A23D3A68D0 for ; Tue, 16 Nov 2010 04:34:59 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 52132C0018 for ; Tue, 16 Nov 2010 13:35:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wtkSU-z7k1E7; Tue, 16 Nov 2010 13:35:41 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A5D76C0014; Tue, 16 Nov 2010 13:35:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9528615AC04E; Tue, 16 Nov 2010 13:35:41 +0100 (CET) Date: Tue, 16 Nov 2010 13:35:41 +0100 From: Juergen Schoenwaelder To: ipfix@ietf.org Message-ID: <20101116123541.GA82517@elstar.local> Mail-Followup-To: ipfix@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [IPFIX] flowStartSysUpTime and flowEndSysUpTime versus sysUpTime X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 16 Nov 2010 12:35:00 -0000 Hi, RFC 5102 has the following text: 5.9.12. flowStartSysUpTime Description: The relative timestamp of the first packet of this Flow. It indicates the number of milliseconds since the last (re-)initialization of the IPFIX Device (sysUpTime). Abstract Data Type: unsigned32 ElementId: 22 Status: current Units: milliseconds 5.9.13. flowEndSysUpTime Description: The relative timestamp of the last packet of this Flow. It indicates the number of milliseconds since the last (re-)initialization of the IPFIX Device (sysUpTime). Abstract Data Type: unsigned32 ElementId: 21 Status: current Units: milliseconds I assume the "(sysUpTime)" refers to the definition given in RFC 3418: sysUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." ::= { system 3 } Note that sysUpTime is counted in hundredths of a second and not milliseconds (means different rollover times) and that sysUpTime is counted from the last re-initialization of the network management portion of a system, which is not necessarily the same as the (re-)initialization of the IPFIX Device. A possible fix is to remove any references to "(sysUpTime)" from RFC 5101. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From yaroslav@arbor.net Mon Nov 22 10:46:34 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F523A6AEA for ; Mon, 22 Nov 2010 10:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odal2JGVW0Wk for ; Mon, 22 Nov 2010 10:46:32 -0800 (PST) Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by core3.amsl.com (Postfix) with ESMTP id A2ACD3A6A2A for ; Mon, 22 Nov 2010 10:46:31 -0800 (PST) Received: from gateout02.mbox.net (gwo2-lo [127.0.0.1]) by gateout02.mbox.net (Postfix) with ESMTP id 124AE4BEFDC; Mon, 22 Nov 2010 18:47:27 +0000 (GMT) X-USANET-Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.68Q) with ESMTP id 227okVsvy1728Mo2; Mon, 22 Nov 2010 18:47:24 -0000 Received: from s1hub1.EXCHPROD.USA.NET [165.212.120.254] by gateout02.mbox.net via smtad (C8.MAIN.3.68M) with ESMTPS id XID974okVsvy5423Xo2; Mon, 22 Nov 2010 18:47:24 -0000 X-USANET-Source: 165.212.120.254 IN yaroslav@arbor.net s1hub1.EXCHPROD.USA.NET X-USANET-MsgId: XID974okVsvy5423Xo2 Received: from MBX14.EXCHPROD.USA.NET ([10.120.221.141]) by s1hub1.EXCHPROD.USA.NET ([10.120.220.31]) with mapi; Mon, 22 Nov 2010 18:46:47 +0000 From: "Rosomakho, Yaroslav" To: "bclaise@cisco.com" Date: Mon, 22 Nov 2010 18:46:46 +0000 Thread-Topic: draft-johnson-ipfix-mib-variable-export-00 Thread-Index: AcuKdZ2JYxuzWy69Tda+g9wJc8bYSQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipfix@ietf.org" Subject: [IPFIX] draft-johnson-ipfix-mib-variable-export-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 18:46:34 -0000 Hello! First of all, I would like to note that this is a very important and useful addition to IPFIX protocol. There are a few notes, that I would like to make: 1. A very practical usage of SNMP counters is verification of accuracy of metering and exporting processes. Comparison of flow and SNMP data is a good way to tune sampling rate and sampling algorithm. I think this could be highlighted in applicability section or in examples. 2. I think indexing approach should be reworked. If I understand proposed indexing correctly, it requires that all indexes at the end of OID must match information elements in flow. Take tcpConnectionTable/Entry (RFC4022) as an example: there is no information element that would cover tcpConnectionRemAddressType =AD so there is no way how we could bind an information element with tcpConnectionLocalPort. A solution would be to have a negative offset for each index. Here is an example of proposed structure of OID with three indexes with offsets: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| MIB OID IE | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index Count |MIB Obj. ID Len| MIB Object Identifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... MIB Object Identifier continued | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset 1 |0| Index Information Element 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset 2 |1| Index Information Element 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset 3 |0| Index Information Element 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Offset =3D 0 means that a given index is exactly at the end of OID. Offset = =3D N means that a given IE is at N bytes from the end of the OID. =20 Best Regards, Yaroslav From bclaise@cisco.com Tue Nov 23 04:42:14 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75B183A6924 for ; Tue, 23 Nov 2010 04:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bunwHQLyWKZu for ; Tue, 23 Nov 2010 04:42:12 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 115663A6939 for ; Tue, 23 Nov 2010 04:42:09 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oANCh61W017598; Tue, 23 Nov 2010 13:43:06 +0100 (CET) Received: from [10.55.43.54] (ams-bclaise-8715.cisco.com [10.55.43.54]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oANCh5i3005886; Tue, 23 Nov 2010 13:43:06 +0100 (CET) Message-ID: <4CEBB6D9.8040609@cisco.com> Date: Tue, 23 Nov 2010 13:43:05 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: DESCOMBES Thierry References: <4CC7DE4E.6090009@lpsc.in2p3.fr> In-Reply-To: <4CC7DE4E.6090009@lpsc.in2p3.fr> Content-Type: multipart/alternative; boundary="------------070605060707080007070604" Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX flows timestamps X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 12:42:14 -0000 This is a multi-part message in MIME format. --------------070605060707080007070604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Thierry, > Hello, > > I am currently developing a collector NetFlow / IPFIX.I am trying to > decode the "first switched" and "last switched" timestamps of flows > with an accuracy of one second. It was simple so far with Netflows. > With IPFIX, is there a simple and standard way to do that ? (Or should > I deal with all possible combinations of time fields > (flowStartSysUpTime, flowEndSysUpTime, systemInitTimeMilliseconds, > flowStartMicroseconds, flowEndMicroseconds, > flowStartDeltaMicroseconds, flowEndDeltaMicroseconds...) ? You should have a generic solution. Regards, Benoit. > > What are the manufacturers and models of router implementing IPFIX? > What type of timestamp do they implement? > > Thanks a lot in advance. > Regards > > Thierry Descombes > LPSC - CNRS > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------070605060707080007070604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Thierry,
Hello,

I am currently developing a collector NetFlow / IPFIX. I am trying to decode the "first switched" and "last switched" timestamps of flows with an accuracy of one second. It was simple so far with Netflows. With IPFIX,  is there a simple and standard way to do that ? (Or should I deal with all possible combinations of time fields (flowStartSysUpTime, flowEndSysUpTime, systemInitTimeMilliseconds, flowStartMicroseconds, flowEndMicroseconds, flowStartDeltaMicroseconds, flowEndDeltaMicroseconds...) ?
You should have a generic solution.

Regards, Benoit.

What are the manufacturers and models of router implementing IPFIX? What type of timestamp do they implement?
Thanks a lot in advance.
Regards

Thierry Descombes
LPSC - CNRS 

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

--------------070605060707080007070604-- From andrjohn@cisco.com Tue Nov 23 09:11:47 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06DEC3A68A0 for ; Tue, 23 Nov 2010 09:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JDRkyhdEwtt for ; Tue, 23 Nov 2010 09:11:45 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 134C13A68DE for ; Tue, 23 Nov 2010 09:11:44 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,243,1288569600"; d="scan'208";a="185173476" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Nov 2010 17:12:41 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oANHCft9020077; Tue, 23 Nov 2010 17:12:41 GMT Received: from ams-andrjohn-8713.cisco.com (ams-andrjohn-8713.cisco.com [10.55.163.36]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id oANHCc810880; Tue, 23 Nov 2010 17:12:39 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Andrew Johnson In-Reply-To: Date: Tue, 23 Nov 2010 17:12:37 +0000 Content-Transfer-Encoding: 7bit Message-Id: <800709EC-C250-4A47-901C-70DC4B694233@cisco.com> References: To: "Rosomakho, Yaroslav" X-Mailer: Apple Mail (2.1082) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-johnson-ipfix-mib-variable-export-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 17:11:47 -0000 Dear Yaroslav Thank you for your interest in the draft and your comments. The Indexes are identified with the extended field specifier, so can optionally be identified using another OID. We are looking to update the draft in the near future make this more obvious. In your suggestion below, you're basically proposing to make the indexes that are identified optional? The current feeling is that the indexes must be identified in order to communicate the full meaning of what is being exported. You raise some interesting points / questions: 1. Does the value in the index have to be the actual value used for the index, or is the semantic what's important? e.g. the value used for tcpConnectionRemAddressType can be inferred using the ipVersion IE, but the values don't match. 2. The semantic behind both the tcpConnectionRemAddressType and tcpConnectionRemAddress can be communicated via the sourceIPv6Address IE, however how do you map that to two indexes? 3. When your simply associated extra information with a flow, you should be able to communicate how the OID was indexed using information from the flow, but if we want to export management information, then won't we need a way to transmit the value of an index? i.e., why not simply transmit the tcpConnectionRemAddressType, but how do we identify that? regards Andrew On 22 Nov 2010, at 18:46, Rosomakho, Yaroslav wrote: > Hello! > > First of all, I would like to note that this is a very important and > useful addition to IPFIX protocol. > > There are a few notes, that I would like to make: > > 1. A very practical usage of SNMP counters is verification of accuracy of > metering and exporting processes. Comparison of flow and SNMP data is a > good way to tune sampling rate and sampling algorithm. I think this could > be highlighted in applicability section or in examples. > > 2. I think indexing approach should be reworked. If I understand proposed > indexing correctly, it requires that all indexes at the end of OID must > match information elements in flow. Take tcpConnectionTable/Entry > (RFC4022) as an example: there is no information element that would cover > tcpConnectionRemAddressType so there is no way how we could bind an > information element with tcpConnectionLocalPort. A solution would be to > have a negative offset for each index. Here is an example of proposed > structure of OID with three indexes with offsets: > > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |E| MIB OID IE | Field Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Index Count |MIB Obj. ID Len| MIB Object Identifier ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... MIB Object Identifier continued | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Offset 1 |0| Index Information Element 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Offset 2 |1| Index Information Element 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Offset 3 |0| Index Information Element 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Offset = 0 means that a given index is exactly at the end of OID. Offset = > N means that a given IE is at N bytes from the end of the OID. > > > > Best Regards, > Yaroslav > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > From bclaise@cisco.com Tue Nov 23 09:27:39 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9883A68A9 for ; Tue, 23 Nov 2010 09:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojnjvmlWMsPc for ; Tue, 23 Nov 2010 09:27:38 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 49F1C3A6881 for ; Tue, 23 Nov 2010 09:27:29 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oANHKs7W024600; Tue, 23 Nov 2010 18:20:54 +0100 (CET) Received: from [10.55.43.54] (ams-bclaise-8715.cisco.com [10.55.43.54]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oANHKscQ003572; Tue, 23 Nov 2010 18:20:54 +0100 (CET) Message-ID: <4CEBF7F5.2050806@cisco.com> Date: Tue, 23 Nov 2010 18:20:53 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Andrew Johnson References: <800709EC-C250-4A47-901C-70DC4B694233@cisco.com> In-Reply-To: <800709EC-C250-4A47-901C-70DC4B694233@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-johnson-ipfix-mib-variable-export-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 17:27:39 -0000 Dear Yaroslav, > Dear Yaroslav > > Thank you for your interest in the draft and your comments. > > The Indexes are identified with the extended field specifier, > so can optionally be identified using another OID. We are > looking to update the draft in the near future make this more > obvious. Indeed. In the mean time: Figure K shows an index being an IPFIX IE Figure L shows an index being an MIB OID Regards, Benoit. > In your suggestion below, you're basically proposing to make > the indexes that are identified optional? The current feeling > is that the indexes must be identified in order to communicate > the full meaning of what is being exported. > > > You raise some interesting points / questions: > > 1. Does the value in the index have to be the actual value used > for the index, or is the semantic what's important? > > e.g. the value used for tcpConnectionRemAddressType can be > inferred using the ipVersion IE, but the values don't match. > > > 2. The semantic behind both the tcpConnectionRemAddressType and > tcpConnectionRemAddress can be communicated via the > sourceIPv6Address IE, however how do you map that to two > indexes? > > > 3. When your simply associated extra information with a flow, > you should be able to communicate how the OID was indexed > using information from the flow, but if we want to export > management information, then won't we need a way to transmit > the value of an index? > > i.e., why not simply transmit the tcpConnectionRemAddressType, > but how do we identify that? > > > regards > > Andrew > > > > On 22 Nov 2010, at 18:46, Rosomakho, Yaroslav wrote: > >> Hello! >> >> First of all, I would like to note that this is a very important and >> useful addition to IPFIX protocol. >> >> There are a few notes, that I would like to make: >> >> 1. A very practical usage of SNMP counters is verification of accuracy of >> metering and exporting processes. Comparison of flow and SNMP data is a >> good way to tune sampling rate and sampling algorithm. I think this could >> be highlighted in applicability section or in examples. >> >> 2. I think indexing approach should be reworked. If I understand proposed >> indexing correctly, it requires that all indexes at the end of OID must >> match information elements in flow. Take tcpConnectionTable/Entry >> (RFC4022) as an example: there is no information element that would cover >> tcpConnectionRemAddressType so there is no way how we could bind an >> information element with tcpConnectionLocalPort. A solution would be to >> have a negative offset for each index. Here is an example of proposed >> structure of OID with three indexes with offsets: >> >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |E| MIB OID IE | Field Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Index Count |MIB Obj. ID Len| MIB Object Identifier ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... MIB Object Identifier continued | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Offset 1 |0| Index Information Element 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Offset 2 |1| Index Information Element 2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Enterprise Number | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | Offset 3 |0| Index Information Element 3 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Offset = 0 means that a given index is exactly at the end of OID. Offset = >> N means that a given IE is at N bytes from the end of the OID. >> >> >> >> Best Regards, >> Yaroslav >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> From bclaise@cisco.com Tue Nov 23 23:42:12 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 105E13A68D3 for ; Tue, 23 Nov 2010 23:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.668 X-Spam-Level: X-Spam-Status: No, score=-0.668 tagged_above=-999 required=5 tests=[AWL=-1.902, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, SARE_HTML_URI_LHOST31=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCDZL9SOvQda for ; Tue, 23 Nov 2010 23:42:04 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id A7B113A6989 for ; Tue, 23 Nov 2010 23:42:03 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAO7dHWI006794; Wed, 24 Nov 2010 08:39:17 +0100 (CET) Received: from [10.55.43.54] (ams-bclaise-8715.cisco.com [10.55.43.54]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAO7dEW9013409; Wed, 24 Nov 2010 08:39:14 +0100 (CET) Message-ID: <4CECC122.6090107@cisco.com> Date: Wed, 24 Nov 2010 08:39:14 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Paul Aitken References: <4CDD2A1F.9040804@cisco.com> In-Reply-To: <4CDD2A1F.9040804@cisco.com> Content-Type: multipart/alternative; boundary="------------000208080501020501090109" Cc: IETF IPFIX Working Group , dietz@neclab.eu, Juergen Quittek Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-psamp-mib-02 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 07:42:12 -0000 This is a multi-part message in MIME format. --------------000208080501020501090109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Paul, Thanks for your review, as always. A couple of points addressed in line. I started by acknowledging every editorial changes, then I stop: we will simply trust your English expertise. ;-) > Dear all, > > > > This is the working group last call on draft-ietf-ipfix-psamp-mib-02. > > This draft requires additional editorial work. > > Please find comments inline below. > > Thanks, > P. > > > > Network Working Group T. Dietz, Ed. > > Internet-Draft NEC Europe Ltd. > > Intended status: Standards Track B. Claise > > Expires: May 12, 2011 Cisco Systems, Inc. > > J. Quittek > > NEC Europe Ltd. > > November 8, 2010 > > > > > > Definitions of Managed Objects for Packet Sampling > > > > > > Abstract > > > > This memo defines a portion of the Management Information Base (MIB) > > for use with network management protocols in the Internet community. > > In particular, it describes extensions to the IPFIX MIB module > > [RFC5815]. For IPFIX implementations that use packet sampling > > (PSAMP) techniques as described in [RFC5475], this memo defines the > > PSAMP MIB module containing managed objects for providing information > > on applied packet selection functions and their parameters. > > > > Status of this Memo > > > > This Internet-Draft is submitted in full conformance with the > > provisions of BCP 78 and BCP 79. > > > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF). Note that other groups may also distribute > > working documents as Internet-Drafts. The list of current Internet- > > Drafts is at http://datatracker.ietf.org/drafts/current/. > > > > Internet-Drafts are draft documents valid for a maximum of six months > > and may be updated, replaced, or obsoleted by other documents at any > > time. It is inappropriate to use Internet-Drafts as reference > > material or to cite them other than as "work in progress." > > > > This Internet-Draft will expire on May 12, 2011. > > > > Copyright Notice > > > > Copyright (c) 2010 IETF Trust and the persons identified as the > > document authors. All rights reserved. > > > > This document is subject to BCP 78 and the IETF Trust's Legal > > Provisions Relating to IETF Documents > > (http://trustee.ietf.org/license-info) in effect on the date of > > publication of this document. Please review these documents > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 1] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > carefully, as they describe your rights and restrictions with respect > > to this document. Code Components extracted from this document must > > include Simplified BSD License text as described in Section 4.e of > > the Trust Legal Provisions and are provided without warranty as > > described in the Simplified BSD License. > > > > > > Table of Contents > > > > 1. Open Issues/TODOs . . . . . . . . . . . . . . . . . . . . . . 3 > > > > 2. The Internet-Standard Management Framework . . . . . . . . . . 3 > > > > 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > > > > 4. PSAMP Documents Overview . . . . . . . . . . . . . . . . . . . 4 > > > > 5. Related IPFIX Documents . . . . . . . . . . . . . . . . . . . 4 > > > > 6. Structure of the PSAMP MIB module . . . . . . . . . . . . . . 4 > > 6.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 5 > > 6.2. Packet Selection Functions . . . . . . . . . . . . . . . . 6 > > 6.2.1. Systematic Count-based Sampling . . . . . . . . . . . 6 > > 6.2.2. Systematic Time-based Sampling . . . . . . . . . . . . 6 > > 6.2.3. Random n-out-of-N Sampling . . . . . . . . . . . . . . 7 > > 6.2.4. Uniform Probabilistic Sampling . . . . . . . . . . . . 7 > > 6.2.5. Property Match Filtering . . . . . . . . . . . . . . . 7 > > 6.2.6. Hash-based Filtering . . . . . . . . . . . . . . . . . 8 > > > > 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 > > > > 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 > > > > 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 > > > > 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 26 > > > > 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 > > 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 > > 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 > > > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 > > > > > > > > > > > > > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 2] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > 1. Open Issues/TODOs > > > > o security considerations: check security issues raised by Nick > > Duffield on privacy issues with hash parameters etc. > > I'm surprised to find open issues in WGLC. Oups ;-) > > > > 2. The Internet-Standard Management Framework > > > > For a detailed overview of the documents that describe the current > > Internet-Standard Management Framework, please refer to section 7 of > > RFC 3410 [RFC3410]. > > This format is different from the Abstract, where the title isn't > given (ie, there's no duplication), eg "section 7 of [RFC3410]". > > > > Managed objects are accessed via a virtual information store, termed > > the Management Information Base or MIB. MIB objects are generally > > accessed through the Simple Network Management Protocol (SNMP). > > Objects in the MIB are defined using the mechanisms defined in the > > Structure of Management Information (SMI). This memo specifies MIB > > modules that is compliant to the SMIv2, which is described in STD 58, > > RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58,RFC 2580 > > [RFC2580]. > > Either "a MIB module which is", or "MIB modules which are". This section comes from the boilerplate http://www.ops.ietf.org/mib-boilerplate.html Even if not perfect, I propose to leave it unchanged. > > > > 3. Introduction > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > document are to be interpreted as described in RFC 2119 [RFC2119]. > > > > This document is a product of the IP Flow Information eXport (IPFIX) > > working group. Work on this document was started in the Packet > > Sampling (PSAMP) Working Group (WG) and moved to the IPFIX WG when > > the PSAMP WG was concluded. > > > > Its purpose is to define managed objects for monitoring PSAMP Devices > > performing packet selection by sampling and hashing as described in > > [RFC5475]. > > > > It is assumed that packet sampling is performed according to the > > framework defined in [RFC5474]. > > > > Managed objects in the PSAMP MIB module are defined as an extension > > of the IPFIX MIB module [RFC5815]. Since the IPFIX MIB module is for > > monitoring only the same holds true for the PSAMP MIB module defined > > in this document. The definition of objects is in line with the > > PSAMP information model [RFC5477]. > > "is only for monitoring," Yes. " Section 4 gives an overview of the PSAMP documents, while section 5 refers to the related IPFIX documents" > > > > > > Section 6 describes the structure of the PSAMP MIB module and section > > 7 contains the formal definition. Security issues are discussed in > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 3] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > section 8. > > What about sections 4 and 5? Done above. > > > > 4. PSAMP Documents Overview > > > > [RFC5474]: "A Framework for Packet Selection and Reporting" describes > > the PSAMP framework for network elements to select subsets of packets > > by statistical and other methods, and to export a stream of reports > > on the selected packets to a Collector. > > > > [RFC5475]: "Sampling and Filtering Techniques for IP Packet > > Selection" describes the set of packet selection techniques supported > > by PSAMP. > > > > [RFC5476]: "Packet Sampling (PSAMP) Protocol Specifications" > > specifies the export of packet information from a PSAMP Exporting > > Process to a PSAMP Collecting Process. > > > > [RFC5477]: "Information Model for Packet Sampling Exports" defines an > > information and data model for PSAMP. > > > > This document: "Definitions of Managed Objects for Packet Sampling" > > describes the PSAMP Management Information Base. > > > > > > 5. Related IPFIX Documents > > > > The IPFIX protocol provides network administrators with access to IP > > Flow information. The protocol document [RFC5101] specifies how > > IPFIX Data Records and Templates are carried via a congestion-aware > > transport protocol from IPFIX Exporting Processes to IPFIX Collecting > > Processes. This document also specifies the data types used in this > > MIB module and their encoding. The IPFIX MIB [RFC5815] is the basis > > for this document and is extended by this MIB module. > > Too confusing. I think you mean: > > [RFC5101] also specifies the data types used in this MIB module... I think we refer to the textual convention here. So "this document" is draft-ietf-ipfix-psamp-mib-02 I agree this is slightly confusing. > > > > > > > > 6. Structure of the PSAMP MIB module > > > > The IPFIX MIB module defined in [RFC5815] has the concept of a packet > > selection process containing a set of selector function instances. > > Selection processes and functions are referenced in the > > ipfixSelectionProcessTable of the IPFIX MIB module. This table > > identifies an instance of a selector function by an OID. The OID > > points to an object that describes the selector function. For simple > > selector functions without parameters, the OID refers to an object > > that only contains one more object indicating the current > > I read this several times as "one or more objects...", which doesn't > make sense. > > I suggest: > > "the OID refers to an object that contains only one additional object > indicating ..." > > BTW I keep wanting to change "that" to "which". > > > > availability of this function. For functions that have one or more > > "the". Fine with me. > > > > parameters the object has a subtree that in addition to an > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 4] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > availability object contains a table with a conceptual column for > > each parameter. Entries (conceptual rows) in this table represent > > different combinations of parameter values for instances of the > > selector function. > > > > Object ipfixSelectorFunctions in the IPFIX SELECTOR MIB module serves > > as home for objects that describe instances of packet selector > > "as a home" or "as the home" ? ok. > > > > functions. The IPFIX SELECTOR MIB is a very small module that is > > also defined in [RFC5815]. Objects under ipfixSelectorFunctions are > > Remove "also", because it sounds like a duplicate definition (ie, > defined here and also in RFC 5815). ok. > > > > maintained by IANA. In the IPFIX SELECTOR module object > > ipfixSelectorFunctions contains just a single trivial packet selector > > function called ipfixFuncSelectAll that selects every packet and has > > no parameter: > > > > ipfixSelectorMIB > > +- ipfixSelectorObjects(1) > > +- ipfixSelectorFunctions(1) > > +- ipfixFuncSelectAll(1) > > +- ipfixFuncSelectAllAvail(1) > > > > The PSAMP MIB module defined in this document contains six new > > objects under ipfixSelectorFunctions. Each of them describes a > > packet selector function with one or more parameters. Naming and > > ordering of objects is fully in line with the guidelines given in > > section 6.1 of [RFC5815]. All functions and their parameters are > > already listed in the overview of functions given by the figure in > > section 8.2.1 of [RFC5477]. > > > > In addition, the PSAMP MIB module contains two textual conventions > > that define data types used for parameters in the above tables that > > cannot be expressed by the basic data types defined by [RFC2578], > > unsigned64 and float64. > > Is this the right place to define these for more general use? From the IPFIX meeting minutes Juergen Quittek presented the PSAMP MID draft. This only needed textual conventions for 64-bit unsigned integers and real. The MIB Doctors have provided one for Unsigned64, but we will need to create a new one for IEEE 64-bit floating objects. Dan Romascanu pointed out that our Float64 TC should be general, so that other MIBs can use it. > > > > > > 6.1. Textual Conventions > > > > The MIB module defines one textual conventions that defines a data > > Typo. > > > > type used within this MIB module. Another data type is imported from > > the APPLICATION MIB [RFC2564]. Those data types are defined > > according to [RFC5101]. Those data types are not integral part of > > "not an integral" > > > > [RFC2578] but are needed to define objects in this MIB module that > > conform to the Information Elements defined for those objects in > > [RFC5477]. > > > > The Unsigned64TC textual convention describes an unsigned integer of > > 64 bits. It is imported from the APPLICATION MIB. > > > > The PsampFloat64 textuanl convention describes a double precision > > floating point number. It is encoded accroding to [IEEE.754.1985]. > > Typo x 2. > > > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 5] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > 6.2. Packet Selection Functions > > > > In general, different packet selector functions have different > > parameters. The PSAMP MIB module contains six objects with subtrees > > that provide information on parameters of function instances of > > different selector functions. All objects are named and structured > > according to section 8.2.1 of [RFC5477]: > > > > ipfixSelectorFunctions(1) > > +-- psampSampCountBased(2) > > +- -psampSampTimeBased(3) > > +-- psampSampRandOutOfN(4) > > +-- psampSampUniProb(5) > > +-- psampFiltPropMatch(6) > > +-- psampFiltHash(7) > > Why do you use these strange contracted names, which will surely be > confusing to people whose first language isn't English? > > > > > > Indexing of these functions in the PSAMP MIB module starts with index > > (2). The function ipfixFuncSelectAll with index (1) is already > > defined in the IPFIX SELECTOR MIB module. > > As mentioned in section 6, just above. > > > > > > The object tree for each of these functions is described below. > > Semantics of all functions and their parameters are described in > > detail in [RFC5475]. More information on the Selector Reports can > > also be found in section 6.5.2 of [RFC5476]. > > > > 6.2.1. Systematic Count-based Sampling > > > > The first selector function is systematic count-based sampling. Its > > availability is indicated by object psampSampCountBasedAvail. The > > function has two parameters: psampSampCountBasedInterval and > > psampSampCountBasedSpace. Different combination of values of these > > parameters for different instances of the selector function are > > represented by different conceptual rows in table > > psampSampCountBasedParamSetEntry: > > > > psampSampCountBased(2) > > +-- psampSampCountBasedAvail(1) > > +-- psampSampCountBasedParamSetTable(2) > > +-- psampSampCountBasedParamSetEntry(1) [psampSampCountBasedIndex] > > +-- psampSampCountBasedIndex(1) > > +-- psampSampCountBasedInterval(2) > > +-- psampSampCountBasedSpace(3) > > > > 6.2.2. Systematic Time-based Sampling > > > > The second selector function is systematic time-based sampling. The > > structure of the sub-tree for this function is similar to the > > previous one. Parameters are psampSampTimeBasedInterval and > > Be specific: say "to the psampSampCountBased sub-tree". > > > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 6] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > psampSampTimeBasedSpace. They appear to be the same as for count > > based sampling, but their data types are different because they > > indicate time values instead of numbers of packets: > > > > psampSampTimeBased(3) > > +-- psampSampTimeBasedAvail(1) > > +-- psampSampTimeBasedParamSetTable(2) > > +-- psampSampTimeBasedParamSetEntry(1) [psampSampTimeBasedIndex] > > +-- psampSampTimeBasedIndex(1) > > +-- psampSampTimeBasedInterval(2) > > +-- psampSampTimeBasedSpace(3) > > > > 6.2.3. Random n-out-of-N Sampling > > > > The third selector function is random n-out-of-N sampling. The > > structure of the sub-tree for this function is similar to the > > previous one. Parameters are psampSampRandOutOfNSamplingSize and > > So it's similar to both of the previous ones. > > > > psampSampRandOutOfNPopulation: > > > > psampSampRandOutOfN(4) > > +-- psampSampRandOutOfNAvail(1) > > +-- psampSampRandOutOfNParamSetTable(3) > > Why is this (3) rather than (2) ? Because of 3 below. psampSampRandOutOfNParamSetTable OBJECT-TYPE SYNTAX SEQUENCE OF PsampSampRandOutOfNParamSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists configurations of random n-out-of-N sampling. A parameter set describing a configuration contains a two parameter only, the sampling size and the parent population." ::= { psampSampRandOutOfN 3 } However, there is no entry for "::= { psampSampRandOutOfN 2 }", so you have a good point. > > > > +-- psampSampRandOutOfNParamSetEntry(1) [psampSampRandOutOfNIndex] > > +-- psampSampRandOutOfNIndex(1) > > +-- psampSampRandOutOfNSamplingSize(2) > > +-- psampSampRandOutOfNPopulation(3) > > > > 6.2.4. Uniform Probabilistic Sampling > > > > The fourth selector function is uniform probabilistic sampling. It > > has just a single parameter called psampSampUniProbProbability: > > > > psampSampUniProb(5) > > +-- psampSampUniProbAvail(1) > > +-- psampSampUniProbParamSetTable(3) > > Why is this (3) rather than (2) ? same good point. > > > > +-- psampSampUniProbParamSetEntry(1) [psampSampUniProbIndex] > > +-- psampSampUniProbIndex(1) > > +-- psampSampUniProbProbability(2) > > > > 6.2.5. Property Match Filtering > > > > The fifth selector function is property match filtering. For this > > selector function there is a broad variety of possible parameters > > that could be used. But as stated in section 8.2.1 of [RFC5477] > > there are no agreed parameters specified and the sub-tree for this > > function only contains an object indicating the availability of this > > function. Paameters cannot be retireved via the PSAMP MIB module: > > Typo x 2. > > > > > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 7] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > psampFiltPropMatch(6) > > +-- psampFiltPropMatchAvail(1) > > > > 6.2.6. Hash-based Filtering > > > > The sixth selector function is hash-based filtering. This function > > has more parameters and the actual number may vary with the choice of > > the hash function applied. The common parameter set for all hash- > > based filtering functions contains 7 parameters: > > psampFiltHashInitializerValue, psampFiltHashIpPayloadOffset, > > psampFiltHashIpPayloadSize, psampFiltHashSelectedRangeMin, > > psampFiltHashSelectedRangeMax, psampFiltHashOutputRangeMin, and > > psampFiltHashOutputRangeMax. > > psampFiltHashFunction isn't mentioned? > > > > > > psampFiltHash(7) > > +-- psampFiltHashAvail(1) > > +-- psampFiltHashCapabilities(2) > > +-- psampFiltHashParamSetTable(3) > > +-- psampFiltHashParamSetEntry(1) [psampFiltHashIndex] > > +-- psampFiltHashIndex(1) > > +-- psampFiltHashFunction(2) > > +-- psampFiltHashInitializerValue(3) > > +-- psampFiltHashIpPayloadOffset(4) > > +-- psampFiltHashIpPayloadSize(5) > > +-- psampFiltHashSelectedRangeMin(6) > > +-- psampFiltHashSelectedRangeMax(7) > > +-- psampFiltHashOutputRangeMin(8) > > +-- psampFiltHashOutputRangeMax(9) > > > > Further parameters depend on the applied hash function and are not > > specified within the PSAMP MIB module. > > > > > > 7. Definitions > > > > > > Have you compiled this MIB? > > > > PSAMP-MIB DEFINITIONS ::= BEGIN > > > > IMPORTS > > MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, mib-2 > > FROM SNMPv2-SMI -- RFC2578 > > TEXTUAL-CONVENTION, TruthValue > > FROM SNMPv2-TC -- RFC2579 > > MODULE-COMPLIANCE, OBJECT-GROUP > > FROM SNMPv2-CONF -- RFC2580 > > Unsigned64TC > > FROM APPLICATION-MIB -- RFC2564 > > ipfixSelectorFunctions > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 8] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > FROM IPFIX-SELECTOR-MIB; > > > > psampMIB MODULE-IDENTITY > > LAST-UPDATED "201011081200Z" -- 08 November 2010 > > ORGANIZATION "IETF IPFIX Working Group" > > CONTACT-INFO > > "WG charter: > > http://www.ietf.org/html.charters/ipfix-charter.html > > > > Mailing Lists: > > General Discussion: ipfix@ietf.org > > To Subscribe: http://www1.ietf.org/mailman/listinfo/ipfix > > Archive: > > http://www1.ietf.org/mail-archive/web/ipfix/current/index.html > > > > Editor: > > Thomas Dietz > > NEC Europe Ltd. > > NEC Laboratories Europe > > Network Research Division > > Kurfuersten-Anlage 36 > > 69115 Heidelberg > > Germany > > Phone: +49 6221 4342-128 > > Email: Thomas.Dietz@nw.neclab.eu > > > > Benoit Claise > > Cisco Systems, Inc. > > De Kleetlaan 6a b1 > > Degem 1831 > > Belgium > > Phone: +32 2 704 5622 > > Email: bclaise@cisco.com > > > > Juergen Quittek > > NEC Europe Ltd. > > NEC Laboratories Europe > > Network Research Division > > Kurfuersten-Anlage 36 > > 69115 Heidelberg > > Germany > > Phone: +49 6221 4342-115 > > Email: quittek@nw.neclab.eu" > > DESCRIPTION > > "The PSAMP MIB defines managed objects for packet sampling > > and filtering. > > These objects provide information about managed nodes > > supporting packet sampling, including packet sampling > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 9] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > capabilities, configuration and statistics. > > > > Copyright (c) 2010 IETF Trust and the persons identified as > > the document authors. All rights reserved. This version > > of this MIB module is part of RFC yyyy; see the RFC itself > > for full legal notices" > > -- RFC Ed.: replace yyyy with actual RFC number & remove this notice > > Being buried in the MIB, it's possible, even likely, that this will be > overlooked. > > > > > > -- Revision history > > > > REVISION "201011081200Z" -- 08 November 2010 > > DESCRIPTION > > "Initial version, published as RFC yyyy." > > -- RFC Ed.: replace yyyy with actual RFC number & remove this notice > > > > ::= { mib-2 xxx } > > -- xxx to be assigned by IANA. > > This isn't mentioned in the IANA section. good point. > > > > > > PsampFloat64 ::= TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "Represents the float64 data type and MUST be encoded as > > an IEEE double-precision 64-bit floating point-type, as > > specified in IEEE 754." > > SYNTAX OCTET STRING (SIZE (8)) > > > > -- Top level structure of the MIB > > > > psampObjects OBJECT IDENTIFIER ::= { psampMIB 1 } > > psampConformance OBJECT IDENTIFIER ::= { psampMIB 2 } > > > > > > --================================================================== > > -- Packet selection sampling methods group of objects > > --================================================================== > > > > --================================================================== > > --* Method 1: Systematic count-based Sampling > > --================================================================== > > > > -- Reference: RFC5475, Section 5.1, RFC5476 Section 6.5.2.1 and > > -- RFC5477, Section 8.2 > > psampSampCountBased OBJECT IDENTIFIER > > ::= { ipfixSelectorFunctions 2 } > > > > psampSampCountBasedAvail OBJECT-TYPE > > SYNTAX TruthValue > > MAX-ACCESS read-only > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 10] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > STATUS current > > DESCRIPTION > > "This object indicates the availability of systematic > > count-based sampling at the managed node. > > > > A Selector may be unavailable if it is implemented but > > currently disabled due to e.g., administrative reasons, lack > > of resources or similar." > > DEFVAL { false } > > ::= { psampSampCountBased 1 } > > > > -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ > > > > psampSampCountBasedParamSetTable OBJECT-TYPE > > SYNTAX SEQUENCE OF > > PsampSampCountBasedParamSetEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "This table lists configurations of systematic count-based > > packet sampling. A parameter set describing a > > configuration contains two parameters: the sampling > > interval length and the space." > > Either say "and the sampling interval space", or say "the sampling > interval length and space." > > > > ::= { psampSampCountBased 2 } > > > > psampSampCountBasedParamSetEntry OBJECT-TYPE > > SYNTAX PsampSampCountBasedParamSetEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "Defines an entry in the psampSampCountBasedParamSetTable." > > INDEX { psampSampCountBasedIndex } > > ::= { psampSampCountBasedParamSetTable 1 } > > > > PsampSampCountBasedParamSetEntry ::= > > SEQUENCE { > > psampSampCountBasedIndex Integer32, > > psampSampCountBasedInterval Unsigned32, > > psampSampCountBasedSpace Unsigned32 > > } > > > > psampSampCountBasedIndex OBJECT-TYPE > > SYNTAX Integer32 (1..2147483647) > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The index of this parameter set in the > > psampSampCountBasedParamSetTable.It is used in the > > Spacing. > > > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 11] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > object ipfixSelectionProcessSelectorFunctionentries of > > the ipfixSelectionProcessTable in the IPFIX-MIB as reference > > to this parameter set." > > ::= { psampSampCountBasedParamSetEntry 1 } > > > > psampSampCountBasedInterval OBJECT-TYPE > > SYNTAX Unsigned32 > > UNITS "packets" > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object specifies the number of packets that are > > consecutively sampled. A value of 100 means that 100 > > consecutive packets are sampled." > > REFERENCE > > "RFC5475, Section 5.1 and RFC5477, Section 8.2" > > ::= { psampSampCountBasedParamSetEntry 2 } > > > > psampSampCountBasedSpace OBJECT-TYPE > > SYNTAX Unsigned32 > > UNITS "packets" > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object specifies the number of packets between two > > psampSampCountBasedInterval's. A value of 100 means that > > the next interval starts 100 packets (which are not sampled) > > after the current psampSampCountBasedInterval is over." > > REFERENCE > > "RFC5475, Section 5.1 and RFC5477, Section 8.2" > > ::= { psampSampCountBasedParamSetEntry 3 } > > > > --================================================================== > > --* Method 2: Systematic time-based Sampling > > --================================================================== > > > > -- Reference: RFC5475, Section 5.1, RFC5476 Section 6.5.2.2 and > > -- RFC5477, Section 8.2 > > psampSampTimeBased OBJECT IDENTIFIER > > ::= { ipfixSelectorFunctions 3 } > > > > psampSampTimeBasedAvail OBJECT-TYPE > > SYNTAX TruthValue > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object indicates the availability of systematic > > time-based sampling at the managed node. > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 12] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > A Selector may be unavailable if it is implemented but > > currently disabled due to e.g., administrative reasons, lack > > of resources or similar." > > DEFVAL { false } > > ::= { psampSampTimeBased 1 } > > > > -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ > > > > psampSampTimeBasedParamSetTable OBJECT-TYPE > > SYNTAX SEQUENCE OF > > PsampSampTimeBasedParamSetEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "This table lists configurations of systematic time-based > > packet sampling. A parameter set describing a configuration > > contains two parameters: the sampling interval length and > > the space." > > ::= { psampSampTimeBased 2 } > > > > psampSampTimeBasedParamSetEntry OBJECT-TYPE > > SYNTAX PsampSampTimeBasedParamSetEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "Defines an entry in the psampSampTimeBasedParamSetTable." > > INDEX { psampSampTimeBasedIndex } > > ::= { psampSampTimeBasedParamSetTable 1 } > > > > PsampSampTimeBasedParamSetEntry ::= > > SEQUENCE { > > psampSampTimeBasedIndex Integer32, > > psampSampTimeBasedInterval Unsigned32, > > psampSampTimeBasedSpace Unsigned32 > > } > > > > psampSampTimeBasedIndex OBJECT-TYPE > > SYNTAX Integer32 (1..2147483647) > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The index of this parameter set in the > > psampSampTimeBasedParamSetTable. It is used in the > > object ipfixSelectionProcessSelectorFunctionentries of > > the ipfixSelectionProcessTable in the IPFIX-MIB as reference > > to this parameter set." > > ::= { psampSampTimeBasedParamSetEntry 1 } > > > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 13] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > psampSampTimeBasedInterval OBJECT-TYPE > > SYNTAX Unsigned32 > > UNITS "microseconds" > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object specifies the time interval in microseconds > > during which all arriving packets are sampled." > > This description's indentation is slightly different. > > > > REFERENCE > > "RFC5475, Section 5.1 and RFC5477, Section 8.2" > > ::= { psampSampTimeBasedParamSetEntry 2 } > > > > psampSampTimeBasedSpace OBJECT-TYPE > > SYNTAX Unsigned32 > > UNITS "microseconds" > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object specifies the time interval in microseconds > > between two psampSampTimeBasedInterval's. A value of 100 > > means that the next interval starts 100 microseconds (during > > which no packets are sampled) after the current > > psampSampTimeBasedInterval is over." > > REFERENCE > > "RFC5475, Section 5.1 and RFC5477, Section 8.2" > > ::= { psampSampTimeBasedParamSetEntry 3 } > > > > --================================================================== > > --* Method 3: Random n-out-of-N Sampling > > --================================================================== > > > > -- Reference: RFC5475, Section 5.2.1, RFC5476 Section 6.5.2.3 and > > -- RFC5477, Section 8.2 > > psampSampRandOutOfN OBJECT IDENTIFIER > > ::= { ipfixSelectorFunctions 4 } > > > > psampSampRandOutOfNAvail OBJECT-TYPE > > SYNTAX TruthValue > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object indicates the availability of random n-out-of-N > > sampling at the managed node. > > > > A Selector may be unavailable if it is implemented but > > currently disabled due to e.g., administrative reasons, lack > > of resources or similar." > > DEFVAL { false } > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 14] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > ::= { psampSampRandOutOfN 1 } > > > > -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ > > > > psampSampRandOutOfNParamSetTable OBJECT-TYPE > > SYNTAX SEQUENCE OF > > PsampSampRandOutOfNParamSetEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "This table lists configurations of random n-out-of-N > > sampling. A parameter set describing a configuration > > contains a two parameter only, the sampling size and the > > parent population." > > ::= { psampSampRandOutOfN 3 } > > > > psampSampRandOutOfNParamSetEntry OBJECT-TYPE > > SYNTAX PsampSampRandOutOfNParamSetEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "Defines an entry in the psampSampRandOutOfNParamSetTable." > > INDEX { psampSampRandOutOfNIndex } > > ::= { psampSampRandOutOfNParamSetTable 1 } > > > > PsampSampRandOutOfNParamSetEntry ::= > > SEQUENCE { > > psampSampRandOutOfNIndex Integer32, > > psampSampRandOutOfNSamplingSize Unsigned32, > > psampSampRandOutOfNPopulation Unsigned32 > > } > > > > psampSampRandOutOfNIndex OBJECT-TYPE > > SYNTAX Integer32 (1..2147483647) > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The index of this parameter set in the > > psampSampRandOutOfNParamSetTable. It is used in the > > object ipfixSelectionProcessSelectorFunctionentries of > > the ipfixSelectionProcessTable in the IPFIX-MIB as reference > > to this parameter set." > > ::= { psampSampRandOutOfNParamSetEntry 1 } > > > > psampSampRandOutOfNSamplingSize OBJECT-TYPE > > SYNTAX Unsigned32 > > UNITS "packets" > > MAX-ACCESS read-only > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 15] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > STATUS current > > DESCRIPTION > > "This object specifies the number of elements taken from the > > parent Populationfor specified in > > Remove "for". > > > > psampSampRandOutOfNPopulation." > > REFERENCE > > "RFC5475, Section 5.2.1 and RFC5477, Section 8.2" > > ::= { psampSampRandOutOfNParamSetEntry 2 } > > > > psampSampRandOutOfNPopulation OBJECT-TYPE > > SYNTAX Unsigned32 > > UNITS "packets" > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object specifies the number of elements in the parent > > Population." > > This description's indentation is slightly different. > > > > REFERENCE > > "RFC5475, Section 5.2.1 and RFC5477, Section 8.2" > > ::= { psampSampRandOutOfNParamSetEntry 3 } > > > > --================================================================== > > --* Method 4: Uniform probabilistic Sampling > > --================================================================== > > > > -- Reference: RFC5475, Section 5.2.2, RFC5476 Section 6.5.2.4 and > > -- RFC5477, Section 8.2 > > psampSampUniProb OBJECT IDENTIFIER ::= { ipfixSelectorFunctions 5 } > > > > psampSampUniProbAvail OBJECT-TYPE > > SYNTAX TruthValue > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object indicates the availability of random uniform > > probabilistic sampling at the managed node. > > > > A Selector may be unavailable if it is implemented but > > currently disabled due to e.g., administrative reasons, lack > > of resources or similar." > > DEFVAL { false } > > ::= { psampSampUniProb 1 } > > > > -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ > > > > -- Reference: RFC5475, Section 5.2.2.1 and RFC5477, Section 8.2 > > psampSampUniProbParamSetTable OBJECT-TYPE > > SYNTAX SEQUENCE OF > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 16] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > PsampSampUniProbParamSetEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "This table lists configurations of random probabilistic > > sampling. A parameter set describing a configuration > > contains a single parameter only: the sampling probability." > > ::= { psampSampUniProb 3 } > > > > psampSampUniProbParamSetEntry OBJECT-TYPE > > SYNTAX PsampSampUniProbParamSetEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "Defines an entry in the psampSampUniProbParamSetTable." > > INDEX { psampSampUniProbIndex } > > ::= { psampSampUniProbParamSetTable 1 } > > > > PsampSampUniProbParamSetEntry ::= > > SEQUENCE { > > psampSampUniProbIndex Integer32, > > psampSampUniProbProbability PsampFloat64 > > } > > > > psampSampUniProbIndex OBJECT-TYPE > > SYNTAX Integer32 (1..2147483647) > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The index of this parameter set in the > > The indentation of the first line of this description is slightly > different. > > > > psampSampUniProbParamSetTable. It is used in the > > object ipfixSelectionProcessSelectorFunctionentries of > > the ipfixSelectionProcessTable in the IPFIX-MIB as reference > > to this parameter set." > > ::= { psampSampUniProbParamSetEntry 1 } > > > > psampSampUniProbProbability OBJECT-TYPE > > SYNTAX PsampFloat64 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object specifies the probability that a packet is > > sampled, expressed as a value between 0 and 1. The > > probability is equal for every packet. A value of 0 means > > no packet was sampled since the probability is 0. A value > > of 1 means all packets were sampled since the > > probability is 1." > > REFERENCE > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 17] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > "RFC5475, Section 5.2.2.1 and RFC5477, Section 8.2" > > ::= { psampSampUniProbParamSetEntry 2 } > > > > --================================================================== > > -- Packet selection filtering methods group of objects > > --================================================================== > > > > --================================================================== > > --* Method 5: Property Match filtering > > --================================================================== > > > > -- Reserves Method 5 (see RFC5475, Section 6.1, RFC5476 > > -- Section 6.5.2.5 and RFC5477) > > psampFiltPropMatch OBJECT IDENTIFIER > > ::= { ipfixSelectorFunctions 6 } > > > > psampFiltPropMatchAvail OBJECT-TYPE > > SYNTAX TruthValue > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object indicates the availability of property match > > filtering at the managed node. > > > > A Selector may be unavailable if it is implemented but > > currently disabled due to e.g., administrative reasons, lack > > of resources or similar." > > DEFVAL { false } > > ::= { psampFiltPropMatch 1 } > > > > --================================================================== > > --* Method 1: Hash filtering > > Typo: it's method 6. > > > > --================================================================== > > > > -- Reference: RFC5475, Section 6.2, RFC5476 Section 6.5.2.6 and > > -- RFC5477, Section 8.3 > > psampFiltHash OBJECT IDENTIFIER ::= { ipfixSelectorFunctions 7 } > > > > psampFiltHashAvail OBJECT-TYPE > > SYNTAX TruthValue > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object indicates the availability of hash filtering > > at the managed node. > > > > A Selector may be unavailable if it is implemented but > > currently disabled due to e.g., administrative reasons, lack > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 18] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > of resources or similar." > > DEFVAL { false } > > ::= { psampFiltHash 1 } > > > > psampFiltHashCapabilities OBJECT IDENTIFIER > > ::= { psampFiltHash 2 } > > > > -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ > > > > -- Reference: RFC5475, Sections 6.2, 3.8, and 7.1 > > psampFiltHashParamSetTable OBJECT-TYPE > > SYNTAX SEQUENCE OF > > PsampFiltHashParamSetEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "This table lists configurations of hash filtering. A > > parameter set describing a configuration contains eight > > parameter describing the hash function." > > ::= { psampFiltHash 3 } > > > > psampFiltHashParamSetEntry OBJECT-TYPE > > SYNTAX PsampFiltHashParamSetEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "Defines an entry in the psampFiltHashParamSetTable." > > INDEX { psampFiltHashIndex } > > ::= { psampFiltHashParamSetTable 1 } > > > > PsampFiltHashParamSetEntry ::= > > SEQUENCE { > > psampFiltHashIndex Integer32, > > psampFiltHashFunction INTEGER, > > psampFiltHashInitializerValue Unsigned64TC, > > psampFiltHashIpPayloadOffset Unsigned64TC, > > psampFiltHashIpPayloadSize Unsigned64TC, > > psampFiltHashSelectedRangeMin Unsigned64TC, > > psampFiltHashSelectedRangeMax Unsigned64TC, > > psampFiltHashOutputRangeMin Unsigned64TC, > > psampFiltHashOutputRangeMax Unsigned64TC > > } > > > > psampFiltHashIndex OBJECT-TYPE > > SYNTAX Integer32 (1..2147483647) > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 19] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > "The index of this parameter set in the > > psampFiltHashParamSetTable. It is used in the > > object ipfixSelectionProcessSelectorFunctionentries of > > the ipfixSelectionProcessTable in the IPFIX-MIB as reference > > to this parameter set." > > ::= { psampFiltHashParamSetEntry 1 } > > > > psampFiltHashFunction OBJECT-TYPE > > SYNTAX INTEGER { > > crc32(1), > > ipsx(2), > > bob(3) > > } > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The Hash Function used by this filter. The PSAMP-MIB > > supports the following Hash Functions: > > > > crc32(1) > > > > ipsx(2) > > > > bob(3) > > " > > ::= { psampFiltHashParamSetEntry 2 } > > > > psampFiltHashInitializerValue OBJECT-TYPE > > SYNTAX Unsigned64TC > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object specifies the initializer value to the hash > > function." > > REFERENCE > > "RFC5475, Sections 6.2, 3.8, and 7.1" > > ::= { psampFiltHashParamSetEntry 3 } > > > > psampFiltHashIpPayloadOffset OBJECT-TYPE > > SYNTAX Unsigned64TC > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object specifies the IP payload offset used by a > > Hash-based Selection Selector." > > REFERENCE > > "RFC5475, Sections 6.2, 3.8, and 7.1" > > ::= { psampFiltHashParamSetEntry 4 } > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 20] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > psampFiltHashIpPayloadSize OBJECT-TYPE > > SYNTAX Unsigned64TC > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object specifies the IP payload size used by a > > Hash-based Selection Selector." > > REFERENCE > > "RFC5475, Sections 6.2, 3.8, and 7.1" > > ::= { psampFiltHashParamSetEntry 5 } > > > > psampFiltHashSelectedRangeMin OBJECT-TYPE > > SYNTAX Unsigned64TC > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object specifies the value for the beginning of a hash > > function's selected range." > > REFERENCE > > "RFC5475, Sections 6.2, 3.8, and 7.1" > > ::= { psampFiltHashParamSetEntry 6 } > > > > psampFiltHashSelectedRangeMax OBJECT-TYPE > > SYNTAX Unsigned64TC > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object specifies the value for the end of a hash > > function's selected range." > > REFERENCE > > "RFC5475, Sections 6.2, 3.8, and 7.1" > > ::= { psampFiltHashParamSetEntry 7 } > > > > psampFiltHashOutputRangeMin OBJECT-TYPE > > SYNTAX Unsigned64TC > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object specifies the value for the beginning of a hash > > function's potential output range." > > REFERENCE > > "RFC5475, Sections 6.2, 3.8, and 7.1" > > ::= { psampFiltHashParamSetEntry 8 } > > > > psampFiltHashOutputRangeMax OBJECT-TYPE > > SYNTAX Unsigned64TC > > MAX-ACCESS read-only > > STATUS current > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 21] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > DESCRIPTION > > "This object specifies the value for the end of a hash > > function's potential output range." > > REFERENCE > > "RFC5475, Sections 6.2, 3.8, and 7.1" > > ::= { psampFiltHashParamSetEntry 9 } > > > > --================================================================== > > -- Conformance information > > --================================================================== > > > > psampCompliances OBJECT IDENTIFIER ::= { psampConformance 1 } > > psampGroups OBJECT IDENTIFIER ::= { psampConformance 2 } > > > > --================================================================== > > -- Compliance statements > > --================================================================== > > > > psampCompliance MODULE-COMPLIANCE > > STATUS current > > DESCRIPTION > > "The implementation of all objects is optional and depends > > on the implementation of the corresponding functionality in > > the equipment." > > MODULE -- this module > > GROUP psampGroupSampCountBased > > DESCRIPTION > > "These objects must be implemented if the corresponding > > sampling function is implemented in the equipment." > > GROUP psampGroupSampTimeBased > > DESCRIPTION > > "These objects must be implemented if the corresponding > > sampling function is implemented in the equipment." > > GROUP psampGroupSampRandOutOfN > > DESCRIPTION > > "These objects must be implemented if the corresponding > > sampling function is implemented in the equipment." > > GROUP psampGroupSampUniProb > > DESCRIPTION > > "These objects must be implemented if the corresponding > > sampling function is implemented in the equipment." > > GROUP psampGroupFiltPropMatch > > DESCRIPTION > > "These objects must be implemented if the corresponding > > filter function is implemented in the equipment." > > GROUP psampGroupFiltHash > > DESCRIPTION > > "These objects must be implemented if the corresponding > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 22] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > filter function is implemented in the equipment." > > ::= { psampCompliances 1 } > > > > --================================================================== > > -- MIB groupings > > --================================================================== > > > > The indentation of all the descriptions below is slightly different > from the previous descriptions above. > > > > psampGroupSampCountBased OBJECT-GROUP > > OBJECTS { > > psampSampCountBasedAvail, > > psampSampCountBasedInterval, > > psampSampCountBasedSpace > > } > > STATUS current > > DESCRIPTION > > "These objects are needed if count based sampling is > > implemented." > > ::= { psampGroups 2 } > > > > psampGroupSampTimeBased OBJECT-GROUP > > OBJECTS { > > psampSampTimeBasedAvail, > > psampSampTimeBasedInterval, > > psampSampTimeBasedSpace > > } > > STATUS current > > DESCRIPTION > > "These objects are needed if time based sampling is > > implemented." > > ::= { psampGroups 3 } > > > > psampGroupSampRandOutOfN OBJECT-GROUP > > OBJECTS { > > psampSampRandOutOfNAvail, > > psampSampRandOutOfNSamplingSize, > > psampSampRandOutOfNPopulation > > } > > STATUS current > > DESCRIPTION > > "These objects are needed if random n-out-of-N sampling is > > implemented." > > ::= { psampGroups 4 } > > > > psampGroupSampUniProb OBJECT-GROUP > > OBJECTS { > > psampSampUniProbAvail, > > psampSampUniProbProbability > > } > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 23] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > STATUS current > > DESCRIPTION > > "These objects are needed if uniform probabilistic sampling > > is implemented." > > ::= { psampGroups 5 } > > > > psampGroupFiltPropMatch OBJECT-GROUP > > OBJECTS { > > psampFiltPropMatchAvail > > } > > STATUS current > > DESCRIPTION > > "These objects are needed if property match filtering is > > implemented." > > ::= { psampGroups 6 } > > > > psampGroupFiltHash OBJECT-GROUP > > OBJECTS { > > psampFiltHashAvail, > > psampFiltHashFunction, > > psampFiltHashInitializerValue, > > psampFiltHashIpPayloadOffset, > > psampFiltHashIpPayloadSize, > > psampFiltHashSelectedRangeMin, > > psampFiltHashSelectedRangeMax, > > psampFiltHashOutputRangeMin, > > psampFiltHashOutputRangeMax > > } > > STATUS current > > DESCRIPTION > > "These objects are needed if hash filtering is implemented." > > ::= { psampGroups 9 } > > "psampGroups 7". > > > > > > END > > > > > > 8. Security Considerations > > > > There are no management objects defined in this MIB module that have > > a MAX-ACCESS clause of read-write and/or read-create. So, if this > > MIB module is implemented correctly, then there is no risk that an > > intruder can alter or create any management objects of this MIB > > module via direct SNMP SET operations. > > > > Some of the readable objects in this MIB module (i.e., objects with a > > See below. > > > > MAX-ACCESS other than not-accessible) may be considered sensitive or > > vulnerable in some network environments. It is thus important to > > control even GET and/or NOTIFY access to these objects and possibly > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 24] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > to even encrypt the values of these objects when sending them over > > the network via SNMP. These are the tables and objects and their > > sensitivity/vulnerability: > > > > o All tables - they contain configuration data that might be > > sensitive because objects in this table may reveal information > > about the network infrastructure and device configuration > > >From "Some of" to here, why not just say: > > All tables in this MIB modulemay be considered sensitive or vulnerable > in some network environmentsbecause objects in the tables may reveal > information > about the network infrastructure and device configuration.It is thus > important to > control even GET and/or NOTIFY access to these objects and possibly > to even encrypt the values of these objects when sending them over > the network via SNMP. Yes we should be consistent. > > > > > > SNMP versions prior to SNMPv3 did not include adequate security. > > Even if the network itself is secure (for example by using IPsec), > > there is no control as to who on the secure network is allowed to > > access and GET/SET (read/change/create/delete) the objects in this > > MIB module. > > > > It is RECOMMENDED that implementers consider the security features as > > Remove "as". > > > > provided by the SNMPv3 framework (see [RFC3410], section 8), > > including full support for the SNMPv3 cryptographic mechanisms (for > > authentication and privacy). > > > > Further, deployment of SNMP versions prior to SNMPv3 is NOT > > RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to > > enable cryptographic security. It is then a customer/operator > > responsibility to ensure that the SNMP entity giving access to an > > instance of this MIB module is properly configured to give access to > > the objects only to those principals (users) that have legitimate > > Users are people, so use "who". > > > > rights to indeed GET or SET (change/create/delete) them. > > Remove "indeed". > > > > 9. IANA Considerations > > > > The MIB module in this document uses the following IANA-assigned > > OBJECT IDENTIFIER values recorded in the SMI Numbers registry: > > > > Descriptor OBJECT IDENTIFIER value > > ---------- ----------------------- > > psampMIB { mib-2 xxx } > > Clearly specify that xxx must be assigned by IANA and also written > into the MIB in section 7. yes. Thanks for the detailed review > > > Thanks, > P. > > > > psampSampCountBased { ipfixSelectorFunctions 2 } > > psampSampTimeBased { ipfixSelectorFunctions 3 } > > psampSampRandOutOfN { ipfixSelectorFunctions 4 } > > psampSampUniProb { ipfixSelectorFunctions 5 } > > psampFiltPropMatch { ipfixSelectorFunctions 6 } > > psampFiltHash { ipfixSelectorFunctions 7 } > > > > Other than that this document does not impose any IANA > > considerations. > > > > > > > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 25] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > 10. Acknowledgment > > > > This document is a product of the PSAMP and IPFIX working groups. > > > > > > 11. References > > > > 11.1. Normative References > > > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > > Requirement Levels", BCP 14, RFC 2119, March 1997. > > > > [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. > > Schoenwaelder, Ed., "Structure of Management Information > > Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. > > > > [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. > > Schoenwaelder, Ed., "Textual Conventions for SMIv2", > > STD 58, RFC 2579, April 1999. > > > > [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, > > "Conformance Statements for SMIv2", STD 58, RFC 2580, > > April 1999. > > > > [RFC2564] Kalbfleisch, C., Krupczak, C., Presuhn, R., and J. > > Saperia, "Application Management MIB", RFC 2564, May 1999. > > > > [RFC5101] Claise, B., "Specification of the IP Flow Information > > Export (IPFIX) Protocol for the Exchange of IP Traffic > > Flow Information", RFC 5101, January 2008. > > > > [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. > > Carle, "Information Model for Packet Sampling Exports", > > RFC 5477, March 2009. > > > > [RFC5815] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, > > "Definitions of Managed Objects for IP Flow Information > > Export", RFC 5815, April 2010. > > > > [IEEE.754.1985] > > Institute of Electrical and Electronics Engineers, > > "Standard for Binary Floating-Point Arithmetic", > > IEEE Standard 754, August 1985. > > > > 11.2. Informative References > > > > [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, > > "Introduction and Applicability Statements for Internet- > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 26] > > > > Internet-Draft PSAMP MIB November 2010 > > > > > > Standard Management Framework", RFC 3410, December 2002. > > > > [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., > > Grossglauser, M., and J. Rexford, "A Framework for Packet > > Selection and Reporting", RFC 5474, March 2009. > > > > [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. > > Raspall, "Sampling and Filtering Techniques for IP Packet > > Selection", RFC 5475, March 2009. > > > > [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling > > (PSAMP) Protocol Specifications", RFC 5476, March 2009. > > > > > > Authors' Addresses > > > > Thomas Dietz (editor) > > NEC Europe Ltd. > > NEC Laboratories Europe > > Kurfuersten-Anlage 36 > > Heidelberg 69115 > > DE > > > > Phone: +49 6221 4342-128 > > Email: dietz@neclab.eu > > > > > > Benoit Claise > > Cisco Systems, Inc. > > De Kleetlaan 6a b1 > > Degem 1831 > > BE > > > > Phone: +32 2 704 5622 > > Email: bclaise@cisco.com > > > > > > Juergen Quittek > > NEC Europe Ltd. > > NEC Laboratories Europe > > Kurfuersten-Anlage 36 > > Heidelberg 69115 > > DE > > > > Phone: +49 6221 4342-115 > > Email: quittek@neclab.eu > > > > > > > > > > > > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 27] > > > > > --------------000208080501020501090109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Paul,

Thanks for your review, as always.
A couple of points addressed in line. I started by acknowledging every editorial changes, then I stop: we will simply trust your English expertise. ;-)


Dear all,


> This is the working group last call on draft-ietf-ipfix-psamp-mib-02.

This draft requires additional editorial work.

Please find comments inline below.

Thanks,
P.


> Network Working Group                                      T. Dietz, Ed.
> Internet-Draft                                           NEC Europe Ltd.
> Intended status: Standards Track                               B. Claise
> Expires: May 12, 2011                                Cisco Systems, Inc.
>                                                               J. Quittek
>                                                          NEC Europe Ltd.
>                                                         November 8, 2010
>
>
>            Definitions of Managed Objects for Packet Sampling
>                   <draft-ietf-ipfix-psamp-mib-02.txt>
>
> Abstract
>
>    This memo defines a portion of the Management Information Base (MIB)
>    for use with network management protocols in the Internet community.
>    In particular, it describes extensions to the IPFIX MIB module
>    [RFC5815].  For IPFIX implementations that use packet sampling
>    (PSAMP) techniques as described in [RFC5475], this memo defines the
>    PSAMP MIB module containing managed objects for providing information
>    on applied packet selection functions and their parameters.
>
> Status of this Memo
>
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    This Internet-Draft will expire on May 12, 2011.
>
> Copyright Notice
>
>    Copyright (c) 2010 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt           [Page 1]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>    carefully, as they describe your rights and restrictions with respect
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
>
>
> Table of Contents
>
>    1.  Open Issues/TODOs  . . . . . . . . . . . . . . . . . . . . . .  3
>
>    2.  The Internet-Standard Management Framework . . . . . . . . . .  3
>
>    3.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
>
>    4.  PSAMP Documents Overview . . . . . . . . . . . . . . . . . . .  4
>
>    5.  Related IPFIX Documents  . . . . . . . . . . . . . . . . . . .  4
>
>    6.  Structure of the PSAMP MIB module  . . . . . . . . . . . . . .  4
>      6.1.  Textual Conventions  . . . . . . . . . . . . . . . . . . .  5
>      6.2.  Packet Selection Functions . . . . . . . . . . . . . . . .  6
>        6.2.1.  Systematic Count-based Sampling  . . . . . . . . . . .  6
>        6.2.2.  Systematic Time-based Sampling . . . . . . . . . . . .  6
>        6.2.3.  Random n-out-of-N Sampling . . . . . . . . . . . . . .  7
>        6.2.4.  Uniform Probabilistic Sampling . . . . . . . . . . . .  7
>        6.2.5.  Property Match Filtering . . . . . . . . . . . . . . .  7
>        6.2.6.  Hash-based Filtering . . . . . . . . . . . . . . . . .  8
>
>    7.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  8
>
>    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
>
>    9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
>
>    10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 26
>
>    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
>      11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
>      11.2. Informative References . . . . . . . . . . . . . . . . . . 26
>
>    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
>
>
>
>
>
>
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt           [Page 2]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
> 1.  Open Issues/TODOs
>
>    o  security considerations: check security issues raised by Nick
>       Duffield on privacy issues with hash parameters etc.

I'm surprised to find open issues in WGLC.
Oups ;-)


> 2.  The Internet-Standard Management Framework
>
>    For a detailed overview of the documents that describe the current
>    Internet-Standard Management Framework, please refer to section 7 of
>    RFC 3410 [RFC3410].

This format is different from the Abstract, where the title isn't given (ie, there's no duplication), eg "section 7 of [RFC3410]".


>    Managed objects are accessed via a virtual information store, termed
>    the Management Information Base or MIB.  MIB objects are generally
>    accessed through the Simple Network Management Protocol (SNMP).
>    Objects in the MIB are defined using the mechanisms defined in the
>    Structure of Management Information (SMI).  This memo specifies MIB
>    modules that is compliant to the SMIv2, which is described in STD 58,
>    RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58,RFC 2580
>    [RFC2580].

Either "a MIB module which is", or "MIB modules which are".
This section comes from the boilerplate http://www.ops.ietf.org/mib-boilerplate.html
Even if not perfect, I propose to leave it unchanged.


> 3.  Introduction
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in RFC 2119 [RFC2119].
>
>    This document is a product of the IP Flow Information eXport (IPFIX)
>    working group.  Work on this document was started in the Packet
>    Sampling (PSAMP) Working Group (WG) and moved to the IPFIX WG when
>    the PSAMP WG was concluded.
>
>    Its purpose is to define managed objects for monitoring PSAMP Devices
>    performing packet selection by sampling and hashing as described in
>    [RFC5475].
>
>    It is assumed that packet sampling is performed according to the
>    framework defined in [RFC5474].
>
>    Managed objects in the PSAMP MIB module are defined as an extension
>    of the IPFIX MIB module [RFC5815].  Since the IPFIX MIB module is for
>    monitoring only the same holds true for the PSAMP MIB module defined
>    in this document.  The definition of objects is in line with the
>    PSAMP information model [RFC5477].

"is only for monitoring,"
Yes.
" Section 4 gives an overview of the PSAMP documents, while section 5 refers to  the related IPFIX documents"


>
>    Section 6 describes the structure of the PSAMP MIB module and section
>    7 contains the formal definition.  Security issues are discussed in
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt           [Page 3]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>    section 8.

What about sections 4 and 5?
Done above.


> 4.  PSAMP Documents Overview
>
>    [RFC5474]: "A Framework for Packet Selection and Reporting" describes
>    the PSAMP framework for network elements to select subsets of packets
>    by statistical and other methods, and to export a stream of reports
>    on the selected packets to a Collector.
>
>    [RFC5475]: "Sampling and Filtering Techniques for IP Packet
>    Selection" describes the set of packet selection techniques supported
>    by PSAMP.
>
>    [RFC5476]: "Packet Sampling (PSAMP) Protocol Specifications"
>    specifies the export of packet information from a PSAMP Exporting
>    Process to a PSAMP Collecting Process.
>
>    [RFC5477]: "Information Model for Packet Sampling Exports" defines an
>    information and data model for PSAMP.
>
>    This document: "Definitions of Managed Objects for Packet Sampling"
>    describes the PSAMP Management Information Base.
>
>
> 5.  Related IPFIX Documents
>
>    The IPFIX protocol provides network administrators with access to IP
>    Flow information.  The protocol document [RFC5101] specifies how
>    IPFIX Data Records and Templates are carried via a congestion-aware
>    transport protocol from IPFIX Exporting Processes to IPFIX Collecting
>    Processes.  This document also specifies the data types used in this
>    MIB module and their encoding.  The IPFIX MIB [RFC5815] is the basis
>    for this document and is extended by this MIB module.

Too confusing. I think you mean:

  [RFC5101] also specifies the data types used in this MIB module...
I think we refer to the textual convention here. So "this document" is  draft-ietf-ipfix-psamp-mib-02
I agree this is slightly confusing.


>
>
> 6.  Structure of the PSAMP MIB module
>
>    The IPFIX MIB module defined in [RFC5815] has the concept of a packet
>    selection process containing a set of selector function instances.
>    Selection processes and functions are referenced in the
>    ipfixSelectionProcessTable of the IPFIX MIB module.  This table
>    identifies an instance of a selector function by an OID.  The OID
>    points to an object that describes the selector function.  For simple
>    selector functions without parameters, the OID refers to an object
>    that only contains one more object indicating the current

I read this several times as "one or more objects...", which doesn't make sense.

I suggest:

 "the OID refers to an object that contains only one additional object indicating ..."

BTW I keep wanting to change "that" to "which".


>    availability of this function.  For functions that have one or more

"the".
Fine with me.


>    parameters the object has a subtree that in addition to an
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt           [Page 4]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>    availability object contains a table with a conceptual column for
>    each parameter.  Entries (conceptual rows) in this table represent
>    different combinations of parameter values for instances of the
>    selector function.
>
>    Object ipfixSelectorFunctions in the IPFIX SELECTOR MIB module serves
>    as home for objects that describe instances of packet selector

"as a home" or "as the home" ?
ok.


>    functions.  The IPFIX SELECTOR MIB is a very small module that is
>    also defined in [RFC5815].  Objects under ipfixSelectorFunctions are

Remove "also", because it sounds like a duplicate definition (ie, defined here and also in RFC 5815).
ok.


>    maintained by IANA.  In the IPFIX SELECTOR module object
>    ipfixSelectorFunctions contains just a single trivial packet selector
>    function called ipfixFuncSelectAll that selects every packet and has
>    no parameter:
>
>    ipfixSelectorMIB
>    +- ipfixSelectorObjects(1)
>       +- ipfixSelectorFunctions(1)
>          +- ipfixFuncSelectAll(1)
>             +- ipfixFuncSelectAllAvail(1)
>
>    The PSAMP MIB module defined in this document contains six new
>    objects under ipfixSelectorFunctions.  Each of them describes a
>    packet selector function with one or more parameters.  Naming and
>    ordering of objects is fully in line with the guidelines given in
>    section 6.1 of [RFC5815].  All functions and their parameters are
>    already listed in the overview of functions given by the figure in
>    section 8.2.1 of [RFC5477].
>
>    In addition, the PSAMP MIB module contains two textual conventions
>    that define data types used for parameters in the above tables that
>    cannot be expressed by the basic data types defined by [RFC2578],
>    unsigned64 and float64.

Is this the right place to define these for more general use?
From the IPFIX meeting minutes

Juergen Quittek presented the PSAMP MID draft.  This only needed
textual conventions for 64-bit unsigned integers and real.  The MIB
Doctors have provided one for Unsigned64, but we will need to create a
new one for IEEE 64-bit floating objects.  Dan Romascanu pointed out
that our Float64 TC should be general, so that other MIBs can use it.



>
> 6.1.  Textual Conventions
>
>    The MIB module defines one textual conventions that defines a data

Typo.


>    type used within this MIB module.  Another data type is imported from
>    the APPLICATION MIB [RFC2564].  Those data types are defined
>    according to [RFC5101].  Those data types are not integral part of

"not an integral"


>    [RFC2578] but are needed to define objects in this MIB module that
>    conform to the Information Elements defined for those objects in
>    [RFC5477].
>
>    The Unsigned64TC textual convention describes an unsigned integer of
>    64 bits.  It is imported from the APPLICATION MIB.
>
>    The PsampFloat64 textuanl convention describes a double precision
>    floating point number.  It is encoded accroding to [IEEE.754.1985].

Typo x 2.


>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt           [Page 5]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
> 6.2.  Packet Selection Functions
>
>    In general, different packet selector functions have different
>    parameters.  The PSAMP MIB module contains six objects with subtrees
>    that provide information on parameters of function instances of
>    different selector functions.  All objects are named and structured
>    according to section 8.2.1 of [RFC5477]:
>
>    ipfixSelectorFunctions(1)
>    +-- psampSampCountBased(2)
>    +- -psampSampTimeBased(3)
>    +-- psampSampRandOutOfN(4)
>    +-- psampSampUniProb(5)
>    +-- psampFiltPropMatch(6)
>    +-- psampFiltHash(7)

Why do you use these strange contracted names, which will surely be confusing to people whose first language isn't English?


>
>    Indexing of these functions in the PSAMP MIB module starts with index
>    (2).  The function ipfixFuncSelectAll with index (1) is already
>    defined in the IPFIX SELECTOR MIB module.

As mentioned in section 6, just above.


>
>    The object tree for each of these functions is described below.
>    Semantics of all functions and their parameters are described in
>    detail in [RFC5475].  More information on the Selector Reports can
>    also be found in section 6.5.2 of [RFC5476].
>
> 6.2.1.  Systematic Count-based Sampling
>
>    The first selector function is systematic count-based sampling.  Its
>    availability is indicated by object psampSampCountBasedAvail.  The
>    function has two parameters: psampSampCountBasedInterval and
>    psampSampCountBasedSpace.  Different combination of values of these
>    parameters for different instances of the selector function are
>    represented by different conceptual rows in table
>    psampSampCountBasedParamSetEntry:
>
>    psampSampCountBased(2)
>    +-- psampSampCountBasedAvail(1)
>    +-- psampSampCountBasedParamSetTable(2)
>       +-- psampSampCountBasedParamSetEntry(1) [psampSampCountBasedIndex]
>          +-- psampSampCountBasedIndex(1)
>          +-- psampSampCountBasedInterval(2)
>          +-- psampSampCountBasedSpace(3)
>
> 6.2.2.  Systematic Time-based Sampling
>
>    The second selector function is systematic time-based sampling.  The
>    structure of the sub-tree for this function is similar to the
>    previous one.  Parameters are psampSampTimeBasedInterval and

Be specific: say "to the psampSampCountBased sub-tree".


>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt           [Page 6]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>    psampSampTimeBasedSpace.  They appear to be the same as for count
>    based sampling, but their data types are different because they
>    indicate time values instead of numbers of packets:
>
>    psampSampTimeBased(3)
>    +-- psampSampTimeBasedAvail(1)
>    +-- psampSampTimeBasedParamSetTable(2)
>       +-- psampSampTimeBasedParamSetEntry(1) [psampSampTimeBasedIndex]
>          +-- psampSampTimeBasedIndex(1)
>          +-- psampSampTimeBasedInterval(2)
>          +-- psampSampTimeBasedSpace(3)
>
> 6.2.3.  Random n-out-of-N Sampling
>
>    The third selector function is random n-out-of-N sampling.  The
>    structure of the sub-tree for this function is similar to the
>    previous one.  Parameters are psampSampRandOutOfNSamplingSize and

So it's similar to both of the previous ones.


>    psampSampRandOutOfNPopulation:
>
>    psampSampRandOutOfN(4)
>    +-- psampSampRandOutOfNAvail(1)
>    +-- psampSampRandOutOfNParamSetTable(3)

Why is this (3) rather than (2) ?
Because of 3 below.
   psampSampRandOutOfNParamSetTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF
                   PsampSampRandOutOfNParamSetEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table lists configurations of random n-out-of-N
           sampling.  A parameter set describing a configuration
           contains a two parameter only, the sampling size and the
           parent population."
       ::= { psampSampRandOutOfN 3 }

However, there is no entry for "::= { psampSampRandOutOfN 2 }", so you have a good point.


>       +-- psampSampRandOutOfNParamSetEntry(1) [psampSampRandOutOfNIndex]
>          +-- psampSampRandOutOfNIndex(1)
>          +-- psampSampRandOutOfNSamplingSize(2)
>          +-- psampSampRandOutOfNPopulation(3)
>
> 6.2.4.  Uniform Probabilistic Sampling
>
>    The fourth selector function is uniform probabilistic sampling.  It
>    has just a single parameter called psampSampUniProbProbability:
>
>    psampSampUniProb(5)
>    +-- psampSampUniProbAvail(1)
>    +-- psampSampUniProbParamSetTable(3)

Why is this (3) rather than (2) ?
same good point.


>       +-- psampSampUniProbParamSetEntry(1) [psampSampUniProbIndex]
>          +-- psampSampUniProbIndex(1)
>          +-- psampSampUniProbProbability(2)
>
> 6.2.5.  Property Match Filtering
>
>    The fifth selector function is property match filtering.  For this
>    selector function there is a broad variety of possible parameters
>    that could be used.  But as stated in section 8.2.1 of [RFC5477]
>    there are no agreed parameters specified and the sub-tree for this
>    function only contains an object indicating the availability of this
>    function.  Paameters cannot be retireved via the PSAMP MIB module:

Typo x 2.


>
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt           [Page 7]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>    psampFiltPropMatch(6)
>    +-- psampFiltPropMatchAvail(1)
>
> 6.2.6.  Hash-based Filtering
>
>    The sixth selector function is hash-based filtering.  This function
>    has more parameters and the actual number may vary with the choice of
>    the hash function applied.  The common parameter set for all hash-
>    based filtering functions contains 7 parameters:
>    psampFiltHashInitializerValue, psampFiltHashIpPayloadOffset,
>    psampFiltHashIpPayloadSize, psampFiltHashSelectedRangeMin,
>    psampFiltHashSelectedRangeMax, psampFiltHashOutputRangeMin, and
>    psampFiltHashOutputRangeMax.

psampFiltHashFunction isn't mentioned?


>
>    psampFiltHash(7)
>    +-- psampFiltHashAvail(1)
>    +-- psampFiltHashCapabilities(2)
>    +-- psampFiltHashParamSetTable(3)
>       +-- psampFiltHashParamSetEntry(1) [psampFiltHashIndex]
>          +-- psampFiltHashIndex(1)
>          +-- psampFiltHashFunction(2)
>          +-- psampFiltHashInitializerValue(3)
>          +-- psampFiltHashIpPayloadOffset(4)
>          +-- psampFiltHashIpPayloadSize(5)
>          +-- psampFiltHashSelectedRangeMin(6)
>          +-- psampFiltHashSelectedRangeMax(7)
>          +-- psampFiltHashOutputRangeMin(8)
>          +-- psampFiltHashOutputRangeMax(9)
>
>    Further parameters depend on the applied hash function and are not
>    specified within the PSAMP MIB module.
>
>
> 7.  Definitions
>
>

Have you compiled this MIB?


>    PSAMP-MIB DEFINITIONS ::= BEGIN
>
>    IMPORTS
>        MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, mib-2
>            FROM SNMPv2-SMI                  -- RFC2578
>        TEXTUAL-CONVENTION, TruthValue
>            FROM SNMPv2-TC                   -- RFC2579
>        MODULE-COMPLIANCE, OBJECT-GROUP
>            FROM SNMPv2-CONF                 -- RFC2580
>        Unsigned64TC
>            FROM APPLICATION-MIB             -- RFC2564
>        ipfixSelectorFunctions
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt           [Page 8]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>            FROM IPFIX-SELECTOR-MIB;
>
>    psampMIB MODULE-IDENTITY
>        LAST-UPDATED "201011081200Z"         -- 08 November 2010
>        ORGANIZATION "IETF IPFIX Working Group"
>        CONTACT-INFO
>            "WG charter:
>              http://www.ietf.org/html.charters/ipfix-charter.html
>
>            Mailing Lists:
>              General Discussion: ipfix@ietf.org
>              To Subscribe: http://www1.ietf.org/mailman/listinfo/ipfix
>              Archive:
>          http://www1.ietf.org/mail-archive/web/ipfix/current/index.html
>
>            Editor:
>              Thomas Dietz
>              NEC Europe Ltd.
>              NEC Laboratories Europe
>              Network Research Division
>              Kurfuersten-Anlage 36
>              69115 Heidelberg
>              Germany
>              Phone: +49 6221 4342-128
>              Email: Thomas.Dietz@nw.neclab.eu
>
>              Benoit Claise
>              Cisco Systems, Inc.
>              De Kleetlaan 6a b1
>              Degem 1831
>              Belgium
>              Phone:  +32 2 704 5622
>              Email: bclaise@cisco.com
>
>              Juergen Quittek
>              NEC Europe Ltd.
>              NEC Laboratories Europe
>              Network Research Division
>              Kurfuersten-Anlage 36
>              69115 Heidelberg
>              Germany
>              Phone: +49 6221 4342-115
>              Email: quittek@nw.neclab.eu"
>            DESCRIPTION
>            "The PSAMP MIB defines managed objects for packet sampling
>            and filtering.
>            These objects provide information about managed nodes
>            supporting packet sampling, including packet sampling
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt           [Page 9]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>            capabilities, configuration and statistics.
>
>            Copyright (c) 2010 IETF Trust and the persons identified as
>            the document authors.  All rights reserved. This version
>            of this MIB module is part of RFC yyyy; see the RFC itself
>            for full legal notices"
>    -- RFC Ed.: replace yyyy with actual RFC number & remove this notice

Being buried in the MIB, it's possible, even likely, that this will be overlooked.


>
>         --  Revision history
>
>         REVISION     "201011081200Z"         -- 08 November 2010
>         DESCRIPTION
>             "Initial version, published as RFC yyyy."
>    -- RFC Ed.: replace yyyy with actual RFC number & remove this notice
>
>        ::= { mib-2 xxx }
>    -- xxx to be assigned by IANA.

This isn't mentioned in the IANA section.
good point.


>
>    PsampFloat64 ::= TEXTUAL-CONVENTION
>        STATUS       current
>        DESCRIPTION
>                "Represents the float64 data type and MUST be encoded as
>                an IEEE double-precision 64-bit floating point-type, as
>                specified in IEEE 754."
>        SYNTAX       OCTET STRING (SIZE (8))
>
>    -- Top level structure of the MIB
>
>    psampObjects     OBJECT IDENTIFIER ::= { psampMIB 1 }
>    psampConformance OBJECT IDENTIFIER ::= { psampMIB 2 }
>
>
>    --==================================================================
>    -- Packet selection sampling methods group of objects
>    --==================================================================
>
>    --==================================================================
>    --* Method 1: Systematic count-based Sampling
>    --==================================================================
>
>    -- Reference: RFC5475, Section 5.1, RFC5476 Section 6.5.2.1 and
>    --            RFC5477, Section 8.2
>    psampSampCountBased OBJECT IDENTIFIER
>        ::= { ipfixSelectorFunctions 2 }
>
>    psampSampCountBasedAvail OBJECT-TYPE
>        SYNTAX      TruthValue
>        MAX-ACCESS  read-only
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 10]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>        STATUS      current
>        DESCRIPTION
>            "This object indicates the availability of systematic
>            count-based sampling at the managed node.
>
>            A Selector may be unavailable if it is implemented but
>            currently disabled due to e.g., administrative reasons, lack
>            of resources or similar."
>        DEFVAL { false }
>        ::= { psampSampCountBased 1 }
>
>    -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++
>
>    psampSampCountBasedParamSetTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF
>                    PsampSampCountBasedParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "This table lists configurations of systematic count-based
>            packet sampling.  A parameter set describing a
>            configuration contains two parameters: the sampling
>            interval length and the space."

Either say "and the sampling interval space", or say "the sampling interval length and space."


>        ::= { psampSampCountBased 2 }
>
>    psampSampCountBasedParamSetEntry OBJECT-TYPE
>        SYNTAX      PsampSampCountBasedParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Defines an entry in the psampSampCountBasedParamSetTable."
>        INDEX { psampSampCountBasedIndex }
>        ::= { psampSampCountBasedParamSetTable 1 }
>
>    PsampSampCountBasedParamSetEntry ::=
>        SEQUENCE {
>            psampSampCountBasedIndex     Integer32,
>            psampSampCountBasedInterval  Unsigned32,
>            psampSampCountBasedSpace     Unsigned32
>        }
>
>    psampSampCountBasedIndex OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The index of this parameter set in the
>            psampSampCountBasedParamSetTable.It is used in the

Spacing.


>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 11]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>            object ipfixSelectionProcessSelectorFunctionentries of
>            the ipfixSelectionProcessTable in the IPFIX-MIB as reference
>            to this parameter set."
>        ::= { psampSampCountBasedParamSetEntry 1 }
>
>    psampSampCountBasedInterval OBJECT-TYPE
>        SYNTAX      Unsigned32
>        UNITS       "packets"
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the number of packets that are
>            consecutively sampled.  A value of 100 means that 100
>            consecutive packets are sampled."
>        REFERENCE
>            "RFC5475, Section 5.1 and RFC5477, Section 8.2"
>        ::= { psampSampCountBasedParamSetEntry 2 }
>
>    psampSampCountBasedSpace OBJECT-TYPE
>        SYNTAX      Unsigned32
>        UNITS       "packets"
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the number of packets between two
>            psampSampCountBasedInterval's.  A value of 100 means that
>            the next interval starts 100 packets (which are not sampled)
>            after the current psampSampCountBasedInterval is over."
>        REFERENCE
>            "RFC5475, Section 5.1 and RFC5477, Section 8.2"
>        ::= { psampSampCountBasedParamSetEntry 3 }
>
>    --==================================================================
>    --* Method 2: Systematic time-based Sampling
>    --==================================================================
>
>    -- Reference: RFC5475, Section 5.1, RFC5476 Section 6.5.2.2 and
>    --            RFC5477, Section 8.2
>    psampSampTimeBased OBJECT IDENTIFIER
>        ::= { ipfixSelectorFunctions 3 }
>
>    psampSampTimeBasedAvail OBJECT-TYPE
>        SYNTAX      TruthValue
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object indicates the availability of systematic
>            time-based sampling at the managed node.
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 12]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>            A Selector may be unavailable if it is implemented but
>            currently disabled due to e.g., administrative reasons, lack
>            of resources or similar."
>        DEFVAL { false }
>        ::= { psampSampTimeBased 1 }
>
>    -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++
>
>    psampSampTimeBasedParamSetTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF
>                    PsampSampTimeBasedParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "This table lists configurations of systematic time-based
>            packet sampling. A parameter set describing a configuration
>            contains two parameters: the sampling interval length and
>            the space."
>        ::= { psampSampTimeBased 2 }
>
>    psampSampTimeBasedParamSetEntry OBJECT-TYPE
>        SYNTAX      PsampSampTimeBasedParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Defines an entry in the psampSampTimeBasedParamSetTable."
>        INDEX { psampSampTimeBasedIndex }
>        ::= { psampSampTimeBasedParamSetTable 1 }
>
>    PsampSampTimeBasedParamSetEntry ::=
>        SEQUENCE {
>            psampSampTimeBasedIndex     Integer32,
>            psampSampTimeBasedInterval  Unsigned32,
>            psampSampTimeBasedSpace     Unsigned32
>        }
>
>    psampSampTimeBasedIndex OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The index of this parameter set in the
>            psampSampTimeBasedParamSetTable. It is used in the
>            object ipfixSelectionProcessSelectorFunctionentries of
>            the ipfixSelectionProcessTable in the IPFIX-MIB as reference
>            to this parameter set."
>        ::= { psampSampTimeBasedParamSetEntry 1 }
>
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 13]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>    psampSampTimeBasedInterval OBJECT-TYPE
>        SYNTAX      Unsigned32
>        UNITS       "microseconds"
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>           "This object specifies the time interval in microseconds
>           during which all arriving packets are sampled."

This description's indentation is slightly different.


>        REFERENCE
>            "RFC5475, Section 5.1 and RFC5477, Section 8.2"
>        ::= { psampSampTimeBasedParamSetEntry 2 }
>
>    psampSampTimeBasedSpace OBJECT-TYPE
>        SYNTAX      Unsigned32
>        UNITS       "microseconds"
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the time interval in microseconds
>            between two psampSampTimeBasedInterval's.  A value of 100
>            means that the next interval starts 100 microseconds (during
>            which no packets are sampled) after the current
>            psampSampTimeBasedInterval is over."
>        REFERENCE
>            "RFC5475, Section 5.1 and RFC5477, Section 8.2"
>        ::= { psampSampTimeBasedParamSetEntry 3 }
>
>    --==================================================================
>    --* Method 3: Random n-out-of-N Sampling
>    --==================================================================
>
>    -- Reference: RFC5475, Section 5.2.1, RFC5476 Section 6.5.2.3 and
>    --            RFC5477, Section 8.2
>    psampSampRandOutOfN OBJECT IDENTIFIER
>        ::= { ipfixSelectorFunctions 4 }
>
>    psampSampRandOutOfNAvail OBJECT-TYPE
>        SYNTAX      TruthValue
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object indicates the availability of random n-out-of-N
>            sampling at the managed node.
>
>            A Selector may be unavailable if it is implemented but
>            currently disabled due to e.g., administrative reasons, lack
>            of resources or similar."
>        DEFVAL { false }
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 14]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>        ::= { psampSampRandOutOfN 1 }
>
>    -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++
>
>    psampSampRandOutOfNParamSetTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF
>                    PsampSampRandOutOfNParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "This table lists configurations of random n-out-of-N
>            sampling.  A parameter set describing a configuration
>            contains a two parameter only, the sampling size and the
>            parent population."
>        ::= { psampSampRandOutOfN 3 }
>
>    psampSampRandOutOfNParamSetEntry OBJECT-TYPE
>        SYNTAX      PsampSampRandOutOfNParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Defines an entry in the psampSampRandOutOfNParamSetTable."
>        INDEX { psampSampRandOutOfNIndex }
>        ::= { psampSampRandOutOfNParamSetTable 1 }
>
>    PsampSampRandOutOfNParamSetEntry ::=
>        SEQUENCE {
>            psampSampRandOutOfNIndex        Integer32,
>            psampSampRandOutOfNSamplingSize Unsigned32,
>            psampSampRandOutOfNPopulation   Unsigned32
>        }
>
>    psampSampRandOutOfNIndex OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The index of this parameter set in the
>            psampSampRandOutOfNParamSetTable.  It is used in the
>            object ipfixSelectionProcessSelectorFunctionentries of
>            the ipfixSelectionProcessTable in the IPFIX-MIB as reference
>            to this parameter set."
>        ::= { psampSampRandOutOfNParamSetEntry 1 }
>
>    psampSampRandOutOfNSamplingSize OBJECT-TYPE
>        SYNTAX      Unsigned32
>        UNITS       "packets"
>        MAX-ACCESS  read-only
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 15]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the number of elements taken from the
>            parent Population for specified in

Remove "for".


>            psampSampRandOutOfNPopulation."
>        REFERENCE
>            "RFC5475, Section 5.2.1 and RFC5477, Section 8.2"
>        ::= { psampSampRandOutOfNParamSetEntry 2 }
>
>    psampSampRandOutOfNPopulation OBJECT-TYPE
>        SYNTAX      Unsigned32
>        UNITS       "packets"
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>           "This object specifies the number of elements in the parent
>           Population."

This description's indentation is slightly different.


>        REFERENCE
>            "RFC5475, Section 5.2.1 and RFC5477, Section 8.2"
>        ::= { psampSampRandOutOfNParamSetEntry 3 }
>
>    --==================================================================
>    --* Method 4: Uniform probabilistic Sampling
>    --==================================================================
>
>    -- Reference: RFC5475, Section 5.2.2, RFC5476 Section 6.5.2.4 and
>    --            RFC5477, Section 8.2
>    psampSampUniProb OBJECT IDENTIFIER ::= { ipfixSelectorFunctions 5 }
>
>    psampSampUniProbAvail OBJECT-TYPE
>        SYNTAX      TruthValue
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object indicates the availability of random uniform
>            probabilistic sampling at the managed node.
>
>            A Selector may be unavailable if it is implemented but
>            currently disabled due to e.g., administrative reasons, lack
>            of resources or similar."
>        DEFVAL { false }
>        ::= { psampSampUniProb 1 }
>
>    -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++
>
>    -- Reference: RFC5475, Section 5.2.2.1 and RFC5477, Section 8.2
>    psampSampUniProbParamSetTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 16]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>                    PsampSampUniProbParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "This table lists configurations of random probabilistic
>            sampling.  A parameter set describing a configuration
>            contains a single parameter only: the sampling probability."
>        ::= { psampSampUniProb 3 }
>
>    psampSampUniProbParamSetEntry OBJECT-TYPE
>        SYNTAX      PsampSampUniProbParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Defines an entry in the psampSampUniProbParamSetTable."
>        INDEX { psampSampUniProbIndex }
>        ::= { psampSampUniProbParamSetTable 1 }
>
>    PsampSampUniProbParamSetEntry ::=
>        SEQUENCE {
>            psampSampUniProbIndex       Integer32,
>            psampSampUniProbProbability PsampFloat64
>        }
>
>    psampSampUniProbIndex OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>           "The index of this parameter set in the

The indentation of the first line of this description is slightly different.


>            psampSampUniProbParamSetTable.  It is used in the
>            object ipfixSelectionProcessSelectorFunctionentries of
>            the ipfixSelectionProcessTable in the IPFIX-MIB as reference
>            to this parameter set."
>        ::= { psampSampUniProbParamSetEntry 1 }
>
>    psampSampUniProbProbability OBJECT-TYPE
>        SYNTAX      PsampFloat64
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the probability that a packet is
>            sampled, expressed as a value between 0 and 1.  The
>            probability is equal for every packet.  A value of 0 means
>            no packet was sampled since the probability is 0. A value
>            of 1 means all packets were sampled since the
>            probability is 1."
>        REFERENCE
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 17]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>            "RFC5475, Section 5.2.2.1 and RFC5477, Section 8.2"
>        ::= { psampSampUniProbParamSetEntry 2 }
>
>    --==================================================================
>    -- Packet selection filtering methods group of objects
>    --==================================================================
>
>    --==================================================================
>    --* Method 5: Property Match filtering
>    --==================================================================
>
>    -- Reserves Method 5 (see RFC5475, Section 6.1, RFC5476
>    -- Section 6.5.2.5 and RFC5477)
>    psampFiltPropMatch OBJECT IDENTIFIER
>        ::= { ipfixSelectorFunctions 6 }
>
>    psampFiltPropMatchAvail OBJECT-TYPE
>        SYNTAX      TruthValue
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object indicates the availability of property match
>            filtering at the managed node.
>
>            A Selector may be unavailable if it is implemented but
>            currently disabled due to e.g., administrative reasons, lack
>            of resources or similar."
>        DEFVAL { false }
>        ::= { psampFiltPropMatch 1 }
>
>    --==================================================================
>    --* Method 1: Hash filtering

Typo: it's method 6.


>    --==================================================================
>
>    -- Reference: RFC5475, Section 6.2, RFC5476 Section 6.5.2.6 and
>    --            RFC5477, Section 8.3
>    psampFiltHash OBJECT IDENTIFIER ::= { ipfixSelectorFunctions 7 }
>
>    psampFiltHashAvail OBJECT-TYPE
>        SYNTAX      TruthValue
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object indicates the availability of hash filtering
>            at the managed node.
>
>            A Selector may be unavailable if it is implemented but
>            currently disabled due to e.g., administrative reasons, lack
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 18]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>            of resources or similar."
>        DEFVAL { false }
>        ::= { psampFiltHash 1 }
>
>    psampFiltHashCapabilities OBJECT IDENTIFIER
>        ::= { psampFiltHash 2 }
>
>    -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++
>
>    -- Reference: RFC5475, Sections 6.2, 3.8, and 7.1
>    psampFiltHashParamSetTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF
>                    PsampFiltHashParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "This table lists configurations of hash filtering. A
>            parameter set describing a configuration contains eight
>            parameter describing the hash function."
>        ::= { psampFiltHash 3 }
>
>    psampFiltHashParamSetEntry OBJECT-TYPE
>        SYNTAX      PsampFiltHashParamSetEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Defines an entry in the psampFiltHashParamSetTable."
>        INDEX { psampFiltHashIndex }
>        ::= { psampFiltHashParamSetTable 1 }
>
>    PsampFiltHashParamSetEntry ::=
>        SEQUENCE {
>            psampFiltHashIndex            Integer32,
>            psampFiltHashFunction         INTEGER,
>            psampFiltHashInitializerValue Unsigned64TC,
>            psampFiltHashIpPayloadOffset  Unsigned64TC,
>            psampFiltHashIpPayloadSize    Unsigned64TC,
>            psampFiltHashSelectedRangeMin Unsigned64TC,
>            psampFiltHashSelectedRangeMax Unsigned64TC,
>            psampFiltHashOutputRangeMin   Unsigned64TC,
>            psampFiltHashOutputRangeMax   Unsigned64TC
>        }
>
>    psampFiltHashIndex OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 19]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>            "The index of this parameter set in the
>             psampFiltHashParamSetTable. It is used in the
>            object ipfixSelectionProcessSelectorFunctionentries of
>            the ipfixSelectionProcessTable in the IPFIX-MIB as reference
>            to this parameter set."
>        ::= { psampFiltHashParamSetEntry 1 }
>
>    psampFiltHashFunction OBJECT-TYPE
>        SYNTAX      INTEGER {
>                        crc32(1),
>                        ipsx(2),
>                        bob(3)
>                    }
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The Hash Function used by this filter. The PSAMP-MIB
>            supports the following Hash Functions:
>
>            crc32(1)
>
>            ipsx(2)
>
>            bob(3)
>            "
>        ::= { psampFiltHashParamSetEntry 2 }
>
>    psampFiltHashInitializerValue OBJECT-TYPE
>        SYNTAX      Unsigned64TC
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the initializer value to the hash
>            function."
>        REFERENCE
>            "RFC5475, Sections 6.2, 3.8, and 7.1"
>        ::= { psampFiltHashParamSetEntry 3 }
>
>    psampFiltHashIpPayloadOffset OBJECT-TYPE
>        SYNTAX      Unsigned64TC
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the IP payload offset used by a
>            Hash-based Selection Selector."
>        REFERENCE
>            "RFC5475, Sections 6.2, 3.8, and 7.1"
>        ::= { psampFiltHashParamSetEntry 4 }
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 20]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>    psampFiltHashIpPayloadSize OBJECT-TYPE
>        SYNTAX      Unsigned64TC
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the IP payload size used by a
>            Hash-based Selection Selector."
>        REFERENCE
>            "RFC5475, Sections 6.2, 3.8, and 7.1"
>        ::= { psampFiltHashParamSetEntry 5 }
>
>    psampFiltHashSelectedRangeMin OBJECT-TYPE
>        SYNTAX      Unsigned64TC
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the value for the beginning of a hash
>            function's selected range."
>        REFERENCE
>            "RFC5475, Sections 6.2, 3.8, and 7.1"
>        ::= { psampFiltHashParamSetEntry 6 }
>
>    psampFiltHashSelectedRangeMax OBJECT-TYPE
>        SYNTAX      Unsigned64TC
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the value for the end of a hash
>            function's selected range."
>        REFERENCE
>            "RFC5475, Sections 6.2, 3.8, and 7.1"
>        ::= { psampFiltHashParamSetEntry 7 }
>
>    psampFiltHashOutputRangeMin OBJECT-TYPE
>        SYNTAX      Unsigned64TC
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This object specifies the value for the beginning of a hash
>            function's potential output range."
>        REFERENCE
>            "RFC5475, Sections 6.2, 3.8, and 7.1"
>        ::= { psampFiltHashParamSetEntry 8 }
>
>    psampFiltHashOutputRangeMax OBJECT-TYPE
>        SYNTAX      Unsigned64TC
>        MAX-ACCESS  read-only
>        STATUS      current
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 21]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>        DESCRIPTION
>            "This object specifies the value for the end of a hash
>            function's potential output range."
>        REFERENCE
>            "RFC5475, Sections 6.2, 3.8, and 7.1"
>        ::= { psampFiltHashParamSetEntry 9 }
>
>    --==================================================================
>    -- Conformance information
>    --==================================================================
>
>    psampCompliances OBJECT IDENTIFIER ::= { psampConformance 1 }
>    psampGroups      OBJECT IDENTIFIER ::= { psampConformance 2 }
>
>    --==================================================================
>    -- Compliance statements
>    --==================================================================
>
>    psampCompliance MODULE-COMPLIANCE
>        STATUS  current
>        DESCRIPTION
>            "The implementation of all objects is optional and depends
>            on the implementation of the corresponding functionality in
>            the equipment."
>        MODULE  -- this module
>            GROUP psampGroupSampCountBased
>            DESCRIPTION
>                "These objects must be implemented if the corresponding
>                sampling function is implemented in the equipment."
>            GROUP psampGroupSampTimeBased
>            DESCRIPTION
>                "These objects must be implemented if the corresponding
>                sampling function is implemented in the equipment."
>            GROUP psampGroupSampRandOutOfN
>            DESCRIPTION
>                "These objects must be implemented if the corresponding
>                sampling function is implemented in the equipment."
>            GROUP psampGroupSampUniProb
>            DESCRIPTION
>                "These objects must be implemented if the corresponding
>                sampling function is implemented in the equipment."
>            GROUP psampGroupFiltPropMatch
>            DESCRIPTION
>                "These objects must be implemented if the corresponding
>                filter function is implemented in the equipment."
>            GROUP psampGroupFiltHash
>            DESCRIPTION
>                "These objects must be implemented if the corresponding
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 22]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>                filter function is implemented in the equipment."
>        ::= { psampCompliances 1 }
>
>    --==================================================================
>    -- MIB groupings
>    --==================================================================
>

The indentation of all the descriptions below is slightly different from the previous descriptions above.


>    psampGroupSampCountBased OBJECT-GROUP
>        OBJECTS {
>                  psampSampCountBasedAvail,
>                  psampSampCountBasedInterval,
>                  psampSampCountBasedSpace
>                }
>        STATUS  current
>        DESCRIPTION
>           "These objects are needed if count based sampling is
>           implemented."
>        ::= { psampGroups 2 }
>
>    psampGroupSampTimeBased OBJECT-GROUP
>        OBJECTS {
>                  psampSampTimeBasedAvail,
>                  psampSampTimeBasedInterval,
>                  psampSampTimeBasedSpace
>                }
>        STATUS  current
>        DESCRIPTION
>           "These objects are needed if time based sampling is
>           implemented."
>        ::= { psampGroups 3 }
>
>    psampGroupSampRandOutOfN OBJECT-GROUP
>        OBJECTS {
>                  psampSampRandOutOfNAvail,
>                  psampSampRandOutOfNSamplingSize,
>                  psampSampRandOutOfNPopulation
>                }
>        STATUS  current
>        DESCRIPTION
>           "These objects are needed if random n-out-of-N sampling is
>           implemented."
>        ::= { psampGroups 4 }
>
>    psampGroupSampUniProb OBJECT-GROUP
>        OBJECTS {
>                  psampSampUniProbAvail,
>                  psampSampUniProbProbability
>                }
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 23]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>        STATUS  current
>        DESCRIPTION
>           "These objects are needed if uniform probabilistic sampling
>           is implemented."
>        ::= { psampGroups 5 }
>
>    psampGroupFiltPropMatch OBJECT-GROUP
>        OBJECTS {
>                  psampFiltPropMatchAvail
>                }
>        STATUS  current
>        DESCRIPTION
>           "These objects are needed if property match filtering is
>           implemented."
>        ::= { psampGroups 6 }
>
>    psampGroupFiltHash OBJECT-GROUP
>        OBJECTS {
>                  psampFiltHashAvail,
>                  psampFiltHashFunction,
>                  psampFiltHashInitializerValue,
>                  psampFiltHashIpPayloadOffset,
>                  psampFiltHashIpPayloadSize,
>                  psampFiltHashSelectedRangeMin,
>                  psampFiltHashSelectedRangeMax,
>                  psampFiltHashOutputRangeMin,
>                  psampFiltHashOutputRangeMax
>                }
>        STATUS  current
>        DESCRIPTION
>           "These objects are needed if hash filtering is implemented."
>        ::= { psampGroups 9 }

"psampGroups 7".


>
>    END
>
>
> 8.  Security Considerations
>
>    There are no management objects defined in this MIB module that have
>    a MAX-ACCESS clause of read-write and/or read-create.  So, if this
>    MIB module is implemented correctly, then there is no risk that an
>    intruder can alter or create any management objects of this MIB
>    module via direct SNMP SET operations.
>
>    Some of the readable objects in this MIB module (i.e., objects with a

See below.


>    MAX-ACCESS other than not-accessible) may be considered sensitive or
>    vulnerable in some network environments.  It is thus important to
>    control even GET and/or NOTIFY access to these objects and possibly
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 24]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>    to even encrypt the values of these objects when sending them over
>    the network via SNMP.  These are the tables and objects and their
>    sensitivity/vulnerability:
>
>    o  All tables - they contain configuration data that might be
>       sensitive because objects in this table may reveal information
>       about the network infrastructure and device configuration

>From "Some of" to here, why not just say:

All tables in this MIB module may be considered sensitive or vulnerable
in some network environments because objects in the tables may reveal information
about the network infrastructure and device configuration. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP.
Yes we should be consistent.


>
>    SNMP versions prior to SNMPv3 did not include adequate security.
>    Even if the network itself is secure (for example by using IPsec),
>    there is no control as to who on the secure network is allowed to
>    access and GET/SET (read/change/create/delete) the objects in this
>    MIB module.
>
>    It is RECOMMENDED that implementers consider the security features as

Remove "as".


>    provided by the SNMPv3 framework (see [RFC3410], section 8),
>    including full support for the SNMPv3 cryptographic mechanisms (for
>    authentication and privacy).
>
>    Further, deployment of SNMP versions prior to SNMPv3 is NOT
>    RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
>    enable cryptographic security.  It is then a customer/operator
>    responsibility to ensure that the SNMP entity giving access to an
>    instance of this MIB module is properly configured to give access to
>    the objects only to those principals (users) that have legitimate

Users are people, so use "who".


>    rights to indeed GET or SET (change/create/delete) them.

Remove "indeed".


> 9.  IANA Considerations
>
>    The MIB module in this document uses the following IANA-assigned
>    OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
>
>            Descriptor             OBJECT IDENTIFIER value
>            ----------             -----------------------
>            psampMIB               { mib-2 xxx }

Clearly specify that xxx must be assigned by IANA and also written into the MIB in section 7.
yes.

Thanks for the detailed review


Thanks,
P.


>            psampSampCountBased    { ipfixSelectorFunctions 2 }
>            psampSampTimeBased     { ipfixSelectorFunctions 3 }
>            psampSampRandOutOfN    { ipfixSelectorFunctions 4 }
>            psampSampUniProb       { ipfixSelectorFunctions 5 }
>            psampFiltPropMatch     { ipfixSelectorFunctions 6 }
>            psampFiltHash          { ipfixSelectorFunctions 7 }
>
>    Other than that this document does not impose any IANA
>    considerations.
>
>
>
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 25]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
> 10.  Acknowledgment
>
>    This document is a product of the PSAMP and IPFIX working groups.
>
>
> 11.  References
>
> 11.1.  Normative References
>
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>    [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
>               Schoenwaelder, Ed., "Structure of Management Information
>               Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
>
>    [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
>               Schoenwaelder, Ed., "Textual Conventions for SMIv2",
>               STD 58, RFC 2579, April 1999.
>
>    [RFC2580]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
>               "Conformance Statements for SMIv2", STD 58, RFC 2580,
>               April 1999.
>
>    [RFC2564]  Kalbfleisch, C., Krupczak, C., Presuhn, R., and J.
>               Saperia, "Application Management MIB", RFC 2564, May 1999.
>
>    [RFC5101]  Claise, B., "Specification of the IP Flow Information
>               Export (IPFIX) Protocol for the Exchange of IP Traffic
>               Flow Information", RFC 5101, January 2008.
>
>    [RFC5477]  Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
>               Carle, "Information Model for Packet Sampling Exports",
>               RFC 5477, March 2009.
>
>    [RFC5815]  Dietz, T., Kobayashi, A., Claise, B., and G. Muenz,
>               "Definitions of Managed Objects for IP Flow Information
>               Export", RFC 5815, April 2010.
>
>    [IEEE.754.1985]
>               Institute of Electrical and Electronics Engineers,
>               "Standard for Binary Floating-Point Arithmetic",
>               IEEE Standard 754, August 1985.
>
> 11.2.  Informative References
>
>    [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
>               "Introduction and Applicability Statements for Internet-
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 26]
>
> Internet-Draft                  PSAMP MIB                  November 2010
>
>
>               Standard Management Framework", RFC 3410, December 2002.
>
>    [RFC5474]  Duffield, N., Chiou, D., Claise, B., Greenberg, A.,
>               Grossglauser, M., and J. Rexford, "A Framework for Packet
>               Selection and Reporting", RFC 5474, March 2009.
>
>    [RFC5475]  Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F.
>               Raspall, "Sampling and Filtering Techniques for IP Packet
>               Selection", RFC 5475, March 2009.
>
>    [RFC5476]  Claise, B., Johnson, A., and J. Quittek, "Packet Sampling
>               (PSAMP) Protocol Specifications", RFC 5476, March 2009.
>
>
> Authors' Addresses
>
>    Thomas Dietz (editor)
>    NEC Europe Ltd.
>    NEC Laboratories Europe
>    Kurfuersten-Anlage 36
>    Heidelberg  69115
>    DE
>
>    Phone: +49 6221 4342-128
>    Email: dietz@neclab.eu
>
>
>    Benoit Claise
>    Cisco Systems, Inc.
>    De Kleetlaan 6a b1
>    Degem  1831
>    BE
>
>    Phone: +32 2 704 5622
>    Email: bclaise@cisco.com
>
>
>    Juergen Quittek
>    NEC Europe Ltd.
>    NEC Laboratories Europe
>    Kurfuersten-Anlage 36
>    Heidelberg  69115
>    DE
>
>    Phone: +49 6221 4342-115
>    Email: quittek@neclab.eu
>
>
>
>
>
> Dietz, et al.       draft-ietf-ipfix-psamp-mib-02.txt          [Page 27]
>
>


--------------000208080501020501090109-- From bclaise@cisco.com Wed Nov 24 03:39:16 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8961C28C191 for ; Wed, 24 Nov 2010 03:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChlTmOez+E-h for ; Wed, 24 Nov 2010 03:39:15 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id DBEF53A691D for ; Wed, 24 Nov 2010 03:39:14 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAOBaQv2011189; Wed, 24 Nov 2010 12:36:26 +0100 (CET) Received: from [10.55.43.54] (ams-bclaise-8715.cisco.com [10.55.43.54]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAOBaQnW009293; Wed, 24 Nov 2010 12:36:26 +0100 (CET) Message-ID: <4CECF8B9.2000807@cisco.com> Date: Wed, 24 Nov 2010 12:36:25 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Chris Inacio References: <71523BFA-2730-4D7D-82AD-E8241BB3A91F@cert.org> In-Reply-To: <71523BFA-2730-4D7D-82AD-E8241BB3A91F@cert.org> Content-Type: multipart/alternative; boundary="------------050608050105020305040706" Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Structured Data WGLC comments -> IP Flow to Flow again X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 11:39:16 -0000 This is a multi-part message in MIME format. --------------050608050105020305040706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Let me address a single point from Chris' email in this thread > First off, I agree with Brian's comments. > > In section 1.1, do you want to keep saying "IP Flow information"? Especially considering the chances of using IPFIX in other IETF activities. You have a good point. As we concluded already on the mailing list, IPFIX scope is not IP anymore As we discussed at the last IPFIX meeting, the meeting minutes expresses: Juergen led a discussion on "should we move the IPFIX base standards (RFCs 5101, 5102 and 5103) to Draft Standard. There was consensus that this would be worthwhile if it corrected all the bugs discovered to date in the documents, and added explanatory text to make them easier to understand. _We also need to remove 'IP' from the IPFIX Flow definition, since that is proving to be a blocking factor or the ITU-T NGN to reference IPFIX._ How to address this in the new drafts? Most new IPFIX drafts have section like these 1 . Overview.................................................7 1.1 . IPFIX Documents Overview............................7 1.2 . Relationship between IPFIX and PSAMP................8 I see two solutions: 1. maybe it's time to start changing from IP Flow to Flow in those sections for the new drafts. 2. alternatively, we add a generic note (somewhere in the same sections) that IPFIX scope has been extended to non IP, even if RFC5101 and RFC5102 focuses on IP. What do you think? Regards, Benoit. > Section 2: "Indeed, polling short-live Flows" to "Indeed, polling short-lived Flows". > > The dangling "Figure F" label on page 22-23 is really annoying. > > I would like to see a better discussion about how structured data elements change the TLV tuple contract that is the core of the IPFIX model today. I personally think that is the largest change with how we will handle these new data types. > > Even more importantly for our application, I would really like to see a way of passing metadata about a structured template as well. Can we expand structured data to include some options elements so that I can do something like say "template 255 is email" "template 256 is IMAP" / "template 257 is POP3". Something like that. We're really worried about the template issue withdraw problem that seems to be creeping up on us when we use structured data. > > As a point of reference, we have structured data fully implemented in our fixbuf library. We're currently converting the DPI capabilities that are in YAF to use structured data for export. We're still working through the issues of how to manage templates using structured data. We have the issue of that, for example, if you want capture details on HTTP, then sometimes the "referer" field will be present, and sometimes it won't. If we want to encode that efficiently, we need to either change the templates, or have multiples available. If we have multiples, we always want the collector to understand that these N templates are HTTP, otherwise we have to do a lot of withdraws of templates. > > I really like structured data, especially if I find more than one HTTP header in a network stream (proxying anyone?) because it captures the relationship. But right now, I'm not sure how to manage it. > > I'll try to be on the webex if I can. > > > regards, > Chris Inacio > inacio@cert.org > > > On Nov 8, 2010, at 4:53 AM, Brian Trammell wrote: > >> Greetings, all, >> >> I have the following two comments on draft-ietf-ipfix-structured-data-03. >> >> First, I don't necessarily find the repeated examples showing how variable length Information Elements work to be particularly useful, but I accept that this might be because I already know how they work. >> >> What I _am_ missing, however, are unified diagrams showing how the structured data Information Elements and variable-length encoding work together: >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 255 | Length (0 to 65535) | Semantic | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| Information Element ID | Element Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | basicList content . . . | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> Second, Section 5.4 is missing a discussion of when you shouldn't use Structured Data _at all_: i.e., when there is low or no semantic variation among records represented by a template. Consequently, I'm not sure about section 9.3. It seems like although we _could_ use structured data for biflows, the suggested approach misses the 1. semantic clarity and 2. export efficiency that were aims of 5103. >> >> Beyond these points, I've reviewed the draft, and it looks good. >> >> Best regards, >> >> Brian >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix --------------050608050105020305040706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Let me address a single point from Chris' email in this thread
First off, I agree with Brian's comments.

In section 1.1, do you want to keep saying "IP Flow information"?  Especially considering the chances of using IPFIX in other IETF activities.
You have a good point.
As we concluded already on the mailing list, IPFIX scope is not IP anymore
As we discussed at the last IPFIX meeting, the meeting minutes expresses:
Juergen led a discussion on "should we move the IPFIX base standards
(RFCs 5101, 5102 and 5103) to Draft Standard.  There was consensus
that this would be worthwhile if it corrected all the bugs discovered
to date in the documents, and added explanatory text to make them
easier to understand.  We also need to remove 'IP' from the IPFIX Flow
definition, since that is proving to be a blocking factor or the ITU-T
NGN to reference IPFIX.
How to address this in the new drafts? Most new IPFIX drafts have section like these
           1. Overview................................................. 7
           1.1. IPFIX Documents Overview............................ 7
           1.2. Relationship between IPFIX and PSAMP................ 8
I see two solutions:
1. maybe it's time to start changing from IP Flow to Flow in those sections for the new drafts.
2. alternatively, we add a generic note (somewhere in the same sections) that IPFIX scope has been extended to non IP, even if RFC5101 and RFC5102 focuses on IP.

What do you think?

Regards, Benoit.

Section 2: "Indeed, polling short-live Flows" to "Indeed, polling short-lived Flows".

The dangling "Figure F" label on page 22-23 is really annoying.

I would like to see a better discussion about how structured data elements change the TLV tuple contract that is the core of the IPFIX model today.  I personally think that is the largest change with how we will handle these new data types. 

Even more importantly for our application, I would really like to see a way of passing metadata about a structured template as well.  Can we expand structured data to include some options elements so that I can do something like say "template 255 is email"  "template 256 is IMAP" / "template 257 is POP3".  Something like that.  We're really worried about the template issue withdraw problem that seems to be creeping up on us when we use structured data.

As a point of reference, we have structured data fully implemented in our fixbuf library.  We're currently converting the DPI capabilities that are in YAF to use structured data for export.  We're still working through the issues of how to manage templates using structured data.  We have the issue of that, for example, if you want capture details on HTTP, then sometimes the "referer" field will be present, and sometimes it won't.  If we want to encode that efficiently, we need to either change the templates, or have multiples available.  If we have multiples, we always want the collector to understand that these N templates are HTTP, otherwise we have to do a lot of withdraws of templates.

I really like structured data, especially if I find more than one HTTP header in a network stream (proxying anyone?) because it captures the relationship.  But right now, I'm not sure how to manage it.

I'll try to be on the webex if I can.


regards,
Chris Inacio
inacio@cert.org


On Nov 8, 2010, at 4:53 AM, Brian Trammell wrote:


Greetings, all,

I have the following two comments on draft-ietf-ipfix-structured-data-03.

First, I don't necessarily find the repeated examples showing how variable length Information Elements work to be particularly useful, but I accept that this might be because I already know how they work.

What I _am_ missing, however, are unified diagrams showing how the structured data Information Elements and variable-length encoding work together:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      255      |      Length (0 to 65535)      |   Semantic    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|   Information Element ID    |        Element Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      basicList content . . .                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Second, Section 5.4 is missing a discussion of when you shouldn't use Structured Data _at all_: i.e., when there is low or no semantic variation among records represented by a template. Consequently, I'm not sure about section 9.3. It seems like although we _could_ use structured data for biflows, the suggested approach misses the 1. semantic clarity and 2. export efficiency that were aims of 5103.

Beyond these points, I've reviewed the draft, and it looks good.

Best regards,

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


    

    

  


--------------050608050105020305040706--

From iesg-secretary@ietf.org  Wed Nov 24 05:37:17 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B948128C1FA; Wed, 24 Nov 2010 05:37:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.442
X-Spam-Level: 
X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFlZKSaBpjdU; Wed, 24 Nov 2010 05:37:17 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0635A28C193; Wed, 24 Nov 2010 05:37:17 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 3.09
Message-ID: <20101124133717.6183.11692.idtracker@localhost>
Date: Wed, 24 Nov 2010 05:37:17 -0800
Cc: ipfix@ietf.org
Subject: [IPFIX] Last Call:  (IPFIX	Mediation: Framework) to Informational RFC
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Nov 2010 13:37:17 -0000

The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'IPFIX Mediation: Framework'
   as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-12-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-mediators-framework/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-mediators-framework/


No IPR declarations have been submitted directly on this I-D.

From Quittek@neclab.eu  Thu Nov 25 00:05:56 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD6F828C0E9 for ; Thu, 25 Nov 2010 00:05:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.179
X-Spam-Level: 
X-Spam-Status: No, score=-102.179 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgI0fSTHMVz0 for ; Thu, 25 Nov 2010 00:05:56 -0800 (PST)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 0C8A328C0E7 for ; Thu, 25 Nov 2010 00:05:55 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C3FBF28000178; Thu, 25 Nov 2010 09:06:55 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRG-bxJkEQ3T; Thu, 25 Nov 2010 09:06:55 +0100 (CET)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 948452800015D; Thu, 25 Nov 2010 09:06:45 +0100 (CET)
Received: from DAPHNIS.office.hd ([169.254.2.241]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0255.000; Thu, 25 Nov 2010 09:06:40 +0100
From: Juergen Quittek 
To: Juergen Schoenwaelder , IETF IPFIX Working Group 
Thread-Topic: [IPFIX] flowStartSysUpTime and flowEndSysUpTime versus sysUpTime
Thread-Index: AcuMd6zm1M9Bn9Kznk6I/h5zlujy3A==
Date: Thu, 25 Nov 2010 08:06:39 +0000
Message-ID: 
In-Reply-To: <20101116123541.GA82517@elstar.local>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.7.0.100913
x-originating-ip: [10.1.2.39]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3373520795_75366290"
MIME-Version: 1.0
Subject: Re: [IPFIX] flowStartSysUpTime and flowEndSysUpTime versus sysUpTime
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Nov 2010 08:05:56 -0000

--B_3373520795_75366290
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi Juergen,

Thank you for this hint.
An alternative fix would be to align these counters more closely with
sysUpTime.

    Juergen Q.


On 16.11.10 13:35  "Juergen Schoenwaelder"
 wrote:

> Hi,
> 
> RFC 5102 has the following text:
> 
>    5.9.12.  flowStartSysUpTime
>    
>       Description:
>          The relative timestamp of the first packet of this Flow.  It
>          indicates the number of milliseconds since the last
>          (re-)initialization of the IPFIX Device (sysUpTime).
>       Abstract Data Type: unsigned32
>       ElementId: 22
>       Status: current
>       Units: milliseconds
>    
>    5.9.13.  flowEndSysUpTime
>    
>       Description:
>          The relative timestamp of the last packet of this Flow.  It
>          indicates the number of milliseconds since the last
>          (re-)initialization of the IPFIX Device (sysUpTime).
>       Abstract Data Type: unsigned32
>       ElementId: 21
>       Status: current
>       Units: milliseconds
> 
> I assume the "(sysUpTime)" refers to the definition given in RFC 3418:
> 
>    sysUpTime OBJECT-TYPE
>        SYNTAX      TimeTicks
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>                "The time (in hundredths of a second) since the
>                network management portion of the system was last
>                re-initialized."
>        ::= { system 3 }
> 
> Note that sysUpTime is counted in hundredths of a second and not
> milliseconds (means different rollover times) and that sysUpTime is
> counted from the last re-initialization of the network management
> portion of a system, which is not necessarily the same as the
> (re-)initialization of the IPFIX Device.
> 
> A possible fix is to remove any references to "(sysUpTime)" from RFC
> 5101.
> 
> /js

--B_3373520795_75366290
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIQ5wYJKoZIhvcNAQcCoIIQ2DCCENQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
Do8wggUzMIIEG6ADAgECAgQP7R53MA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY
MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1
cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu
Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTEwMDQyMDEyNDExMloXDTEzMDQxOTEyNDExMlow
YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD
IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANga4Hf5iSjDiva8/BTlatnXFlOWPfqZvY7AU6bt
CUKFiaGwytFar7XCwRggHcCeodYaMZoDRSEGY+bRUDvayjNvFTkhL19Fmzxg4MPmQA92tcIb
/+IylZD5YkVkw88/6zb6k+T+o875LlLAR79f8gvloaPMbxiB8KwQtdlGB9OiN1k3+7NiESpW
myT8WWrWw4F7qc0WLXaWuqv6/3vRo+jJSxyOwefEnzrRojCePJ2ZD4mgPMQvMHPqodDhTvIB
BupYoAtW53024WnL/PHH34pQ0Zmclz8u/YocnfMEYoyLDVuJKnQowDF75LVbnKmpXfCscKeb
SndFpSANP2TiI2cCAwEAAaOCAb8wggG7MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud
JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQU9WUPxjFB
AtJOXxJ7agqXozHDy9gwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHAYDVR0R
BBUwE4ERUXVpdHRla0BuZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NkcDEu
cGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6Ly9j
ZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEFBQcB
AQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2Ev
cHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2EuZGZu
LmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQADggEB
AH9VRaZ978LNoc+eM/2k/OQafNJl4UjKLjiEnH8FCuqnuNXZMAOdcfnMrRKK1bl+FhCy3sjg
gsuP4Nam2oSy7RDYWYjLY/MKMPO/MD/PpNSe6gox4948wfjWGmj4Uz3gqgDovQEC2H03jcPX
etJqBTipqmfnvMFqozoN5zjiEzJuuLpLMYNPM+E+4pQnLtRAhN94C1e9C7oP66b7as6OgVVC
CplE5llnoKM5ngtAFL5G3ygm/rZtptdmaNgRO6jDX1w9AOrsmSPGp+S+YRNonKGEqTolJpul
EJB7rMdAUimsUp/qdzvWrhIZ6A3fgzHwFhrIHqVBlDLmu7cQHu/QMUEwggUvMIIEF6ADAgEC
AgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVy
ZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwg
LSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMCREUx
GDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmllcyBF
dXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1
bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK6kKX
nTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDBaSa+
nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i/W+u
OQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMzVw94
Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQwggHA
MBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAvmfa+
FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREEJjAk
gSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9oDug
OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3Js
LmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIv
Y3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9j
ZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcG
CCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9j
YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEekP3l3
GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWclSZQ4
60jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yyPjzI
VPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS09mE
WRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkzJNfb
fEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUA
MHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQL
ExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv
b3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRF
MRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4t
VmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0
iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txP
eKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVY
J9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV
Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYw
cAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vydmlj
ZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09U
X0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu6
9VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0G
CSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0Z
MfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSF
PT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0
hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBn
qyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA
9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3Bl
IEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlORUNM
QUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu
ZXUCBA/tHncwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRkyLUMAlGfv1GufV8iTXoJ
2A94UTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDExMjUw
ODA2MzRaMA0GCSqGSIb3DQEBAQUABIIBAIRIjQ6fGhM8+JvnOQhA3+RZfeyB0nRE/Np2P582
bl5dA9RWBKIIipce+beU+iM9giCzyZb7+r4iNlwQiQl9lRZpwlFhYexJrVIC7dN8UkE/3Fgf
DHe6jc/urAoxrrorN+8ye2Fl0NyN2bhVbDAIEOZi1fO/G98YwTCOUiuPq5kpus4LSnc3+n7A
pNdWJnvqo9ICM8eD6WUvszXl8L6vBJhTvT/4wflC/DTBM8BEpst/SWRMeXCiXO3zncGXZVQz
yt9CG5I86vTh2dDwW2/faxdft5VnmWFCyqyXVwBsOI9q8ihVHoEt6e+mNjAjUqOj0xJD/PiR
KTFL2O38UTeOyXc=

--B_3373520795_75366290--

From trammell@tik.ee.ethz.ch  Thu Nov 25 06:01:53 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C902428C0EF for ; Thu, 25 Nov 2010 06:01:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vw1hq8s0pT1i for ; Thu, 25 Nov 2010 06:01:53 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id A7BA43A6A38 for ; Thu, 25 Nov 2010 06:01:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1F72FD9333; Thu, 25 Nov 2010 15:02:52 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GzR-FXPM5KgK; Thu, 25 Nov 2010 15:02:52 +0100 (MET)
Received: from mac-10243.ethz.ch (mac-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id B51EED9329; Thu, 25 Nov 2010 15:02:52 +0100 (MET)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Brian Trammell 
In-Reply-To: 
Date: Thu, 25 Nov 2010 15:02:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0EB25CB8-26BA-48BA-B4F5-CEF54DB7CFC7@tik.ee.ethz.ch>
References: 
To: Juergen Quittek 
X-Mailer: Apple Mail (2.1082)
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] flowStartSysUpTime and flowEndSysUpTime versus sysUpTime
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Nov 2010 14:01:53 -0000

Hi, Juergen and Juergen,

I always read the precision of the system uptime counter as being =
implementation-dependent (as experience shows it generally is). The =
units are milliseconds, but the actual precision is up to the device... =
Issues such as this, as I recall, are part of the reason for the advice =
on timing precision in RFC 5153. Indeed, not having much of an SNMP =
background I find the 3418 specification of sysUpTime to be a little =
odd.=20

sysUpTime (the IPFIX definition) follows the NetFlow V9 definition =
(itself specified in 3954 and canonically defined by Cisco's =
implementation thereof); changing it, at this point, is not =
interoperably possible. Therefore, I'd second the initial recommendation =
 and make it clear (perhaps in an erratum on 5102, and by editorially =
correcting the IANA registry) that sysUpTime is _not_ 3418 sysUpTime.

Best regards,

Brian

On Nov 25, 2010, at 9:06 AM, Juergen Quittek wrote:

> Hi Juergen,
>=20
> Thank you for this hint.
> An alternative fix would be to align these counters more closely with
> sysUpTime.
>=20
>    Juergen Q.
>=20
>=20
> On 16.11.10 13:35  "Juergen Schoenwaelder"
>  wrote:
>=20
>> Hi,
>>=20
>> RFC 5102 has the following text:
>>=20
>>   5.9.12.  flowStartSysUpTime
>>=20
>>      Description:
>>         The relative timestamp of the first packet of this Flow.  It
>>         indicates the number of milliseconds since the last
>>         (re-)initialization of the IPFIX Device (sysUpTime).
>>      Abstract Data Type: unsigned32
>>      ElementId: 22
>>      Status: current
>>      Units: milliseconds
>>=20
>>   5.9.13.  flowEndSysUpTime
>>=20
>>      Description:
>>         The relative timestamp of the last packet of this Flow.  It
>>         indicates the number of milliseconds since the last
>>         (re-)initialization of the IPFIX Device (sysUpTime).
>>      Abstract Data Type: unsigned32
>>      ElementId: 21
>>      Status: current
>>      Units: milliseconds
>>=20
>> I assume the "(sysUpTime)" refers to the definition given in RFC =
3418:
>>=20
>>   sysUpTime OBJECT-TYPE
>>       SYNTAX      TimeTicks
>>       MAX-ACCESS  read-only
>>       STATUS      current
>>       DESCRIPTION
>>               "The time (in hundredths of a second) since the
>>               network management portion of the system was last
>>               re-initialized."
>>       ::=3D { system 3 }
>>=20
>> Note that sysUpTime is counted in hundredths of a second and not
>> milliseconds (means different rollover times) and that sysUpTime is
>> counted from the last re-initialization of the network management
>> portion of a system, which is not necessarily the same as the
>> (re-)initialization of the IPFIX Device.
>>=20
>> A possible fix is to remove any references to "(sysUpTime)" from RFC
>> 5101.
>>=20
>> /js
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From bclaise@cisco.com  Thu Nov 25 08:04:34 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ADDB28C11D for ; Thu, 25 Nov 2010 08:04:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.547
X-Spam-Level: 
X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pX+5fFvIS-M for ; Thu, 25 Nov 2010 08:04:28 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 5683A28C13C for ; Thu, 25 Nov 2010 08:04:26 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAPFjWt4014605; Thu, 25 Nov 2010 16:45:32 +0100 (CET)
Received: from [10.55.43.54] (ams-bclaise-8715.cisco.com [10.55.43.54]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAPFjVoa003247; Thu, 25 Nov 2010 16:45:31 +0100 (CET)
Message-ID: <4CEE849B.70109@cisco.com>
Date: Thu, 25 Nov 2010 16:45:31 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Brian Trammell 
References:  <0EB25CB8-26BA-48BA-B4F5-CEF54DB7CFC7@tik.ee.ethz.ch>
In-Reply-To: <0EB25CB8-26BA-48BA-B4F5-CEF54DB7CFC7@tik.ee.ethz.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF IPFIX Working Group , Juergen Quittek 
Subject: Re: [IPFIX] flowStartSysUpTime and flowEndSysUpTime versus sysUpTime
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Nov 2010 16:04:34 -0000

Hi,
> Hi, Juergen and Juergen,
>
> I always read the precision of the system uptime counter as being implementation-dependent (as experience shows it generally is). The units are milliseconds, but the actual precision is up to the device... Issues such as this, as I recall, are part of the reason for the advice on timing precision in RFC 5153. Indeed, not having much of an SNMP background I find the 3418 specification of sysUpTime to be a little odd.
>
> sysUpTime (the IPFIX definition) follows the NetFlow V9 definition (itself specified in 3954 and canonically defined by Cisco's implementation thereof); changing it, at this point, is not interoperably possible. Therefore, I'd second the initial recommendation  and make it clear (perhaps in an erratum on 5102, and by editorially correcting the IANA registry) that sysUpTime is _not_ 3418 sysUpTime.
Agreed.

Regards, Benoit.
> Best regards,
>
> Brian
>
> On Nov 25, 2010, at 9:06 AM, Juergen Quittek wrote:
>
>> Hi Juergen,
>>
>> Thank you for this hint.
>> An alternative fix would be to align these counters more closely with
>> sysUpTime.
>>
>>     Juergen Q.
>>
>>
>> On 16.11.10 13:35  "Juergen Schoenwaelder"
>>   wrote:
>>
>>> Hi,
>>>
>>> RFC 5102 has the following text:
>>>
>>>    5.9.12.  flowStartSysUpTime
>>>
>>>       Description:
>>>          The relative timestamp of the first packet of this Flow.  It
>>>          indicates the number of milliseconds since the last
>>>          (re-)initialization of the IPFIX Device (sysUpTime).
>>>       Abstract Data Type: unsigned32
>>>       ElementId: 22
>>>       Status: current
>>>       Units: milliseconds
>>>
>>>    5.9.13.  flowEndSysUpTime
>>>
>>>       Description:
>>>          The relative timestamp of the last packet of this Flow.  It
>>>          indicates the number of milliseconds since the last
>>>          (re-)initialization of the IPFIX Device (sysUpTime).
>>>       Abstract Data Type: unsigned32
>>>       ElementId: 21
>>>       Status: current
>>>       Units: milliseconds
>>>
>>> I assume the "(sysUpTime)" refers to the definition given in RFC 3418:
>>>
>>>    sysUpTime OBJECT-TYPE
>>>        SYNTAX      TimeTicks
>>>        MAX-ACCESS  read-only
>>>        STATUS      current
>>>        DESCRIPTION
>>>                "The time (in hundredths of a second) since the
>>>                network management portion of the system was last
>>>                re-initialized."
>>>        ::= { system 3 }
>>>
>>> Note that sysUpTime is counted in hundredths of a second and not
>>> milliseconds (means different rollover times) and that sysUpTime is
>>> counted from the last re-initialization of the network management
>>> portion of a system, which is not necessarily the same as the
>>> (re-)initialization of the IPFIX Device.
>>>
>>> A possible fix is to remove any references to "(sysUpTime)" from RFC
>>> 5101.
>>>
>>> /js
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From descombes@lpsc.in2p3.fr  Fri Nov 26 02:11:31 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09E23A6AA6 for ; Fri, 26 Nov 2010 02:11:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2RvBuQdwVmE for ; Fri, 26 Nov 2010 02:11:28 -0800 (PST)
Received: from lpsc-mail.in2p3.fr (lpsc-mail.in2p3.fr [134.158.40.8]) by core3.amsl.com (Postfix) with ESMTP id A5F573A6AC6 for ; Fri, 26 Nov 2010 02:11:23 -0800 (PST)
Received: from [134.158.40.158] (lpsc0158x.in2p3.fr [134.158.40.158]) by lpsc-mail.in2p3.fr (8.13.1/8.13.1/In2p3) with ESMTP id oAQACJBG023656; Fri, 26 Nov 2010 11:12:19 +0100
Message-ID: <4CEF8803.5090401@lpsc.in2p3.fr>
Date: Fri, 26 Nov 2010 11:12:19 +0100
From: DESCOMBES Thierry 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100808 Mandriva/3.1.2-0.2mdv2010.1 (2010.1) Thunderbird/3.1.2
MIME-Version: 1.0
To: Benoit Claise 
References: <4CC7DE4E.6090009@lpsc.in2p3.fr> <4CEBB6D9.8040609@cisco.com>
In-Reply-To: <4CEBB6D9.8040609@cisco.com>
Content-Type: multipart/alternative; boundary="------------000800060204010701060604"
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] IPFIX flows timestamps
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Nov 2010 10:11:31 -0000

This is a multi-part message in MIME format.
--------------000800060204010701060604
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

  Hi Benoit,
Thanks for your answer.
> You should have a generic solution.
>
Yes, sure... But I must be certain that my generic algorithm can deal 
with most cases...
So, what is the current template data definition of Cisco switchs 
(mainly concerning the timestamp) ? Is it possible to configure them 
with all combinaisons of datatimestamps ? (With the 6000 series and 
NetFlow 9... Template data seems fixed and not configurable). With 
IPfix, are Cisco switches still using  "LAST_SWITCHED" and 
"FIRST_SWITCHED" fields ? If yes... why have you decided to remove the 
"sysuptime" field, and how should I guess the sysuptime to deal with 
this timestamps ?
Thanks a lot.
Cheers
T.D

--------------000800060204010701060604
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    Hi Benoit,

        Thanks for your answer.

      
    

      

      

      You should have a generic solution.

      

    

    Yes, sure... But I must be certain that my generic algorithm can
    deal with most cases...

    So, what is the current template data definition of Cisco switchs
    (mainly concerning the timestamp) ? Is it possible to configure them
    with all combinaisons of datatimestamps ? (With the 6000 series and
    NetFlow 9... Template data seems fixed and not configurable). With
    IPfix, are Cisco switches still using  "LAST_SWITCHED" and
    "FIRST_SWITCHED" fields ? If yes... why have you decided to remove
    the "sysuptime" field, and how should I guess the sysuptime to deal
    with this timestamps ?

    Thanks a lot.

    Cheers

    T.D

  


--------------000800060204010701060604--

From paitken@cisco.com  Fri Nov 26 04:01:11 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11DA23A6A25 for ; Fri, 26 Nov 2010 04:01:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.51
X-Spam-Level: 
X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[AWL=1.089,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+ZBPMlmmmWb for ; Fri, 26 Nov 2010 04:01:10 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1441828B797 for ; Fri, 26 Nov 2010 04:01:10 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.59,260,1288569600"; d="scan'208";a="186355213"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 26 Nov 2010 12:02:11 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAQC2ATu022008; Fri, 26 Nov 2010 12:02:10 GMT
Received: from [10.61.100.159] (dhcp-10-61-100-159.cisco.com [10.61.100.159]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id oAQC28805094; Fri, 26 Nov 2010 12:02:09 GMT
Message-ID: <4CEFA1C0.8040205@cisco.com>
Date: Fri, 26 Nov 2010 12:02:08 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10
MIME-Version: 1.0
To: "ipfix@ietf.org" 
References: <4C4E996E.2000300@net.in.tum.de> <4CA2F41E.7020900@cisco.com>	<4CC80C2E.1080105@net.in.tum.de> <4CC81ADD.5010802@cisco.com>
In-Reply-To: <4CC81ADD.5010802@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [IPFIX] Review: draft-ietf-ipfix-structured-data-02.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Nov 2010 12:01:11 -0000

Dear All,

Regarding this text:

     The Exporter SHOULD NOT check all semantically meaningless
     combinations before exporting the Data Record.

In recent versions this changed from "SHOULD NOT" to "doesn't have to" 
to "may".

The original intention was to say that the exporter should just do what 
it's told and export data coming from the metering process without 
additional validation.

However, it seems that some implementations may actually want to do this.

So we simply removed this line from the draft.

Thanks,
P.

>   Hi Gerhard,
>
> Thanks for the follow up.
> Changed in my temp version from:
>
>     The Exporter SHOULD NOT check all semantically meaningless
>     combinations before exporting the Data Record.
>
>
> To
>
>     The Exporting Process doesn't have to check all semantically
>     meaningless combinations before exporting the Data Record.
>
>
> Regards, Benoit.
>> Benoit,
>>
>> On 29.09.2010 10:09, Benoit Claise wrote:
>>>>>       The Exporter SHOULD NOT check all semantically meaningless
>>>>>       combinations before exporting the Data Record.
>>>> I do not understand.
>>>> SHOULD NOT =>  SHOULD
>>>> or
>>>> SHOULD NOT =>  "does not have to"
>>> does not have to.
>>> In IPFIX structured data, we can express some complex (or stupid)
>>> semantic. It's not the responsibility of the  exporter to check if what
>>> is encoded makes sense from a semantic point of view.
>> I do not see this comment addressed because "SHOULD NOT" still appears
>> in -03.
>> Are you actually talking about the Exporting Process and not the
>> Exporter? Then, you might want to replace "Exporter" as well.
>>
>> Regards,
>> Gerhard
>>
>>
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From Quittek@neclab.eu  Fri Nov 26 06:56:30 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2102328C0DC for ; Fri, 26 Nov 2010 06:56:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.188
X-Spam-Level: 
X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQttDdrv-k8Q for ; Fri, 26 Nov 2010 06:56:29 -0800 (PST)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 0AB6B3A694E for ; Fri, 26 Nov 2010 06:56:29 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 47FE12800017F; Fri, 26 Nov 2010 15:57:32 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGH3v-PjjFAl; Fri, 26 Nov 2010 15:57:32 +0100 (CET)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 263EA2800015D; Fri, 26 Nov 2010 15:57:17 +0100 (CET)
Received: from DAPHNIS.office.hd ([169.254.2.241]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0255.000; Fri, 26 Nov 2010 15:57:17 +0100
From: Juergen Quittek 
To: Benoit Claise , Brian Trammell 
Thread-Topic: [IPFIX] flowStartSysUpTime and flowEndSysUpTime versus sysUpTime
Thread-Index: AcuNejLrFblI05MW9UqmVUllZndueg==
Date: Fri, 26 Nov 2010 14:57:16 +0000
Message-ID: 
In-Reply-To: <4CEE849B.70109@cisco.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.7.0.100913
x-originating-ip: [10.1.2.39]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3373631829_81360079"
MIME-Version: 1.0
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] flowStartSysUpTime and flowEndSysUpTime versus sysUpTime
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Nov 2010 14:56:30 -0000

--B_3373631829_81360079
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Dear all,

On 25.11.10 16:45  "Benoit Claise"  wrote:

> Hi,
>> Hi, Juergen and Juergen,
>> 
>> I always read the precision of the system uptime counter as being
>> implementation-dependent (as experience shows it generally is). The units are
>> milliseconds, but the actual precision is up to the device... Issues such as
>> this, as I recall, are part of the reason for the advice on timing precision
>> in RFC 5153. Indeed, not having much of an SNMP background I find the 3418
>> specification of sysUpTime to be a little odd.
>> 
>> sysUpTime (the IPFIX definition) follows the NetFlow V9 definition (itself
>> specified in 3954 and canonically defined by Cisco's implementation thereof);
>> changing it, at this point, is not interoperably possible. Therefore, I'd
>> second the initial recommendation  and make it clear (perhaps in an erratum
>> on 5102, and by editorially correcting the IANA registry) that sysUpTime is
>> _not_ 3418 sysUpTime.
> Agreed.

Fine. Let's file an erratum.

    Juergen


> Regards, Benoit.
>> Best regards,
>> 
>> Brian
>> 
>> On Nov 25, 2010, at 9:06 AM, Juergen Quittek wrote:
>> 
>>> Hi Juergen,
>>> 
>>> Thank you for this hint.
>>> An alternative fix would be to align these counters more closely with
>>> sysUpTime.
>>> 
>>>     Juergen Q.
>>> 
>>> 
>>> On 16.11.10 13:35  "Juergen Schoenwaelder"
>>>   wrote:
>>> 
>>>> Hi,
>>>> 
>>>> RFC 5102 has the following text:
>>>> 
>>>>    5.9.12.  flowStartSysUpTime
>>>> 
>>>>       Description:
>>>>          The relative timestamp of the first packet of this Flow.  It
>>>>          indicates the number of milliseconds since the last
>>>>          (re-)initialization of the IPFIX Device (sysUpTime).
>>>>       Abstract Data Type: unsigned32
>>>>       ElementId: 22
>>>>       Status: current
>>>>       Units: milliseconds
>>>> 
>>>>    5.9.13.  flowEndSysUpTime
>>>> 
>>>>       Description:
>>>>          The relative timestamp of the last packet of this Flow.  It
>>>>          indicates the number of milliseconds since the last
>>>>          (re-)initialization of the IPFIX Device (sysUpTime).
>>>>       Abstract Data Type: unsigned32
>>>>       ElementId: 21
>>>>       Status: current
>>>>       Units: milliseconds
>>>> 
>>>> I assume the "(sysUpTime)" refers to the definition given in RFC 3418:
>>>> 
>>>>    sysUpTime OBJECT-TYPE
>>>>        SYNTAX      TimeTicks
>>>>        MAX-ACCESS  read-only
>>>>        STATUS      current
>>>>        DESCRIPTION
>>>>                "The time (in hundredths of a second) since the
>>>>                network management portion of the system was last
>>>>                re-initialized."
>>>>        ::= { system 3 }
>>>> 
>>>> Note that sysUpTime is counted in hundredths of a second and not
>>>> milliseconds (means different rollover times) and that sysUpTime is
>>>> counted from the last re-initialization of the network management
>>>> portion of a system, which is not necessarily the same as the
>>>> (re-)initialization of the IPFIX Device.
>>>> 
>>>> A possible fix is to remove any references to "(sysUpTime)" from RFC
>>>> 5101.
>>>> 
>>>> /js
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipfix
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
> 

--B_3373631829_81360079
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIQ5wYJKoZIhvcNAQcCoIIQ2DCCENQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
Do8wggUzMIIEG6ADAgECAgQP7R53MA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY
MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1
cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu
Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTEwMDQyMDEyNDExMloXDTEzMDQxOTEyNDExMlow
YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD
IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANga4Hf5iSjDiva8/BTlatnXFlOWPfqZvY7AU6bt
CUKFiaGwytFar7XCwRggHcCeodYaMZoDRSEGY+bRUDvayjNvFTkhL19Fmzxg4MPmQA92tcIb
/+IylZD5YkVkw88/6zb6k+T+o875LlLAR79f8gvloaPMbxiB8KwQtdlGB9OiN1k3+7NiESpW
myT8WWrWw4F7qc0WLXaWuqv6/3vRo+jJSxyOwefEnzrRojCePJ2ZD4mgPMQvMHPqodDhTvIB
BupYoAtW53024WnL/PHH34pQ0Zmclz8u/YocnfMEYoyLDVuJKnQowDF75LVbnKmpXfCscKeb
SndFpSANP2TiI2cCAwEAAaOCAb8wggG7MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud
JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQU9WUPxjFB
AtJOXxJ7agqXozHDy9gwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHAYDVR0R
BBUwE4ERUXVpdHRla0BuZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NkcDEu
cGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6Ly9j
ZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEFBQcB
AQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2Ev
cHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2EuZGZu
LmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQADggEB
AH9VRaZ978LNoc+eM/2k/OQafNJl4UjKLjiEnH8FCuqnuNXZMAOdcfnMrRKK1bl+FhCy3sjg
gsuP4Nam2oSy7RDYWYjLY/MKMPO/MD/PpNSe6gox4948wfjWGmj4Uz3gqgDovQEC2H03jcPX
etJqBTipqmfnvMFqozoN5zjiEzJuuLpLMYNPM+E+4pQnLtRAhN94C1e9C7oP66b7as6OgVVC
CplE5llnoKM5ngtAFL5G3ygm/rZtptdmaNgRO6jDX1w9AOrsmSPGp+S+YRNonKGEqTolJpul
EJB7rMdAUimsUp/qdzvWrhIZ6A3fgzHwFhrIHqVBlDLmu7cQHu/QMUEwggUvMIIEF6ADAgEC
AgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVy
ZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwg
LSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMCREUx
GDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmllcyBF
dXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1
bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK6kKX
nTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDBaSa+
nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i/W+u
OQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMzVw94
Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQwggHA
MBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAvmfa+
FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREEJjAk
gSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9oDug
OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3Js
LmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIv
Y3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9j
ZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcG
CCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9j
YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEekP3l3
GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWclSZQ4
60jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yyPjzI
VPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS09mE
WRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkzJNfb
fEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUA
MHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQL
ExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv
b3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRF
MRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4t
VmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0
iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txP
eKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVY
J9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV
Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYw
cAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vydmlj
ZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09U
X0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu6
9VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0G
CSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0Z
MfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSF
PT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0
hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBn
qyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA
9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3Bl
IEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlORUNM
QUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu
ZXUCBA/tHncwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQh+1IRuPQzqzjiwMzeYNlE
gwJwcTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDExMjYx
NDU3MDlaMA0GCSqGSIb3DQEBAQUABIIBADyI9rEdsrM1pe3KkAqTBHu4nnjpvoP/Q5lF2y8G
VS9MaSLLd6IqpOiW5cdnUFjtof8UFvKrnO/Zy0FdRmClV0DBJ9BiIrw/2wFbAYsH05HVogFa
sMwra9LQlCmH8pjX3M5b1Dy2tQpoINHFmUv577T5VqMPh5sp8YW0fPOjbDSxq2kthf1JwO9u
cal6azIRyc2qr5haiHKNaMarUNuK4GtkmnJiOxoA3c0XgR4MCIe3nwPdOWp/tfCdyHOP+lSD
Htv+XXBZFe/0GpMX/fTilV+33Q1vKx/f4tBU+DHlVqEyD54ibFehnmrD1dEdF/B6cSnKW00B
ZCVd1M0E5uia2XY=

--B_3373631829_81360079--

From kashima@nttv6.net  Fri Nov 26 12:15:19 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8BA28C102 for ; Fri, 26 Nov 2010 12:15:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5p-bgtBWvpIs for ; Fri, 26 Nov 2010 12:15:18 -0800 (PST)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id BD54C28C0E6 for ; Fri, 26 Nov 2010 12:15:17 -0800 (PST)
Received: from [127.0.0.1] (localhost [IPv6:::1]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id oAQKGF3m069903; Sat, 27 Nov 2010 05:16:19 +0900 (JST) (envelope-from kashima@nttv6.net)
Date: Sat, 27 Nov 2010 05:15:46 +0900
From: Shingo KASHIMA 
To: Juergen Quittek 
In-Reply-To: 
References: 
Message-Id: <20101127050703.DF03.1AB7FA03@nttv6.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.50.05 [ja]
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (mail.nttv6.net [IPv6:::1]); Sat, 27 Nov 2010 05:16:19 +0900 (JST)
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-psamp-mib-02
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Nov 2010 20:15:19 -0000

Deal all,

Please find one comment.

 > 3.  Introduction
 >
 >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 >    document are to be interpreted as described in RFC 2119 [RFC2119].
 >
 >    This document is a product of the IP Flow Information eXport (IPFIX)
 >    working group.  Work on this document was started in the Packet
 >    Sampling (PSAMP) Working Group (WG) and moved to the IPFIX WG when
 >    the PSAMP WG was concluded.
 >
 >    Its purpose is to define managed objects for monitoring PSAMP Devices
 >    performing packet selection by sampling and hashing as described in
 >    [RFC5475].

"sampling and hashing"
I think "sampling and filtering" is better.

Regards,
Shingo.

-- 
Shingo KASHIMA 
NTT Information Sharing Platform Lab.



From muenz@net.in.tum.de  Sat Nov 27 04:05:49 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B05C28C154 for ; Sat, 27 Nov 2010 04:05:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhaqSXZkqEAJ for ; Sat, 27 Nov 2010 04:05:48 -0800 (PST)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 1FE5F28C153 for ; Sat, 27 Nov 2010 04:05:47 -0800 (PST)
Received: from [192.168.1.151] (ppp-93-104-76-180.dynamic.mnet-online.de [93.104.76.180]) by mail.net.in.tum.de (Postfix) with ESMTPSA id B1308204235C for ; Sat, 27 Nov 2010 13:06:48 +0100 (CET)
Message-ID: <4CF0F459.3070001@net.in.tum.de>
Date: Sat, 27 Nov 2010 13:06:49 +0100
From: Gerhard Muenz 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: ipfix@ietf.org
References: <4CC7DE4E.6090009@lpsc.in2p3.fr> <4CEBB6D9.8040609@cisco.com> <4CEF8803.5090401@lpsc.in2p3.fr>
In-Reply-To: <4CEF8803.5090401@lpsc.in2p3.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [IPFIX] IPFIX flows timestamps
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Nov 2010 12:05:49 -0000

Hi Thierry,

On 26.11.2010 11:12, DESCOMBES Thierry wrote:
> Hi Benoit,
> Thanks for your answer.
>> You should have a generic solution.
>>
> Yes, sure... But I must be certain that my generic algorithm can deal
> with most cases...

If current Cisco products export one type of time stamp, the next router 
generation or routers from another vendor might still export another type.

So, if you want a generic algorithm, you need to be able to process all 
kinds of time stamps. Converting them to a common internal format of 
your choice (e.g. unix time measured in milliseconds) is not a big deal.

Regards,
Gerhard

> So, what is the current template data definition of Cisco switchs
> (mainly concerning the timestamp) ? Is it possible to configure them
> with all combinaisons of datatimestamps ? (With the 6000 series and
> NetFlow 9... Template data seems fixed and not configurable). With
> IPfix, are Cisco switches still using "LAST_SWITCHED" and
> "FIRST_SWITCHED" fields ? If yes... why have you decided to remove the
> "sysuptime" field, and how should I guess the sysuptime to deal with
> this timestamps ?
> Thanks a lot.
> Cheers
> T.D

From descombes@lpsc.in2p3.fr  Sun Nov 28 08:39:34 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09DBE28C10C for ; Sun, 28 Nov 2010 08:39:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Level: 
X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeB5KdbCE7Kp for ; Sun, 28 Nov 2010 08:39:33 -0800 (PST)
Received: from lpsc-mail.in2p3.fr (lpsc-mail.in2p3.fr [134.158.40.8]) by core3.amsl.com (Postfix) with ESMTP id 8E39228C10D for ; Sun, 28 Nov 2010 08:39:31 -0800 (PST)
Received: from lpsc.in2p3.fr (lpsc.in2p3.fr [134.158.40.162]) by lpsc-mail.in2p3.fr (8.13.1/8.13.1/In2p3) with ESMTP id oASGeR3G004510; Sun, 28 Nov 2010 17:40:27 +0100
MIME-Version: 1.0
Date: Sun, 28 Nov 2010 17:40:26 +0100
From: descombes 
To: Gerhard Muenz 
In-Reply-To: <4CF0F459.3070001@net.in.tum.de>
References: <4CC7DE4E.6090009@lpsc.in2p3.fr> <4CEBB6D9.8040609@cisco.com> <4CEF8803.5090401@lpsc.in2p3.fr> <4CF0F459.3070001@net.in.tum.de>
Message-ID: <2185b5dec523a37626b9d7cde312c4ca@lpsc-mail>
X-Sender: descombes@lpsc-mail
User-Agent: RoundCube Webmail/0.3.1
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] IPFIX flows timestamps
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Nov 2010 16:39:34 -0000

Hi Gerhard,

> If current Cisco products export one type of time stamp, the next router

> generation or routers from another vendor might still export another
type.

Yes, you're right... anyway, my aim is not to write a wonderful generic
algorithm, which can deal with all combinaison of timestamp fields, that
I'll never get, since... no current Ipfix implementation is able to send
them ! If Cisco implementation just send "LAST_SWITCHED" and
"FIRST_SWITCHED" fields... I can't guess the sysuptime, and it's not worth
I bother me: whatever algorithm I do, my software will just work with
NetFlow 9.

So, what's the situation ?
Cheers,

T.D


> 
> So, if you want a generic algorithm, you need to be able to process all 
> kinds of time stamps. Converting them to a common internal format of 
> your choice (e.g. unix time measured in milliseconds) is not a big deal.
> 
> Regards,
> Gerhard
> 
>> So, what is the current template data definition of Cisco switchs
>> (mainly concerning the timestamp) ? Is it possible to configure them
>> with all combinaisons of datatimestamps ? (With the 6000 series and
>> NetFlow 9... Template data seems fixed and not configurable). With
>> IPfix, are Cisco switches still using "LAST_SWITCHED" and
>> "FIRST_SWITCHED" fields ? If yes... why have you decided to remove the
>> "sysuptime" field, and how should I guess the sysuptime to deal with
>> this timestamps ?
>> Thanks a lot.
>> Cheers
>> T.D
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix

From bclaise@cisco.com  Sun Nov 28 19:29:28 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DBCD28C129 for ; Sun, 28 Nov 2010 19:29:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.637
X-Spam-Level: 
X-Spam-Status: No, score=0.637 tagged_above=-999 required=5 tests=[AWL=-3.134,  BAYES_50=0.001, DATE_IN_PAST_06_12=1.069, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_83=0.6, MANGLED_PENIS=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nELg1OyZ8bpy for ; Sun, 28 Nov 2010 19:29:19 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 74CDB28C12D for ; Sun, 28 Nov 2010 19:29:18 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAT3UQ8M004945; Mon, 29 Nov 2010 04:30:26 +0100 (CET)
Received: from [10.21.82.246] (sjc-vpn4-758.cisco.com [10.21.82.246]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAT3UMEi019280; Mon, 29 Nov 2010 04:30:22 +0100 (CET)
Message-ID: <4CF29569.2070708@cisco.com>
Date: Sun, 28 Nov 2010 18:46:17 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Paul Aitken 
References: <4CD9C807.7060205@cisco.com>
In-Reply-To: <4CD9C807.7060205@cisco.com>
Content-Type: multipart/alternative; boundary="------------050209080709000606050008"
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] review of draft-trammell-ipfix-ie-doctors-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Nov 2010 03:29:28 -0000

This is a multi-part message in MIME format.
--------------050209080709000606050008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Paul,

Thanks for excellent review..
I will address the important points in line.
> Brian, Benoit,
>
> Please find review comments inline.
>
> Thanks,
> P.
>
>> IPFIX Working Group                                          B. Trammell
>> Internet-Draft                                                ETH Zurich
>> Intended status: BCP                                           B. Claise
>> Expires: April 4, 2011                                     Cisco Systems
>>                                                           October 1, 2010
>>
>>
>>     Guidelines for Authors and Reviewers of IPFIX Information Elements
>>                   draft-trammell-ipfix-ie-doctors-00.txt
>>
>> Abstract
>>
>>     This document provides guidelines for the definition of IPFIX
>>     Information Elements for addition to the IANA IPFIX Information
>>     Element registry, in order to extend the applicability of the IPFIX
>>     protocol to new operations and management areas.
>>
>> Status of this Memo
>>
>>     This Internet-Draft is submitted in full conformance with the
>>     provisions of BCP 78 and BCP 79.
>>
>>     Internet-Drafts are working documents of the Internet Engineering
>>     Task Force (IETF).  Note that other groups may also distribute
>>     working documents as Internet-Drafts.  The list of current Internet-
>>     Drafts is athttp://datatracker.ietf.org/drafts/current/.
>>
>>     Internet-Drafts are draft documents valid for a maximum of six months
>>     and may be updated, replaced, or obsoleted by other documents at any
>>     time.  It is inappropriate to use Internet-Drafts as reference
>>     material or to cite them other than as "work in progress."
>>
>>     This Internet-Draft will expire on April 4, 2011.
>>
>> Copyright Notice
>>
>>     Copyright (c) 2010 IETF Trust and the persons identified as the
>>     document authors.  All rights reserved.
>>
>>     This document is subject to BCP 78 and the IETF Trust's Legal
>>     Provisions Relating to IETF Documents
>>     (http://trustee.ietf.org/license-info) in effect on the date of
>>     publication of this document.  Please review these documents
>>     carefully, as they describe your rights and restrictions with respect
>>     to this document.  Code Components extracted from this document must
>>     include Simplified BSD License text as described in Section 4.e of
>>     the Trust Legal Provisions and are provided without warranty as
>>     described in the Simplified BSD License.
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                 [Page 1]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>> Table of Contents
>>
>>     1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
>>       1.1.  Intended Audience and Usage  . . . . . . . . . . . . . . .  3
>>       1.2.  Overview of relevant IPFIX documents . . . . . . . . . . .  4
>>     2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
>>     3.  How to apply IPFIX . . . . . . . . . . . . . . . . . . . . . .  5
>>     4.  Defining new Information Elements  . . . . . . . . . . . . . .  6
>>       4.1.  Information Element naming . . . . . . . . . . . . . . . .  6
>>       4.2.  Information Element data types . . . . . . . . . . . . . .  7
>>       4.3.  Ancillary Information Element properties . . . . . . . . .  7
>>       4.4.  Internal structure in Information Elements . . . . . . . .  8
>>       4.5.  Enumerated Values and Subregistries  . . . . . . . . . . .  9
>>       4.6.  Reversibility as per RFC 5103  . . . . . . . . . . . . . .  9
>>     5.  The Information Element Lifecycle: Revision and Deprecation  . 10
>>     6.  When not to define new Information Elements  . . . . . . . . . 12
>>       6.1.  Maximizing reuse of existing Information Elements  . . . . 12
>>       6.2.  Applying enterprise-specific Information Elements  . . . . 13
>>     7.  Applying IPFIX to non-Flow Applications  . . . . . . . . . . . 14
>>     8.  Defining Recommended Templates . . . . . . . . . . . . . . . . 14
>>     9.  A Textual Format for Specifying Information Elements and
>>         Templates  . . . . . . . . . . . . . . . . . . . . . . . . . . 15
>>       9.1.  Information Element Specifiers . . . . . . . . . . . . . . 16
>>       9.2.  Specifying Templates . . . . . . . . . . . . . . . . . . . 18
>>       9.3.  Specifying IPFIX Structured Data . . . . . . . . . . . . . 18
>>     10. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
>>     11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
>>     12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
>>     13. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 20
>>     14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
>>       14.1. Normative References . . . . . . . . . . . . . . . . . . . 20
>>       14.2. Informative References . . . . . . . . . . . . . . . . . . 21
>>     Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                 [Page 2]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>> 1.  Introduction
>>
>>     This document provides guidelines for the extension of the
>>     applicability of the IP Flow Information Export (IPFIX) protocol to
>>     network operations and management purposes outside the initial scope
>>     defined in "IPFIX Applicability Statement" [RFC5472].  These new
>>     applications areis  largely defined through the definition of new
>>    
>
> Remove "is".
>
>>     Information Elements beyond those defined in the IPFIX Information
>>     Model [RFC5102] or already added to the IANA IPFIX Information
>>     Element Registry [iana-ipfix-assignments].  New applications may be
>>     further specified through additional RFCs defining and describing
>>     their  usage.
>>    
>
> Ambiguous "their": seems like new applications, rather than 
> Information Elements.
>
>>     We intend this document to enable the expansion of the applicability
>>     of IPFIX to new areas by experts in the working group or area
>>     directorate concerned with the technical details of the protocol or
>>     application to be measured or managed using IPFIX.  This expansion
>>     would occur with the consultation of IPFIX experts informally called
>>     'IE-Doctors'.  It provides guidelines both for those defining new
>>     Information Elements as well as the IE-Doctors reviewingthem.
>>    
>
> Ambiguous "them": seems like "those defining new Information Elements".
>
>> 1.1.  Intended Audience and Usage
>>
>>     This document is meant for two separate audiences.  For IETF
>>     contributors extending the applicability of IPFIX, it provides a set
>>     of guidelines and best practices to be used in deciding which
>>     Information Elements are necessary for a given application, defining
>>     these Information Elements, and deciding whether an RFC should be
>>     published to further describe the application.  For the IPFIX experts
>>     appointed as IE-Doctors, and for IANA personnel changing the
>>     Information Element registry, it defines a set of acceptance criteria
>>     against which these proposed Information Elements should be
>>     evaluated.
>>
>>     This document is not intended to guide the extension of the IPFIX
>>     protocol itself, e.g. through new export mechanisms, data types, or
>>     the like; these activities should be pursued through the publication
>>     of standards-track RFCs by the IPFIX Working Group.
>>
>>     This document specifies additional practices beyond those appearing
>>     in the IANA Considerations sections of existing IPFIX documents,
>>     especially the Information Model [RFC5102].  The practices outlined
>>     in this document are intended to guide experts when making changes to
>>     the IANA registry under Expert Review as defined in [RFC5226].
>>
>>
>>
>>
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                 [Page 3]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>> 1.2.  Overview of relevant IPFIX documents
>>
>>     [RFC5101] defines the IPFIX Protocol, the IPFIX-specific terminology
>>     used by this document,and the data type encodings  for each of the
>>     data types supported by IPFIX.
>>    
>
> Not entirely true; it defines the initial set of data types as an 
> extensible registry. There are already drafts proposing new IPFIX data 
> types beyond RFC5101. Therefore the IANA IPFIX registry is the master, 
> rather than any of the IPFIX RFCs.
Good point.
>
>>     [RFC5102] defines the initial IPFIX Information Model, as well as
>>     procedures for extending the Information Model.  It states that new
>>     Information Elements may be added to the Information Model on Expert
>>     Review basis, and delegates the appointment of experts to an IESG
>>     Area Director.  This document is intended to further codify the best
>>     practices to be followed by these experts, in order to improve the
>>     efficiency of this process.
>>
>>     [RFC5103] defines a method for exporting bidirectional flow
>>     information using IPFIX; this document should be followed when
>>     extending IPFIX to represent information about bidirectional network
>>     interactions in general.  Additionally, new Information Elements
>>     should be annotated  for their reversibility or lack thereof as per
>>     this document.
>>    
>
> Where is this annotation to be recorded? AFAIK there's currently 
> nowhere to do this in the IANA registry, yet there's no requirement to 
> create any other document before creating new IEs.
Isn't part of the description in the IPFIX IANA?
>
>>     [RFC5610] defines a method for exporting information about
>>     Information Elements inline within IPFIX.  In doing so, it explicitly
>>     defines a set of implicit restrictions on the use of data types and
>>     semantics; these restrictions MUST be observed in the definition of
>>     new Information Elements, as inSection 4.3.
>>    
>
> Ambiguous "Section 4.3". 5610 doesn't have a section 4.3. Say "Section 
> 4.3 below.". Throughout the document, please makes it clear whether 
> you're referring to sections in this doc or in other RFCs.
>
>> 2.  Terminology
>>
>>     Capitalized terms used in this document that are defined in the
>>     Terminology section of [RFC5101] are to be interpreted as defined
>>     there.
>>
>>     An "application", as used in this document, refers to a candidate
>>     protocol, task, or domain to which IPFIX export, collection, and/or
>>     storage is applied, beyond those within the IPFIX Applicability
>>     statement [RFC5472].  By this definition, PSAMP [RFC5476] was the
>>     first new IPFIX application after the publication of the IPFIX
>>     protocol [RFC5101].
>>
>>     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>>     document are to be interpreted as described in [RFC2119].
>>
>>
>>
>>
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                 [Page 4]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>> 3.  How to apply IPFIX
>>
>>     Though originally specified for the export of IP flow information,
>>     the message format, template mechanism, and data model specified by
>>     IPFIX lead to it being applicable to a wide variety of network
>>     management situations.  In addition to flow information export, for
>>     which it was designed, and packet information export as specified by
>>     PSAMP [RFC5476], any application with the following characteristics
>>     is a good candidate for an IPFIX application:
>>
>>     o  The application's data flow is fundamentally unidirectional.
>>        IPFIX is a "push" protocol, supporting only the export of
>>        information from a sender (an Exporting Process) to a receiver (a
>>        Collecting Process).  Request-response interactions are not
>>        supported by IPFIX.
>>
>>     o  The application handles discrete event information, or information
>>        to be periodically reported.  IPFIX is particularly well suited to
>>        representing events, which can be scoped in time.
>>
>>     oThe application handles information about network entities.
>>        IPFIX's information model is network-oriented, so network
>>        management applications have many opportunities for information
>>        model reuse.
>>    
>
> No; this is contrary to the Abstract. I can export anything over IPFIX 
> that I can define an IE for. 
Again good point.
> With suitable IEs, it would even be possible to tunnel other protocols 
> over IPFIX!
>
>>     o  The application requires a small number of arrangements of data
>>        structures relative to the number of records it handles.  The
>>        template-driven self-description mechanism used by IPFIX excels at
>>        handling large volumes of identically structured data, compared to
>>        representations which define structure inline with data (such as
>>        XML).
>>
>>     Most applications meeting these criteria can be supported over IPFIX.
>>     Onceit's  been determined that IPFIX is a good fit, the next step is
>>    
>
> "it's" = "it is", not "it has".
>
>>     determining which Information Elements are necessary to represent the
>>     information required by the application.  Especially for network-
>>     centric applications, the IPFIX Information Element registry may
>>     already contain all the necessary Information Elements (see
>>     Section 6.1 for guidelines on maximizing Information Element reuse).
>>    
>>     In this case, no additional work within the IETF is necessary: simply
>>     define Templates and start exporting.
>>
>>     It is expected, however, that most applications will be able to reuse
>>     some existing Information Elements, but must define some additional
>>     Information Elements to support all their requirements; in this case,
>>     see Section 4 for best practices to be followed in defining
>>     Information Elements.
>>    
>>
>> Trammell&  Claise         Expires April 4, 2011                 [Page 5]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>>     Optionally, a Working Group or individual contributor may choose to
>>    
>
> You should detail "Optionally". New IEs don't need an RFC, but some 
> applications may require changes to the IPFIX protocol which do 
> require an RFC.
This was discussed during the IPFIX working group: unless really really 
required, don't create a RFC for new IEs allocation.
>
>>     publish an RFC detailing the new IPFIX application.  Such an RFC
>>     should contain discussion of the new application, the Information
>>     Element definitions as in Section 4, as well assuggested Templates
>
> Good grief, I can't believe I just read that!
>
> Perhaps the fields may be specified, but that's about as far as I'd 
> go. Suggesting templates is something for the implementer to do in his 
> software design, and not something to be specified in, or slavishly 
> copy from, RFCs. More on this below.
Bad wording.
What we mean is for example the specific Options Templates in the IPFIX 
or PSAMP protocol
>
>>     and examples of the use of those Templates within the new application
>>     as in Section 8.  Section 9 defines a compact textual Information
>>     Element notation to be used in describing these suggested Templates
>>     and/or the use of IPFIX Structured Data
>>     [I-D.ietf-ipfix-structured-data] within the new application.
>>    
>
> This last line seems jammed in without reference to the foregoing 
> text. A new paragraph might be better.
>
>> 4.  Defining new Information Elements
>>
>>     In many cases, a new application will require nothing more than a new
>>     Information Element or set of Information Elements to be exportable
>>     using IPFIX.  An Information Element meeting the following criteria,
>>     as evaluated by appointed IPFIX experts, is eligible for inclusion in
>>     theInformation Element registry:
>>    
>
> Xref with [IANA] URL.
>
>>     o  The Information Element MUST be sufficiently unique within the
>>        registry.  A proposed Information Elements  which is a substantial
>>    
>
> Typo.
>
>>        duplicate of an exiting Information Element is to be represented
>>        using the existing Element.
>>    
>
> Yes and no:
>
> If a new element simply adds a new value to an existing element, then 
> it can be considered as extending the value registry for that element, 
> which is considerably better than creating a new element for each new 
> value. However, how are implementers to track when new values are 
> added? An exporter and collector may interoperate just fine until the 
> exporter is updated to a newer version of the IPFIX info model, where 
> a certain IE now includes an additional value which the collector 
> doesn't understand. Since both have previously implemented this field 
> and interoperated successfully, how are we to know that this potential 
> failure now exists - other than exhaustively testing every field / 
> value combination?
>
> Again, if a new element extends the functionality of an existing 
> element in a small way - while substantially duplicating all the 
> existing functionality of the existing element - then again the new 
> element introduces a lack of interoperability.
>
> Potentially these issues may be solved with clear version tracking.
exactly.
Discussing with Brian in Beijing, we think that one (if not the only 
one) solution would be to have a version number for IPFIX IANA registry. 
Everything single time something is changed in it (new IE, extra value 
for a sub registry, etc...), the version number would be incremented.
>
>>     o  The Information Element SHOULD contain minimal internal structure;
>>        complex information should be represented with multiple simple
>>        Information Elements to be exported in parallel, as in
>>        Section 4.4.
>>    
>
> Or be represented with structured data, if the elements form a 
> structure or other composite unit of data.
As discussed during the last IPFIX meeting, basicList is fine. Not sure 
yet regarding subTemplateList and subTemplateMultiList
>
>>     o  The Information Element SHOULD be generally applicable to the
>>        application at hand,
>
> Meaning, don't request irrelevant elements? Why would anyone do that?
>
>>   which SHOULD be of general interest to the
>>        community.  Information Elements representing information about
>>        proprietary or nonstandard applications SHOULD be represented
>>        using enterprise-specific Information Elements as detailed in
>>        section 6.2 of [RFC5101].
>>
>>     The definition of new Information Elements requires a descriptive
>>     name, a specification of the data type as one from the IPFIX Data
>>     Type Registry, and a human-readable description written in English.
>>    
>
> Also semantics, units, range (which are all eventually discussed 
> below), and reference and requester info.
>
> The reference is especially important to allow others to clarify any 
> ambiguity with the new IE.
yes.
>
> Ideally the requester should be a generic or team email address 
> (rather than a single personal address) where relevant experts can 
> still be reached even if the original requester isn't available or has 
> moved on.
yes.
>
>>     This section provides guidelines on each of these components of an
>>     Information Element definition, referring to existing documentation
>>     such as [RFC5102] as appropriate.
>>
>> 4.1.  Information Element naming
>>
>>     Information Element Names should be defined in accordance with
>>     section 2.3 of [RFC5102]; the most important naming conventions are
>>     repeated here for convenience.
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                 [Page 6]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>>     o  Names of Information Elements should be descriptive.
>>
>>     o  Names of Information Elements MUST be unique within the IPFIX
>>        information model.
>>
>>     o  Names of Information Elements start with non-capitalized letters.
>>
>>     o  Composed names use capital letters for the first letter of each
>>        component (except for the first one).  All other letters are non-
>>        capitalized, even for acronyms.  Exceptions are made for acronyms
>>        containing non-capitalized letter, such as 'IPv4' and 'IPv6'.
>>        Examples are sourceMacAddress and destinationIPv4Address.
>>
>>     In addition, new Information Elements pertaining to a specific
>>     protocol SHOULD name the protocol in the first word in order to ease
>>     searching by name (e.g. "sipMethod" for a SIP method, as would be
>>     used in a logging format for SIP based on IPFIX).  Similarly, new
>>     Information Elements pertaining to a specific application SHOULD name
>>     the application in the first word.
>>
>> 4.2.  Information Element data types
>>
>>     IPFIX provides a set of data types covering most primitives used in
>>     network measurement and management applications.  The most
>>     appropriate data type should be chosen for the Information Element
>>     type.
>>
>>     Because IPFIX provides reduced-length encoding for Information
>>     Elements, unless an integral Information Element is derived from a
>>     fixed-width field in a measured protocol (e.g., tcpSequenceNumber,
>>     which is an unsigned32), it should be defined with the maximum
>>     possible  width, generally signed64 or unsigned64.  Applications can
>>    
>
> Then all new elements would be defined as 64-bits. Perhaps "maximum 
> foreseeable" or "maximum likely" would be better?
yes.
>
>>     then choose to use reduced-size encoding as defined in Section 6.2 of
>>     [RFC5101] in cases where fewer than 2^64 values are necessary.
>>    
>
> So why don't we just do away with the size specification and specify 
> only the type (signed, unsigned, ...)? Collectors can presume to 
> allocate 64 bit fields, while the actual size being exported is 
> encoded in the IPFIX template.
  Because some IE would clearly less 64 bits.  Example: TOS. So no point 
to waste any space in a DB.
>
>>     Information Elements representing time values should be exported with
>>     appropriate precision.  For example, a Information Element for a time
>>     measured at second-level precision should be defined as having a
>>     dateTimeSeconds data type, instead of dateTimeMilliseconds.
>>
>> 4.3.  Ancillary Information Element properties
>>
>>     Information Elements with numeric types and special semantics SHOULD
>>     define these semantics with one of the values in the Information
>>     Element Semantics registry, as described in Section 3.2 of [RFC5102],
>>     subject to the restrictions given in Section 3.10 of [RFC5610];
>>     essentially, the semantics and the type must be consistent.
>>
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                 [Page 7]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>>     When defining Information Elements representing a dimensioned
>>     quantity or entity count, the units of that quantity SHOULD be
>>     defined in the units field.This field takes its values from the
>>     IANA Information Element Units registry.  If an Information Element
>>     expresses a quantity in units not yet in this registry, then the unit
>>     must be added to the Units registry at the same time the Information
>>     Element is added to the Information Element registry.
>>    
>
> Similar text for both data types and semantics, please.
>
>>     Additionally, when the range of values an Information Element can
>>     take is smaller than the range implied by its data type, the range
>>     SHOULD be definedwithin the Information Element registry.
>>    
>
> More exactly, as part of the IE definition.
>
>> 4.4.  Internal structure in Information Elements
>>
>>     Unless defining an Information Element which is a direct copy of a
>>     bitfield or other structured entity (e.g., the tcpControlBits
>>     Information Element for the Flags byte from the TCP header)in a
>>     measured protocol, the definition of Information Elements with
>>    
>
> I think it would read better with this text before the parenthesised 
> example.
> ie, give the example *after* the explanation.
>
>>     internal structure with the structure defined in the Description
>>     field is discouraged.  In this case, the field SHOULD be decomposed
>>     into multiple primitive Information Elements to be used in parallel.
>>    
>
> There's a danger here, when there are multiple instances of the field. 
> So instead of exporting multiple instances of a single structured 
> field, "X:Y" like so:
>
>      { X:Y, X:Y, X:Y }
>
> we prefer to export multiple instances of the broken down fields:
>
>     { X, Y, X, Y, X, Y }
>
> - which may make sense, if the collector knows to relate the first X 
> and Y together, the second X with the second Y etc...
>
> However, the following is also quite legitimate:
>
>     { X, X, X, Y, Y, Y }
>
> Again it follows the same rule: first X relates to first Y etc. 
> However, now it's a lot less clear that X and Y are related. Yet it's 
> not any less valid.
Let us address this one.
>
>>     For more complicated semantics, where the structuremay not haveuse
>>     the IPFIX Structured Data [I-D.ietf-ipfix-structured-data] extension
>>     instead.
>>    
>
> Missing text? Where the structure may not have... what?
>
>>     As an example of information element decomposition, consider an
>>     application-level identifier called an "endpoint", which represents a
>>     {host, port, protocol} tuple.  Instead of allocating an opaque,
>>     structured "source endpoint" Information Element, the source endpoint
>>     should be represented by three separate Information Elements: "source
>>     address", "source port", "transport protocol".  Indeed, in this
>>     example, the required information elements already exist in the
>>     Information Element registry: sourceIPv4Address or sourceIPv6Address,
>>     sourceTransportPort, protocolIdentifier.  Indeed, as well as being
>>     good practice, this normalization down to non-structured Information
>>     Elements also increases opportunities for reuse as in Section 6.1.
>>    
>
> This example is perfect for structured data.
>
>>     The decomposition of data with internal structure SHOULD avoid the
>>     definition of Information Elements with a meaning too specific to be
>>     generally useful, or that would result in either the export of
>>     meaningless data or a multitude of templates to handle different
>>     multiplicities.  A specific example of this within the IANA registry
>>     is the following list of assigned IPFIX Information Elements:
>>     mplsTopLabelStackSection, mplsLabelStackSection2,
>>     mplsLabelStackSection3, mplsLabelStackSection4,
>>     mplsLabelStackSection5, mplsLabelStackSection6
>>     mplsLabelStackSection7, mplsLabelStackSection8,
>>     mplsLabelStackSection9, and mplsLabelStackSection10.  The only
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                 [Page 8]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>>     distinction between those almost-identical Information Elements is
>>     the position within the MPLS stack.  This Information Element design
>>     pattern met an early requirement of the definition of IPFIX which was
>>     not carried forward into the final specification -- namely, that no
>>     semantic dependency was allowed between Information Elements in the
>>     same Record -- and as such SHOULD NOT be followed in the definition
>>     of new Information Elements.  In this case, since the size of the
>>     MPLS stack will vary from flow to flow, it should be exported using
>>     IPFIX Structured Data [I-D.ietf-ipfix-structured-data] where
>>     supported, as a basicList of MPLS label entries.
>>
>>     Note that a Template may contain multiple instances of the same
>>     Information Element; in this case,the  each of the Information
>>    
>
> Typo.
>
>>     Elements in the Template are semantically indistinguishable, and
>>     appear in their "natural" order, where natural order is defined
>>     according to application; PSAMP uses this for exporting selectors.
>>     Multiple IEs used in this way are preferable to IEs with internal
>>     structure, but only when there is some natural order, and no semantic
>>     interdependence among the elements.
>>
>> 4.5.  Enumerated Values and Subregistries
>>
>>     When defining an Information Element that takes an enumerated value
>>     from a set of values which may change in the future, this enumeration
>>     MUST be defined by an IANA registry or subregistry.  For situations
>>     where an existing registry defines the enumeration (e.g., the IANA
>>     Protocol Numbers registry for the protocolIdentifier Information
>>     Element), that registry MUST be used.  Otherwise, a new IPFIX
>>     subregistry must be defined for the enumerated value, to be modified
>>     subject to Expert Review [RFC5226].
>>    
>
> There's some ongoing discussion with Nevil as to whether 
> sub-registries should be used, or whether the values can be recorded 
> directly in the element description.
>
> Again, the version control issue...
>
>> 4.6.  Reversibility as per RFC 5103
>>
>>     [TODO: fix this para][RFC5103] defines a method for exporting
>>     bidirectional flows using a special Private Enterprise Number to
>>     define reverse-direction variants of IANA Information Elements, and a
>>     set of criteria for determining whether an Information Element may be
>>     reversed using this method.  Section 6.1 of [RFC5103] states that CPs
>>     should use the set of criteria therein to determine reversibility.
>>     Since almost all Information Elements are reversible, these criteria
>>     are expressed as to determine the exceptions, i.e. which Information
>>     Elements are NOT reversible.
>>
>>     To ease the determination of reversibility, future Information
>>     Elements which are NOT reversible SHOULD note this fact in the
>>     description at the time of definition.
>>    
>
> Can you include some examples of non-reversible elements?
>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                 [Page 9]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>> 5.  The Information Element Lifecycle: Revision and Deprecation
>>
>>     The Information Element status field in the Information Element
>>     Registry is defined in [RFC5102] to allow Information Elements to be
>>     'deprecated' or 'obsolete'.  No Information Elements are as of this
>>     writing deprecated,and but provides no further explanation of these
>>     statuses, [RFC5102] does not define any policy for using them.
>>    
>
> This doesn't make sense.
>
>>     Additionally, no policy is defined for revising Information Element
>>     registry entries or addressing errors therein.  To be certain,
>>     changes and deprecations within the Information Element registry are
>>     not encouraged, and should be avoided to the extent possible.
>>    
>
> Clarify whether addition of new values is a change.
>
>>     However, in recognition that change is inevitable, this section is
>>     intended to remedy this situation.
>>
>>     The primary requirement in the definition of a policy for managing
>>     changes to existing Information Elements is avoidance of
>>     interoperability problems; IPFIX experts appointed to review changes
>>     to the Information Element Registry MUST work to maintain
>>     interoperability above all else.  Changes to Information Elements
>>     already in use may only be done in an interoperable way; necessary
>>     changes which cannot be done in a way to allow interoperability with
>>     unchanged implementations MUST result in deprecation.
>>
>>     A change to an Information Element is held to be interoperable only
>>     when:
>>
>>     o  it involves the correction of an error which is obviously only
>>        editorial; or
>>
>>     o  it corrects an ambiguity in the Information Element's definition,
>>        which itself leads to non-interoperability (e.g., a prior change
>>        to ipv6ExtensionHeaders); or
>>    
>
> Cite the errata for this:
>
> http://www.rfc-editor.org/errata_search.php?eid=1738
>
>>     o  it expands the Information Element's data type without changing
>>        how it is represented (e.g., changing unsigned32 to unsigned64, as
>>        with a prior change to selectorId); or
>>    
>
> http://www.rfc-editor.org/errata_search.php?eid=2052
>
>>     o  it defines a previously undefined or reserved enumerated value, or
>>        one or more previously reserved bits in an Information Element
>>        with flag semantics; or
>>
>>     o  it expands the set of permissible values in the Information
>>        Element's range; or
>>    
>
> These two changes may NOT be interoperable.
>
> eg, an exporter reporting an additional (new) value to a collector 
> which hasn't been updated to understand that new value (though the 
> collector was 100% IPFIX compliant at the time of implementation).
>
> Somewhere in here you should discuss version control of the IANA 
> registry, so every change is clearly called out. Find out how other 
> protocols deal with change.
Yes. Same issue as discussed above.
>
>>     o  it harmonizes with an external reference which was itself
>>        corrected.
>>    
>
> This is a potentially dangerous change. The correct route may be to 
> deprecate the wrongly defined IE and create a new IE with the correct 
> definition.
>
>>     A non-interoperable Information Element change may also be made if it
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                [Page 10]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>>     can be reasonably assumedin the eyes of the appointed experts  that
>>     no unchanged implementation of the Information Element exists; this
>>    
>
> A subjective opinion is NOT sufficient. They should query the IPFIX 
> community as widely as possible.
Yes.
>
>>     can be held to happen if a non-interoperable change to an Information
>>     Element defined shortly before is proposed to the IPFIX mailing list
>>     by the original proposer of the Information Element, and no objection
>>     is raised within a reasonable amount of time, to be defined by the
>>     expert reviewers.
>>    
>
> Is this by way of an example, or is it by way of limitation? If the 
> former, state "for example". If the latter, state "this can only be 
> held to happen".
>
>>     If a change ispermissible, it is sent to IANA, which passes it to
>>    
>
> Who determines whether a change is permissible? This reads as if the 
> change submitter self-determines? I'd have expected change requests to 
> be sent to IANA which forwards them to the expert(s) who determine 
> permissibility.
Yes. Should be explained.
>
>>     the appointed experts for review; if there is no objection to the
>>     change from any appointed expert, IANA makes the change in the
>>     Information Element Registry.Changes that are not permissible MUST
>>     be handled by deprecation.
>>    
>
> They can also be rejected outright. Else, by the MUST, a determined 
> individual can completely deprecate the existing info model by 
> requesting a sufficient number of changes.
I see. We need to correct this.
>
>>     An Information Element MAY be deprecated and replaced when:
>>
>>     o  the Information Element definition has an error or shortcoming
>>        which cannot be permissibly changed as above; or
>>
>>     o  the deprecation harmonizes with an external reference which was
>>        itself deprecated through that reference's accepted deprecation
>>        method; or
>>    
>
> Depending on the external action, the IE may be deprecated and not 
> replaced.
>
>>     o  changes in the IPFIX Protocol or its extensions, or in community
>>        understanding thereof, allow the information represented by the
>>        Information Element to be represented in a more efficient or
>>        convenient way.  Deprecation in this circumstance additionally
>>        requires the assent of the IPFIX Working Group, and should be
>>        specified in the Internet Draft(s) defining the protocol change.
>>
>>     A request for deprecation is sent to IANA, which passes it to the
>>     appointed expertsand a responsible Operations Area Director  for
>>    
>
> This is new.
to be discussed.
>
>>     review; if there is no objection to the change from any appointed
>>     expert, IANA makes the change in the Information Element Registry
>>     according to its internal procedures.  When deprecating an
>>     Information Element, the Information Element description MUST be
>>     updated to explain the deprecation, as well as to refer to any new
>>     Information Elements created to replace the deprecated Information
>>     Element.
>>
>>     Deprecated Information Elements SHOULD continue to be supported by
>>     Collecting Processes, but SHOULD NOT be exported by Exporting
>>     Processes.  The use of deprecated Information Elements SHOULD result
>>     in a log entry or human-readable warning at theExporting  and
>>    
>
> That's crazy! You're saying that the EP should be updated to report 
> that it's still sending deprecated fields? LOL. If you're going to 
> update it to know that it's sending an obsolete field, your time would 
> clearly be better spent updating it not to export that field any more.
We have in mind a kind of syslog message sent from the exporter.
>
>>     Collecting Processes.After  a period of time determined in the eyes
>>    
>
> Split to a new paragraph at "After".
>
>>     of the appointed experts to be reasonable in order to allow deployed
>>     Exporting Processes to be updated to account for the deprecation, a
>>     deprecated Information Element may be made obsolete.  Obsolete
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                [Page 11]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>>     Information Elements MUST NOT be supported by either Exporting or
>>     Collecting Processes.  The receipt of obsolete Information Elements
>>     SHOULD be logged by the Collecting Process.
>>    
>
> ...and? Should the fields and/or records be discarded or processed?
> (Clue: "Be strict in what you send, but generous in what you receive.")
to be discussed.
>
>>     Names of deprecated Information Elements MUST NOT be reused.  Names
>>     of obsolete Information Elements MAY be reused, but this is NOT
>>     RECOMMENDED, as it may cause confusion among users.
>>    
>
> Be consistent: if names are the primary reference (rather than the ID 
> numbers, strangely), then don't allow names to be reused at all.
Maybe this is the easiest solution.
>
>> 6.  When not to define new Information Elements
>>
>>     Also important in defining new applications is avoiding redundancy
>>     and clutter in the Information Element registry.  Here we provide
>>     guidelines for reuse of existing Information Elements, as well as
>>     guidelines on using enterprise-specific Information Elements instead
>>     of adding Information Elementsin  the registry.
>>    
>
> "to"
>
>> 6.1.  Maximizing reuse of existing Information Elements
>>
>>     Whenever possible, new applications should prefer usage of existing
>>     IPFIX Information Elements to the creation of new Information
>>     Elements.  IPFIX already provides Information Elements for every
>>     common Layer 4 and Layer 3 packet header field in the IETF protocol
>>     suite, basic Layer 2 information, basic counters, timestamps and time
>>     ranges, and so on.  When defining a new Information Element similar
>>     to an existing one,reviewers shall  ensure that the existing one is
>>     not applicable.
>>    
>
> "... the expert reviewers MUST ..." ?
yes.
>
>>     Simply changing the context in which an Information Element will be
>>     used is insufficient reason for the definition of a new Information
>>     Element.  For example, an extension of IPFIX to log detailed
>>     information about HTTP transactions alongside network-level
>>     information should not define httpClientAddress and httpServerAddress
>>     Information Elements, preferring instead the use of
>>     sourceIPv[46]Address and destinationIPv[46]Address.
>>    
>
> I've got http through a tunnel, proxy or NAT, such that there are two 
> source addresses and two destination addresses.
> One src/dst pair is for http, the other belongs to the tunnel, proxy 
> or NAT. What do you propose?
what do you propose? ;-)
>
>>     Applications dealing with bidirectional interactions should use
>>     Bidirectional Flow Support for IPFIX [RFC5103] to represent these
>>     interactions.
>>
>>     Specifically, existing timestamp and time range Information Elements
>>     should be reused for any situation requiring simple timestamping of
>>     an event: for single observations, the observationTime* Information
>>     Elements from PSAMP are provided, and for events with a duration, the
>>     flowStart* and flowEnd* Information Elements suffice.  This
>>     arrangement allows minimal generic time handling by existing
>>     Collecting Processes and analysis workflows.  New timestamp
>>     Information Elements should ONLY be defined for semantically distinct
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                [Page 12]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>>     timing information (e.g., an IPFIX-exported record containing
>>     information about an event to be scheduled in the future).
>>
>>     In all cases the use of absolute timestamp Information Elements (e.g.
>>     flowStartMilliseconds) is RECOMMENDED, as these Information Elements
>>     allow for maximum flexibility in processing with minimal overhead.
>>     Timestamps based on the export time header in the enclosing IPFIX
>>     Message (e.g. flowStartTimeDeltaMicroseconds) MAY be used if high-
>>     precision timing is important, export bandwidth or storage space is
>>     limited, timestamps comprise a relatively large fraction of record
>>     size, and the application naturally groups records into Messages.
>>     Timestamps based on information which must be exported in a separate
>>     Options Template (e.g. flowStartSysUpTime) MAY be used only in the
>>     context of an existing practice of using runtime-defined epochs for
>>     the given application.
>>
>>     The best practice in Information Element creation is a conservative
>>     one: don't create a new Information Element unlessyou  really need
>>     it.
>>    
>
> Of course you really need it. However, does the wider IPFIX community 
> really need it?
let's correct the sentence.  "... unless the IPFIX community really 
needs it"
>
>> 6.2.  Applying enterprise-specific Information Elements
>>
>>     IPFIX provides a mechanism for defining enterprise-specific
>>     Infomation Elements, as in Section 3.2 of [RFC5101].  These are
>>     scoped to a vendor's or organization's Structure of Management
>>     Information (SMI)Private Enterprise Number, and are under complete
>>     control of the organization assigning them.
>>    
>
> Cite xref.
>
>>     For situations in which interoperability is unimportant, new
>>     information SHOULD be exported using enterprise-specific Information
>>     Elements instead of adding new Information Elements to the registry.
>>     These situations include:
>>
>>     o  export of implementation-specific information, or
>>
>>     o  export of information derived in a commercially-sensitive or
>>        proprietary method, or
>>
>>     o  export of information or meta-information specific to a
>>        commercially-sensitive or proprietary application.
>>
>>     While work within the IETF generally does not fall into these
>>     categories, enterprise-specific Information Elements are also useful
>>     for pre-standardization testing of a new IPFIX application.  While
>>     performing initial development and interoperability testing of a new
>>     application, the Information Elements used by the application SHOULD
>>     NOT be submitted to IANA for inclusion in the registry.  Instead,
>>     these experimental Information Elements SHOULD be represented as
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                [Page 13]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>>     enterprise-specific until their definitions are finalized, then
>>     transitioned from enterprise-specific to IANA-defined upon
>>     finalization.
>>
>>
>> 7.  Applying IPFIX to non-Flow Applications
>>
>>     At the core of IPFIX is its definition of a Flow, a set of packets
>>     sharing some common properties crossing an observation point within a
>>     certain time window.  However, the reliance on this definition does
>>     not preclude the application of IPFIX to domains which are not
>>     obviously handling flow dataaccording to it.  Most network
>>    
>
> According to what? Perhaps just drop these words?
ok
>
>>     management data collection tasks, those to which IPFIX is most
>>     applicable, have at their core the movement of packets from one place
>>     to another; by a liberal interpretation of the common properties
>>     defining the flow, then, almost any event handled by these can be
>>     held to concern data records conforming to the IPFIX definition of a
>>     Flow.
>>    
>
> Is it strictly necessary to convince oneself that a flow exists in 
> order to use IPFIX?
>
>>     Non-flow information defining associations or key-value pairs, on the
>>     other hand, are handled by IPFIX Options.  Here, the Information
>>     Elements within an Options Template are split into Scope IEs which
>>     define the key, and non-scope IEs which define the values associated
>>     with that key.  Unlike Flows, Options are not necessarily scoped in
>>     time; an Option is generally held to be in effect until a new set of
>>     values for a specific set of keys is exported.  While Options are
>>     often used by IPFIX to export metadata about the collection
>>     infrastructure, they are applicable to any association information.
>>    
>
> IIRC, there was some discussion about time-scoping IPFIX options and 
> templates some years ago. eg, we can export a template, indicating 
> that it will be valid from 6pm until midnight. Or pre-export an 
> option, indicating that a new selectorAlgorithm will be in force from 6am.
I don't recall the discussion, but I think the sentence is fine as it 
includes "not necessarily"
>
>>     An IPFIX application can mix Flow Records and Options in an IPFIX
>>     Message or Message stream, and exploit relationships among the Flow
>>     Keys, values, and Scopes to create interrelated data structures.  See
>>     [RFC5473] for an example application of this.
>>
>>
>> 8.  Defining Recommended Templates
>>
>>     New IPFIX applications SHOULD NOT, in the general case, define fixed
>>     templates for export, as this throws away much of the flexibility
>>     afforded by IPFIX.  However, fixed template export is permissible in
>>     the case that the export implementation must operate in a resource
>>     constrained environment, and/or that the application is replacing an
>>     existing fixed-format binary export format in a maximally compatible
>>     way.In any case, Collecting Processes for such applications SHOULD
>>     support reordered Templates or Templates with additional Information
>>     Elements.
>>
>>     An Internet-Draft clarifying the use of new Information Elements
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                [Page 14]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>>     SHOULD include any recommended Templates or Options Templates
>>     necessary for supporting the application, as well as examples of
>>    
>
> No it shouldn't, because implementers will blindly follow these and 
> system specifiers will expect exactly these templates / options an no 
> others, in order to be 100% compliant with the RFC / definition.
>
> Rather, the ID MUST specify which fields are required in the option / 
> template, if any, and MAY give example options and templates, clearly 
> labelling them as such.
Like a remark above, we were targeting the predefined Options Templates 
such as the one in the IPFIX and PSAMP protocols.
>
>>     records exported using these Templates.  In defining these Templates,
>>     such Internet-Drafts SHOULD mention, subject to rare exceptions as
>>     above:
>>
>>     o  that the order of Information Elements within a Template is not
>>        significant;
>>
>>     o  that Templates on the wire for the application may also contain
>>        additional Information Elements beyond those specified in the
>>        recommended Template;
>>
>>     o  that a stream of IPFIX Messages supporting the application may
>>        also contain Data Records not described by the recommended
>>        Templates; and
>>
>>     o  that any reader of IPFIX Messages supporting the application MUST
>>        accept these conditions.
>>
>>     Definitions of recommended Templates for flow-like information, where
>>     the Flow Key is well-defined, SHOULD indicate which of the
>>     Information Elements in the recommended Template are Flow Keys.
>>    
>
> There's a flowKeyIndicator for that, if it's needed.
will add a reference.
>
>>     Recommended Templates are defined, for example, in [RFC5476] for
>>     PSAMP packet reports (section 6.4) and extended packet reports
>>     (section 6.5).  Recommended Options Templates are defined extensively
>>     throughout the IPFIX documents, including in the protocol document
>>     itself [RFC5101] for exporting export statistics; in the file format
>>     [RFC5655] for exporting file metadata; and in Mediator intermediate
>>     process definitions such as [I-D.ietf-ipfix-anon] for intermediate
>>     process metadata.  The discussion in these examples is a good model
>>     for recommended template definitions.
>>    
>
> In your experience (or a quick poll?) do current IPFIX systems 
> implement these exactly as specified, or does anyone implement them 
> with the caveats described above (eg, in a different order, or with 
> additional fields) ?
no idea on this one.
>
>>     However, the bitmap diagrams of these Templates are illustrative but
>>     not particularly readable for more complicated recommended Templates,
>>     provide no support for rapid implementation of new Templates, and do
>>     not adequately convey the optional nature of ordering and additional
>>     Information Elements as above.  Therefore, we have defined
>>     RECOMMENDED textual format for specifying Information Elements and
>>     Templates in Internet-Drafts in Section 9.
>>
>>
>> 9.  A Textual Format for Specifying Information Elements and Templates
>>
>>     The  extension of IPFIXwill  generate a fair amount of documentation
>>    
>
> "Any extension of IPFIX may be expected to generate..."
>
>>     and discussion covering the definition of new Information Elements.
>>     Here we define a simple textual syntax for describing IPFIX
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                [Page 15]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>>     Information Elements and IPFIX Templates, with human readability,
>>     human writability, compactness, and ease of parser/generator
>>     implementation without requiring external XML support as design
>>     goals.  It is intended both for use in human communication (e.g., in
>>     new Internet-Drafts containing higher-level descriptions of IPFIX
>>     Templates, or describing sets of new IPFIX Information Elements for
>>     supporting new applications of the protocol) as well as at runtime by
>>     IPFIX implementations.
>>
>> 9.1.  Information Element Specifiers
>>
>>     The basis of this format is the textual Information Element
>>     Specifier, or IESpec.  An IESpec contains each of the four important
>>     aspects of an Information Element: itsname, its number, its type,
>>     and its size,separated by simple markup based on various types of
>>    
>
> No semantics, units, range?
>
>>     brackets.  Fully-qualified IESpecs may be used to specify existing or
>>     new Information Elements within an Information Model, while either
>>     fully-qualified or partial IESpecs may be used to define fields in a
>>     Template.
>>
>>     Bare words are used for Information Element names, and each aspect of
>>     information associated with an Information Element is associated with
>>     a type of brackets:
>>
>>     o  () parentheses for Information Element numbers,
>>
>>     o<>  angles for Information Element data types, and
>>
>>     o  [] square brackets for Information Element sizes.
>>
>>     o  {} curly braces contain an optional space-separated list of
>>        context identifiers to be associated with an Information Element,
>>        as described in more detail in Section 9.2
>>
>>     The symbol + is reserved for Information Element nesting within
>>     structured data elements; these are described in and Section 9.3,
>>     respectively.
>>
>>     Whitespace in IESpecs is insignificant; spaces can be added after
>>     each element in order, e.g., to align columns for better readability.
>>
>>     The basic form of a fully-qualified IESpec for an IANA-registered
>>     Information Element is as follows:
>>
>>     name(number)[size]
>>    
>
> As long as all the information is present, is the order important? eg, 
> using the example from below, one might prefer to write:
>
>           [8] (152) flowStartMilliseconds
>           [8] (153) flowEndMilliseconds
>           [8]   (1) octetDeltaCount
>           [8]   (2) packetDeltaCount
>     {key} [4]   (8) sourceIPv4Address
>     {key} [4]  (12) destinationIPv4Address
>     {key} [2]   (7) sourceTransportPort
>     {key} [2]  (11) destinationTransportPort
>     {key} [1]   (4) protocolIdentifier
>
>>     where 'name' is the name of the Information Element in UTF-8,
>>     'number' is the Information Element as a decimal integer, 'type' is
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                [Page 16]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>>     the name of the data type as in the IANA informationElementDataTypes
>>     registry, and 'size' is the length of the Information Element in
>>     octets as a decimal integer, where 65535 or the string 'v' signifies
>>     a variable-length Information Element. [size] may be omitted; in this
>>     case, the data type's native or default size is assumed.
>>
>>     The basic form of a fully-qualified IESpec for an enterprise-specific
>>     Information Element is as follows:
>>
>>     name(pen/number)[size]
>>
>>     where 'pen' is the Private Enterprise Number as a decimal integer.
>>
>>     A fully-qualified IESpec is intended to express enough information
>>     about an Information Element to decode and display Data Records
>>     defined by Templates containing that Information Element.  Range,
>>     unit, semantic, and description information, as in [RFC5610], is not
>>     supported by this syntax.
>>
>>     Example fully-qualified IESpecs follow:
>>
>>        octetDeltaCount(1)[8]
>>
>>        octetDeltaCount(1)  (unsigned64 is natively 8 octets
>>        long)
>>
>>        sourceIPv4Address(8)
>>
>>        wlanSSID(146)[v]
>>    
>
> It's 147.
Excellent catch.
After all those years, I still impressed by your thorough reviews ;-)
>
>>        sipRequestURI(35566/403)[65535]
>>
>>     A partial IESpec is any IESpec that is not fully-qualified; these are
>>     useful when defining templates.  A partial IESpec is assumed to take
>>     missing values from its canonical definition, for example, the IANA
>>     registry.  At minimum, a partial IESpec must contain a name, or a
>>     number.  Any name, number, or type information given with a partial
>>     IESpec must match the values given in the Information Model; however,
>>     size information in a partial IESpec overrides size information in
>>     the Information Model; in this way, IESpecs can be used to express
>>     reduced-length encoding for Information Elements.
>>
>>     Example partial IESpecs follow:
>>
>>     o  octetDeltaCount
>>
>>     o  octetDeltaCount[4] (reduced-length encoding)
>>
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                [Page 17]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>>     o  (1)
>>
>>     o  (1)[4] (reduced length encoding; note that this is exactly
>>        equivalent to an Information Element specifier in a Template)
>>
>> 9.2.  Specifying Templates
>>
>>     A Template can then be defined simply as an ordered, newline-
>>     separated sequence of IESpecs.  IESpecs in example Templates
>>     illustrating a new application of IPFIX SHOULD be fully-qualified.
>>     Flow Keys may be optionally annotated by appending the {key} context
>>     to the end of each Flow Key specifier.  A template counting packets
>>     and octets per five-tuple with millisecond precision in IESpec syntax
>>     is shown below.
>>
>>     flowStartMilliseconds(152)[8]
>>     flowEndMilliseconds(153)[8]
>>     octetDeltaCount(1)[8]
>>     packetDeltaCount(2)[8]
>>     sourceIPv4Address(8)[4]{key}
>>     destinationIPv4Address(12)[4]{key}
>>     sourceTransportPort(7)[2]{key}
>>     destinationTransportPort(11)[2]{key}
>>     protocolIdentifier(4)[1]{key}
>>
>>     An Options Template is specified similarly.  Scope is specified
>>    
>
> "specified by"
>
>>     appending the {scope} contextto the end  of each IESpec for a Scope
>>    
>
> See earlier about ordering.
>
>>     IE.Due to the way Information Elements are represented in Options
>>     Templates, all {scope} IESpecs must appear before any non-scope
>>     IESpec.  The Flow Key Options Template defined in section 4.4 of
>>     [RFC5101] in IESpec syntax is shown below:
>>    
>
> Nonsense! That's only true when the IEs are being exported in an 
> option on the wire, because that's how the protocol works.
> However, when writing them down, they can be any way around that you like.
>
> eg, specifications written by people who are unfamiliar with the exact 
> details of the export protocols, but who simply want to use our 
> exporter, sometimes list fields in alphabetical or numerical order. As 
> long as {scope} is clearly indicated at the relevant place, it's up to 
> us as protocol experts to deal with the ordering detail.
We can relax the sentence, but I'm still convinced the scope first makes 
more sense.
>
>>     templateId(145)[2]{scope}
>>     flowKeyIndicator(173)[8]
>>
>> 9.3.  Specifying IPFIX Structured Data
>>
>>     IESpecs can also be used to illustrate the structure of the
>>     information exported using the IPFIX Structured Data extension
>>     [I-D.ietf-ipfix-structured-data].  Here, the semantics of the
>>     structured data elements are specified using contexts, and the
>>     information elements within each structured data element follow the
>>     structured data element, prefixed with + to show they are contained
>>     therein.  Arbitrary nesting of structured data elements is possible
>>     by using multiple + signs in the prefix.  For example, a basic list
>>     of IP addresses with "one or more" semantics would be expressed using
>>     parially  qualified IESpecs as follows:
>>    
>
> Typo, "partially".
>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                [Page 18]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>>     basicList{oneOrMoreOf}
>>     +sourceIPv4Address(8)[4]
>>
>>     And an example subTemplateList itself containing a basicList is shown
>>     below:
>>
>>     subTemplateList{allOf}
>>     +basicList{oneOrMoreOf}
>>     ++sourceIPv4Address(8)[4]
>>     +destinationIPv4Address(12)[4]
>>
>>     This describes a subTemplateMultilist containing all of the expressed
>>     set of source-destination pairs, where the source address itself
>>     could be one of any number in a basicList (e.g., in the case of SCTP
>>     multihoming).
>>
>>     The contexts associable with structured data Information Elements are
>>     the semantics, as defined in section 4.4 of
>>     [I-D.ietf-ipfix-structured-data]; a structured data Information
>>     Element without any context is taken to have undefined semantics.
>>     More information on the application of structured data is available
>>     in [I-D.ietf-ipfix-structured-data].
>>
>>
>> 10.  Security Considerations
>>
>>     The security aspects of new Information Elements must be considered
>>     in order not to give a potential attacker too much information.  For
>>     example, the "A Framework for Packet Selection and Reporting"
>>     [RFC5474] concluded in section 12.3.2 that the hash functions private
>>     parameters should not exported within IPFIX.
>>
>>     If some security considerations are specific to an Information
>>     Element, they MUST be mentioned in the Information Element
>>     description.  For example, the ipHeaderPacketSection in the IPFIX
>>     registry mentions: "This Information Element, which may have a
>>     variable length, carries a series of octets from the start of the IP
>>     header of a sampled packet.  With sufficient length, this element
>>     also reports octets from the IP payload, subject to [RFC2804].See
>>     the Security Considerations section."
>>    
>
> Crucially, the relevant RFC containing the Security Considerations is 
> cited in the registry 'Requester" column. Without that, this text 
> wouldn't make sense.
>
>>     These security considerations MAY also be stressed in a separate
>>     draft.  For example, the "Packet Sampling (PSAMP) Protocols
>>     Specification" [RFC5476] specifies: "In the basic Packet Report, a
>>     PSAMP Device exports some number of contiguous bytes from the start
>>     of the packet, including the packet header (which includes link
>>     layer, network layer and other encapsulation headers) and some
>>     subsequent bytes of the packet payload.  The PSAMP Device SHOULD NOT
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                [Page 19]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>>     export the full payload of conversations, as this would mean
>>     wiretapping [RFC2804].  The PSAMP Device MUST respect local privacy
>>     laws."
>>
>>
>> 11.  IANA Considerations
>>
>>     [TODO - collect IANA considerations from the document once we have
>>     them.]
>>
>>
>> 12.  Acknowledgements
>>
>>     [TODO]
>>    
>
> TIA ;-)
>
>> 13.  Open Issues
>>
>>     o  add examples everywhere (including sipclf)
>>
>>     o  explain the range 0-127.
>>
>>     o  explain thatexisting  draft should use temporary IE identifier
>>    
>
> Not just existing, but new drafts too.
>
>>        such as XXX, YYY, and ZZZ both in the text and in the examples,
>>        and a note to IANA: "to be replaced by IANA when the IE identifier
>>        is assigned"
>>
>>     o  TBD (in WG): Do we want the IE-Doctors to be a formal directorate
>>        under the OPS area?  What can we take from the experience of PMOL?
>>
>>
>> 14.  References
>>
>> 14.1.  Normative References
>>
>>     [RFC5101]  Claise, B., "Specification of the IP Flow Information
>>                Export (IPFIX) Protocol for the Exchange of IP Traffic
>>                Flow Information", RFC 5101, January 2008.
>>
>>     [RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
>>                Meyer, "Information Model for IP Flow Information Export",
>>                RFC 5102, January 2008.
>>
>>     [RFC5103]  Trammell, B. and E. Boschi, "Bidirectional Flow Export
>>                Using IP Flow Information Export (IPFIX)", RFC 5103,
>>                January 2008.
>>
>>     [RFC5610]  Boschi, E., Trammell, B., Mark, L., and T. Zseby,
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                [Page 20]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>>                "Exporting Type Information for IP Flow Information Export
>>                (IPFIX) Information Elements", RFC 5610, July 2009.
>>
>>     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>>                Requirement Levels", BCP 14, RFC 2119, March 1997.
>>
>>     [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
>>                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
>>                May 2008.
>>
>> 14.2.  Informative References
>>
>>     [RFC2804]  IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
>>                May 2000.
>>
>>     [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
>>                "Requirements for IP Flow Information Export (IPFIX)",
>>                RFC 3917, October 2004.
>>
>>     [RFC4181]  Heard, C., "Guidelines for Authors and Reviewers of MIB
>>                Documents", BCP 111, RFC 4181, September 2005.
>>
>>     [RFC5153]  Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P.
>>                Aitken, "IP Flow Information Export (IPFIX) Implementation
>>                Guidelines", RFC 5153, April 2008.
>>
>>     [RFC5470]  Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
>>                "Architecture for IP Flow Information Export", RFC 5470,
>>                March 2009.
>>
>>     [RFC5471]  Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP
>>                Flow Information Export (IPFIX) Testing", RFC 5471,
>>                March 2009.
>>
>>     [RFC5472]  Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP
>>                Flow Information Export (IPFIX) Applicability", RFC 5472,
>>                March 2009.
>>
>>     [RFC5473]  Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy
>>                in IP Flow Information Export (IPFIX) and Packet Sampling
>>                (PSAMP) Reports", RFC 5473, March 2009.
>>
>>     [RFC5474]  Duffield, N., Chiou, D., Claise, B., Greenberg, A.,
>>                Grossglauser, M., and J. Rexford, "A Framework for Packet
>>                Selection and Reporting", RFC 5474, March 2009.
>>
>>     [RFC5476]  Claise, B., Johnson, A., and J. Quittek, "Packet Sampling
>>                (PSAMP) Protocol Specifications", RFC 5476, March 2009.
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                [Page 21]
>> 
>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>
>>
>>     [RFC5655]  Trammell, B., Boschi, E., Mark, L., Zseby, T., and A.
>>                Wagner, "Specification of the IP Flow Information Export
>>                (IPFIX) File Format", RFC 5655, October 2009.
>>
>>     [I-D.ietf-ipfix-structured-data]
>>                Claise, B., Dhandapani, G., Yates, S., and P. Aitken,
>>                "Export of Structured Data in IPFIX",
>>                draft-ietf-ipfix-structured-data-02 (work in progress),
>>                July 2010.
>>
>>     [I-D.ietf-ipfix-anon]
>>                Boschi, E. and B. Trammell, "IP Flow Anonymisation
>>                Support", draft-ietf-ipfix-anon-03 (work in progress),
>>                April 2010.
>>
>>     [iana-ipfix-assignments]
>>                Internet Assigned Numbers Authority, "IP Flow Information
>>                Export Information Elements
>>                (http://www.iana.org/assignments/ipfix/ipfix.xml)".
>>
>>
>> Authors' Addresses
>>
>>     Brian Trammell
>>     Swiss Federal Institute of Technology Zurich
>>     Gloriastrasse 35
>>     8092 Zurich
>>     Switzerland
>>
>>     Phone: +41 44 632 70 13
>>     Email:trammell@tik.ee.ethz.ch
>>
>>
>>     Benoit Claise
>>     Cisco Systems, Inc.
>>     De Kleetlaan 6a b1
>>     1831 Diagem
>>     Belgium
>>
>>     Phone: +32 2 704 5622
>>     Email:bclaise@cisco.com
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Trammell&  Claise         Expires April 4, 2011                [Page 22]
>> 
>>
>>    
>


--------------050209080709000606050008
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    Hi Paul, 

    

    Thanks for excellent review..

    I will address the important points in line.

    

      
      Brian, Benoit,

      

      Please find review comments inline.

      

      Thanks,

      P.

      

      

        
IPFIX Working Group                                          B. Trammell
Internet-Draft                                                ETH Zurich
Intended status: BCP                                           B. Claise
Expires: April 4, 2011                                     Cisco Systems
                                                         October 1, 2010


   Guidelines for Authors and Reviewers of IPFIX Information Elements
                 draft-trammell-ipfix-ie-doctors-00.txt

Abstract

   This document provides guidelines for the definition of IPFIX
   Information Elements for addition to the IANA IPFIX Information
   Element registry, in order to extend the applicability of the IPFIX
   protocol to new operations and management areas.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 4, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Trammell & Claise         Expires April 4, 2011                 [Page 1]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Intended Audience and Usage  . . . . . . . . . . . . . . .  3
     1.2.  Overview of relevant IPFIX documents . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  How to apply IPFIX . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Defining new Information Elements  . . . . . . . . . . . . . .  6
     4.1.  Information Element naming . . . . . . . . . . . . . . . .  6
     4.2.  Information Element data types . . . . . . . . . . . . . .  7
     4.3.  Ancillary Information Element properties . . . . . . . . .  7
     4.4.  Internal structure in Information Elements . . . . . . . .  8
     4.5.  Enumerated Values and Subregistries  . . . . . . . . . . .  9
     4.6.  Reversibility as per RFC 5103  . . . . . . . . . . . . . .  9
   5.  The Information Element Lifecycle: Revision and Deprecation  . 10
   6.  When not to define new Information Elements  . . . . . . . . . 12
     6.1.  Maximizing reuse of existing Information Elements  . . . . 12
     6.2.  Applying enterprise-specific Information Elements  . . . . 13
   7.  Applying IPFIX to non-Flow Applications  . . . . . . . . . . . 14
   8.  Defining Recommended Templates . . . . . . . . . . . . . . . . 14
   9.  A Textual Format for Specifying Information Elements and
       Templates  . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1.  Information Element Specifiers . . . . . . . . . . . . . . 16
     9.2.  Specifying Templates . . . . . . . . . . . . . . . . . . . 18
     9.3.  Specifying IPFIX Structured Data . . . . . . . . . . . . . 18
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   13. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 20
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     14.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22


















Trammell & Claise         Expires April 4, 2011                 [Page 2]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


1.  Introduction

   This document provides guidelines for the extension of the
   applicability of the IP Flow Information Export (IPFIX) protocol to
   network operations and management purposes outside the initial scope
   defined in "IPFIX Applicability Statement" [RFC5472].  These new
   applications are is largely defined through the definition of new
  

      

      

      Remove "is".

      

      

        
   Information Elements beyond those defined in the IPFIX Information
   Model [RFC5102] or already added to the IANA IPFIX Information
   Element Registry [iana-ipfix-assignments].  New applications may be
   further specified through additional RFCs defining and describing
   their usage.
  

      

      

      Ambiguous "their": seems like new applications, rather than
      Information
      Elements.

      

      

        
   We intend this document to enable the expansion of the applicability
   of IPFIX to new areas by experts in the working group or area
   directorate concerned with the technical details of the protocol or
   application to be measured or managed using IPFIX.  This expansion
   would occur with the consultation of IPFIX experts informally called
   'IE-Doctors'.  It provides guidelines both for those defining new
   Information Elements as well as the IE-Doctors reviewing them.
  

      

      

      Ambiguous "them": seems like "those defining new Information
      Elements".

      

      

        
1.1.  Intended Audience and Usage

   This document is meant for two separate audiences.  For IETF
   contributors extending the applicability of IPFIX, it provides a set
   of guidelines and best practices to be used in deciding which
   Information Elements are necessary for a given application, defining
   these Information Elements, and deciding whether an RFC should be
   published to further describe the application.  For the IPFIX experts
   appointed as IE-Doctors, and for IANA personnel changing the
   Information Element registry, it defines a set of acceptance criteria
   against which these proposed Information Elements should be
   evaluated.

   This document is not intended to guide the extension of the IPFIX
   protocol itself, e.g. through new export mechanisms, data types, or
   the like; these activities should be pursued through the publication
   of standards-track RFCs by the IPFIX Working Group.

   This document specifies additional practices beyond those appearing
   in the IANA Considerations sections of existing IPFIX documents,
   especially the Information Model [RFC5102].  The practices outlined
   in this document are intended to guide experts when making changes to
   the IANA registry under Expert Review as defined in [RFC5226].







Trammell & Claise         Expires April 4, 2011                 [Page 3]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


1.2.  Overview of relevant IPFIX documents

   [RFC5101] defines the IPFIX Protocol, the IPFIX-specific terminology
   used by this document, and the data type encodings for each of the
   data types supported by IPFIX.
  

      

      

      Not entirely true; it defines the initial set of data types as an
      extensible registry. There are already drafts proposing new IPFIX
      data
      types beyond RFC5101. Therefore the IANA IPFIX registry is the
      master,
      rather than any of the IPFIX RFCs.

    

    Good point.

    

      

      

        
   [RFC5102] defines the initial IPFIX Information Model, as well as
   procedures for extending the Information Model.  It states that new
   Information Elements may be added to the Information Model on Expert
   Review basis, and delegates the appointment of experts to an IESG
   Area Director.  This document is intended to further codify the best
   practices to be followed by these experts, in order to improve the
   efficiency of this process.

   [RFC5103] defines a method for exporting bidirectional flow
   information using IPFIX; this document should be followed when
   extending IPFIX to represent information about bidirectional network
   interactions in general.  Additionally, new Information Elements
   should be annotated for their reversibility or lack thereof as per
   this document.
  

      

      

      Where is this annotation to be recorded? AFAIK there's currently
      nowhere to do this in the IANA registry, yet there's no
      requirement to
      create any other document before creating new IEs.

    

    Isn't part of the description in the IPFIX IANA?

    

      

      

        
   [RFC5610] defines a method for exporting information about
   Information Elements inline within IPFIX.  In doing so, it explicitly
   defines a set of implicit restrictions on the use of data types and
   semantics; these restrictions MUST be observed in the definition of
   new Information Elements, as in Section 4.3.
  

      

      

      Ambiguous "Section 4.3". 5610 doesn't have a section 4.3. Say
      "Section
      4.3 below.". Throughout the document, please makes it clear
      whether
      you're referring to sections in this doc or in other RFCs.

      

      

        
2.  Terminology

   Capitalized terms used in this document that are defined in the
   Terminology section of [RFC5101] are to be interpreted as defined
   there.

   An "application", as used in this document, refers to a candidate
   protocol, task, or domain to which IPFIX export, collection, and/or
   storage is applied, beyond those within the IPFIX Applicability
   statement [RFC5472].  By this definition, PSAMP [RFC5476] was the
   first new IPFIX application after the publication of the IPFIX
   protocol [RFC5101].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].







Trammell & Claise         Expires April 4, 2011                 [Page 4]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


3.  How to apply IPFIX

   Though originally specified for the export of IP flow information,
   the message format, template mechanism, and data model specified by
   IPFIX lead to it being applicable to a wide variety of network
   management situations.  In addition to flow information export, for
   which it was designed, and packet information export as specified by
   PSAMP [RFC5476], any application with the following characteristics
   is a good candidate for an IPFIX application:

   o  The application's data flow is fundamentally unidirectional.
      IPFIX is a "push" protocol, supporting only the export of
      information from a sender (an Exporting Process) to a receiver (a
      Collecting Process).  Request-response interactions are not
      supported by IPFIX.

   o  The application handles discrete event information, or information
      to be periodically reported.  IPFIX is particularly well suited to
      representing events, which can be scoped in time.

   o  The application handles information about network entities.
      IPFIX's information model is network-oriented, so network
      management applications have many opportunities for information
      model reuse.
  

      

      

      No; this is contrary to the Abstract. I can export anything over
      IPFIX
      that I can define an IE for. 

    Again good point.

    
With
      suitable IEs, it would even be
      possible to tunnel other protocols over IPFIX!

      

      

        
   o  The application requires a small number of arrangements of data
      structures relative to the number of records it handles.  The
      template-driven self-description mechanism used by IPFIX excels at
      handling large volumes of identically structured data, compared to
      representations which define structure inline with data (such as
      XML).

   Most applications meeting these criteria can be supported over IPFIX.
   Once it's been determined that IPFIX is a good fit, the next step is
  

      

      

      "it's" = "it is", not "it has".

      

      

        
   determining which Information Elements are necessary to represent the
   information required by the application.  Especially for network-
   centric applications, the IPFIX Information Element registry may
   already contain all the necessary Information Elements (see
   Section 6.1 for guidelines on maximizing Information Element reuse).
  

      

      

        
   In this case, no additional work within the IETF is necessary: simply
   define Templates and start exporting.

   It is expected, however, that most applications will be able to reuse
   some existing Information Elements, but must define some additional
   Information Elements to support all their requirements; in this case,
   see Section 4 for best practices to be followed in defining
   Information Elements.
  

      

      

        

Trammell & Claise         Expires April 4, 2011                 [Page 5]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   Optionally, a Working Group or individual contributor may choose to
  

      

      

      You should detail "Optionally". New IEs don't need an RFC, but
      some
      applications may require changes to the IPFIX protocol which do
      require
      an RFC.

    

    This was discussed during the IPFIX working group: unless really
    really required, don't create a RFC for new IEs allocation.

    

      

      

        
   publish an RFC detailing the new IPFIX application.  Such an RFC
   should contain discussion of the new application, the Information
   Element definitions as in Section 4, as well as suggested Templates

      

      

      Good grief, I can't believe I just read that!

      

      Perhaps the fields may be specified, but that's about as far as
      I'd go.
      Suggesting templates is something for the implementer to do in his
      software design, and not something to be specified in, or
      slavishly
      copy from, RFCs. More on this below.

    

    Bad wording.

    What we mean is for example the specific Options Templates in the
    IPFIX or PSAMP protocol

    

      

      

        
   and examples of the use of those Templates within the new application
   as in Section 8.  Section 9 defines a compact textual Information
   Element notation to be used in describing these suggested Templates
   and/or the use of IPFIX Structured Data
   [I-D.ietf-ipfix-structured-data] within the new application.
  

      

      
 

      

      This last line seems jammed in without reference to the foregoing
      text.
      A new paragraph might be better.

      

      

        
4.  Defining new Information Elements

   In many cases, a new application will require nothing more than a new
   Information Element or set of Information Elements to be exportable
   using IPFIX.  An Information Element meeting the following criteria,
   as evaluated by appointed IPFIX experts, is eligible for inclusion in
   the Information Element registry:
  

      

      

      Xref with [IANA] URL.

      

      

        
   o  The Information Element MUST be sufficiently unique within the
      registry.  A proposed Information Elements which is a substantial
  

      

      

      Typo.

      

      

        
      duplicate of an exiting Information Element is to be represented
      using the existing Element.
  

      

      

      Yes and no:

      

      If a new element simply adds a new value to an existing element,
      then
      it can be considered as extending the value registry for that
      element,
      which is considerably better than creating a new element for each
      new
      value. However, how are implementers to track when new values are
      added? An exporter and collector may interoperate just fine until
      the
      exporter is updated to a newer version of the IPFIX info model,
      where a
      certain IE now includes an additional value which the collector
      doesn't
      understand. Since both have previously implemented this field and
      interoperated successfully, how are we to know that this potential
      failure now exists - other than exhaustively testing every field /
      value combination?

      

      Again, if a new element extends the functionality of an existing
      element in a small way - while substantially duplicating all the
      existing functionality of the existing element - then again the
      new
      element introduces a lack of interoperability.

      

      Potentially these issues may be solved with clear version
      tracking.

    

    exactly.

    Discussing with Brian in Beijing, we think that one (if not the only
    one) solution would be to have a version number for IPFIX IANA
    registry. Everything single time something is changed in it (new IE,
    extra value for a sub registry, etc...), the version number would be
    incremented.

    

      

      

        
   o  The Information Element SHOULD contain minimal internal structure;
      complex information should be represented with multiple simple
      Information Elements to be exported in parallel, as in
      Section 4.4.
  

      

      

      Or be represented with structured data, if the elements form a
      structure or other composite unit of data.

    

    As discussed during the last IPFIX meeting, basicList is fine. Not
    sure yet regarding subTemplateList and subTemplateMultiList

    

      

      

        
   o  The Information Element SHOULD be generally applicable to the
      application at hand,

      

      

      Meaning, don't request irrelevant elements? Why would anyone do
      that?

      

      

        
 which SHOULD be of general interest to the
      community.  Information Elements representing information about
      proprietary or nonstandard applications SHOULD be represented
      using enterprise-specific Information Elements as detailed in
      section 6.2 of [RFC5101].

   The definition of new Information Elements requires a descriptive
   name, a specification of the data type as one from the IPFIX Data
   Type Registry, and a human-readable description written in English.
  

      

      

      Also semantics, units, range (which are all eventually discussed
      below), and reference and requester info.

      

      The reference is especially important to allow others to clarify
      any
      ambiguity with the new IE.

    

    yes.

    

      

      Ideally the requester should be a generic or team email address
      (rather than a single personal address) where relevant experts can
      still be reached even if the original requester isn't available or
      has
      moved on.

    

    yes.

    

      

      

        
   This section provides guidelines on each of these components of an
   Information Element definition, referring to existing documentation
   such as [RFC5102] as appropriate.

4.1.  Information Element naming

   Information Element Names should be defined in accordance with
   section 2.3 of [RFC5102]; the most important naming conventions are
   repeated here for convenience.



Trammell & Claise         Expires April 4, 2011                 [Page 6]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   o  Names of Information Elements should be descriptive.

   o  Names of Information Elements MUST be unique within the IPFIX
      information model.

   o  Names of Information Elements start with non-capitalized letters.

   o  Composed names use capital letters for the first letter of each
      component (except for the first one).  All other letters are non-
      capitalized, even for acronyms.  Exceptions are made for acronyms
      containing non-capitalized letter, such as 'IPv4' and 'IPv6'.
      Examples are sourceMacAddress and destinationIPv4Address.

   In addition, new Information Elements pertaining to a specific
   protocol SHOULD name the protocol in the first word in order to ease
   searching by name (e.g. "sipMethod" for a SIP method, as would be
   used in a logging format for SIP based on IPFIX).  Similarly, new
   Information Elements pertaining to a specific application SHOULD name
   the application in the first word.

4.2.  Information Element data types

   IPFIX provides a set of data types covering most primitives used in
   network measurement and management applications.  The most
   appropriate data type should be chosen for the Information Element
   type.

   Because IPFIX provides reduced-length encoding for Information
   Elements, unless an integral Information Element is derived from a
   fixed-width field in a measured protocol (e.g., tcpSequenceNumber,
   which is an unsigned32), it should be defined with the maximum
   possible width, generally signed64 or unsigned64.  Applications can
  

      

      

      Then all new elements would be defined as 64-bits. Perhaps
      "maximum
      foreseeable" or "maximum likely" would be better?

    

    yes.

    

      

      

        
   then choose to use reduced-size encoding as defined in Section 6.2 of
   [RFC5101] in cases where fewer than 2^64 values are necessary.
  

      

      

      So why don't we just do away with the size specification and
      specify
      only the type (signed, unsigned, ...)? Collectors can presume to
      allocate 64 bit fields, while the actual size being exported is
      encoded
      in the IPFIX template.

    

     Because some IE would clearly less 64 bits.  Example: TOS. So no
    point to waste any space in a DB.

    

      

      

        
   Information Elements representing time values should be exported with
   appropriate precision.  For example, a Information Element for a time
   measured at second-level precision should be defined as having a
   dateTimeSeconds data type, instead of dateTimeMilliseconds.

4.3.  Ancillary Information Element properties

   Information Elements with numeric types and special semantics SHOULD
   define these semantics with one of the values in the Information
   Element Semantics registry, as described in Section 3.2 of [RFC5102],
   subject to the restrictions given in Section 3.10 of [RFC5610];
   essentially, the semantics and the type must be consistent.




Trammell & Claise         Expires April 4, 2011                 [Page 7]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   When defining Information Elements representing a dimensioned
   quantity or entity count, the units of that quantity SHOULD be
   defined in the units field.  This field takes its values from the
   IANA Information Element Units registry.  If an Information Element
   expresses a quantity in units not yet in this registry, then the unit
   must be added to the Units registry at the same time the Information
   Element is added to the Information Element registry.
  

      

      

      Similar text for both data types and semantics, please.

      

      

        
   Additionally, when the range of values an Information Element can
   take is smaller than the range implied by its data type, the range
   SHOULD be defined within the Information Element registry.
  

      

      

      More exactly, as part of the IE definition.

      

      

        
4.4.  Internal structure in Information Elements

   Unless defining an Information Element which is a direct copy of a
   bitfield or other structured entity (e.g., the tcpControlBits
   Information Element for the Flags byte from the TCP header) in a
   measured protocol, the definition of Information Elements with
  

      

      

      I think it would read better with this text before the
      parenthesised
      example.

      ie, give the example after the explanation.

      

      

        
   internal structure with the structure defined in the Description
   field is discouraged.  In this case, the field SHOULD be decomposed
   into multiple primitive Information Elements to be used in parallel.
  

      

      

      There's a danger here, when there are multiple instances of the
      field.
      So instead of exporting multiple instances of a single structured
      field, "X:Y" like so:

      

           { X:Y, X:Y, X:Y }

      

      we prefer to export multiple instances of the broken down fields:

      

          { X, Y, X, Y, X, Y }

      

      - which may make sense, if the collector knows to relate the first
      X
      and Y together, the second X with the second Y etc...

      

      However, the following is also quite legitimate:

      

          { X, X, X, Y, Y, Y }

      

      Again it follows the same rule: first X relates to first Y etc.
      However, now it's a lot less clear that X and Y are related. Yet
      it's
      not any less valid.

    

    Let us address this one.

    

      

      

        
   For more complicated semantics, where the structure may not have use
   the IPFIX Structured Data [I-D.ietf-ipfix-structured-data] extension
   instead.
  

      

      

      Missing text? Where the structure may not have... what? 

      

      

        
   As an example of information element decomposition, consider an
   application-level identifier called an "endpoint", which represents a
   {host, port, protocol} tuple.  Instead of allocating an opaque,
   structured "source endpoint" Information Element, the source endpoint
   should be represented by three separate Information Elements: "source
   address", "source port", "transport protocol".  Indeed, in this
   example, the required information elements already exist in the
   Information Element registry: sourceIPv4Address or sourceIPv6Address,
   sourceTransportPort, protocolIdentifier.  Indeed, as well as being
   good practice, this normalization down to non-structured Information
   Elements also increases opportunities for reuse as in Section 6.1.
  

      

      

      This example is perfect for structured data.

      

      

        
   The decomposition of data with internal structure SHOULD avoid the
   definition of Information Elements with a meaning too specific to be
   generally useful, or that would result in either the export of
   meaningless data or a multitude of templates to handle different
   multiplicities.  A specific example of this within the IANA registry
   is the following list of assigned IPFIX Information Elements:
   mplsTopLabelStackSection, mplsLabelStackSection2,
   mplsLabelStackSection3, mplsLabelStackSection4,
   mplsLabelStackSection5, mplsLabelStackSection6
   mplsLabelStackSection7, mplsLabelStackSection8,
   mplsLabelStackSection9, and mplsLabelStackSection10.  The only



Trammell & Claise         Expires April 4, 2011                 [Page 8]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   distinction between those almost-identical Information Elements is
   the position within the MPLS stack.  This Information Element design
   pattern met an early requirement of the definition of IPFIX which was
   not carried forward into the final specification -- namely, that no
   semantic dependency was allowed between Information Elements in the
   same Record -- and as such SHOULD NOT be followed in the definition
   of new Information Elements.  In this case, since the size of the
   MPLS stack will vary from flow to flow, it should be exported using
   IPFIX Structured Data [I-D.ietf-ipfix-structured-data] where
   supported, as a basicList of MPLS label entries.

   Note that a Template may contain multiple instances of the same
   Information Element; in this case, the each of the Information
  

      

      

      Typo.

      

      

        
   Elements in the Template are semantically indistinguishable, and
   appear in their "natural" order, where natural order is defined
   according to application; PSAMP uses this for exporting selectors.
   Multiple IEs used in this way are preferable to IEs with internal
   structure, but only when there is some natural order, and no semantic
   interdependence among the elements.

4.5.  Enumerated Values and Subregistries

   When defining an Information Element that takes an enumerated value
   from a set of values which may change in the future, this enumeration
   MUST be defined by an IANA registry or subregistry.  For situations
   where an existing registry defines the enumeration (e.g., the IANA
   Protocol Numbers registry for the protocolIdentifier Information
   Element), that registry MUST be used.  Otherwise, a new IPFIX
   subregistry must be defined for the enumerated value, to be modified
   subject to Expert Review [RFC5226].
  

      

      

      There's some ongoing discussion with Nevil as to whether
      sub-registries
      should be used, or whether the values can be recorded directly in
      the
      element description.

      

      Again, the version control issue...

      

      

        
4.6.  Reversibility as per RFC 5103

   [TODO: fix this para][RFC5103] defines a method for exporting
   bidirectional flows using a special Private Enterprise Number to
   define reverse-direction variants of IANA Information Elements, and a
   set of criteria for determining whether an Information Element may be
   reversed using this method.  Section 6.1 of [RFC5103] states that CPs
   should use the set of criteria therein to determine reversibility.
   Since almost all Information Elements are reversible, these criteria
   are expressed as to determine the exceptions, i.e. which Information
   Elements are NOT reversible.

   To ease the determination of reversibility, future Information
   Elements which are NOT reversible SHOULD note this fact in the
   description at the time of definition.
  

      

      

      Can you include some examples of non-reversible elements?

      

      

        


Trammell & Claise         Expires April 4, 2011                 [Page 9]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


5.  The Information Element Lifecycle: Revision and Deprecation

   The Information Element status field in the Information Element
   Registry is defined in [RFC5102] to allow Information Elements to be
   'deprecated' or 'obsolete'.  No Information Elements are as of this
   writing deprecated, and but provides no further explanation of these
   statuses, [RFC5102] does not define any policy for using them.
  

      

      

      This doesn't make sense.

      

      

        
   Additionally, no policy is defined for revising Information Element
   registry entries or addressing errors therein.  To be certain,
   changes and deprecations within the Information Element registry are
   not encouraged, and should be avoided to the extent possible.
  

      

      

      Clarify whether addition of new values is a change.

      

      

        
   However, in recognition that change is inevitable, this section is
   intended to remedy this situation.

   The primary requirement in the definition of a policy for managing
   changes to existing Information Elements is avoidance of
   interoperability problems; IPFIX experts appointed to review changes
   to the Information Element Registry MUST work to maintain
   interoperability above all else.  Changes to Information Elements
   already in use may only be done in an interoperable way; necessary
   changes which cannot be done in a way to allow interoperability with
   unchanged implementations MUST result in deprecation.

   A change to an Information Element is held to be interoperable only
   when:

   o  it involves the correction of an error which is obviously only
      editorial; or

   o  it corrects an ambiguity in the Information Element's definition,
      which itself leads to non-interoperability (e.g., a prior change
      to ipv6ExtensionHeaders); or
  

      

      

      Cite the errata for this:

      

      http://www.rfc-editor.org/errata_search.php?eid=1738

      

      

        
   o  it expands the Information Element's data type without changing
      how it is represented (e.g., changing unsigned32 to unsigned64, as
      with a prior change to selectorId); or
  

      

      

      http://www.rfc-editor.org/errata_search.php?eid=2052

      

      

        
   o  it defines a previously undefined or reserved enumerated value, or
      one or more previously reserved bits in an Information Element
      with flag semantics; or

   o  it expands the set of permissible values in the Information
      Element's range; or
  

      

      

      These two changes may NOT be interoperable.

      

      eg, an exporter reporting an additional (new) value to a collector
      which hasn't been updated to understand that new value (though the
      collector was 100% IPFIX compliant at the time of implementation).

      

      Somewhere in here you should discuss version control of the IANA
      registry, so every change is clearly called out. Find out how
      other
      protocols deal with change.

    

    Yes. Same issue as discussed above.

    

      

      

        
   o  it harmonizes with an external reference which was itself
      corrected.
  

      

      

      This is a potentially dangerous change. The correct route may be
      to
      deprecate the wrongly defined IE and create a new IE with the
      correct
      definition.

      

      

        
   A non-interoperable Information Element change may also be made if it



Trammell & Claise         Expires April 4, 2011                [Page 10]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   can be reasonably assumed in the eyes of the appointed experts that
   no unchanged implementation of the Information Element exists; this
  

      

      

      A subjective opinion is NOT sufficient. They should query the
      IPFIX
      community as widely as possible.

    

    Yes.

    

      

      

        
   can be held to happen if a non-interoperable change to an Information
   Element defined shortly before is proposed to the IPFIX mailing list
   by the original proposer of the Information Element, and no objection
   is raised within a reasonable amount of time, to be defined by the
   expert reviewers.
  

      

      

      Is this by way of an example, or is it by way of limitation? If
      the
      former, state "for example". If the latter, state "this can only be held to happen".

      

      

        
   If a change is permissible, it is sent to IANA, which passes it to
  

      

      

      Who determines whether a change is permissible? This reads as if
      the
      change submitter self-determines? I'd have expected change
      requests to
      be sent to IANA which forwards them to the expert(s) who determine
      permissibility.

    

    Yes. Should be explained.

    

      

      

        
   the appointed experts for review; if there is no objection to the
   change from any appointed expert, IANA makes the change in the
   Information Element Registry.  Changes that are not permissible MUST
   be handled by deprecation.
  

      

      

      They can also be rejected outright. Else, by the MUST, a
      determined
      individual can completely deprecate the existing info model by
      requesting a sufficient number of changes.

    

    I see. We need to correct this.

    

      

      

        
   An Information Element MAY be deprecated and replaced when:

   o  the Information Element definition has an error or shortcoming
      which cannot be permissibly changed as above; or

   o  the deprecation harmonizes with an external reference which was
      itself deprecated through that reference's accepted deprecation
      method; or
  

      

      

      Depending on the external action, the IE may be deprecated and not
      replaced.

      

      

        
   o  changes in the IPFIX Protocol or its extensions, or in community
      understanding thereof, allow the information represented by the
      Information Element to be represented in a more efficient or
      convenient way.  Deprecation in this circumstance additionally
      requires the assent of the IPFIX Working Group, and should be
      specified in the Internet Draft(s) defining the protocol change.

   A request for deprecation is sent to IANA, which passes it to the
   appointed experts and a responsible Operations Area Director for
  

      

      

      This is new.

    

    to be discussed.

    

      

      

        
   review; if there is no objection to the change from any appointed
   expert, IANA makes the change in the Information Element Registry
   according to its internal procedures.  When deprecating an
   Information Element, the Information Element description MUST be
   updated to explain the deprecation, as well as to refer to any new
   Information Elements created to replace the deprecated Information
   Element.

   Deprecated Information Elements SHOULD continue to be supported by
   Collecting Processes, but SHOULD NOT be exported by Exporting
   Processes.  The use of deprecated Information Elements SHOULD result
   in a log entry or human-readable warning at the Exporting and
  

      

      

      That's crazy! You're saying that the EP should be updated to
      report
      that it's still sending deprecated fields? LOL. If you're going to
      update it to know that it's sending an obsolete field, your time
      would
      clearly be better spent updating it not to export that field any
      more.

    

    We have in mind a kind of syslog message sent from the exporter.

    

      

      

        
   Collecting Processes.  After a period of time determined in the eyes
  

      

      

      Split to a new paragraph at "After".

      

      

        
   of the appointed experts to be reasonable in order to allow deployed
   Exporting Processes to be updated to account for the deprecation, a
   deprecated Information Element may be made obsolete.  Obsolete



Trammell & Claise         Expires April 4, 2011                [Page 11]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   Information Elements MUST NOT be supported by either Exporting or
   Collecting Processes.  The receipt of obsolete Information Elements
   SHOULD be logged by the Collecting Process.
  

      

      

      ...and? Should the fields and/or records be discarded or
      processed?

      (Clue: "Be strict
        in
        what you send, but generous in what you receive.")

    

    to be discussed.

    

      

      

        
   Names of deprecated Information Elements MUST NOT be reused.  Names
   of obsolete Information Elements MAY be reused, but this is NOT
   RECOMMENDED, as it may cause confusion among users.
  

      

      

      Be consistent: if names are the primary reference (rather than the
      ID
      numbers, strangely), then don't allow names to be reused at all.

    

    Maybe this is the easiest solution.

    

      

      

        
6.  When not to define new Information Elements

   Also important in defining new applications is avoiding redundancy
   and clutter in the Information Element registry.  Here we provide
   guidelines for reuse of existing Information Elements, as well as
   guidelines on using enterprise-specific Information Elements instead
   of adding Information Elements in the registry.
  

      

      

      "to"

      

      

        
6.1.  Maximizing reuse of existing Information Elements

   Whenever possible, new applications should prefer usage of existing
   IPFIX Information Elements to the creation of new Information
   Elements.  IPFIX already provides Information Elements for every
   common Layer 4 and Layer 3 packet header field in the IETF protocol
   suite, basic Layer 2 information, basic counters, timestamps and time
   ranges, and so on.  When defining a new Information Element similar
   to an existing one, reviewers shall ensure that the existing one is
   not applicable.
  

      

      

      "... the expert reviewers MUST ..." ?

    

    yes.

    

      

      

        
   Simply changing the context in which an Information Element will be
   used is insufficient reason for the definition of a new Information
   Element.  For example, an extension of IPFIX to log detailed
   information about HTTP transactions alongside network-level
   information should not define httpClientAddress and httpServerAddress
   Information Elements, preferring instead the use of
   sourceIPv[46]Address and destinationIPv[46]Address.
  

      

      

      I've got http through a tunnel, proxy or NAT, such that there are
      two
      source addresses and two destination addresses.

      One src/dst pair is for http, the other belongs to the tunnel,
      proxy or
      NAT. What do you propose?

    

    what do you propose? ;-)

    

      

      

        
   Applications dealing with bidirectional interactions should use
   Bidirectional Flow Support for IPFIX [RFC5103] to represent these
   interactions.

   Specifically, existing timestamp and time range Information Elements
   should be reused for any situation requiring simple timestamping of
   an event: for single observations, the observationTime* Information
   Elements from PSAMP are provided, and for events with a duration, the
   flowStart* and flowEnd* Information Elements suffice.  This
   arrangement allows minimal generic time handling by existing
   Collecting Processes and analysis workflows.  New timestamp
   Information Elements should ONLY be defined for semantically distinct



Trammell & Claise         Expires April 4, 2011                [Page 12]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   timing information (e.g., an IPFIX-exported record containing
   information about an event to be scheduled in the future).

   In all cases the use of absolute timestamp Information Elements (e.g.
   flowStartMilliseconds) is RECOMMENDED, as these Information Elements
   allow for maximum flexibility in processing with minimal overhead.
   Timestamps based on the export time header in the enclosing IPFIX
   Message (e.g. flowStartTimeDeltaMicroseconds) MAY be used if high-
   precision timing is important, export bandwidth or storage space is
   limited, timestamps comprise a relatively large fraction of record
   size, and the application naturally groups records into Messages.
   Timestamps based on information which must be exported in a separate
   Options Template (e.g. flowStartSysUpTime) MAY be used only in the
   context of an existing practice of using runtime-defined epochs for
   the given application.

   The best practice in Information Element creation is a conservative
   one: don't create a new Information Element unless you really need
   it.
  

      

      

      Of course you really need it.
      However,
      does the wider IPFIX community really need it?

    

    let's correct the sentence.  "... unless the IPFIX community really
    needs it"

    

      

      

        
6.2.  Applying enterprise-specific Information Elements

   IPFIX provides a mechanism for defining enterprise-specific
   Infomation Elements, as in Section 3.2 of [RFC5101].  These are
   scoped to a vendor's or organization's Structure of Management
   Information (SMI) Private Enterprise Number, and are under complete
   control of the organization assigning them.
  

      

      

      Cite xref.

      

      

        
   For situations in which interoperability is unimportant, new
   information SHOULD be exported using enterprise-specific Information
   Elements instead of adding new Information Elements to the registry.
   These situations include:

   o  export of implementation-specific information, or

   o  export of information derived in a commercially-sensitive or
      proprietary method, or

   o  export of information or meta-information specific to a
      commercially-sensitive or proprietary application.

   While work within the IETF generally does not fall into these
   categories, enterprise-specific Information Elements are also useful
   for pre-standardization testing of a new IPFIX application.  While
   performing initial development and interoperability testing of a new
   application, the Information Elements used by the application SHOULD
   NOT be submitted to IANA for inclusion in the registry.  Instead,
   these experimental Information Elements SHOULD be represented as



Trammell & Claise         Expires April 4, 2011                [Page 13]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   enterprise-specific until their definitions are finalized, then
   transitioned from enterprise-specific to IANA-defined upon
   finalization.


7.  Applying IPFIX to non-Flow Applications

   At the core of IPFIX is its definition of a Flow, a set of packets
   sharing some common properties crossing an observation point within a
   certain time window.  However, the reliance on this definition does
   not preclude the application of IPFIX to domains which are not
   obviously handling flow data according to it.  Most network
  

      

      

      According to what? Perhaps just drop these words?

    

    ok

    

      

      

        
   management data collection tasks, those to which IPFIX is most
   applicable, have at their core the movement of packets from one place
   to another; by a liberal interpretation of the common properties
   defining the flow, then, almost any event handled by these can be
   held to concern data records conforming to the IPFIX definition of a
   Flow.
  

      

      

      Is it strictly necessary to convince oneself that a flow exists in
      order to use IPFIX?

      

      

        
   Non-flow information defining associations or key-value pairs, on the
   other hand, are handled by IPFIX Options.  Here, the Information
   Elements within an Options Template are split into Scope IEs which
   define the key, and non-scope IEs which define the values associated
   with that key.  Unlike Flows, Options are not necessarily scoped in
   time; an Option is generally held to be in effect until a new set of
   values for a specific set of keys is exported.  While Options are
   often used by IPFIX to export metadata about the collection
   infrastructure, they are applicable to any association information.
  

      

      

      IIRC, there was some discussion about time-scoping IPFIX options
      and
      templates some years ago. eg, we can export a template, indicating
      that
      it will be valid from 6pm until midnight. Or pre-export an option,
      indicating that a new selectorAlgorithm will be in force from 6am.

    

    I don't recall the discussion, but I think the sentence is fine as
    it includes "not necessarily"

    

      

      

        
   An IPFIX application can mix Flow Records and Options in an IPFIX
   Message or Message stream, and exploit relationships among the Flow
   Keys, values, and Scopes to create interrelated data structures.  See
   [RFC5473] for an example application of this.


8.  Defining Recommended Templates

   New IPFIX applications SHOULD NOT, in the general case, define fixed
   templates for export, as this throws away much of the flexibility
   afforded by IPFIX.  However, fixed template export is permissible in
   the case that the export implementation must operate in a resource
   constrained environment, and/or that the application is replacing an
   existing fixed-format binary export format in a maximally compatible
   way.  In any case, Collecting Processes for such applications SHOULD
   support reordered Templates or Templates with additional Information
   Elements.

   An Internet-Draft clarifying the use of new Information Elements



Trammell & Claise         Expires April 4, 2011                [Page 14]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   SHOULD include any recommended Templates or Options Templates
   necessary for supporting the application, as well as examples of
  

      

      

      No it shouldn't, because implementers will blindly follow these
      and
      system specifiers will expect exactly these templates / options an
      no
      others, in order to be 100% compliant with the RFC / definition.

      

      Rather, the ID MUST specify which fields are required in the
      option /
      template, if any, and MAY give example options and templates,
      clearly
      labelling them as such.

    

    Like a remark above, we were targeting the predefined Options
    Templates such as the one in the IPFIX and PSAMP protocols.

    

      

      

        
   records exported using these Templates.  In defining these Templates,
   such Internet-Drafts SHOULD mention, subject to rare exceptions as
   above:

   o  that the order of Information Elements within a Template is not
      significant;

   o  that Templates on the wire for the application may also contain
      additional Information Elements beyond those specified in the
      recommended Template;

   o  that a stream of IPFIX Messages supporting the application may
      also contain Data Records not described by the recommended
      Templates; and

   o  that any reader of IPFIX Messages supporting the application MUST
      accept these conditions.

   Definitions of recommended Templates for flow-like information, where
   the Flow Key is well-defined, SHOULD indicate which of the
   Information Elements in the recommended Template are Flow Keys.
  

      

      

      There's a flowKeyIndicator for that, if it's needed.

    

    will add a reference.

    

      

      

        
   Recommended Templates are defined, for example, in [RFC5476] for
   PSAMP packet reports (section 6.4) and extended packet reports
   (section 6.5).  Recommended Options Templates are defined extensively
   throughout the IPFIX documents, including in the protocol document
   itself [RFC5101] for exporting export statistics; in the file format
   [RFC5655] for exporting file metadata; and in Mediator intermediate
   process definitions such as [I-D.ietf-ipfix-anon] for intermediate
   process metadata.  The discussion in these examples is a good model
   for recommended template definitions.
  

      

      

      In your experience (or a quick poll?) do current IPFIX systems
      implement these exactly as specified, or does anyone implement
      them
      with the caveats described above (eg, in a different order, or
      with
      additional fields) ?

    

    no idea on this one.

    

      

      

        
   However, the bitmap diagrams of these Templates are illustrative but
   not particularly readable for more complicated recommended Templates,
   provide no support for rapid implementation of new Templates, and do
   not adequately convey the optional nature of ordering and additional
   Information Elements as above.  Therefore, we have defined
   RECOMMENDED textual format for specifying Information Elements and
   Templates in Internet-Drafts in Section 9.


9.  A Textual Format for Specifying Information Elements and Templates

   The extension of IPFIX will generate a fair amount of documentation
  

      

      

      "Any extension of IPFIX may be expected to generate..."

      

      

        
   and discussion covering the definition of new Information Elements.
   Here we define a simple textual syntax for describing IPFIX



Trammell & Claise         Expires April 4, 2011                [Page 15]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   Information Elements and IPFIX Templates, with human readability,
   human writability, compactness, and ease of parser/generator
   implementation without requiring external XML support as design
   goals.  It is intended both for use in human communication (e.g., in
   new Internet-Drafts containing higher-level descriptions of IPFIX
   Templates, or describing sets of new IPFIX Information Elements for
   supporting new applications of the protocol) as well as at runtime by
   IPFIX implementations.

9.1.  Information Element Specifiers

   The basis of this format is the textual Information Element
   Specifier, or IESpec.  An IESpec contains each of the four important
   aspects of an Information Element: its name, its number, its type,
   and its size, separated by simple markup based on various types of
  

      

      

      No semantics, units, range?

      

      

        
   brackets.  Fully-qualified IESpecs may be used to specify existing or
   new Information Elements within an Information Model, while either
   fully-qualified or partial IESpecs may be used to define fields in a
   Template.

   Bare words are used for Information Element names, and each aspect of
   information associated with an Information Element is associated with
   a type of brackets:

   o  () parentheses for Information Element numbers,

   o  <> angles for Information Element data types, and

   o  [] square brackets for Information Element sizes.

   o  {} curly braces contain an optional space-separated list of
      context identifiers to be associated with an Information Element,
      as described in more detail in Section 9.2

   The symbol + is reserved for Information Element nesting within
   structured data elements; these are described in and Section 9.3,
   respectively.

   Whitespace in IESpecs is insignificant; spaces can be added after
   each element in order, e.g., to align columns for better readability.

   The basic form of a fully-qualified IESpec for an IANA-registered
   Information Element is as follows:

   name(number)<type>[size]
  

      

      

      As long as all the information is present, is the order important?
      eg,
      using the example from below, one might prefer to write:

      

      
         [8] (152) flowStartMilliseconds    <dateTimeMilliseconds>
         [8] (153) flowEndMilliseconds      <dateTimeMilliseconds>
         [8]   (1) octetDeltaCount          <unsigned64>
         [8]   (2) packetDeltaCount         <unsigned64>
   {key} [4]   (8) sourceIPv4Address        <ipv4Address>
   {key} [4]  (12) destinationIPv4Address   <ipv4Address>
   {key} [2]   (7) sourceTransportPort      <unsigned16>
   {key} [2]  (11) destinationTransportPort <unsigned16>
   {key} [1]   (4) protocolIdentifier       <unsigned8>

      

      

        
   where 'name' is the name of the Information Element in UTF-8,
   'number' is the Information Element as a decimal integer, 'type' is



Trammell & Claise         Expires April 4, 2011                [Page 16]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   the name of the data type as in the IANA informationElementDataTypes
   registry, and 'size' is the length of the Information Element in
   octets as a decimal integer, where 65535 or the string 'v' signifies
   a variable-length Information Element. [size] may be omitted; in this
   case, the data type's native or default size is assumed.

   The basic form of a fully-qualified IESpec for an enterprise-specific
   Information Element is as follows:

   name(pen/number)<type>[size]

   where 'pen' is the Private Enterprise Number as a decimal integer.

   A fully-qualified IESpec is intended to express enough information
   about an Information Element to decode and display Data Records
   defined by Templates containing that Information Element.  Range,
   unit, semantic, and description information, as in [RFC5610], is not
   supported by this syntax.

   Example fully-qualified IESpecs follow:

      octetDeltaCount(1)<unsigned64>[8]

      octetDeltaCount(1)<unsigned64> (unsigned64 is natively 8 octets
      long)

      sourceIPv4Address(8)<ipv4Address>

      wlanSSID(146)<string>[v]
  

      

      

      It's 147.

    

    Excellent catch.

    After all those years, I still impressed by your thorough reviews
    ;-)

    

      

      

        
      sipRequestURI(35566/403)<string>[65535]

   A partial IESpec is any IESpec that is not fully-qualified; these are
   useful when defining templates.  A partial IESpec is assumed to take
   missing values from its canonical definition, for example, the IANA
   registry.  At minimum, a partial IESpec must contain a name, or a
   number.  Any name, number, or type information given with a partial
   IESpec must match the values given in the Information Model; however,
   size information in a partial IESpec overrides size information in
   the Information Model; in this way, IESpecs can be used to express
   reduced-length encoding for Information Elements.

   Example partial IESpecs follow:

   o  octetDeltaCount

   o  octetDeltaCount[4] (reduced-length encoding)




Trammell & Claise         Expires April 4, 2011                [Page 17]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   o  (1)

   o  (1)[4] (reduced length encoding; note that this is exactly
      equivalent to an Information Element specifier in a Template)

9.2.  Specifying Templates

   A Template can then be defined simply as an ordered, newline-
   separated sequence of IESpecs.  IESpecs in example Templates
   illustrating a new application of IPFIX SHOULD be fully-qualified.
   Flow Keys may be optionally annotated by appending the {key} context
   to the end of each Flow Key specifier.  A template counting packets
   and octets per five-tuple with millisecond precision in IESpec syntax
   is shown below.

   flowStartMilliseconds(152)<dateTimeMilliseconds>[8]
   flowEndMilliseconds(153)<dateTimeMilliseconds>[8]
   octetDeltaCount(1)<unsigned64>[8]
   packetDeltaCount(2)<unsigned64>[8]
   sourceIPv4Address(8)<ipv4Address>[4]{key}
   destinationIPv4Address(12)<ipv4Address>[4]{key}
   sourceTransportPort(7)<unsigned16>[2]{key}
   destinationTransportPort(11)<unsigned16>[2]{key}
   protocolIdentifier(4)<unsigned8>[1]{key}

   An Options Template is specified similarly.  Scope is specified
  

      

      

      "specified by"

      

      

        
   appending the {scope} context to the end of each IESpec for a Scope
  

      

      

      See earlier about ordering.

      

      

        
   IE.  Due to the way Information Elements are represented in Options
   Templates, all {scope} IESpecs must appear before any non-scope
   IESpec.  The Flow Key Options Template defined in section 4.4 of
   [RFC5101] in IESpec syntax is shown below:
  

      

      

      Nonsense! That's only true when the IEs are being exported in an
      option
      on the wire, because that's how the protocol works.

      However, when writing them down, they can be any way around that
      you
      like.

      

      eg, specifications written by people who are unfamiliar with the
      exact
      details of the export protocols, but who simply want to use our
      exporter, sometimes list fields in alphabetical or numerical
      order. As
      long as {scope} is clearly indicated at the relevant place, it's
      up to
      us as protocol experts to deal with the ordering detail.

    

    We can relax the sentence, but I'm still convinced the scope first
    makes more sense.

    

      

      

        
   templateId(145)<unsigned16>[2]{scope}
   flowKeyIndicator(173)<unsigned64>[8]

9.3.  Specifying IPFIX Structured Data

   IESpecs can also be used to illustrate the structure of the
   information exported using the IPFIX Structured Data extension
   [I-D.ietf-ipfix-structured-data].  Here, the semantics of the
   structured data elements are specified using contexts, and the
   information elements within each structured data element follow the
   structured data element, prefixed with + to show they are contained
   therein.  Arbitrary nesting of structured data elements is possible
   by using multiple + signs in the prefix.  For example, a basic list
   of IP addresses with "one or more" semantics would be expressed using
   parially qualified IESpecs as follows:
  

      

      

      Typo, "partially".

      

      

        


Trammell & Claise         Expires April 4, 2011                [Page 18]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   basicList{oneOrMoreOf}
   +sourceIPv4Address(8)[4]

   And an example subTemplateList itself containing a basicList is shown
   below:

   subTemplateList{allOf}
   +basicList{oneOrMoreOf}
   ++sourceIPv4Address(8)[4]
   +destinationIPv4Address(12)[4]

   This describes a subTemplateMultilist containing all of the expressed
   set of source-destination pairs, where the source address itself
   could be one of any number in a basicList (e.g., in the case of SCTP
   multihoming).

   The contexts associable with structured data Information Elements are
   the semantics, as defined in section 4.4 of
   [I-D.ietf-ipfix-structured-data]; a structured data Information
   Element without any context is taken to have undefined semantics.
   More information on the application of structured data is available
   in [I-D.ietf-ipfix-structured-data].


10.  Security Considerations

   The security aspects of new Information Elements must be considered
   in order not to give a potential attacker too much information.  For
   example, the "A Framework for Packet Selection and Reporting"
   [RFC5474] concluded in section 12.3.2 that the hash functions private
   parameters should not exported within IPFIX.

   If some security considerations are specific to an Information
   Element, they MUST be mentioned in the Information Element
   description.  For example, the ipHeaderPacketSection in the IPFIX
   registry mentions: "This Information Element, which may have a
   variable length, carries a series of octets from the start of the IP
   header of a sampled packet.  With sufficient length, this element
   also reports octets from the IP payload, subject to [RFC2804].  See
   the Security Considerations section."
  

      

      

      Crucially, the relevant RFC containing the Security Considerations
      is
      cited in the registry 'Requester" column. Without that, this text
      wouldn't make sense.

      

      

        
   These security considerations MAY also be stressed in a separate
   draft.  For example, the "Packet Sampling (PSAMP) Protocols
   Specification" [RFC5476] specifies: "In the basic Packet Report, a
   PSAMP Device exports some number of contiguous bytes from the start
   of the packet, including the packet header (which includes link
   layer, network layer and other encapsulation headers) and some
   subsequent bytes of the packet payload.  The PSAMP Device SHOULD NOT



Trammell & Claise         Expires April 4, 2011                [Page 19]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   export the full payload of conversations, as this would mean
   wiretapping [RFC2804].  The PSAMP Device MUST respect local privacy
   laws."


11.  IANA Considerations

   [TODO - collect IANA considerations from the document once we have
   them.]


12.  Acknowledgements

   [TODO]
  

      

      

      TIA ;-)

      

      

        
13.  Open Issues

   o  add examples everywhere (including sipclf)

   o  explain the range 0-127.

   o  explain that existing draft should use temporary IE identifier
  

      

      

      Not just existing, but new drafts too.

      

      

        
      such as XXX, YYY, and ZZZ both in the text and in the examples,
      and a note to IANA: "to be replaced by IANA when the IE identifier
      is assigned"

   o  TBD (in WG): Do we want the IE-Doctors to be a formal directorate
      under the OPS area?  What can we take from the experience of PMOL?


14.  References

14.1.  Normative References

   [RFC5101]  Claise, B., "Specification of the IP Flow Information
              Export (IPFIX) Protocol for the Exchange of IP Traffic
              Flow Information", RFC 5101, January 2008.

   [RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
              Meyer, "Information Model for IP Flow Information Export",
              RFC 5102, January 2008.

   [RFC5103]  Trammell, B. and E. Boschi, "Bidirectional Flow Export
              Using IP Flow Information Export (IPFIX)", RFC 5103,
              January 2008.

   [RFC5610]  Boschi, E., Trammell, B., Mark, L., and T. Zseby,



Trammell & Claise         Expires April 4, 2011                [Page 20]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


              "Exporting Type Information for IP Flow Information Export
              (IPFIX) Information Elements", RFC 5610, July 2009.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

14.2.  Informative References

   [RFC2804]  IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
              May 2000.

   [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
              "Requirements for IP Flow Information Export (IPFIX)",
              RFC 3917, October 2004.

   [RFC4181]  Heard, C., "Guidelines for Authors and Reviewers of MIB
              Documents", BCP 111, RFC 4181, September 2005.

   [RFC5153]  Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P.
              Aitken, "IP Flow Information Export (IPFIX) Implementation
              Guidelines", RFC 5153, April 2008.

   [RFC5470]  Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
              "Architecture for IP Flow Information Export", RFC 5470,
              March 2009.

   [RFC5471]  Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP
              Flow Information Export (IPFIX) Testing", RFC 5471,
              March 2009.

   [RFC5472]  Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP
              Flow Information Export (IPFIX) Applicability", RFC 5472,
              March 2009.

   [RFC5473]  Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy
              in IP Flow Information Export (IPFIX) and Packet Sampling
              (PSAMP) Reports", RFC 5473, March 2009.

   [RFC5474]  Duffield, N., Chiou, D., Claise, B., Greenberg, A.,
              Grossglauser, M., and J. Rexford, "A Framework for Packet
              Selection and Reporting", RFC 5474, March 2009.

   [RFC5476]  Claise, B., Johnson, A., and J. Quittek, "Packet Sampling
              (PSAMP) Protocol Specifications", RFC 5476, March 2009.



Trammell & Claise         Expires April 4, 2011                [Page 21]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   [RFC5655]  Trammell, B., Boschi, E., Mark, L., Zseby, T., and A.
              Wagner, "Specification of the IP Flow Information Export
              (IPFIX) File Format", RFC 5655, October 2009.

   [I-D.ietf-ipfix-structured-data]
              Claise, B., Dhandapani, G., Yates, S., and P. Aitken,
              "Export of Structured Data in IPFIX",
              draft-ietf-ipfix-structured-data-02 (work in progress),
              July 2010.

   [I-D.ietf-ipfix-anon]
              Boschi, E. and B. Trammell, "IP Flow Anonymisation
              Support", draft-ietf-ipfix-anon-03 (work in progress),
              April 2010.

   [iana-ipfix-assignments]
              Internet Assigned Numbers Authority, "IP Flow Information
              Export Information Elements
              (http://www.iana.org/assignments/ipfix/ipfix.xml)".


Authors' Addresses

   Brian Trammell
   Swiss Federal Institute of Technology Zurich
   Gloriastrasse 35
   8092 Zurich
   Switzerland

   Phone: +41 44 632 70 13
   Email: trammell@tik.ee.ethz.ch


   Benoit Claise
   Cisco Systems, Inc.
   De Kleetlaan 6a b1
   1831 Diagem
   Belgium

   Phone: +32 2 704 5622
   Email: bclaise@cisco.com










Trammell & Claise         Expires April 4, 2011                [Page 22]


  

      

      

    

    

  


--------------050209080709000606050008--

From paitken@cisco.com  Mon Nov 29 10:30:55 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562493A6C1E for ; Mon, 29 Nov 2010 10:30:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.782
X-Spam-Level: 
X-Spam-Status: No, score=-9.782 tagged_above=-999 required=5 tests=[AWL=0.816,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkxNcCdknzvG for ; Mon, 29 Nov 2010 10:30:52 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C86213A6B78 for ; Mon, 29 Nov 2010 10:30:49 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.59,276,1288569600";  d="scan'208,217";a="186970478"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Nov 2010 18:31:59 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oATIVwR2024588; Mon, 29 Nov 2010 18:31:59 GMT
Received: from [10.55.89.2] (dhcp-10-55-89-2.cisco.com [10.55.89.2]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id oATIVu825069; Mon, 29 Nov 2010 18:31:56 GMT
Message-ID: <4CF3F19C.7020805@cisco.com>
Date: Mon, 29 Nov 2010 18:31:56 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10
MIME-Version: 1.0
To: Benoit Claise 
References: <4CD9C807.7060205@cisco.com> <4CF29569.2070708@cisco.com>
In-Reply-To: <4CF29569.2070708@cisco.com>
Content-Type: multipart/alternative; boundary="------------050705010200030706090508"
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] review of draft-trammell-ipfix-ie-doctors-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Nov 2010 18:30:55 -0000

This is a multi-part message in MIME format.
--------------050705010200030706090508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Benoit,

Replying to just a few points:


>>>     [RFC5103] defines a method for exporting bidirectional flow
>>>     information using IPFIX; this document should be followed when
>>>     extending IPFIX to represent information about bidirectional network
>>>     interactions in general.  Additionally, new Information Elements
>>>     should be annotated  for their reversibility or lack thereof as per
>>>     this document.
>>>    
>>
>> Where is this annotation to be recorded? AFAIK there's currently 
>> nowhere to do this in the IANA registry, yet there's no requirement 
>> to create any other document before creating new IEs.
> Isn't part of the description in the IPFIX IANA?

If that's what you intend then you should explicitly say that here.

eg "new Information Elements should be annotated in the IANA registry...".


>>>     Optionally, a Working Group or individual contributor may choose to
>>
>> You should detail "Optionally". New IEs don't need an RFC, but some 
>> applications may require changes to the IPFIX protocol which do 
>> require an RFC.
> This was discussed during the IPFIX working group: unless really 
> really required, don't create a RFC for new IEs allocation.

Exactly! So write it in this draft.

Surely you don't expect new contributors to trawl the group archives 
first? :-(


>> Potentially these issues may be solved with clear version tracking.
> exactly.
> Discussing with Brian in Beijing, we think that one (if not the only 
> one) solution would be to have a version number for IPFIX IANA 
> registry. Everything single time something is changed in it (new IE, 
> extra value for a sub registry, etc...), the version number would be 
> incremented.

I could be OK with that. Did you investigate how other registries deal 
with this issue (if they do, at all?).


>>>     Deprecated Information Elements SHOULD continue to be supported by
>>>     Collecting Processes, but SHOULD NOT be exported by Exporting
>>>     Processes.  The use of deprecated Information Elements SHOULD result
>>>     in a log entry or human-readable warning at theExporting  and
>>>    
>>
>> That's crazy! You're saying that the EP should be updated to report 
>> that it's still sending deprecated fields? LOL. If you're going to 
>> update it to know that it's sending an obsolete field, your time 
>> would clearly be better spent updating it not to export that field 
>> any more.
> We have in mind a kind of syslog message sent from the exporter.

No.

Instead of wasting time adding a message to say "I'm still sending a 
deprecated IE", just change the deprecated IE to the new one.

Anyway, how is a 5, 10, 20... year old EP to know that it's sending 
deprecated IEs? It will be, because it hasn't been updated in all that 
time. However it won't be compliant with this draft because it has no 
way of knowing that what it's sending is deprecated!

So, what exactly are you trying to achieve here?


>>>     Simply changing the context in which an Information Element will be
>>>     used is insufficient reason for the definition of a new Information
>>>     Element.  For example, an extension of IPFIX to log detailed
>>>     information about HTTP transactions alongside network-level
>>>     information should not define httpClientAddress and httpServerAddress
>>>     Information Elements, preferring instead the use of
>>>     sourceIPv[46]Address and destinationIPv[46]Address.
>>>    
>>
>> I've got http through a tunnel, proxy or NAT, such that there are two 
>> source addresses and two destination addresses.
>> One src/dst pair is for http, the other belongs to the tunnel, proxy 
>> or NAT. What do you propose?
> what do you propose? ;-)

When the same IE appears multiple times in a message, we need a way to 
add context to each instance. eg, encapsulation, MPLS labels, and the 
example above.

I don't propose to solve that here today :-)


>>>     The best practice in Information Element creation is a conservative
>>>     one: don't create a new Information Element unlessyou  really need
>>>     it.
>>>    
>> Applications dealing with bidirectional interactions should use
>>
>> Of course you really need it. However, does the wider IPFIX community 
>> really need it?
> let's correct the sentence.  "... unless the IPFIX community really 
> needs it"

How do we know that? Even today, we create new IEs because we believe 
they will be useful in future. We don't ask the community to vote on how 
useful they are.


>>>     Non-flow information defining associations or key-value pairs, on the
>>>     other hand, are handled by IPFIX Options.  Here, the Information
>>>     Elements within an Options Template are split into Scope IEs which
>>>     define the key, and non-scope IEs which define the values associated
>>>     with that key.  Unlike Flows, Options are not necessarily scoped in
>>>     time; an Option is generally held to be in effect until a new set of
>>>     values for a specific set of keys is exported.  While Options are
>>>     often used by IPFIX to export metadata about the collection
>>>     infrastructure, they are applicable to any association information.
>>>        
>>
>> IIRC, there was some discussion about time-scoping IPFIX options and 
>> templates some years ago. eg, we can export a template, indicating 
>> that it will be valid from 6pm until midnight. Or pre-export an 
>> option, indicating that a new selectorAlgorithm will be in force from 
>> 6am.
> I don't recall the discussion, but I think the sentence is fine as it 
> includes "not necessarily"

I've no issue with the sentence; just recalling an old discussion that 
was related. I believe it was between Brian and Andrew.


>>> 8.  Defining Recommended Templates
>>>
>>>     New IPFIX applications SHOULD NOT, in the general case, define fixed
>>>     templates for export, as this throws away much of the flexibility
>>>     afforded by IPFIX.  However, fixed template export is permissible in
>>>     the case that the export implementation must operate in a resource
>>>     constrained environment, and/or that the application is replacing an
>>>     existing fixed-format binary export format in a maximally compatible
>>>     way.In any case, Collecting Processes for such applications SHOULD
>>>     support reordered Templates or Templates with additional Information
>>>     Elements.
>>>
>>>     An Internet-Draft clarifying the use of new Information Elements
>>>
>>>
>>>
>>> Trammell&  Claise         Expires April 4, 2011                [Page 14]
>>> 
>>> Internet-Draft              IPFIX IE-DOCTORS                October 2010
>>>
>>>
>>>     SHOULD include any recommended Templates or Options Templates
>>>     necessary for supporting the application, as well as examples of
>>>    
>>
>> No it shouldn't, because implementers will blindly follow these and 
>> system specifiers will expect exactly these templates / options an no 
>> others, in order to be 100% compliant with the RFC / definition.
>>
>> Rather, the ID MUST specify which fields are required in the option / 
>> template, if any, and MAY give example options and templates, clearly 
>> labelling them as such.
> Like a remark above, we were targeting the predefined Options 
> Templates such as the one in the IPFIX and PSAMP protocols.

Even so, do you think implementers will a) blindly copy the drafts, or 
b) implement their own version (eg, with the fields in another order) ?

Worse, if someone does (b), there's no reason for it not to work. But I 
expect some collectors would reject it, or at least not recognise it as 
intended, because it didn't copy the RFC.


>>>     PSAMP packet reports (section 6.4) and extended packet reports
>>>     (section 6.5).  Recommended Options Templates are defined extensively
>>>     throughout the IPFIX documents, including in the protocol document
>>>     itself [RFC5101] for exporting export statistics; in the file format
>>>     [RFC5655] for exporting file metadata; and in Mediator intermediate
>>>     process definitions such as [I-D.ietf-ipfix-anon] for intermediate
>>>     process metadata.  The discussion in these examples is a good model
>>>     for recommended template definitions.
>>>    
>>
>> In your experience (or a quick poll?) do current IPFIX systems 
>> implement these exactly as specified, or does anyone implement them 
>> with the caveats described above (eg, in a different order, or with 
>> additional fields) ?
> no idea on this one.

As I said, a quick poll: ask the WG what they implement.
An interop would also answer this.


>>>        wlanSSID(146)[v]
>>>    
>>
>> It's 147.
> Excellent catch.
> After all those years, I still impressed by your thorough reviews ;-)

Thank you :-)


>>>     IE.Due to the way Information Elements are represented in Options
>>>     Templates, all {scope} IESpecs must appear before any non-scope
>>>     IESpec.  The Flow Key Options Template defined in section 4.4 of
>>>     [RFC5101] in IESpec syntax is shown below:
>>>    
>>
>> Nonsense! That's only true when the IEs are being exported in an 
>> option on the wire, because that's how the protocol works.
>> However, when writing them down, they can be any way around that you 
>> like.
>>
>> eg, specifications written by people who are unfamiliar with the 
>> exact details of the export protocols, but who simply want to use our 
>> exporter, sometimes list fields in alphabetical or numerical order. 
>> As long as {scope} is clearly indicated at the relevant place, it's 
>> up to us as protocol experts to deal with the ordering detail.
> We can relax the sentence, but I'm still convinced the scope first 
> makes more sense.

It makes sense to us as protocol people. However, alphabetical or random 
order often makes more sense to those who simply want to export data, 
without knowing how the protocol actually works. Perhaps /recommend/ 
scope first.


P.

--------------050705010200030706090508
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  
  


Benoit,



Replying to just a few points:







  

    

      
   [RFC5103] defines a method for exporting bidirectional flow
   information using IPFIX; this document should be followed when
   extending IPFIX to represent information about bidirectional network
   interactions in general.  Additionally, new Information Elements
   should be annotated for their reversibility or lack thereof as per
   this document.
  

    

    

Where is this annotation to be recorded? AFAIK there's currently
nowhere to do this in the IANA registry, yet there's no requirement to
create any other document before creating new IEs.

  

Isn't part of the description in the IPFIX IANA?





If that's what you intend then you should explicitly say that here.



eg "new Information Elements should be annotated in the IANA
registry...".







  

    

      
   Optionally, a Working Group or individual contributor may choose to  

    

    

You should detail "Optionally". New IEs don't need an RFC, but some
applications may require changes to the IPFIX protocol which do require
an RFC.

  

This was discussed during the IPFIX working group: unless really really
required, don't create a RFC for new IEs allocation.





Exactly! So write it in this draft.



Surely you don't expect new contributors to trawl the group archives
first? :-(







  

Potentially these issues may be solved with clear version tracking.

  

exactly.

Discussing with Brian in Beijing, we think that one (if not the only
one) solution would be to have a version number for IPFIX IANA
registry. Everything single time something is changed in it (new IE,
extra value for a sub registry, etc...), the version number would be
incremented.





I could be OK with that. Did you investigate how other registries deal
with this issue (if they do, at all?).







  

    

      
   Deprecated Information Elements SHOULD continue to be supported by
   Collecting Processes, but SHOULD NOT be exported by Exporting
   Processes.  The use of deprecated Information Elements SHOULD result
   in a log entry or human-readable warning at the Exporting and
  

    

    

That's crazy! You're saying that the EP should be updated to report
that it's still sending deprecated fields? LOL. If you're going to
update it to know that it's sending an obsolete field, your time would
clearly be better spent updating it not to export that field any more.

  

We have in mind a kind of syslog message sent from the exporter.





No.



Instead of wasting time adding a message to say "I'm still sending a
deprecated IE", just change the deprecated IE to the new one.



Anyway, how is a 5, 10, 20... year old EP to know that it's sending
deprecated IEs? It will be, because it hasn't been updated in all that
time. However it won't be compliant with this draft because it has no
way of knowing that what it's sending is deprecated!



So, what exactly are you trying to achieve here?







  

    

      
   Simply changing the context in which an Information Element will be
   used is insufficient reason for the definition of a new Information
   Element.  For example, an extension of IPFIX to log detailed
   information about HTTP transactions alongside network-level
   information should not define httpClientAddress and httpServerAddress
   Information Elements, preferring instead the use of
   sourceIPv[46]Address and destinationIPv[46]Address.
  

    

    

I've got http through a tunnel, proxy or NAT, such that there are two
source addresses and two destination addresses.

One src/dst pair is for http, the other belongs to the tunnel, proxy or
NAT. What do you propose?

  

what do you propose? ;-)





When the same IE appears multiple times in a message, we need a way to
add context to each instance. eg, encapsulation, MPLS labels, and the
example above.



I don't propose to solve that here today :-)







  

    

      
   The best practice in Information Element creation is a conservative
   one: don't create a new Information Element unless you really need
   it.
  

    

Applications dealing with bidirectional interactions should use

    

Of course you really need it. However,
does the wider IPFIX community really need it?

  

let's correct the sentence.  "... unless the IPFIX community really
needs it"





How do we know that? Even today, we create new IEs because we believe
they will be useful in future. We don't ask the community to vote on
how useful they are.







  

    

      
   Non-flow information defining associations or key-value pairs, on the
   other hand, are handled by IPFIX Options.  Here, the Information
   Elements within an Options Template are split into Scope IEs which
   define the key, and non-scope IEs which define the values associated
   with that key.  Unlike Flows, Options are not necessarily scoped in
   time; an Option is generally held to be in effect until a new set of
   values for a specific set of keys is exported.  While Options are
   often used by IPFIX to export metadata about the collection
   infrastructure, they are applicable to any association information.
      

    

    

IIRC, there was some discussion about time-scoping IPFIX options and
templates some years ago. eg, we can export a template, indicating that
it will be valid from 6pm until midnight. Or pre-export an option,
indicating that a new selectorAlgorithm will be in force from 6am.

  

I don't recall the discussion, but I think the sentence is fine as it
includes "not necessarily"





I've no issue with the sentence; just recalling an old discussion that
was related. I believe it was between Brian and Andrew.







  

    

      
8.  Defining Recommended Templates

   New IPFIX applications SHOULD NOT, in the general case, define fixed
   templates for export, as this throws away much of the flexibility
   afforded by IPFIX.  However, fixed template export is permissible in
   the case that the export implementation must operate in a resource
   constrained environment, and/or that the application is replacing an
   existing fixed-format binary export format in a maximally compatible
   way.  In any case, Collecting Processes for such applications SHOULD
   support reordered Templates or Templates with additional Information
   Elements.

   An Internet-Draft clarifying the use of new Information Elements



Trammell & Claise         Expires April 4, 2011                [Page 14]

Internet-Draft              IPFIX IE-DOCTORS                October 2010


   SHOULD include any recommended Templates or Options Templates
   necessary for supporting the application, as well as examples of
  

    

    

No it shouldn't, because implementers will blindly follow these and
system specifiers will expect exactly these templates / options an no
others, in order to be 100% compliant with the RFC / definition.

    

Rather, the ID MUST specify which fields are required in the option /
template, if any, and MAY give example options and templates, clearly
labelling them as such.

  

Like a remark above, we were targeting the predefined Options Templates
such as the one in the IPFIX and PSAMP protocols.





Even so, do you think implementers will a) blindly copy the drafts, or
b) implement their own version (eg, with the fields in another order) ?



Worse, if someone does (b), there's no reason for it not to work. But I
expect some collectors would reject it, or at least not recognise it as
intended, because it didn't copy the RFC.







  

    

      
   PSAMP packet reports (section 6.4) and extended packet reports
   (section 6.5).  Recommended Options Templates are defined extensively
   throughout the IPFIX documents, including in the protocol document
   itself [RFC5101] for exporting export statistics; in the file format
   [RFC5655] for exporting file metadata; and in Mediator intermediate
   process definitions such as [I-D.ietf-ipfix-anon] for intermediate
   process metadata.  The discussion in these examples is a good model
   for recommended template definitions.
  

    

    

In your experience (or a quick poll?) do current IPFIX systems
implement these exactly as specified, or does anyone implement them
with the caveats described above (eg, in a different order, or with
additional fields) ?

  

no idea on this one.





As I said, a quick poll: ask the WG what they implement.

An interop would also answer this.







  

    

      
      wlanSSID(146)<string>[v]
  

    

    

It's 147.

  

Excellent catch.

After all those years, I still impressed by your thorough reviews ;-)





Thank you :-)







  

    

      
   IE.  Due to the way Information Elements are represented in Options
   Templates, all {scope} IESpecs must appear before any non-scope
   IESpec.  The Flow Key Options Template defined in section 4.4 of
   [RFC5101] in IESpec syntax is shown below:
  

    

    

Nonsense! That's only true when the IEs are being exported in an option
on the wire, because that's how the protocol works.

However, when writing them down, they can be any way around that you
like.

    

eg, specifications written by people who are unfamiliar with the exact
details of the export protocols, but who simply want to use our
exporter, sometimes list fields in alphabetical or numerical order. As
long as {scope} is clearly indicated at the relevant place, it's up to
us as protocol experts to deal with the ordering detail.

  

We can relax the sentence, but I'm still convinced the scope first
makes more sense.





It makes sense to us as protocol people. However, alphabetical or
random order often makes more sense to those who simply want to export
data, without knowing how the protocol actually works. Perhaps recommend
scope first.





P.




--------------050705010200030706090508--

From paitken@cisco.com  Tue Nov 30 03:16:53 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF4828C105 for ; Tue, 30 Nov 2010 03:16:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.945
X-Spam-Level: 
X-Spam-Status: No, score=-9.945 tagged_above=-999 required=5 tests=[AWL=0.654,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ft+ALrJsRupu for ; Tue, 30 Nov 2010 03:16:53 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D4B973A6C6D for ; Tue, 30 Nov 2010 03:16:52 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEADds9ExAZnwN/2dsb2JhbACjC3GmaptVhUcEimGDDw
X-IronPort-AV: E=Sophos;i="4.59,279,1288569600"; d="scan'208";a="187454207"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 30 Nov 2010 11:18:04 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAUBI3Z9001926; Tue, 30 Nov 2010 11:18:03 GMT
Received: from [10.55.94.46] (dhcp-10-55-94-46.cisco.com [10.55.94.46]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id oAUBI0811616; Tue, 30 Nov 2010 11:18:01 GMT
Message-ID: <4CF4DD68.3040402@cisco.com>
Date: Tue, 30 Nov 2010 11:18:00 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10
MIME-Version: 1.0
To: descombes 
References: <4CC7DE4E.6090009@lpsc.in2p3.fr> <4CEBB6D9.8040609@cisco.com>	<4CEF8803.5090401@lpsc.in2p3.fr> <4CF0F459.3070001@net.in.tum.de> <2185b5dec523a37626b9d7cde312c4ca@lpsc-mail>
In-Reply-To: <2185b5dec523a37626b9d7cde312c4ca@lpsc-mail>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] IPFIX flows timestamps
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Nov 2010 11:16:53 -0000

Thierry,

> If Cisco implementation just send "LAST_SWITCHED" and
> "FIRST_SWITCHED" fields... I can't guess the sysuptime, and it's not
> worth I bother me: whatever algorithm I do, my software will just
> work with NetFlow 9.
>
> So, what's the situation ?

Although this isn't the place to discuss details of cisco's
implementation, please be assured that we won't export sysuptime based
timestamps that you can't possibly decode.

Depending upon the implementation, we would either select an appropriate
pair of timestamps from the #150 - #159 range to export instead of the
sysuptime, or export sysuptime fields and also include #160
systemInitTimeMilliseconds which gives the base time.

See section 4.7 of RFC 5153:

    Therefore, the sending of the flowStartSysUpTime and flowEndSysUpTime
    Information Elements without also sending the
    systemInitTimeMilliseconds Information Element is not recommended.


Cheers,
P.

From descombes@lpsc.in2p3.fr  Tue Nov 30 07:58:56 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 633AC28C0E2 for ; Tue, 30 Nov 2010 07:58:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.784
X-Spam-Level: 
X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.465,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vj4yoQcdDfbW for ; Tue, 30 Nov 2010 07:58:55 -0800 (PST)
Received: from lpsc-mail.in2p3.fr (lpsc-mail.in2p3.fr [134.158.40.8]) by core3.amsl.com (Postfix) with ESMTP id 68D0728C0DD for ; Tue, 30 Nov 2010 07:58:54 -0800 (PST)
Received: from [134.158.40.158] (lpsc0158x.in2p3.fr [134.158.40.158]) by lpsc-mail.in2p3.fr (8.13.1/8.13.1/In2p3) with ESMTP id oAUG02Ze015704; Tue, 30 Nov 2010 17:00:02 +0100
Message-ID: <4CF51F82.5090508@lpsc.in2p3.fr>
Date: Tue, 30 Nov 2010 17:00:02 +0100
From: DESCOMBES Thierry 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100808 Mandriva/3.1.2-0.2mdv2010.1 (2010.1) Thunderbird/3.1.2
MIME-Version: 1.0
To: Paul Aitken 
References: <4CC7DE4E.6090009@lpsc.in2p3.fr> <4CEBB6D9.8040609@cisco.com>	<4CEF8803.5090401@lpsc.in2p3.fr> <4CF0F459.3070001@net.in.tum.de> <2185b5dec523a37626b9d7cde312c4ca@lpsc-mail> <4CF4DD68.3040402@cisco.com>
In-Reply-To: <4CF4DD68.3040402@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] IPFIX flows timestamps
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Nov 2010 15:58:56 -0000

  Hi Paul,
Thanks for your answer. You're right and I don't want to discuss details 
of Cisco's implementation. I'd just like to know if a compatible network 
equipement exists, in order to test my algorithm. Until now, is there 
any implementations of IPFix on switches ? I've read that Nortel finally 
used Netflow 9... Thanks a lot.
Cheers
T.D


Le 30/11/2010 12:18, Paul Aitken a écrit :
> Thierry,
>
>> If Cisco implementation just send "LAST_SWITCHED" and
>> "FIRST_SWITCHED" fields... I can't guess the sysuptime, and it's not
>> worth I bother me: whatever algorithm I do, my software will just
>> work with NetFlow 9.
>>
>> So, what's the situation ?
>
> Although this isn't the place to discuss details of cisco's
> implementation, please be assured that we won't export sysuptime based
> timestamps that you can't possibly decode.
>
> Depending upon the implementation, we would either select an appropriate
> pair of timestamps from the #150 - #159 range to export instead of the
> sysuptime, or export sysuptime fields and also include #160
> systemInitTimeMilliseconds which gives the base time.
>
> See section 4.7 of RFC 5153:
>
>    Therefore, the sending of the flowStartSysUpTime and flowEndSysUpTime
>    Information Elements without also sending the
>    systemInitTimeMilliseconds Information Element is not recommended.
>
>
> Cheers,
> P.