From dromasca@avaya.com Wed Jun 1 01:38:57 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455D0E07C1 for ; Wed, 1 Jun 2011 01:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.317 X-Spam-Level: X-Spam-Status: No, score=-103.317 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfE4PW71B2RO for ; Wed, 1 Jun 2011 01:38:56 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 89CF0E0782 for ; Wed, 1 Jun 2011 01:38:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAF/45U3GmAcF/2dsb2JhbABTglKUfY5Td6scApsghiAElTWKSA X-IronPort-AV: E=Sophos;i="4.65,302,1304308800"; d="scan'208,217";a="282602921" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 Jun 2011 04:38:55 -0400 X-IronPort-AV: E=Sophos;i="4.65,302,1304308800"; d="scan'208,217";a="628276977" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Jun 2011 04:38:55 -0400 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_01CC2037.574DA2F1" Date: Wed, 1 Jun 2011 10:38:53 +0200 Message-ID: In-Reply-To: <29883E73-D176-41BC-933C-13A89C77AE7B@cert.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] comments on draft-johnson-ipfix-mib-variable-export-01 Thread-Index: AcwfolYPPBnd1r72RaqYbokfkj9/vwAk6p6Q References: <29883E73-D176-41BC-933C-13A89C77AE7B@cert.org> From: "Romascanu, Dan (Dan)" To: "Chris Inacio" , "IPFIX Working Group" Subject: Re: [IPFIX] comments on draft-johnson-ipfix-mib-variable-export-01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 08:38:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2037.574DA2F1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 Hi, Can we please avoid using PDF for comments on the mail list? While using PDF may be justified in some cases in order to better represent complex diagrams in RFCs or Internet-Drafts (although even for RFCs and Internet-Drafts the default format is ASCII text, and PDF or Post-Script are accepted only if an equivalent ASCII version is also available), I see no reason to require proprietary sofware in order to be able to read comments or other mails on an IETF list.=20 Thanks and Regards, Dan From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of Chris Inacio Sent: Tuesday, May 31, 2011 5:52 PM To: IPFIX Working Group Subject: [IPFIX] comments on draft-johnson-ipfix-mib-variable-export-01 =20 Here are my comments on the draft. This model is much improved and with some minor additional clarification I think it should be much more seriously considered. I did everything as PDF comments to the PDF version of the draft. I've attached it here. regards, chris ------_=_NextPart_001_01CC2037.574DA2F1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

Hi,

Can we please avoid = using PDF for comments on the mail list? While using PDF may be = justified in some cases in order to better represent complex diagrams in = RFCs or Internet-Drafts (although even for RFCs and Internet-Drafts the = default format is ASCII text, and PDF or Post-Script are accepted only = if an equivalent ASCII version is also available), I see no reason to = require proprietary sofware in order to be able to read comments or = other mails on an IETF list.


Thanks and = Regards,

Dan

From:= = ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of = Chris Inacio
Sent: Tuesday, May 31, 2011 5:52 = PM
To: IPFIX Working Group
Subject: [IPFIX] comments = on = draft-johnson-ipfix-mib-variable-export-01

 

Here are my comments on the draft.  This = model is much improved and with some minor additional clarification I = think it should be much more seriously considered.  I did = everything as PDF comments to the PDF version of the draft.  I've = attached it = here.

regards,
chris



------_=_NextPart_001_01CC2037.574DA2F1-- From dromasca@avaya.com Wed Jun 1 03:19:17 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BEBE07A6 for ; Wed, 1 Jun 2011 03:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KemsmamZsV9Q for ; Wed, 1 Jun 2011 03:19:16 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 70A2AE0787 for ; Wed, 1 Jun 2011 03:19:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAE0R5k3GmAcF/2dsb2JhbABTpiJ3p3eDWgKbGIYgBJU1ikg X-IronPort-AV: E=Sophos;i="4.65,302,1304308800"; d="scan'208";a="249227222" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Jun 2011 06:19:14 -0400 X-IronPort-AV: E=Sophos;i="4.65,302,1304308800"; d="scan'208";a="628308273" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Jun 2011 06:19:14 -0400 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: Wed, 1 Jun 2011 12:19:12 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-ipfix-psamp-mib-03.txt Thread-Index: AcwgRVpKL+rIVnCXROu/usNykoC0lg== From: "Romascanu, Dan (Dan)" To: "IPFIX Working Group" Subject: [IPFIX] AD review of draft-ietf-ipfix-psamp-mib-03.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 10:19:17 -0000 Hi,=20 I have performed the AD review of draft-ietf-ipfix-psamp-mib-03.txt. This document is in good shape and I am sending it to IETF Last Call. Please address the comments below together with the other IETF LC comments.=20 The technical comments are marked T and the editorial comments are marked E.=20 T1.=20 Float64TC FROM FLOAT-TC-MIB -- draft-ietf-opsawg-mib-float Actually will need to be published before or simultaneously with this document, in order to satisfy the normative reference. Leaving draft-ietf-opsawg-mib-float would be confusing, we need the RFC number here. I suggest to include here (as a comment) a note to the RFC Editor that mentions that draft-ietf-opsawg-mib-float is to be replaced with the RFC number of that document, and the note deleted.=20 T2. Why do psampSampCountBasedAvail, psampSampTimeBasedAvail, psampSampRandOutOfNAvail, psampSampUniProbAvail, psampFiltPropMatchAvail, psampFiltHashAvail have DEFVAL clauses? These are read-only objects, so the values must be configured by some other means (not by SNMP) and just read by the agent. =20 T3. There is no need to include the following in the IANA considerations section:=20 psampSampCountBased { ipfixSelectorFunctions 2 } psampSampTimeBased { ipfixSelectorFunctions 3 } psampSampRandOutOfN { ipfixSelectorFunctions 4 } psampSampUniProb { ipfixSelectorFunctions 5 } psampFiltPropMatch { ipfixSelectorFunctions 6 } psampFiltHash { ipfixSelectorFunctions 7 } These are already assigned in the MIB module and no IANA action is required for them.=20 E1. The contents of sections 3 and 4 are similar, but the formatting of the texts in the two sections is different. I suggest to fix this using for section 4 the same format as in section 3, which is easier to read.=20 E2. Page 5 - second paragraph s/as defiend/as defined/ E3. Please explain the meaning of each enumerated value in the DESCRIPTION clause of psampFiltHashFunction E4. Please detail the 'corresponding sampling function' in the DESCRIPTION clause of each one of the conformance groups under MODULE-COMPLIANCE.=20 Thanks and Regards, Dan=20 From dromasca@avaya.com Wed Jun 1 04:40:50 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1B4E0692 for ; Wed, 1 Jun 2011 04:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.731 X-Spam-Level: X-Spam-Status: No, score=-101.731 tagged_above=-999 required=5 tests=[AWL=-1.298, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+7LfUKj1oF8 for ; Wed, 1 Jun 2011 04:40:49 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 81460E0670 for ; Wed, 1 Jun 2011 04:40:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAPkk5k2HCzI1/2dsb2JhbABTl1COU3eregKbD4YgBJU1ikg X-IronPort-AV: E=Sophos;i="4.65,303,1304308800"; d="scan'208";a="191192332" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 01 Jun 2011 07:40:38 -0400 X-IronPort-AV: E=Sophos;i="4.65,303,1304308800"; d="scan'208";a="658351995" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 01 Jun 2011 07:40:23 -0400 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: Wed, 1 Jun 2011 13:40:19 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] AD review of draft-ietf-ipfix-psamp-mib-03.txt Thread-Index: AcwgRVpKL+rIVnCXROu/usNykoC0lgACsYcA References: From: "Romascanu, Dan (Dan)" To: "IPFIX Working Group" Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-psamp-mib-03.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 11:40:50 -0000 Hi,=20 I have one more comment - please add it to the review:=20 T4. As per [I-D.ietf-opsawg-mib-floats]:=20 o Since these textual conventions are defined in terms of the OCTET STRING type, the SMI's mechanisms for formally setting range constraints are not available. MIB designers using these textual conventions will need to use DESCRIPTION clauses to spell out any applicable range constraints beyond those implied by the underlying IEEE types. o Whenever these textual conventions are used in a MIB module, the associated DESCRIPTION clause will need to clearly specify whether denormalized numbers, NaNs ("not a number") or infinities are permitted, along with any special semantics associated with these cases. This is especially important for writeable objects. As the object psampSampUniProbProbability uses the Float64TC - these requirements need to be taken into consideration.=20 Thanks and Regards, Dan=20 > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf > Of Romascanu, Dan (Dan) > Sent: Wednesday, June 01, 2011 1:19 PM > To: IPFIX Working Group > Subject: [IPFIX] AD review of draft-ietf-ipfix-psamp-mib-03.txt >=20 >=20 >=20 > Hi, >=20 > I have performed the AD review of draft-ietf-ipfix-psamp-mib-03.txt. > This document is in good shape and I am sending it to IETF Last Call. > Please address the comments below together with the other IETF LC > comments. >=20 > The technical comments are marked T and the editorial comments are > marked E. >=20 > T1. >=20 > Float64TC > FROM FLOAT-TC-MIB -- draft-ietf-opsawg-mib-float >=20 > Actually will need to be published before or simultaneously with this > document, in order to satisfy the normative reference. Leaving > draft-ietf-opsawg-mib-float would be confusing, we need the RFC number > here. I suggest to include here (as a comment) a note to the RFC Editor > that mentions that draft-ietf-opsawg-mib-float is to be replaced with > the RFC number of that document, and the note deleted. >=20 > T2. Why do psampSampCountBasedAvail, psampSampTimeBasedAvail, > psampSampRandOutOfNAvail, psampSampUniProbAvail, > psampFiltPropMatchAvail, psampFiltHashAvail have DEFVAL clauses? These > are read-only objects, so the values must be configured by some other > means (not by SNMP) and just read by the agent. >=20 > T3. There is no need to include the following in the IANA > considerations > section: >=20 > psampSampCountBased { ipfixSelectorFunctions 2 } > psampSampTimeBased { ipfixSelectorFunctions 3 } > psampSampRandOutOfN { ipfixSelectorFunctions 4 } > psampSampUniProb { ipfixSelectorFunctions 5 } > psampFiltPropMatch { ipfixSelectorFunctions 6 } > psampFiltHash { ipfixSelectorFunctions 7 } >=20 > These are already assigned in the MIB module and no IANA action is > required for them. >=20 >=20 > E1. The contents of sections 3 and 4 are similar, but the formatting of > the texts in the two sections is different. I suggest to fix this using > for section 4 the same format as in section 3, which is easier to read. >=20 > E2. Page 5 - second paragraph s/as defiend/as defined/ >=20 > E3. Please explain the meaning of each enumerated value in the > DESCRIPTION clause of psampFiltHashFunction >=20 > E4. Please detail the 'corresponding sampling function' in the > DESCRIPTION clause of each one of the conformance groups under > MODULE-COMPLIANCE. >=20 >=20 > Thanks and Regards, >=20 > Dan >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From iesg-secretary@ietf.org Wed Jun 1 07:03:38 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B027FE0864; Wed, 1 Jun 2011 07:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSJLS4gfkOhm; Wed, 1 Jun 2011 07:03:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443A5E0807; Wed, 1 Jun 2011 07:03:38 -0700 (PDT) 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.55 Message-ID: <20110601140338.26104.39290.idtracker@ietfa.amsl.com> Date: Wed, 01 Jun 2011 07:03:38 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] Last Call: (Definitions of Managed Objects for Packet Sampling) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 14:03:38 -0000 The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Definitions of Managed Objects for Packet Sampling' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the IPFIX MIB module [RFC5815]. For IPFIX implementations that use packet Sampling (PSAMP) techniques as described in [RFC5475], this memo defines the PSAMP MIB module containing managed objects for providing information on applied packet selection functions and their parameters. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-psamp-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-psamp-mib/ No IPR declarations have been submitted directly on this I-D. From dromasca@avaya.com Wed Jun 1 08:39:56 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48836E08F4 for ; Wed, 1 Jun 2011 08:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.253 X-Spam-Level: X-Spam-Status: No, score=-103.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noME7aMF9qB7 for ; Wed, 1 Jun 2011 08:39:55 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5D554E08E8 for ; Wed, 1 Jun 2011 08:39:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADxc5k2HCzI1/2dsb2JhbABTpiR3qC+DWgKbE4YgBJU1ik0 X-IronPort-AV: E=Sophos;i="4.65,303,1304308800"; d="scan'208";a="249287501" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Jun 2011 11:39:53 -0400 X-IronPort-AV: E=Sophos;i="4.65,303,1304308800"; d="scan'208";a="658443638" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 01 Jun 2011 11:39:52 -0400 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: Wed, 1 Jun 2011 17:39:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-ipfix-configuration-model-09.txt Thread-Index: AcwgciV7zMizbAuASkCAs/BaNPh4Cw== From: "Romascanu, Dan (Dan)" To: "IPFIX Working Group" Subject: [IPFIX] AD review of draft-ietf-ipfix-configuration-model-09.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 15:39:56 -0000 Hi,=20 I performed the AD review of draft-ietf-ipfix-configuration-model-09.txt. This document is in good shape and I am sending it to IETF Last Call. Please consider the comments below together with the other IETF Last Call comments.=20 Technical Comments are marked T and Editorial comments are marked R.=20 T1. Section 4.2.2 - how is probability expressed - as a value between 0 and 1? T2. Section 4.7:=20 If SCTP is transport protocol, Exporter or Collector may be multi-homed SCTP endpoints (see [RFC4960], Section 6.4) and use more than one IP address. A capitalized 2119 MAY seems to be appropriate here.=20 E1. In Section 4.1:=20 However, indexes SHOULD only be used as identifiers if an SNMP agent on the same Monitoring Device enables access to the corresponding MIB objects. s/indexes/indices/ s/MIB objects/MIB tables/=20 Similarly=20 ifIndex SHOULD only be used if an SNMP agent enables access to the corresponding MIB object in the ifTable. Similarly, a physical entity is either identified by its name (entPhysicalName) or the entPhysicalIndex value of the corresponding object in the ENTITY-MIB module [RFC4133]. entPhysicalIndex SHOULD only be used if an SNMP agent enables access to the corresponding MIB object in the entPhysicalTable. Indices are by definition not-accessible, but accessing the tables that they index should be sufficient as the index can be extracted from the OIDs of the objects in the table.=20 E2. In section 4.3 cacheDiscontinuityTime: Timestamp of the most recent occasion at which dataRecords suffered a discontinuity. In contrast to ipfixMeteringProcessDiscontinuityTime, the time is absolute and not relative to sysUpTime. Note that this parameter corresponds to ipfixMeteringProcessDiscontinuityTime in the IPFIX MIB module [RFC5815]. Better say 'functionally corresponds' ... Thanks and Regards, Dan=20 From iesg-secretary@ietf.org Wed Jun 1 08:44:34 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DF7E090D; Wed, 1 Jun 2011 08:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO06pKOblxvh; Wed, 1 Jun 2011 08:44:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D85E08FD; Wed, 1 Jun 2011 08:44:28 -0700 (PDT) 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.55 Message-ID: <20110601154428.26005.54697.idtracker@ietfa.amsl.com> Date: Wed, 01 Jun 2011 08:44:28 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] Last Call: (Configuration Data Model for IPFIX and PSAMP) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 15:44:34 -0000 The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Configuration Data Model for IPFIX and PSAMP' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a data model for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX and PSAMP compliant Monitoring Devices using the NETCONF protocol [RFC4741]. The data model is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG [RFC6020]. The configuration data is encoded in Extensible Markup Language (XML). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-configuration-model/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-configuration-model/ No IPR declarations have been submitted directly on this I-D. From tanja.zseby9cd33xy531fokus.fraunhofer.de@bounce.antispameurope.com Tue Jun 7 06:46:32 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D4A21F8524 for ; Tue, 7 Jun 2011 06:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtdXr1C6ispz for ; Tue, 7 Jun 2011 06:46:31 -0700 (PDT) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8586C21F8521 for ; Tue, 7 Jun 2011 06:46:29 -0700 (PDT) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 1E93B160162; Tue, 7 Jun 2011 15:46:28 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 47EAC1601A5; Tue, 7 Jun 2011 15:46:23 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.4/8.14.2) with SMTP id p57DkMEr009669; Tue, 7 Jun 2011 15:46:22 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2011 15:46:32 +0200 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA1044F5AA2@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] New WG Last Call fordraft-ietf-ipfix-flow-selection-tech-06.txt Thread-Index: Acwcc961QvzCvh9IRFO+QqJW5YbJGAInlO5w References: <20110523092128.18082.9981.idtracker@ietfa.amsl.com><804B13F8F3D94A4AB18B9B01ACB68FA1044F55B0@EXCHSRV.fokus.fraunhofer.de><4DDC22C7.6070704@auckland.ac.nz><1E3C6A6E-83BC-4ABC-861E-EF46FC3F0624@tik.ee.ethz.ch> From: "Zseby, Tanja" To: "Brian Trammell" , "IPFIX Working Group" Subject: Re: [IPFIX] New WG Last Call fordraft-ietf-ipfix-flow-selection-tech-06.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 13:46:32 -0000 Hi Brian, thanks for summarizing the comments. Please find my answers below > 1. As Benoit said, and in refinement of my earlier message, the model = which > the document uses should be based on an Intermediate (Flow) Selection > Process (IFSP) as in RFC 6183, instead of adding new concepts to 5470. = The > case in section 4.1 is a bit of a special one, to address an uncommon > requirement; in addition, it isn't really a flow selection process at = all, but > rather a packet selection process that selects packets on the same = criteria > that by which packets are separated into flows by the flow key. = Therefore it > can be noted here, I think, that the _function_ run within an IFSP can = run _as > a packet selection process_ before flow generation within an MP = without > having to hack new processes into the 5470 model. Section 6 will have = to be > updated a bit to fit this change as well. I did not see the aggregation and classification process as = contradiction to RFC 5470, just as a more detailed/fine grained view on = processes that are needed inside the metering process to generate flow = records from packets. I think we need this more fine grained view to = describe the different flow selection processes. We can try to align with the Intermediate Process in RFC6183, but the = definition in RFC6183 requires a record stream as input which is not the = case in 4.1. (as you point out) and also not the case if you apply the = method on flow cache entries (which may contain different information = than the final flow record). In those cases the flow selection takes = place _within_ the metering process, before a record is generated. So we = probably would also violate the RFC6183 definition. >=20 > 2. The document should use a different term for "aggregation" (of = packets > into flows) to avoid collision with terminology related to aggregation = in RFCs > 5982 and 6183. Maybe we can use "packet aggregation" to make it clear? >=20 > 3. The document should use a different term for "classification" to = avoid > confusion with the use of this term with respect to "flow = classification" and > labeling. I realize 5470 uses the verb "classify" to refer to this = process; I really > wish it didn't. I think that both terms, aggregation and classification, are correct = here to describe the processes. It is just another entity (packets = instead of flows) that is classified or aggregated. So maybe we can use = "packet classification " and "packet aggregation"? >=20 > Aggregation and classification _together_ comprise the "assignment" of > packets to flows, and flow "generation". I'm afraid I don't have any = better > suggestions at this time. This is exactly my understanding. >=20 > 4. Terminology based on terminology borrowed by analogy or reference = to > the packet selection techniques draft is a good idea; however, these = terms > should be defined in section . To which terms do you refer to? In which section? > Additionally, terminology through the entire > document should be reviewed for proper capitalization. o.k. >=20 > 5. Within section 6, it is not clear how to apply this configuration = data model. > Should this be harmonized with ipfix-configuration-model? Yes, it shoudl be possible to use this as basis, like PASMP-TECH. Should = we just reference to the config-model or do you suggest any further = alignment? >=20 > 6. In section 7, I would suggest unifying Paul and Benoit's comments = on the > subject of fsFlowRecordTotalCount; additionally, the IE should be = named > flowDeltaCount to keep parallel with IEs 1 and 2. Consider renaming = the IEs in > general to drop the "fs" prefix. perhaps "postSelection" or something = similar > (as with the pre/post IEs). Review other IEs to ensure they are not = covered > by existing IEs (especially those "pre-selection", as with IE 3) >=20 We used fs in order to clarify that this refers to the flow records as = seen as input by the selection process. The values may differ e.g. if we = cascade multiple subsequent flow selection processes.=20 Wrt to delta counters I am unsure. We want to have the total records for = the interval that is used for the selection process. This might differ = from the reporting interval. So if we use the term deltaCount it refers = to the reporting interval. We need to have a further look into this. > 7. What is a Flow Entry? Should this be defined in this document, or > referenced as terminology from another? If this is what I think it is = (reporting > flow cache size inline), I'm not certain it belongs here in flow = selection > (perhaps in a document on metering process monitoring?). With flow entry we mean an entry in the flow cache. We differentiate = this from flow records because it may include different information than = the flow record (e.g., current flow size vs. final flow size, additional = counters per flow entry that are not exported, etc.). Kind regards Tanja >=20 > Best regards, >=20 > Brian >=20 > On May 26, 2011, at 4:20 PM, Brian Trammell wrote: >=20 > > Hi, Nevil, all, > > > > The following is intended as a WGLC comment on flow-selection-tech. = It > will not be my only one; however, it identifies an issue I've seen in = a cursory > review of the document which I believe could benefit from some = discussion: > > > > Is this document intended to update RFC 5470? I'm not convinced this = is > necessary; e.g. RFC 6235 defines a flow-modifying intermediate = process, and > shows how it could be integrated into various stages within the IPFIX > Architecture, without introducing a new model of how data is handled = in the > architecture. If each additional intermediate process definition = updates the > architecture, the architecture becomes confusing, and subsequently = useless. > > > > If the authors and the WG believe it is necessary to update 5470 to = support > flow selection, I would _strongly_ suggest reviewing all new = terminology, as > the proposed terms collide with existing terms of art in network > measurement. Specifically, there are two serious problems here. First, = I'm > not aware of any use of the word "classification" with respect to the > associating of packets with flows; classification instead seems = primarily to be > used when associating a label with a packet of a flow (e.g., = application > classification). Second, while packets are indeed aggregated into = flows, the > word "aggregation" in this draft is used in a completely different way = than in > either -ipfix-a9n or in RFCs 5982 or 6183. This could lead to = confusion. > > > > More detailed comments to follow. > > > > Best regards, > > > > Brian > > > > On May 24, 2011, at 11:27 PM, Nevil Brownlee wrote: > > > >> > >> Hi all: > >> > >> Thanks very much to all the authors of the flow-selection draft, it > >> does indeed look much better. Since there's so much new material = in > >> it, we need to run a new WG LC on it - that start's today, and will > >> finish on Friday, 10 June. Do please read it anew, and send = comments > >> to the list. Brief comments such as "yes, this looks fine now" are > >> welcome, of course! > >> > >> Cheers, Nevil > >> > >> > >> On 23/05/11 9:30 PM, Zseby, Tanja wrote: > >>> Hi all, > >>> > >>> we worked on a major revision of the flow selection draft and just > submitted a new version (see below). Among other changes we now = provide > a much improved classification of methods, which is more consistent = with the > PSAMP packet selection documents. > >>> Many thanks to all who provided comments. > >>> > >>> Changes: > >>> - Flow recording process removed > >>> - Clarification of difference between flow selection and packet > >>> selection > >>> - Distinguished flow filtering and flow sampling similar to PSAMP > >>> - Flow selection in the metering process either before aggregation > >>> or after aggregation > >>> - Integrated Flow-state dependent packet selection > >>> - Supporting arbitrary key space subsets with property match flow > >>> filtering > >>> - Removed timestamp IEs for reporting > >>> - Mediator integrated in first picture > >>> - Configuration parameters and IEs redefined and re-named > >>> - Many rewording, shortened several paragraphs to improve > >>> readability > >>> > >>> Kind regards > >>> Tanja > >>> > >>> > >>> -----Urspr=FCngliche Nachricht----- > >>> Von: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] Im > >>> Auftrag von internet-drafts@ietf.org > >>> Gesendet: Montag, 23. Mai 2011 11:21 > >>> An: i-d-announce@ietf.org > >>> Cc: ipfix@ietf.org > >>> Betreff: [IPFIX] I-D Action: > >>> draft-ietf-ipfix-flow-selection-tech-06.txt > >>> > >>> 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) : Salvatore D'Antonio > >>> Tanja Zseby > >>> Christian Henke > >>> Lorenzo Peluso > >>> Filename : draft-ietf-ipfix-flow-selection-tech-06.txt > >>> Pages : 25 > >>> Date : 2011-05-23 > >>> > >>> Flow selection is the process of selecting a subset of flows = from all > >>> flows observed at an observation point. Flow selection reduces = the > >>> effort of post-processing flow data and transferring flow = records. > >>> This document describes motivations for flow selection and = presents > >>> flow selection techniques. It provides an information model for > >>> configuring flow selection techniques and discusses what = information > >>> about a flow selection process should be exported. > >>> > >>> > >>> > >>> A URL for this Internet-Draft is: > >>> = http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection- > >>> tech-06.txt > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> This Internet-Draft can be retrieved at: > >>> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-t > >>> ech-06.txt _______________________________________________ > >>> IPFIX mailing list > >>> IPFIX@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ipfix > >>> _______________________________________________ > >>> IPFIX mailing list > >>> IPFIX@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ipfix > >> > >> > >> -- > >> = --------------------------------------------------------------------- > >> 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 > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Tue Jun 7 10:21:30 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41CA11E8072 for ; Tue, 7 Jun 2011 10:21:29 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKWjY+KxhTq0 for ; Tue, 7 Jun 2011 10:21:28 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id E1F4711E817F for ; Tue, 7 Jun 2011 10:21:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A32EFD936C; Tue, 7 Jun 2011 19:21:35 +0200 (MEST) 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 H65XY-SdID9H; Tue, 7 Jun 2011 19:21:35 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (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 44FC3D9324; Tue, 7 Jun 2011 19:21:35 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA1044F5AA2@EXCHSRV.fokus.fraunhofer.de> Date: Tue, 7 Jun 2011 19:21:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110523092128.18082.9981.idtracker@ietfa.amsl.com><804B13F8F3D94A4AB18B9B01ACB68FA1044F55B0@EXCHSRV.fokus.fraunhofer.de><4DDC22C7.6070704@auckland.ac.nz><1E3C6A6E-83BC-4ABC-861E-EF46FC3F0624@tik.ee.ethz.ch> <804B13F8F3D94A4AB18B9B01ACB68FA1044F5AA2@EXCHSRV.fokus.fraunhofer.de> To: "Zseby, Tanja" X-Mailer: Apple Mail (2.1084) Cc: IPFIX Working Group Subject: Re: [IPFIX] New WG Last Call fordraft-ietf-ipfix-flow-selection-tech-06.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 17:21:30 -0000 Hi, Tanja, all, Please see replies inline, as per tradition. :) Cheers, Brian On Jun 7, 2011, at 3:46 PM, Zseby, Tanja wrote: > Hi Brian, >=20 > thanks for summarizing the comments. Please find my answers below >=20 >> 1. As Benoit said, and in refinement of my earlier message, the model = which >> the document uses should be based on an Intermediate (Flow) Selection >> Process (IFSP) as in RFC 6183, instead of adding new concepts to = 5470. The >> case in section 4.1 is a bit of a special one, to address an uncommon >> requirement; in addition, it isn't really a flow selection process at = all, but >> rather a packet selection process that selects packets on the same = criteria >> that by which packets are separated into flows by the flow key. = Therefore it >> can be noted here, I think, that the _function_ run within an IFSP = can run _as >> a packet selection process_ before flow generation within an MP = without >> having to hack new processes into the 5470 model. Section 6 will have = to be >> updated a bit to fit this change as well. >=20 > I did not see the aggregation and classification process as = contradiction to RFC 5470, just as a more detailed/fine grained view on = processes that are needed inside the metering process to generate flow = records from packets. I think we need this more fine grained view to = describe the different flow selection processes. > We can try to align with the Intermediate Process in RFC6183, but the = definition in RFC6183 requires a record stream as input which is not the = case in 4.1. (as you point out) and also not the case if you apply the = method on flow cache entries (which may contain different information = than the final flow record). In those cases the flow selection takes = place _within_ the metering process, before a record is generated. So we = probably would also violate the RFC6183 definition. So I'd suggest the following: for _flow_ selection, define a Flow = Selection Intermediate Process, in terms of 6183. For _packet_ selection = (as in section 4.1) which has an effect on the produced flow stream, = define it in terms of 5474. Updating 5470 as in the present revision of = the draft implies that _all_ 5470-compliant IPFIX devices should be flow = selection compliant. Given the limited applicability of section 4.1, = this seems like a bad idea to me. >> 2. The document should use a different term for "aggregation" (of = packets >> into flows) to avoid collision with terminology related to = aggregation in RFCs >> 5982 and 6183. >=20 > Maybe we can use "packet aggregation" to make it clear? >=20 >>=20 >> 3. The document should use a different term for "classification" to = avoid >> confusion with the use of this term with respect to "flow = classification" and >> labeling. I realize 5470 uses the verb "classify" to refer to this = process; I really >> wish it didn't. >=20 > I think that both terms, aggregation and classification, are correct = here to describe the processes. It is just another entity (packets = instead of flows) that is classified or aggregated. So maybe we can use = "packet classification " and "packet aggregation"? Yep, this would clear it up. >>=20 >> Aggregation and classification _together_ comprise the "assignment" = of >> packets to flows, and flow "generation". I'm afraid I don't have any = better >> suggestions at this time. >=20 > This is exactly my understanding. >=20 >>=20 >> 4. Terminology based on terminology borrowed by analogy or reference = to >> the packet selection techniques draft is a good idea; however, these = terms >> should be defined in section . >=20 > To which terms do you refer to? In which section? The techniques described in subsections of section 5; these should = probably be introduced in the terminology. >> Additionally, terminology through the entire >> document should be reviewed for proper capitalization. >=20 > o.k. >=20 >>=20 >> 5. Within section 6, it is not clear how to apply this configuration = data model. >> Should this be harmonized with ipfix-configuration-model? >=20 > Yes, it shoudl be possible to use this as basis, like PASMP-TECH. = Should we just reference to the config-model or do you suggest any = further alignment? Since configuration per the configuration-model draft is done with YANG = for NETCONF-compatibility, I think this should be handled as a model = extension, with YANG defined for it. I'm neither a YANG nor a NETCONF = expert; perhaps someone with more experience could pop in and say = whether my suggestion makes any sense. :) >> 6. In section 7, I would suggest unifying Paul and Benoit's comments = on the >> subject of fsFlowRecordTotalCount; additionally, the IE should be = named >> flowDeltaCount to keep parallel with IEs 1 and 2. Consider renaming = the IEs in >> general to drop the "fs" prefix. perhaps "postSelection" or something = similar >> (as with the pre/post IEs). Review other IEs to ensure they are not = covered >> by existing IEs (especially those "pre-selection", as with IE 3) >>=20 >=20 > We used fs in order to clarify that this refers to the flow records as = seen as input by the selection process. The values may differ e.g. if we = cascade multiple subsequent flow selection processes.=20 > Wrt to delta counters I am unsure. We want to have the total records = for the interval that is used for the selection process. This might = differ from the reporting interval. So if we use the term deltaCount it = refers to the reporting interval. We need to have a further look into = this. The real question here is whether the flow record count should be = represented by the v9-compatible IE 3,=20 >> 7. What is a Flow Entry? Should this be defined in this document, or >> referenced as terminology from another? If this is what I think it is = (reporting >> flow cache size inline), I'm not certain it belongs here in flow = selection >> (perhaps in a document on metering process monitoring?). >=20 > With flow entry we mean an entry in the flow cache. We differentiate = this from flow records because it may include different information than = the flow record (e.g., current flow size vs. final flow size, additional = counters per flow entry that are not exported, etc.). Okay... if it's referred to in the descriptions of the Information = Elements, it should probably be defined as terminology. >>=20 >> On May 26, 2011, at 4:20 PM, Brian Trammell wrote: >>=20 >>> Hi, Nevil, all, >>>=20 >>> The following is intended as a WGLC comment on flow-selection-tech. = It >> will not be my only one; however, it identifies an issue I've seen in = a cursory >> review of the document which I believe could benefit from some = discussion: >>>=20 >>> Is this document intended to update RFC 5470? I'm not convinced this = is >> necessary; e.g. RFC 6235 defines a flow-modifying intermediate = process, and >> shows how it could be integrated into various stages within the IPFIX >> Architecture, without introducing a new model of how data is handled = in the >> architecture. If each additional intermediate process definition = updates the >> architecture, the architecture becomes confusing, and subsequently = useless. >>>=20 >>> If the authors and the WG believe it is necessary to update 5470 to = support >> flow selection, I would _strongly_ suggest reviewing all new = terminology, as >> the proposed terms collide with existing terms of art in network >> measurement. Specifically, there are two serious problems here. = First, I'm >> not aware of any use of the word "classification" with respect to the >> associating of packets with flows; classification instead seems = primarily to be >> used when associating a label with a packet of a flow (e.g., = application >> classification). Second, while packets are indeed aggregated into = flows, the >> word "aggregation" in this draft is used in a completely different = way than in >> either -ipfix-a9n or in RFCs 5982 or 6183. This could lead to = confusion. >>>=20 >>> More detailed comments to follow. >>>=20 >>> Best regards, >>>=20 >>> Brian >>>=20 >>> On May 24, 2011, at 11:27 PM, Nevil Brownlee wrote: >>>=20 >>>>=20 >>>> Hi all: >>>>=20 >>>> Thanks very much to all the authors of the flow-selection draft, it >>>> does indeed look much better. Since there's so much new material = in >>>> it, we need to run a new WG LC on it - that start's today, and will >>>> finish on Friday, 10 June. Do please read it anew, and send = comments >>>> to the list. Brief comments such as "yes, this looks fine now" are >>>> welcome, of course! >>>>=20 >>>> Cheers, Nevil >>>>=20 >>>>=20 >>>> On 23/05/11 9:30 PM, Zseby, Tanja wrote: >>>>> Hi all, >>>>>=20 >>>>> we worked on a major revision of the flow selection draft and just >> submitted a new version (see below). Among other changes we now = provide >> a much improved classification of methods, which is more consistent = with the >> PSAMP packet selection documents. >>>>> Many thanks to all who provided comments. >>>>>=20 >>>>> Changes: >>>>> - Flow recording process removed >>>>> - Clarification of difference between flow selection and packet >>>>> selection >>>>> - Distinguished flow filtering and flow sampling similar to PSAMP >>>>> - Flow selection in the metering process either before aggregation >>>>> or after aggregation >>>>> - Integrated Flow-state dependent packet selection >>>>> - Supporting arbitrary key space subsets with property match flow >>>>> filtering >>>>> - Removed timestamp IEs for reporting >>>>> - Mediator integrated in first picture >>>>> - Configuration parameters and IEs redefined and re-named >>>>> - Many rewording, shortened several paragraphs to improve >>>>> readability >>>>>=20 >>>>> Kind regards >>>>> Tanja >>>>>=20 >>>>>=20 >>>>> -----Urspr=FCngliche Nachricht----- >>>>> Von: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] Im >>>>> Auftrag von internet-drafts@ietf.org >>>>> Gesendet: Montag, 23. Mai 2011 11:21 >>>>> An: i-d-announce@ietf.org >>>>> Cc: ipfix@ietf.org >>>>> Betreff: [IPFIX] I-D Action: >>>>> draft-ietf-ipfix-flow-selection-tech-06.txt >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Title : Flow Selection Techniques >>>>> Author(s) : Salvatore D'Antonio >>>>> Tanja Zseby >>>>> Christian Henke >>>>> Lorenzo Peluso >>>>> Filename : draft-ietf-ipfix-flow-selection-tech-06.txt >>>>> Pages : 25 >>>>> Date : 2011-05-23 >>>>>=20 >>>>> Flow selection is the process of selecting a subset of flows from = all >>>>> flows observed at an observation point. Flow selection reduces = the >>>>> effort of post-processing flow data and transferring flow = records. >>>>> This document describes motivations for flow selection and = presents >>>>> flow selection techniques. It provides an information model for >>>>> configuring flow selection techniques and discusses what = information >>>>> about a flow selection process should be exported. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> A URL for this Internet-Draft is: >>>>> = http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection- >>>>> tech-06.txt >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> This Internet-Draft can be retrieved at: >>>>> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-t >>>>> ech-06.txt _______________________________________________ >>>>> IPFIX mailing list >>>>> IPFIX@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>> _______________________________________________ >>>>> IPFIX mailing list >>>>> IPFIX@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>=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 >>>=20 >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >>=20 >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Mon Jun 13 08:03:52 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101E621F849F for ; Mon, 13 Jun 2011 08:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOl+t5pKqmMh for ; Mon, 13 Jun 2011 08:03:51 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1425021F844D for ; Mon, 13 Jun 2011 08:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1788; q=dns/txt; s=iport; t=1307977431; x=1309187031; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=WyUa7DvnnMNZJ6L7fm+A9NhSYZ7zZTSFz5HN6p5aGsc=; b=C/EBpGCLKg0SKIi4pivR0LGkhz670jupqd0rpIQm6R3ZMtaj9innQNL7 QKrYidUoMJFDFzooav8Ubq7VdxAV6dZCJsgFvAybHroU7Z+p+gBBmmqdJ 6co7siJBM8KRxAkeyePWBDEYA3UGgWN0YlassDLWszvdW+OMoN81Hi3LK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIcl9k2Q/khR/2dsb2JhbABSpjl3qTqBH51EhiQEkTSET4sP X-IronPort-AV: E=Sophos;i="4.65,359,1304294400"; d="scan'208";a="93709771" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 13 Jun 2011 15:03:50 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5DF3jXj017519 for ; Mon, 13 Jun 2011 15:03:45 GMT Received: from [144.254.153.42] (dhcp-144-254-153-42.cisco.com [144.254.153.42]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p5DF3epc021449 for ; Mon, 13 Jun 2011 16:03:44 +0100 (BST) Message-ID: <4DF626E8.80606@cisco.com> Date: Mon, 13 Jun 2011 16:04:08 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] new IPFIX fields for traffic classification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 15:03:52 -0000 Dear IPFIX experts, Cisco would like to define some new IPFIX fields for traffic classification so we can attach classification information to each exported flow. Unlike many other fields, we don't propose to encode these fields numerically, so the usual option table mapping numbers to names won't be necessary. Instead, these fields would contain strings. Each field would be extensible so new strings could be added in future. In fact, we expect this to be a regular occurrence as new classifications are defined. However, it's not desirable - and perhaps not even possible - to list all the classification values. So there won't be any complete or exhaustive value list for any of these fields, and IANA won't maintain a registry for each field. This is similar to the existing wlanSSID, interfaceName and VRFname fields: while we can define the purpose of these fields, the values cannot be listed exhaustively. These can only be defined as generic strings, and no attempt should be made to register all the possible values. While we've already defined enterprise-specific fields, we feel these fields will be generally useful to the community. Nevil has asked for discussion before approving our request for new IANA field allocations. So, please discuss... ;-) Specifically, the fields which we'd like to define are: * Category = a protocol attribute which broadly groups a set of protocols having the same characteristic. e.g. file-sharing, email. * Sub-category = a second level category attribute e.g. p2p-file-transfer, gmail * Application-group = a protocol attribute which groups a set of protocols belonging to same application. e.g. ftp-group Cheers, P. From trammell@tik.ee.ethz.ch Mon Jun 13 08:22:40 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40FF21F84A2 for ; Mon, 13 Jun 2011 08:22:40 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34mBYN7l8DSB for ; Mon, 13 Jun 2011 08:22:40 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id EFCED21F8493 for ; Mon, 13 Jun 2011 08:22:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D8F92D9324; Mon, 13 Jun 2011 17:22:51 +0200 (MEST) 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 l1Rwlpd89EHB; Mon, 13 Jun 2011 17:22:51 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (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 76551D931C; Mon, 13 Jun 2011 17:22:51 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4DF626E8.80606@cisco.com> Date: Mon, 13 Jun 2011 17:22:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <73F44306-67AE-4776-95EE-224BB8D63275@tik.ee.ethz.ch> References: <4DF626E8.80606@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1084) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] new IPFIX fields for traffic classification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 15:22:40 -0000 Hi, Paul, A suggestion: if these are encoded in strings, why not specify a = delimiter-separated ID space and have a single flowClassification string = with this delimiter separated space. IE "flowClassification" =3D "email.gmail", "ftp-group.ftp-data" and so = on? This would allow sub-sub-sub categories, as well = ("voip.skype.datachannel.noudp.v5") Cheers, Brian On Jun 13, 2011, at 5:04 PM, Paul Aitken wrote: > Dear IPFIX experts, >=20 > Cisco would like to define some new IPFIX fields for traffic = classification so we can attach classification information to each = exported flow. >=20 > Unlike many other fields, we don't propose to encode these fields = numerically, so the usual option table mapping numbers to names won't be = necessary. >=20 > Instead, these fields would contain strings. Each field would be = extensible so new strings could be added in future. In fact, we expect = this to be a regular occurrence as new classifications are defined. >=20 > However, it's not desirable - and perhaps not even possible - to list = all the classification values. So there won't be any complete or = exhaustive value list for any of these fields, and IANA won't maintain a = registry for each field. >=20 > This is similar to the existing wlanSSID, interfaceName and VRFname = fields: while we can define the purpose of these fields, the values = cannot be listed exhaustively. These can only be defined as generic = strings, and no attempt should be made to register all the possible = values. >=20 > While we've already defined enterprise-specific fields, we feel these = fields will be generally useful to the community. Nevil has asked for = discussion before approving our request for new IANA field allocations. >=20 > So, please discuss... ;-) >=20 >=20 > Specifically, the fields which we'd like to define are: >=20 > * Category =3D a protocol attribute which broadly groups a set of = protocols having the same characteristic. > e.g. file-sharing, email. >=20 > * Sub-category =3D a second level category attribute > e.g. p2p-file-transfer, gmail >=20 > * Application-group =3D a protocol attribute which groups a set of = protocols belonging to same application. > e.g. ftp-group >=20 >=20 > Cheers, > P. >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From inacio@cert.org Mon Jun 13 08:45:24 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB3D11E80DF for ; Mon, 13 Jun 2011 08:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrMUauysslQj for ; Mon, 13 Jun 2011 08:45:23 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 125A811E80E1 for ; Mon, 13 Jun 2011 08:45:23 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1294) with ESMTP id p5DFjDHJ003663; Mon, 13 Jun 2011 11:45:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1307979913; bh=gg3dOepQLKDyeUPya3w3SHh3DTf7aJ/LDV7ZOnZgEoA=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=Pef5nbAzzUIMq+RJQL7XIDh3ECDQ/Om+M/mdG2A53m6XvPlHnWwNcI3mDIo2yNwsQ CpdHK8+mZeiPaWFqUuQ7Mb6UsUZsHlo2vAdkvF0WfXeo3C/PA3qVIye7FGCRtWo2q3 wructPcq13faZ0vXfo17o5uo9s7szTqg3oOXhzK0= Received: from owa.sei.cmu.edu (vader.sei.cmu.edu [10.64.28.14]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1348) with ESMTP id p5DFjCQq019675; Mon, 13 Jun 2011 11:45:13 -0400 Received: from EXCHANGE.sei.cmu.edu ([10.64.28.12]) by vader.sei.cmu.edu ([10.64.28.14]) with mapi; Mon, 13 Jun 2011 11:45:12 -0400 From: Chris Inacio To: Brian Trammell Date: Mon, 13 Jun 2011 11:45:14 -0400 Thread-Topic: [IPFIX] new IPFIX fields for traffic classification Thread-Index: Acwp4ODhrSFAxksQTqifdHKM3QlJHQ== Message-ID: <9D1F34B6-9254-4FC4-8745-31653B533A87@cert.org> References: <4DF626E8.80606@cisco.com> <73F44306-67AE-4776-95EE-224BB8D63275@tik.ee.ethz.ch> In-Reply-To: <73F44306-67AE-4776-95EE-224BB8D63275@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] new IPFIX fields for traffic classification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 15:45:24 -0000 On Jun 13, 2011, at 11:22 AM, Brian Trammell wrote: > Hi, Paul, >=20 > A suggestion: if these are encoded in strings, why not specify a delimite= r-separated ID space and have a single flowClassification string with this = delimiter separated space. >=20 > IE "flowClassification" =3D "email.gmail", "ftp-group.ftp-data" and so on= ? >=20 > This would allow sub-sub-sub categories, as well ("voip.skype.datachannel= .noudp.v5") >=20 > Cheers, >=20 > Brian >=20 I have a lot more to say down below; but I agree with Brian. If there is a= desire to start using string fields like this in the protocol, then I thin= k having some structure in the strings that allows them to be somewhat hier= archal maybe, would be wise. > On Jun 13, 2011, at 5:04 PM, Paul Aitken wrote: >=20 >> Dear IPFIX experts, >>=20 >> Cisco would like to define some new IPFIX fields for traffic classificat= ion so we can attach classification information to each exported flow. >>=20 >> Unlike many other fields, we don't propose to encode these fields numeri= cally, so the usual option table mapping numbers to names won't be necessar= y. >>=20 >> Instead, these fields would contain strings. Each field would be extensi= ble so new strings could be added in future. In fact, we expect this to be = a regular occurrence as new classifications are defined. >>=20 >> However, it's not desirable - and perhaps not even possible - to list al= l the classification values. So there won't be any complete or exhaustive v= alue list for any of these fields, and IANA won't maintain a registry for e= ach field. >>=20 >> This is similar to the existing wlanSSID, interfaceName and VRFname fiel= ds: while we can define the purpose of these fields, the values cannot be l= isted exhaustively. These can only be defined as generic strings, and no at= tempt should be made to register all the possible values. >>=20 >> While we've already defined enterprise-specific fields, we feel these fi= elds will be generally useful to the community. Nevil has asked for discuss= ion before approving our request for new IANA field allocations. >>=20 >> So, please discuss... ;-) >>=20 >>=20 >> Specifically, the fields which we'd like to define are: >>=20 >> * Category =3D a protocol attribute which broadly groups a set of prot= ocols having the same characteristic. >> e.g. file-sharing, email. >>=20 >> * Sub-category =3D a second level category attribute >> e.g. p2p-file-transfer, gmail >>=20 >> * Application-group =3D a protocol attribute which groups a set of pro= tocols belonging to same application. >> e.g. ftp-group >>=20 >>=20 >> Cheers, >> P. Why would you (being Cisco) want to use strings? =20 There are the obvious downsides to table mappings: have to have some type o= f out-of-band mechanism to distribute them, or define some new options reco= rds that allows them to be distributed. If not sending them from probe to = collector, then you need a central registry. The consensus mechanism of th= e central repository is too slow, strings are agile. Strings more easily a= llow ``quiet-mode'' before introducing a product to market, making the suit= s happy, by eliminating the central repository. I understand that these ar= e all problems, but I would argue these are still better problems to have t= han having strings. =20 The problem with strings: The model without a central repository means eve= ryone developing their own strings, mostly incompatible ones. (The collect= or will then have to guess that Cisco's "email:mua" is the same as my "smtp= :user-agent". Or push the problem back up to the user.) Strings are a lot= less efficient. IPFIX's design is clearly architected to bandwidth reduct= ion by sending the type-length information very infrequently, and including= reduced length encoding - strings are not bandwidth friendly. I would still argue for a bandwidth efficient interoperable protocol. I do= n't think adding strings would create an interoperable protocol. So that said, what I would ask of you Paul, is to describe the why's that m= ake this string mapping so attractive? (Although if we can all figure out how to get bonuses from our respective e= mployers for writing RFC's, we can start working on the SIP protocol model = to define the strings, and I'm fully on board! :) ) Best regards, Chris Inacio >>=20 >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Tue Jun 14 03:04:04 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD31521F85DA for ; Tue, 14 Jun 2011 03:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqOQzStorGqG for ; Tue, 14 Jun 2011 03:04:04 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 650F121F85D5 for ; Tue, 14 Jun 2011 03:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=5725; q=dns/txt; s=iport; t=1308045843; x=1309255443; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=yXidkrqMKzkL2EkmT+0NDmgg6dyONU4AV7bOXRXGH3E=; b=NFYUWSRE97LIbumMW+qyYkecV3l/4BDdDVVgNGQSFMuXeHBnWj1wMT+J J6OyZrUWm4bBv6ZJ4vzHGkv8wdVk7jqpJ9AqxuflSEKPXALlUn7iGQeH1 SI7cRBjDIA/o1ROmmOwhWFl/LoJtBCyXns2cNPg4NtlXUh+F4B9ZWF1/r I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAL8w902Q/khM/2dsb2JhbABSpjd3qhmeL4YkBJFHhFeLDw X-IronPort-AV: E=Sophos;i="4.65,363,1304294400"; d="scan'208";a="93856294" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 14 Jun 2011 10:03:53 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5EA3rm3015872; Tue, 14 Jun 2011 10:03:53 GMT Received: from [10.61.100.192] (dhcp-10-61-100-192.cisco.com [10.61.100.192]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p5EA3pGO019133; Tue, 14 Jun 2011 11:03:51 +0100 (BST) Message-ID: <4DF73207.1060700@cisco.com> Date: Tue, 14 Jun 2011 11:03:51 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Chris Inacio References: <4DF626E8.80606@cisco.com> <73F44306-67AE-4776-95EE-224BB8D63275@tik.ee.ethz.ch> <9D1F34B6-9254-4FC4-8745-31653B533A87@cert.org> In-Reply-To: <9D1F34B6-9254-4FC4-8745-31653B533A87@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] new IPFIX fields for traffic classification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 10:04:04 -0000 Chris, We've been asked to export strings coming from a classification engine. We need an extensible scheme which allows the classification team to export their information with zero intervention from us or from any external registry maintainer as they add new classifications. An ID-based export has multiple disadvantages as you list below - not least of which is that it stalls the dev/rel cycle while new IDs are requested from the registry maintainer (say, IANA). Most importantly, there can be no central registry for on-box user-defined classifications. The main disadvantages of exporting the strings directly are bandwidth and interoperability. However, the main advantage is that new classifications can be exported immediately. Since we're exporting the strings in enterprise-specific IDs, there's essentially no interoperability (unless others also export cisco PEN IDs - which is unwise). Interoperability and bandwidth would both be improved by moving to IANA elements. Cheers, P. On 13/06/11 16:45, Chris Inacio wrote: > On Jun 13, 2011, at 11:22 AM, Brian Trammell wrote: > >> Hi, Paul, >> >> A suggestion: if these are encoded in strings, why not specify a delimiter-separated ID space and have a single flowClassification string with this delimiter separated space. >> >> IE "flowClassification" = "email.gmail", "ftp-group.ftp-data" and so on? >> >> This would allow sub-sub-sub categories, as well ("voip.skype.datachannel.noudp.v5") >> >> Cheers, >> >> Brian >> > I have a lot more to say down below; but I agree with Brian. If there is a desire to start using string fields like this in the protocol, then I think having some structure in the strings that allows them to be somewhat hierarchal maybe, would be wise. > > >> On Jun 13, 2011, at 5:04 PM, Paul Aitken wrote: >> >>> Dear IPFIX experts, >>> >>> Cisco would like to define some new IPFIX fields for traffic classification so we can attach classification information to each exported flow. >>> >>> Unlike many other fields, we don't propose to encode these fields numerically, so the usual option table mapping numbers to names won't be necessary. >>> >>> Instead, these fields would contain strings. Each field would be extensible so new strings could be added in future. In fact, we expect this to be a regular occurrence as new classifications are defined. >>> >>> However, it's not desirable - and perhaps not even possible - to list all the classification values. So there won't be any complete or exhaustive value list for any of these fields, and IANA won't maintain a registry for each field. >>> >>> This is similar to the existing wlanSSID, interfaceName and VRFname fields: while we can define the purpose of these fields, the values cannot be listed exhaustively. These can only be defined as generic strings, and no attempt should be made to register all the possible values. >>> >>> While we've already defined enterprise-specific fields, we feel these fields will be generally useful to the community. Nevil has asked for discussion before approving our request for new IANA field allocations. >>> >>> So, please discuss... ;-) >>> >>> >>> Specifically, the fields which we'd like to define are: >>> >>> * Category = a protocol attribute which broadly groups a set of protocols having the same characteristic. >>> e.g. file-sharing, email. >>> >>> * Sub-category = a second level category attribute >>> e.g. p2p-file-transfer, gmail >>> >>> * Application-group = a protocol attribute which groups a set of protocols belonging to same application. >>> e.g. ftp-group >>> >>> >>> Cheers, >>> P. > Why would you (being Cisco) want to use strings? > > There are the obvious downsides to table mappings: have to have some type of out-of-band mechanism to distribute them, or define some new options records that allows them to be distributed. If not sending them from probe to collector, then you need a central registry. The consensus mechanism of the central repository is too slow, strings are agile. Strings more easily allow ``quiet-mode'' before introducing a product to market, making the suits happy, by eliminating the central repository. I understand that these are all problems, but I would argue these are still better problems to have than having strings. > > > The problem with strings: The model without a central repository means everyone developing their own strings, mostly incompatible ones. (The collector will then have to guess that Cisco's "email:mua" is the same as my "smtp:user-agent". Or push the problem back up to the user.) Strings are a lot less efficient. IPFIX's design is clearly architected to bandwidth reduction by sending the type-length information very infrequently, and including reduced length encoding - strings are not bandwidth friendly. > > I would still argue for a bandwidth efficient interoperable protocol. I don't think adding strings would create an interoperable protocol. > > So that said, what I would ask of you Paul, is to describe the why's that make this string mapping so attractive? > > (Although if we can all figure out how to get bonuses from our respective employers for writing RFC's, we can start working on the SIP protocol model to define the strings, and I'm fully on board! :) ) > > > Best regards, > Chris Inacio > > > >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Tue Jun 14 03:04:21 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D6321F85DE for ; Tue, 14 Jun 2011 03:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dc0HgvQS-1DY for ; Tue, 14 Jun 2011 03:04:20 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4030C21F85D5 for ; Tue, 14 Jun 2011 03:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=2612; q=dns/txt; s=iport; t=1308045860; x=1309255460; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=zGl5R0qYh5ZR7VZuz7gnO0GwE2Jj9ZVfAR4NWeUimWg=; b=KJM5XxFcKr0dg9+543GnsBK9HnFHLWxa0+AfJ+7FicU/lN25GoZxKWhq 2GHhsrEF1e26qlZ0HMy2D/e72xl4uhI6IiKe8mgoGEBrOwRcJ9yAhWZ0a RljU63VEGzniAkjgdSVKH3IgzAyUI/L7En/INg3gzJyzkzehYB/znqmG0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALsx902Q/khM/2dsb2JhbABSpjd3qiueL4YkBJFHhFeLDw X-IronPort-AV: E=Sophos;i="4.65,363,1304294400"; d="scan'208";a="35130401" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 14 Jun 2011 10:04:14 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5EA4DRd016034; Tue, 14 Jun 2011 10:04:14 GMT Received: from [10.61.100.192] (dhcp-10-61-100-192.cisco.com [10.61.100.192]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p5EA48tX019150; Tue, 14 Jun 2011 11:04:09 +0100 (BST) Message-ID: <4DF73218.3050105@cisco.com> Date: Tue, 14 Jun 2011 11:04:08 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Brian Trammell References: <4DF626E8.80606@cisco.com> <73F44306-67AE-4776-95EE-224BB8D63275@tik.ee.ethz.ch> In-Reply-To: <73F44306-67AE-4776-95EE-224BB8D63275@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] new IPFIX fields for traffic classification X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 10:04:22 -0000 Brian, Hierarchical sub-classification is essentially the direction we're going with draft-claise-export-application-info-in-ipfix. P. On 13/06/11 16:22, Brian Trammell wrote: > Hi, Paul, > > A suggestion: if these are encoded in strings, why not specify a delimiter-separated ID space and have a single flowClassification string with this delimiter separated space. > > IE "flowClassification" = "email.gmail", "ftp-group.ftp-data" and so on? > > This would allow sub-sub-sub categories, as well ("voip.skype.datachannel.noudp.v5") > > Cheers, > > Brian > > On Jun 13, 2011, at 5:04 PM, Paul Aitken wrote: > >> Dear IPFIX experts, >> >> Cisco would like to define some new IPFIX fields for traffic classification so we can attach classification information to each exported flow. >> >> Unlike many other fields, we don't propose to encode these fields numerically, so the usual option table mapping numbers to names won't be necessary. >> >> Instead, these fields would contain strings. Each field would be extensible so new strings could be added in future. In fact, we expect this to be a regular occurrence as new classifications are defined. >> >> However, it's not desirable - and perhaps not even possible - to list all the classification values. So there won't be any complete or exhaustive value list for any of these fields, and IANA won't maintain a registry for each field. >> >> This is similar to the existing wlanSSID, interfaceName and VRFname fields: while we can define the purpose of these fields, the values cannot be listed exhaustively. These can only be defined as generic strings, and no attempt should be made to register all the possible values. >> >> While we've already defined enterprise-specific fields, we feel these fields will be generally useful to the community. Nevil has asked for discussion before approving our request for new IANA field allocations. >> >> So, please discuss... ;-) >> >> >> Specifically, the fields which we'd like to define are: >> >> * Category = a protocol attribute which broadly groups a set of protocols having the same characteristic. >> e.g. file-sharing, email. >> >> * Sub-category = a second level category attribute >> e.g. p2p-file-transfer, gmail >> >> * Application-group = a protocol attribute which groups a set of protocols belonging to same application. >> e.g. ftp-group >> >> >> Cheers, >> P. >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From Thomas.Dietz@neclab.eu Thu Jun 16 02:57:57 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC55411E8106 for ; Thu, 16 Jun 2011 02:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.083 X-Spam-Level: X-Spam-Status: No, score=-0.083 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAAT3tWxnNl0 for ; Thu, 16 Jun 2011 02:57:57 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id DC7DB11E8094 for ; Thu, 16 Jun 2011 02:57:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 419922800039F; Thu, 16 Jun 2011 11:57:56 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cdXx+T01reI; Thu, 16 Jun 2011 11:57:56 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 1D4F0280003A6; Thu, 16 Jun 2011 11:57:46 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.115]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Thu, 16 Jun 2011 11:57:40 +0200 From: Thomas Dietz To: "Romascanu, Dan (Dan)" , IPFIX Working Group Thread-Topic: AD review of draft-ietf-ipfix-psamp-mib-03.txt Thread-Index: AcwgRVpKL+rIVnCXROu/usNykoC0lgLxh9LQ Date: Thu, 16 Jun 2011 09:57:40 +0000 Message-ID: <75581E268A48F849916117B977D76D37240524BA@Polydeuces.office.hd> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.10] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003E_01CC2C1C.97323C20" MIME-Version: 1.0 Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-psamp-mib-03.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 09:57:57 -0000 ------=_NextPart_000_003E_01CC2C1C.97323C20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Dan, I am currently editing the new version of the PSAMP MIB addressing your review comment. Please also find some comments inline in this mail. -- Thomas Dietz NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 Heidelberg, Germany NEC Europe Limited, Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: Wednesday, June 01, 2011 12:19 PM > To: IPFIX Working Group > Subject: [IPFIX] AD review of draft-ietf-ipfix-psamp-mib-03.txt > > > > Hi, > > I have performed the AD review of draft-ietf-ipfix-psamp-mib-03.txt. > This document is in good shape and I am sending it to IETF Last Call. > Please address the comments below together with the other IETF LC > comments. > > The technical comments are marked T and the editorial comments are > marked E. > > T1. > > Float64TC > FROM FLOAT-TC-MIB -- draft-ietf-opsawg-mib-float > > Actually will need to be published before or simultaneously with this > document, in order to satisfy the normative reference. Leaving > draft-ietf-opsawg-mib-float would be confusing, we need the RFC number > here. I suggest to include here (as a comment) a note to the RFC Editor > that mentions that draft-ietf-opsawg-mib-float is to be replaced with > the RFC number of that document, and the note deleted. > Done. > T2. Why do psampSampCountBasedAvail, psampSampTimeBasedAvail, > psampSampRandOutOfNAvail, psampSampUniProbAvail, > psampFiltPropMatchAvail, psampFiltHashAvail have DEFVAL clauses? These > are read-only objects, so the values must be configured by some other > means (not by SNMP) and just read by the agent. > The values depend on what the manufacturer of the equipment has implemented in his hard- or software. So basically a DEFVAL cannot be given here. > T3. There is no need to include the following in the IANA considerations > section: > > psampSampCountBased { ipfixSelectorFunctions 2 } > psampSampTimeBased { ipfixSelectorFunctions 3 } > psampSampRandOutOfN { ipfixSelectorFunctions 4 } > psampSampUniProb { ipfixSelectorFunctions 5 } > psampFiltPropMatch { ipfixSelectorFunctions 6 } > psampFiltHash { ipfixSelectorFunctions 7 } > > These are already assigned in the MIB module and no IANA action is > required for them. > > Done. Best Regards, Thomas > E1. The contents of sections 3 and 4 are similar, but the formatting of > the texts in the two sections is different. I suggest to fix this using > for section 4 the same format as in section 3, which is easier to read. > > E2. Page 5 - second paragraph s/as defiend/as defined/ > > E3. Please explain the meaning of each enumerated value in the > DESCRIPTION clause of psampFiltHashFunction > > E4. Please detail the 'corresponding sampling function' in the > DESCRIPTION clause of each one of the conformance groups under > MODULE-COMPLIANCE. > > > Thanks and Regards, > > Dan > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix ------=_NextPart_000_003E_01CC2C1C.97323C20 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNDCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFNTCCBB2gAwIBAgIED+0gWzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0xMDA0MjAxMjQ5MTVaFw0xMzA0MTkxMjQ5MTVaMGAx CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQD2mMcvPbgraEaWMV6uNCs6t88lhBczgfxybD46mwr8D3VaQLEnqTsBOAf/ Y8ARtq+P6Dkm2MBMXQG+Ebo2qhif6O4dH7whcG9E88F9247R2EJjcXmxMYZWYGQTI2vGw/joerRB waiwfxCXWBTLutbdWEEKL/DG9A1yQRPGJc+jJYfgm0ekYn+WESOLYaBH7G9aIIZQ7en3afhPpbQA Ajh92K240TG+VgBpe1vnDdth28Ps5XeN+otookDZHwwGQYwYrPZJtnhGIyjKMm7OkXL62Rf3aSoI doVUwYYS67RYYNOY0C7qOVyCUF+z4Bkn758sZhZzotiLQVT3AZ625PrvAgMBAAGjggHEMIIBwDAJ BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFH9fxgi2EshupgLF49SzaAX0QFoMMB8GA1UdIwQYMBaAFE8ch3od 4C+Z9r4VqtE1nQ5K5ro2MCEGA1UdEQQaMBiBFlRob21hcy5EaWV0ekBuZWNsYWIuZXUwfQYDVR0f BHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNy bC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2Fj cmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRm bi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8v Y2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN AQEFBQADggEBACnPHI1mIY1TVY9Aj8zsHHxiwMRx02Hp6DLZGYXHGG9IkflrRKNiDIV2LbBDpXVH vojMxTtCt10iwbyVMGaevet/VHYCJSHzrCLkw+GkvuhDU70lNsWw9P+mai7OHa+NQ6im8+4RnY1B yhqidcCt3hIV9B69ax0/KIhIFpiWz/lKZVIghki07I4m8mf1sbvCORKxudH0TVLlRJlX1r8S+8ea 9e+Q8pgXfrsCeyxBV3KAjszRQkqDZsbD7jQHQWokkMPIjbaTjw6V/5SRzmcAy0XlKNOCbldlzmCB jDZTQWdSH/AFDy5L2l4j0Ck0vVlQv+r1F4omsb4BelRq+vHd+lExggQ4MIIENAIBATCBmTCBkDEL MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzAJBgUrDgMCGgUAoIICczAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA2MTYwOTU3MzlaMCMGCSqGSIb3 DQEJBDEWBBQvirrAw4uCtHuhaohaSllsURjgczCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQswCQYD VQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9y aWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemll cnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQP7SBbMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCBkDEL MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzCBtwYJKoZIhvcNAQkPMYGpMIGmMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3 DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAL BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG 9w0BAQEFAASCAQD0dfzebOCWm9XDh12Rlc6QswejyanLj80ZuRzX+sVsbcnocmgYTFC9wBnln9es bV4fCLH0qKt97RXbM/yy8F+0LC1jGF34YydKDZQDni2J5+iVHH9OoQLD2iosrUoRKVKkuSI/k9Yf Vv/4z05/2JUQdUTeSdQ1WzIOPIm5z3B+exkLoLBTeNHI4U1R+4z/79FeYo0K/26lMWTfWBmq1TYf mcgL7pC68Li+fqFs+nNP/+zFjwdezXApGbHIWefpdozEOosoQukMNfVCdfaPJXYX6kCaIRvSDdRX b2OzGsc+gNW3jnH/MmwVvCmcldrUpU2sVcdld8KVLRhr+VymZhRtAAAAAAAA ------=_NextPart_000_003E_01CC2C1C.97323C20-- From Thomas.Dietz@neclab.eu Thu Jun 16 03:00:30 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE48911E8106 for ; Thu, 16 Jun 2011 03:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.083 X-Spam-Level: X-Spam-Status: No, score=-0.083 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCTbevEi1lLQ for ; Thu, 16 Jun 2011 03:00:30 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id D5F4E11E8094 for ; Thu, 16 Jun 2011 03:00:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3F009280003A6; Thu, 16 Jun 2011 12:00:29 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52ukjYwRV1Zz; Thu, 16 Jun 2011 12:00:29 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 1EACF2800039F; Thu, 16 Jun 2011 12:00:19 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.115]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Thu, 16 Jun 2011 11:59:58 +0200 From: Thomas Dietz To: "Romascanu, Dan (Dan)" , IPFIX Working Group Thread-Topic: [IPFIX] AD review of draft-ietf-ipfix-psamp-mib-03.txt Thread-Index: AcwgRVpKL+rIVnCXROu/usNykoC0lgACsYcAAu7vkmA= Date: Thu, 16 Jun 2011 09:59:58 +0000 Message-ID: <75581E268A48F849916117B977D76D37240534CE@Polydeuces.office.hd> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.10] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0043_01CC2C1C.E975A710" MIME-Version: 1.0 Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-psamp-mib-03.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 10:00:31 -0000 ------=_NextPart_000_0043_01CC2C1C.E975A710 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Dan, find comments inline. -- Thomas Dietz NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 Heidelberg, Germany NEC Europe Limited, Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > Sent: Wednesday, June 01, 2011 1:40 PM > To: IPFIX Working Group > Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-psamp-mib-03.txt > > > > Hi, > > I have one more comment - please add it to the review: > > T4. As per [I-D.ietf-opsawg-mib-floats]: > > o Since these textual conventions are defined in terms of the OCTET > STRING type, the SMI's mechanisms for formally setting range > constraints are not available. MIB designers using these textual > conventions will need to use DESCRIPTION clauses to spell out any > applicable range constraints beyond those implied by the > underlying IEEE types. > A range was already given in the description. > o Whenever these textual conventions are used in a MIB module, the > associated DESCRIPTION clause will need to clearly specify whether > denormalized numbers, NaNs ("not a number") or infinities are > permitted, along with any special semantics associated with these > cases. This is especially important for writeable objects. > I added a sentence that excludes NaN and infinity. Hope the description is now sound. Best Regards, Thomas > As the object psampSampUniProbProbability uses the Float64TC - these > requirements need to be taken into consideration. > > Thanks and Regards, > > Dan > > > -----Original Message----- > > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf > > Of Romascanu, Dan (Dan) > > Sent: Wednesday, June 01, 2011 1:19 PM > > To: IPFIX Working Group > > Subject: [IPFIX] AD review of draft-ietf-ipfix-psamp-mib-03.txt > > > > > > > > Hi, > > > > I have performed the AD review of draft-ietf-ipfix-psamp-mib-03.txt. > > This document is in good shape and I am sending it to IETF Last Call. > > Please address the comments below together with the other IETF LC > > comments. > > > > The technical comments are marked T and the editorial comments are > > marked E. > > > > T1. > > > > Float64TC > > FROM FLOAT-TC-MIB -- draft-ietf-opsawg-mib-float > > > > Actually will need to be published before or simultaneously with this > > document, in order to satisfy the normative reference. Leaving > > draft-ietf-opsawg-mib-float would be confusing, we need the RFC number > > here. I suggest to include here (as a comment) a note to the RFC > Editor > > that mentions that draft-ietf-opsawg-mib-float is to be replaced with > > the RFC number of that document, and the note deleted. > > > > T2. Why do psampSampCountBasedAvail, psampSampTimeBasedAvail, > > psampSampRandOutOfNAvail, psampSampUniProbAvail, > > psampFiltPropMatchAvail, psampFiltHashAvail have DEFVAL clauses? These > > are read-only objects, so the values must be configured by some other > > means (not by SNMP) and just read by the agent. > > > > T3. There is no need to include the following in the IANA > > considerations > > section: > > > > psampSampCountBased { ipfixSelectorFunctions 2 } > > psampSampTimeBased { ipfixSelectorFunctions 3 } > > psampSampRandOutOfN { ipfixSelectorFunctions 4 } > > psampSampUniProb { ipfixSelectorFunctions 5 } > > psampFiltPropMatch { ipfixSelectorFunctions 6 } > > psampFiltHash { ipfixSelectorFunctions 7 } > > > > These are already assigned in the MIB module and no IANA action is > > required for them. > > > > > > E1. The contents of sections 3 and 4 are similar, but the formatting > of > > the texts in the two sections is different. I suggest to fix this > using > > for section 4 the same format as in section 3, which is easier to > read. > > > > E2. Page 5 - second paragraph s/as defiend/as defined/ > > > > E3. Please explain the meaning of each enumerated value in the > > DESCRIPTION clause of psampFiltHashFunction > > > > E4. Please detail the 'corresponding sampling function' in the > > DESCRIPTION clause of each one of the conformance groups under > > MODULE-COMPLIANCE. > > > > > > Thanks and Regards, > > > > Dan > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix ------=_NextPart_000_0043_01CC2C1C.E975A710 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNDCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFNTCCBB2gAwIBAgIED+0gWzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0xMDA0MjAxMjQ5MTVaFw0xMzA0MTkxMjQ5MTVaMGAx CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQD2mMcvPbgraEaWMV6uNCs6t88lhBczgfxybD46mwr8D3VaQLEnqTsBOAf/ Y8ARtq+P6Dkm2MBMXQG+Ebo2qhif6O4dH7whcG9E88F9247R2EJjcXmxMYZWYGQTI2vGw/joerRB waiwfxCXWBTLutbdWEEKL/DG9A1yQRPGJc+jJYfgm0ekYn+WESOLYaBH7G9aIIZQ7en3afhPpbQA Ajh92K240TG+VgBpe1vnDdth28Ps5XeN+otookDZHwwGQYwYrPZJtnhGIyjKMm7OkXL62Rf3aSoI doVUwYYS67RYYNOY0C7qOVyCUF+z4Bkn758sZhZzotiLQVT3AZ625PrvAgMBAAGjggHEMIIBwDAJ BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFH9fxgi2EshupgLF49SzaAX0QFoMMB8GA1UdIwQYMBaAFE8ch3od 4C+Z9r4VqtE1nQ5K5ro2MCEGA1UdEQQaMBiBFlRob21hcy5EaWV0ekBuZWNsYWIuZXUwfQYDVR0f BHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNy bC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2Fj cmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRm bi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8v Y2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN AQEFBQADggEBACnPHI1mIY1TVY9Aj8zsHHxiwMRx02Hp6DLZGYXHGG9IkflrRKNiDIV2LbBDpXVH vojMxTtCt10iwbyVMGaevet/VHYCJSHzrCLkw+GkvuhDU70lNsWw9P+mai7OHa+NQ6im8+4RnY1B yhqidcCt3hIV9B69ax0/KIhIFpiWz/lKZVIghki07I4m8mf1sbvCORKxudH0TVLlRJlX1r8S+8ea 9e+Q8pgXfrsCeyxBV3KAjszRQkqDZsbD7jQHQWokkMPIjbaTjw6V/5SRzmcAy0XlKNOCbldlzmCB jDZTQWdSH/AFDy5L2l4j0Ck0vVlQv+r1F4omsb4BelRq+vHd+lExggQ4MIIENAIBATCBmTCBkDEL MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzAJBgUrDgMCGgUAoIICczAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA2MTYwOTU5NTdaMCMGCSqGSIb3 DQEJBDEWBBStB+Jgh6quAKPKFiotjN/JyyTU8jCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQswCQYD VQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9y aWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemll cnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQP7SBbMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCBkDEL MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzCBtwYJKoZIhvcNAQkPMYGpMIGmMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3 DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAL BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG 9w0BAQEFAASCAQAGKgVkLbtWQ1TCGGMHenehU/1o8zhjkS8BXt8ides9xYpGxlWZFXlzXk/xuddy Oj1c1tgg/fBJhQWeTBeo4nOyw37iWj0VrdyA1c37sh2o6b1A05JKp9aG0e8KTqWH94M3bk95CrBW GT78PIxx8wjHl5jybEyFWB6vYw94zbP+41kLNT+aeylpjUMl/bwjFsDwql/iHWmQq5otECqEFo1D hgogR+3KzFMXMAupKs2FcOavV9q9Z28lqcAkIogY54UMRLb4v5xs+4VDJguSetG67RoL2nrpYgio mWKP3b+JPA/XgycpDHXJfWaGIZLGJVp5OASs5CuCPWGM+Hc5u+trAAAAAAAA ------=_NextPart_000_0043_01CC2C1C.E975A710-- From trammell@tik.ee.ethz.ch Thu Jun 16 04:44:11 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB05821F8564; Thu, 16 Jun 2011 04:44:11 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpES95fjD2va; Thu, 16 Jun 2011 04:44:11 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id E623621F855F; Thu, 16 Jun 2011 04:44:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2FF92D9307; Thu, 16 Jun 2011 13:44:24 +0200 (MEST) 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 LseovClGhrgh; Thu, 16 Jun 2011 13:44:24 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-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 01454D9302; Thu, 16 Jun 2011 13:44:23 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <201105301525.p4UFPaPQ019646@alpd052.aldc.att.com> Date: Thu, 16 Jun 2011 13:44:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201105301525.p4UFPaPQ019646@alpd052.aldc.att.com> To: Al Morton X-Mailer: Apple Mail (2.1084) Cc: ipfix@ietf.org, bmwg@ietf.org Subject: Re: [IPFIX] [bmwg] WGLC: draft-ietf-bmwg-ipflow-meth-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 11:44:12 -0000 Hi, Al, all, the -01 revision of bmwg-ipflow-meth addresses all my concerns with the = -00 revision. It is in my opinion ready for submission. Best regards, Brian On May 30, 2011, at 5:26 PM, Al Morton wrote: > BMWG, > CC: IPFIX WG, >=20 > This message begins the second WG Last call on the draft: >=20 > IP Flow Information Accounting and Export Benchmarking Methodology > draft-ietf-bmwg-ipflow-meth-01.txt >=20 > A URL for this draft is: > http://tools.ietf.org/html/draft-ietf-bmwg-ipflow-meth-01 >=20 > The Last Call will end on June 20, 2011. >=20 > We have discussed this draft in the working group for > over two years and made many improvements. > We have also benefited from review by folks from IPFIX WG. >=20 > I now ask everyone to consider items where they commented earlier, > and make sure that the resolutions are satisfactory. >=20 > Please weigh-in on whether or not this Internet-Draft > should be given to the Area Directors and IESG for consideration and > publication as an Informational RFC. Send your comments > to this list and/or acmorton@att.com. >=20 > Al > bmwg chair >=20 > _______________________________________________ > bmwg mailing list > bmwg@ietf.org > https://www.ietf.org/mailman/listinfo/bmwg From muenz@net.in.tum.de Sun Jun 19 03:40:03 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D9A11E810C for ; Sun, 19 Jun 2011 03:40:03 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OG2ZU7dZZ0h for ; Sun, 19 Jun 2011 03:40:02 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1D34811E80D8 for ; Sun, 19 Jun 2011 03:40:01 -0700 (PDT) Received: from [192.168.2.152] (p4FCFDD59.dip.t-dialin.net [79.207.221.89]) by mail.net.in.tum.de (Postfix) with ESMTPSA id CEB412255BA7; Sun, 19 Jun 2011 12:40:29 +0200 (CEST) Message-ID: <4DFDD218.2000501@net.in.tum.de> Date: Sun, 19 Jun 2011 12:40:24 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Brian Trammell References: <20110523092128.18082.9981.idtracker@ietfa.amsl.com><804B13F8F3D94A4AB18B9B01ACB68FA1044F55B0@EXCHSRV.fokus.fraunhofer.de><4DDC22C7.6070704@auckland.ac.nz><1E3C6A6E-83BC-4ABC-861E-EF46FC3F0624@tik.ee.ethz.ch> <804B13F8F3D94A4AB18B9B01ACB68FA1044F5AA2@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] New WG Last Call fordraft-ietf-ipfix-flow-selection-tech-06.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 10:40:03 -0000 >>> 5. Within section 6, it is not clear how to apply this >>> configuration data model. Should this be harmonized with >>> ipfix-configuration-model? >> >> Yes, it shoudl be possible to use this as basis, like PASMP-TECH. >> Should we just reference to the config-model or do you suggest any >> further alignment? > > Since configuration per the configuration-model draft is done with > YANG for NETCONF-compatibility, I think this should be handled as a > model extension, with YANG defined for it. I'm neither a YANG nor a > NETCONF expert; perhaps someone with more experience could pop in and > say whether my suggestion makes any sense. :) I had a brief look at section 6 without having read the entire draft. It seems that FS_SELECTOR_ID is an enumerator for FS_TYPE. If this is true, the following sentence is imprecise because only one of FS_SELECTOR_ID and FS_TYPE is required for the configuration: "A flow selection configuration consists of FS_SELECTOR_ID, FS_TYPE, FS_SELECTOR PARAMETERS." My recommendation is not to define any enumeration or names such as FS_SELECTOR_ID and FS_TYPE. This should be done in the data model (i.e. MIB or YANG draft) if needed and according to the corresponding enumeration or naming style. However, you should provide a description for every single parameter that you propose. This text can be later copied into the data model draft. Regards, Gerhard From n.brownlee@auckland.ac.nz Sun Jun 19 21:38:45 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACA821F8503 for ; Sun, 19 Jun 2011 21:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcP+zCE7F7LM for ; Sun, 19 Jun 2011 21:38:44 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1701D21F8504 for ; Sun, 19 Jun 2011 21:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1308544724; x=1340080724; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4DFECECB.4010000@auckland.ac.nz>|Date:=20 Mon,=2020=20Jun=202011=2016:38:35=20+1200|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20Working=20Group=20 |Subject:=20IETF=2081:=20New=20work=20for=20IPFIX=20... |Content-Transfer-Encoding:=207bit; bh=8Hq8iR4uxK6+8So9ADyy8GKLHnSEJdf2TTlxNZANZCM=; b=X0wMa5vh1qED5EbdLMYeoPppYc5PE1qkxn2uiAovqXgK/XAYKEkWTPfT r8ry2B02R1oG9Z9xqfcu9lGxuGauc1w7oNq+hfXl0WtNlxmzAOQtMY3Sn vH97WyII4axjdx4CendfHlOz3sg8wcwyaSfvdQF/539PWQcDjsr3X8TQk Q=; X-IronPort-AV: E=Sophos;i="4.65,391,1304251200"; d="scan'208";a="68142353" 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; 20 Jun 2011 16:38:35 +1200 Message-ID: <4DFECECB.4010000@auckland.ac.nz> Date: Mon, 20 Jun 2011 16:38:35 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] IETF 81: New work for IPFIX ... X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 04:38:45 -0000 Hi all: It looks as though the flow-selection draft will be ready to submit before the Quebec IETF meeting, so it's time to start discussion on new charter items. Looking back at the minutes from IETF 80 in Prague, possible items are: 1. New versions of the base standards, 5101 and 5102, which implement small changes that did not affect interoperation, (for example adding detail where there are gaps in 5101) as a Standards Track successor to 5101. Once that had been published as an RFC for some time we could work on moving it to Draft; that should be possible in a reasonably short time. 2. IE Doctors, a draft that "lays out the ground rules for developing new IPFIX Information Elements, and clarifies how the IE Registry process works." The issues here are a. Should we develop an 'IE Guidelines' draft? b. Do we want to have an 'IE Doctors' team (with IESG overview), an expanded group of IE Expert reviewers, or what? 3. IPFIX Aggregation. This seems (to me) to be a required function for IPFIX Mediation. 4. IPFIX Mediation protocol draft. 5. Exporting MIB variables using IPFIX draft. For any of these that we adopt as new work items, I'd like to know - who is prepared to work on writing/editing? (at least 2 people) - who is prepared to review these drafts as they change from time to time? (at least three people) If you are prepared to do either of these, please email me a list of which item numbers in the list above you're willing to write/edit and/or to review. So, do please send your comments on these to the list, so that we can have an informed discussion in Quebec City. Cheers, Nevil (IPFIX co-chair) -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From bclaise@cisco.com Mon Jun 20 06:34:56 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901DE1F0C50 for ; Mon, 20 Jun 2011 06:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZP-M1xoH7LD for ; Mon, 20 Jun 2011 06:34:56 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 983C91F0C44 for ; Mon, 20 Jun 2011 06:34:55 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p5KDNUfl000382; Mon, 20 Jun 2011 15:23:30 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p5KDNS5i019214; Mon, 20 Jun 2011 15:23:29 +0200 (CEST) Message-ID: <4DFF49D0.2020506@cisco.com> Date: Mon, 20 Jun 2011 15:23:28 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nevil Brownlee References: <4DFECECB.4010000@auckland.ac.nz> In-Reply-To: <4DFECECB.4010000@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] IETF 81: New work for IPFIX ... X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 13:34:56 -0000 Hi Nevil, > > Hi all: > > It looks as though the flow-selection draft will be ready to submit > before the Quebec IETF meeting, so it's time to start discussion > on new charter items. Looking back at the minutes from IETF 80 in > Prague, possible items are: > > 1. New versions of the base standards, 5101 and 5102, which implement > small changes that did not affect interoperation, (for example > adding detail where there are gaps in 5101) as a Standards Track > successor to 5101. Once that had been published as an RFC > for some time we could work on moving it to Draft; that should be > possible in a reasonably short time. > > 2. IE Doctors, a draft that "lays out the ground rules for developing > new IPFIX Information Elements, and clarifies how the IE Registry > process works." The issues here are > a. Should we develop an 'IE Guidelines' draft? > b. Do we want to have an 'IE Doctors' team (with IESG overview), > an expanded group of IE Expert reviewers, or what? > > 3. IPFIX Aggregation. This seems (to me) to be a required function > for IPFIX Mediation. > > 4. IPFIX Mediation protocol draft. > > 5. Exporting MIB variables using IPFIX draft. > > For any of these that we adopt as new work items, I'd like to know > - who is prepared to work on writing/editing? (at least 2 people) I'm ready to do so for all drafts. Regards, Benoit. > - who is prepared to review these drafts as they change from time > to time? (at least three people) > If you are prepared to do either of these, please email me a list > of which item numbers in the list above you're willing to write/edit > and/or to review. > > So, do please send your comments on these to the list, so that we > can have an informed discussion in Quebec City. > > Cheers, Nevil (IPFIX co-chair) > From paitken@cisco.com Mon Jun 20 15:14:07 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D14E9E804D for ; Mon, 20 Jun 2011 15:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.699 X-Spam-Level: X-Spam-Status: No, score=-10.699 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21Z7am9iOcD5 for ; Mon, 20 Jun 2011 15:14:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 17CEC9E804C for ; Mon, 20 Jun 2011 15:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=130440; q=dns/txt; s=iport; t=1308608038; x=1309817638; h=message-id:date:from:mime-version:to:subject; bh=SITmdSVcsMknuoKSv6CLckBP3T2cKPasZQsGKYrcfiw=; b=IhsvUpKkl+Hlm9M792dA///tDOfHlHXofhIZAAjh50aq+Ps9IXIocAIa pkcg3OpQlJ3moJ+2rjC4aDuFWKRWaEsjj03sAmB4oOrVk5D9F6/iRLFg6 rl7oLCgEKJpthlCbTnOyGxmHDXZt0NX883GH4BcOZZG1gWPCwwlXeNWol c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAzF/02Q/khL/2dsb2JhbABNBqZnd4hzoCeBHZ4eAoM1gnMEkV6EYIsi X-IronPort-AV: E=Sophos;i="4.65,396,1304294400"; d="scan'208,217";a="95033942" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2011 22:13:56 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5KMDppN014106 for ; Mon, 20 Jun 2011 22:13:51 GMT Received: from [10.61.81.114] (ams3-vpn-dhcp4467.cisco.com [10.61.81.114]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p5KMDlLf029438 for ; Mon, 20 Jun 2011 23:13:47 +0100 (BST) Message-ID: <4DFFC61E.70605@cisco.com> Date: Mon, 20 Jun 2011 23:13:50 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: multipart/alternative; boundary="------------070800050200020304050907" Subject: Re: [IPFIX] draft-ietf-ipfix-flow-selection-tech-06 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 22:14:07 -0000 This is a multi-part message in MIME format. --------------070800050200020304050907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear All, Please find some review comments inline. Hopefully you can see the red highlighting too. P. > Internet Engineering Task Force S. D'Antonio > Internet-Draft CINI Consortium/University of > Intended status: Standards Track Napoli "Parthenope" > Expires: November 24, 2011 T. Zseby > Fraunhofer Institute FOKUS > C. Henke > Technische Universitat Berlin > L. Peluso > University of Napoli > May 23, 2011 > > > Flow Selection Techniques > draft-ietf-ipfix-flow-selection-tech-06.txt > > Abstract > > Flow selection is the process of selecting a subset of flows from all > flows observed at an observation point. Flow selection reduces the > effort of post-processing flow data and transferring flow records. > This document describes motivations for flow selection and presents > flow selection techniques. It provides an information model for > configuring flow selection techniques and discusses what information > about a flow selection process should be exported. > > Requirements Language > > 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]. > > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is athttp://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on November 24, 2011. > > > > > D'Antonio, et al. Expires November 24, 2011 [Page 1] > > Internet-Draft Flow Selection Techniques May 2011 > > > Copyright Notice > > Copyright (c) 2011 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > This document may contain material from IETF Documents or IETF > Contributions published or made publicly available before November > 10, 2008. The person(s) controlling the copyright in some of this > material may not have granted the IETF Trust the right to allow > modifications of such material outside the IETF Standards Process. > Without obtaining an adequate license from the person(s) controlling > the copyright in such materials, this document may not be modified > outside the IETF Standards Process, and derivative works of it may > not be created outside the IETF Standards Process, except to format > it for publication as an RFC or to translate it into languages other > than English. > > > > > > > > > > > > > > > > > > > > > > > > > > D'Antonio, et al. Expires November 24, 2011 [Page 2] > > Internet-Draft Flow Selection Techniques May 2011 > > > Table of Contents > > 1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Difference between Flow Selection and Packet Selection . . . . 6 > 4. Flow selection as Function in the IPFIX Architecture . . . . . 7 > 4.1. Flow selection in the Metering Process before > Aggregation . . . . . . . . . . . . . . . . . . . . . . . 9 > 4.2. Flow selection in the Metering Process after > Aggregation . . . . . . . . . . . . . . . . . . . . . . . 9 > 4.3. Flow selection during the Exporting Process . . . . . . . 9 > 4.4. Flow selection as a function of the IPFIX Mediator . . . . 10 > 5. Flow Selection Techniques . . . . . . . . . . . . . . . . . . 10 > 5.1. Flow Filtering . . . . . . . . . . . . . . . . . . . . . . 10 > 5.1.1. Property Match Filtering . . . . . . . . . . . . . . . 10 > 5.1.2. Hash-based Flow Filtering . . . . . . . . . . . . . . 11 > 5.1.3. Flow State Dependent Flow Filtering . . . . . . . . . 11 > 5.2. Flow Sampling . . . . . . . . . . . . . . . . . . . . . . 12 > 5.2.1. Systematic Sampling . . . . . . . . . . . . . . . . . 12 > 5.2.2. Random Sampling . . . . . . . . . . . . . . . . . . . 12 > 5.3. Flow-state Dependent Packet Selection . . . . . . . . . . 13 > 6. Information Model for Configuration of Flow Selection > Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 13 > 6.1. Description of Flow Filtering Techniques . . . . . . . . . 15 > 6.2. Description of Flow Sampling Techniques . . . . . . . . . 16 > 6.3. Description of Flow State Dependent Packet Selection . . . 17 > 7. Information Model for Flow Selection Reporting . . . . . . . . 18 > 7.1. fsFlowRecordTotalCount . . . . . . . . . . . . . . . . . . 19 > 7.2. fsFlowRecordSelectedCount . . . . . . . . . . . . . . . . 19 > 7.3. fsCurrentFlowEntries . . . . . . . . . . . . . . . . . . . 19 > 7.4. fsMaxFlowEntries . . . . . . . . . . . . . . . . . . . . . 20 > 7.5. fsFlowEntryTotalCount . . . . . . . . . . . . . . . . . . 20 > 7.6. fsFlowEntrySelectedCount . . . . . . . . . . . . . . . . . 20 > 7.7. fsPacketTotalCount . . . . . . . . . . . . . . . . . . . . 21 > 7.8. fsFlowEntrySelectedCount . . . . . . . . . . . . . . . . . 21 > 7.9. fsOctetTotalCount . . . . . . . . . . . . . . . . . . . . 21 > 7.10. fsOctetSelectedCount . . . . . . . . . . . . . . . . . . . 22 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 > 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 > 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 > 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 > > > > > > > > > D'Antonio, et al. Expires November 24, 2011 [Page 3] > > Internet-Draft Flow Selection Techniques May 2011 > > > 1. Scope > > This document describes flow selection techniquesfor traffic > measurements. A flow is defined as a set of packets with common "for traffic measurements" doesn't add anything. > properties as described in [RFC5101]. Flow selection can be done to > limit the resource demands for capturing, storing, exporting and > post-processing of flow records. It also can be used to select a > particular set of flows that are of interest to a specific > application. This document provides acathegorization of flow Typo. > selection techniques and describes configuration and reporting > parameters for them. In order to be compliant with this document, at > least one of proposed flow selection schemes MUST be implemented. > That means that the configuration parameters as well as the reporting > information elementsfor this particular scheme MUST be supported. Capitalised? > This document also addresses configuration and reporting parameters > for flow-state dependent packet selection as described in [RFC5475], > althoughthe technique is categorized as packet selection. The "that" ? > reason is,thta flow-state dependent packet selection techniques Typo. > often aim at the reduction of resources for flow capturing and flow > processing. Furthermore, they were only briefly discussed in > [RFC5475]. Therefore we included configuration and reporting > considerations for such techniques in this document. > > > 2. Terminology > > This document is consistent with the terminology introduced in > [RFC5101], [RFC5470], [RFC5475] and [RFC3917]. As in [RFC5101] and > [RFC5476], the first letter of each IPFIX-specific and PSAMP-specific > term is capitalized along with the flow selection specific terms > defined here. > > * Classification > > Classification is a processin which packets are mapped to "by" ? > specific flow recordsbased on packet properties. These The mapping may not be due to packet properties, eg interface or ACL. > properties make up the flow key (e.g. header information, packet > content, AS number). In case a flow record for a specific flow > key already exists the flow record is updated, otherwise a new > flow record is created. > > * Flow Selection Process > > A Flow Selection Process takes classified packets, flow cache > entries or flow records as its input and selects a subset of that Surely a process taking packets as inputs would be a *packet* selection process? > set as its output. A Flow Selection Process MAY runon several > instances within the IPFIX architecture. A Flow Selection Process "in several places" ? > > D'Antonio, et al. Expires November 24, 2011 [Page 4] > > Internet-Draft Flow Selection Techniques May 2011 > > > MAY be part of an IPFIXmetering process, exporting process or as Please capitalise these terms. > anIntermediate Selection Process running on an IPFIX Mediator. This term is not defined, although it's used several times in this document. > * Flow Selection State > > A Flow Selection Process SHOULD maintain state information for use > by the Flow Selector. At a given time, the Flow Selection State > may depend on flows and packets observed at and before that time, > as well as other variables. Examples include: > > (i) sequence number of packets and accounted flow records; > > (ii) number of selected flows; > > (iii) number of observed flows; > > (iv) current flow cache occupancy; > > (v) flow specific counters, lower und upper bounds > > (vi) flow selection timeout intervals > > * Flow Selector > > A Flow Selector defines the action of a Flow Selection Process on > a single flow of its input. The Flow Selector can make use of the > following information in order to establish whether a flow has to > be selected or not: > > (i) the content of the flow record; > > (ii) any state information related to themetering or exporting > process; "Metering Process or Exporting Process". > (iii) any Flow Selection State that may be maintained by the > Flow Selection Process. > > * Complete Flow > > A Complete Flow consists of all packets within the flow time-Out > interval that enter the Flow Selection Process and belong to the > same flow as defined by theflow definition. For this definition What does "flow definition" mean? Is it the key fields? > only packets are considered that arrive at the Flow Selection "For this definition only packets that arrive at the Flow Selection Process are considered." > Process. That means, packets that are not observed at the Flow > Selection Process because of prior packet selection or packet loss > are not considered as belonging to the Complete Flow. Therefore the "Complete Flow" can be incomplete. Can you find a better term, eg "Measured Flow" ? > * Flow Filtering > > > > D'Antonio, et al. Expires November 24, 2011 [Page 5] > > Internet-Draft Flow Selection Techniques May 2011 > > > Flow Filtering selects flows based on a deterministic function on > the flow record content, flow state, external properties (e.g. > ingress interface) or external events (e.g violated Access Control > List). If the relevant parts of the flow record content can be > already observed at packet level (e.g. flow keys from packet > header fields) Flow Filtering can be performed at packet level by > property match packet filtering as described in [RFC5475]. > > * Flow Sampling > > Flow Sampling selects flows based on flow record sequence or > arrival times (e.g.position in flow cache, arrival time at That would be implementation dependant. > exporter or mediator). The selection can be systematic (e.g. Please capitalise your terminology. > every n-threcord) or based on a random functions (e.g. select > eachrecord with probability p, or randomly select n out of N > records). s/record/flow/ > * Aggregation Process > > In the IPFIX metering process the aggregation process aggregates > packet data into flow data and forms the flow cache entries or > flow records. After the aggregation step only the aggregated flow > information is available. Information about individual packets is > lost. > > > 3. Difference between Flow Selection and Packet Selection > > Flow selection differs from packet selection described in [RFC5475]. > Packet selection techniques consider packets as basic element and the > parent population consists of all packets observed at an observation > point. In contrast to this the basic elements in flow selection are > the flows. The parent population consists of all observed flows and > the selection process operates on the flows. The major > characteristics of flow selection are the following: > > - Flow selection takes flows as basic elements. For packet > selection, packets are considered as basic elements. > > - Flow selection can only take place after classification, > because the classification rules determine to which flow a > packet belongs. Packet selection can be applied before or > after classification. > > - Flow selection operates on complete flows. That means that > after the flow selection process either all packets of the > flow are kept or all packets of the flow are discarded. All > packets of the flow here means all packets that enter the > > > > D'Antonio, et al. Expires November 24, 2011 [Page 6] > > Internet-Draft Flow Selection Techniques May 2011 > > > flow selection process. That means that if the flow > selection is preceded by a packet selection process the > complete flow consists only of the packets thatwhere not > discarded during the packet selection. "were". > There are some techniques that are difficult to unambiguously > categorize into one of the categories.We here give some guidance "Here we give" > how to categorize such techniques: > > - Techniques that can be considered as both, packet and flow Remove the comma. > selection: Some packet selection techniques result in the > selection ofwhole flows and therefore can be considered as What is a "whole flow" ? > packet or as flow selection at the same time. An example is > property match filtering of all packets to a specific > destination address. If flows are defined based on > destination addresses, such a packet selection also results > in a flow selection and can be considered as packet or flow > selection. > > - Flow-state dependent packet selection (as described in > [RFC5475]): There exist techniques that select packets based > on the flow state, e.g. based on the number of already > observed packets belonging to the flow. Examples of these > techniques from the literature are "Sample and Hold" [EsVa01] > "Fast Filtered Sampling" [MSZC10] or the "Sticky Sampling" > algorithm presented in [MaMo02]. Such techniques can be used > to influence which flows are captured (e.g. increase the > selection of packets belonging to large flows) and reduce the > number of flows that need to be stored in the flow cache. > Nevertheless, such techniques do not necessarily select > Complete Flows, becauseit is not ensured that all packets of "they do not ensure" > a selected flow are captured. Therefore flow-state dependent > packet selection methods that do not ensure that either all > or no packets of a flow are selected strictly speaking have > to be considered as packet selectiontechnique and not as "techniques" > flow selection. Append "techniques". > 4. Flow selection as Function in the IPFIX Architecture "as *a* Function" > Figure 1 shows the IPFIX reference model as defined in [RFC5470], and > extends it by introducing the functional components where flow > selection can take place. > > Packet(s) coming in to Observation Point(s) > | | > v v > +----------------+---------------------------+ +-----+-------+ > > > > D'Antonio, et al. Expires November 24, 2011 [Page 7] > > Internet-Draft Flow Selection Techniques May 2011 > > > | Metering Process | | | > | | | | > | packet header capturing | | | > | | |...| Metering | > | timestamping | | Process N | > | | | | | > | packet selection | | | > | | | | | > | classification | | | > | | | | | > | flow state dependent packet selection | | | > | | | | | > | flow selection before aggregation (*) | | | > | | | | | > | aggregation | | | > | | | | | > | flow selection after aggregation (*) | | | > +--------|-----------------------------------+ +-----|-------+ > Flow Records Flow Records > | | > +----------------------+----------------------+ > | > +----------------------|-----------------+ > | Exporting Process | | > | v | > |flow selection before export(*) | > | | | > | v | > | flow export | > +----------------------+-----------------+ > | IPFIX (Flow Records) > v > +-------------------------|-----------------------+ > | IPFIX Mediator | | > | v | > | Collecting Process(es) | > | | | > |Intermediate Flow Selection Process (*) | > | | | > | Exporting Process(es) | > +-------------------------|-----------------------+ > v > IPFIX The latter two parts of the Mediator constitute another Exporting Process. As such, the "flow selection before export" and "Intermediate Flow Selection Process" are identical. > (*) indicates where flow selection can take place. > > Figure 1: Flow selection in the IPFIX Architecture > > > > > D'Antonio, et al. Expires November 24, 2011 [Page 8] > > Internet-Draft Flow Selection Techniques May 2011 > > > In contrast to packet selection, flow selection is always applied > after the packets are classified into flows. Flows can be selected > at different stages of the measurement chain: > > 1. during Metering Process before aggregation > > 2. during Metering Process after aggregation; > > 3. during Exporting Process > > 4. in an Intermediate Selection Process on a Mediator Again, 3+4 are identical. > 4.1. Flow selection in the Metering Process before Aggregation > > In the aggregation process the packet information is used to update > the flow entries in the flow cache. Flow selection that is applied > before aggregation equals a packet selection process. The flow still > consists of individual packets. Those are then selected based on the > classification information, i.e. based on the flow they belong to. > Flow selection before aggregation can be based on the fields of the > flow key (also on a hash value over these fields), but not based on > characteristics that are only available after aggregation (e.g. flow > size, flow duration). Flow selection before aggregation is applied > to reduce resources for all succeeding processes (aggregation, > exporting process) or select specific flows of interest in case such > flow characteristics are already observable at packet level (e.g. > flows to specificIPs). In contrast, flow state dependent packet Say, "IP addresses". > selection is a packet selection method, because it does not > necessarily select Complete Flows. Flow selection before aggregation > and flow state dependent packet selection can be applied in arbitrary > order. > > 4.2. Flow selection in the Metering Process after Aggregation > > Flow selection after aggregation is usually applied to reduce the > flows to those that are of interest to a particular application and > to unload flow export and flow postprocessing. Since the flow cache > entries are already generated by the aggregationprocess flow "process, flow" > selection after aggregation can also depend on flow characteristics > that are only visible after the aggregation of packets, such as flow > size and flow duration. > > 4.3. Flow selection during the Exporting Process > > The Exporting Process may implement policies for exporting only a > subset of the flow records which have been stored in the system > memory. Flow selection in the exporting process may select only the > subset of flow records which are of interest to the users > > > > D'Antonio, et al. Expires November 24, 2011 [Page 9] > > Internet-Draft Flow Selection Techniques May 2011 > > > application, or select only as many flow recordsthan can be handled s/than/as/ > by the available resources( e.g. limited flow cache size and export > link capacity). Extra space. > 4.4. Flow selection as a function of the IPFIX Mediator > > As shown in Figure 1, flow selection can be performed as an > intermediate process within an IPFIX Mediator [RFC6183]. The > Intermediate Selection Process takes a flow record stream as its > input and retrieves a record stream. The Intermediate Selection > Process can again apply a flow selection technique to obtain flows of > interest for the application. Further the Intermediate Selection > Process can base its selection decision on the correlation of data > from different observation points, e.g by only selecting flows that > were at least recorded on two observation points. These actions can also be performed in 4.3. > 5. Flow Selection Techniques > > A flow selection technique selects eitherall packets or none of a > flow, otherwise the technique has to be considered as packet "all or none of the packets of a flow" > selection. We distinguish between Flow Filtering and Flow Sampling. > > 5.1. Flow Filtering > > Flow Filtering is a deterministic function on the IPFIX flow record > content. In case that the relevant flow characteristics are already > observable at packet level (e.g. flow keys) Flow Filtering can be > applied before aggregation at packet level. > > 5.1.1. Property Match Filtering > > Flow Filtering can be done similarly to Property Match Filtering for > packet selection described in [RFC5475]. The difference is that, > instead of packet fields, flow record fields arehere used to derive Remove "here". > the selection decision. Property Match Filtering is typically used > to select a specific subset of the flows that are of interest to a > particular application (e.g. all flows to a specific destination, all > large flows, etc.). Properties on which the filtering is based can > be for example flow keys, the flow size in bytes, the number of > packets in the flow, the observation time of the first or last > packet, or the maximum packet length. The selection criteria can be > a specific value or an interval. Property match filtering can be > applied before aggregationin case the properties are already s/in case/if/ > observable at the packet level (e.g. flow key fields). > > There are content based Property Match filtering techniques that > require acompution on the current flow cache. An example is the "computation"? > > D'Antonio, et al. Expires November 24, 2011 [Page 10] > > Internet-Draft Flow Selection Techniques May 2011 > > > selection of the k largest flows or a percentage of flows with the > longest livetime. This type of Property Match Filtering is also used > in flow selection techniques that reacton external events (e.g. "react to" > resource constraint). For example in case the flow cache is full, > the flow cache entry with the lowest flow volume per current flow > live time is deleted. Typo, "life". You say "current flow life time" as if there are different possibilities? > 5.1.2. Hash-based Flow Filtering > > Hash-based Flow Filtering uses a Hash Function h to map the flow key > c onto a Hash Range R. A flow is selected if the hash value h(c) is > within the Hash Selection Range S, which is a subset of R. Hash-based > Flow Filtering can be used to emulate a random sampling process but > still enable the correlation between selected flow subset at > different observation points. Hash-based Flow Filtering is similar > to Hash-based Packet Selection, and in fact is identical when Hash- > based Packet Selection uses the flow key that define the flow as the > Hash Input. Nevertheless there MAY be the incentive to apply Hash- > based Flow Selection not on the packet level before aggregation, for > example when the size of the Selection Range and therefore the > sampling probability is dependent on the number of observed flows. > > 5.1.3. Flow State Dependent Flow Filtering > > Flow state dependent filtering does not base the selection decision > on fields of the current flow record content but on the flow state > which may be kept additionally for each of the flows. External > processes may update counters, bounds and timers for each of the flow > records and the flow selection process utilises this information for > the selection decision. A review of flow state dependent filtering > techniques that aim at the selection of the most frequent items by > keeping additional flow state information can be found in [CoHa08]. > Flow state dependent flow filtering can only be applied after > aggregation, when a packet has been assignedto a flow cache. The Either the packet is assigned to a Flow, or to a cache entry - but not to a flow cache. > selection process then decides based upon the flow state for each > flow if it is kept in the flow cache or not. Two flow dependent flow > filtering techniques are here described: Should these be 5.1.3.1 and 5.1.3.2 ? > The Frequent Algorithm [KaPS03] is a technique that aims at the > selection of all flows that at least exceed a 1/k fraction of the > observed packet stream. The algorithm has only a flow cache of size > k-1 and each flow in the cache has an additional counter. The > counter is incremented each time a packet belonging to the flow in > the flow cache is observed. In case the observed packet does not > belong to any flow all counters are decremented and if any of the > flow counters have a value of zero the flow is replacedwith the new > flow. Presumably "with a flow formed from the new packet"? > > > D'Antonio, et al. Expires November 24, 2011 [Page 11] > > Internet-Draft Flow Selection Techniques May 2011 > > > Lossy Counting is a selection technique that identifies all flows > whose packet count exceeds a certain percentage of the whole observed > packet stream (e.g. 5% of all packets) with a certain estimation > error e. Lossy Counting seperates the observed packet stream in > windows of size N=1/e, where N is an amount of consecutive packets. > For each observed flow an additional counter will be held in the flow > state. The counter is incremented each time a packet belonging to > the flow is observed and all counters are decremented at the end of > each window and all flows with a counter of zero will be removed from > the flow cache. > > 5.2. Flow Sampling > > Flow sampling operates on flow record sequence or arrival times. It > can use a systematic or a random functions for the selection process. > Flow sampling usually aims at the selection of a representative > subset of all flows in order to estimate characteristics of the whole > set (e.g. mean flow size in the network). > > 5.2.1. Systematic Sampling > > Systematic sampling is a deterministic selection function. > Systematic sampling may be a periodic selection of the k-th flow > record which arrives at the exporting or mediator process. > Systematic Sampling can also be applied before aggregation. An > example would be to use an additional data structure that saves the > flow keys of thenot selected flows. Then one can create a flow "un-selected"? > cache entry for the k-th observed packet thathas yet no flow cache "does not yet have a" > entry and is not within the data structure containing thenot > selected flows. > > Systematic sampling can also be time-based. Systematic Sampling is > applied by only creating flows that are observed between time-based > start and stop triggers. The time interval may be applied at packet > level or after aggregation level, e.g.by selecting every k seconds a > flow arriving at the export process. "by selecting a flow arriving at the export process every k seconds". What if the export is irregular, so nothing arrives at the required time? - export the next flow which arrives, or export nothing? > 5.2.2. Random Sampling > > Random flow sampling is based on a random process which requires the > calculation of random numbers. One can differentiate between n-out-N > and probabilistic sampling. The sampling probability of individual > flows records MAY be adjusted according to the flow record content or > external events like the available export resources. Non-uniform > random sampling approaches can be applied similar to the ones defined > in [RFC5475].An example would be to prefer large volume flows over > small volume flows. Random flow sampling can also be applied before Out of scope of this doc, but surely this method ensures that the large get larger while the small never get a chance to grow. So the observation may be skewed by the initial observations. > aggregation when additional flow state about non selected flows is > > > > D'Antonio, et al. Expires November 24, 2011 [Page 12] > > Internet-Draft Flow Selection Techniques May 2011 > > > kept. > > 5.3. Flow-state Dependent Packet Selection > > As explained above Flow-state Dependent Packet Selection is not a > Flow Selection Technique buta packet selection. Nevertheless we "a packet selection *technique*". > will describe configuration and reporting parameters for this > technique in this document. An example is the the "Sample and Hold" > algorithm [EsVa01] that tries to prefer large volume flows in the > selection. When a packet arrives it is selectedwhen already a flow > cache entry for this packet exists. In case there is no flow cache "when a flow cache entry for this packet already exists." > entry, the packet is selected by a certain probability that is > dependent on the packet size. > > > 6. Information Model for Configuration of Flow Selection Techniques How exactly would the reader use this configuration model? > This section describes the configuration parameters of the flow > selection techniques presented above. It provides the basis of an > information model to be adopted in order to configure the flow > selection process within an IPFIX device. The following table gives > an overview of the defined selection techniques, where they can be > applied andwhat are their input parameters. Dependent on where the "what their input parameters are". > flow selection techniques are applied different input parameters can > be configured. > > Overview of Flow Selection Techniques: > > > > > > > > > > > > > > > > > > > > > > > > > D'Antonio, et al. Expires November 24, 2011 [Page 13] > > Internet-Draft Flow Selection Techniques May 2011 > > > +------------------+-----------------+------------------------------+ > | Location | Selection | Selection Input | > | | Method | | > +------------------+-----------------+------------------------------+ > | before | Flow State | packet sampling | > | aggregation | Dependent | probabilities, flow state, | > | | Packet | packet properties | > | | Selection | | > +------------------+-----------------+------------------------------+ > | | Property Match | flow key fields, filter | > | | Flow Filtering | function | > +------------------+-----------------+------------------------------+ > | | Hash-Based Flow | selection range, hash | > | | Filtering | function, flow key | > +------------------+-----------------+------------------------------+ > | | Time-based | flow position (derived from | > | | Systematic Flow | arrival time of packets), | > | | Sampling | flow state | > +------------------+-----------------+------------------------------+ > | | Sequence-based | flow position (derived from | > | | Systematic Flow | packet position), flow state | > | | Sampling | | > +------------------+-----------------+------------------------------+ > | | Random Flow | random number generator or | > | | Sampling | list and packet position, | > | | | flow state | > +------------------+-----------------+------------------------------+ > | after | Property Match | flow record content, filter | > | aggregation | Flow Filtering | function | > +------------------+-----------------+------------------------------+ > | | Hash-Based Flow | selection range, hash | > | | Filtering | function, hash input (flow | > | | | keys and other flow | > | | | properties) | > +------------------+-----------------+------------------------------+ > | | Flow State | flow state parameters | > | | Dependent Flow | | > | | Selection | | > +------------------+-----------------+------------------------------+ > | | Time-based | flow arrival time, flow | > | | Systematic Flow | state | > | | Sampling | | > +------------------+-----------------+------------------------------+ > | | Sequence-based | flow position, flow state | > | | Systematic Flow | | > | | Sampling | | > +------------------+-----------------+------------------------------+ > > > > > D'Antonio, et al. Expires November 24, 2011 [Page 14] > > Internet-Draft Flow Selection Techniques May 2011 > > > +------------------+-----------------+------------------------------+ > | | Random Flow | random number generator or | > | | Sampling | list and flow position, flow | > | | | state | > +------------------+-----------------+------------------------------+ > | during Exporting | Property Match | flow record content, filter | > | Process or in | Flow Filtering | function | > | the Mediator | | | > +------------------+-----------------+------------------------------+ > | | Hash-Based Flow | selection range, hash | > | | Filtering | function, flow key | > +------------------+-----------------+------------------------------+ > | | Time-based | flow record arrival time | > | | Systematic Flow | | > | | Sampling | | > +------------------+-----------------+------------------------------+ > | | Sequence-based | flow record position | > | | Systematic Flow | | > | | Sampling | | > +------------------+-----------------+------------------------------+ > | | Random Flow | random number generator or | > | | Sampling | list and flow position | > +------------------+-----------------+------------------------------+ > | | Flow State | flow state parameters | > | | Dependent Flow | | > | | Selection | | > +------------------+-----------------+------------------------------+ > > A flow selection configuration consists of FS_SELECTOR_ID, FS_TYPE, > FS_SELECTOR PARAMETERS. > > FS_SELECTOR ID: Unique ID for the flow sampler > > FS_TYPE: Defines which algorithm is used. > > FS_SELECTOR_PARAMETERS: Defines the input parameter for the flow > selection methods > > 6.1. Description of Flow Filtering Techniques > > In this section, we define what elements are needed to describe the > most common Flow Filtering techniques. > > > > > > > > > > D'Antonio, et al. Expires November 24, 2011 [Page 15] > > Internet-Draft Flow Selection Techniques May 2011 > > > +----------------+----------------------------------------+ > | FS_SELECTOR_ID | FS_TYPE | > +----------------+----------------------------------------+ > | 1 | fs_property_matching | > +----------------+----------------------------------------+ > | 2 | fs_hashing | > +----------------+----------------------------------------+ > | 3 | fs_flow_state_dependent_flow_selection | > +----------------+----------------------------------------+ > > FS_SELECTOR_PARAMETERS: > > case fs_property_matching: > > - Information Element (from [RFC5102]) > > - Value or Value Interval > > case fs_hashing: > > - Hash Domain (input bits from packet) - can be specified for IPv4 > or IPv6 or both > > - Hash Function Name > > - Hash Selection Range > > - optional parameters (e.g. random seed) > > case fs_flow_state_dependent_flow_selection: > > - accuracy paramter > > - frequency threshold (in per cent of observed packets) > > The above list of parameters for flow dependent flow selection > techniques is suitable for the presented Frequent Item and Lossy > Counting Algorithm. Nevertheless there exist a variety of techniques > with very specific parameters which are not defined here. > > 6.2. Description of Flow Sampling Techniques > > In this section, we define what elements are needed to describe the > most common Flow Sampling techniques. > > > > > > > > D'Antonio, et al. Expires November 24, 2011 [Page 16] > > Internet-Draft Flow Selection Techniques May 2011 > > > +----------------+---------------------------+ > | FS_SELECTOR_ID | FS_TYPE | > +----------------+---------------------------+ > |5 | fs_systematic_count-based | s/5/4/ > +----------------+---------------------------+ > | 5 | fs_systematic_time-based | > +----------------+---------------------------+ > | 6 | fs_n-out-of-N | > +----------------+---------------------------+ > | 7 | fs_probabilistic | > +----------------+---------------------------+ > > FS_SELECTOR_PARAMETERS: > > case systematic count-based: > > - Interval length (number of new observed flows) > > - Spacing (number of new observed flows) > > case fs_systematic_time-based: > > - Interval length (in usec) > > - Spacing (in usec) > > case fs_random n-out-of-N: > > - Population Size N > > - Sample size n > > case fs_probabilistic: > > - Sampling probability p > > 6.3. Description of Flow State Dependent Packet Selection > > The configuration of flow dependent packet selection has not been > described in [RFC5475] therefore the paramaters are defined here: > > SELECTOR_TYPE: flow_dependent_packet_selection > > SELECTOR_PARAMETERS: > > > > > > > > D'Antonio, et al. Expires November 24, 2011 [Page 17] > > Internet-Draft Flow Selection Techniques May 2011 > > > - packet selection probability per possible flow state interval > > - additional parameters (e.g. packet properties as in [EsVa01]) > > > 7. Information Model for Flow Selection Reporting > > In this section we describe Information Elements (IEs) that SHOULD be > exported by a flow selection process in order to support the > interpretation of measurement results from flow measurements where > only some flows are selected. The information is mainly used to > report how many packets and flows have been observed in total and how > many of themwhere selected. This helps for instance to calculate Typo. > the attained sampling fraction, which is an important parameter to > provide an accuracy statement. The IEs can provide reporting > information about flow records, flow cache entries, packets or bytes. > The reported metrics arenumber of total and the number of selected "total number" > elements. From this the number of dropped elements can be derived. > All counters are delta counters andSHOULD be exported and reset when What happens if they're not? > a new measurement interval starts. Additional IEs may be useful for > future flow selection techniques. Those can be defined additionally > if needed. > > List of additional Flow Selection information elements: > > +-------+---------------------------+ > | ID | Name | > +-------+---------------------------+ > | TBD1 | fsFlowRecordTotalCount | > +-------+---------------------------+ > | TBD2 | fsFlowRecordSelectedCount | > +-------+---------------------------+ > | TBD3 | fsCurrentFlowEntries | > +-------+---------------------------+ > | TBD4 | fsMaxFlowEntries | > +-------+---------------------------+ > | TBD5 | fsFlowEntryTotalCount | > +-------+---------------------------+ > | TBD6 | fsFlowEntrySelectedCount | > +-------+---------------------------+ > | TBD7 | fsPacketTotalCount | > +-------+---------------------------+ > | TBD8 | fsPacketSelectedCount | > +-------+---------------------------+ > | TBD9 | fsOctetTotalCount | > +-------+---------------------------+ > | TBD10 | fsOctetSelectedCount | > +-------+---------------------------+ > > > > D'Antonio, et al. Expires November 24, 2011 [Page 18] > > Internet-Draft Flow Selection Techniques May 2011 > > > 7.1. fsFlowRecordTotalCount > > Description: > > This Information Element specifies the current number of all Flow > Records that form the parent population as input to the Flow > Selection Process. > > Abstract Data Type: unsigned64 > > ElementId: TBD1 > > Status:Proposed I don't think you should write the status here, because it must be changed to "current" before the doc is published. Thereafter it'll never change, even if the field is obsoleted. Rather, "Status" should be a property only recorded in the IANA registry. > Units: Flow Records > > 7.2. fsFlowRecordSelectedCount > > Description: > > This Information Element specifies the current number Flow Records > that were selected during the Flow Selection Process. > > Abstract Data Type: unsigned64 > > ElementId: TBD2 > > Status: Proposed > > Units: Flow Records > > 7.3. fsCurrentFlowEntries > > Description: > > This Information Element specifies the current number offlow > entries in theflow cache. They're not "flow entries", but "cache entries". This assumes that the implementation is cache based. The description is ambiguous: it's not clear whether it means the overall size of the cache (especially where that size can be changed dynamically), or whether it means how many of the cache entries are consumed. > Abstract Data Type: unsigned64 > > ElementId: TBD3 > > Status: Proposed > > Units:Flow Entries Again, "cache entries". > > > > > D'Antonio, et al. Expires November 24, 2011 [Page 19] > > Internet-Draft Flow Selection Techniques May 2011 > > > 7.4. fsMaxFlowEntries > > Description: > > This Information Element specifies the maximum number offlow > entries in the flow cache. Why is this needed? It sounds like something from the configuration draft. > Abstract Data Type: unsigned64 > > ElementId: TBD4 > > Status: Proposed > > Units:Flow Entries > > 7.5. fsFlowEntryTotalCount > > Description: > > This Information Element specifies the current number of all Flow > Entries that form the parent population as input to the Flow > Selection Process. > > Abstract Data Type: unsigned64 > > ElementId: TBD5 > > Status: Proposed > > Units: Flow Entries > > 7.6. fsFlowEntrySelectedCount > > Description: > > This Information Element specifies the current number Flow entries > that were selected during the Flow Selection Process. > > Abstract Data Type: unsigned64 > > ElementId: TBD6 > > Status: Proposed > > Units: Flow Entries > > > > > > > D'Antonio, et al. Expires November 24, 2011 [Page 20] > > Internet-Draft Flow Selection Techniques May 2011 > > > 7.7. fsPacketTotalCount > > Description: > > This Information Element specifies the current number of packets > in all flows that form the parent population as input to the Flow > Selection Process. > > Abstract Data Type: unsigned64 > > ElementId: TBD7 > > Status: Proposed > > Units: Packets > > 7.8.fsFlowEntrySelectedCount s/fsFlowEntrySelectedCount/fsPacketSelectedCount/ > Description: > > This Information Element specifies the current number packets in > all flows that were selected during the Flow Selection Process. > > Abstract Data Type: unsigned64 > > ElementId: TBD8 > > Status: Proposed > > Units: Packets > > 7.9. fsOctetTotalCount > > Description: > > This Information Element specifies the current number of all bytes > in all flows that form the parent population as input to the Flow > Selection Process. > > Abstract Data Type: unsigned64 > > ElementId: TBD9 > > Status: Proposed > > Units:Bytes s/Bytes/octets/ > > > > D'Antonio, et al. Expires November 24, 2011 [Page 21] > > Internet-Draft Flow Selection Techniques May 2011 > > > 7.10. fsOctetSelectedCount > > Description: > > This Information Element specifies the current number of bytes in > all flows that were selected during the Flow Selection Process. > > Abstract Data Type: unsigned64 > > ElementId: TBD10 > > Status: Proposed > > Units:Bytes s/Bytes/octets/ > 8. IANA Considerations > > This document introduces several new information elements as an > extension to the IPFIX information model. Values TBD1-TBD10in this > document should be replaced with the assigned numbers by IANA. More specifically, "in section 7 of this document". This section doesn't specifically request that IANA make the allocations, and it should specifically say that. Cheers, P. > 9. Security Considerations > > In this section security issues concerning an IPFIX device performing > flow selection are pointed out. In case the flow selection function > is activated an IPFIX device might be exposed to security threats. > Since flow selection implies analysing flow packets, associating them > to a specific traffic flow and selecting flow records, a malicious > user who was able to gain control of an IPFIX device might access > both packet and flow data, thus violating their confidentiality. > > Furthermore, the intruder might be attracted by the possibility of > altering the flow selection process by modifying the criteria used to > select flow records. In this case, the IPFIX device would export > flow data which are different from the ones that the Collector > expects to receive. > > It is apparent that these security threats can be mitigated by > authenticating entities that interact with the IPFIX device and > keeping information for flow selection configuration confidential. > > > 10. References > > > > > > > D'Antonio, et al. Expires November 24, 2011 [Page 22] > > Internet-Draft Flow Selection Techniques May 2011 > > > 10.1. Normative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > 10.2. Informative References > > [CoHa08] Cormode, G. and M. Hadjieleftheriou, "Finding frequent > items in data streams", Journal, Proceedings of the Very > Large DataBase Endowment VLDB Endowment, Volume 1 Issue 2, > August 2008, August 2008. > > [DuLT01a] Duffield, N., Lund, C., and M. Thorup, "Charging from > Sampled Network Usage", ACM Internet Measurement Workshop > IMW 2001, San Francisco, USA, November 2001. > > [DuLT01b] Duffield, N., Lund, C., and M. Thorup, "Properties and > Prediction of Flow Statistics from Sampled Packet > Streams", ACM SIGCOMM Internet Measurement Workshop 2002, > November 2002. > > [EsVa01] Estan, C. and G,. Varghese, "New Directions in Traffic > Measurement and Accounting: Focusing on the Elephants, > Ignoring the Mice", ACM SIGCOMM Internet Measurement > Workshop 2001, San Francisco (CA), November 2001. > > [KaPS03] Karp, R., Papadimitriou, C., and S. S. Shenker, "A simple > algorithm for finding frequent elements in sets and > bags.", ACM Transactions on Database Systems, Volume 28, > 51-55, 2003, March 2003. > > [KuXW04] Kumar, K., Xu, J., Wang, J., Spatschek, O., and L. Li, > "Space-code bloom filter for efficient per-flow traffic > measurement", INFOCOM 2004 Twenty-third AnnualJoint > Conference of the IEEE Computer and Communications > Societies, March 2004. > > [MSZC10] Mai, J., Sridharan, A., Zang, H., and C. Chuah, "Fast > Filtered Sampling", Computer Networks Volume 54, Issue 11, > Pages 1885-1898, ISSN 1389-1286, January 2010. > > [MaMo02] Manku, G. and R. Motwani, "Approximate Frequency Counts > over Data Streams", Proceedings of the Internation > Conference on Very large DataBases (VLDB) pages 346--357, > 2002, Hong Kong, China, 2002. > > [Moli03] Molina, M., "A scalable and efficient methodology for flow > monitoring in the Internet", International Teletraffic > > > > D'Antonio, et al. Expires November 24, 2011 [Page 23] > > Internet-Draft Flow Selection Techniques May 2011 > > > Congress (ITC-18), Berlin, September 2003. > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > "Requirements for IP Flow Information Export (IPFIX)", > RFC 3917, October 2004. > > [RFC5101] Claise, B., "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic > Flow Information", RFC 5101, January 2008. > > [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. > Meyer, "Information Model for IP Flow Information Export", > RFC 5102, January 2008. > > [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, > "Architecture for IP Flow Information Export", RFC 5470, > March 2009. > > [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. > Raspall, "Sampling and Filtering Techniques for IP Packet > Selection", RFC 5475, March 2009. > > [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling > (PSAMP) Protocol Specifications", RFC 5476, March 2009. > > [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, > "IP Flow Information Export (IPFIX) Mediation: Framework", > RFC 6183, April 2011. > > > Authors' Addresses > > Salvatore D'Antonio > CINI Consortium/University of Napoli "Parthenope" > Monte S.Angelo, Via Cinthia > Napoli 80126 > Italy > > Phone: +39 081 679944 > Email:salvatore.dantonio@parthenope.it > > > > > > > > > > > > D'Antonio, et al. Expires November 24, 2011 [Page 24] > > Internet-Draft Flow Selection Techniques May 2011 > > > Tanja Zseby > Fraunhofer Institute FOKUS > Kaiserin-Augusta-Allee 31 > Berlin 10589 > Germany > > Phone: +49 30 3463 7153 > Email:tanja.zseby@fokus.fraunhofer.de > > > Christian Henke > Technische Universitat Berlin > Strasse des 17. Juni 135 > Berlin 10623 > Germany > > Phone: +49 30 3463 7366 > Email:c.henke@tu-berlin.de > > > Lorenzo Peluso > University of Napoli > Via Claudio 21 > Napoli 80125 > Italy > > Phone: +39 081 7683821 > Email:lorenzo.peluso@unina.it > > > > > > > > > > > > > > > > > > > > > > > > D'Antonio, et al. Expires November 24, 2011 [Page 25] > --------------070800050200020304050907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear All,

Please find some review comments inline.
Hopefully you can see the red highlighting too.

P.

Internet Engineering Task Force                             S. D'Antonio
Internet-Draft                             CINI Consortium/University of
Intended status: Standards Track                     Napoli "Parthenope"
Expires: November 24, 2011                                      T. Zseby
                                              Fraunhofer Institute FOKUS
                                                                C. Henke
                                           Technische Universitat Berlin
                                                               L. Peluso
                                                    University of Napoli
                                                            May 23, 2011


                       Flow Selection Techniques
              draft-ietf-ipfix-flow-selection-tech-06.txt

Abstract

   Flow selection is the process of selecting a subset of flows from all
   flows observed at an observation point.  Flow selection reduces the
   effort of post-processing flow data and transferring flow records.
   This document describes motivations for flow selection and presents
   flow selection techniques.  It provides an information model for
   configuring flow selection techniques and discusses what information
   about a flow selection process should be exported.

Requirements Language

   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].

Status of this Memo

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

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

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

   This Internet-Draft will expire on November 24, 2011.




D'Antonio, et al.       Expires November 24, 2011               [Page 1]

Internet-Draft          Flow Selection Techniques               May 2011


Copyright Notice

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

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

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

























D'Antonio, et al.       Expires November 24, 2011               [Page 2]

Internet-Draft          Flow Selection Techniques               May 2011


Table of Contents

   1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Difference between Flow Selection and Packet Selection . . . .  6
   4.  Flow selection as Function in the IPFIX Architecture . . . . .  7
     4.1.  Flow selection in the Metering Process before
           Aggregation  . . . . . . . . . . . . . . . . . . . . . . .  9
     4.2.  Flow selection in the Metering Process after
           Aggregation  . . . . . . . . . . . . . . . . . . . . . . .  9
     4.3.  Flow selection during the Exporting Process  . . . . . . .  9
     4.4.  Flow selection as a function of the IPFIX Mediator . . . . 10
   5.  Flow Selection Techniques  . . . . . . . . . . . . . . . . . . 10
     5.1.  Flow Filtering . . . . . . . . . . . . . . . . . . . . . . 10
       5.1.1.  Property Match Filtering . . . . . . . . . . . . . . . 10
       5.1.2.  Hash-based Flow Filtering  . . . . . . . . . . . . . . 11
       5.1.3.  Flow State Dependent Flow Filtering  . . . . . . . . . 11
     5.2.  Flow Sampling  . . . . . . . . . . . . . . . . . . . . . . 12
       5.2.1.  Systematic Sampling  . . . . . . . . . . . . . . . . . 12
       5.2.2.  Random Sampling  . . . . . . . . . . . . . . . . . . . 12
     5.3.  Flow-state Dependent Packet Selection  . . . . . . . . . . 13
   6.  Information Model for Configuration of Flow Selection
       Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  Description of Flow Filtering Techniques . . . . . . . . . 15
     6.2.  Description of Flow Sampling Techniques  . . . . . . . . . 16
     6.3.  Description of Flow State Dependent Packet Selection . . . 17
   7.  Information Model for Flow Selection Reporting . . . . . . . . 18
     7.1.  fsFlowRecordTotalCount . . . . . . . . . . . . . . . . . . 19
     7.2.  fsFlowRecordSelectedCount  . . . . . . . . . . . . . . . . 19
     7.3.  fsCurrentFlowEntries . . . . . . . . . . . . . . . . . . . 19
     7.4.  fsMaxFlowEntries . . . . . . . . . . . . . . . . . . . . . 20
     7.5.  fsFlowEntryTotalCount  . . . . . . . . . . . . . . . . . . 20
     7.6.  fsFlowEntrySelectedCount . . . . . . . . . . . . . . . . . 20
     7.7.  fsPacketTotalCount . . . . . . . . . . . . . . . . . . . . 21
     7.8.  fsFlowEntrySelectedCount . . . . . . . . . . . . . . . . . 21
     7.9.  fsOctetTotalCount  . . . . . . . . . . . . . . . . . . . . 21
     7.10. fsOctetSelectedCount . . . . . . . . . . . . . . . . . . . 22
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
     10.2. Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24








D'Antonio, et al.       Expires November 24, 2011               [Page 3]

Internet-Draft          Flow Selection Techniques               May 2011


1.  Scope

   This document describes flow selection techniques for traffic
   measurements.  A flow is defined as a set of packets with common

"for traffic measurements" doesn't add anything.


   properties as described in [RFC5101].  Flow selection can be done to
   limit the resource demands for capturing, storing, exporting and
   post-processing of flow records.  It also can be used to select a
   particular set of flows that are of interest to a specific
   application.  This document provides a cathegorization of flow

Typo.


   selection techniques and describes configuration and reporting
   parameters for them.  In order to be compliant with this document, at
   least one of proposed flow selection schemes MUST be implemented.
   That means that the configuration parameters as well as the reporting
   information elements for this particular scheme MUST be supported.

Capitalised?


   This document also addresses configuration and reporting parameters
   for flow-state dependent packet selection as described in [RFC5475],
   although the technique is categorized as packet selection.  The

"that" ?


   reason is, thta flow-state dependent packet selection techniques

Typo.


   often aim at the reduction of resources for flow capturing and flow
   processing.  Furthermore, they were only briefly discussed in
   [RFC5475].  Therefore we included configuration and reporting
   considerations for such techniques in this document.


2.  Terminology

   This document is consistent with the terminology introduced in
   [RFC5101], [RFC5470], [RFC5475] and [RFC3917].  As in [RFC5101] and
   [RFC5476], the first letter of each IPFIX-specific and PSAMP-specific
   term is capitalized along with the flow selection specific terms
   defined here.

   * Classification

      Classification is a process in which packets are mapped to

"by" ?


      specific flow records based on packet properties.  These

The mapping may not be due to packet properties, eg interface or ACL.


      properties make up the flow key (e.g. header information, packet
      content, AS number).  In case a flow record for a specific flow
      key already exists the flow record is updated, otherwise a new
      flow record is created.

   * Flow Selection Process

      A Flow Selection Process takes classified packets, flow cache
      entries or flow records as its input and selects a subset of that

Surely a process taking packets as inputs would be a packet selection process?


      set as its output.  A Flow Selection Process MAY run on several
      instances within the IPFIX architecture.  A Flow Selection Process

"in several places" ?



D'Antonio, et al.       Expires November 24, 2011               [Page 4]

Internet-Draft          Flow Selection Techniques               May 2011


      MAY be part of an IPFIX metering process, exporting process or as

Please capitalise these terms.


      an Intermediate Selection Process running on an IPFIX Mediator.

This term is not defined, although it's used several times in this document.


   * Flow Selection State

      A Flow Selection Process SHOULD maintain state information for use
      by the Flow Selector.  At a given time, the Flow Selection State
      may depend on flows and packets observed at and before that time,
      as well as other variables.  Examples include:

        (i)   sequence number of packets and accounted flow records;

        (ii)  number of selected flows;

        (iii) number of observed flows;

        (iv)  current flow cache occupancy;

        (v)   flow specific counters, lower und upper bounds

        (vi)  flow selection timeout intervals

   * Flow Selector

      A Flow Selector defines the action of a Flow Selection Process on
      a single flow of its input.  The Flow Selector can make use of the
      following information in order to establish whether a flow has to
      be selected or not:

        (i)   the content of the flow record;

        (ii)  any state information related to the metering or exporting
              process;

"Metering Process or Exporting Process".


        (iii) any Flow Selection State that may be maintained by the
              Flow Selection Process.

   * Complete Flow

      A Complete Flow consists of all packets within the flow time-Out
      interval that enter the Flow Selection Process and belong to the
      same flow as defined by the flow definition.  For this definition

What does "flow definition" mean? Is it the key fields?


      only packets are considered that arrive at the Flow Selection

"For this definition only packets that arrive at the Flow Selection Process are considered."


      Process.  That means, packets that are not observed at the Flow
      Selection Process because of prior packet selection or packet loss
      are not considered as belonging to the Complete Flow.

Therefore the "Complete Flow" can be incomplete. Can you find a better term, eg "Measured Flow" ?


   * Flow Filtering



D'Antonio, et al.       Expires November 24, 2011               [Page 5]

Internet-Draft          Flow Selection Techniques               May 2011


      Flow Filtering selects flows based on a deterministic function on
      the flow record content, flow state, external properties (e.g.
      ingress interface) or external events (e.g violated Access Control
      List).  If the relevant parts of the flow record content can be
      already observed at packet level (e.g. flow keys from packet
      header fields) Flow Filtering can be performed at packet level by
      property match packet filtering as described in [RFC5475].

   * Flow Sampling

      Flow Sampling selects flows based on flow record sequence or
      arrival times (e.g. position in flow cache, arrival time at

That would be implementation dependant.


      exporter or mediator).  The selection can be systematic (e.g.

Please capitalise your terminology.


      every n-th record) or based on a random functions (e.g. select
      each record with probability p, or randomly select n out of N
      records).

s/record/flow/


   * Aggregation Process

      In the IPFIX metering process the aggregation process aggregates
      packet data into flow data and forms the flow cache entries or
      flow records.  After the aggregation step only the aggregated flow
      information is available.  Information about individual packets is
      lost.


3.  Difference between Flow Selection and Packet Selection

   Flow selection differs from packet selection described in [RFC5475].
   Packet selection techniques consider packets as basic element and the
   parent population consists of all packets observed at an observation
   point.  In contrast to this the basic elements in flow selection are
   the flows.  The parent population consists of all observed flows and
   the selection process operates on the flows.  The major
   characteristics of flow selection are the following:

   -       Flow selection takes flows as basic elements.  For packet
           selection, packets are considered as basic elements.

   -       Flow selection can only take place after classification,
           because the classification rules determine to which flow a
           packet belongs.  Packet selection can be applied before or
           after classification.

   -       Flow selection operates on complete flows.  That means that
           after the flow selection process either all packets of the
           flow are kept or all packets of the flow are discarded.  All
           packets of the flow here means all packets that enter the



D'Antonio, et al.       Expires November 24, 2011               [Page 6]

Internet-Draft          Flow Selection Techniques               May 2011


           flow selection process.  That means that if the flow
           selection is preceded by a packet selection process the
           complete flow consists only of the packets that where not
           discarded during the packet selection.

"were".


   There are some techniques that are difficult to unambiguously
   categorize into one of the categories.  We here give some guidance

"Here we give"


   how to categorize such techniques:

   -       Techniques that can be considered as both, packet and flow

Remove the comma.


           selection: Some packet selection techniques result in the
           selection of whole flows and therefore can be considered as

What is a "whole flow" ?


           packet or as flow selection at the same time.  An example is
           property match filtering of all packets to a specific
           destination address.  If flows are defined based on
           destination addresses, such a packet selection also results
           in a flow selection and can be considered as packet or flow
           selection.

   -       Flow-state dependent packet selection (as described in
           [RFC5475]): There exist techniques that select packets based
           on the flow state, e.g. based on the number of already
           observed packets belonging to the flow.  Examples of these
           techniques from the literature are "Sample and Hold" [EsVa01]
           "Fast Filtered Sampling" [MSZC10] or the "Sticky Sampling"
           algorithm presented in [MaMo02].  Such techniques can be used
           to influence which flows are captured (e.g. increase the
           selection of packets belonging to large flows) and reduce the
           number of flows that need to be stored in the flow cache.
           Nevertheless, such techniques do not necessarily select
           Complete Flows, because it is not ensured that all packets of

"they do not ensure"


           a selected flow are captured.  Therefore flow-state dependent
           packet selection methods that do not ensure that either all
           or no packets of a flow are selected strictly speaking have
           to be considered as packet selection technique and not as

"techniques"


           flow selection.

Append "techniques".


4.  Flow selection as Function in the IPFIX Architecture

"as a Function"


   Figure 1 shows the IPFIX reference model as defined in [RFC5470], and
   extends it by introducing the functional components where flow
   selection can take place.

                       Packet(s) coming in to Observation Point(s)
                         |                                     |
                         v                                     v
        +----------------+---------------------------+   +-----+-------+



D'Antonio, et al.       Expires November 24, 2011               [Page 7]

Internet-Draft          Flow Selection Techniques               May 2011


        |          Metering Process                  |   |             |
        |                                            |   |             |
        |   packet header capturing                  |   |             |
        |        |                                   |...| Metering    |
        |   timestamping                             |   | Process N   |
        |        |                                   |   |             |
        |   packet selection                         |   |             |
        |        |                                   |   |             |
        |   classification                           |   |             |
        |        |                                   |   |             |
        |   flow state dependent packet selection    |   |             |
        |        |                                   |   |             |
        |   flow selection before aggregation (*)    |   |             |
        |        |                                   |   |             |
        |   aggregation                              |   |             |
        |        |                                   |   |             |
        |   flow selection after aggregation (*)     |   |             |
        +--------|-----------------------------------+   +-----|-------+
            Flow Records                                   Flow Records
                 |                                             |
                 +----------------------+----------------------+
                                        |
                 +----------------------|-----------------+
                 | Exporting Process    |                 |
                 |                      v                 |
                 |        flow selection before export(*) |
                 |                      |                 |
                 |                      v                 |
                 |                 flow export            |
                 +----------------------+-----------------+
                                        |  IPFIX (Flow Records)
                                        v
              +-------------------------|-----------------------+
              |  IPFIX Mediator         |                       |
              |                         v                       |
              |               Collecting Process(es)            |
              |                         |                       |
              |      Intermediate Flow Selection Process (*)    |
              |                         |                       |
              |               Exporting Process(es)             |
              +-------------------------|-----------------------+
                                        v
                                      IPFIX

The latter two parts of the Mediator constitute another Exporting Process.

As such, the "flow selection before export" and "Intermediate Flow Selection Process" are identical.


         (*) indicates where flow selection can take place.

            Figure 1: Flow selection in the IPFIX Architecture




D'Antonio, et al.       Expires November 24, 2011               [Page 8]

Internet-Draft          Flow Selection Techniques               May 2011


   In contrast to packet selection, flow selection is always applied
   after the packets are classified into flows.  Flows can be selected
   at different stages of the measurement chain:

   1.  during Metering Process before aggregation

   2.  during Metering Process after aggregation;

   3.  during Exporting Process

   4.  in an Intermediate Selection Process on a Mediator

Again, 3+4 are identical.


4.1.  Flow selection in the Metering Process before Aggregation

   In the aggregation process the packet information is used to update
   the flow entries in the flow cache.  Flow selection that is applied
   before aggregation equals a packet selection process.  The flow still
   consists of individual packets.  Those are then selected based on the
   classification information, i.e. based on the flow they belong to.
   Flow selection before aggregation can be based on the fields of the
   flow key (also on a hash value over these fields), but not based on
   characteristics that are only available after aggregation (e.g. flow
   size, flow duration).  Flow selection before aggregation is applied
   to reduce resources for all succeeding processes (aggregation,
   exporting process) or select specific flows of interest in case such
   flow characteristics are already observable at packet level (e.g.
   flows to specific IPs).  In contrast, flow state dependent packet

Say, "IP addresses".


   selection is a packet selection method, because it does not
   necessarily select Complete Flows.  Flow selection before aggregation
   and flow state dependent packet selection can be applied in arbitrary
   order.

4.2.  Flow selection in the Metering Process after Aggregation

   Flow selection after aggregation is usually applied to reduce the
   flows to those that are of interest to a particular application and
   to unload flow export and flow postprocessing.  Since the flow cache
   entries are already generated by the aggregation process flow

"process, flow"


   selection after aggregation can also depend on flow characteristics
   that are only visible after the aggregation of packets, such as flow
   size and flow duration.

4.3.  Flow selection during the Exporting Process

   The Exporting Process may implement policies for exporting only a
   subset of the flow records which have been stored in the system
   memory.  Flow selection in the exporting process may select only the
   subset of flow records which are of interest to the users



D'Antonio, et al.       Expires November 24, 2011               [Page 9]

Internet-Draft          Flow Selection Techniques               May 2011


   application, or select only as many flow records than can be handled

s/than/as/


   by the available resources ( e.g. limited flow cache size and export
   link capacity).

Extra space.


4.4.  Flow selection as a function of the IPFIX Mediator

   As shown in Figure 1, flow selection can be performed as an
   intermediate process within an IPFIX Mediator [RFC6183].  The
   Intermediate Selection Process takes a flow record stream as its
   input and retrieves a record stream.  The Intermediate Selection
   Process can again apply a flow selection technique to obtain flows of
   interest for the application.  Further the Intermediate Selection
   Process can base its selection decision on the correlation of data
   from different observation points, e.g by only selecting flows that
   were at least recorded on two observation points.

These actions can also be performed in 4.3.


5.  Flow Selection Techniques

   A flow selection technique selects either all packets or none of a
   flow, otherwise the technique has to be considered as packet

"all or none of the packets of a flow"


   selection.  We distinguish between Flow Filtering and Flow Sampling.

5.1.  Flow Filtering

   Flow Filtering is a deterministic function on the IPFIX flow record
   content.  In case that the relevant flow characteristics are already
   observable at packet level (e.g. flow keys) Flow Filtering can be
   applied before aggregation at packet level.

5.1.1.  Property Match Filtering

   Flow Filtering can be done similarly to Property Match Filtering for
   packet selection described in [RFC5475].  The difference is that,
   instead of packet fields, flow record fields are here used to derive

Remove "here".


   the selection decision.  Property Match Filtering is typically used
   to select a specific subset of the flows that are of interest to a
   particular application (e.g. all flows to a specific destination, all
   large flows, etc.).  Properties on which the filtering is based can
   be for example flow keys, the flow size in bytes, the number of
   packets in the flow, the observation time of the first or last
   packet, or the maximum packet length.  The selection criteria can be
   a specific value or an interval.  Property match filtering can be
   applied before aggregation in case the properties are already

s/in case/if/


   observable at the packet level (e.g. flow key fields).

   There are content based Property Match filtering techniques that
   require a compution on the current flow cache.  An example is the

"computation"?



D'Antonio, et al.       Expires November 24, 2011              [Page 10]

Internet-Draft          Flow Selection Techniques               May 2011


   selection of the k largest flows or a percentage of flows with the
   longest livetime.  This type of Property Match Filtering is also used
   in flow selection techniques that react on external events (e.g.

"react to"


   resource constraint).  For example in case the flow cache is full,
   the flow cache entry with the lowest flow volume per current flow
   live time is deleted.

Typo, "life".

You say "current flow life time" as if there are different possibilities?


5.1.2.  Hash-based Flow Filtering

   Hash-based Flow Filtering uses a Hash Function h to map the flow key
   c onto a Hash Range R. A flow is selected if the hash value h(c) is
   within the Hash Selection Range S, which is a subset of R. Hash-based
   Flow Filtering can be used to emulate a random sampling process but
   still enable the correlation between selected flow subset at
   different observation points.  Hash-based Flow Filtering is similar
   to Hash-based Packet Selection, and in fact is identical when Hash-
   based Packet Selection uses the flow key that define the flow as the
   Hash Input.  Nevertheless there MAY be the incentive to apply Hash-
   based Flow Selection not on the packet level before aggregation, for
   example when the size of the Selection Range and therefore the
   sampling probability is dependent on the number of observed flows.

5.1.3.  Flow State Dependent Flow Filtering

   Flow state dependent filtering does not base the selection decision
   on fields of the current flow record content but on the flow state
   which may be kept additionally for each of the flows.  External
   processes may update counters, bounds and timers for each of the flow
   records and the flow selection process utilises this information for
   the selection decision.  A review of flow state dependent filtering
   techniques that aim at the selection of the most frequent items by
   keeping additional flow state information can be found in [CoHa08].
   Flow state dependent flow filtering can only be applied after
   aggregation, when a packet has been assigned to a flow cache.  The

Either the packet is assigned to a Flow, or to a cache entry - but not to a flow cache.


   selection process then decides based upon the flow state for each
   flow if it is kept in the flow cache or not.  Two flow dependent flow
   filtering techniques are here described:

Should these be 5.1.3.1 and 5.1.3.2 ?


   The Frequent Algorithm [KaPS03] is a technique that aims at the
   selection of all flows that at least exceed a 1/k fraction of the
   observed packet stream.  The algorithm has only a flow cache of size
   k-1 and each flow in the cache has an additional counter.  The
   counter is incremented each time a packet belonging to the flow in
   the flow cache is observed.  In case the observed packet does not
   belong to any flow all counters are decremented and if any of the
   flow counters have a value of zero the flow is replaced with the new
   flow.

Presumably "with a flow formed from the new packet"?




D'Antonio, et al.       Expires November 24, 2011              [Page 11]

Internet-Draft          Flow Selection Techniques               May 2011


   Lossy Counting is a selection technique that identifies all flows
   whose packet count exceeds a certain percentage of the whole observed
   packet stream (e.g. 5% of all packets) with a certain estimation
   error e.  Lossy Counting seperates the observed packet stream in
   windows of size N=1/e, where N is an amount of consecutive packets.
   For each observed flow an additional counter will be held in the flow
   state.  The counter is incremented each time a packet belonging to
   the flow is observed and all counters are decremented at the end of
   each window and all flows with a counter of zero will be removed from
   the flow cache.

5.2.  Flow Sampling

   Flow sampling operates on flow record sequence or arrival times.  It
   can use a systematic or a random functions for the selection process.
   Flow sampling usually aims at the selection of a representative
   subset of all flows in order to estimate characteristics of the whole
   set (e.g. mean flow size in the network).

5.2.1.  Systematic Sampling

   Systematic sampling is a deterministic selection function.
   Systematic sampling may be a periodic selection of the k-th flow
   record which arrives at the exporting or mediator process.
   Systematic Sampling can also be applied before aggregation.  An
   example would be to use an additional data structure that saves the
   flow keys of the not selected flows.  Then one can create a flow

"un-selected"?


   cache entry for the k-th observed packet that has yet no flow cache

"does not yet have a"


   entry and is not within the data structure containing the not
   selected flows.

   Systematic sampling can also be time-based.  Systematic Sampling is
   applied by only creating flows that are observed between time-based
   start and stop triggers.  The time interval may be applied at packet
   level or after aggregation level, e.g. by selecting every k seconds a
   flow arriving at the export process.

"by selecting a flow arriving at the export process every k seconds".

What if the export is irregular, so nothing arrives at the required time?
- export the next flow which arrives, or export nothing?


5.2.2.  Random Sampling

   Random flow sampling is based on a random process which requires the
   calculation of random numbers.  One can differentiate between n-out-N
   and probabilistic sampling.  The sampling probability of individual
   flows records MAY be adjusted according to the flow record content or
   external events like the available export resources.  Non-uniform
   random sampling approaches can be applied similar to the ones defined
   in [RFC5475].  An example would be to prefer large volume flows over
   small volume flows.  Random flow sampling can also be applied before

Out of scope of this doc, but surely this method ensures that the large get larger while the small never get a chance to grow.
So the observation may be skewed by the initial observations.


   aggregation when additional flow state about non selected flows is



D'Antonio, et al.       Expires November 24, 2011              [Page 12]

Internet-Draft          Flow Selection Techniques               May 2011


   kept.

5.3.  Flow-state Dependent Packet Selection

   As explained above Flow-state Dependent Packet Selection is not a
   Flow Selection Technique but a packet selection.  Nevertheless we

"a packet selection technique".


   will describe configuration and reporting parameters for this
   technique in this document.  An example is the the "Sample and Hold"
   algorithm [EsVa01] that tries to prefer large volume flows in the
   selection.  When a packet arrives it is selected when already a flow
   cache entry for this packet exists.  In case there is no flow cache

"when a flow cache entry for this packet already exists."


   entry, the packet is selected by a certain probability that is
   dependent on the packet size.


6.  Information Model for Configuration of Flow Selection Techniques

How exactly would the reader use this configuration model?


   This section describes the configuration parameters of the flow
   selection techniques presented above.  It provides the basis of an
   information model to be adopted in order to configure the flow
   selection process within an IPFIX device.  The following table gives
   an overview of the defined selection techniques, where they can be
   applied and what are their input parameters.  Dependent on where the

"what their input parameters are".


   flow selection techniques are applied different input parameters can
   be configured.

   Overview of Flow Selection Techniques:
























D'Antonio, et al.       Expires November 24, 2011              [Page 13]

Internet-Draft          Flow Selection Techniques               May 2011


   +------------------+-----------------+------------------------------+
   | Location         | Selection       | Selection Input              |
   |                  | Method          |                              |
   +------------------+-----------------+------------------------------+
   | before           | Flow State      | packet sampling              |
   | aggregation      | Dependent       | probabilities, flow state,   |
   |                  | Packet          | packet properties            |
   |                  | Selection       |                              |
   +------------------+-----------------+------------------------------+
   |                  | Property Match  | flow key fields, filter      |
   |                  | Flow Filtering  | function                     |
   +------------------+-----------------+------------------------------+
   |                  | Hash-Based Flow | selection range, hash        |
   |                  | Filtering       | function, flow key           |
   +------------------+-----------------+------------------------------+
   |                  | Time-based      | flow position (derived from  |
   |                  | Systematic Flow | arrival time of packets),    |
   |                  | Sampling        | flow state                   |
   +------------------+-----------------+------------------------------+
   |                  | Sequence-based  | flow position (derived from  |
   |                  | Systematic Flow | packet position), flow state |
   |                  | Sampling        |                              |
   +------------------+-----------------+------------------------------+
   |                  | Random Flow     | random number generator or   |
   |                  | Sampling        | list and packet position,    |
   |                  |                 | flow state                   |
   +------------------+-----------------+------------------------------+
   | after            | Property Match  | flow record content, filter  |
   | aggregation      | Flow Filtering  | function                     |
   +------------------+-----------------+------------------------------+
   |                  | Hash-Based Flow | selection range, hash        |
   |                  | Filtering       | function, hash input (flow   |
   |                  |                 | keys and other flow          |
   |                  |                 | properties)                  |
   +------------------+-----------------+------------------------------+
   |                  | Flow State      | flow state parameters        |
   |                  | Dependent Flow  |                              |
   |                  | Selection       |                              |
   +------------------+-----------------+------------------------------+
   |                  | Time-based      | flow arrival time, flow      |
   |                  | Systematic Flow | state                        |
   |                  | Sampling        |                              |
   +------------------+-----------------+------------------------------+
   |                  | Sequence-based  | flow position, flow state    |
   |                  | Systematic Flow |                              |
   |                  | Sampling        |                              |
   +------------------+-----------------+------------------------------+




D'Antonio, et al.       Expires November 24, 2011              [Page 14]

Internet-Draft          Flow Selection Techniques               May 2011


   +------------------+-----------------+------------------------------+
   |                  | Random Flow     | random number generator or   |
   |                  | Sampling        | list and flow position, flow |
   |                  |                 | state                        |
   +------------------+-----------------+------------------------------+
   | during Exporting | Property Match  | flow record content, filter  |
   | Process or in    | Flow Filtering  | function                     |
   | the Mediator     |                 |                              |
   +------------------+-----------------+------------------------------+
   |                  | Hash-Based Flow | selection range, hash        |
   |                  | Filtering       | function, flow key           |
   +------------------+-----------------+------------------------------+
   |                  | Time-based      | flow record arrival time     |
   |                  | Systematic Flow |                              |
   |                  | Sampling        |                              |
   +------------------+-----------------+------------------------------+
   |                  | Sequence-based  | flow record position         |
   |                  | Systematic Flow |                              |
   |                  | Sampling        |                              |
   +------------------+-----------------+------------------------------+
   |                  | Random Flow     | random number generator or   |
   |                  | Sampling        | list and flow position       |
   +------------------+-----------------+------------------------------+
   |                  | Flow State      | flow state parameters        |
   |                  | Dependent Flow  |                              |
   |                  | Selection       |                              |
   +------------------+-----------------+------------------------------+

   A flow selection configuration consists of FS_SELECTOR_ID, FS_TYPE,
   FS_SELECTOR PARAMETERS.

   FS_SELECTOR ID: Unique ID for the flow sampler

   FS_TYPE: Defines which algorithm is used.

   FS_SELECTOR_PARAMETERS: Defines the input parameter for the flow
   selection methods

6.1.  Description of Flow Filtering Techniques

   In this section, we define what elements are needed to describe the
   most common Flow Filtering techniques.









D'Antonio, et al.       Expires November 24, 2011              [Page 15]

Internet-Draft          Flow Selection Techniques               May 2011


        +----------------+----------------------------------------+
        | FS_SELECTOR_ID | FS_TYPE                                |
        +----------------+----------------------------------------+
        | 1              | fs_property_matching                   |
        +----------------+----------------------------------------+
        | 2              | fs_hashing                             |
        +----------------+----------------------------------------+
        | 3              | fs_flow_state_dependent_flow_selection |
        +----------------+----------------------------------------+

   FS_SELECTOR_PARAMETERS:

   case fs_property_matching:

   -   Information Element (from [RFC5102])

   -   Value or Value Interval

   case fs_hashing:

   -   Hash Domain (input bits from packet) - can be specified for IPv4
       or IPv6 or both

   -   Hash Function Name

   -   Hash Selection Range

   -   optional parameters (e.g. random seed)

   case fs_flow_state_dependent_flow_selection:

   -   accuracy paramter

   -   frequency threshold (in per cent of observed packets)

   The above list of parameters for flow dependent flow selection
   techniques is suitable for the presented Frequent Item and Lossy
   Counting Algorithm.  Nevertheless there exist a variety of techniques
   with very specific parameters which are not defined here.

6.2.  Description of Flow Sampling Techniques

   In this section, we define what elements are needed to describe the
   most common Flow Sampling techniques.







D'Antonio, et al.       Expires November 24, 2011              [Page 16]

Internet-Draft          Flow Selection Techniques               May 2011


              +----------------+---------------------------+
              | FS_SELECTOR_ID | FS_TYPE                   |
              +----------------+---------------------------+
              | 5              | fs_systematic_count-based |

s/5/4/


              +----------------+---------------------------+
              | 5              | fs_systematic_time-based  |
              +----------------+---------------------------+
              | 6              | fs_n-out-of-N             |
              +----------------+---------------------------+
              | 7              | fs_probabilistic          |
              +----------------+---------------------------+

   FS_SELECTOR_PARAMETERS:

   case systematic count-based:

   -   Interval length (number of new observed flows)

   -   Spacing (number of new observed flows)

   case fs_systematic_time-based:

   -   Interval length (in usec)

   -   Spacing (in usec)

   case fs_random n-out-of-N:

   -   Population Size N

   -   Sample size n

   case fs_probabilistic:

   -   Sampling probability p

6.3.  Description of Flow State Dependent Packet Selection

   The configuration of flow dependent packet selection has not been
   described in [RFC5475] therefore the paramaters are defined here:

   SELECTOR_TYPE: flow_dependent_packet_selection

   SELECTOR_PARAMETERS:







D'Antonio, et al.       Expires November 24, 2011              [Page 17]

Internet-Draft          Flow Selection Techniques               May 2011


   -   packet selection probability per possible flow state interval

   -   additional parameters (e.g. packet properties as in [EsVa01])


7.  Information Model for Flow Selection Reporting

   In this section we describe Information Elements (IEs) that SHOULD be
   exported by a flow selection process in order to support the
   interpretation of measurement results from flow measurements where
   only some flows are selected.  The information is mainly used to
   report how many packets and flows have been observed in total and how
   many of them where selected.  This helps for instance to calculate

Typo.


   the attained sampling fraction, which is an important parameter to
   provide an accuracy statement.  The IEs can provide reporting
   information about flow records, flow cache entries, packets or bytes.
   The reported metrics are number of total and the number of selected

"total number"


   elements.  From this the number of dropped elements can be derived.
   All counters are delta counters and SHOULD be exported and reset when

What happens if they're not?


   a new measurement interval starts.  Additional IEs may be useful for
   future flow selection techniques.  Those can be defined additionally
   if needed.

   List of additional Flow Selection information elements:

                   +-------+---------------------------+
                   | ID    | Name                      |
                   +-------+---------------------------+
                   | TBD1  | fsFlowRecordTotalCount    |
                   +-------+---------------------------+
                   | TBD2  | fsFlowRecordSelectedCount |
                   +-------+---------------------------+
                   | TBD3  | fsCurrentFlowEntries      |
                   +-------+---------------------------+
                   | TBD4  | fsMaxFlowEntries          |
                   +-------+---------------------------+
                   | TBD5  | fsFlowEntryTotalCount     |
                   +-------+---------------------------+
                   | TBD6  | fsFlowEntrySelectedCount  |
                   +-------+---------------------------+
                   | TBD7  | fsPacketTotalCount        |
                   +-------+---------------------------+
                   | TBD8  | fsPacketSelectedCount     |
                   +-------+---------------------------+
                   | TBD9  | fsOctetTotalCount         |
                   +-------+---------------------------+
                   | TBD10 | fsOctetSelectedCount      |
                   +-------+---------------------------+



D'Antonio, et al.       Expires November 24, 2011              [Page 18]

Internet-Draft          Flow Selection Techniques               May 2011


7.1.  fsFlowRecordTotalCount

   Description:

      This Information Element specifies the current number of all Flow
      Records that form the parent population as input to the Flow
      Selection Process.

   Abstract Data Type: unsigned64

   ElementId: TBD1

   Status: Proposed

I don't think you should write the status here, because it must be changed to "current" before the doc is published.
Thereafter it'll never change, even if the field is obsoleted.
Rather, "Status" should be a property only recorded in the IANA registry.


   Units: Flow Records

7.2.  fsFlowRecordSelectedCount

   Description:

      This Information Element specifies the current number Flow Records
      that were selected during the Flow Selection Process.

   Abstract Data Type: unsigned64

   ElementId: TBD2

   Status: Proposed

   Units: Flow Records

7.3.  fsCurrentFlowEntries

   Description:

      This Information Element specifies the current number of flow
      entries in the flow cache.

They're not "flow entries", but "cache entries".

This assumes that the implementation is cache based.

The description is ambiguous: it's not clear whether it means the overall size of the cache (especially where that size can be changed dynamically), or whether it means how many of the cache entries are consumed.


   Abstract Data Type: unsigned64

   ElementId: TBD3

   Status: Proposed

   Units: Flow Entries

Again, "cache entries".






D'Antonio, et al.       Expires November 24, 2011              [Page 19]

Internet-Draft          Flow Selection Techniques               May 2011


7.4.  fsMaxFlowEntries

   Description:

      This Information Element specifies the maximum number of flow
      entries in the flow cache.

Why is this needed? It sounds like something from the configuration draft.


   Abstract Data Type: unsigned64

   ElementId: TBD4

   Status: Proposed

   Units: Flow Entries

7.5.  fsFlowEntryTotalCount

   Description:

      This Information Element specifies the current number of all Flow
      Entries that form the parent population as input to the Flow
      Selection Process.

   Abstract Data Type: unsigned64

   ElementId: TBD5

   Status: Proposed

   Units: Flow Entries

7.6.  fsFlowEntrySelectedCount

   Description:

      This Information Element specifies the current number Flow entries
      that were selected during the Flow Selection Process.

   Abstract Data Type: unsigned64

   ElementId: TBD6

   Status: Proposed

   Units: Flow Entries






D'Antonio, et al.       Expires November 24, 2011              [Page 20]

Internet-Draft          Flow Selection Techniques               May 2011


7.7.  fsPacketTotalCount

   Description:

      This Information Element specifies the current number of packets
      in all flows that form the parent population as input to the Flow
      Selection Process.

   Abstract Data Type: unsigned64

   ElementId: TBD7

   Status: Proposed

   Units: Packets

7.8.  fsFlowEntrySelectedCount

s/fsFlowEntrySelectedCount/fsPacketSelectedCount/


   Description:

      This Information Element specifies the current number packets in
      all flows that were selected during the Flow Selection Process.

   Abstract Data Type: unsigned64

   ElementId: TBD8

   Status: Proposed

   Units: Packets

7.9.  fsOctetTotalCount

   Description:

      This Information Element specifies the current number of all bytes
      in all flows that form the parent population as input to the Flow
      Selection Process.

   Abstract Data Type: unsigned64

   ElementId: TBD9

   Status: Proposed

   Units: Bytes

s/Bytes/octets/





D'Antonio, et al.       Expires November 24, 2011              [Page 21]

Internet-Draft          Flow Selection Techniques               May 2011


7.10.  fsOctetSelectedCount

   Description:

      This Information Element specifies the current number of bytes in
      all flows that were selected during the Flow Selection Process.

   Abstract Data Type: unsigned64

   ElementId: TBD10

   Status: Proposed

   Units: Bytes

s/Bytes/octets/


8.  IANA Considerations

   This document introduces several new information elements as an
   extension to the IPFIX information model.  Values TBD1-TBD10 in this
   document should be replaced with the assigned numbers by IANA.

More specifically, "in section 7 of this document".

This section doesn't specifically request that IANA make the allocations, and it should specifically say that.


Cheers,
P.

9.  Security Considerations

   In this section security issues concerning an IPFIX device performing
   flow selection are pointed out.  In case the flow selection function
   is activated an IPFIX device might be exposed to security threats.
   Since flow selection implies analysing flow packets, associating them
   to a specific traffic flow and selecting flow records, a malicious
   user who was able to gain control of an IPFIX device might access
   both packet and flow data, thus violating their confidentiality.

   Furthermore, the intruder might be attracted by the possibility of
   altering the flow selection process by modifying the criteria used to
   select flow records.  In this case, the IPFIX device would export
   flow data which are different from the ones that the Collector
   expects to receive.

   It is apparent that these security threats can be mitigated by
   authenticating entities that interact with the IPFIX device and
   keeping information for flow selection configuration confidential.


10.  References






D'Antonio, et al.       Expires November 24, 2011              [Page 22]

Internet-Draft          Flow Selection Techniques               May 2011


10.1.  Normative References

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

10.2.  Informative References

   [CoHa08]   Cormode, G. and M. Hadjieleftheriou, "Finding frequent
              items in data streams", Journal, Proceedings of the Very
              Large DataBase Endowment VLDB Endowment, Volume 1 Issue 2,
              August 2008, August 2008.

   [DuLT01a]  Duffield, N., Lund, C., and M. Thorup, "Charging from
              Sampled Network Usage", ACM Internet Measurement Workshop
              IMW 2001, San Francisco, USA, November 2001.

   [DuLT01b]  Duffield, N., Lund, C., and M. Thorup, "Properties and
              Prediction of Flow Statistics from Sampled Packet
              Streams", ACM SIGCOMM Internet Measurement Workshop 2002,
              November 2002.

   [EsVa01]   Estan, C. and G,. Varghese, "New Directions in Traffic
              Measurement and Accounting: Focusing on the Elephants,
              Ignoring the Mice", ACM SIGCOMM Internet Measurement
              Workshop 2001, San Francisco (CA), November 2001.

   [KaPS03]   Karp, R., Papadimitriou, C., and S. S. Shenker, "A simple
              algorithm for finding frequent elements in sets and
              bags.", ACM Transactions on Database Systems, Volume 28,
              51-55, 2003, March 2003.

   [KuXW04]   Kumar, K., Xu, J., Wang, J., Spatschek, O., and L. Li,
              "Space-code bloom filter for efficient per-flow traffic
              measurement", INFOCOM 2004 Twenty-third AnnualJoint
              Conference of the IEEE Computer and Communications
              Societies, March 2004.

   [MSZC10]   Mai, J., Sridharan, A., Zang, H., and C. Chuah, "Fast
              Filtered Sampling", Computer Networks Volume 54, Issue 11,
              Pages 1885-1898, ISSN 1389-1286, January 2010.

   [MaMo02]   Manku, G. and R. Motwani, "Approximate Frequency Counts
              over Data Streams", Proceedings of the Internation
              Conference on Very large DataBases (VLDB) pages 346--357,
              2002, Hong Kong, China, 2002.

   [Moli03]   Molina, M., "A scalable and efficient methodology for flow
              monitoring in the Internet", International Teletraffic



D'Antonio, et al.       Expires November 24, 2011              [Page 23]

Internet-Draft          Flow Selection Techniques               May 2011


              Congress (ITC-18), Berlin, September 2003.

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

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

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

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

   [RFC5475]  Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F.
              Raspall, "Sampling and Filtering Techniques for IP Packet
              Selection", RFC 5475, March 2009.

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

   [RFC6183]  Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi,
              "IP Flow Information Export (IPFIX) Mediation: Framework",
              RFC 6183, April 2011.


Authors' Addresses

   Salvatore D'Antonio
   CINI Consortium/University of Napoli "Parthenope"
   Monte S.Angelo, Via Cinthia
   Napoli  80126
   Italy

   Phone: +39 081 679944
   Email: salvatore.dantonio@parthenope.it











D'Antonio, et al.       Expires November 24, 2011              [Page 24]

Internet-Draft          Flow Selection Techniques               May 2011


   Tanja Zseby
   Fraunhofer Institute FOKUS
   Kaiserin-Augusta-Allee 31
   Berlin  10589
   Germany

   Phone: +49 30 3463 7153
   Email: tanja.zseby@fokus.fraunhofer.de


   Christian Henke
   Technische Universitat Berlin
   Strasse des 17. Juni 135
   Berlin  10623
   Germany

   Phone: +49 30 3463 7366
   Email: c.henke@tu-berlin.de


   Lorenzo Peluso
   University of Napoli
   Via Claudio 21
   Napoli  80125
   Italy

   Phone: +39 081 7683821
   Email: lorenzo.peluso@unina.it























D'Antonio, et al.       Expires November 24, 2011              [Page 25]

--------------070800050200020304050907-- From akoba@orange.plala.or.jp Thu Jun 23 01:32:23 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839C811E8083 for ; Thu, 23 Jun 2011 01:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62iWtX5p32DB for ; Thu, 23 Jun 2011 01:32:23 -0700 (PDT) Received: from msa03b.plala.or.jp (msa03.plala.or.jp [58.93.240.3]) by ietfa.amsl.com (Postfix) with ESMTP id B8A4311E8077 for ; Thu, 23 Jun 2011 01:32:21 -0700 (PDT) Received: from [127.0.0.1] (really [114.184.177.87]) by msa03b.plala.or.jp with ESMTP id <20110623083213.REQX27506.msa03b.plala.or.jp@[127.0.0.1]>; Thu, 23 Jun 2011 17:32:13 +0900 Date: Thu, 23 Jun 2011 17:32:16 +0900 From: ATSUSHI KOBAYASHI To: Nevil Brownlee In-Reply-To: <4DFECECB.4010000@auckland.ac.nz> References: <4DFECECB.4010000@auckland.ac.nz> Message-Id: <20110623173216.3BFB.C996B02F@orange.plala.or.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.53 [ja] X-VirusScan: Outbound; msa03b; Thu, 23 Jun 2011 17:32:19 +0900 Cc: IPFIX Working Group Subject: Re: [IPFIX] IETF 81: New work for IPFIX ... X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 08:32:23 -0000 Hi all, Although I can not attend IETF session any more, I will be ready for several items from far Japan. On Mon, 20 Jun 2011 16:38:35 +1200 Nevil Brownlee wrote: > > Hi all: > > It looks as though the flow-selection draft will be ready to submit > before the Quebec IETF meeting, so it's time to start discussion > on new charter items. Looking back at the minutes from IETF 80 in > Prague, possible items are: > > 1. New versions of the base standards, 5101 and 5102, which implement > small changes that did not affect interoperation, (for example > adding detail where there are gaps in 5101) as a Standards Track > successor to 5101. Once that had been published as an RFC > for some time we could work on moving it to Draft; that should be > possible in a reasonably short time. > > 2. IE Doctors, a draft that "lays out the ground rules for developing > new IPFIX Information Elements, and clarifies how the IE Registry > process works." The issues here are > a. Should we develop an 'IE Guidelines' draft? > b. Do we want to have an 'IE Doctors' team (with IESG overview), > an expanded group of IE Expert reviewers, or what? > > 3. IPFIX Aggregation. This seems (to me) to be a required function > for IPFIX Mediation. I will reviews it. > > 4. IPFIX Mediation protocol draft. I will support it. > > 5. Exporting MIB variables using IPFIX draft. I will reviews it. > > For any of these that we adopt as new work items, I'd like to know > - who is prepared to work on writing/editing? (at least 2 people) > - who is prepared to review these drafts as they change from time > to time? (at least three people) > If you are prepared to do either of these, please email me a list > of which item numbers in the list above you're willing to write/edit > and/or to review. How about the following draft as work item? Monitoring link layer section is required for expanding IPFIX. http://tools.ietf.org/html/draft-kashima-ipfix-data-link-layer-monitoring-05 Regards, Atsushi > > So, do please send your comments on these to the list, so that we > can have an informed discussion in Quebec City. > > Cheers, Nevil (IPFIX co-chair) > > -- > --------------------------------------------------------------------- > 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 -- KOBAYASHI ATSUSHI From trammell@tik.ee.ethz.ch Thu Jun 23 06:27:49 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8057011E8163 for ; Thu, 23 Jun 2011 06:27:49 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBJeiMbHk+cu for ; Thu, 23 Jun 2011 06:27:49 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C241511E8153 for ; Thu, 23 Jun 2011 06:27:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BB972D9303 for ; Thu, 23 Jun 2011 15:28:07 +0200 (MEST) 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 rTtGYexNQ7Og for ; Thu, 23 Jun 2011 15:28:07 +0200 (MEST) Received: from etx-public-dock-102-dhcp.ethz.ch (etx-public-dock-102-dhcp.ethz.ch [82.130.81.102]) (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 880A0D9302 for ; Thu, 23 Jun 2011 15:28:07 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Jun 2011 15:27:47 +0200 References: <20110623132007.8342.41701.idtracker@ietfa.amsl.com> To: IPFIX Working Group Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-ie-doctors-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 13:27:49 -0000 Greetings, all, A new version of the ie-doctors draft is now available. This version = addresses all open issues; we believe this revision to be essentially = complete and ready for adoption as a WG item. Best regards, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Date: June 23, 2011 3:20:07 PM GMT+02:00 > To: trammell@tik.ee.ethz.ch > Cc: bclaise@cisco.com, trammell@tik.ee.ethz.ch > Subject: New Version Notification for = draft-trammell-ipfix-ie-doctors-02.txt >=20 > A new version of I-D, draft-trammell-ipfix-ie-doctors-02.txt has been = successfully submitted by Brian Trammell and posted to the IETF = repository. >=20 > Filename: draft-trammell-ipfix-ie-doctors > Revision: 02 > Title: Guidelines for Authors and Reviewers of IPFIX = Information Elements > Creation date: 2011-06-24 > WG ID: Individual Submission > Number of pages: 26 >=20 > Abstract: > This document provides guidelines for the definition of IPFIX > Information Elements for addition to the IANA IPFIX Information > Element registry, in order to extend the applicability of the IPFIX > protocol to new operations and management areas. >=20 >=20 >=20 >=20 > The IETF Secretariat From n.brownlee@auckland.ac.nz Sun Jun 26 14:35:46 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F641F0C3C for ; Sun, 26 Jun 2011 14:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZwfZIolp+3e for ; Sun, 26 Jun 2011 14:35:45 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5377F1F0C3B for ; Sun, 26 Jun 2011 14:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1309124145; x=1340660145; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4E07A62B.9070100@auckland.ac.nz>|Date:=20 Mon,=2027=20Jun=202011=2009:35:39=20+1200|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20Working=20Group=20 |Subject:=20Fwd:=20FW:=20Nomcom=202011-2012:=20Second=20C all=20for=20Volunteers|Content-Transfer-Encoding:=207bit; bh=kJcI/R3o/TsBTA9HEOt74qC3bkn6lzkU6wnKjoHsFUE=; b=OC5CRScV8G2K10S20GKcNCt4GzioRluebrnzPrP8Wx7AIw/qG2tItVyR U0wgff+WJvhOV1V2nM+KkU/y6q5PeRH5qWq+qbyaY3LG4NUVkZx2PMnin 4MSjzYjD8CUl8yriL2G/LYYbAGbyTPBg+9P5YEJ1+GUoR4QPPwkzzUQTb w=; X-IronPort-AV: E=Sophos;i="4.65,428,1304251200"; d="scan'208";a="69071497" 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; 27 Jun 2011 09:35:43 +1200 Message-ID: <4E07A62B.9070100@auckland.ac.nz> Date: Mon, 27 Jun 2011 09:35:39 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Fwd: FW: Nomcom 2011-2012: Second Call for Volunteers X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 21:35:46 -0000 -------- Original Message -------- Subject: FW: Nomcom 2011-2012: Second Call for Volunteers Date: Sun, 26 Jun 2011 11:10:03 +0200 From: Romascanu, Dan (Dan) To: OPS Area WG chairs, Please forward this message from the Nomcom chair to your WG lists if you did not do it yet. Please remind the WG members the importance of this activity for the selection of the best leadership of the IETF and the continuous improvement of the IETF processes. Thanks and Regards, Dan -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Suresh Krishnan Sent: Friday, June 24, 2011 9:13 PM To: IETF Discussion Subject: Nomcom 2011-2012: Second Call for Volunteers This is the Second call for Volunteers for the 2011-12 Nomcom. We are just about halfway through the volunteer period so if you are considering volunteering, please do so very soon. We have had a very good response to the initial call for volunteers and I am pleased to report that we have 50 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. However, we would like to have many more volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. You have until 11:59 pm EDT July 10, 2011 to volunteer for Nomcom but it would be much better if you can volunteer as early as possible. If you volunteered before 21:00 EDT on June 21 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! Details about the process for volunteering for the Nomcom and the list of open positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2938/ The 50 volunteers who have thus far been qualified by the secretariat are: Alia Atlas , Juniper Networks Lixia Zhang , UCLA Wassim Haddad , Ericsson Glen Zorn , Network Zen Richard Barnes , BBN Technologies Stephen Kent , BBN Technologies Scott Mansfield , Ericsson Tina TSOU , FutureWei Technologies Fernando Gont , UTN/FRH Karen Seo , BBN Technologies Jie Dong , Huawei Technologies Mach Chen , Huawei Technologies Co. Sheng Jiang , Huawei Technologies Co. Ltd. Dimitri Papadimitriou , Alcatel-Lucent Thomas D. Nadeau , CA Technologies David Meyer , Cisco Systems/University of Oregon Wesley George , Time Warner Cable Cullen Jennings , Cisco Stephen Hanna , Juniper Networks Stephan Wenger , Bidyo Keyur Patel , Cisco Systems Michael Hamilton , BreakingPoint Systems Behcet Sarikaya , Huawei USA Mark Townsley , Cisco Systems Fred Baker , Cisco Systems Brian Trammell , ETH Zurich Sam Hartman , Painless Security Chris Griffiths , Comcast George Michaelson , APNIC Jiankang Yao , CNNIC Sohel Khan , Comcast Dacheng Zhang , Huawei Lianshu Zheng , Huawei Technologies Hui Deng , China Mobile Gang Chen , China Mobile Mirja Kuhlewind , University of Stuttgart John E Drake , Juniper Networks Matt Lepinski , BBN Technologies Subir Das , Telcordia Technologies Inc Yi Zhao , Huawei John Scudder , Juniper Networks Christer Holmberg , LM Ericsson Teemu Savolainen , Nokia Samita Chakrabarti , Ericsson Jaap Akkerhuis , NLnet labs Jason Weil , Time Warner Cable Randy Bush , Internet Initiative Japan Christian Schmidt , Nokia Siemens Networks Sean Shen , CNNIC Lou Berger , LabN Consulting The primary activity for this nomcom will begin during IETF-81 in Quebec City and should be completed by January 2012. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email to me before 11:59 pm EDT July 10, 2011 as follows: To: suresh.krishnan@ericsson.com Subject: Nomcom 2011-12 Volunteer Please include the following information in the body of the mail: Full Name: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name Current Primary Affiliation: // typically what goes in the Company // field in the IETF Registration Form Email Address(es): // all email addresses used to Register for the // past 5 IETF meetings // Please designate a Preferred email address for // contact if there is more than one email address Telephone number: // With country code (for confirmation if selected) Please expect an email response from me within 3 business days stating whether or not you are qualified. If you do not receive a response in this timeframe, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that Nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the Nomcom is a good way of contributing in that direction. I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process within the next few days. Thank you in advance for your participation. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From Thomas.Dietz@neclab.eu Wed Jun 29 04:58:27 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC8B21F86D9 for ; Wed, 29 Jun 2011 04:58:27 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9l8rABdJHIN for ; Wed, 29 Jun 2011 04:58:25 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7BD21F86D7 for ; Wed, 29 Jun 2011 04:58:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id DD9C7280001DB for ; Wed, 29 Jun 2011 13:58:21 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaNu+vlZk9Lg for ; Wed, 29 Jun 2011 13:58:21 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C02DA280001AA for ; Wed, 29 Jun 2011 13:58:16 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.5]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Wed, 29 Jun 2011 13:58:16 +0200 From: Thomas Dietz To: "ipfix@ietf.org" Thread-Topic: RFC5815 (IPFIX MIB) IANA Consideration issues Thread-Index: Acw2UTDP4s1AG749R2qYS+FDccCBuA== Date: Wed, 29 Jun 2011 11:58:15 +0000 Message-ID: <75581E268A48F849916117B977D76D372CC427D7@Polydeuces.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.10] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0019_01CC3664.9789ED10" MIME-Version: 1.0 Subject: [IPFIX] RFC5815 (IPFIX MIB) IANA Consideration issues X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 11:58:27 -0000 ------=_NextPart_000_0019_01CC3664.9789ED10 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Dear all, in the course of editing the PSAMP MIB draft we identified that the IANA Considerations in RFC 5815 (the IPFIX MIB RFC) do not make sense. Putting the whole IPFIX SELECTOR MIB under IANA control and creating a registry hereof is not what we need here. I propose to change that and only put up a registry that registers the OIDs of the subtrees under the ipfixSelectorFunctions OID. Each subtree -- as described in the RFC -- represents a Selector Function and its parameters (in a table). So the root of the subtree (i.e. its OID) has to be registered in the new registry. In addition the document where this subtree is defined has to be registered. The review process setup in RFC5815 can remain as it is. Implementing this change needs -- according to our ADs -- an updated RFC5815. Please comment on this issue. Any feedback is welcome. Best Regards, Thomas -- Thomas Dietz E-mail: Thomas.Dietz@neclab.eu トーマス・ヂィーツ NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL ------=_NextPart_000_0019_01CC3664.9789ED10 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNDCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFNTCCBB2gAwIBAgIED+0gWzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0xMDA0MjAxMjQ5MTVaFw0xMzA0MTkxMjQ5MTVaMGAx CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQD2mMcvPbgraEaWMV6uNCs6t88lhBczgfxybD46mwr8D3VaQLEnqTsBOAf/ Y8ARtq+P6Dkm2MBMXQG+Ebo2qhif6O4dH7whcG9E88F9247R2EJjcXmxMYZWYGQTI2vGw/joerRB waiwfxCXWBTLutbdWEEKL/DG9A1yQRPGJc+jJYfgm0ekYn+WESOLYaBH7G9aIIZQ7en3afhPpbQA Ajh92K240TG+VgBpe1vnDdth28Ps5XeN+otookDZHwwGQYwYrPZJtnhGIyjKMm7OkXL62Rf3aSoI doVUwYYS67RYYNOY0C7qOVyCUF+z4Bkn758sZhZzotiLQVT3AZ625PrvAgMBAAGjggHEMIIBwDAJ BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFH9fxgi2EshupgLF49SzaAX0QFoMMB8GA1UdIwQYMBaAFE8ch3od 4C+Z9r4VqtE1nQ5K5ro2MCEGA1UdEQQaMBiBFlRob21hcy5EaWV0ekBuZWNsYWIuZXUwfQYDVR0f BHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNy bC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2Fj cmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRm bi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8v Y2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN AQEFBQADggEBACnPHI1mIY1TVY9Aj8zsHHxiwMRx02Hp6DLZGYXHGG9IkflrRKNiDIV2LbBDpXVH vojMxTtCt10iwbyVMGaevet/VHYCJSHzrCLkw+GkvuhDU70lNsWw9P+mai7OHa+NQ6im8+4RnY1B yhqidcCt3hIV9B69ax0/KIhIFpiWz/lKZVIghki07I4m8mf1sbvCORKxudH0TVLlRJlX1r8S+8ea 9e+Q8pgXfrsCeyxBV3KAjszRQkqDZsbD7jQHQWokkMPIjbaTjw6V/5SRzmcAy0XlKNOCbldlzmCB jDZTQWdSH/AFDy5L2l4j0Ck0vVlQv+r1F4omsb4BelRq+vHd+lExggQ4MIIENAIBATCBmTCBkDEL MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzAJBgUrDgMCGgUAoIICczAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA2MjkxMTU4MTVaMCMGCSqGSIb3 DQEJBDEWBBTzJtKKzPDlgwgwt8jYiGiGaxgOwDCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQswCQYD VQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9y aWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemll cnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQP7SBbMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCBkDEL MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzCBtwYJKoZIhvcNAQkPMYGpMIGmMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3 DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAL BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG 9w0BAQEFAASCAQDZNvOs92BCDVY1qwxqGebpOqpLs13y22qW+tYlBEJoj3ITR4bNqjICLqUtGE9K 8Hv0/tDwsvoBwqIDM2u5lTnk6UxXpM7qq3kb8fACp6ChexiYsTfwQ8jqwBN1PxQUOgPOBv+PauCp BvhKiEH/pWq1fXNtHrmlk5xHW+OwBGXnRaHQYURATnHkwIRP762kvkSUa8/b13lGxKU6Xzkegqyr XS95nCocCILObxPXsJlt9NZIz1UMiGozjy2/00nhZLUU1Ai5oP0MKI7flaWgtb9SSS36RJ82YQF8 7YuIwuJ1pqrwYmDRQ8z8rHUVLWK+iAoszyu7FGT9lBFlPJfZQGHcAAAAAAAA ------=_NextPart_000_0019_01CC3664.9789ED10-- From j.schoenwaelder@jacobs-university.de Thu Jun 30 02:10:57 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2331E21F8740 for ; Thu, 30 Jun 2011 02:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuKf781jhyQU for ; Thu, 30 Jun 2011 02:10:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3D55621F8685 for ; Thu, 30 Jun 2011 02:10:54 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4199520BFC; Thu, 30 Jun 2011 11:10:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QGwb-2djJoB0; Thu, 30 Jun 2011 11:10:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C36020BF6; Thu, 30 Jun 2011 11:10:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 66ECE197B128; Thu, 30 Jun 2011 11:10:49 +0200 (CEST) Date: Thu, 30 Jun 2011 11:10:49 +0200 From: Juergen Schoenwaelder To: Chris Inacio Message-ID: <20110630091048.GA3317@elstar.local> Mail-Followup-To: Chris Inacio , IPFIX Working Group References: <29883E73-D176-41BC-933C-13A89C77AE7B@cert.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29883E73-D176-41BC-933C-13A89C77AE7B@cert.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPFIX Working Group Subject: Re: [IPFIX] comments on draft-johnson-ipfix-mib-variable-export-01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 09:10:57 -0000 On Tue, May 31, 2011 at 10:52:19AM -0400, Chris Inacio wrote: > Here are my comments on the draft. This model is much improved and > with some minor additional clarification I think it should be much > more seriously considered. I did everything as PDF comments to the > PDF version of the draft. I've attached it here. Inacio, thanks for your comments. While going through them, we were not sure what you meant with your common on Figure 1: Maybe a little too implementation specific. This could all be represented in DTMF CIM format with a translation to SNMP/MIB. Can you please elaborate? My view is that "Instrumentation" is really meant as being implementation specific and the figure does not rule out that your instrumentation is in fact a DMTF CIM store as long as it provides MIB object instrumentation consistent with definitions in MIB modules. Perhaps you can propose concrete edits to make it easier for us to understand what you think should be changed? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Jun 30 02:39:08 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A537021F87B7 for ; Thu, 30 Jun 2011 02:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfMG4Z7Y1Pl9 for ; Thu, 30 Jun 2011 02:39:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8365621F87DB for ; Thu, 30 Jun 2011 02:39:07 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB85F20BF4 for ; Thu, 30 Jun 2011 11:39:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RdHzQ0UMfQtM; Thu, 30 Jun 2011 11:39:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D51220BD4; Thu, 30 Jun 2011 11:39:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 15892197B186; Thu, 30 Jun 2011 11:39:05 +0200 (CEST) Date: Thu, 30 Jun 2011 11:39:05 +0200 From: Juergen Schoenwaelder To: ipfix@ietf.org Message-ID: <20110630093904.GB3317@elstar.local> Mail-Followup-To: ipfix@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [IPFIX] ipfix mib export and context information X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 09:39:08 -0000 Hi, as explained in section 3.3 of RFC 3411, MIB objects (identified by an OID) always exist in a context. A context is identified by a contextEngineID and a contextName. In colloquial terms, the contextEngineID identifies an SNMP agent and a contextName identifies an OID tree accessible on that agent. In short, within a management domain, a unique name of a MIB object is the following 4-tuple: (contextEngineID, contextName, object-type OID, instance-identifier) | | | | +-----------+------------+ +--------------+-----------------+ | | context OID Many agents only have one context (the so called default context) and hence this is mostly invisible for many people. However, in certain situations, contexts are used. The classic example are bridges that have an instance of the BRIDGE-MIB for each VLAN (in this case the contextName used to distinguish BRIDGE-MIB instances is usually the VLAN name). For exporting MIB objects in IPFIX, we need to deal with the representation of contexts: a) If a MIB object exists in the default context (zero length contextName), then the contextName is not carried in IPFIX. b) If a MIB object exists in a non-default context, then the contextName needs to be carried in IPFIX. There are again two options: b.1) The contextName is associated to the template. This means all MIB objects in an IPFIX flow record must belong to the same SNMP context. Continuing the example mentioned above, you would not be able to have flow record that carries a MIB object for multiple VLANs. (Note that a similar restriction exists in SNMP since a PDU is always scoped to one context.) The trade-off here is that flow records are smaller at the expense of having to deal with more template options in cases where many contexts are used. b.2) The contextName is associated to a MIB object in a flow record. This allows to have objects existing in different SNMP contexts on the same "agent" to be carried in a single flow record. However, there is a price for this flexibility since context information is now repeated in every flow record. Independent of the options a), b.1), and b.2) above, there is a question whether the contextEngineID should be carried somewhere? This would disambiguate things if a device has multiple SNMP agents running concurrently. If the contextEngineID is carried, then this should likely be part of the template information, not the flow records. So the main question at this point (sorry for the lengthy explanation): Should we go for b.1) or b.2) or even allow both b.1) and b.2)? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103