From Internet-Drafts@ietf.org Mon Dec 6 10:15: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 CBDC93A688B; Mon, 6 Dec 2010 10:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 GhhTlzAuokmI; Mon, 6 Dec 2010 10:15:05 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 183863A688A; Mon, 6 Dec 2010 10:15:03 -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 X-IETF-IDTracker: 3.09 Message-ID: <20101206181503.20861.94938.idtracker@localhost> Date: Mon, 06 Dec 2010 10:15:03 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-flow-selection-tech-03.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, 06 Dec 2010 18:15: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 : Flow Selection Techniques Author(s) : L. Peluso, S. D'Antonio, T. Zseby, M. Molina Filename : draft-ietf-ipfix-flow-selection-tech-03.txt Pages : 29 Date : 2010-12-6 Flow selection is the process of selecting a subset of flows from all flows observed at an observation point. The objective of flow selection is to reduce the effort of post-processing flow data and transferring flow records. The flow selection process can be enabled at different stages of the measurement process. It can be applied either directly after classification or at recording/exporting time by limiting the number of flows to be stored and/or exported to the collecting process. This document describes motivations for flow selection and presents flow selection techniques. It furthermore provides an information model for configuring flow selection techniques and discusses what information about a flow selection process is worth exporting through a suitable information model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-03.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-flow-selection-tech-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-6101416.I-D@ietf.org> --NextPart-- From shanna@juniper.net Wed Dec 8 22:22:40 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 012373A69F0; Wed, 8 Dec 2010 22:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 thBzB5Ntl827; Wed, 8 Dec 2010 22:22:35 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 7E7253A69F5; Wed, 8 Dec 2010 22:22:33 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTQB1/269RZGPLnPwZfXhZ4c8e+QyPEQ+@postini.com; Wed, 08 Dec 2010 22:24:02 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 8 Dec 2010 22:23:10 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 9 Dec 2010 01:23:09 -0500 From: Stephen Hanna To: "ietf@ietf.org" , "secdir@ietf.org" , "ipfix@ietf.org" Date: Thu, 9 Dec 2010 01:23:06 -0500 Thread-Topic: secdir review of draft-ietf-ipfix-mediators-framework-09.txt Thread-Index: Acth3WZtFoUbk+23ReaFVG39Xm1qzw1iXwtQ Message-ID: 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-Mailman-Approved-At: Thu, 09 Dec 2010 11:55:43 -0800 Subject: [IPFIX] secdir review of draft-ietf-ipfix-mediators-framework-09.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: Thu, 09 Dec 2010 06:22:40 -0000 I have reviewed this document as part of the security directorate's =20 ongoing effort to review all IETF documents being processed by the =20 IESG. These comments were written primarily for the benefit of the =20 security area directors. Document editors and WG chairs should treat =20 these comments just like any other last call comments. This document adds a new concept to the IPFIX architecture (RFC 5470): IPFIX Mediation. This concept allows conversion, correlation, selection, and other transformations on IPFIX records. The document is clear and the Security Considerations section seems to adequately cover the issues raised. I don't see any problems from a security perspective. Thanks, Steve From bclaise@cisco.com Sat Dec 11 06:32: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 C82DF3A6CA8 for ; Sat, 11 Dec 2010 06:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 2u8huAtNdKZh for ; Sat, 11 Dec 2010 06:31:54 -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 39A973A6D23 for ; Sat, 11 Dec 2010 06:31:42 -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 oBBEFqDs027444; Sat, 11 Dec 2010 15:15:52 +0100 (CET) Received: from [10.82.253.76] (rtp-vpn6-1351.cisco.com [10.82.253.76]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oBBEFoEw001662; Sat, 11 Dec 2010 15:15:51 +0100 (CET) Message-ID: <4D038795.4040701@cisco.com> Date: Sat, 11 Dec 2010 09:15:49 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Nevil Brownlee References: <4CBBA607.7080404@auckland.ac.nz> In-Reply-To: <4CBBA607.7080404@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] Two WGLCs starting now 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, 11 Dec 2010 14:32:37 -0000 Dear IPFIX chairs, > > Hi all: > > We have two drafts waiting for Working Group Last Call. > Their WGLCs start now, and will finish on 3 November (the > Wednesday before the Beijing IETF). > > The drafts are: > 1. draft-ietf-ipfix-structured-data-03.txt > Second WGLC for this draft, the first was back in July > for the -01 version. There's been a *lot* of discussion > on the mailing list since!) > 2. draft-ietf-ipfix-configuration-model-07.txt > We were waiting for the YANG RFCs to be published for this one. As far as I recall, you asked the YANG gang to review this draft. Any feedback? Note: draft-ietf-ipfix-configuration-model-08.txt has been posted. Regards, Benoit. > > Cheers, Nevil (IPFIX co-chair) > From aakhter@cisco.com Sun Dec 12 17:55: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 903F03A6D9F for ; Sun, 12 Dec 2010 17:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.311 X-Spam-Level: X-Spam-Status: No, score=-107.311 tagged_above=-999 required=5 tests=[AWL=-2.548, 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, TRACKER_ID=2.003, 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 bgx+CBDphW3I for ; Sun, 12 Dec 2010 17:54:48 -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 C2FE03A6D52 for ; Sun, 12 Dec 2010 17:54:45 -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,333,1288569600"; d="scan'208,217";a="191979756" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 13 Dec 2010 01:56:21 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oBD1uLc8020468; Mon, 13 Dec 2010 01:56:21 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Dec 2010 19:56:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB9A68.F0143065" Date: Sun, 12 Dec 2010 19:54:22 -0600 Message-ID: <7F298ACC76CC154F832B6D02852D169F036AD602@XMB-RCD-101.cisco.com> In-Reply-To: <4CECC122.6090107@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] WG last call on draft-ietf-ipfix-psamp-mib-02 Thread-Index: AcuLq2juFWRMk8WlQ2+HwQaxWQaP5QOvQ+sA References: <4CDD2A1F.9040804@cisco.com> <4CECC122.6090107@cisco.com> From: "Aamer Akhter (aakhter)" To: "Benoit Claise (bclaise)" , "Paul Aitken (paitken)" X-OriginalArrivalTime: 13 Dec 2010 01:56:21.0077 (UTC) FILETIME=[F0675050:01CB9A68] Cc: dietz@neclab.eu, IETF IPFIX Working Group , 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: Mon, 13 Dec 2010 01:55:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB9A68.F0143065 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Benoit/ IPFIXers, =20 I did a quick review and am fine (with Paul's changes) with the document.=20 =20 =20 =20 From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of Benoit Claise (bclaise) Sent: Wednesday, November 24, 2010 2:39 AM To: Paul Aitken (paitken) Cc: IETF IPFIX Working Group; dietz@neclab.eu; Juergen Quittek Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-psamp-mib-02 =20 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 >=20 >=20 > Definitions of Managed Objects for Packet Sampling > >=20 > Abstract >=20 > 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. >=20 > Status of this Memo >=20 > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > 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/. >=20 > 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." >=20 > This Internet-Draft will expire on May 12, 2011. >=20 > Copyright Notice >=20 > Copyright (c) 2010 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 > 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 >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 1] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > 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. >=20 >=20 > Table of Contents >=20 > 1. Open Issues/TODOs . . . . . . . . . . . . . . . . . . . . . . 3 >=20 > 2. The Internet-Standard Management Framework . . . . . . . . . . 3 >=20 > 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 >=20 > 4. PSAMP Documents Overview . . . . . . . . . . . . . . . . . . . 4 >=20 > 5. Related IPFIX Documents . . . . . . . . . . . . . . . . . . . 4 >=20 > 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 >=20 > 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 >=20 > 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 >=20 > 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 >=20 > 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 26 >=20 > 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 > 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 > 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 >=20 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 2] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > 1. Open Issues/TODOs >=20 > 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 >=20 > 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 >=20 > 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]. >=20 > 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. >=20 > Its purpose is to define managed objects for monitoring PSAMP Devices > performing packet selection by sampling and hashing as described in > [RFC5475]. >=20 > It is assumed that packet sampling is performed according to the > framework defined in [RFC5474]. >=20 > 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" =20 =09 =09 >=20 > Section 6 describes the structure of the PSAMP MIB module and section > 7 contains the formal definition. Security issues are discussed in >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 3] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > section 8. =09 What about sections 4 and 5? Done above. > 4. PSAMP Documents Overview >=20 > [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. >=20 > [RFC5475]: "Sampling and Filtering Techniques for IP Packet > Selection" describes the set of packet selection techniques supported > by PSAMP. >=20 > [RFC5476]: "Packet Sampling (PSAMP) Protocol Specifications" > specifies the export of packet information from a PSAMP Exporting > Process to a PSAMP Collecting Process. >=20 > [RFC5477]: "Information Model for Packet Sampling Exports" defines an > information and data model for PSAMP. >=20 > This document: "Definitions of Managed Objects for Packet Sampling" > describes the PSAMP Management Information Base. >=20 >=20 > 5. Related IPFIX Documents >=20 > 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. >=20 >=20 > 6. Structure of the PSAMP MIB module >=20 > 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 >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 4] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > 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. >=20 > 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: >=20 > ipfixSelectorMIB > +- ipfixSelectorObjects(1) > +- ipfixSelectorFunctions(1) > +- ipfixFuncSelectAll(1) > +- ipfixFuncSelectAllAvail(1) >=20 > 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]. >=20 > 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=20 Juergen Quittek presented the PSAMP MID draft. This only needed=20 textual conventions for 64-bit unsigned integers and real. The MIB=20 Doctors have provided one for Unsigned64, but we will need to create a=20 new one for IEEE 64-bit floating objects. Dan Romascanu pointed out=20 that our Float64 TC should be general, so that other MIBs can use it.=20 >=20 > 6.1. Textual Conventions >=20 > 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]. >=20 > The Unsigned64TC textual convention describes an unsigned integer of > 64 bits. It is imported from the APPLICATION MIB. >=20 > The PsampFloat64 textuanl convention describes a double precision > floating point number. It is encoded accroding to [IEEE.754.1985]. Typo x 2. >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 5] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > 6.2. Packet Selection Functions >=20 > 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]: >=20 > 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? >=20 > 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. >=20 > 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]. >=20 > 6.2.1. Systematic Count-based Sampling >=20 > 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: >=20 > psampSampCountBased(2) > +-- psampSampCountBasedAvail(1) > +-- psampSampCountBasedParamSetTable(2) > +-- psampSampCountBasedParamSetEntry(1) [psampSampCountBasedIndex] > +-- psampSampCountBasedIndex(1) > +-- psampSampCountBasedInterval(2) > +-- psampSampCountBasedSpace(3) >=20 > 6.2.2. Systematic Time-based Sampling >=20 > 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". >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 6] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > 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: >=20 > psampSampTimeBased(3) > +-- psampSampTimeBasedAvail(1) > +-- psampSampTimeBasedParamSetTable(2) > +-- psampSampTimeBasedParamSetEntry(1) [psampSampTimeBasedIndex] > +-- psampSampTimeBasedIndex(1) > +-- psampSampTimeBasedInterval(2) > +-- psampSampTimeBasedSpace(3) >=20 > 6.2.3. Random n-out-of-N Sampling >=20 > 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: >=20 > 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." ::=3D { psampSampRandOutOfN 3 } =20 However, there is no entry for "::=3D { psampSampRandOutOfN 2 }", so you have a good point. =09 =09 > +-- psampSampRandOutOfNParamSetEntry(1) [psampSampRandOutOfNIndex] > +-- psampSampRandOutOfNIndex(1) > +-- psampSampRandOutOfNSamplingSize(2) > +-- psampSampRandOutOfNPopulation(3) >=20 > 6.2.4. Uniform Probabilistic Sampling >=20 > The fourth selector function is uniform probabilistic sampling. It > has just a single parameter called psampSampUniProbProbability: >=20 > psampSampUniProb(5) > +-- psampSampUniProbAvail(1) > +-- psampSampUniProbParamSetTable(3) =09 Why is this (3) rather than (2) ? same good point. > +-- psampSampUniProbParamSetEntry(1) [psampSampUniProbIndex] > +-- psampSampUniProbIndex(1) > +-- psampSampUniProbProbability(2) >=20 > 6.2.5. Property Match Filtering >=20 > 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. >=20 >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 7] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > psampFiltPropMatch(6) > +-- psampFiltPropMatchAvail(1) >=20 > 6.2.6. Hash-based Filtering >=20 > 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? >=20 > 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) >=20 > Further parameters depend on the applied hash function and are not > specified within the PSAMP MIB module. >=20 >=20 > 7. Definitions >=20 >=20 Have you compiled this MIB? > PSAMP-MIB DEFINITIONS ::=3D BEGIN >=20 > 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 >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 8] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > FROM IPFIX-SELECTOR-MIB; >=20 > 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 >=20 > 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 >=20 > 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 >=20 > Benoit Claise > Cisco Systems, Inc. > De Kleetlaan 6a b1 > Degem 1831 > Belgium > Phone: +32 2 704 5622 > Email: bclaise@cisco.com >=20 > 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 >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 9] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > capabilities, configuration and statistics. >=20 > 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. >=20 > -- Revision history >=20 > REVISION "201011081200Z" -- 08 November 2010 > DESCRIPTION > "Initial version, published as RFC yyyy." > -- RFC Ed.: replace yyyy with actual RFC number & remove this notice >=20 > ::=3D { mib-2 xxx } > -- xxx to be assigned by IANA. This isn't mentioned in the IANA section. good point. >=20 > PsampFloat64 ::=3D 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)) >=20 > -- Top level structure of the MIB >=20 > psampObjects OBJECT IDENTIFIER ::=3D { psampMIB 1 } > psampConformance OBJECT IDENTIFIER ::=3D { psampMIB 2 } >=20 >=20 > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > -- Packet selection sampling methods group of objects > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --* Method 1: Systematic count-based Sampling > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > -- Reference: RFC5475, Section 5.1, RFC5476 Section 6.5.2.1 and > -- RFC5477, Section 8.2 > psampSampCountBased OBJECT IDENTIFIER > ::=3D { ipfixSelectorFunctions 2 } >=20 > psampSampCountBasedAvail OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 10] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > STATUS current > DESCRIPTION > "This object indicates the availability of systematic > count-based sampling at the managed node. >=20 > 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 } > ::=3D { psampSampCountBased 1 } >=20 > -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ >=20 > 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." > ::=3D { psampSampCountBased 2 } >=20 > psampSampCountBasedParamSetEntry OBJECT-TYPE > SYNTAX PsampSampCountBasedParamSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Defines an entry in the psampSampCountBasedParamSetTable." > INDEX { psampSampCountBasedIndex } > ::=3D { psampSampCountBasedParamSetTable 1 } >=20 > PsampSampCountBasedParamSetEntry ::=3D > SEQUENCE { > psampSampCountBasedIndex Integer32, > psampSampCountBasedInterval Unsigned32, > psampSampCountBasedSpace Unsigned32 > } >=20 > 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. >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 11] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > object ipfixSelectionProcessSelectorFunctionentries of > the ipfixSelectionProcessTable in the IPFIX-MIB as reference > to this parameter set." > ::=3D { psampSampCountBasedParamSetEntry 1 } >=20 > 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" > ::=3D { psampSampCountBasedParamSetEntry 2 } >=20 > 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" > ::=3D { psampSampCountBasedParamSetEntry 3 } >=20 > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --* Method 2: Systematic time-based Sampling > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > -- Reference: RFC5475, Section 5.1, RFC5476 Section 6.5.2.2 and > -- RFC5477, Section 8.2 > psampSampTimeBased OBJECT IDENTIFIER > ::=3D { ipfixSelectorFunctions 3 } >=20 > 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. >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 12] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > 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 } > ::=3D { psampSampTimeBased 1 } >=20 > -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ >=20 > 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." > ::=3D { psampSampTimeBased 2 } >=20 > psampSampTimeBasedParamSetEntry OBJECT-TYPE > SYNTAX PsampSampTimeBasedParamSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Defines an entry in the psampSampTimeBasedParamSetTable." > INDEX { psampSampTimeBasedIndex } > ::=3D { psampSampTimeBasedParamSetTable 1 } >=20 > PsampSampTimeBasedParamSetEntry ::=3D > SEQUENCE { > psampSampTimeBasedIndex Integer32, > psampSampTimeBasedInterval Unsigned32, > psampSampTimeBasedSpace Unsigned32 > } >=20 > 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." > ::=3D { psampSampTimeBasedParamSetEntry 1 } >=20 >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 13] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > 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" > ::=3D { psampSampTimeBasedParamSetEntry 2 } >=20 > 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" > ::=3D { psampSampTimeBasedParamSetEntry 3 } >=20 > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --* Method 3: Random n-out-of-N Sampling > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > -- Reference: RFC5475, Section 5.2.1, RFC5476 Section 6.5.2.3 and > -- RFC5477, Section 8.2 > psampSampRandOutOfN OBJECT IDENTIFIER > ::=3D { ipfixSelectorFunctions 4 } >=20 > 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. >=20 > 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 } >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 14] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > ::=3D { psampSampRandOutOfN 1 } >=20 > -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ >=20 > 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." > ::=3D { psampSampRandOutOfN 3 } >=20 > psampSampRandOutOfNParamSetEntry OBJECT-TYPE > SYNTAX PsampSampRandOutOfNParamSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Defines an entry in the psampSampRandOutOfNParamSetTable." > INDEX { psampSampRandOutOfNIndex } > ::=3D { psampSampRandOutOfNParamSetTable 1 } >=20 > PsampSampRandOutOfNParamSetEntry ::=3D > SEQUENCE { > psampSampRandOutOfNIndex Integer32, > psampSampRandOutOfNSamplingSize Unsigned32, > psampSampRandOutOfNPopulation Unsigned32 > } >=20 > 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." > ::=3D { psampSampRandOutOfNParamSetEntry 1 } >=20 > psampSampRandOutOfNSamplingSize OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "packets" > MAX-ACCESS read-only >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 15] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > 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" > ::=3D { psampSampRandOutOfNParamSetEntry 2 } >=20 > 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" > ::=3D { psampSampRandOutOfNParamSetEntry 3 } >=20 > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --* Method 4: Uniform probabilistic Sampling > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > -- Reference: RFC5475, Section 5.2.2, RFC5476 Section 6.5.2.4 and > -- RFC5477, Section 8.2 > psampSampUniProb OBJECT IDENTIFIER ::=3D { ipfixSelectorFunctions 5 = } >=20 > 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. >=20 > 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 } > ::=3D { psampSampUniProb 1 } >=20 > -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ >=20 > -- Reference: RFC5475, Section 5.2.2.1 and RFC5477, Section 8.2 > psampSampUniProbParamSetTable OBJECT-TYPE > SYNTAX SEQUENCE OF >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 16] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > 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." > ::=3D { psampSampUniProb 3 } >=20 > psampSampUniProbParamSetEntry OBJECT-TYPE > SYNTAX PsampSampUniProbParamSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Defines an entry in the psampSampUniProbParamSetTable." > INDEX { psampSampUniProbIndex } > ::=3D { psampSampUniProbParamSetTable 1 } >=20 > PsampSampUniProbParamSetEntry ::=3D > SEQUENCE { > psampSampUniProbIndex Integer32, > psampSampUniProbProbability PsampFloat64 > } >=20 > 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." > ::=3D { psampSampUniProbParamSetEntry 1 } >=20 > 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 >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 17] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > "RFC5475, Section 5.2.2.1 and RFC5477, Section 8.2" > ::=3D { psampSampUniProbParamSetEntry 2 } >=20 > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > -- Packet selection filtering methods group of objects > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --* Method 5: Property Match filtering > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > -- Reserves Method 5 (see RFC5475, Section 6.1, RFC5476 > -- Section 6.5.2.5 and RFC5477) > psampFiltPropMatch OBJECT IDENTIFIER > ::=3D { ipfixSelectorFunctions 6 } >=20 > 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. >=20 > 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 } > ::=3D { psampFiltPropMatch 1 } >=20 > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --* Method 1: Hash filtering Typo: it's method 6. > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > -- Reference: RFC5475, Section 6.2, RFC5476 Section 6.5.2.6 and > -- RFC5477, Section 8.3 > psampFiltHash OBJECT IDENTIFIER ::=3D { ipfixSelectorFunctions 7 } >=20 > psampFiltHashAvail OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object indicates the availability of hash filtering > at the managed node. >=20 > A Selector may be unavailable if it is implemented but > currently disabled due to e.g., administrative reasons, lack >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 18] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > of resources or similar." > DEFVAL { false } > ::=3D { psampFiltHash 1 } >=20 > psampFiltHashCapabilities OBJECT IDENTIFIER > ::=3D { psampFiltHash 2 } >=20 > -- Parameter Set Table +++++++++++++++++++++++++++++++++++++++++++++ >=20 > -- 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." > ::=3D { psampFiltHash 3 } >=20 > psampFiltHashParamSetEntry OBJECT-TYPE > SYNTAX PsampFiltHashParamSetEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Defines an entry in the psampFiltHashParamSetTable." > INDEX { psampFiltHashIndex } > ::=3D { psampFiltHashParamSetTable 1 } >=20 > PsampFiltHashParamSetEntry ::=3D > SEQUENCE { > psampFiltHashIndex Integer32, > psampFiltHashFunction INTEGER, > psampFiltHashInitializerValue Unsigned64TC, > psampFiltHashIpPayloadOffset Unsigned64TC, > psampFiltHashIpPayloadSize Unsigned64TC, > psampFiltHashSelectedRangeMin Unsigned64TC, > psampFiltHashSelectedRangeMax Unsigned64TC, > psampFiltHashOutputRangeMin Unsigned64TC, > psampFiltHashOutputRangeMax Unsigned64TC > } >=20 > psampFiltHashIndex OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 19] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > "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." > ::=3D { psampFiltHashParamSetEntry 1 } >=20 > 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: >=20 > crc32(1) >=20 > ipsx(2) >=20 > bob(3) > " > ::=3D { psampFiltHashParamSetEntry 2 } >=20 > 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" > ::=3D { psampFiltHashParamSetEntry 3 } >=20 > 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" > ::=3D { psampFiltHashParamSetEntry 4 } >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 20] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > 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" > ::=3D { psampFiltHashParamSetEntry 5 } >=20 > 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" > ::=3D { psampFiltHashParamSetEntry 6 } >=20 > 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" > ::=3D { psampFiltHashParamSetEntry 7 } >=20 > 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" > ::=3D { psampFiltHashParamSetEntry 8 } >=20 > psampFiltHashOutputRangeMax OBJECT-TYPE > SYNTAX Unsigned64TC > MAX-ACCESS read-only > STATUS current >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 21] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > 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" > ::=3D { psampFiltHashParamSetEntry 9 } >=20 > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > -- Conformance information > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > psampCompliances OBJECT IDENTIFIER ::=3D { psampConformance 1 } > psampGroups OBJECT IDENTIFIER ::=3D { psampConformance 2 } >=20 > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > -- Compliance statements > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 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 >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 22] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > filter function is implemented in the equipment." > ::=3D { psampCompliances 1 } >=20 > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > -- MIB groupings > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 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." > ::=3D { psampGroups 2 } >=20 > psampGroupSampTimeBased OBJECT-GROUP > OBJECTS { > psampSampTimeBasedAvail, > psampSampTimeBasedInterval, > psampSampTimeBasedSpace > } > STATUS current > DESCRIPTION > "These objects are needed if time based sampling is > implemented." > ::=3D { psampGroups 3 } >=20 > psampGroupSampRandOutOfN OBJECT-GROUP > OBJECTS { > psampSampRandOutOfNAvail, > psampSampRandOutOfNSamplingSize, > psampSampRandOutOfNPopulation > } > STATUS current > DESCRIPTION > "These objects are needed if random n-out-of-N sampling is > implemented." > ::=3D { psampGroups 4 } >=20 > psampGroupSampUniProb OBJECT-GROUP > OBJECTS { > psampSampUniProbAvail, > psampSampUniProbProbability > } >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 23] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > STATUS current > DESCRIPTION > "These objects are needed if uniform probabilistic sampling > is implemented." > ::=3D { psampGroups 5 } >=20 > psampGroupFiltPropMatch OBJECT-GROUP > OBJECTS { > psampFiltPropMatchAvail > } > STATUS current > DESCRIPTION > "These objects are needed if property match filtering is > implemented." > ::=3D { psampGroups 6 } >=20 > 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." > ::=3D { psampGroups 9 } "psampGroups 7". >=20 > END >=20 >=20 > 8. Security Considerations >=20 > 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. >=20 > 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 >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 24] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > 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: >=20 > 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.=20 Yes we should be consistent. >=20 > 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. >=20 > 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). >=20 > 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 >=20 > The MIB module in this document uses the following IANA-assigned > OBJECT IDENTIFIER values recorded in the SMI Numbers registry: >=20 > 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 } >=20 > Other than that this document does not impose any IANA > considerations. >=20 >=20 >=20 >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 25] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > 10. Acknowledgment >=20 > This document is a product of the PSAMP and IPFIX working groups. >=20 >=20 > 11. References >=20 > 11.1. Normative References >=20 > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. >=20 > [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. > Schoenwaelder, Ed., "Structure of Management Information > Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. >=20 > [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. > Schoenwaelder, Ed., "Textual Conventions for SMIv2", > STD 58, RFC 2579, April 1999. >=20 > [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, > "Conformance Statements for SMIv2", STD 58, RFC 2580, > April 1999. >=20 > [RFC2564] Kalbfleisch, C., Krupczak, C., Presuhn, R., and J. > Saperia, "Application Management MIB", RFC 2564, May 1999. >=20 > [RFC5101] Claise, B., "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic > Flow Information", RFC 5101, January 2008. >=20 > [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. > Carle, "Information Model for Packet Sampling Exports", > RFC 5477, March 2009. >=20 > [RFC5815] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, > "Definitions of Managed Objects for IP Flow Information > Export", RFC 5815, April 2010. >=20 > [IEEE.754.1985] > Institute of Electrical and Electronics Engineers, > "Standard for Binary Floating-Point Arithmetic", > IEEE Standard 754, August 1985. >=20 > 11.2. Informative References >=20 > [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, > "Introduction and Applicability Statements for Internet- >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 26] >=20 > Internet-Draft PSAMP MIB November 2010 >=20 >=20 > Standard Management Framework", RFC 3410, December 2002. >=20 > [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. >=20 > [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. > Raspall, "Sampling and Filtering Techniques for IP Packet > Selection", RFC 5475, March 2009. >=20 > [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling > (PSAMP) Protocol Specifications", RFC 5476, March 2009. >=20 >=20 > Authors' Addresses >=20 > Thomas Dietz (editor) > NEC Europe Ltd. > NEC Laboratories Europe > Kurfuersten-Anlage 36 > Heidelberg 69115 > DE >=20 > Phone: +49 6221 4342-128 > Email: dietz@neclab.eu >=20 >=20 > Benoit Claise > Cisco Systems, Inc. > De Kleetlaan 6a b1 > Degem 1831 > BE >=20 > Phone: +32 2 704 5622 > Email: bclaise@cisco.com >=20 >=20 > Juergen Quittek > NEC Europe Ltd. > NEC Laboratories Europe > Kurfuersten-Anlage 36 > Heidelberg 69115 > DE >=20 > Phone: +49 6221 4342-115 > Email: quittek@neclab.eu >=20 >=20 >=20 >=20 >=20 > Dietz, et al. draft-ietf-ipfix-psamp-mib-02.txt [Page 27] >=20 >=20 =20 ------_=_NextPart_001_01CB9A68.F0143065 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Benoit/ IPFIXers,

 

I did a quick review and am fine (with Paul’s changes) with the = document.

 

 

 

From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On = Behalf Of Benoit Claise (bclaise)
Sent: Wednesday, = November 24, 2010 2:39 AM
To: Paul Aitken = (paitken)
Cc: IETF IPFIX Working Group; dietz@neclab.eu; = Juergen Quittek
Subject: Re: [IPFIX] WG last call on = draft-ietf-ipfix-psamp-mib-02

 

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           &n= bsp;           &nb= sp;           &nbs= p;  T. Dietz, Ed.
> = Internet-Draft          = ;            =             &= nbsp;        NEC Europe = Ltd.
> Intended status: Standards = Track           &n= bsp;           &nb= sp;       B. Claise
> = Expires: May 12, = 2011           &nb= sp;           &nbs= p;        Cisco Systems, = Inc.
>        &nbs= p;            = ;            =             &= nbsp;           &n= bsp;     J. = Quittek
>        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ; NEC Europe = Ltd.
>        &nbs= p;            = ;            =             &= nbsp;           = November 8, 2010
>
> =
>         &n= bsp;  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.i= etf.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/lic= ense-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      &nbs= p;    [Page 1]
>
> = Internet-Draft          = ;        PSAMP = MIB           &nbs= p;      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      &nbs= p;    [Page 2]
>
> = Internet-Draft          = ;        PSAMP = MIB           &nbs= p;      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      &nbs= p;    [Page 3]
>
> = Internet-Draft          = ;        PSAMP = MIB           &nbs= p;      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      &nbs= p;    [Page 4]
>
> = Internet-Draft          = ;        PSAMP = MIB           &nbs= p;      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)
>     &nb= sp; +- = ipfixSelectorFunctions(1)
>     &= nbsp;    +- = 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      &nbs= p;    [Page 5]
>
> = Internet-Draft          = ;        PSAMP = MIB           &nbs= p;      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)
>   &nb= sp;   +-- psampSampCountBasedParamSetEntry(1) = [psampSampCountBasedIndex]
>     =      +-- = psampSampCountBasedIndex(1)
>     = ;     +-- = psampSampCountBasedInterval(2)
>    &n= bsp;     +-- = 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      &nbs= p;    [Page 6]
>
> = Internet-Draft          = ;        PSAMP = MIB           &nbs= p;      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)
>   &nbs= p;   +-- psampSampTimeBasedParamSetEntry(1) = [psampSampTimeBasedIndex]
>     &= nbsp;    +-- = psampSampTimeBasedIndex(1)
>     =      +-- = psampSampTimeBasedInterval(2)
>    &nb= sp;     +-- = 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
        &=
nbsp;          =
PsampSampRandOutOfNParamSetEntry
   &=
nbsp;   MAX-ACCESS  =
not-accessible
       =
STATUS      =
current
       =
DESCRIPTION
      &nbs=
p;    "This table lists configurations of random =
n-out-of-N
       =
;    sampling.  A parameter set describing a =
configuration
      &n=
bsp;    contains a two parameter only, the sampling size =
and =
the
        =
   parent =
population."
     &nbs=
p; ::=3D { psampSampRandOutOfN 3 =
}
 
However, there is no =
entry for "::=3D { psampSampRandOutOfN 2 }", so you have a =
good point.



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

This isn't = mentioned in the IANA section.

good point.



>
>    PsampFloat64 = ::=3D = TEXTUAL-CONVENTION
>      &n= bsp; STATUS       = current
>        = DESCRIPTION
>       &nb= sp;        "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 ::=3D { psampMIB 1 = }
>    psampConformance OBJECT IDENTIFIER = ::=3D { psampMIB 2 }
>
> =
>    = --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> = ;   -- Packet selection sampling methods group of = objects
>    = --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =
>    = --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> = ;   --* Method 1: Systematic count-based = Sampling
>    = --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =
>    -- Reference: RFC5475, Section 5.1, = RFC5476 Section 6.5.2.1 and
>    = --            = RFC5477, Section 8.2
>    = psampSampCountBased OBJECT = IDENTIFIER
>        = ::=3D { ipfixSelectorFunctions 2 }
> =
>    psampSampCountBasedAvail = OBJECT-TYPE
>        = SYNTAX      = TruthValue
>        = MAX-ACCESS  read-only
>
> =
>
> Dietz, et = al.       = draft-ietf-ipfix-psamp-mib-02.txt      &nbs= p;   [Page 10]
>
> = Internet-Draft          = ;        PSAMP = MIB           &nbs= p;      November 2010
> =
> =
>        = STATUS      = current
>        = DESCRIPTION
>       &nb= sp;    "This object indicates the availability of = systematic
>       &nbs= p;    count-based sampling at the managed = node.
> =
>         &n= bsp;  A Selector may be unavailable if it is implemented = but
>         = ;   currently disabled due to e.g., administrative reasons, = lack
>        &nbs= p;   of resources or = similar."
>       = DEFVAL { false = }
>        ::=3D { = psampSampCountBased 1 }
> =
>    -- Parameter Set Table = +++++++++++++++++++++++++++++++++++++++++++++
> =
>    psampSampCountBasedParamSetTable = OBJECT-TYPE
>        = SYNTAX      SEQUENCE = OF
>         =            = PsampSampCountBasedParamSetEntry
>    =     MAX-ACCESS  = not-accessible
>       = STATUS      = current
>        = DESCRIPTION
>       &nb= sp;    "This table lists configurations of = systematic = count-based
>       &nb= sp;    packet sampling.  A parameter set describing = a
>         &= nbsp;  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."


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

This description's indentation is = slightly = different.


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

Remove = "for".


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

This description's = indentation is slightly = different.


>      &n= bsp; = REFERENCE
>        = ;    "RFC5475, Section 5.2.1 and RFC5477, Section = 8.2"
>        = ::=3D { psampSampRandOutOfNParamSetEntry 3 }
> =
>    = --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> = ;   --* Method 4: Uniform probabilistic = Sampling
>    = --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =
>    -- Reference: RFC5475, Section = 5.2.2, RFC5476 Section 6.5.2.4 and
>    = --            = RFC5477, Section 8.2
>    psampSampUniProb = OBJECT IDENTIFIER ::=3D { ipfixSelectorFunctions 5 }
> =
>    psampSampUniProbAvail = OBJECT-TYPE
>        = SYNTAX      = TruthValue
>        = MAX-ACCESS  = read-only
>        = STATUS      = current
>        = DESCRIPTION
>       &nb= sp;    "This object indicates the availability of = random = uniform
>        &= nbsp;   probabilistic sampling at the managed = node.
> =
>         &n= bsp;  A Selector may be unavailable if it is implemented = but
>         = ;   currently disabled due to e.g., administrative reasons, = lack
>        &nbs= p;   of resources or = similar."
>       = DEFVAL { false = }
>        ::=3D { = 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      &nbs= p;   [Page 16]
>
> = Internet-Draft          = ;        PSAMP = MIB           &nbs= p;      November 2010
> =
> =
>         &n= bsp;          = PsampSampUniProbParamSetEntry
>    &nb= sp;   MAX-ACCESS  = not-accessible
>       = STATUS      = current
>        = DESCRIPTION
>       &nb= sp;    "This table lists configurations of random = probabilistic
>       &= nbsp;    sampling.  A parameter set describing a = configuration
>       &= nbsp;    contains a single parameter only: the sampling = probability."
>      &n= bsp; ::=3D { psampSampUniProb 3 }
> =
>    psampSampUniProbParamSetEntry = OBJECT-TYPE
>        = SYNTAX      = PsampSampUniProbParamSetEntry
>    &nb= sp;   MAX-ACCESS  = not-accessible
>       = STATUS      = current
>        = DESCRIPTION
>       &nb= sp;    "Defines an entry in the = psampSampUniProbParamSetTable."
>   &n= bsp;    INDEX { psampSampUniProbIndex = }
>        ::=3D { = psampSampUniProbParamSetTable 1 }
> =
>    PsampSampUniProbParamSetEntry = ::=3D
>        = SEQUENCE = {
>         &= nbsp;  psampSampUniProbIndex       = Integer32,
>       &nbs= p;    psampSampUniProbProbability = PsampFloat64
>        = }
>
>    = psampSampUniProbIndex = OBJECT-TYPE
>        = SYNTAX      Integer32 = (1..2147483647)
>       = ; MAX-ACCESS  = not-accessible
>       = STATUS      = current
>        = DESCRIPTION
>       &nb= sp;   "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
>         &= nbsp;  object ipfixSelectionProcessSelectorFunctionentries = of
>         =    the ipfixSelectionProcessTable in the IPFIX-MIB as = reference
>        = ;    to this parameter = set."
>        = ::=3D { psampSampUniProbParamSetEntry 1 }
> =
>    psampSampUniProbProbability = OBJECT-TYPE
>        = SYNTAX      = PsampFloat64
>        = MAX-ACCESS  = read-only
>        = STATUS      = current
>        = DESCRIPTION
>       &nb= sp;    "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
>        &nb= sp;   no packet was sampled since the probability is 0. A = value
>        &nb= sp;   of 1 means all packets were sampled since = the
>         = ;   probability is = 1."
>        = REFERENCE
>
>
> =
> Dietz, et al.       = draft-ietf-ipfix-psamp-mib-02.txt      &nbs= p;   [Page 17]
>
> = Internet-Draft          = ;        PSAMP = MIB           &nbs= p;      November 2010
> =
> =
>         &n= bsp;  "RFC5475, Section 5.2.2.1 and RFC5477, Section = 8.2"
>        = ::=3D { psampSampUniProbParamSetEntry 2 }
> =
>    = --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> = ;   -- Packet selection filtering methods group of = objects
>    = --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =
>    = --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> = ;   --* Method 5: Property Match = filtering
>    = --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =
>    -- Reserves Method 5 (see RFC5475, = Section 6.1, RFC5476
>    -- Section = 6.5.2.5 and RFC5477)
>    = psampFiltPropMatch OBJECT = IDENTIFIER
>        = ::=3D { ipfixSelectorFunctions 6 }
> =
>    psampFiltPropMatchAvail = OBJECT-TYPE
>        = SYNTAX      = TruthValue
>        = MAX-ACCESS  = read-only
>        = STATUS      = current
>        = DESCRIPTION
>       &nb= sp;    "This object indicates the availability of = property = match
>        &nb= sp;   filtering at the managed node.
> =
>         &n= bsp;  A Selector may be unavailable if it is implemented = but
>         = ;   currently disabled due to e.g., administrative reasons, = lack
>        &nbs= p;   of resources or = similar."
>       = DEFVAL { false = }
>        ::=3D { = psampFiltPropMatch 1 }
> =
>    = --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> = ;   --* Method 1: Hash filtering

Typo: = it's method 6.


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

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


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


> &n= bsp;          = psampSampCountBased    { ipfixSelectorFunctions 2 = }
>         &= nbsp;  psampSampTimeBased     { = ipfixSelectorFunctions 3 = }
>         &= nbsp;  psampSampRandOutOfN    { = ipfixSelectorFunctions 4 = }
>         &= nbsp;  psampSampUniProb       { = ipfixSelectorFunctions 5 = }
>         &= nbsp;  psampFiltPropMatch     { = ipfixSelectorFunctions 6 = }
>         &= nbsp;  = psampFiltHash          { = ipfixSelectorFunctions 7 }
> =
>    Other than that this document does = not impose any IANA
>    = considerations.
>
>
> =
>
>
>
> = Dietz, et al.       = draft-ietf-ipfix-psamp-mib-02.txt      &nbs= p;   [Page 25]
>
> = Internet-Draft          = ;        PSAMP = MIB           &nbs= p;      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
>       &nb= sp;       Version 2 (SMIv2)", STD 58, = RFC 2578, April 1999.
> =
>    [RFC2579]  McCloghrie, K., Ed., = Perkins, D., Ed., and = J.
>         =       Schoenwaelder, Ed., "Textual = Conventions for = SMIv2",
>       &n= bsp;       STD 58, RFC 2579, April = 1999.
>
>    = [RFC2580]  McCloghrie, K., Perkins, D., and J. = Schoenwaelder,
>       =         "Conformance Statements = for SMIv2", STD 58, RFC = 2580,
>        &nb= sp;      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
>       &nb= sp;       Export (IPFIX) Protocol for the = Exchange of IP = Traffic
>        &= nbsp;      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,
>        &n= bsp;      "Definitions of Managed Objects = for IP Flow = Information
>       &nb= sp;       Export", RFC 5815, April = 2010.
>
>    = [IEEE.754.1985]
>       = ;        Institute of Electrical and = Electronics = Engineers,
>       &nbs= p;       "Standard for Binary = Floating-Point = Arithmetic",
>      &nb= sp;        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      &nbs= p;   [Page 26]
>
> = Internet-Draft          = ;        PSAMP = MIB           &nbs= p;      November 2010
> =
> =
>         &n= bsp;     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
>        &n= bsp;      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
>        &n= bsp;      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      &nbs= p;   [Page 27]
>
> =

 

------_=_NextPart_001_01CB9A68.F0143065-- From lhotka@cesnet.cz Mon Dec 13 07:37: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 70A723A6CB5; Mon, 13 Dec 2010 07:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.057, 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 Pgs-fBZuRvou; Mon, 13 Dec 2010 07:37:20 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 47A3D3A6DD2; Mon, 13 Dec 2010 07:37:19 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e] (unknown [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e]) by office2.cesnet.cz (Postfix) with ESMTPSA id DC5472CDE059; Mon, 13 Dec 2010 16:38:56 +0100 (CET) From: Ladislav Lhotka To: ipfix@ietf.org Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 13 Dec 2010 16:38:56 +0100 Message-ID: <1292254737.8763.57.camel@behold> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Dec 2010 09:11:12 -0800 Cc: YANG Doctors Subject: [IPFIX] review of YANG module ietf-ipfix-psamp@2010-10-25 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, 13 Dec 2010 15:37:21 -0000 Hi, this is my review of the ietf-ipfix-psamp@2010-10-25 module: *** General comments This module is probably the largest (public) data modelling effort that has been done with YANG so far. It is therefore also important as a serious test case for YANG itself. The module demonstrates that object-based data modelling can be done with the current YANG syntax in an elegant and extensible way. I like the approach of mapping UML diagrams to YANG structures where object properties are represented by groupings, aggregated components as subordinate nodes and unidirectional associations with leafrefs. The module closely obeys all the recommendations of draft-ietf-netmod-yang-usage-11. My main concern is the size of the module. I believe that splitting the data model into smaller coherent modules makes it more understandable and manageable - also in terms of the standardisation process. It seems that the present module could relatively easily be divided into two modules, one describing the collector subsystem and the other dealing with the remaining functionality. As a matter of fact, flow collectors are in most cases implemented in a separate device, so their configuration won't be mixed with configurations of the other parts. This change would also remove one level of containment in the schema, at a very reasonable price of adding one more namespace. The module could certainly make a good use of a generic model of network interfaces. *** Specific comments - Some description statements only retell in prose what is succinctly expressed by other statements. Such description statements should be removed. For example the type description in typedef ieIdType { type uint16 { range "1..32767" { description "Valid range of Information Element identifiers."; reference "RFC5102, Section 4."; } } description "Type for Information Element identifiers."; } - Several leafs with string type could be further restricted: + The length of "ifName" is restricted to 255 characters. + Distinguished names of certification authorities and subjects also have a structure and a set of reserved characters - of course, a DN datatype would normally be imported from an external module, but it doesn't exist yet. + I am not sure about "ieName" - is it a completely arbitrary string? - The description of "ieEnterpriseNumber" leafs says: "If omitted or zero, the Information Element is registered in the IANA registry of IPFIX Information Elements." Why not define a default value of "0" here (perhaps in a special typedef)? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From biermana@Brocade.com Mon Dec 13 08:44: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 EBBBD3A6DDB; Mon, 13 Dec 2010 08:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=0.6] 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 ggWnKEATiJxR; Mon, 13 Dec 2010 08:44:38 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id E73113A6CAD; Mon, 13 Dec 2010 08:44:37 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id oBDGkDuh029220; Mon, 13 Dec 2010 08:46:13 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id t5pnr00r5-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Dec 2010 08:46:13 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 13 Dec 2010 08:46:59 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::6452:4b5c:f595:4894]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Mon, 13 Dec 2010 08:46:11 -0800 From: Andy Bierman To: Ladislav Lhotka , "ipfix@ietf.org" Date: Mon, 13 Dec 2010 08:46:10 -0800 Thread-Topic: [yang-doctors] review of YANG module ietf-ipfix-psamp@2010-10-25 Thread-Index: Acua299d8RqdhyO+RlGceNh8yac9dAACN02w Message-ID: References: <1292254737.8763.57.camel@behold> In-Reply-To: <1292254737.8763.57.camel@behold> 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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-12-13_07:2010-12-13, 2010-12-13, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1010190000 definitions=main-1012130107 X-Mailman-Approved-At: Mon, 13 Dec 2010 09:11:14 -0800 Cc: YANG Doctors Subject: Re: [IPFIX] [yang-doctors] review of YANG module ietf-ipfix-psamp@2010-10-25 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, 13 Dec 2010 16:44:39 -0000 Hi, I do not agree with removing description-stmts. They are not required for range-stmt, but they are for typedef=3Dstmt. Strings intended for humans to read are important. They may get displayed in help text and translated to other languages. Andy -----Original Message----- From: yang-doctors-bounces@ietf.org [mailto:yang-doctors-bounces@ietf.org] = On Behalf Of Ladislav Lhotka Sent: Monday, December 13, 2010 7:39 AM To: ipfix@ietf.org Cc: YANG Doctors Subject: [yang-doctors] review of YANG module ietf-ipfix-psamp@2010-10-25 Hi, this is my review of the ietf-ipfix-psamp@2010-10-25 module: *** General comments This module is probably the largest (public) data modelling effort that has been done with YANG so far. It is therefore also important as a serious test case for YANG itself. The module demonstrates that object-based data modelling can be done with the current YANG syntax in an elegant and extensible way. I like the approach of mapping UML diagrams to YANG structures where object properties are represented by groupings, aggregated components as subordinate nodes and unidirectional associations with leafrefs. The module closely obeys all the recommendations of draft-ietf-netmod-yang-usage-11. My main concern is the size of the module. I believe that splitting the data model into smaller coherent modules makes it more understandable and manageable - also in terms of the standardisation process. It seems that the present module could relatively easily be divided into two modules, one describing the collector subsystem and the other dealing with the remaining functionality. As a matter of fact, flow collectors are in most cases implemented in a separate device, so their configuration won't be mixed with configurations of the other parts. This change would also remove one level of containment in the schema, at a very reasonable price of adding one more namespace. The module could certainly make a good use of a generic model of network interfaces. *** Specific comments - Some description statements only retell in prose what is succinctly expressed by other statements. Such description statements should be removed. For example the type description in typedef ieIdType { type uint16 { range "1..32767" { description "Valid range of Information Element identifiers."; reference "RFC5102, Section 4."; } } description "Type for Information Element identifiers."; } - Several leafs with string type could be further restricted: + The length of "ifName" is restricted to 255 characters. + Distinguished names of certification authorities and subjects also have a structure and a set of reserved characters - of course, a DN datatype would normally be imported from an external module, but it doesn't exist yet. + I am not sure about "ieName" - is it a completely arbitrary string? - The description of "ieEnterpriseNumber" leafs says: "If omitted or zero, the Information Element is registered in the IANA registry of IPFIX Information Elements." Why not define a default value of "0" here (perhaps in a special typedef)? Lada --=20 Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C _______________________________________________ yang-doctors mailing list yang-doctors@ietf.org https://www.ietf.org/mailman/listinfo/yang-doctors From jloiacon@csc.com Mon Dec 13 09:23:40 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 726FC3A6EB4; Mon, 13 Dec 2010 09:23:40 -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 bkQa27RhPvOK; Mon, 13 Dec 2010 09:23:39 -0800 (PST) Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by core3.amsl.com (Postfix) with ESMTP id 4B7583A6EA8; Mon, 13 Dec 2010 09:23:38 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jloiacon@csc.com X-Msg-Ref: server-4.tower-164.messagelabs.com!1292261106!34697641!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 13222 invoked from network); 13 Dec 2010 17:25:08 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-4.tower-164.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Dec 2010 17:25:08 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id oBDHP3RM025039; Mon, 13 Dec 2010 12:25:03 -0500 In-Reply-To: <4CF51F82.5090508@lpsc.in2p3.fr> 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> <4CF51F82.5090508@lpsc.in2p3.fr> X-KeepSent: C74E78D4:F70AE5C3-852577F8:005F786A; type=4; name=$KeepSent To: ipfix@ietf.org, ipfix-bounces@ietf.org X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 Message-ID: From: Joe Loiacono Date: Mon, 13 Dec 2010 12:25:00 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.1FP1 HF440|June 18, 2010) at 12/13/2010 12:24:42 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [IPFIX] IPFIX Reference software 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, 13 Dec 2010 17:23:40 -0000 Just curious. Is there a set of reference code for IPFIX? i.e., capture, reporting, etc. C++? Thanks, Joe Loiacono From dressler@informatik.uni-erlangen.de Mon Dec 13 09:31:20 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 8709C28C0E4 for ; Mon, 13 Dec 2010 09:31:20 -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 HjGBUYGny7aY for ; Mon, 13 Dec 2010 09:31:18 -0800 (PST) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id B5BF728C0DF for ; Mon, 13 Dec 2010 09:31:18 -0800 (PST) Received: from faui7as (faui7as.informatik.uni-erlangen.de [131.188.37.230]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id C06E04751; Mon, 13 Dec 2010 18:32:53 +0100 (MET) Received: from [208.50.228.87] (unknown [208.50.228.87]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by faui7as (Postfix) with ESMTPSA id 5799F8000D; Mon, 13 Dec 2010 18:32:53 +0100 (CET) Message-ID: <4D0658C2.8040805@informatik.uni-erlangen.de> Date: Mon, 13 Dec 2010 18:32:50 +0100 From: Falko Dressler User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ipfix@ietf.org 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> <4CF51F82.5090508@lpsc.in2p3.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] IPFIX Reference software 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, 13 Dec 2010 17:31:20 -0000 Dear Joe, you might want to check . Cheers, Falko On 13.12.2010 18:25, Joe Loiacono wrote: > Just curious. Is there a set of reference code for IPFIX? i.e., capture, > reporting, etc. > > C++? > > Thanks, > > Joe Loiacono > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > -- PD Dr.-Ing. habil. Falko Dressler Computer Networks and Communication Systems University of Erlangen, Germany Phone: +49 9131 85-27914 / Fax: +49 9131 85-27409 mailto:dressler@informatik.uni-erlangen.de http://www7.informatik.uni-erlangen.de/~dressler/ From lhotka@cesnet.cz Mon Dec 13 10:28:15 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 273CC28C0DF; Mon, 13 Dec 2010 10:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, 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 JXfijgQNDS38; Mon, 13 Dec 2010 10:28:14 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id A6C683A6EB9; Mon, 13 Dec 2010 10:28:13 -0800 (PST) Received: from stardust-w.lhotkovi.cz (unknown [IPv6:2001:718:1a02:7:5ab0:35ff:fe73:8f1d]) by office2.cesnet.cz (Postfix) with ESMTPSA id 67EBA2CDE05C; Mon, 13 Dec 2010 19:29:50 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: Date: Mon, 13 Dec 2010 19:29:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1292254737.8763.57.camel@behold> To: Andy Bierman X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Mon, 13 Dec 2010 11:27:27 -0800 Cc: YANG Doctors , "ipfix@ietf.org" Subject: Re: [IPFIX] [yang-doctors] review of YANG module ietf-ipfix-psamp@2010-10-25 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, 13 Dec 2010 18:28:15 -0000 On Dec 13, 2010, at 5:46 PM, Andy Bierman wrote: > Hi, >=20 > I do not agree with removing description-stmts. > They are not required for range-stmt, but they are for typedef=3Dstmt. Yes, I meant only the description inside the 'type' statement, not the = one for 'typedef'. Lada > Strings intended for humans to read are important. > They may get displayed in help text and translated to other languages. >=20 >=20 > Andy >=20 >=20 > -----Original Message----- > From: yang-doctors-bounces@ietf.org = [mailto:yang-doctors-bounces@ietf.org] On Behalf Of Ladislav Lhotka > Sent: Monday, December 13, 2010 7:39 AM > To: ipfix@ietf.org > Cc: YANG Doctors > Subject: [yang-doctors] review of YANG module = ietf-ipfix-psamp@2010-10-25 >=20 > Hi, >=20 > this is my review of the ietf-ipfix-psamp@2010-10-25 module: >=20 > *** General comments >=20 > This module is probably the largest (public) data modelling effort > that has been done with YANG so far. It is therefore also important as > a serious test case for YANG itself. >=20 > The module demonstrates that object-based data modelling can be done > with the current YANG syntax in an elegant and extensible way. I like > the approach of mapping UML diagrams to YANG structures where object > properties are represented by groupings, aggregated components as > subordinate nodes and unidirectional associations with leafrefs. >=20 > The module closely obeys all the recommendations of > draft-ietf-netmod-yang-usage-11. >=20 > My main concern is the size of the module. I believe that splitting = the > data model into smaller coherent modules makes it more understandable > and manageable - also in terms of the standardisation process. It > seems that the present module could relatively easily be divided into > two modules, one describing the collector subsystem and the other > dealing with the remaining functionality. As a matter of fact, flow > collectors are in most cases implemented in a separate device, so > their configuration won't be mixed with configurations of the other > parts. This change would also remove one level of containment in the > schema, at a very reasonable price of adding one more namespace. >=20 > The module could certainly make a good use of a generic model of > network interfaces. >=20 > *** Specific comments >=20 > - Some description statements only retell in prose what is succinctly > expressed by other statements. Such description statements should > be removed. For example the type description in > typedef ieIdType { > type uint16 { > range "1..32767" { > description "Valid range of Information Element > identifiers."; > reference "RFC5102, Section 4."; > } > } > description "Type for Information Element identifiers."; > } >=20 > - Several leafs with string type could be further restricted: > + The length of "ifName" is restricted to 255 characters. > + Distinguished names of certification authorities and subjects also > have a structure and a set of reserved characters - of course, a DN > datatype would normally be imported from an external module, but > it doesn't exist yet. > + I am not sure about "ieName" - is it a completely arbitrary string? >=20 > - The description of "ieEnterpriseNumber" leafs says: "If omitted or > zero, the Information Element is registered in the IANA registry of > IPFIX Information Elements." Why not define a default value of "0" > here (perhaps in a special typedef)? >=20 > Lada >=20 > --=20 > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C >=20 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From n.brownlee@auckland.ac.nz Mon Dec 13 15:47:01 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 8F8F73A6E13 for ; Mon, 13 Dec 2010 15:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.549 X-Spam-Level: X-Spam-Status: No, score=-104.549 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, GB_I_LETTER=-2, 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 hOS-kZNmCuM6 for ; Mon, 13 Dec 2010 15:47:00 -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 267BA3A6DFA for ; Mon, 13 Dec 2010 15:46:58 -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=1292284119; x=1323820119; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4D06B0C7.4070901@auckland.ac.nz>|Date:=20 Tue,=2014=20Dec=202010=2012:48:23=20+1300|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20draft-ietf-ipfix-flow-selection-tech@tools.i etf.org,=20=0D=0A=20IPFIX=20Working=20Group=20|Subject:=20Shepherd=20review=20of=20=20draft-ietf-i pfix-flow-selection-tech|Content-Transfer-Encoding:=207bi t; bh=V4PkzllCIaPJm4JLYsVJL0tKfXb6nFwQUfdmXSlE5wk=; b=Ld61tXZGU2p+WKcXxngMWEFCLJZBj4dLJ118KstIlYKPoDK9578OcbAN tuRlutARGdXQnFopzhC2s+BrMRGfgPDTOEj2QFBC0dvBmX0kTF6TGQ/dY ZbRRERerTsgcXYFzKBGi+c3VHwaYBarS3jyCwBB/6yhPyfgqXQKoNzpuB k=; X-IronPort-AV: E=Sophos;i="4.59,338,1288522800"; d="scan'208";a="39175257" 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; 14 Dec 2010 12:48:25 +1300 Message-ID: <4D06B0C7.4070901@auckland.ac.nz> Date: Tue, 14 Dec 2010 12:48:23 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org, IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Shepherd review of draft-ietf-ipfix-flow-selection-tech 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, 13 Dec 2010 23:47:01 -0000 Hi Lorenzo et al: As part of writing a shepherd document I have to read your draft carefully, and check it for ID-nits. I've done that, and I find quite a few things that need to be fixed, as follows: s7, p15: List of new IEs 5102 clearly says that IE names start with a lower-case letter. Also, none of the existing IEs use an underscore character. How about using fsMeterUnmeasPacketCount, as per 5102? s7, p14 You say "Some elements have been associated with a pair of timestamps, which are referred to as Tfirst and Tlast (instead of element_nameTfirst, element_nameTlast). Does that mean that you both the TFirst and Tlast timestamps are also needed as IEs? Or are they something that will only be used inside a meter or mediator? You need to explain this here! s7.1.1, p15 Refers to TsFirst and TsLast - you should change Tfirst and Tlast above (I think TsFirst is easier to read). s7.2.2 Why is ..PacketInDropped.. defined in terms of its two timestamps, but ..ByteInDropped.. is not? Similarly for other IEs in 7.2.x sections. s9, p22: remove [RFC 2051] (as above) s9.1, p22: In the table, don't use ID, that suggests its an ID for an Informations Element. I think you mean Value. Running ID-nits, using the [Nits] button at the top os http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-03 You should run this, and fix the little things it finds. In particular, I see that there's no Security Considerations section. Every RFC has to have such a section! You need to add one, pointing out what possible security weaknesses could be introduced by using flow selection (or explaining that there aren't any obvious ones). Most of these are quite trivial, so they won't take much fixing. The ones that do need some real work are to explain how TsFirst/ TsFirst are intended to be used in the FlowSelect Info Model, and to add a Security Considerations section. I look forward to seeing your next version. 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 mehmet.ersue@nsn.com Tue Dec 14 05:02: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 9BEEA28B797; Tue, 14 Dec 2010 05:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.422 X-Spam-Level: X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 S4V7os1CcFF1; Tue, 14 Dec 2010 05:02:53 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 9E5B528C0DE; Tue, 14 Dec 2010 05:02:52 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id oBED4UtI031977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Dec 2010 14:04:30 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id oBED4S6h017713; Tue, 14 Dec 2010 14:04:30 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Dec 2010 14:04:29 +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: Tue, 14 Dec 2010 14:04:28 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64015D3AFE@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of ietf-ipfix-psamp@2010-10-25.yang Thread-Index: Acubj3Bp92dAa+3xR7GVylV98Gp+4Q== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 14 Dec 2010 13:04:29.0927 (UTC) FILETIME=[71A21F70:01CB9B8F] X-Mailman-Approved-At: Tue, 14 Dec 2010 11:53:14 -0800 Cc: "Linowski, Bernd \(EXT-Other - DE\)" , ipfix@ietf.org Subject: [IPFIX] Review of ietf-ipfix-psamp@2010-10-25.yang 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, 14 Dec 2010 13:02:54 -0000 Hi All, below are a few review comments on the IPFIX YANG module in draft-ietf-ipfix-configuration-model-08 from Bernd and myself. In general I agree with Lada that the model is too long and should be probably devided into two parts covering the collector subsystem and the rest functionality. The grouping "selectorParameters" is very long (spans several pages) and therefore is hard to read and understand. Main reason is that it contains a huge choice statement ("Method") that hosts a container for every type of selector, each containing several leafs.=20 Perhaps it would be better to move the contents of each of those containers in an own grouping which are then used inside the choice statement. The applicability of certain cacheMode identities is feature depended. For example: identity timeout { base "cacheMode"; description "Flow expiration after active and inactive timeout; generation of Flow Records. This identity MUST NOT be referred to unless the feature cacheModeTimeout is supported by the Monitoring Device."; } In effect, the constraint is described only in the description but not enforced by the way the module is defined. The current model saves some space though it would be better to model Constraint-based. I think it would be better to introduce a Container per cachMode and protect it with if-feature (see model excerpt below with some skipped parts). The Container could be then put in a Choice statement and groupings could be used to avoid repetitions (not in the example). container timeout { if-feature cacheModeTimeout ; leaf maxFlows { type uint32; units flows; ... } leaf activeTimeout { type uint32; ... } leaf inactiveTimeout { type uint32; ... } ... } conatiner natural { if-feature cacheModeNatural ; leaf maxFlows { type uint32; units flows; ... } leaf activeTimeout { type uint32; ... } leaf inactiveTimeout { type uint32; ... } ... } conatiner permanent { if-feature cacheModePermanent; leaf maxFlows { type uint32; units flows; ... } leaf exportInterval { when "../cacheMode =3D 'ipfix:permanent'" { description "This parameter is only available for Cache Mode 'permanent'."; } ... =20 } Hope this helps. Cheers, Mehmet From muenz@net.in.tum.de Wed Dec 15 12:52: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 6699128B23E for ; Wed, 15 Dec 2010 12:52:05 -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=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, 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 IjXGzfMNZgT2 for ; Wed, 15 Dec 2010 12:52:03 -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 996BF3A6EBC for ; Wed, 15 Dec 2010 12:52:03 -0800 (PST) Received: by mail.net.in.tum.de (Postfix, from userid 81) id A81B8208BD8A; Wed, 15 Dec 2010 21:53:45 +0100 (CET) To: X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 15 Dec 2010 21:53:45 +0100 From: Gerhard Muenz In-Reply-To: References: Message-ID: <12259ed080c17fc5ca54eb5443d830db@net.in.tum.de> X-Sender: muenz@net.in.tum.de User-Agent: Roundcube Webmail/RCMAIL_VERSION 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, 15 Dec 2010 20:52:05 -0000 Dear all, Please find below some comments regarding the PSAMP MIB document. (I will not mention types already reported by Paul) Regards, Gerhard > 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]. "hashing" should be replaced by "filtering"! You do not use capitalized first letters as usual. Why? I think, it should be "Sampling and Filtering". BTW, you do use capitalized first letters in the spec of the MIB module as well. That's not consistent. ... > 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. Capitalize? "Selection Process" "Selector" etc. ... > Object ipfixSelectorFunctions in the IPFIX SELECTOR MIB module > serves > as home for objects that describe instances of packet selector > functions. The IPFIX SELECTOR MIB is a very small module that is > also defined in [RFC5815]. Objects under ipfixSelectorFunctions > are > 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: This last sentence is only true for the SELECTOR MIB module as it is today. There may be extensions after PSAMP-MIB. I propose to rewrite the paragraph a little bit, making clear that IPFIX SELECTOR MIB is defined in RFC5815, and that this document extends it according to the procedure defined in RFC5815. > > 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]. It's not a figure, it's a table. I propose to show a copy of the table. There are already many references to other documents making it difficult to read this draft. > > 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. > > 6.1. Textual Conventions > > The MIB module defines one textual conventions that defines a data Which MIB module are you talking about here? > 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 > [RFC2578] but are needed to define objects in this MIB module that > conform to the Information Elements defined for those objects in > [RFC5477]. ... > 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. The last sentence should be removed. The parameter names are quite different. > Parameters are psampSampRandOutOfNSamplingSize and > psampSampRandOutOfNPopulation: > > psampSampRandOutOfN(4) > +-- psampSampRandOutOfNAvail(1) > +-- psampSampRandOutOfNParamSetTable(3) > +-- psampSampRandOutOfNParamSetEntry(1) > [psampSampRandOutOfNIndex] > +-- psampSampRandOutOfNIndex(1) > +-- psampSampRandOutOfNSamplingSize(2) > +-- psampSampRandOutOfNPopulation(3) The naming is not consistent. In RFC5477, its "samplingSize" and "samplingPopulation". So, with your logic of omitting the prefix "sampling" in all cases, it should be: psampSampRandOutOfNSize and psampSampRandOutOfNPopulation. ... > 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: > > psampFiltPropMatch(6) > +-- psampFiltPropMatchAvail(1) In IPFIX-CONFIG, we still have: +--------------------------+ | FilterMatch | +--------------------------+ | ieId/ieName | | ieEnterpriseNumber[0..1] | | value | +--------------------------+ Shall this filter be removed as well? ... > 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 > capabilities, configuration and statistics. I think, you should explain the relationship to IPFIX SELECTOR MIB in the description! > > 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 ... > 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 > object ipfixSelectionProcessSelectorFunctionentries of There is a space missing! "ipfixSelectionProcessSelectorFunction entries" This error is repeated multiple times below! > the ipfixSelectionProcessTable in the IPFIX-MIB as > reference > to this parameter set." > ::= { psampSampCountBasedParamSetEntry 1 } ... > 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 copy-past error! remove "a" and "only", add plural "s" "contains two parameters, the sampling ..." > parent population." > ::= { psampSampRandOutOfN 3 } ... > 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 "was" -> "is" > of 1 means all packets were sampled since the "were" -> "are" > probability is 1." ... > -- 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." missing plural "s" : "parameters" From trammell@tik.ee.ethz.ch Thu Dec 16 03:49: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 0BBD43A70E2 for ; Thu, 16 Dec 2010 03:49:30 -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 ytXpGdusa+xE for ; Thu, 16 Dec 2010 03:49:29 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 214343A70DE for ; Thu, 16 Dec 2010 03:49:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 622F0D933F; Thu, 16 Dec 2010 12:51:12 +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 9cj48G62ftLb; Thu, 16 Dec 2010 12:51:11 +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 D74B9D9336; Thu, 16 Dec 2010 12:51:11 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4CBBA607.7080404@auckland.ac.nz> Date: Thu, 16 Dec 2010 12:51:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CBBA607.7080404@auckland.ac.nz> To: Nevil Brownlee X-Mailer: Apple Mail (2.1082) Cc: IPFIX Working Group Subject: Re: [IPFIX] Two WGLCs starting now 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, 16 Dec 2010 11:49:30 -0000 Hi, Nevil, all, I have reviewed the latest configuration model draft (-08, including = WGLC comments), exclusive of the YANG code, which I'm not presently = enough of a YANG expert to have an opinion of. The document in its = present form is in my opinion ready for IESG submission. Best regards, Brian On Oct 18, 2010, at 3:42 AM, Nevil Brownlee wrote: >=20 > Hi all: >=20 > We have two drafts waiting for Working Group Last Call. > Their WGLCs start now, and will finish on 3 November (the > Wednesday before the Beijing IETF). >=20 > The drafts are: > 1. draft-ietf-ipfix-structured-data-03.txt > Second WGLC for this draft, the first was back in July > for the -01 version. There's been a *lot* of discussion > on the mailing list since!) > 2. draft-ietf-ipfix-configuration-model-07.txt > We were waiting for the YANG RFCs to be published for this one. >=20 > Cheers, Nevil (IPFIX co-chair) >=20 > --=20 > --------------------------------------------------------------------- > 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 From dromasca@avaya.com Thu Dec 16 09:41: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 8EEAE3A6954 for ; Thu, 16 Dec 2010 09:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 qHWn5q84Rssl for ; Thu, 16 Dec 2010 09:41:29 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 843DF3A696A for ; Thu, 16 Dec 2010 09:41:29 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADfeCU3GmAcF/2dsb2JhbACkOHOpBwKZQIVKBI4u X-IronPort-AV: E=Sophos;i="4.59,356,1288584000"; d="scan'208";a="223581778" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 16 Dec 2010 12:43:12 -0500 X-IronPort-AV: E=Sophos;i="4.59,356,1288584000"; d="scan'208";a="556695585" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 16 Dec 2010 12:43:12 -0500 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: Thu, 16 Dec 2010 18:42:53 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipfix-mediators-framework-09 approved as Informational RFC Thread-Index: AcudSKqXbOchLlSZRmWb9A/YHtbB3A== From: "Romascanu, Dan (Dan)" To: "IPFIX Working Group" Subject: [IPFIX] draft-ietf-ipfix-mediators-framework-09 approved as 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: Thu, 16 Dec 2010 17:41:30 -0000 The IESG approved in the telechat today draft-ietf-ipfix-mediators-framework-09 as Informational RFC. Thanks to everybody who contributed, and especially with Benoit who worked on-line until the last minute to propose solutions to all the concerns expressed by the IESG.=20 Regards, Dan From muenz@net.in.tum.de Sun Dec 19 02:47:41 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 0822C3A6841; Sun, 19 Dec 2010 02:47:41 -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 7hQ0kcoQmjAx; Sun, 19 Dec 2010 02:47:39 -0800 (PST) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) by core3.amsl.com (Postfix) with ESMTP id 957263A683F; Sun, 19 Dec 2010 02:47:39 -0800 (PST) Received: from [192.168.1.151] (ppp-88-217-7-31.dynamic.mnet-online.de [88.217.7.31]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 42F9F21AAFCE; Sun, 19 Dec 2010 11:49:26 +0100 (CET) Message-ID: <4D0DE31F.1080308@net.in.tum.de> Date: Sun, 19 Dec 2010 11:49:03 +0100 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ladislav Lhotka References: <1292254737.8763.57.camel@behold> In-Reply-To: <1292254737.8763.57.camel@behold> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: YANG Doctors , ipfix@ietf.org Subject: Re: [IPFIX] review of YANG module ietf-ipfix-psamp@2010-10-25 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, 19 Dec 2010 10:47:41 -0000 Dear Lada, Thanks a lot for your valuable comments. Please find my replies inline. Gerhard On 13.12.2010 16:38, Ladislav Lhotka wrote: > Hi, > > this is my review of the ietf-ipfix-psamp@2010-10-25 module: > > *** General comments > > This module is probably the largest (public) data modelling effort > that has been done with YANG so far. It is therefore also important as > a serious test case for YANG itself. > > The module demonstrates that object-based data modelling can be done > with the current YANG syntax in an elegant and extensible way. I like > the approach of mapping UML diagrams to YANG structures where object > properties are represented by groupings, aggregated components as > subordinate nodes and unidirectional associations with leafrefs. > > The module closely obeys all the recommendations of > draft-ietf-netmod-yang-usage-11. > > My main concern is the size of the module. I believe that splitting the > data model into smaller coherent modules makes it more understandable > and manageable - also in terms of the standardisation process. It > seems that the present module could relatively easily be divided into > two modules, one describing the collector subsystem and the other > dealing with the remaining functionality. As a matter of fact, flow > collectors are in most cases implemented in a separate device, so > their configuration won't be mixed with configurations of the other > parts. This change would also remove one level of containment in the > schema, at a very reasonable price of adding one more namespace. With the upcoming IPFIX mediators, we will have devices implementing Collecting Processes, Intermediate Processes, and Exporting Processes. Therefore, I think that keeping the configuration data of all IPFIX processes in one module makes sense. > The module could certainly make a good use of a generic model of > network interfaces. > > *** Specific comments > > - Some description statements only retell in prose what is succinctly > expressed by other statements. Such description statements should > be removed. For example the type description in > typedef ieIdType { > type uint16 { > range "1..32767" { > description "Valid range of Information Element > identifiers."; > reference "RFC5102, Section 4."; > } > } > description "Type for Information Element identifiers."; > } Please note that this is not a description for type but for range! I want to motivate the range restriction for ieIdType and provide a reference to the corresponding section in RFC5102. > - Several leafs with string type could be further restricted: > + The length of "ifName" is restricted to 255 characters. > + Distinguished names of certification authorities and subjects also > have a structure and a set of reserved characters - of course, a DN > datatype would normally be imported from an external module, but > it doesn't exist yet. Is there somebody who feels capable of providing a regular expression for DN that covers all valid cases? > + I am not sure about "ieName" - is it a completely arbitrary string? I am not aware of any restriction (apart from white spaces, which should probably be excluded). I have to check. > - The description of "ieEnterpriseNumber" leafs says: "If omitted or > zero, the Information Element is registered in the IANA registry of > IPFIX Information Elements." Why not define a default value of "0" > here (perhaps in a special typedef)? I'm not sure whether 0 is a valid enterprise number. In http://www.iana.org/assignments/enterprise-numbers , we have: Decimal | Organization | | Contact | | | Email | | | | 0 Reserved Internet Assigned Numbers Authority iana&iana.org Does this mean that 0 can be used to refer to IANA? If yes, we could use 0 as a default value. Otherwise, I would rather remove "or zero" and create a type that does not allow zero values. From muenz@net.in.tum.de Sun Dec 19 03:19: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 D43BA3A685B; Sun, 19 Dec 2010 03:19:55 -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 4IajLDsv7u5i; Sun, 19 Dec 2010 03:19:55 -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 B5A8A3A684D; Sun, 19 Dec 2010 03:19:54 -0800 (PST) Received: from [192.168.1.151] (ppp-88-217-7-31.dynamic.mnet-online.de [88.217.7.31]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 015A221AAFCE; Sun, 19 Dec 2010 12:21:39 +0100 (CET) Message-ID: <4D0DEAAA.3070005@net.in.tum.de> Date: Sun, 19 Dec 2010 12:21:14 +0100 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <80A0822C5E9A4440A5117C2F4CD36A64015D3AFE@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64015D3AFE@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: yang-doctors@ietf.org, "Linowski, Bernd \(EXT-Other - DE\)" , ipfix@ietf.org Subject: Re: [IPFIX] Review of ietf-ipfix-psamp@2010-10-25.yang 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, 19 Dec 2010 11:19:55 -0000 Dear Mehmet, Bernd, Thanks a lot for your valuable comments. Please find my replies inline. Gerhard On 14.12.2010 14:04, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi All, > > below are a few review comments on the IPFIX YANG module in > draft-ietf-ipfix-configuration-model-08 from Bernd and myself. > > In general I agree with Lada that the model is too long and should be > probably devided into two parts covering the collector subsystem and the > rest functionality. > > The grouping "selectorParameters" is very long (spans several pages) and > therefore is hard to read and understand. > Main reason is that it contains a huge choice statement ("Method") that > hosts a container for every type of selector, each containing several > leafs. > Perhaps it would be better to move the contents of each of those > containers in an own grouping which are then used inside the choice > statement. As already stated in my reply to Lada, I would not separate CP from the other processes. However, we could put the selector parameters in a separate module. As a result, we would have the same distinction between an ipfix-psamp module (which then could be renamed ipfix module) and a selector module as between IPFIX-MIB and SELECTOR-MIB. The motivation for this separation is that adding a new selector only affects the selector module, but not the ipfix module. Hence, we would put "choice Method" in a grouping within the selector module. The ipfix module would refer to this external grouping with a "uses" statement. I hope that such external references are possible? > The applicability of certain cacheMode identities is feature depended. > > For example: > identity timeout { > base "cacheMode"; > description "Flow expiration after active and inactive timeout; > generation of Flow Records. > This identity MUST NOT be referred to unless the feature > cacheModeTimeout is supported by the Monitoring Device."; > } > > In effect, the constraint is described only in the description but not > enforced by the way the module is defined. > The current model saves some space though it would be better to model > Constraint-based. > I think it would be better to introduce a Container per cachMode and > protect it with if-feature (see model excerpt below with some skipped > parts). > The Container could be then put in a Choice statement and groupings > could be used to avoid repetitions (not in the example). > > container timeout { > if-feature cacheModeTimeout ; > leaf maxFlows { > type uint32; > units flows; > ... > } > leaf activeTimeout { > type uint32; > ... > } > leaf inactiveTimeout { > type uint32; > ... > } > ... > } > conatiner natural { > if-feature cacheModeNatural ; > leaf maxFlows { > type uint32; > units flows; > ... > } > leaf activeTimeout { > type uint32; > ... > } > leaf inactiveTimeout { > type uint32; > ... > } > ... > } > conatiner permanent { > if-feature cacheModePermanent; > leaf maxFlows { > type uint32; > units flows; > ... > } > leaf exportInterval { > when "../cacheMode = 'ipfix:permanent'" { > description "This parameter is only available for Cache Mode > 'permanent'."; > } > ... > } That's a good idea. From braun@net.in.tum.de Sun Dec 19 04:14: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 1CC743A688F for ; Sun, 19 Dec 2010 04:14:27 -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 jLcxODLCXGiN for ; Sun, 19 Dec 2010 04:14:26 -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 377533A6888 for ; Sun, 19 Dec 2010 04:14:26 -0800 (PST) Received: from tnomrev.box (e181096129.adsl.alicedsl.de [85.181.96.129]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 29465213C8AC; Sun, 19 Dec 2010 13:16:16 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Lothar Braun In-Reply-To: <4CBBA607.7080404@auckland.ac.nz> Date: Sun, 19 Dec 2010 13:16:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3690E8D4-E17A-4502-871A-45A5F6378A73@net.in.tum.de> References: <4CBBA607.7080404@auckland.ac.nz> To: Nevil Brownlee X-Mailer: Apple Mail (2.1082) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Two WGLCs starting now 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, 19 Dec 2010 12:14:27 -0000 Hi all, I have reviewed the latest draft-ietf-ipfix-configuration-model-08.txt, = and I'm happy with the current version.=20 The only nit I could identify is a missing closing bracket in Section = 3.1, page 10: ("SelectAll" class in Section 4.2.1.=20 should be =09 ("SelectAll" class in Section 4.2.1). Please note that my YANG experience is very limited. Best regards, Lothar =20 On Oct 18, 2010, at 3:42 AM, Nevil Brownlee wrote: >=20 > Hi all: >=20 > We have two drafts waiting for Working Group Last Call. > Their WGLCs start now, and will finish on 3 November (the > Wednesday before the Beijing IETF). >=20 > The drafts are: > 1. draft-ietf-ipfix-structured-data-03.txt > Second WGLC for this draft, the first was back in July > for the -01 version. There's been a *lot* of discussion > on the mailing list since!) > 2. draft-ietf-ipfix-configuration-model-07.txt > We were waiting for the YANG RFCs to be published for this one. >=20 > Cheers, Nevil (IPFIX co-chair) >=20 > --=20 > --------------------------------------------------------------------- > 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 -- Lothar Braun Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18010 Fax: +49 89 289-18033 E-mail: braun@net.in.tum.de=20 From akoba@nttv6.net Sun Dec 19 07:47:18 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 A3EE43A67E4 for ; Sun, 19 Dec 2010 07:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.698, 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 z6ndmdCP4OZE for ; Sun, 19 Dec 2010 07:47:17 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 35C5E3A67F0 for ; Sun, 19 Dec 2010 07:47:16 -0800 (PST) Received: from [192.168.1.5] (mail.nttv6.net [IPv6:2001:fa8::25]) by mail.nttv6.net (8.14.4/8.14.4) with ESMTP id oBJFn3FO047675; Mon, 20 Dec 2010 00:49:04 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 20 Dec 2010 00:49:04 +0900 From: Kobayashi Atsushi To: "Romascanu, Dan (Dan)" In-Reply-To: References: Message-Id: <20101220004903.4A55.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.53 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 20 Dec 2010 00:49:04 +0900 (JST) Cc: IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-framework-09 approved as 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: Sun, 19 Dec 2010 15:47:18 -0000 Dear Dan, Benoit, and all, Thank you for announcement of happy news. Benoit, thanks to you for your contribution in IESG review. I as first author could not have achieved the draft to be current status without IPFIXer's supports and contributions. I realized that, again. I would like to thank all of you. I have prepared new draft to be submitted along with IESG writeups. Is it to be submitted? http://www3.plala.or.jp/akoba/draft-ietf-ipfix-mediators-framework-10-01.txt http://www3.plala.or.jp/akoba/diff-md-fk-09-fk-10-01.htm Thanks, Atsushi On Thu, 16 Dec 2010 18:42:53 +0100 "Romascanu, Dan (Dan)" wrote: > The IESG approved in the telechat today > draft-ietf-ipfix-mediators-framework-09 as Informational RFC. Thanks to > everybody who contributed, and especially with Benoit who worked on-line > until the last minute to propose solutions to all the concerns expressed > by the IESG. > > Regards, > > Dan > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --- Atsushi KOBAYASHI From dromasca@avaya.com Mon Dec 20 01:19:40 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 5D32A3A67BD for ; Mon, 20 Dec 2010 01:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 0mpysIKriS9k for ; Mon, 20 Dec 2010 01:19:39 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 224183A67B5 for ; Mon, 20 Dec 2010 01:19:38 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEOvDk3GmAcF/2dsb2JhbACkIHOkPQKYL4VKBI4y X-IronPort-AV: E=Sophos;i="4.60,201,1291611600"; d="scan'208";a="50830073" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 20 Dec 2010 04:21:31 -0500 X-IronPort-AV: E=Sophos;i="4.60,201,1291611600"; d="scan'208";a="558212141" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Dec 2010 04:21:25 -0500 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, 20 Dec 2010 10:21:10 +0100 Message-ID: In-Reply-To: <20101220004903.4A55.17391CF2@nttv6.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] draft-ietf-ipfix-mediators-framework-09 approved as Informational RFC Thread-Index: AcuflEYm3WtW7ZGKTDS5roepbw1EKgAkp5NQ References: <20101220004903.4A55.17391CF2@nttv6.net> From: "Romascanu, Dan (Dan)" To: "Kobayashi Atsushi" Cc: IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-framework-09 approved as 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: Mon, 20 Dec 2010 09:19:40 -0000 No, there is no need. Now the document is handed to the RFC Editor, and they will make the changes according to the Note to the RFC Editor. If you feel that anything was left our you can comment during the 48 hours process, when authors are asked for a final review of the text.=20 Thanks and Regards, Dan =20 > -----Original Message----- > From: Kobayashi Atsushi [mailto:akoba@nttv6.net]=20 > Sent: Sunday, December 19, 2010 5:49 PM > To: Romascanu, Dan (Dan) > Cc: IPFIX Working Group > Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-framework-09=20 > approved as Informational RFC >=20 > Dear Dan, Benoit, and all, >=20 > Thank you for announcement of happy news.=20 > Benoit, thanks to you for your contribution in IESG review. I=20 > as first author could not have achieved the draft to be=20 > current status without IPFIXer's supports and contributions.=20 > I realized that, again. > I would like to thank all of you. >=20 > I have prepared new draft to be submitted along with IESG=20 > writeups. Is it to be submitted? > http://www3.plala.or.jp/akoba/draft-ietf-ipfix-mediators-frame > work-10-01.txt > http://www3.plala.or.jp/akoba/diff-md-fk-09-fk-10-01.htm >=20 > Thanks, > Atsushi >=20 > On Thu, 16 Dec 2010 18:42:53 +0100 > "Romascanu, Dan (Dan)" wrote: >=20 > > The IESG approved in the telechat today > > draft-ietf-ipfix-mediators-framework-09 as Informational=20 > RFC. Thanks=20 > > to everybody who contributed, and especially with Benoit who worked=20 > > on-line until the last minute to propose solutions to all=20 > the concerns=20 > > expressed by the IESG. > >=20 > > Regards, > >=20 > > Dan > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix >=20 > --- > Atsushi KOBAYASHI >=20 >=20 From bclaise@cisco.com Mon Dec 20 01:47:20 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 095153A67D2; Mon, 20 Dec 2010 01:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 2BoEV8q8Cma2; Mon, 20 Dec 2010 01:47: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 3FD5D3A6A37; Mon, 20 Dec 2010 01:47:16 -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 oBK9br55001732; Mon, 20 Dec 2010 10:37:53 +0100 (CET) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oBK9bqQr005091; Mon, 20 Dec 2010 10:37:52 +0100 (CET) Message-ID: <4D0F23F0.9070200@cisco.com> Date: Mon, 20 Dec 2010 10:37:52 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Gerhard Muenz References: <1292254737.8763.57.camel@behold> <4D0DE31F.1080308@net.in.tum.de> In-Reply-To: <4D0DE31F.1080308@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: YANG Doctors , Ladislav Lhotka , ipfix@ietf.org Subject: Re: [IPFIX] review of YANG module ietf-ipfix-psamp@2010-10-25 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, 20 Dec 2010 09:47:20 -0000 Hi, > > Dear Lada, > > Thanks a lot for your valuable comments. > > Please find my replies inline. > > Gerhard > > On 13.12.2010 16:38, Ladislav Lhotka wrote: >> Hi, >> >> this is my review of the ietf-ipfix-psamp@2010-10-25 module: >> >> *** General comments >> >> This module is probably the largest (public) data modelling effort >> that has been done with YANG so far. It is therefore also important as >> a serious test case for YANG itself. >> >> The module demonstrates that object-based data modelling can be done >> with the current YANG syntax in an elegant and extensible way. I like >> the approach of mapping UML diagrams to YANG structures where object >> properties are represented by groupings, aggregated components as >> subordinate nodes and unidirectional associations with leafrefs. >> >> The module closely obeys all the recommendations of >> draft-ietf-netmod-yang-usage-11. >> >> My main concern is the size of the module. I believe that splitting the >> data model into smaller coherent modules makes it more understandable >> and manageable - also in terms of the standardisation process. It >> seems that the present module could relatively easily be divided into >> two modules, one describing the collector subsystem and the other >> dealing with the remaining functionality. As a matter of fact, flow >> collectors are in most cases implemented in a separate device, so >> their configuration won't be mixed with configurations of the other >> parts. This change would also remove one level of containment in the >> schema, at a very reasonable price of adding one more namespace. > > With the upcoming IPFIX mediators, we will have devices implementing > Collecting Processes, Intermediate Processes, and Exporting Processes. > Therefore, I think that keeping the configuration data of all IPFIX > processes in one module makes sense. I agree with Gerhard here. Regards, Benoit. From akoba@nttv6.net Mon Dec 20 05:58:06 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 C1CFC3A6891 for ; Mon, 20 Dec 2010 05:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] 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 CUOFi+pYmKfz for ; Mon, 20 Dec 2010 05:58:05 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id D696F3A68DD for ; Mon, 20 Dec 2010 05:58:04 -0800 (PST) Received: from [192.168.1.100] (mail.nttv6.net [IPv6:2001:fa8::25]) by mail.nttv6.net (8.14.4/8.14.4) with ESMTP id oBKDxelh054328; Mon, 20 Dec 2010 22:59:46 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 20 Dec 2010 22:59:47 +0900 From: Kobayashi Atsushi To: "Romascanu, Dan (Dan)" In-Reply-To: References: <20101220004903.4A55.17391CF2@nttv6.net> Message-Id: <20101220225934.DF73.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.56.04 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 20 Dec 2010 22:59:51 +0900 (JST) Cc: IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-framework-09 approved as 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: Mon, 20 Dec 2010 13:58:06 -0000 Dear Dan, OK, Thank you. Regards, Atsushi On Mon, 20 Dec 2010 10:21:10 +0100 "Romascanu, Dan (Dan)" wrote: > No, there is no need. Now the document is handed to the RFC Editor, and > they will make the changes according to the Note to the RFC Editor. If > you feel that anything was left our you can comment during the 48 hours > process, when authors are asked for a final review of the text. > > Thanks and Regards, > > Dan > > > > -----Original Message----- > > From: Kobayashi Atsushi [mailto:akoba@nttv6.net] > > Sent: Sunday, December 19, 2010 5:49 PM > > To: Romascanu, Dan (Dan) > > Cc: IPFIX Working Group > > Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-framework-09 > > approved as Informational RFC > > > > Dear Dan, Benoit, and all, > > > > Thank you for announcement of happy news. > > Benoit, thanks to you for your contribution in IESG review. I > > as first author could not have achieved the draft to be > > current status without IPFIXer's supports and contributions. > > I realized that, again. > > I would like to thank all of you. > > > > I have prepared new draft to be submitted along with IESG > > writeups. Is it to be submitted? > > http://www3.plala.or.jp/akoba/draft-ietf-ipfix-mediators-frame > > work-10-01.txt > > http://www3.plala.or.jp/akoba/diff-md-fk-09-fk-10-01.htm > > > > Thanks, > > Atsushi > > > > On Thu, 16 Dec 2010 18:42:53 +0100 > > "Romascanu, Dan (Dan)" wrote: > > > > > The IESG approved in the telechat today > > > draft-ietf-ipfix-mediators-framework-09 as Informational > > RFC. Thanks > > > to everybody who contributed, and especially with Benoit who worked > > > on-line until the last minute to propose solutions to all > > the concerns > > > expressed by the IESG. > > > > > > Regards, > > > > > > Dan > > > _______________________________________________ > > > IPFIX mailing list > > > IPFIX@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipfix > > > > --- > > Atsushi KOBAYASHI > > > > > --- Atsushi KOBAYASHI From lhotka@cesnet.cz Mon Dec 20 06:09:52 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 9DF413A68CB; Mon, 20 Dec 2010 06:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.065, 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 qU3l6Pt3FfPm; Mon, 20 Dec 2010 06:09:51 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 56C4A3A69D7; Mon, 20 Dec 2010 06:09:50 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e] (unknown [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e]) by office2.cesnet.cz (Postfix) with ESMTPSA id 288D82CDE057; Mon, 20 Dec 2010 15:11:42 +0100 (CET) From: Ladislav Lhotka To: Gerhard Muenz In-Reply-To: <4D0DE31F.1080308@net.in.tum.de> References: <1292254737.8763.57.camel@behold> <4D0DE31F.1080308@net.in.tum.de> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 20 Dec 2010 15:11:42 +0100 Message-ID: <1292854302.15113.23.camel@behold> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 20 Dec 2010 12:19:56 -0800 Cc: YANG Doctors , ipfix@ietf.org Subject: Re: [IPFIX] review of YANG module ietf-ipfix-psamp@2010-10-25 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, 20 Dec 2010 14:09:52 -0000 On Ne, 2010-12-19 at 11:49 +0100, Gerhard Muenz wrote: > Dear Lada, > > Thanks a lot for your valuable comments. > > Please find my replies inline. > > Gerhard > > On 13.12.2010 16:38, Ladislav Lhotka wrote: > > Hi, > > > > this is my review of the ietf-ipfix-psamp@2010-10-25 module: > > > > *** General comments > > > > This module is probably the largest (public) data modelling effort > > that has been done with YANG so far. It is therefore also important as > > a serious test case for YANG itself. > > > > The module demonstrates that object-based data modelling can be done > > with the current YANG syntax in an elegant and extensible way. I like > > the approach of mapping UML diagrams to YANG structures where object > > properties are represented by groupings, aggregated components as > > subordinate nodes and unidirectional associations with leafrefs. > > > > The module closely obeys all the recommendations of > > draft-ietf-netmod-yang-usage-11. > > > > My main concern is the size of the module. I believe that splitting the > > data model into smaller coherent modules makes it more understandable > > and manageable - also in terms of the standardisation process. It > > seems that the present module could relatively easily be divided into > > two modules, one describing the collector subsystem and the other > > dealing with the remaining functionality. As a matter of fact, flow > > collectors are in most cases implemented in a separate device, so > > their configuration won't be mixed with configurations of the other > > parts. This change would also remove one level of containment in the > > schema, at a very reasonable price of adding one more namespace. > > With the upcoming IPFIX mediators, we will have devices implementing > Collecting Processes, Intermediate Processes, and Exporting Processes. > Therefore, I think that keeping the configuration data of all IPFIX > processes in one module makes sense. All functions could be combined anyway, even if they are defined in different modules, by advertising all modules that apply in the hello message rather than having just one module and using various combinations of features. By way of analogy, entire router configuration could also be specified in one module and various routing protocols selected by means of features - I just don't think this is the right approach. > > > The module could certainly make a good use of a generic model of > > network interfaces. > > > > *** Specific comments > > > > - Some description statements only retell in prose what is succinctly > > expressed by other statements. Such description statements should > > be removed. For example the type description in > > typedef ieIdType { > > type uint16 { > > range "1..32767" { > > description "Valid range of Information Element > > identifiers."; > > reference "RFC5102, Section 4."; > > } > > } > > description "Type for Information Element identifiers."; > > } > > Please note that this is not a description for type but for range! > I want to motivate the range restriction for ieIdType and provide a > reference to the corresponding section in RFC5102. The 'reference' is fine but otherwise the 'range' statement says it all. > > > - Several leafs with string type could be further restricted: > > + The length of "ifName" is restricted to 255 characters. > > + Distinguished names of certification authorities and subjects also > > have a structure and a set of reserved characters - of course, a DN > > datatype would normally be imported from an external module, but > > it doesn't exist yet. > > Is there somebody who feels capable of providing a regular expression > for DN that covers all valid cases? > > > + I am not sure about "ieName" - is it a completely arbitrary string? > > I am not aware of any restriction (apart from white spaces, which should > probably be excluded). I have to check. > > > - The description of "ieEnterpriseNumber" leafs says: "If omitted or > > zero, the Information Element is registered in the IANA registry of > > IPFIX Information Elements." Why not define a default value of "0" > > here (perhaps in a special typedef)? > > I'm not sure whether 0 is a valid enterprise number. > > > In http://www.iana.org/assignments/enterprise-numbers , we have: > > Decimal > | Organization > | | Contact > | | | Email > | | | | > 0 > Reserved > Internet Assigned Numbers Authority > iana&iana.org > > Does this mean that 0 can be used to refer to IANA? > If yes, we could use 0 as a default value. Otherwise, I would rather > remove "or zero" and create a type that does not allow zero values. I don't know but the text as it is now sounds exactly like zero is the default value for this leaf. Lada > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From iesg-secretary@ietf.org Mon Dec 20 13:07:08 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 DB0A63A6AF4; Mon, 20 Dec 2010 13:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 kYp5n3iyRcb3; Mon, 20 Dec 2010 13:07:07 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1683A6AF5; Mon, 20 Dec 2010 13:07:07 -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.10 Message-ID: <20101220210707.32571.30069.idtracker@localhost> Date: Mon, 20 Dec 2010 13:07:07 -0800 Cc: Internet Architecture Board , ipfix chair , ipfix mailing list , RFC Editor Subject: [IPFIX] Document Action: 'IPFIX Mediation: Framework' to Informational RFC (draft-ietf-ipfix-mediators-framework-09.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, 20 Dec 2010 21:07:09 -0000 The IESG has approved the following document: - 'IPFIX Mediation: Framework' (draft-ietf-ipfix-mediators-framework-09.txt) as an Informational RFC This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipfix-mediators-framework/ Technical Summary This document describes a framework for IPFIX Mediation. This framework extends the IPFIX reference model by defining the IPFIX Mediator components. Working Group Summary The mediation framework was added to the IPIFX charter in 2008. There is a strong consensus in the IPFIX WG to publish this version of the document. The document had multiple individual reviews from key WG members during two WG last calls. Several comments were made and have been addressed when updating the document after the WGLCs. There are no particular issues in the document without strong consensus in the IPFIX WG. Document Quality The document underwent two WG last call in the IPFIX WG. This way, a high document quality has been achieved already. Personnel Juergen Quittek is the Document Shepherd. Dan Romascanu is the Responsible Area Director. RFC Editor Note 1. Add to the document header: Updates: 5470 (if approved) 2. In the Abstract: OLD: This document describes a framework for IPFIX Mediation. This framework extends the IPFIX reference model by defining the IPFIX Mediator components. NEW: This document describes a framework for IPFIX Mediation. This framework extends the IPFIX reference model specified in RFC5470 by defining the IPFIX Mediator components. 3. Add RFC 5470 and RFC 5655 as Normative References 4. In Section 8: OLD: IPFIX Mediation reuses the general information models from [RFC5102] and [RFC5477]. However, several Intermediate Processes would potentially require additional Information Elements as follows: NEW: IPFIX Mediation reuses the general information models from [RFC5102] and [RFC5477], and, depending on the Intermediate Processes type, potentially Information Elements such as: 5. Append at the end of Section 5.3 the following paragraph: For example, an Intermediate Aggregation Process aggregating incoming Flow Records composed of the sourceIPv4Address and destinationIPv4Address Flow Keys into outgoing Flow Records with the destinationIPv4Address Flow Key, must the modify the incoming flowKeyIndicator to contain only the destinationIPv4Address. From bclaise@cisco.com Mon Dec 20 14:10:50 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 D3F2E3A6B0B for ; Mon, 20 Dec 2010 14:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.118, 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 S3fNwgpOz4H4 for ; Mon, 20 Dec 2010 14:10:46 -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 69B3B3A68FC for ; Mon, 20 Dec 2010 14:10:41 -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 oBKM8p45029596 for ; Mon, 20 Dec 2010 23:08:51 +0100 (CET) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oBKM8mba029693; Mon, 20 Dec 2010 23:08:48 +0100 (CET) Message-ID: <4D0FD3EF.6040803@cisco.com> Date: Mon, 20 Dec 2010 23:08:47 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/alternative; boundary="------------050204090907030804000902" Subject: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-structured-data-04 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, 20 Dec 2010 22:10:50 -0000 This is a multi-part message in MIME format. --------------050204090907030804000902 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, This version should take care of all the WGLC comments. Regards, Benoit. -------- Original Message -------- Subject: New Version Notification for draft-ietf-ipfix-structured-data-04 Date: Mon, 20 Dec 2010 14:04:35 -0800 (PST) From: IETF I-D Submission Tool To: bclaise@cisco.com CC: gowri@cisco.com, syates@cisco.com, paitken@cisco.com A new version of I-D, draft-ietf-ipfix-structured-data-04.txt has been successfully submitted by Benoit Claise and posted to the IETF repository. Filename: draft-ietf-ipfix-structured-data Revision: 04 Title: Export of Structured Data in IPFIX Creation_date: 2010-12-20 WG ID: ipfix Number_of_pages: 74 Abstract: This document specifies an extension to the IP Flow Information eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX information model specified in [RFC5102] to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record. The IETF Secretariat. --------------050204090907030804000902 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Dear all,

This version should take care of all the WGLC comments.

Regards, Benoit.
-------- Original Message --------
Subject: New Version Notification for draft-ietf-ipfix-structured-data-04
Date: Mon, 20 Dec 2010 14:04:35 -0800 (PST)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: bclaise@cisco.com
CC: gowri@cisco.com, syates@cisco.com, paitken@cisco.com 


A new version of I-D, draft-ietf-ipfix-structured-data-04.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-ietf-ipfix-structured-data
Revision:	 04
Title:		 Export of Structured Data in IPFIX
Creation_date:	 2010-12-20
WG ID:		 ipfix
Number_of_pages: 74

Abstract:
This document specifies an extension to the IP Flow Information 

  eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX 

  information model specified in [RFC5102] to support hierarchical 

  structured data and lists (sequences) of Information Elements in 

  data records.  This extension allows definition of complex data 

  structures such as variable-length lists and specification of 

  hierarchical containment relationships between Templates. 

  Finally, the semantics are provided in order to express the 

  relationship among multiple list elements in a structured data 

  record.
                                                                                  


The IETF Secretariat.
--------------050204090907030804000902-- From Internet-Drafts@ietf.org Mon Dec 20 14:15:04 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 9C6373A6921; Mon, 20 Dec 2010 14:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 AbXlvOgKhslG; Mon, 20 Dec 2010 14:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75BC73A68FD; Mon, 20 Dec 2010 14:15:01 -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 X-IETF-IDTracker: 3.10 Message-ID: <20101220221501.5051.22922.idtracker@localhost> Date: Mon, 20 Dec 2010 14:15:01 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-structured-data-04.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, 20 Dec 2010 22:15:04 -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 : Export of Structured Data in IPFIX Author(s) : B. Claise, et al. Filename : draft-ietf-ipfix-structured-data-04.txt Pages : 74 Date : 2010-12-20 This document specifies an extension to the IP Flow Information eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX information model specified in [RFC5102] to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-structured-data-04.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-structured-data-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-20140434.I-D@ietf.org> --NextPart--