From paitken@cisco.com Thu Nov 1 10:16:56 2012 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 EAB1E21F9109 for ; Thu, 1 Nov 2012 10:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.458 X-Spam-Level: X-Spam-Status: No, score=-10.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 tL58Y+1J5md4 for ; Thu, 1 Nov 2012 10:16:56 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id E91D521F9106 for ; Thu, 1 Nov 2012 10:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3370; q=dns/txt; s=iport; t=1351790216; x=1352999816; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZKXihZA4TJisIsTSOMidS+PRGja/An4S7ETOTNGUtiw=; b=FSM955IpR781+0bJOS1fKJc+XUrvXGLUdQxf2hxHpvFXocvTFKtgbegR BKKbn/Js8L5gB/feSB1X2w7dqB2xscXnQhuJ/5Tue2kI0SmpTMffiWyhe tHVAIRbusp8jMrNhlF50C0tPzwjs1yTz/VjHLcpIkJVd9KhU/pB5NhBCS Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAM6tklCQ/khM/2dsb2JhbABEgyzAQYEIgh4BAQEDARIBCgoRDzEBBQsLEg8WDwkDAgECATcOBg0BBwEBHodeBpxnkRuPFZI2A5V4hWqIboFrgm8 X-IronPort-AV: E=Sophos;i="4.80,693,1344211200"; d="scan'208";a="9280802" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 01 Nov 2012 17:16:54 +0000 Received: from [10.55.87.37] (dhcp-10-55-87-37.cisco.com [10.55.87.37]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA1HGsQ2004770; Thu, 1 Nov 2012 17:16:54 GMT Message-ID: <5092AE87.6040400@cisco.com> Date: Thu, 01 Nov 2012 17:16:55 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Brian Trammell References: <506CBFE3.10607@auckland.ac.nz> <5090547C.5020803@cisco.com> <5091271E.3050206@cisco.com> <68907E1B-1D38-4F3A-B0E0-F47628F989F0@tik.ee.ethz.ch> <50913BF3.2080408@cisco.com> <8ED0D683-536C-46B6-8E5A-3CC3B7CB678F@tik.ee.ethz.ch> <5091422B.9070607@cisco.com> <48C58B9E-EE52-415D-896F-AA15F8B7A6C4@tik.ee.ethz.ch> In-Reply-To: <48C58B9E-EE52-415D-896F-AA15F8B7A6C4@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nevil Brownlee , IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5102bis-05.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, 01 Nov 2012 17:16:57 -0000 Brian, >>> What verb does the MP apply to a unit of information when it gives it to the EP? >>> >>> A delta counter counts only observations made since the last Flow Record for a given Flow was measured. >>> >>> Or maybe we can sidestep the action completely: >>> >>> A delta counter counts only observations made since the previous Flow Record for a given Flow. >> No, that's still involving export. >> >> What should the MP do if the flow ends *but isn't exported* ? > In the idealized architecture, the MP can't know, so it just keeps exporting, clearly. NB the MP doesn't export. As you say, I don't think we have any verb for the MP -> EP handoff. > If your implementation allows loss between the MP and the EP, there is nothing conceptually different between this situation and loss between the EP and the CP, except you can't use wireshark to debug it. :) The MP has no knowledge of what happens to the data it produces, so the infomodel definitions simply can't be expressed in export terms. eg, suppose traffic from a first level cache is aggregated into a second level cache. Although traffic isn't "exported" per se, we want the delta counters to begin from zero next time around. (Even if this isn't strict IPFIX, the caches are using the IPFIX infomodel, and 5102bis recognises this as valid: "the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications.") The point is that the definitions have to work for other potential uses of the infomodel. >> Just the same as when the flow *is* exported. So the definition of deltaCount is independent of export, flow records, etc. >> >> So the definitions have to be about the metering time, and particularly that we've started metering again. However, we can't write that, because some implementations may not hold state that tells them this. So all we know is that totalCounters meter from the start of the MP, while delta counters meter a potentially shorter interval, reporting the value metered since the start of that interval. > I've stared at this for a while and I can't come up with a way to express it that's unconvoluted enough for my taste. I still don't see why my last attempt at a definition above necessarily invokes export -- it's the MP sending on the information in a proto-Flow Record to the EP and deciding to start the counters over. So I suppose for the corner case that the MP sends something up to the EP and the EP drops it we could complicate the language a bit: > > A delta counter counts only observations made since the previous Flow Record for a given Flow, as seen from the point of view of the Metering Process (i.e., discounting any failure or refusal to export the Flow Record on the part of the Exporting Process or failure to receive the Flow Record on the part of the Collecting Process). > > although truth be told I think this overly complicated and unreadable for the magnitude of the corner case it addresses. Maybe without the i.e. phrase? Agreed; this is just too cumbersome. So since MPs generate Flow Records, your earlier definition seems to be best, except that there may not have been any previous Flow Record. So, how about "A delta counter only counts observations made since the previous Flow Record (if any) for a given Flow." P. From paitken@cisco.com Thu Nov 1 14:16:10 2012 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 19DA721F9739 for ; Thu, 1 Nov 2012 14:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.489 X-Spam-Level: X-Spam-Status: No, score=-10.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 35q0KQfnCEnj for ; Thu, 1 Nov 2012 14:16: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 6EE8521F973A for ; Thu, 1 Nov 2012 14:16:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12564; q=dns/txt; s=iport; t=1351804562; x=1353014162; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=dUITqglIELIzOO/ZLnk7d8gO27XNUjzfaDJPkEOJDgE=; b=lgUzLaVS8e8yf3OdrLv+v9S4k4PM7ii3+30wDoIBLAbKysC4HumCT9Y/ HudAIwMW+P+lgz1cM1Ebo0iqiW3BiQuY1I0M8aj5Ncbb3MrLuavTLhLgC hjHW/wNpGx7hPn57Tlx/TXmIXDncOIjkGFb6zKZz0Defm7nq78Sh6P1OG M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAFPlklCQ/khM/2dsb2JhbABEgyyISrc/gQiCHgEBAQIBARIBZQEFCwshDAoPCQMCAQIBRQYNAQcBAR6HXgYLnGmgLYwFgwGDMAOVeIVqiG6Ba4Jv X-IronPort-AV: E=Sophos;i="4.80,695,1344211200"; d="scan'208,217";a="146163794" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 01 Nov 2012 21:15:56 +0000 Received: from [10.61.102.64] (dhcp-10-61-102-64.cisco.com [10.61.102.64]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA1LFtJr018651; Thu, 1 Nov 2012 21:15:55 GMT Message-ID: <5092E68B.8070902@cisco.com> Date: Thu, 01 Nov 2012 21:15:55 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Brian Trammell References: <500039DE.5050706@cisco.com> <071B9C0F-B58F-489A-99E1-A3A4A4D25382@tik.ee.ethz.ch> In-Reply-To: <071B9C0F-B58F-489A-99E1-A3A4A4D25382@tik.ee.ethz.ch> Content-Type: multipart/alternative; boundary="------------070109060703070202080209" Cc: draft-ietf-ipfix-a9n@tools.ietf.org, IETF IPFIX Working Group Subject: Re: [IPFIX] review of draft-ietf-ipfix-a9n-04 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, 01 Nov 2012 21:16:11 -0000 This is a multi-part message in MIME format. --------------070109060703070202080209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nevil, when was the WGLC on this document? I can't find any WG emails with the appropriate subject line. Brian, the IESG LC prompted me to re-review this. Please see inline as usual... >>> 2. Terminology >>> >>> Terms used in this document that are defined in the Terminology >>> section of the IPFIX Protocol [I-D.ietf-ipfix-protocol-rfc5101bis] >>> document are to be interpreted as defined there. >>> >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >>> document are to be interpreted as described in [RFC2119]. >>> >>> In addition, this document defines the following terms >>> >>> Aggregated Flow: A Flow, as defined by >>> [I-D.ietf-ipfix-protocol-rfc5101bis], derived from a set of zero >>> or more original Flows within a defined Aggregation Interval. The >>> >> Zero things can't be aggregated. You can only say, "none were seen". > This is equivalent to what's written in the terminology, no? Export of an aggregation of an empty set is the same thing as an assertion that nothing was observed corresponding to the given key in the reported interval. So to be quite clear: when zero flows are aggregated, is the result zero Aggregated Flows, or is the result one Aggregated Flow which says there was nothing to be aggregated? (I know it sounds odd, but it's a serious question.) > BTW, the case of a collector or mediator aggregating received flows presents another possibility: the flow could be received late (eg, delayed export), so rather than re-opening an old start / mid / end aggregation, the flow is simply included in the "current" aggregation. ie, real time aggregation, regardless of the flow timestamps. > A good point; however, this is already covered in section 6.2: > > In certain circumstances, additional delay at the original Exporter > may cause an IAP to close an interval before the last Original > Flow(s) accountable to the interval arrives; in this case the IAP > SHOULD drop the late Original Flow(s). Accounting of flows lost at > an Intermediate Process due to such issues is covered in > [I-D.ietf-ipfix-mediation-protocol]. > > Would you suggest loosening the language to allow an IAP to fake timestamps to avoid drops in delay-intolerant situations? So there are several options: 1. drop the late flows. In this case the late traffic is utterly lost, which may be quite undesirable. 2. re-open the appropriate aggregation to correctly account the late flows. 2a. don't close aggregations immediately, but wait for some period and accept late flows. 3. account the late flows in the current (though wrong) aggregation. I'd prefer that the doc discussed the options or gave reasons rather than simply advising "SHOULD drop". >>> dest ip4 port dist src >>> 192.0.2.131 53 3 >>> 198.51.100.2 80 1 >>> 198.51.100.2 443 3 >>> 198.51.100.67 80 2 >>> 198.51.100.68 80 2 >>> 198.51.100.133 80 2 >>> 198.51.100.3 80 3 >>> 198.51.100.4 80 2 >>> 198.51.100.17 80 1 >>> 198.51.100.69 443 1 >>> >> This table seems to be completely wrong. Even the total counts is wrong - ie, add up the "dist src" = 20. Yet Figure 9 has 24 entries. > These are *distinct* sources per destination endpoint. > > For 192.0.2.131:53, there are 5 flows, but the sources are 192.0.2.2, 192.0.2.3, 192.0.2.131. I went over it again and finally worked it out - so no issue. (This has been troubling me for a while, but I didn't relish re-working the data.) >>> Benoit Claise >>> Cisco Systems, Inc. >>> De Kleetlaan 6a b1 >>> 1831 Diagem >>> >> Once again, in existing RFCs - and in Cisco's internal directory - this is "Diegem 1831". > Per the Universal Postal Union, the most authoritative reference source I could find in English with a couple of minutes of googling, the proper format for addressing in Belgium places the postcode before the municipality name. > > See: http://www.upu.int/fileadmin/documentsFiles/activities/addressingUnit/belEn.pdf NB "Diagem" != "Diegem". Looking at Benoit's 22 RFCs + 17 drafts reveals the following 52 usages: 13 1831 Diegem 10 Diegem 1831 7 Diegem 1813 6 Degem 1831 5 Diegem 1831 3 Degem 1831 2 Degem 1813 1 Diegem, 1831 1 Diegem, 1813 1 Diegem B-1831 1 Diegem 1813 1 Brussels, Diegem B-1831 1 1831 Diagem Some drafts even have > 1 format. I'll leave you to draw your own conclusions. P. --------------070109060703070202080209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Nevil, when was the WGLC on this document? I can't find any WG emails with the appropriate subject line.


Brian, the IESG LC prompted me to re-review this. Please see inline as usual...


2.  Terminology

   Terms used in this document that are defined in the Terminology
   section of the IPFIX Protocol [I-D.ietf-ipfix-protocol-rfc5101bis]
   document are to be interpreted as defined there.

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

   In addition, this document defines the following terms

   Aggregated Flow:   A Flow, as defined by
      [I-D.ietf-ipfix-protocol-rfc5101bis], derived from a set of zero
      or more original Flows within a defined Aggregation Interval.  The


Zero things can't be aggregated. You can only say, "none were seen".

This is equivalent to what's written in the terminology, no? Export of an aggregation of an empty set is the same thing as an assertion that nothing was observed corresponding to the given key in the reported interval.

So to be quite clear: when zero flows are aggregated, is the result zero Aggregated Flows, or is the result one Aggregated Flow which says there was nothing to be aggregated? (I know it sounds odd, but it's a serious question.)


BTW, the case of a collector or mediator aggregating received flows presents another possibility: the flow could be received late (eg, delayed export), so rather than re-opening an old start / mid / end aggregation, the flow is simply included in the "current" aggregation. ie, real time aggregation, regardless of the flow timestamps.

A good point; however, this is already covered in section 6.2: 

   In certain circumstances, additional delay at the original Exporter
   may cause an IAP to close an interval before the last Original
   Flow(s) accountable to the interval arrives; in this case the IAP
   SHOULD drop the late Original Flow(s).  Accounting of flows lost at
   an Intermediate Process due to such issues is covered in
   [I-D.ietf-ipfix-mediation-protocol].

Would you suggest loosening the language to allow an IAP to fake timestamps to avoid drops in delay-intolerant situations?

So there are several options:

1. drop the late flows. In this case the late traffic is utterly lost, which may be quite undesirable.

2. re-open the appropriate aggregation to correctly account the late flows.
2a. don't close aggregations immediately, but wait for some period and accept late flows.

3. account the late flows in the current (though wrong) aggregation.

I'd prefer that the doc discussed the options or gave reasons rather than simply advising "SHOULD drop".


   dest ip4       port  dist src
   192.0.2.131    53           3
   198.51.100.2   80           1
   198.51.100.2   443          3
   198.51.100.67  80           2
   198.51.100.68  80           2
   198.51.100.133 80           2
   198.51.100.3   80           3
   198.51.100.4   80           2
   198.51.100.17  80           1
   198.51.100.69  443          1


This table seems to be completely wrong. Even the total counts is wrong - ie, add up the "dist src" = 20. Yet Figure 9 has 24 entries.

These are *distinct* sources per destination endpoint.

For 192.0.2.131:53, there are 5 flows, but the sources are 192.0.2.2, 192.0.2.3, 192.0.2.131.

I went over it again and finally worked it out - so no issue.
(This has been troubling me for a while, but I didn't relish re-working the data.)


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


Once again, in existing RFCs - and in Cisco's internal directory - this is "Diegem 1831".

Per the Universal Postal Union, the most authoritative reference source I could find in English with a couple of minutes of googling, the proper format for addressing in Belgium places the postcode before the municipality name.

See: http://www.upu.int/fileadmin/documentsFiles/activities/addressingUnit/belEn.pdf

NB "Diagem" != "Diegem".

Looking at Benoit's 22 RFCs + 17 drafts reveals the following 52 usages:

     13 1831 Diegem
     10 Diegem  1831
      7 Diegem 1813
      6 Degem 1831
      5 Diegem 1831
      3 Degem  1831
      2 Degem  1813
      1 Diegem,   1831
      1 Diegem,   1813
      1 Diegem  B-1831
      1 Diegem  1813
      1 Brussels, Diegem  B-1831
      1 1831 Diagem

Some drafts even have > 1 format.

I'll leave you to draw your own conclusions.

P.

--------------070109060703070202080209-- From paitken@cisco.com Thu Nov 1 15:09:02 2012 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 D855F21F89F4 for ; Thu, 1 Nov 2012 15:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.5 X-Spam-Level: X-Spam-Status: No, score=-10.5 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 XFWS+6n2UmOV for ; Thu, 1 Nov 2012 15:09:02 -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 7573621F943F for ; Thu, 1 Nov 2012 15:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5781; q=dns/txt; s=iport; t=1351807741; x=1353017341; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=xrJgLRxVhX5hVPbl+TGGsqzKfmrnn9QdoqyBWP+9myk=; b=AzGTVKccxCd+I4hX9RoCIPa3ZbFulNgWrJOKLJ8NdNgDbEM7R4hTozlv PMJXJg/WKObODtOCnlPLz2lDSGrAvgIR3K2y9HpUWtm5hTIGDwSovO2Da rDKR1djJlDB1+diAjxJaaoVvMD1KPPNrXRT62CKzlUJVR0i6knf+9M/rj w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFAO3xklCQ/khN/2dsb2JhbABEgyyISrc/gQiCHwEBBBIBFFEBECwWDwkDAgECAUUGDQEHAQEeh2Scf6ArkjYDkkaDMoVqiG6Ba4Jv X-IronPort-AV: E=Sophos;i="4.80,695,1344211200"; d="scan'208,217";a="77939219" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 01 Nov 2012 22:08:59 +0000 Received: from [10.61.102.64] (dhcp-10-61-102-64.cisco.com [10.61.102.64]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA1M8w9j020867; Thu, 1 Nov 2012 22:08:59 GMT Message-ID: <5092F2FA.1090104@cisco.com> Date: Thu, 01 Nov 2012 22:08:58 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Brian Trammell References: <500039DE.5050706@cisco.com> <071B9C0F-B58F-489A-99E1-A3A4A4D25382@tik.ee.ethz.ch> <5092E68B.8070902@cisco.com> In-Reply-To: <5092E68B.8070902@cisco.com> Content-Type: multipart/alternative; boundary="------------000907030708010300050300" Cc: draft-ietf-ipfix-a9n@tools.ietf.org, IETF IPFIX Working Group Subject: [IPFIX] review of draft-ietf-ipfix-a9n-07 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, 01 Nov 2012 22:09:03 -0000 This is a multi-part message in MIME format. --------------000907030708010300050300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Having missed the WGLC announcement and just seen the IESG LC announcement, I thought I should quickly review the 04->05->06->07 diffs. As usual I have just a few minor points which I hope are helpful. Sorry things are a bit jumbled up this time, which is due to reviewing the three versions in order rather than the larger 04->07 all at once. Section 3, 5th paragraph: I think the paragraph means to say that conversion between Flows is possible. However, I mis-read that the IEs can be converted within a flow - so there's potential ambiguity here: While much of the discussion in this document, and all of the examples, apply to the common case that the Original Flows to be aggregated are all of the same underlying type (i.e., are represented with identical Templates or compatible Templatescontaining a core set Information Elements which can be freely converted to one another), and Also, there's a missing "of": with identical Templates or compatible Templates containing a core set*of*Information Elements Section 8: Why was "pt" used for "protocolIdentifier"? Surely "pr" would have been more obvious choice and less easily confused with "Port". Under Figure 19: remove ";" : After applying the interval distribution step to the source data in Figure 10,*;* the Partially Aggregated flows are shown in Figure 20. Under Figure 24: remove space before the comma: information from the Original Flows in Figure 10 , and as such is not Section 6.2: Note that when aggregating flows from multiple Metering Processes with different active timeouts, the delay is *determined by* the maximum active timeout. - it's not so much "determined by" as "proportional to", because an allowance should also be made for other delays. Section 3, paragraph 4: s/anonymising/anonymizing/ for consistency with the 8 other uses in the doc. Section 8: The data records given as input to the examples in this section are shown below; say "in Figure 10", else the figure isn't referenced until after Figure 12. P. --------------000907030708010300050300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Having missed the WGLC announcement and just seen the IESG LC announcement, I thought I should quickly review the 04->05->06->07 diffs.

As usual I have just a few minor points which I hope are helpful.

Sorry things are a bit jumbled up this time, which is due to reviewing the three versions in order rather than the larger 04->07 all at once.


Section 3, 5th paragraph:

    I think the paragraph means to say that conversion between Flows is possible.
    However, I mis-read that the IEs can be converted within a flow - so there's potential ambiguity here:

   While much of the discussion in this document, and all of the
   examples, apply to the common case that the Original Flows to be
   aggregated are all of the same underlying type (i.e., are represented
   with identical Templates or compatible Templates containing a core
   set Information Elements which can be freely converted to one
   another), and

Also, there's a missing "of":

   with identical Templates or compatible Templates containing a core
   set of Information Elements


Section 8:

    Why was "pt" used for "protocolIdentifier"? Surely "pr" would have been more obvious choice and less easily confused with "Port".


Under Figure 19: remove ";" :
   After applying the interval distribution step to the source data in
   Figure 10,; the Partially Aggregated flows are shown in Figure 20.


Under Figure 24: remove space before the comma:
   information from the Original Flows in Figure 10 , and as such is not


Section 6.2:
   Note that when aggregating flows from multiple
   Metering Processes with different active timeouts, the delay is
   determined by the maximum active timeout.

    -  it's not so much "determined by" as "proportional to", because an allowance should also be made for other delays.


Section 3, paragraph 4:

    s/anonymising/anonymizing/ for consistency with the 8 other uses in the doc.


Section 8:
   The data records given as input to the examples in this section are
   shown below;

    say "in Figure 10", else the figure isn't referenced until after Figure 12.


P.

--------------000907030708010300050300-- From n.brownlee@auckland.ac.nz Thu Nov 1 18:21:06 2012 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 783C721F94D7 for ; Thu, 1 Nov 2012 18:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 GXnrqPUr6vYC for ; Thu, 1 Nov 2012 18:21:05 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3589421F94E6 for ; Thu, 1 Nov 2012 18:21:01 -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=1351819263; x=1383355263; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=LpoMOQKqMET/tft+O6bK/cX7KubHAWU9EO0swE+Gci8=; b=OlpTgHAqgtSKErTw2ayaOeTiAqp5oei2Llly8c2x2S3wnb62O7AwJGvK 1uACB1xOG9eeyLqyF5j9Tk17x1tA5bY9wZMog4RiXka4MXHmzzJEO/wbP t4dYG9YICSqsPJZ2yHX3GADw90YXw1mpMEvZEIvN7TrEyxYuKn5PpKc67 c=; X-IronPort-AV: E=Sophos;i="4.80,696,1344168000"; d="scan'208";a="154559761" 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; 02 Nov 2012 14:21:00 +1300 Message-ID: <50931FFC.6010903@auckland.ac.nz> Date: Fri, 02 Nov 2012 14:21:00 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Atlanta agenda updated 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: Fri, 02 Nov 2012 01:21:06 -0000 Hi all: A new version of the agenda for the IPFIX meeting at IETF 85 (Atlanta) is available at http://www.ietf.org/proceedings/85/agenda/agenda-85-ipfix So far we have no new drafts to be presented - if you have something you'd like to share, please email me or Juergen. We may have some time during 'AOB' for some open discussion, e.g. what/when/how should we do some more IPFIX inter-operation testing? If you have ideas for other topics, please email them to me. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From trammell@tik.ee.ethz.ch Thu Nov 1 20:42:38 2012 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 E69B421F95BE for ; Thu, 1 Nov 2012 20:42:38 -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 kw-ZF0DiZiDs for ; Thu, 1 Nov 2012 20:42:38 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 16FBB21F98EA for ; Thu, 1 Nov 2012 20:42:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4D80DD9314; Fri, 2 Nov 2012 04:42:32 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2pO0YJTY8MXb; Fri, 2 Nov 2012 04:42:32 +0100 (MET) Received: from [10.67.199.86] (72-254-238-23.client.stsn.net [72.254.238.23]) (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 9AC96D930C; Fri, 2 Nov 2012 04:42:31 +0100 (MET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <5092AE87.6040400@cisco.com> Date: Thu, 1 Nov 2012 22:42:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <506CBFE3.10607@auckland.ac.nz> <5090547C.5020803@cisco.com> <5091271E.3050206@cisco.com> <68907E1B-1D38-4F3A-B0E0-F47628F989F0@tik.ee.ethz.ch> <50913BF3.2080408@cisco.com> <8ED0D683-536C-46B6-8E5A-3CC3B7CB678F@tik.ee.ethz.ch> <5091422B.9070607@cisco.com> <48C58B9E-EE52-415D-896F-AA15F8B7A6C4@tik.ee.ethz.ch> <5092AE87.6040400@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1499) Cc: Nevil Brownlee , IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5102bis-05.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: Fri, 02 Nov 2012 03:42:39 -0000 Hi, Paul, On 1 Nov 2012, at 12:16, Paul Aitken wrote: >> If your implementation allows loss between the MP and the EP, there = is nothing conceptually different between this situation and loss = between the EP and the CP, except you can't use wireshark to debug it. = :) >=20 > The MP has no knowledge of what happens to the data it produces, so = the infomodel definitions simply can't be expressed in export terms. >=20 > eg, suppose traffic from a first level cache is aggregated into a = second level cache. Although traffic isn't "exported" per se, we want = the delta counters to begin from zero next time around. > (Even if this isn't strict IPFIX, the caches are using the IPFIX = infomodel, and 5102bis recognises this as valid: "the model is defined = in an open way that easily allows using it in other protocols, = interfaces, and applications.") >=20 > The point is that the definitions have to work for other potential = uses of the infomodel. Good point. Which means any definition should be even more removed from = the cache. >>> Just the same as when the flow *is* exported. So the definition of = deltaCount is independent of export, flow records, etc. >>>=20 >>> So the definitions have to be about the metering time, and = particularly that we've started metering again. However, we can't write = that, because some implementations may not hold state that tells them = this. So all we know is that totalCounters meter from the start of the = MP, while delta counters meter a potentially shorter interval, reporting = the value metered since the start of that interval. >> I've stared at this for a while and I can't come up with a way to = express it that's unconvoluted enough for my taste. I still don't see = why my last attempt at a definition above necessarily invokes export -- = it's the MP sending on the information in a proto-Flow Record to the EP = and deciding to start the counters over. So I suppose for the corner = case that the MP sends something up to the EP and the EP drops it we = could complicate the language a bit: >>=20 >> A delta counter counts only observations made since the previous Flow = Record for a given Flow, as seen from the point of view of the Metering = Process (i.e., discounting any failure or refusal to export the Flow = Record on the part of the Exporting Process or failure to receive the = Flow Record on the part of the Collecting Process). >>=20 >> although truth be told I think this overly complicated and unreadable = for the magnitude of the corner case it addresses. Maybe without the = i.e. phrase? >=20 > Agreed; this is just too cumbersome. >=20 > So since MPs generate Flow Records, your earlier definition seems to = be best, except that there may not have been any previous Flow Record. >=20 > So, how about "A delta counter only counts observations made since the = previous Flow Record (if any) for a given Flow."\ This works for me. Cheers, Brian From trammell@tik.ee.ethz.ch Thu Nov 1 21:24:06 2012 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 6334021F9795 for ; Thu, 1 Nov 2012 21:24:06 -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 k4M6RNb45GUf for ; Thu, 1 Nov 2012 21:24:05 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB0C21F9785 for ; Thu, 1 Nov 2012 21:24:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A974BD9310; Fri, 2 Nov 2012 05:24:04 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ozpp1Bt3HneA; Fri, 2 Nov 2012 05:24:04 +0100 (MET) Received: from [10.67.199.86] (72-254-238-23.client.stsn.net [72.254.238.23]) (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 D4F30D930C; Fri, 2 Nov 2012 05:24:03 +0100 (MET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <5092E68B.8070902@cisco.com> Date: Fri, 2 Nov 2012 00:24:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2FE57FE3-6F59-46B8-9AB5-CE2E64807D92@tik.ee.ethz.ch> References: <500039DE.5050706@cisco.com> <071B9C0F-B58F-489A-99E1-A3A4A4D25382@tik.ee.ethz.ch> <5092E68B.8070902@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1499) Cc: draft-ietf-ipfix-a9n@tools.ietf.org, IETF IPFIX Working Group Subject: Re: [IPFIX] review of draft-ietf-ipfix-a9n-04 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: Fri, 02 Nov 2012 04:24:06 -0000 Paul, I wondered this myself, and I suspect you can't find the LC announcement = for this document because you may not be searching far enough in the = past. WGLC on -a9n began on 5 February 2012, nearly nine months ago = (!!!), following a Christmas delay on top of an indication of WGLC = readiness at the Taipei IETF meeting. Since that time, -04 was published in response to WGLC comments, -05 was = published in response to comments you sent on an outdated individual = version of the draft, -06 in response to your -04 review comments, and = -07 in response to Benoit's AD review.=20 Points inline. On 1 Nov 2012, at 16:15, Paul Aitken wrote: > Nevil, when was the WGLC on this document? I can't find any WG emails = with the appropriate subject line. >=20 >=20 > Brian, the IESG LC prompted me to re-review this. Please see inline as = usual... >=20 >=20 >>>> 2. Terminology >>>>=20 >>>> Terms used in this document that are defined in the Terminology >>>> section of the IPFIX Protocol = [I-D.ietf-ipfix-protocol-rfc5101bis] >>>> document are to be interpreted as defined there. >>>>=20 >>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT", >>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this >>>> document are to be interpreted as described in [RFC2119]. >>>>=20 >>>> In addition, this document defines the following terms >>>>=20 >>>> Aggregated Flow: A Flow, as defined by >>>> [I-D.ietf-ipfix-protocol-rfc5101bis], derived from a set of = zero >>>> or more original Flows within a defined Aggregation Interval. = The >>>>=20 >>> Zero things can't be aggregated. You can only say, "none were seen". >> This is equivalent to what's written in the terminology, no? Export = of an aggregation of an empty set is the same thing as an assertion that = nothing was observed corresponding to the given key in the reported = interval. >=20 > So to be quite clear: when zero flows are aggregated, is the result = zero Aggregated Flows, or is the result one Aggregated Flow which says = there was nothing to be aggregated? (I know it sounds odd, but it's a = serious question.) It depends (I know it sounds flippant, but it's a serious answer). If an IAP has been configured to report all volumes (matching some = selection) per (regular, externally imposed) interval, for example, and = it observed zero packets for an interval, it should report that so it's = clear there were no flows and not a missing report: "I was looking for = this key, but I didn't see it, sorry!" On the other hand, when aggregating by more complicated keys or larger = selections it probably doesn't make much sense to report "I saw no = flows" for all the keys for which no flows/packets/bytes were seen, = unless one is trying to generate a whole bunch of useless data records = e.g. to stress-test a collector. The intention is to leave this up to implementors as appropriate for = each specific set of application requirements. >> BTW, the case of a collector or mediator aggregating received flows = presents another possibility: the flow could be received late (eg, = delayed export), so rather than re-opening an old start / mid / end = aggregation, the flow is simply included in the "current" aggregation. = ie, real time aggregation, regardless of the flow timestamps. >> A good point; however, this is already covered in section 6.2:=20 >>=20 >> In certain circumstances, additional delay at the original = Exporter >> may cause an IAP to close an interval before the last Original >> Flow(s) accountable to the interval arrives; in this case the IAP >> SHOULD drop the late Original Flow(s). Accounting of flows lost = at >> an Intermediate Process due to such issues is covered in >> [I-D.ietf-ipfix-mediation-protocol]. >>=20 >> Would you suggest loosening the language to allow an IAP to fake = timestamps to avoid drops in delay-intolerant situations? >=20 > So there are several options: >=20 > 1. drop the late flows. In this case the late traffic is utterly lost, = which may be quite undesirable. >=20 > 2. re-open the appropriate aggregation to correctly account the late = flows. > 2a. don't close aggregations immediately, but wait for some period and = accept late flows. >=20 > 3. account the late flows in the current (though wrong) aggregation. >=20 > I'd prefer that the doc discussed the options or gave reasons rather = than simply advising "SHOULD drop". The real solution IMO is wait and make sure you've got everything, and = treat exceptions as just that. 2a. is just a variant of that solution = with two different kinds of waiting. 3. is for when it's more important = to be conservative than to be correct, when waiting all the time isn't = possible. But this is getting very deeply into implementation choices = and application-specific requirements, so I'm inclined to leave it as = is. The intention here, again, is to give recommendations for non-corner = cases while allowing implementation flexibility.=20 Cheers, Brian= From trammell@tik.ee.ethz.ch Thu Nov 1 21:26:17 2012 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 5964921F9970 for ; Thu, 1 Nov 2012 21:26:17 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 JC8FZbJjaZQP for ; Thu, 1 Nov 2012 21:26:15 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6A28921F98D2 for ; Thu, 1 Nov 2012 21:26:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5310DD9310; Fri, 2 Nov 2012 05:26:14 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PHXumS3PXoRp; Fri, 2 Nov 2012 05:26:14 +0100 (MET) Received: from [10.67.199.86] (72-254-238-23.client.stsn.net [72.254.238.23]) (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 63CDBD930C; Fri, 2 Nov 2012 05:26:13 +0100 (MET) Content-Type: multipart/alternative; boundary="Apple-Mail=_2EFD296C-F3CE-4373-81F4-0893D9079E4C" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <5092F2FA.1090104@cisco.com> Date: Fri, 2 Nov 2012 00:26:11 -0400 Message-Id: <03ADAE4E-25F6-485B-BD2B-B0DE99B09012@tik.ee.ethz.ch> References: <500039DE.5050706@cisco.com> <071B9C0F-B58F-489A-99E1-A3A4A4D25382@tik.ee.ethz.ch> <5092E68B.8070902@cisco.com> <5092F2FA.1090104@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1499) Cc: draft-ietf-ipfix-a9n@tools.ietf.org, IETF IPFIX Working Group Subject: Re: [IPFIX] review of draft-ietf-ipfix-a9n-07 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: Fri, 02 Nov 2012 04:26:17 -0000 --Apple-Mail=_2EFD296C-F3CE-4373-81F4-0893D9079E4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Paul, Good comments, all, thanks; will address along with area review and = other IESG processing comments.=20 Cheers, Brian On 1 Nov 2012, at 18:08, Paul Aitken wrote: > Having missed the WGLC announcement and just seen the IESG LC = announcement, I thought I should quickly review the 04->05->06->07 = diffs. >=20 > As usual I have just a few minor points which I hope are helpful. >=20 > Sorry things are a bit jumbled up this time, which is due to reviewing = the three versions in order rather than the larger 04->07 all at once. >=20 >=20 > Section 3, 5th paragraph: >=20 > I think the paragraph means to say that conversion between Flows = is possible. > However, I mis-read that the IEs can be converted within a flow - = so there's potential ambiguity here: >=20 > While much of the discussion in this document, and all of the > examples, apply to the common case that the Original Flows to be > aggregated are all of the same underlying type (i.e., are = represented > with identical Templates or compatible Templates containing a core > set Information Elements which can be freely converted to one > another), and >=20 > Also, there's a missing "of": >=20 > with identical Templates or compatible Templates containing a core > set of Information Elements >=20 >=20 > Section 8: >=20 > Why was "pt" used for "protocolIdentifier"? Surely "pr" would have = been more obvious choice and less easily confused with "Port". >=20 >=20 > Under Figure 19: remove ";" : > After applying the interval distribution step to the source data in > Figure 10,; the Partially Aggregated flows are shown in Figure 20. >=20 >=20 > Under Figure 24: remove space before the comma: > information from the Original Flows in Figure 10 , and as such is = not >=20 >=20 > Section 6.2: > Note that when aggregating flows from multiple > Metering Processes with different active timeouts, the delay is > determined by the maximum active timeout. >=20 > - it's not so much "determined by" as "proportional to", because = an allowance should also be made for other delays. >=20 >=20 > Section 3, paragraph 4: >=20 > s/anonymising/anonymizing/ for consistency with the 8 other uses = in the doc. >=20 >=20 > Section 8: > The data records given as input to the examples in this section are > shown below; >=20 > say "in Figure 10", else the figure isn't referenced until after = Figure 12. >=20 >=20 > P. >=20 --Apple-Mail=_2EFD296C-F3CE-4373-81F4-0893D9079E4C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Hi, Paul,

Good comments, all, thanks; will address along with area review and other IESG processing comments. 

Cheers,

Brian

On 1 Nov 2012, at 18:08, Paul Aitken <paitken@cisco.com> wrote:

Having missed the WGLC announcement and just seen the IESG LC announcement, I thought I should quickly review the 04->05->06->07 diffs.

As usual I have just a few minor points which I hope are helpful.

Sorry things are a bit jumbled up this time, which is due to reviewing the three versions in order rather than the larger 04->07 all at once.


Section 3, 5th paragraph:

    I think the paragraph means to say that conversion between Flows is possible.
    However, I mis-read that the IEs can be converted within a flow - so there's potential ambiguity here:

   While much of the discussion in this document, and all of the
   examples, apply to the common case that the Original Flows to be
   aggregated are all of the same underlying type (i.e., are represented
   with identical Templates or compatible Templates containing a core
   set Information Elements which can be freely converted to one
   another), and

Also, there's a missing "of":

   with identical Templates or compatible Templates containing a core
   set of Information Elements


Section 8:

    Why was "pt" used for "protocolIdentifier"? Surely "pr" would have been more obvious choice and less easily confused with "Port".


Under Figure 19: remove ";" :
   After applying the interval distribution step to the source data in
   Figure 10,; the Partially Aggregated flows are shown in Figure 20.


Under Figure 24: remove space before the comma:
   information from the Original Flows in Figure 10 , and as such is not


Section 6.2:
   Note that when aggregating flows from multiple
   Metering Processes with different active timeouts, the delay is
   determined by the maximum active timeout.

    -  it's not so much "determined by" as "proportional to", because an allowance should also be made for other delays.


Section 3, paragraph 4:

    s/anonymising/anonymizing/ for consistency with the 8 other uses in the doc.


Section 8:
   The data records given as input to the examples in this section are
   shown below;

    say "in Figure 10", else the figure isn't referenced until after Figure 12.


P.


--Apple-Mail=_2EFD296C-F3CE-4373-81F4-0893D9079E4C-- From paitken@cisco.com Fri Nov 2 03:12:18 2012 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 65AFB21F99B3 for ; Fri, 2 Nov 2012 03:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.509 X-Spam-Level: X-Spam-Status: No, score=-10.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 Ue2YvwhJjDo5 for ; Fri, 2 Nov 2012 03:12:17 -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 8889221F99B8 for ; Fri, 2 Nov 2012 03:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2952; q=dns/txt; s=iport; t=1351851138; x=1353060738; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=+GiNceZWR1kf+KpopcpppXkWihR5LsXSYpKB7cD4j1I=; b=K+JzQqYEjT7NEM2wBqF6Om1YVs6oZoX5NoDJycPrWATpkyz787WQ4S/O 5KlfHYUHirW/qtXUuSwZxDIoUjKSBpVOZGxDssXFZFZuIer+mNRjVx1QZ /FyrU4c7UQ5lBKRmBS0T8VMAjQ7J79wDLg7BeV0DZy5qQBDBz9qun5I5Z M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FACibk1CQ/khN/2dsb2JhbABEgyzAC4EIgh4BAQEDARIBJUABBQsLIQwKDwkDAgECAUUGDQEHAQEXB4diBptwoAaMAYMLgzADlXmFa4hugWuCb4Fk X-IronPort-AV: E=Sophos;i="4.80,697,1344211200"; d="scan'208";a="146185207" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 02 Nov 2012 10:12:16 +0000 Received: from [10.61.102.64] (dhcp-10-61-102-64.cisco.com [10.61.102.64]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA2ACFd8025181; Fri, 2 Nov 2012 10:12:15 GMT Message-ID: <50939C80.5020708@cisco.com> Date: Fri, 02 Nov 2012 10:12:16 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Brian Trammell References: <500039DE.5050706@cisco.com> <071B9C0F-B58F-489A-99E1-A3A4A4D25382@tik.ee.ethz.ch> <5092E68B.8070902@cisco.com> <2FE57FE3-6F59-46B8-9AB5-CE2E64807D92@tik.ee.ethz.ch> In-Reply-To: <2FE57FE3-6F59-46B8-9AB5-CE2E64807D92@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-ipfix-a9n@tools.ietf.org, IETF IPFIX Working Group Subject: Re: [IPFIX] review of draft-ietf-ipfix-a9n-04 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: Fri, 02 Nov 2012 10:12:18 -0000 Brian, > I wondered this myself, and I suspect you can't find the LC announcement for this document because you may not be searching far enough in the past. Not so. I searched both my email and the IPFIX WG archive back to -a9n-00 on October 31st 2011. > WGLC on -a9n began on 5 February 2012, nearly nine months ago (!!!), following a Christmas delay on top of an indication of WGLC readiness at the Taipei IETF meeting. > > Since that time, -04 was published in response to WGLC comments, -05 was published in response to comments you sent on an outdated individual version of the draft, -06 in response to your -04 review comments, and -07 in response to Benoit's AD review. Then it has been well reviewed :-) >>> BTW, the case of a collector or mediator aggregating received flows presents another possibility: the flow could be received late (eg, delayed export), so rather than re-opening an old start / mid / end aggregation, the flow is simply included in the "current" aggregation. ie, real time aggregation, regardless of the flow timestamps. >>> A good point; however, this is already covered in section 6.2: >>> >>> In certain circumstances, additional delay at the original Exporter >>> may cause an IAP to close an interval before the last Original >>> Flow(s) accountable to the interval arrives; in this case the IAP >>> SHOULD drop the late Original Flow(s). Accounting of flows lost at >>> an Intermediate Process due to such issues is covered in >>> [I-D.ietf-ipfix-mediation-protocol]. >>> >>> Would you suggest loosening the language to allow an IAP to fake timestamps to avoid drops in delay-intolerant situations? >> So there are several options: >> >> 1. drop the late flows. In this case the late traffic is utterly lost, which may be quite undesirable. >> >> 2. re-open the appropriate aggregation to correctly account the late flows. >> 2a. don't close aggregations immediately, but wait for some period and accept late flows. >> >> 3. account the late flows in the current (though wrong) aggregation. >> >> I'd prefer that the doc discussed the options or gave reasons rather than simply advising "SHOULD drop". > The real solution IMO is wait and make sure you've got everything, and treat exceptions as just that. 2a. is just a variant of that solution with two different kinds of waiting. 3. is for when it's more important to be conservative than to be correct, when waiting all the time isn't possible. But this is getting very deeply into implementation choices and application-specific requirements, so I'm inclined to leave it as is. The intention here, again, is to give recommendations for non-corner cases while allowing implementation flexibility. What you say seems to be contrary to the "SHOULD drop" recommendation. Perhaps that should be downgraded to "MAY drop", which seems to give permission rather than a recommendation. P. From trammell@tik.ee.ethz.ch Fri Nov 2 03:58:24 2012 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 DA30D21F87CD for ; Fri, 2 Nov 2012 03:58:24 -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=[AWL=0.000, 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 K918Uzmkm8BE for ; Fri, 2 Nov 2012 03:58:24 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8F421F885A for ; Fri, 2 Nov 2012 03:58:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id ED288D9312; Fri, 2 Nov 2012 11:58:22 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dMq9y5v19AZN; Fri, 2 Nov 2012 11:58:22 +0100 (MET) Received: from [10.67.199.86] (72-254-238-23.client.stsn.net [72.254.238.23]) (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 58F10D9304; Fri, 2 Nov 2012 11:58:21 +0100 (MET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <50939C80.5020708@cisco.com> Date: Fri, 2 Nov 2012 06:58:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <81148FC1-091C-42ED-8D4E-4AA4A30FFE36@tik.ee.ethz.ch> References: <500039DE.5050706@cisco.com> <071B9C0F-B58F-489A-99E1-A3A4A4D25382@tik.ee.ethz.ch> <5092E68B.8070902@cisco.com> <2FE57FE3-6F59-46B8-9AB5-CE2E64807D92@tik.ee.ethz.ch> <50939C80.5020708@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1499) Cc: draft-ietf-ipfix-a9n@tools.ietf.org, IETF IPFIX Working Group Subject: Re: [IPFIX] review of draft-ietf-ipfix-a9n-04 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: Fri, 02 Nov 2012 10:58:25 -0000 Hi, Paul, On 2 Nov 2012, at 6:12, Paul Aitken wrote: > Brian, >=20 >> I wondered this myself, and I suspect you can't find the LC = announcement for this document because you may not be searching far = enough in the past. >=20 > Not so. I searched both my email and the IPFIX WG archive back to = -a9n-00 on October 31st 2011. Hm, indeed, the draft is called "Aggregation" in the subject of the WGLC = message... >>>>=20 >>> So there are several options: >>>=20 >>> 1. drop the late flows. In this case the late traffic is utterly = lost, which may be quite undesirable. >>>=20 >>> 2. re-open the appropriate aggregation to correctly account the late = flows. >>> 2a. don't close aggregations immediately, but wait for some period = and accept late flows. >>>=20 >>> 3. account the late flows in the current (though wrong) aggregation. >>>=20 >>> I'd prefer that the doc discussed the options or gave reasons rather = than simply advising "SHOULD drop". >> The real solution IMO is wait and make sure you've got everything, = and treat exceptions as just that. 2a. is just a variant of that = solution with two different kinds of waiting. 3. is for when it's more = important to be conservative than to be correct, when waiting all the = time isn't possible. But this is getting very deeply into implementation = choices and application-specific requirements, so I'm inclined to leave = it as is. The intention here, again, is to give recommendations for = non-corner cases while allowing implementation flexibility. >=20 > What you say seems to be contrary to the "SHOULD drop" recommendation. = Perhaps that should be downgraded to "MAY drop", which seems to give = permission rather than a recommendation. Works for me. I'll put it on the pile for -08 Cheers, Brian From paitken@cisco.com Fri Nov 2 04:18:24 2012 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 44C8C21F8B88 for ; Fri, 2 Nov 2012 04:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.517 X-Spam-Level: X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 7n8Bb1HuN0Fs for ; Fri, 2 Nov 2012 04:18:23 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 864FD21F8B83 for ; Fri, 2 Nov 2012 04:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=373; q=dns/txt; s=iport; t=1351855103; x=1353064703; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=oBY6zKkROTFzrXWwkGwUEgbAYSsGWpSgKC5pXUL7Sn0=; b=ITEhF9vb4EO58JGuLQ+2pU3XZUbCjLVH1rr8fvr+o756McqMeNcKBXJN K9uB6kg0iX8KNatjpoc3WIw/mpC+1RFjZJK8Wc2qN79eeCKMchNZtcJ6k 86F+7Yjn5Ue5I90OixF2TOTkg51xisQM1//nrKtXy36EqCQSUecwRG7Bk I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAGGrk1CQ/khR/2dsb2JhbABEgyzADIEIgh4BAQEDARIBJUABEAshFg8JAwIBAgFFBg0BBwEBHodiBpttoAuSPAOVeYVriG6Ba4JvgWQ X-IronPort-AV: E=Sophos;i="4.80,699,1344211200"; d="scan'208";a="9299475" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 02 Nov 2012 11:18:19 +0000 Received: from [10.61.102.64] (dhcp-10-61-102-64.cisco.com [10.61.102.64]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA2BIJgf032761; Fri, 2 Nov 2012 11:18:19 GMT Message-ID: <5093ABFC.6070103@cisco.com> Date: Fri, 02 Nov 2012 11:18:20 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Brian Trammell References: <500039DE.5050706@cisco.com> <071B9C0F-B58F-489A-99E1-A3A4A4D25382@tik.ee.ethz.ch> <5092E68B.8070902@cisco.com> <2FE57FE3-6F59-46B8-9AB5-CE2E64807D92@tik.ee.ethz.ch> <50939C80.5020708@cisco.com> <81148FC1-091C-42ED-8D4E-4AA4A30FFE36@tik.ee.ethz.ch> In-Reply-To: <81148FC1-091C-42ED-8D4E-4AA4A30FFE36@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-ipfix-a9n@tools.ietf.org, IETF IPFIX Working Group Subject: Re: [IPFIX] review of draft-ietf-ipfix-a9n-04 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: Fri, 02 Nov 2012 11:18:24 -0000 >>> I wondered this myself, and I suspect you can't find the LC announcement for this document because you may not be searching far enough in the past. >> Not so. I searched both my email and the IPFIX WG archive back to -a9n-00 on October 31st 2011. > Hm, indeed, the draft is called "Aggregation" in the subject of the WGLC message... Thanks, I see it now. P. From salvatore.dantonio@uniparthenope.it Mon Nov 5 07:04:09 2012 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 A10A021F849C for ; Mon, 5 Nov 2012 07:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.269 X-Spam-Level: X-Spam-Status: No, score=-1.269 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] 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 Sokxd2x5Lw+U for ; Mon, 5 Nov 2012 07:04:03 -0800 (PST) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB5121F849A for ; Mon, 5 Nov 2012 07:04:02 -0800 (PST) Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id 36D8215B45; Mon, 5 Nov 2012 15:04:00 +0000 (UTC) Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 1d8b_072de1ac_275a_11e2_9101_001372515a5c; Mon, 05 Nov 2012 16:03:58 +0100 Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id 6F041C42EE; Mon, 5 Nov 2012 16:03:50 +0100 (CET) Received: by spamk.uniparthenope.it (Postfix, from userid 500) id 6C0B8C432A; Mon, 5 Nov 2012 16:03:50 +0100 (CET) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by spamk.uniparthenope.it (Postfix) with ESMTP id 65B03C4328; Mon, 5 Nov 2012 16:03:44 +0100 (CET) Received: from saldantoPC (unknown [10.100.9.102]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id 3234215C79; Mon, 5 Nov 2012 16:03:53 +0100 (CET) From: "Salvatore D'Antonio" To: "'Benoit Claise'" , , References: <4FC74398.50805@cisco.com> <4FC89B99.40107@cisco.com> <506DA106.5060705@cisco.com> <50904E1D.7060909@cisco.com> In-Reply-To: <50904E1D.7060909@cisco.com> Date: Mon, 5 Nov 2012 16:03:53 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac227+sEZJvYKDxAS/GY4C/oLok6KAEbv9AA Content-Language: it Message-ID: <007301cdbb66$c58d6a10$50a83e30$@dantonio@uniparthenope.it> Content-Type: multipart/alternative; boundary="----=_NextPart_000_0074_01CDBB6F.2751D210" X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20121105 #8315384, check: 20121105 clean Cc: ipfix-chairs@tools.ietf.org Subject: [IPFIX] R: New AD review of draft-ietf-ipfix-flow-selection-tech-10.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: Mon, 05 Nov 2012 15:04:09 -0000 Messaggio multipart in formato MIME. ------=_NextPart_000_0074_01CDBB6F.2751D210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Benoit, =20 My comments to your comments inline. =20 Da: Benoit Claise [mailto:bclaise@cisco.com]=20 Inviato: marted=EC 30 ottobre 2012 23:01 A: ipfix@ietf.org; draft-ietf-ipfix-flow-selection-tech@tools.ietf.org Cc: ipfix-chairs@tools.ietf.org Oggetto: Re: [IPFIX] New AD review of draft-ietf-ipfix-flow-selection-tech-10.txt =20 Dear draft-ietf-ipfix-flow-selection-tech authors, I was expecting a quick discussion on the very few remaining issues... That has not happened. The draft status is: AD evaluation, Revised ID Needed. Regards, Benoit Dear authors, The draft improved quite dramatically.=20 Thanks for that. See in line for some more comments. I removed all unnecessary text. Dear authors, I'm performing the (new) AD review of draft-ietf-ipfix-flow-selection-tech-10.txt Lucky you, an extra pair of eyes specifically looking at your draft=20 If some points have been discussed already on the mailing list, let me = know. I have to admit that I have not been following the latest iterations of = this draft. IMHO, this document needs some more work...=20 I don't think that this document is really in line with the other Intermediate Processes documents:=20 http://tools.ietf.org/html/rfc6235 http://tools.ietf.org/html/draft-ietf-ipfix-a9n-03 Note that I might have some more comments once all the points in this = email are addressed, as there are many ;-) However, I'm available for a conf. call to clarify my points if you want = to=20 See in-line.=20 ... 8.2. Registration of Object Identifier . . . . . . . . . . . . 32 = 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 = 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 = 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 = 11.1. Normative References . . . . . . . . . . . . . . . . . . . 34 = 11.2. Informative References . . . . . . . . . . . . . . . . . . 34 = Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 = Don't you have to include the non-normative XML in the appendix, as it = was done for RFC5102, RFC5103?=20 =20 I will do in the next version of the ID.=20 2. Terminology=20 This document is consistent with the terminology introduced in=20 [RFC5101], [RFC5470], [RFC5475] and [RFC3917]. As in [RFC5101] and=20 [RFC5476], the first letter of each IPFIX-specific and PSAMP-specific = term is capitalized along with the flow selection specific terms=20 defined here.=20 * Packet Classification=20 Packet Classification is a process by which packets are mapped to=20 specific Flow Records based on packet properties or external=20 properties (e.g. interface). The properties (e.g. header=20 information, packet content, AS number) make up the Flow Key. In=20 case a Flow Record for a specific Flow Key already exists the Flow = Record is updated, otherwise a new Flow Record is created.=20 How is this different that the Metering Process (RFC5101)? Metering Process =20 The Metering Process generates Flow Records. Inputs to the process are packet headers and characteristics observed at an Observation Point, and packet treatment at the Observation Point (for example, the selected output interface). =20 The Metering Process consists of a set of functions that includes packet header capturing, timestamping, sampling, classifying, and maintaining Flow Records. =20 The maintenance of Flow Records may include creating new records, updating existing ones, computing Flow statistics, deriving further Flow properties, detecting Flow expiration, passing Flow Records to the Exporting Process, and deleting Flow Records. What is the connection with the Metering Process? Figure 1 seems to suggest that Packet Classification is a subset of the Metering Process... not sure that one was answered. Yes. I already answered. Packet Classification is a function of the = Metering process. Your interpretation is correct. * Packet Aggregation Process=20 In the IPFIX Metering Process the Packet Aggregation Process=20 aggregates packet data into flow data and forms the Flow Records.=20 How is this different from the Metering Process? the "Packet Aggregation Process" is not used in the document. Why do we = need it? I agree with you. We do not need such definition. I will remove it in = the new version of the ID.=20 After the aggregation step only the aggregated flow information is = available. Information about individual packets is lost.=20 Intermediate Flow Selection Process: an Intermediate Process as in [RFC6183 ] that ... =20 =20 The new definition improved a lot: * Intermediate Flow Selection Process =20 An Intermediate Flow Selection Process takes Flow Records as its input and selects a subset of this set as its output. Intermediate Flow Selection Process is a more general concept than Intermediate Selection Process as defined in [RFC6183 ]. While an Intermediate Selection Process selects Flow Records from a sequence based upon criteria-evaluated Flow record values and passes only those Flow Records that match the criteria, an Intermediate Flow Selection Process selects Flow Records using selection criteria applicable to a larger set of Flow characteristics and information. But is there a reason why this definition can't be based on = "intermediate Process" from RFC 6183: Intermediate Process =20 An Intermediate Process takes a record stream as its input from Collecting Processes, Metering Processes, IPFIX File Readers, other Intermediate Processes, or other record sources; performs some transformations on this stream based upon the content of each record, states maintained across multiple records, or other data sources; and passes the transformed record stream as its output to Exporting Processes, IPFIX File Writers, or other Intermediate Processes in order to perform IPFIX Mediation. Typically, an Intermediate Process is hosted by an IPFIX Mediator. Alternatively, an Intermediate Process may be hosted by an Original Exporter. =20 According to the definition of =93Intermediate Process=94 from RFC 6183, = such a process is typically hosted by an IPFIX Mediator. Alternatively, it may = be hosted by an Original Exporter. In my view, an Intermediate Flow = Selection Process could be also hosted by a Collector. =20 So=20 * Intermediate Flow Selection Process =20 An Intermediate Flow Selection Process is an Intermediate Process = as in [RFC6183 ] that takes Flow Records as its input and selects a subset of this set as its output. Intermediate Flow Selection Process is a more general concept than Intermediate Selection Process as defined in [RFC6183 ]. While an Intermediate Selection Process selects Flow Records from a sequence based upon criteria-evaluated Flow record values and passes only those Flow Records that match the criteria, an Intermediate Flow Selection Process selects Flow Records using selection criteria applicable to a larger set of Flow characteristics and information. =20 Regarding terminology, I still some instances of "observation point". = Should be "Observation Point" I will fix them. ... 4. Flow selection as a Function in the IPFIX Architecture=20 =20 Thanks for your new figure 1. One editorial change: change the + in the left vertical line. Ok, will do. = +=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+ | | | Mediator | | + +-V-------------------+ | | | | Collecting Process | | | + +---------------------+ | | | | Intermediate Flow | | | | | Selection Process | | | + +---------------------+ | | | | Exporting Process | | | + +-|-------------------+ | | = +=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+ | =20 5.1. Flow Filtering=20 Flow Filtering is a deterministic function on the IPFIX Flow Record=20 content. If the relevant flow characteristics are already observable = at packet level (e.g. Flow Keys), Flow Filtering can be applied=20 before aggregation at packet level. In order to be compliant with=20 this document, at least the Property Match Filtering MUST be=20 implemented.=20 This contradicts. In order to be compliant with this document, at least one of the flow selection schemes MUST be implemented. Actually, wrong cut/paste. This contradicts, in section 1: In order to be compliant with this document, at least the Property Match Filtering MUST be implemented. =20 This comment is not clear to me. Both in Section 1 and in Section 5.1 = (Flow Filtering) I used the same sentence =93In order to be compliant with = this document, at least the Property Match Filtering MUST be implemented=94. 8. IANA Considerations=20 8.1. Registration of Information Elements=20 Table 3: Information Elements to be registered, you can't put the value = 1, 2, 3,=20 You need TBD1, TBD2, etc... And you must add "IANA Note: please replace TBD1, TBD2, ... with the assigned values, throughout the document." Thanks. I will fix this point. 8.2. Registration of Object Identifier=20 RFC 5815 is obsoleted by RFC 6615 =20 What you want is an extra in = http://www.iana.org/assignments/smi-numbers, pointing to this RFC: Sub-registry Name: IPFIX-SELECTOR-MIB Functions Reference: [RFC6615] Registration Procedures: Expert Review=20 Prefix: iso.org.dod.internet.mgmt.mib-2.ipfixSelectorMIB.ipfixSelectorObjects.ipf= ixS electorFunctions=20 (1.3.6.1.2.1.194.1.1) =20 Decimal Name Description = Reference ------- --------------------- --------------------------------- = --------- 1 ipfixFuncSelectAll Select everything = [RFC6615] 2 psampSampCountBased Systematic Count-based Sampling = [RFC6727] 3 psampSampTimeBased Systematic Time-based Sampling = [RFC6727] 4 psampSampRandOutOfN Random n-out-of-N Sampling = [RFC6727] 5 psampSampUniProb Universal Probabilistic Sampling = [RFC6727] 6 psampFiltPropMatch Property Match Filtering = [RFC6727] 7 psampFiltHash Hash-based Filtering = [RFC6727] So you need TBDx Ok. +---------+-----------------------+---------------------+-----------+ | Decimal | Name | Description | Reference | +---------+-----------------------+---------------------+-----------+ | TBDx | flowSelectorAlgorithm | This Object | [RFCyyyy] | | | | Identifier | | | | | identifies the Flow | | | | | selection technique | | | | | (e.g., Filtering, | | | | | Sampling) that is | | | | | applied by the Flow | | | | | Selection Process | | +---------+-----------------------+---------------------+-----------+ =20 Table 4: Object Identifiers to be registered "IANA Note: please replace TBDx with the assigned value, throughout the document." Btw, there is a mismatch between the IANA registry and the table in = section 7.1: +----+------------------------+--------------------------+ | ID | Technique | Parameters | +----+------------------------+--------------------------+ | 1 | Systematic count-based | flowSamplingInterval | | | Sampling | flowSamplingSpacing | +----+------------------------+--------------------------+ | 2 | Systematic time-based | flowSamplingTimeInterval | | | Sampling | flowSamplingTimeSpacing | +----+------------------------+--------------------------+ | 3 | Random n-out-of-N | samplingSize | | | Sampling | samplingPopulation | +----+------------------------+--------------------------+ | 4 | Uniform probabilistic | samplingProbability | | | Sampling | | +----+------------------------+--------------------------+ | 5 | Property Match | Information Element | | | Filtering | Value Range | +----+------------------------+--------------------------+ | Hash-based Filtering | hashInitialiserValue | +----+------------------------+ hashFlowDomain | | 6 | using BOB | hashSelectedRangeMin | +----+------------------------+ hashSelectedRangeMax | | 7 | using IPSX | hashOutputRangeMin | +----+------------------------+ hashOutputRangeMax | | 8 | using CRC | | +----+------------------------+--------------------------+ | 9 | Flow-state Dependent | No agreed Parameters | | | Flow Selection | | +----+------------------------+--------------------------+ =20 Also, in this table above, you need "TBDx" instead of 9 =20 Ok. =20 - I see "Flow Selection", but this term is not defined. I will replace =93Flow Selection=94 with =93Intermediate Flow Selection = Process=94.=20 Thanks. Regards, Benoit. =20 =20 Thanks a lot. =20 Kind regards, =20 Salvatore _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix =20 _____ =20 Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2012.0.2221 / Database dei virus: 2441/5364 - Data di = rilascio: 30/10/2012 ------=_NextPart_000_0074_01CDBB6F.2751D210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Benoit,

 

My comments to your comments = inline.

 

Da: Benoit Claise [mailto:bclaise@cisco.com]
Inviato: marted=EC 30 ottobre 2012 23:01
A: ipfix@ietf.org; = draft-ietf-ipfix-flow-selection-tech@tools.ietf.org
Cc: ipfix-chairs@tools.ietf.org
Oggetto: Re: [IPFIX] New AD review of = draft-ietf-ipfix-flow-selection-tech-10.txt

 

Dear draft-ietf-ipfix-flow-selection-tech authors,

I was expecting a quick discussion on the very few remaining = issues...
That has not happened.
The draft status is: AD evaluation, Revised ID Needed.

Regards, Benoit

Dear authors,

The draft improved quite dramatically.
Thanks for that.
See in line for some more comments. I removed all unnecessary = text.

Dear authors,

I'm performing the (new) AD review of  = draft-ietf-ipfix-flow-selection-tech-10.txt
Lucky you, an extra pair of eyes specifically looking at your draft

If some points have been discussed already on the mailing list, let me = know. I have to admit that I have not been following the latest iterations of = this draft.

IMHO, this document needs some more work...
I don't think that this document is really in line with the other = Intermediate Processes documents:
    http://tools.ietf.org/html/rf= c6235
    http://tools.= ietf.org/html/draft-ietf-ipfix-a9n-03
Note that I might have some more comments once all the points in this = email are addressed, as there are many ;-)
However, I'm available for a conf. call to clarify my points if you want = to

See in-line.

...

     8.2.  Registration of = Object Identifier  . . . . . . . . . . . . 32
   9.  Security Considerations  . . . . . . . . . . = . . . . . . . . . 32
   10. Acknowledgments  . . . . . . . . . . . . . . . . . = . . . . . . 34
   11. References . . . . . . . . . . . . . . . . . . . . . . = . . . . 34
     11.1. Normative References . . . . . . . . . . = . . . . . . . . . 34
     11.2. Informative References . . . . . . . . . = . . . . . . . . . 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . = . . . . 35

Don't you have to include the non-normative XML in = the appendix, as it was done for RFC5102, RFC5103?

 

I will do in the next = version of the ID.

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.


   * Packet Classification

      Packet Classification is a process by = which packets are mapped to
      specific Flow Records based on packet = properties or external
      properties (e.g. interface).  The properties (e.g. header
      information, packet content, AS number) = make up the Flow Key. In
      case a Flow Record for a specific Flow = Key already exists the Flow
      Record is updated, otherwise a new Flow = Record is created.


How is this different that the Metering Process = (RFC5101)?

=A0=A0 Metering =
Process
 
=A0=A0=A0=A0=A0 =
The Metering Process generates Flow Records.=A0 Inputs to =
the
=A0=A0=A0=A0=A0 process are packet headers and =
characteristics observed at an
=A0=A0=A0=A0=A0 =
Observation Point, and packet treatment at the Observation =
Point
=A0=A0=A0=A0=A0 (for example, the selected =
output =
interface).
 
=A0=A0=A0=A0=
=A0 The Metering Process consists of a set of functions that =
includes
=A0=A0=A0=A0=A0 packet header capturing, =
timestamping, sampling, classifying, =
and
=A0=A0=A0=A0=A0 maintaining Flow =
Records.
 
=A0=A0=A0=A0=A0=
 The maintenance of Flow Records may include creating new =
records,
=A0=A0=A0=A0=A0 updating existing ones, =
computing Flow statistics, deriving
=A0=A0=A0=A0=A0 =
further Flow properties, detecting Flow expiration, passing =
Flow
=A0=A0=A0=A0=A0 Records to the Exporting =
Process, and deleting Flow Records.

What is the connection with the Metering = Process?
Figure 1 seems to suggest that Packet Classification is a subset of the Metering Process...

not sure that one was answered.

Yes. I already answered. Packet = Classification is a function of the Metering process. Your interpretation is = correct.





   * Packet Aggregation Process

      In the IPFIX Metering Process the Packet Aggregation Process
      aggregates packet data into flow data and = forms the Flow Records.

How is this different from the Metering = Process?

the "Packet Aggregation Process" is not = used in the document. Why do we need it?

I agree with you. We = do not need such definition. I will remove it in the new version of the ID. =



      After the aggregation step only the aggregated flow information is
      available.  Information about = individual packets is lost. 


Intermediate Flow Selection Process: an Intermediate Process as =
in
=A0=A0=A0=A0=A0 [RFC6183] that =
...
 

 

The new definition improved a lot:

=A0* Intermediate Flow Selection =
Process
 
=A0=A0=A0=A0=A0 =
An Intermediate Flow Selection Process takes Flow Records as =
its
=A0=A0=A0=A0=A0 input and selects a subset of =
this set as its output.
=A0=A0=A0=A0=A0 =
Intermediate Flow Selection Process is a more general concept =
than
=A0=A0=A0=A0=A0 Intermediate Selection Process =
as defined in [RFC6183].=A0 While an
 =
=A0=A0=A0=A0=A0Intermediate Selection Process selects Flow Records from =
a
=A0=A0=A0=A0=A0 sequence based upon =
criteria-evaluated Flow record values =
and
=A0=A0=A0=A0=A0 passes only those Flow Records =
that match the criteria, an
=A0=A0=A0=A0=A0 =
Intermediate Flow Selection Process selects Flow Records =
using
=A0=A0=A0=A0=A0 selection criteria applicable =
to a larger set of Flow
=A0=A0=A0=A0=A0 =
characteristics and information.

But is there a reason why this definition can't be = based on "intermediate Process" from RFC 6183:

Intermediate =
Process
 
=A0=A0=A0=A0=A0 =
An Intermediate Process takes a record stream as its input =
from
=A0=A0=A0=A0=A0 Collecting Processes, Metering =
Processes, IPFIX File Readers,
=A0=A0=A0=A0=A0 =
other Intermediate Processes, or other record sources; =
performs
=A0=A0=A0=A0=A0 some transformations on =
this stream based upon the content of each
 =
=A0=A0=A0=A0=A0record, states maintained across multiple records, or =
other data
=A0=A0=A0=A0=A0 sources; and passes the =
transformed record stream as its output =
to
=A0=A0=A0=A0=A0 Exporting Processes, IPFIX File =
Writers, or other Intermediate
=A0=A0=A0=A0=A0 =
Processes in order to perform IPFIX Mediation.=A0 Typically, =
an
=A0=A0=A0=A0=A0 Intermediate Process is hosted =
by an IPFIX Mediator.
=A0=A0=A0=A0=A0 =
Alternatively, an Intermediate Process may be hosted by =
an
=A0=A0=A0=A0=A0 Original =
Exporter.
 
According to the definition of “Intermediate Process” =
from RFC 6183, such a process is typically hosted by an IPFIX Mediator. =
Alternatively, it may be hosted by an Original Exporter. In my view, an =
Intermediate Flow Selection Process could be also hosted by a =
Collector.
 

So 

=A0* Intermediate Flow Selection =
Process
 
=A0=A0=A0=A0 =
=A0An Intermediate Flow Selection Process is an Intermediate Process =
as in
=A0=A0=A0=A0=A0 [RFC6183] that takes Flow Records as =
its
=A0=A0=A0=A0=A0 input and selects a subset of =
this set as its output.
=A0=A0=A0=A0=A0 =
Intermediate Flow Selection Process is a more general concept =
than
=A0=A0=A0=A0=A0 Intermediate Selection Process =
as defined in [RFC6183].=A0 While =
an
=A0=A0=A0=A0=A0 Intermediate Selection Process =
selects Flow Records from a
=A0=A0=A0=A0=A0 =
sequence based upon criteria-evaluated Flow record values =
and
=A0=A0=A0=A0=A0 passes only those Flow Records =
that match the criteria, an
=A0=A0=A0=A0=A0 =
Intermediate Flow Selection Process selects Flow Records =
using
=A0=A0=A0=A0=A0 selection criteria applicable =
to a larger set of Flow
=A0=A0=A0=A0=A0 =
characteristics and information.



 


Regarding terminology, I still some instances of "observation = point". Should be "Observation Point"

I will fix = them.


...



4.  Flow selection as a Function in the IPFIX Architecture
  

Thanks for your new = figure 1.
One editorial change: change the + in the left vertical = line.

Ok, will = do.

=A0=A0=A0=A0=A0 =
+=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D+=A0=A0=A0=A0=A0 =
|
=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0 |=A0 =
Mediator=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0 =
|
=A0=A0=A0=A0=A0 +=A0=A0=A0 =
+-V-------------------+=A0=A0=A0 |=A0=A0=A0=A0=A0 =
|
=A0=A0=A0=A0=A0 |=A0=A0=A0 | Collecting =
Process=A0 |=A0=A0=A0 |=A0=A0=A0=A0=A0 =
|
=A0=A0=A0=A0=A0 +=A0=A0=A0 =
+---------------------+=A0=A0=A0 |=A0=A0=A0=A0=A0 =
|
=A0=A0=A0=A0=A0 |=A0=A0=A0 | Intermediate =
Flow=A0=A0 |=A0=A0=A0 |=A0=A0=A0=A0=A0 =
|
=A0=A0=A0=A0=A0 |=A0=A0=A0 | Selection =
Process=A0=A0 |=A0=A0=A0 |=A0=A0=A0=A0=A0 =
|
=A0=A0=A0=A0=A0 +=A0=A0=A0 =
+---------------------+=A0=A0=A0 |=A0=A0=A0=A0=A0 =
|
=A0=A0=A0=A0=A0 |=A0=A0=A0 |=A0 Exporting =
Process=A0 |=A0=A0=A0 |=A0=A0=A0=A0=A0 =
|
=A0=A0=A0=A0=A0 +=A0=A0=A0 =
+-|-------------------+=A0=A0=A0 |=A0=A0=A0=A0=A0 =
|
=A0=A0=A0=A0=A0 =
+=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D+=A0=A0=A0=A0=A0 =
|
=A0=A0=A0=A0=A0


5.1.  Flow Filtering

   Flow Filtering is a deterministic function on the IPFIX = Flow Record
   content.  If the relevant flow characteristics are = already observable
   at packet level (e.g.  Flow Keys), Flow Filtering can = be applied
   before aggregation at packet level.  In order to be = compliant with
   this document, at least the Property Match Filtering MUST = be
   implemented.

This contradicts.

=A0=A0 In order to be compliant with this document, =
at
=A0=A0 least one of the flow selection schemes =
MUST be implemented.

Actually, wrong cut/paste.
This contradicts, in section 1:

=A0=A0 In order to be compliant with this document, =
at
=A0=A0 least the Property Match Filtering MUST =
be implemented.

 

This comment is not = clear to me. Both in Section 1 and in Section 5.1 (Flow Filtering) I used the = same sentence “In order to be compliant with this document, at least = the Property Match Filtering MUST be = implemented”.





8.  IANA Considerations

8.1.  Registration of Information Elements


Table 3: Information Elements to be registered, you can't put the value = 1, 2, 3,
You need TBD1, TBD2, etc...
And you must add
"IANA Note: please replace TBD1, TBD2, ... with the assigned = values, throughout the document."

Thanks. I will fix = this point.





8.2.  Registration of Object Identifier


RFC 5815 is obsoleted by RFC 6615

What you want is an extra in http://www.iana.org/= assignments/smi-numbers, pointing to this RFC:

Sub-registry Name: IPFIX-SELECTOR-MIB =
Functions
Reference: =
[RFC6615]
Registration Procedures: Expert Review =

Prefix: =
iso.org.dod.internet.mgmt.mib-2.ipfixSelectorMIB.ipfixSelectorObjects.ipf=
ixSelectorFunctions =

(1.3.6.1.2.1.194.1.1)
&nb=
sp;
Decimal =
Name=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Description=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 Reference
------- --------------------- =
--------------------------------- =
---------
1=A0=A0=A0=A0=A0=A0 =
ipfixFuncSelectAll=A0=A0=A0 Select =
everything=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
[RFC6615]
2=A0=A0=A0=A0=A0=A0 =
psampSampCountBased=A0=A0 Systematic Count-based Sampling=A0=A0 =
[RFC6727]
3=A0=A0=A0=A0=A0=A0 =
psampSampTimeBased=A0=A0=A0 Systematic Time-based Sampling=A0=A0=A0 =
[RFC6727]
4=A0=A0=A0=A0=A0=A0 =
psampSampRandOutOfN=A0=A0 Random n-out-of-N =
Sampling=A0=A0=A0=A0=A0=A0=A0 =
[RFC6727]
5=A0=A0=A0=A0=A0=A0 =
psampSampUniProb=A0=A0=A0=A0=A0 Universal Probabilistic Sampling=A0 =
[RFC6727]
6=A0=A0=A0=A0=A0=A0 =
psampFiltPropMatch=A0=A0=A0 Property Match =
Filtering=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
[RFC6727]
7=A0=A0=A0=A0=A0=A0 =
psampFiltHash=A0=A0=A0=A0=A0=A0=A0=A0 Hash-based =
Filtering=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
[RFC6727]

So you need = TBDx

Ok. 

=A0=A0 =
+---------+-----------------------+---------------------+-----------+
=A0=A0 | Decimal | =
Name=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =
Description=A0=A0=A0=A0=A0=A0=A0=A0 | Reference =
|
=A0=A0 =
+---------+-----------------------+---------------------+-----------+
=A0=A0 |=A0 TBDx=A0=A0 | flowSelectorAlgorithm | This =
Object=A0=A0=A0=A0=A0=A0=A0=A0 | [RFCyyyy] |
=A0=A0 =
|=A0=A0=A0=A0=A0=A0=A0=A0 =
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =
Identifier=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|
=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 =
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =
identifies the Flow |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|
=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 =
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =
selection technique |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|
=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 =
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =
(e.g., Filtering,=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|
=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 =
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =
Sampling) that is=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|
=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 =
=A0|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =
applied by the Flow |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|
=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 =
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =
Selection Process=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|
=A0=A0 =
+---------+-----------------------+---------------------+-----------+
 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 Table 4: Object Identifiers to be =
registered


"IANA Note: please replace TBDx with the assigned value, throughout = the document."

Btw, there is a mismatch between the IANA registry and the table in = section 7.1:

=A0=A0 =
+----+------------------------+--------------------------+
=A0=A0 | ID |=A0=A0=A0=A0=A0 =
=A0=A0Technique=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0 =
Parameters=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0 =
+----+------------------------+--------------------------+
=A0=A0 | 1=A0 | Systematic count-based | =
flowSamplingInterval=A0=A0=A0=A0 |
=A0=A0 =
|=A0=A0=A0 | Sampling=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =
flowSamplingSpacing=A0=A0=A0=A0=A0 |
=A0=A0 =
+----+------------------------+--------------------------+
=A0=A0 | 2=A0 | Systematic time-based=A0 | =
flowSamplingTimeInterval |
=A0=A0 |=A0=A0=A0 | =
Sampling=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =
flowSamplingTimeSpacing=A0 |
=A0=A0 =
+----+------------------------+--------------------------+
=A0=A0 | 3=A0 | Random n-out-of-N=A0=A0=A0=A0=A0 | =
samplingSize=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|
=A0=A0 |=A0=A0=A0 | =
Sampling=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =
samplingPopulation=A0=A0=A0=A0=A0=A0 |
=A0=A0 =
+----+------------------------+--------------------------+
=A0=A0 | 4=A0 | Uniform probabilistic=A0 | =
samplingProbability=A0=A0=A0=A0=A0 |
=A0=A0 =
|=A0=A0=A0 | Sampling =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|
=A0=A0 =
+----+------------------------+--------------------------+
=A0=A0 | 5=A0 | Property Match=A0=A0=A0=A0=A0=A0=A0=A0 | =
Information Element=A0=A0=A0=A0=A0 |
=A0=A0 =
|=A0=A0=A0 | Filtering=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Value =
Range=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|
=A0=A0 =
+----+------------------------+--------------------------+
=A0=A0 |=A0=A0 Hash-based Filtering=A0=A0=A0=A0=A0 | =
hashInitialiserValue=A0=A0=A0=A0 |
=A0=A0 =
+----+------------------------+ =
hashFlowDomain=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|
=A0=A0 | 6=A0 | using =
BOB=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =
hashSelectedRangeMin=A0=A0=A0=A0 |
=A0=A0 =
+----+------------------------+ hashSelectedRangeMax=A0=A0=A0=A0 =
|
=A0=A0 | 7=A0 | using =
IPSX=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =
hashOutputRangeMin=A0=A0=A0=A0=A0=A0 |
=A0=A0 =
+----+------------------------+ hashOutputRangeMax=A0=A0=A0=A0=A0=A0 =
|
=A0=A0 | 8=A0 | using =
CRC=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 |
=A0=A0 =
+----+------------------------+--------------------------+
=A0=A0 | 9=A0 | Flow-state Dependent=A0=A0 | No agreed =
Parameters=A0=A0=A0=A0 |
=A0=A0 |=A0=A0=A0 | Flow =
Selection=A0=A0=A0=A0=A0=A0=A0=A0 =
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 |
=A0=A0 =
+----+------------------------+--------------------------+
 
Also, in this table above, you need =
"TBDx" instead of 9
 
Ok.
 



- I see "Flow =
Selection", but
this term is not defined.







I will replace =
“Flow Selection”
with “Intermediate Flow Selection Process”. =






Thanks.





Regards, Benoit.



 



 



Thanks a =
lot.



 



Kind =
regards,



 



Salvatore















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

 

Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.2221 / Database dei virus: 2441/5364 - Data di = rilascio: 30/10/2012

------=_NextPart_000_0074_01CDBB6F.2751D210-- From muenz@net.in.tum.de Mon Nov 5 11:58:33 2012 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 C5BF421F845A for ; Mon, 5 Nov 2012 11:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 yX3RNrMrC4qg for ; Mon, 5 Nov 2012 11:58:33 -0800 (PST) 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 2B69321F8459 for ; Mon, 5 Nov 2012 11:58:32 -0800 (PST) Received: from [192.168.2.36] (g229138014.adsl.alicedsl.de [92.229.138.14]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 2EDC218EB88D; Mon, 5 Nov 2012 20:58:29 +0100 (CET) Message-ID: <50981A52.2050104@net.in.tum.de> Date: Mon, 05 Nov 2012 20:58:10 +0100 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Brian Trammell References: <506CBFE3.10607@auckland.ac.nz> <5090547C.5020803@cisco.com> <5091271E.3050206@cisco.com> <68907E1B-1D38-4F3A-B0E0-F47628F989F0@tik.ee.ethz.ch> <50913BF3.2080408@cisco.com> <8ED0D683-536C-46B6-8E5A-3CC3B7CB678F@tik.ee.ethz.ch> <5091422B.9070607@cisco.com> <48C58B9E-EE52-415D-896F-AA15F8B7A6C4@tik.ee.ethz.ch> <5092AE87.6040400@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nevil Brownlee , IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5102bis-05.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: Mon, 05 Nov 2012 19:58:33 -0000 Hi Paul, Brian, >> So, how about "A delta counter only counts observations made since the previous Flow Record (if any) for a given Flow." This statement seems sufficiently clear and sufficiently flexible. For example, as I understand it, it does not imply that all observations since the previous Flow Record must be counted. Some observations might get lost or omitted on purpose. Also, at some time, the next interval will end, so the following observations are not counted. Also, it does not imply that the Flow Record is actually exported. Regards, Gerhard From trammell@tik.ee.ethz.ch Mon Nov 5 14:19:44 2012 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 A88EB21F883E for ; Mon, 5 Nov 2012 14:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 BnkQTfqr2a5I for ; Mon, 5 Nov 2012 14:19:43 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBEB21F878C for ; Mon, 5 Nov 2012 14:19:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1E495D9312 for ; Mon, 5 Nov 2012 23:19:42 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xWBJQvcCYjrm for ; Mon, 5 Nov 2012 23:19:41 +0100 (MET) Received: from dhcp-549e.meeting.ietf.org (dhcp-549e.meeting.ietf.org [130.129.84.158]) (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 64FAED9310 for ; Mon, 5 Nov 2012 23:19:41 +0100 (MET) From: Brian Trammell Content-Type: multipart/alternative; boundary="Apple-Mail=_C3F387C0-9F06-4189-A9A1-DFA836D28673" Date: Mon, 5 Nov 2012 17:19:37 -0500 References: <20121105214030.30141.33617.idtracker@ietfa.amsl.com> To: IETF IPFIX Working Group Message-Id: <10807304-FB23-4C58-B97A-75C868DBFE4E@tik.ee.ethz.ch> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-text-adt-00.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: Mon, 05 Nov 2012 22:19:44 -0000 --Apple-Mail=_C3F387C0-9F06-4189-A9A1-DFA836D28673 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, Following an initial question raised some time ago in the ALTO working = group, I've submitted a (very initial) draft defining text bindings for = IPFIX abstract data types. The idea is to allow usage of the IPFIX = Information Model with textual data representations and protocols. This = revision is very much a work in progress, as I wanted to elicit feedback = from the working group with respect to the general approach before = polishing the content that's there. If you have interest in this sort of thing, please come find me in the = hallway in Atlanta, or drop me a line. (As I've just submitted this = document, it won't be on the agenda on Thursday.) Many thanks, best regards, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-trammell-ipfix-text-adt-00.txt > Date: 5 November 2012 16:40:30 EST > To: trammell@tik.ee.ethz.ch >=20 >=20 > A new version of I-D, draft-trammell-ipfix-text-adt-00.txt > has been successfully submitted by Brian Trammell and posted to the > IETF repository. >=20 > Filename: draft-trammell-ipfix-text-adt > Revision: 00 > Title: Textual Representation of IPFIX Abstract Data = Types > Creation date: 2012-11-05 > WG ID: Individual Submission > Number of pages: 10 > URL: = http://www.ietf.org/internet-drafts/draft-trammell-ipfix-text-adt-00.txt > Status: = http://datatracker.ietf.org/doc/draft-trammell-ipfix-text-adt > Htmlized: = http://tools.ietf.org/html/draft-trammell-ipfix-text-adt-00 >=20 >=20 > Abstract: > This document defines UTF-8 representations for IPFIX abstract data > types, to support interoperable usage of the IPFIX Information > Elements with protocols based on textual encodings. >=20 >=20 >=20 >=20 > The IETF Secretariat --Apple-Mail=_C3F387C0-9F06-4189-A9A1-DFA836D28673 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Subject: New Version Notification for = draft-trammell-ipfix-text-adt-00.txt
Date: 5 November 2012 = 16:40:30 EST


A new version of I-D, = draft-trammell-ipfix-text-adt-00.txt
has been successfully submitted = by Brian Trammell and posted to the
IETF = repository.

Filename: = draft-trammell-ipfix-text-adt
Revision: 00
Title: Textual = Representation of IPFIX Abstract Data Types
Creation date: = 2012-11-05
WG ID: Individual Submission
Number = of pages: 10
URL: =             http://www.ietf.org/internet-drafts/draft-trammell-ipfix-text-adt-= 00.txt
Status: =          htt= p://datatracker.ietf.org/doc/draft-trammell-ipfix-text-adt
Htmlized= :        http:= //tools.ietf.org/html/draft-trammell-ipfix-text-adt-00


Abst= ract:
  This document defines UTF-8 representations for = IPFIX abstract data
  types, to support interoperable = usage of the IPFIX Information
  Elements with protocols = based on textual encodings.




The IETF = Secretariat

= --Apple-Mail=_C3F387C0-9F06-4189-A9A1-DFA836D28673-- From n.brownlee@auckland.ac.nz Tue Nov 6 08:27:15 2012 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 CD8B221F893C for ; Tue, 6 Nov 2012 08:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 2EL6PPbrIXpX for ; Tue, 6 Nov 2012 08:27:15 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id D659F21F892C for ; Tue, 6 Nov 2012 08:27:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1352219235; x=1383755235; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=pG8KwX0hpno31bV72xrO8tWjGF4YZDRm38WXb9ADuBM=; b=HT9ej8QNsXpS/4Ny3dIIRq0ZKGfmXIL9OwJWUuGxecaq33zddRFSJjvj rUW8Xrn2tDM9kODU38uqTQpr/6eZ1lhfDTT+lKrI5JZrcYXXB/ng9oXI6 D4WKmtMnzApsi38d5aHhXmXnl5MYiDZB689obnRdAbvj9Nf+kAO9vvl9z E=; X-IronPort-AV: E=Sophos;i="4.80,723,1344168000"; d="scan'208";a="155386575" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.20.231 - Outgoing - Outgoing-SSL Received: from dhcp-14e7.meeting.ietf.org (HELO [130.129.20.231]) ([130.129.20.231]) by mx2-int.auckland.ac.nz with ESMTP; 07 Nov 2012 05:27:13 +1300 Message-ID: <50993A5E.2090805@auckland.ac.nz> Date: Wed, 07 Nov 2012 05:27:10 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Slides for Wednesday's meeting 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, 06 Nov 2012 16:27:15 -0000 Hi draft authors: We need to get the slides for Wednesday's meeting onto the Meeting Materials page in plenty of time - the Meetecho folk need to copy them into their system well before the actual meeting. Please send your slides to me and to Juergen. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From andrewf@plixer.com Tue Nov 6 08:29:11 2012 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 0C6F721F8B22 for ; Tue, 6 Nov 2012 08:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[AWL=1.002, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 NzEhw5tMM0kp for ; Tue, 6 Nov 2012 08:29:10 -0800 (PST) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id D15CF21F8A77 for ; Tue, 6 Nov 2012 08:29:09 -0800 (PST) Received: from [10.100.1.132] ([10.100.1.132]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Nov 2012 11:29:08 -0500 Message-ID: <50993AD3.5040909@plixer.com> Date: Tue, 06 Nov 2012 11:29:07 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/19.0 Thunderbird/19.0a1 MIME-Version: 1.0 To: Nevil Brownlee References: <50993A5E.2090805@auckland.ac.nz> In-Reply-To: <50993A5E.2090805@auckland.ac.nz> Content-Type: multipart/alternative; boundary="------------000306070909070700050607" X-OriginalArrivalTime: 06 Nov 2012 16:29:08.0773 (UTC) FILETIME=[D8AA1550:01CDBC3B] Cc: IPFIX Working Group Subject: Re: [IPFIX] Slides for Wednesday's meeting 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, 06 Nov 2012 16:29:11 -0000 This is a multi-part message in MIME format. --------------000306070909070700050607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Wednesday? https://datatracker.ietf.org/meeting/85/agenda.html Says THURSDAY, November 8, 2012/ -Andrew On 11/06/2012 11:27 AM, Nevil Brownlee wrote: > > Hi draft authors: > > We need to get the slides for Wednesday's meeting onto the Meeting > Materials page in plenty of time - the Meetecho folk need to copy > them into their system well before the actual meeting. > > Please send your slides to me and to Juergen. > > Cheers, Nevil > --------------000306070909070700050607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Wednesday?

https://datatracker.ietf.org/meeting/85/agenda.html

Says THURSDAY, November 8, 2012/

-Andrew


On 11/06/2012 11:27 AM, Nevil Brownlee wrote:

Hi draft authors:

We need to get the slides for Wednesday's meeting onto the Meeting
Materials page in plenty of time - the Meetecho folk need to copy
them into their system well before the actual meeting.

Please send your slides to me and to Juergen.

Cheers, Nevil


--------------000306070909070700050607-- From n.brownlee@auckland.ac.nz Tue Nov 6 10:16:30 2012 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 19BD021F8A14 for ; Tue, 6 Nov 2012 10:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 tyHrder32xnp for ; Tue, 6 Nov 2012 10:16:29 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9295A21F89FF for ; Tue, 6 Nov 2012 10:16:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1352225789; x=1383761789; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dep/c0O/krdbpMGImkaUKJeC2x1YroQP0IZkYWGE27Y=; b=cTNOeZYA6IUByobSjNLeNLGtqa0GN8iaWPiVkOnHtuLhewgjCFG3gJyF lcqqz/9RWcT2x8RASqqmXtibD+37WTPrrbP1+4dROuHlw3rxZJ48JbcEc 0T7Mk3KEV/H04+WCfzF0xRqskSZ9vg/0R4XAtPyueIsbbLhGoDc361lkz M=; X-IronPort-AV: E=Sophos;i="4.80,723,1344168000"; d="scan'208";a="155393084" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.20.231 - Outgoing - Outgoing-SSL Received: from dhcp-14e7.meeting.ietf.org (HELO [130.129.20.231]) ([130.129.20.231]) by mx2-int.auckland.ac.nz with ESMTP; 07 Nov 2012 07:16:26 +1300 Message-ID: <509953F7.3070804@auckland.ac.nz> Date: Wed, 07 Nov 2012 07:16:23 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Andrew Feren References: <50993A5E.2090805@auckland.ac.nz> <50993AD3.5040909@plixer.com> In-Reply-To: <50993AD3.5040909@plixer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] Slides for **Thursday's** meeting 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, 06 Nov 2012 18:16:30 -0000 Hi Andrew: Oops, I should have saihursday, sorry to be confusing. Thanks, Nevil On 07/11/12 05:29, Andrew Feren wrote: > Wednesday? > > https://datatracker.ietf.org/meeting/85/agenda.html > > Says THURSDAY, November 8, 2012/ > > -Andrew > > > On 11/06/2012 11:27 AM, Nevil Brownlee wrote: >> >> Hi draft authors: >> >> We need to get the slides for Wednesday's meeting onto the Meeting >> Materials page in plenty of time - the Meetecho folk need to copy >> them into their system well before the actual meeting. >> >> Please send your slides to me and to Juergen. >> >> Cheers, Nevil >> > -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From bclaise@cisco.com Tue Nov 6 13:19:32 2012 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 5A38621F89AD for ; Tue, 6 Nov 2012 13:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.49 X-Spam-Level: X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 Ss6cvfYKvCau for ; Tue, 6 Nov 2012 13:19:32 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id B2E3C21F899B for ; Tue, 6 Nov 2012 13:19:31 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA6LJPJ7020380; Tue, 6 Nov 2012 16:19:27 -0500 (EST) Received: from [10.82.209.54] (rtp-vpn4-310.cisco.com [10.82.209.54]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA6LJNSc028872; Tue, 6 Nov 2012 16:19:23 -0500 (EST) Message-ID: <50997EDC.9040105@cisco.com> Date: Tue, 06 Nov 2012 16:19:24 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "radext-chairs@tools.ietf.org" , Alan DeKok Subject: [IPFIX] IPFIX in RADIUS accounting 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, 06 Nov 2012 21:19:32 -0000 Dear all, Some interesting use of IPFIX in RADIUS accounting https://datatracker.ietf.org/doc/draft-dekok-radius-ipfix/ http://www.ietf.org/proceedings/85/slides/slides-85-radext-1.ppt Regards, Benoit From bclaise@cisco.com Wed Nov 7 10:24:38 2012 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 A400621F8B0D for ; Wed, 7 Nov 2012 10:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.483 X-Spam-Level: X-Spam-Status: No, score=-10.483 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 CvDIUOgTtdsf for ; Wed, 7 Nov 2012 10:24:34 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id AA04921F8853 for ; Wed, 7 Nov 2012 10:24:05 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA7IO5vX017526 for ; Wed, 7 Nov 2012 13:24:05 -0500 (EST) Received: from [10.82.212.55] (rtp-vpn4-1079.cisco.com [10.82.212.55]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA7IO4d2006122 for ; Wed, 7 Nov 2012 13:24:04 -0500 (EST) Message-ID: <509AA744.5090401@cisco.com> Date: Wed, 07 Nov 2012 13:24:04 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <20121106214623.41943B1E011@rfc-editor.org> In-Reply-To: <20121106214623.41943B1E011@rfc-editor.org> X-Forwarded-Message-Id: <20121106214623.41943B1E011@rfc-editor.org> Content-Type: multipart/mixed; boundary="------------030802080009040002020206" Subject: [IPFIX] Fwd: RFC 6759 on Cisco Systems Export of Application Information in IP Flow Information Export (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: Wed, 07 Nov 2012 18:24:38 -0000 This is a multi-part message in MIME format. --------------030802080009040002020206 Content-Type: multipart/alternative; boundary="------------040706070404000206080704" --------------040706070404000206080704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI. Regards, Benoit -------- Original Message -------- Subject: RFC 6759 on Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX) Date: Tue, 6 Nov 2012 13:46:23 -0800 (PST) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 6759 Title: Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX) Author: B. Claise, P. Aitken, N. Ben-Dvora Status: Informational Stream: IETF Date: November 2012 Mailbox: bclaise@cisco.com, paitken@cisco.com, nirbd@cisco.com Pages: 43 Characters: 83584 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-claise-export-application-info-in-ipfix-10.txt URL: http://www.rfc-editor.org/rfc/rfc6759.txt This document specifies a Cisco Systems extension to the IPFIX information model specified in RFC 5102 to export application information. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC --------------040706070404000206080704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI.

Regards, Benoit


-------- Original Message --------
Subject: RFC 6759 on Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)
Date: Tue, 6 Nov 2012 13:46:23 -0800 (PST)
From: rfc-editor@rfc-editor.org
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
CC: rfc-editor@rfc-editor.org 


A new Request for Comments is now available in online RFC libraries.

        
        RFC 6759

        Title:      Cisco Systems Export of Application 
                    Information in IP Flow Information Export 
                    (IPFIX) 
        Author:     B. Claise, P. Aitken,
                    N. Ben-Dvora
        Status:     Informational
        Stream:     IETF
        Date:       November 2012
        Mailbox:    bclaise@cisco.com, 
                    paitken@cisco.com, 
                    nirbd@cisco.com
        Pages:      43
        Characters: 83584
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-claise-export-application-info-in-ipfix-10.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6759.txt

This document specifies a Cisco Systems extension to the
IPFIX information model specified in RFC 5102 to export
application information.  This document is not an Internet 
Standards Track specification; it is published for 
informational purposes.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



--------------040706070404000206080704-- --------------030802080009040002020206 Content-Type: text/plain; charset=windows-1252; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" --------------030802080009040002020206-- From bclaise@cisco.com Thu Nov 8 07:14:55 2012 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 E329F21F8B16 for ; Thu, 8 Nov 2012 07:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.518 X-Spam-Level: X-Spam-Status: No, score=-10.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 frtfX+bIgeFw for ; Thu, 8 Nov 2012 07:14:51 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 970C621F88F8 for ; Thu, 8 Nov 2012 07:14:51 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA8FEoHM014148; Thu, 8 Nov 2012 10:14:50 -0500 (EST) Received: from [10.82.236.201] (rtp-vpn5-1221.cisco.com [10.82.236.201]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA8FEnJI017422; Thu, 8 Nov 2012 10:14:49 -0500 (EST) Message-ID: <509BCC69.6020603@cisco.com> Date: Thu, 08 Nov 2012 10:14:49 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Salvatore D'Antonio" References: <4FC74398.50805@cisco.com> <4FC89B99.40107@cisco.com> <506DA106.5060705@cisco.com> <50904E1D.7060909@cisco.com> <007301cdbb66$c58d6a10$50a83e30$@dantonio@uniparthenope.it> In-Reply-To: <007301cdbb66$c58d6a10$50a83e30$@dantonio@uniparthenope.it> Content-Type: multipart/alternative; boundary="------------020107030601030401000303" Cc: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org, ipfix@ietf.org, ipfix-chairs@tools.ietf.org Subject: Re: [IPFIX] R: New AD review of draft-ietf-ipfix-flow-selection-tech-10.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, 08 Nov 2012 15:14:56 -0000 This is a multi-part message in MIME format. --------------020107030601030401000303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear Salvatore, I removed the comments on which we agree, for clarity. > > Dear Benoit, > > My comments to your comments inline. > > *Da:*Benoit Claise [mailto:bclaise@cisco.com] > *Inviato:* martedì 30 ottobre 2012 23:01 > *A:* ipfix@ietf.org; draft-ietf-ipfix-flow-selection-tech@tools.ietf.org > *Cc:* ipfix-chairs@tools.ietf.org > *Oggetto:* Re: [IPFIX] New AD review of > draft-ietf-ipfix-flow-selection-tech-10.txt > > > > Intermediate Flow Selection Process: an Intermediate Process as in > > [RFC6183 ] that ... > > > > The new definition improved a lot: > > * Intermediate Flow Selection Process > > > > An Intermediate Flow Selection Process takes Flow Records as its > > input and selects a subset of this set as its output. > > Intermediate Flow Selection Process is a more general concept than > > Intermediate Selection Process as defined in [RFC6183 ]. While an > > Intermediate Selection Process selects Flow Records from a > > sequence based upon criteria-evaluated Flow record values and > > passes only those Flow Records that match the criteria, an > > Intermediate Flow Selection Process selects Flow Records using > > selection criteria applicable to a larger set of Flow > > characteristics and information. > > But is there a reason why this definition can't be based on > "intermediate Process" from RFC 6183: > > Intermediate Process > > > > An Intermediate Process takes a record stream as its input from > > Collecting Processes, Metering Processes, IPFIX File Readers, > > other Intermediate Processes, or other record sources; performs > > some transformations on this stream based upon the content of each > > record, states maintained across multiple records, or other data > > sources; and passes the transformed record stream as its output to > > Exporting Processes, IPFIX File Writers, or other Intermediate > > Processes in order to perform IPFIX Mediation. Typically, an > > Intermediate Process is hosted by an IPFIX Mediator. > > Alternatively, an Intermediate Process may be hosted by an > > Original Exporter. > > > > According to the definition of "Intermediate Process" from RFC 6183, such a process is typically hosted by an IPFIX Mediator. Alternatively, it may be hosted by an Original Exporter. In my view, an Intermediate Flow Selection Process could be also hosted by a Collector. > Sure. Then the Collector becomes a Collector that contains a mediator function. I don't see the problem. Intermediate Process An Intermediate Process takes a record stream as its input from _Collecting Processes_, Metering Processes, IPFIX File Readers, other Intermediate Processes, My concern if you use your definition is that it doesn't build on the framework RFC 6183 > > > > So > > * Intermediate Flow Selection Process > > > > _ An Intermediate Flow Selection Process is an Intermediate Process as in_ > > _ [_RFC6183 _] that_ takes Flow Records as its > > input and selects a subset of this set as its output. > > Intermediate Flow Selection Process is a more general concept than > > Intermediate Selection Process as defined in [RFC6183 ]. While an > > Intermediate Selection Process selects Flow Records from a > > sequence based upon criteria-evaluated Flow record values and > > passes only those Flow Records that match the criteria, an > > Intermediate Flow Selection Process selects Flow Records using > > selection criteria applicable to a larger set of Flow > > characteristics and information. > > > > > > 4. Flow selection as a Function in the IPFIX Architecture > > Thanks for your new figure 1. > One editorial change: change the + in the left vertical line. > > Ok, will do. > > +======|========================+ | > > | | Mediator | | > > + +-V-------------------+ | | > > | | Collecting Process | | | > > + +---------------------+ | | > > | | Intermediate Flow | | | > > | | Selection Process | | | > > + +---------------------+ | | > > | | Exporting Process | | | > > + +-|-------------------+ | | > > +======|========================+ | > > > > > 5.1. Flow Filtering > > Flow Filtering is a deterministic function on the IPFIX > Flow Record > content. If the relevant flow characteristics are > already observable > at packet level (e.g. Flow Keys), Flow Filtering can > be applied > before aggregation at packet level. In order to be > compliant with > this document, at least the Property Match Filtering > MUST be > implemented. > > This contradicts. > > In order to be compliant with this document, at > > least one of the flow selection schemes MUST be implemented. > > Actually, wrong cut/paste. > This contradicts, in section 1: > > In order to be compliant with this document, at > > least the Property Match Filtering MUST be implemented. > > This comment is not clear to me. Both in Section 1 and in Section > 5.1 (Flow Filtering) I used the same sentence "In order to be > compliant with this document, at least the Property Match > Filtering MUST be implemented". > > > Solved with version 12. However, I'm wondering if the resolution is correct. version 11: In order to be compliant with this document, at least one of the flow selection schemes MUST be implemented. ... In order to be compliant with this document, at least the Property Match Filtering MUST be implemented. Version 12: In order to be compliant with this document, at least the Property Match Filtering MUST be implemented. Listing all the selection techniques, 5 . Flow Selection Techniques . . . . . . . . . . . . . . . . . .10 5.1 . Flow Filtering . . . . . . . . . . . . . . . . . . . . . .11 5.1.1 . Property Match Filtering . . . . . . . . . . . . . . .11 5.1.2 . Hash-based 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 Flow Selection . . . . . . . . . . .13 5.4 . Flow-state Dependent Packet Selection . . . . . . . . . .14 It means that a device that implements Flow Sampling was compliant with version 11 thanks to the sentence "In order to be compliant with this document, at least one of the flow selection schemes MUST be implemented" and is not compliant any longer with version 12 It seems like an important change to me since the WGLC, on which the WG must agree. Regards, Benoit > > > > > --------------020107030601030401000303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear Salvatore,

I removed the comments on which we agree, for clarity.

Dear Benoit,

 

My comments to your comments inline.

 

Da: Benoit Claise [mailto:bclaise@cisco.com]
Inviato: martedì 30 ottobre 2012 23:01
A: ipfix@ietf.org; draft-ietf-ipfix-flow-selection-tech@tools.ietf.org
Cc: ipfix-chairs@tools.ietf.org
Oggetto: Re: [IPFIX] New AD review of draft-ietf-ipfix-flow-selection-tech-10.txt

 



Intermediate Flow Selection Process: an Intermediate Process as in
      [RFC6183] that ...
 

 

The new definition improved a lot:

 * Intermediate Flow Selection Process
 
      An Intermediate Flow Selection Process takes Flow Records as its
      input and selects a subset of this set as its output.
      Intermediate Flow Selection Process is a more general concept than
      Intermediate Selection Process as defined in [RFC6183].  While an
      Intermediate Selection Process selects Flow Records from a
      sequence based upon criteria-evaluated Flow record values and
      passes only those Flow Records that match the criteria, an
      Intermediate Flow Selection Process selects Flow Records using
      selection criteria applicable to a larger set of Flow
      characteristics and information.

But is there a reason why this definition can't be based on "intermediate Process" from RFC 6183:

Intermediate Process
 
      An Intermediate Process takes a record stream as its input from
      Collecting Processes, Metering Processes, IPFIX File Readers,
      other Intermediate Processes, or other record sources; performs
      some transformations on this stream based upon the content of each
      record, states maintained across multiple records, or other data
      sources; and passes the transformed record stream as its output to
      Exporting Processes, IPFIX File Writers, or other Intermediate
      Processes in order to perform IPFIX Mediation.  Typically, an
      Intermediate Process is hosted by an IPFIX Mediator.
      Alternatively, an Intermediate Process may be hosted by an
      Original Exporter.
 
According to the definition of “Intermediate Process” from RFC 6183, such a process is typically hosted by an IPFIX Mediator. Alternatively, it may be hosted by an Original Exporter. In my view, an Intermediate Flow Selection Process could be also hosted by a Collector.
Sure. Then the Collector becomes a Collector that contains a mediator function.
I don't see the problem.
   Intermediate Process

      An Intermediate Process takes a record stream as its input from
      Collecting Processes, Metering Processes, IPFIX File Readers,
      other Intermediate Processes,

My concern if you use your definition is that it doesn't build on the framework RFC 6183
 

So 

 * Intermediate Flow Selection Process
 
      An Intermediate Flow Selection Process is an Intermediate Process as in
      [RFC6183] that takes Flow Records as its
      input and selects a subset of this set as its output.
      Intermediate Flow Selection Process is a more general concept than
      Intermediate Selection Process as defined in [RFC6183].  While an
      Intermediate Selection Process selects Flow Records from a
      sequence based upon criteria-evaluated Flow record values and
      passes only those Flow Records that match the criteria, an
      Intermediate Flow Selection Process selects Flow Records using
      selection criteria applicable to a larger set of Flow
      characteristics and information.






4.  Flow selection as a Function in the IPFIX Architecture
  

Thanks for your new figure 1.
One editorial change: change the + in the left vertical line.

Ok, will do.

      +======|========================+      |
      |      |  Mediator              |      |
      +    +-V-------------------+    |      |
      |    | Collecting Process  |    |      |
      +    +---------------------+    |      |
      |    | Intermediate Flow   |    |      |
      |    | Selection Process   |    |      |
      +    +---------------------+    |      |
      |    |  Exporting Process  |    |      |
      +    +-|-------------------+    |      |
      +======|========================+      |
     


5.1.  Flow Filtering

   Flow Filtering is a deterministic function on the IPFIX Flow Record
   content.  If the relevant flow characteristics are already observable
   at packet level (e.g.  Flow Keys), Flow Filtering can be applied
   before aggregation at packet level.  In order to be compliant with
   this document, at least the Property Match Filtering MUST be
   implemented.

This contradicts.

   In order to be compliant with this document, at
   least one of the flow selection schemes MUST be implemented.

Actually, wrong cut/paste.
This contradicts, in section 1:

   In order to be compliant with this document, at
   least the Property Match Filtering MUST be implemented.

 

This comment is not clear to me. Both in Section 1 and in Section 5.1 (Flow Filtering) I used the same sentence “In order to be compliant with this document, at least the Property Match Filtering MUST be implemented”.



Solved with version 12.
However, I'm wondering if the resolution is correct.
version 11:
       
   In order to be compliant with this document, at
   least one of the flow selection schemes MUST be implemented. 
 
   ...


   In order to be compliant with this document, at
   least the Property Match Filtering MUST be implemented.

Version 12:
    In order to be compliant with this document, at
   least the Property Match Filtering MUST be implemented.

Listing all the selection techniques, 
   5.  Flow Selection Techniques  . . . . . . . . . . . . . . . . . . 10
     5.1.  Flow Filtering . . . . . . . . . . . . . . . . . . . . . . 11
       5.1.1.  Property Match Filtering . . . . . . . . . . . . . . . 11
       5.1.2.  Hash-based 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 Flow Selection  . . . . . . . . . . . 13
     5.4.  Flow-state Dependent Packet Selection  . . . . . . . . . . 14

It means that a device that implements Flow Sampling was compliant with version 11 thanks to the sentence "In order to be compliant with this document, at least one of the flow selection schemes MUST be implemented" and is not compliant any longer with version 12
It seems like an important change to me since the WGLC, on which the WG must agree.

Regards, Benoit






--------------020107030601030401000303-- From bclaise@cisco.com Thu Nov 8 07:49:24 2012 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 3E5DB21F8839 for ; Thu, 8 Nov 2012 07:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.525 X-Spam-Level: X-Spam-Status: No, score=-10.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 AG03xPKlLx1F for ; Thu, 8 Nov 2012 07:49:23 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id A2F3521F880A for ; Thu, 8 Nov 2012 07:49:23 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA8FnHkB017863; Thu, 8 Nov 2012 10:49:17 -0500 (EST) Received: from [10.82.236.201] (rtp-vpn5-1221.cisco.com [10.82.236.201]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA8FnF5m005293; Thu, 8 Nov 2012 10:49:15 -0500 (EST) Message-ID: <509BD47B.5060401@cisco.com> Date: Thu, 08 Nov 2012 10:49:15 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Paul Aitken References: <506CBFE3.10607@auckland.ac.nz> <5090547C.5020803@cisco.com> <5091271E.3050206@cisco.com> In-Reply-To: <5091271E.3050206@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nevil Brownlee , IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5102bis-05.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, 08 Nov 2012 15:49:24 -0000 Paul, Brian > >>> >>>> 1.1. Changes since RFC 5102 >>>> >>>> This document obsoletes the Proposed Standard revision of the >>>> IPFIX >>>> Protocol Specification [RFC5102]. The following changes have been >>>> made to this document with respect to the previous document: >>>> >>>> - All outstanding technical and editorial errata filed on the >>>> [RFC5102] as of publication time have been corrected >>>> - All references into [RFC5101] have been updated to >>>> [RFC5101bis], >>>> reflecting changes in that document as necessary >>>> - Information element definitions have been removed, as the >>>> reference for these is now [IPFIX-IANA]; categorizations of >>>> information elements as defines in [RFC5102] have been retained in >>>> section 5. >>>> - The process for modifying [IPFIX-IANA] has been improved, >>>> and is >>>> now described in [IPFIX-IE-DOCTORS]; Section 6 has been updated >>>> accordingly, and a new section 7.3 gives IANA considerations >>>> for this >>>> process. >>>> - Definitions of timestamp data types have been clarified >>>> - Appendices A and B have been removed >>> BTW, the indentation of that section makes it difficult to read. Can >>> you get all the text - including the wrapped lines - to the right of >>> the bullets? >> I'm not an nroff hacker. Any pointers? > > Personally, I had to hack rfc2xml to make it do what I wanted. > > >> It's also not clear that this section should survive IESG processing >> / RFC editor processing. > > Since this doc obsoletes 5102, I find it useful to get a high level > overview of what was changed, and for that overview to be given early > in the document. We should keep this section. This is much appreciated during the IESG review, and for historical reasons. Regards, Benoit From bclaise@cisco.com Thu Nov 8 07:56:50 2012 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 85ED721F8B0C for ; Thu, 8 Nov 2012 07:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.528 X-Spam-Level: X-Spam-Status: No, score=-10.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 kW4wu0zOuETu for ; Thu, 8 Nov 2012 07:56:48 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 3A24C21F8839 for ; Thu, 8 Nov 2012 07:56:43 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA8FuVLw018665; Thu, 8 Nov 2012 10:56:31 -0500 (EST) Received: from [10.82.236.201] (rtp-vpn5-1221.cisco.com [10.82.236.201]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA8FuUVk015240; Thu, 8 Nov 2012 10:56:30 -0500 (EST) Message-ID: <509BD62E.8070309@cisco.com> Date: Thu, 08 Nov 2012 10:56:30 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Brian Trammell References: <506CBFE3.10607@auckland.ac.nz> <5090547C.5020803@cisco.com> <5091271E.3050206@cisco.com> <68907E1B-1D38-4F3A-B0E0-F47628F989F0@tik.ee.ethz.ch> <50913BF3.2080408@cisco.com> <8ED0D683-536C-46B6-8E5A-3CC3B7CB678F@tik.ee.ethz.ch> In-Reply-To: <8ED0D683-536C-46B6-8E5A-3CC3B7CB678F@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nevil Brownlee , IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5102bis-05.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, 08 Nov 2012 15:56:50 -0000 On 31/10/2012 10:58, Brian Trammell wrote: > Hi, Paul, > > On 31 Oct 2012, at 15:55 , Paul Aitken wrote: > >> How about: >>> >>> A delta counter counts only observations made since the last export of a Flow Record for a given Flow. >> That's back to my point that the observation might not be exported. >> >> More to the point, delta/total counting is a function of the MP. Whether the MP hands data to the EP, and what the EP does or does not do with that data, should have no bearing on how the MP meters subsequent data. So the definition should be purely in MP terms ("last export" being an EP term). > What verb does the MP apply to a unit of information when it gives it to the EP? I've been using "expire" Regards, Benoit (as a contributor) > > A delta counter counts only observations made since the last Flow Record for a given Flow was measured. > > Or maybe we can sidestep the action completely: > > A delta counter counts only observations made since the previous Flow Record for a given Flow. > > Cheers, > > Brian > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > > From bclaise@cisco.com Thu Nov 8 07:58:49 2012 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 AA16B21F87E6 for ; Thu, 8 Nov 2012 07:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.531 X-Spam-Level: X-Spam-Status: No, score=-10.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 khjkokPIc4Mm for ; Thu, 8 Nov 2012 07:58:49 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 4744C21F87E5 for ; Thu, 8 Nov 2012 07:58:48 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA8FwhsH018902; Thu, 8 Nov 2012 10:58:44 -0500 (EST) Received: from [10.82.236.201] (rtp-vpn5-1221.cisco.com [10.82.236.201]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA8Fwhci018873; Thu, 8 Nov 2012 10:58:43 -0500 (EST) Message-ID: <509BD6B3.3030700@cisco.com> Date: Thu, 08 Nov 2012 10:58:43 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Gerhard Muenz References: <506CBFE3.10607@auckland.ac.nz> <5090547C.5020803@cisco.com> <5091271E.3050206@cisco.com> <68907E1B-1D38-4F3A-B0E0-F47628F989F0@tik.ee.ethz.ch> <50913BF3.2080408@cisco.com> <8ED0D683-536C-46B6-8E5A-3CC3B7CB678F@tik.ee.ethz.ch> <5091422B.9070607@cisco.com> <48C58B9E-EE52-415D-896F-AA15F8B7A6C4@tik.ee.ethz.ch> <5092AE87.6040400@cisco.com> <50981A52.2050104@net.in.tum.de> In-Reply-To: <50981A52.2050104@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nevil Brownlee , IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5102bis-05.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, 08 Nov 2012 15:58:49 -0000 On 5/11/2012 14:58, Gerhard Muenz wrote: > > Hi Paul, Brian, > >>> So, how about "A delta counter only counts observations made since >>> the previous Flow Record (if any) for a given Flow." > > This statement seems sufficiently clear and sufficiently flexible. That works for me Regards, Benoit (as a contributor) > For example, as I understand it, it does not imply that all > observations since the previous Flow Record must be counted. Some > observations might get lost or omitted on purpose. Also, at some time, > the next interval will end, so the following observations are not > counted. Also, it does not imply that the Flow Record is actually > exported. > > Regards, > Gerhard > > > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > > From paitken@cisco.com Thu Nov 8 08:29:53 2012 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 A249F21F8433 for ; Thu, 8 Nov 2012 08:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.541 X-Spam-Level: X-Spam-Status: No, score=-10.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 pnNrJHSN3+Bo for ; Thu, 8 Nov 2012 08:29:53 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id EB92F21F8450 for ; Thu, 8 Nov 2012 08:29:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=496; q=dns/txt; s=iport; t=1352392193; x=1353601793; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=FyuMs3yyPOiOb3Mm+rzjEEKfvvzefTeoHDTdf9p5HFE=; b=Nb5Fn8ibTYhUCh3d8NMpDpQh8dYxrmVdZzwthFLP5agHoIFrRlU9uD8B HG33nwinME1m8UnnyH2Ge/CPtS8fmLeNAKBEsw+ESOuf1F/9b9Q8Ibfld MqUhXWXat2213+8K/aFyDWTYYvjoCDW6WXTf4IJQ8RoVp0ziPpv7/Y6aU M=; X-IronPort-AV: E=Sophos;i="4.80,738,1344211200"; d="scan'208";a="146465058" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2012 16:29:52 +0000 Received: from [10.55.89.121] (dhcp-10-55-89-121.cisco.com [10.55.89.121]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA8GTpMV027280; Thu, 8 Nov 2012 16:29:51 GMT Message-ID: <509BDE01.9040709@cisco.com> Date: Thu, 08 Nov 2012 16:29:53 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Benoit Claise References: <506CBFE3.10607@auckland.ac.nz> <5090547C.5020803@cisco.com> <5091271E.3050206@cisco.com> <68907E1B-1D38-4F3A-B0E0-F47628F989F0@tik.ee.ethz.ch> <50913BF3.2080408@cisco.com> <8ED0D683-536C-46B6-8E5A-3CC3B7CB678F@tik.ee.ethz.ch> <509BD62E.8070309@cisco.com> In-Reply-To: <509BD62E.8070309@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nevil Brownlee , IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5102bis-05.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, 08 Nov 2012 16:29:53 -0000 Benoit, >> What verb does the MP apply to a unit of information when it gives it >> to the EP? > > I've been using "expire" This sees to imply a certain architecture (ie a cache), which isn't mentioned in 5101. eg, a PSAMP MP might not have a cache, so there wouldn't be anything for the MP to expire. Also with a permanent cache, entries aren't expired - although they're exported, they also remain in the cache. So "expire" works in some cases, though not all. P. From trammell@tik.ee.ethz.ch Thu Nov 8 10:50:35 2012 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 A066D21F8481 for ; Thu, 8 Nov 2012 10:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 e19jZA3aN94s for ; Thu, 8 Nov 2012 10:50:34 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0F80E21F8458 for ; Thu, 8 Nov 2012 10:50:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D981ED930A for ; Thu, 8 Nov 2012 19:50:32 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Vd788lJD1cWF for ; Thu, 8 Nov 2012 19:50:32 +0100 (MET) Received: from dhcp-549e.meeting.ietf.org (dhcp-549e.meeting.ietf.org [130.129.84.158]) (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 1E6D9D9308 for ; Thu, 8 Nov 2012 19:50:31 +0100 (MET) From: Brian Trammell Content-Type: multipart/alternative; boundary="Apple-Mail=_0275F53F-EA41-4301-88FF-376BC8C10A11" Date: Thu, 8 Nov 2012 13:50:31 -0500 References: <026C1D4B-D592-4DA4-85BE-28FBB38FEA43@tik.ee.ethz.ch> To: IETF IPFIX Working Group Message-Id: <01FB82DB-9021-4F60-8256-8F0D3CE97C5C@tik.ee.ethz.ch> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [IPFIX] Fwd: WG Last Call for draft-ietf-ipfix-data-link-layer-monitoring-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: Thu, 08 Nov 2012 18:50:35 -0000 --Apple-Mail=_0275F53F-EA41-4301-88FF-376BC8C10A11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, As discussed in the meeting in Atlanta, my comments on section 5 should = be directed to someone (at the IEEE, or otherwise with 802 expertise) = who can answer the following question: Is the language in the current definitions of the affected Information = Elements interoperable with the language in the modified definitions? = That is, will implementations using the old definition be able to = correctly interpret information exported using the new one, and = vice-versa? Thanks, Brian Begin forwarded message: > From: Brian Trammell > Subject: Re: [IPFIX] WG Last Call for = draft-ietf-ipfix-data-link-layer-monitoring-01 > Date: 22 October 2012 12:53:34 EDT > To: Nevil Brownlee > Cc: IPFIX Working Group >=20 > Greetings, all, >=20 > I've done a quick review of = draft-ietf-ipfix-data-link-layer-monitoring-01 for WGLC; I haven't = checked the IE definitions for correctness (I'm not a layer 2 geek, and = will rely on external review from IEEE folks for that). However, I do = have a couple of comments. >=20 > This draft needs another revision before AD review, mainly to complete = Section 4, to generalize packet section export per the earlier = discussion on the subject (see = http://www.ietf.org/mail-archive/web/ipfix/current/msg06475.html ) -- = Would these changes also obviate the need for dataLinkFrameSize and = dataLinkFrameSection as defined by Sections 3.1 and 3.2?=20 >=20 > Additional comments, per section: >=20 > 3.3. dataLinkFrameType >=20 > Is there any existing registry for these? All I can think of off the = type of my head are the datalink types for libpcap, which are probably = not appropriate, but it would be nice if we had something to refer to = here. Section 8 will need to be more specific about IANA actions with = respect to the registry created by this section.=20 >=20 > 5. Modification of Existing Information Elements Related to VLAN Tag >=20 > Sections 5.1 through 5.4 will need thorough review by someone deeply = familiar with 802.1q to determine whether the new descriptions for these = Information Elements are interoperable with the existing descriptions, = as per Section 5.2 of IE-DOCTORS. If they are not interoperable, we will = need to create new Information Elements and deprecate the existing ones. >=20 > 8. IANA Considerations >=20 > This section needs to be more specific about IANA actions with respect = to the registry created for dataLinkFrameType. In keeping with existing = policy on subregistries, I presume this will be subject to Expert = Review.=20 >=20 > Cheers, >=20 > Brian >=20 > On 15 Oct 2012, at 4:36 , Nevil Brownlee wrote: >=20 >>=20 >> HI IPFIXers: >>=20 >> Paul has posted this draft, addressing the issue raised at our >> Meeting in Vancouver. >>=20 >> The WG Last Call for it starts now, and will end just after IETF-85, >> i.e. on Sunday, 11 November. >>=20 >> We'll ask the IEEE linklayer folk to comment, but of course we need >> your feedback too. Please read it through, and comment briefly on >> the IPFIX list. If you're able to review it, that would be great. >> However, comments like "I see no problems with this" would also be >> useful in judging consensus! >>=20 >> Cheers, Nevil >>=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 --Apple-Mail=_0275F53F-EA41-4301-88FF-376BC8C10A11 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: Brian Trammell = <trammell@tik.ee.ethz.ch>
Subject: Re: [IPFIX] WG Last Call for = draft-ietf-ipfix-data-link-layer-monitoring-01
Date: 22 October 2012 = 12:53:34 EDT
To: Nevil Brownlee <n.brownlee@auckland.ac.nz>= ;
Cc: IPFIX Working Group <ipfix@ietf.org>

=
Greetings, all,

I've done a quick review of = draft-ietf-ipfix-data-link-layer-monitoring-01 for WGLC; I haven't = checked the IE definitions for correctness (I'm not a layer 2 geek, and = will rely on external review from IEEE folks for that). However, I do = have a couple of comments.

This draft needs another revision = before AD review, mainly to complete Section 4, to generalize packet = section export per the earlier discussion on the subject (see = http://www.ietf.org/mail-archive/web/ipfix/current/msg06475.html ) = -- Would these changes also obviate the need for dataLinkFrameSize and = dataLinkFrameSection as defined by Sections 3.1 and 3.2? =

Additional comments, per section:

3.3. = dataLinkFrameType

Is there any existing registry for these? All I = can think of off the type of my head are the datalink types for libpcap, = which are probably not appropriate, but it would be nice if we had = something to refer to here. Section 8 will need to be more specific = about IANA actions with respect to the registry created by this section. =

5. Modification of Existing Information Elements Related to VLAN = Tag

Sections 5.1 through 5.4 will need thorough review by someone = deeply familiar with 802.1q to determine whether the new descriptions = for these Information Elements are interoperable with the existing = descriptions, as per Section 5.2 of IE-DOCTORS. If they are not = interoperable, we will need to create new Information Elements and = deprecate the existing ones.

8. IANA Considerations

This = section needs to be more specific about IANA actions with respect to the = registry created for dataLinkFrameType. In keeping with existing policy = on subregistries, I presume this will be subject to Expert Review. =

Cheers,

Brian

On 15 Oct 2012, at 4:36 , Nevil = Brownlee wrote:


HI = IPFIXers:

Paul has posted this draft, addressing the issue raised = at our
Meeting in Vancouver.

The WG Last Call for it starts = now, and will end just after IETF-85,
i.e. on Sunday, 11 = November.

We'll ask the IEEE linklayer folk to comment, but of = course we need
your feedback too.  Please read it through, and = comment briefly on
the IPFIX list.  If you're able to review it, = that would be great.
However, comments like "I see no problems with = this" would also be
useful in judging consensus!

Cheers, = Nevil

-- =
---------------------------------------------------------------------<= br>Nevil Brownlee =             &n= bsp;      Computer Science Department | = ITS
Phone: +64 9 373 7599 x88941 =             Th= e 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

= = --Apple-Mail=_0275F53F-EA41-4301-88FF-376BC8C10A11-- From n.brownlee@auckland.ac.nz Fri Nov 9 08:21:03 2012 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 A734621F8860 for ; Fri, 9 Nov 2012 08:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 eFnYQcvJ6WX2 for ; Fri, 9 Nov 2012 08:21:02 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id A810F21F8676 for ; Fri, 9 Nov 2012 08:21:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1352478062; x=1384014062; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=VMhWcOyJclN4BqsZLZcoL1N4HBUx5ouySSoEd03SdU8=; b=AzY65p+Pj3WZQ268StwOo6L90uYFhMPn9QwKnF9bw5J0Iv+YmTsLVmHF /VW3U/jZeVx+0j1gBiSS1ITMAcSNlNDbyc/XXpbhwaAmAzIArNpRkB38c H/+7yGcI5IVt3xTnM0br8vnx2VtzdjjxEuVtMISa6p1Xh1gCvZTP5DXRj k=; X-IronPort-AV: E=Sophos;i="4.80,746,1344168000"; d="scan'208";a="156107967" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.20.231 - Outgoing - Outgoing-SSL Received: from dhcp-14e7.meeting.ietf.org (HELO [130.129.20.231]) ([130.129.20.231]) by mx2-int.auckland.ac.nz with ESMTP; 10 Nov 2012 05:20:58 +1300 Message-ID: <509D2D65.404@auckland.ac.nz> Date: Sat, 10 Nov 2012 05:20:53 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] DRAFT minutes of IPFIX meting at IETF 85 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: Fri, 09 Nov 2012 16:21:03 -0000 Hi all: The DRAFT minutes are available at http://www.ietf.org/proceedings/85/minutes/minutes-85-ipfix Please have a look; if you were at the meeting and feel that changes or corrections are needed, please email them to me. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From ietf@meetecho.com Fri Nov 9 09:09:12 2012 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 B632221F8646 for ; Fri, 9 Nov 2012 09:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 bQ1FwkRktFhD for ; Fri, 9 Nov 2012 09:09:12 -0800 (PST) Received: from smtpdg8.aruba.it (smtpdg8.aruba.it [62.149.158.238]) by ietfa.amsl.com (Postfix) with ESMTP id 2010321F87FD for ; Fri, 9 Nov 2012 09:09:11 -0800 (PST) Received: from [130.129.19.11] ([130.129.19.11]) by smtpcmd03.ad.aruba.it with bizsmtp id MV991k00S0ELJoa01V9AxK; Fri, 09 Nov 2012 18:09:10 +0100 Message-ID: <509D38B3.8060301@meetecho.com> Date: Fri, 09 Nov 2012 18:09:07 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Meetecho session recording 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: Fri, 09 Nov 2012 17:09:12 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of this WG session at IETF-85 is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf85/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From n.brownlee@auckland.ac.nz Fri Nov 9 09:27:53 2012 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 D5F7621F87B5 for ; Fri, 9 Nov 2012 09:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 2W7coz4qAtMF for ; Fri, 9 Nov 2012 09:27:53 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7AC21F8770 for ; Fri, 9 Nov 2012 09:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1352482073; x=1384018073; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=4rsQb1qNPJ1SK6aoVBtrmmhiqR6sIfjdWGmb4LcW3Rg=; b=VRX7WrMuBXzA6pTy0iq2grKnj3vAr3YN6lt71enfF/k9C+Vzf/boOe67 sgDfToogtYdoXhyYqct8N5hG0qMHtZfELqo+kzO64Gg+3L1xnN0hpjwW3 aoQa/YXxV2dsno4pSHbaLwCpX508JFBtnKVPxZ0X77sOrV6iovX5GQj6W Y=; X-IronPort-AV: E=Sophos;i="4.80,746,1344168000"; d="scan'208";a="156111664" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.20.231 - Outgoing - Outgoing-SSL Received: from dhcp-14e7.meeting.ietf.org (HELO [130.129.20.231]) ([130.129.20.231]) by mx2-int.auckland.ac.nz with ESMTP; 10 Nov 2012 06:27:46 +1300 Message-ID: <509D3D0E.1030601@auckland.ac.nz> Date: Sat, 10 Nov 2012 06:27:42 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Andrew Feren , IPFIX Working Group References: <509D2D65.404@auckland.ac.nz> <509D32B5.4030309@plixer.com> In-Reply-To: <509D32B5.4030309@plixer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] DRAFT minutes of IPFIX meting at IETF 85 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: Fri, 09 Nov 2012 17:27:53 -0000 On 10/11/12 05:43, Andrew Feren wrote: > Those don't look like the IPFIX minutes. > > -Andrew Hi Andrew: Nicely spotted, thanks very much! I've submitted the correct file to the meeting materials manager, but it takes quite a while for it to update. Meantime, here are the DRAFT minutes ... DRAFT-00 Minutes of the IPFIX meeting at IETF 85 in Atlanta About 22 people present Scribes: Chris Inacio, Nevil Brownlee Meeting chair: Juergen Quittek, Nevil Brownlee Juergen opened the meeting, Nevil gave the IPFIX status update: - Flow Selection draft is in AD Review, progressing - IE-Doctors in AD Followup: in response to DISCUSS, IANA Actions will be moved to 5102bis, IE-Doctors will need normative reference to it - Aggregation draft: on IESG telechat agenda, will need a new revision before going to RFC Editor - No work done on Mediation-Protocol since IETF 84, expect some progress by IETF 86 (Orlando) Brian presented our 5101bis and 5102bis drafts - Benoit Claise commented that IPR needs to be re-asserted in bis documents, Cisco legal will do that for these two - 5102 (IPFIX Information Model) - WGLC ran from 14 to 22 October, lots of comments - Section 5, Information element Categories, is no longer needed, proposedto replace it with stub pointing to IANA registry - Benoit suggests a summary/history as well as that pointer, including text about categories of IEs, so that 5102 remains a complete description of our model - Meeting agreed to this, to be done in next revision - 5101 (IPFIX Protocol) - No updates since IETF 84, authors working on next revision - AD comment: we don't have to interop all features of protocol to advance standards level - List comment about byte ordering, Brian will add a reference for that - WGLC to start when document is stable Paul Aitken presented (via Meetecho) the Link Layer IEs draft. - WGLC for this started 15 Oct 12; it will end after next week's (bi-monthly) IEEE 802.3 meeting - Juergen commented that the draft has a VXLAN I-D as an Informative Reference - Brian pointed out that several IPFIX IEs cover VLANs, we need to check that the proposed VXLAN IEs will not cause interoperation with them - Paul will find a VLAN-tag expert to check that - Will need a new revision, when that's stable Nevil will submit to IESG Paul presented the MIB Variable Export draft - Most issues have now been resolved - 'Extended Field Specifiers' introduced as a good way to represent OIDs in an IPFIX template. Clear agreement in the room on this - Field Lengths in the EFS were discussed. Brian asked how variable-length fields would be handled? - New version needed, WGLC when draft is stable Paul presented two new individual drafts - IE Equivalence - Addresses question "how does a collector know that a Private IE is equivalent to an IANA IE?" - Four possible methods explored, Paul proposes exporting an 'equivalence table' - How long does an exporter need to keep sending the table? - Benoit suggests using URIs instead, as Chris proposed at IETF 84. Brian wants to see Chris' draft about that completed first - Recent IANA IE Registry Changes - Summarises changes to the registry over about the last 18 months; this is a useful document - Brian pointed out that IE 353 should have an upper-case O in 'octets' - Benoit asked whether these changes meet the guidelines set out in IE-Doctors? - A general review of IE semantics would be 'a good thing' - Nevil will ask for volunteers on the list Any Other Business discussions - IPFIX Milestones - Exporting MIB Objects and Mediation Protocol changed to July 2013 - Aim for Mediation Protocol WGLC in April 2013 - Interop - Interop testing is useful whether or not we need it to advance standards level - Brian's Open Source implementation (ripfix) is now available, he will post instructions on how to use it to the list - IPFIX work in other WGs - Benoit reported on RADIUS Accounting draft - Brian commented that ALTO have a new draft that describes exporting values as text strings; he would like others to read it and comment on the IPFIX list The meeting finished at 1435 Cheers again, Nevil > On 11/09/2012 11:20 AM, Nevil Brownlee wrote: >> >> Hi all: >> >> The DRAFT minutes are available at >> http://www.ietf.org/proceedings/85/minutes/minutes-85-ipfix >> >> Please have a look; if you were at the meeting and feel that >> changes or corrections are needed, please email them to me. >> >> Cheers, Nevil >> > -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From paitken@cisco.com Fri Nov 9 13:01:43 2012 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 B90AA21F85F3 for ; Fri, 9 Nov 2012 13:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.544 X-Spam-Level: X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 0X7yOfLbOXgo for ; Fri, 9 Nov 2012 13:01:42 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A2A2121F85F0 for ; Fri, 9 Nov 2012 13:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=555; q=dns/txt; s=iport; t=1352494902; x=1353704502; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=ikPLnRv2aLmI5ZOTbHisnPZoeTao2qlryPOtBS0AX3M=; b=EUlNxbtiX24DAbCWmDcvk0/rXI+jOjakqN4NbDnvKgwUSQ4yzRMtixSW t/Xk7OqTzjISbSkK3q33a7qJI5hfXzyN7y59c9Prq2BqquFetvab2+yaG a+1ova8SEZ2Sv4lbwX83rmXglY2vGV9PkJoR0awz0pO6g5Vt9/+upcvhv I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOBunVCQ/khN/2dsb2JhbABEw0KBCII3ASUvET0WGAMCAQIBSw0IAQEeh2icU4EroAySXgOVe4VriG2Ba4Jv X-IronPort-AV: E=McAfee;i="5400,1158,6891"; a="146532625" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2012 21:01:17 +0000 Received: from [10.55.85.244] (dhcp-10-55-85-244.cisco.com [10.55.85.244]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA9L1H2n016288 for ; Fri, 9 Nov 2012 21:01:17 GMT Message-ID: <509D6F1D.8030107@cisco.com> Date: Fri, 09 Nov 2012 21:01:17 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 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] Information Elements errata 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: Fri, 09 Nov 2012 21:01:43 -0000 Dear IPFIXers, FYI, after Brian spotted the "layer2octetTotalCount" typo, I've asked IANA to fix two IEs: 1. #95 - rename "ApplicationId" to "applicationId" (ie, with a lowercase "a"). - I verified the name in RFC 6795. 2. #353 rename "layer2octetTotalCount" to "layer2OctetTotalCount" (ie, with a capital "O"). Compare with #352 layer2OctetDeltaCount. - it's a typo carried from draft-kashima-ipfix-data-link-layer-monitoring, which I'll correct in draft-ietf-ipfix-data-link-layer-monitoring. P. From bclaise@cisco.com Mon Nov 12 08:51:29 2012 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 9AA8B21F853E for ; Mon, 12 Nov 2012 08:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.117 X-Spam-Level: X-Spam-Status: No, score=-10.117 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 C5sGmhYNCztp for ; Mon, 12 Nov 2012 08:51:29 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id AB93121F853D for ; Mon, 12 Nov 2012 08:51:28 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qACGpRix015684; Mon, 12 Nov 2012 17:51:27 +0100 (CET) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qACGpQkc019753; Mon, 12 Nov 2012 17:51:26 +0100 (CET) Message-ID: <50A1290E.6080200@cisco.com> Date: Mon, 12 Nov 2012 17:51:26 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org References: <8b9118710c0f73581afe12789d16ae07.squirrel@www.trepanning.net> In-Reply-To: <8b9118710c0f73581afe12789d16ae07.squirrel@www.trepanning.net> X-Forwarded-Message-Id: <8b9118710c0f73581afe12789d16ae07.squirrel@www.trepanning.net> Content-Type: multipart/alternative; boundary="------------020702000701010906000902" Cc: "ipfix@ietf.org" Subject: [IPFIX] Fwd: secdir review of draft-ietf-ipfix-flow-selection-tech 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, 12 Nov 2012 16:51:29 -0000 This is a multi-part message in MIME format. --------------020702000701010906000902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear authors, Reading my old emails, I'm not sure that you took into account Dan's feedback. At the very minimum, you should give a reply Regards, Benoit -------- Original Message -------- Subject: secdir review of draft-ietf-ipfix-flow-selection-tech Date: Tue, 10 Apr 2012 16:59:43 -0700 (PDT) From: Dan Harkins To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes techniques to select flows which are sets of packets with some common characteristics. The authors have accurately identified what constitutes an attack-- an adversary having the ability to influence flow selection-- and the Security Considerations give a couple examples of this. They seem fine. There is reference to a paper "[GoRe07]" which does not appear in the References and seems to give advice that I think is wrong: use a strong cryptographically strong random number generator to thwart an attack in which parameters of time-based sampling are discovered to predict the selection decision. This attack can be thwarted by using a value that the adversary cannot predict (sort of like an IV for CBC mode) instead of a cryptographically strong random number. That leaves the random number pool to applications that really need it (like a key exchange that does a Diffie-Hellman). I suggest removing the reference to the un-referenced paper and mention a weaker requirement to thwart that attack. regards, Dan. --------------020702000701010906000902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear authors,

Reading my old emails, I'm not sure that you took into account Dan's feedback.
At the very minimum, you should give a reply

Regards, Benoit


-------- Original Message --------
Subject: secdir review of draft-ietf-ipfix-flow-selection-tech
Date: Tue, 10 Apr 2012 16:59:43 -0700 (PDT)
From: Dan Harkins <dharkins@lounge.org>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org 


  Hello,

  I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

  This draft describes techniques to select flows which are sets of
packets with some common characteristics. The authors have accurately
identified what constitutes an attack-- an adversary having the ability
to influence flow selection-- and the Security Considerations give
a couple examples of this. They seem fine.

  There is reference to a paper "[GoRe07]" which does not appear in the
References and seems to give advice that I think is wrong: use a strong
cryptographically strong random number generator to thwart an attack in
which parameters of time-based sampling are discovered to predict the
selection decision. This attack can be thwarted by using a value that
the adversary cannot predict (sort of like an IV for CBC mode) instead
of a cryptographically strong random number. That leaves the random
number pool to applications that really need it (like a key exchange
that does a Diffie-Hellman). I suggest removing the reference to the
un-referenced paper and mention a weaker requirement to thwart that
attack.

  regards,

  Dan.



--------------020702000701010906000902-- From dromasca@avaya.com Mon Nov 12 09:32:26 2012 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 9048A21F862E; Mon, 12 Nov 2012 09:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.914 X-Spam-Level: X-Spam-Status: No, score=-102.914 tagged_above=-999 required=5 tests=[AWL=-0.315, 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 yzDfewvuao7d; Mon, 12 Nov 2012 09:32:25 -0800 (PST) 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 955C521F86CB; Mon, 12 Nov 2012 09:32:25 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAEvoFDGmAcF/2dsb2JhbABEw1WBCIIeAQEBAQIBEh4KPwUNARUHDgYMDAdXAQQBGgEZh2IGC54mnAGRfmEDlxiEcYo2gnA X-IronPort-AV: E=Sophos;i="4.80,759,1344225600"; d="scan'208";a="35752013" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 12 Nov 2012 12:25:09 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Nov 2012 12:30:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Nov 2012 18:32:21 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-ipfix-a9n-07 Thread-Index: Ac3A+6vH5icZKWrlTQS9LiERx0FK1Q== From: "Romascanu, Dan (Dan)" To: , "IETF IPFIX Working Group" Cc: Ron Bonica Subject: [IPFIX] Gen-ART review of draft-ietf-ipfix-a9n-07 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, 12 Nov 2012 17:32:26 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ipfix-a9n-07.txt Reviewer: Dan Romascanu Review Date: 11/12/12 IETF LC End Date: 11/13/12 IESG Telechat date: 11/15/12 Summary: The draft is ready for publication, a few minor issues should be clarified before approval and publication. Major issues: None Minor issues: 1. The definition of an aggregated flow in Section 2 reads:=20 > Aggregated Flow: A Flow, as defined by [I-D.ietf-ipfix-protocol-rfc5101bis], derived from a set of zero or more original Flows within a defined Aggregation Interval. The primary difference between a Flow and an Aggregated Flow in the general case is that the time interval (i.e., the two-tuple of start and end times) of a Flow is derived from information about the timing of the packets comprising the Flow, while the time interval of an Aggregated Flow is often externally imposed. Note that an Aggregated Flow is defined in the context of an Intermediate Aggregation Process only. Once an Aggregated Flow is exported, it is essentially a Flow as in [I-D.ietf-ipfix-protocol-rfc5101bis] and can be treated as such. The way the second phrase is written confuses me. If 'the time interval of an Aggregated Flow' is externally imposed, this means that there are exceptions? In which cases? And in these cases what is the specific difference that makes that Flow to be Aggregated?=20 2. In Section 5.3.1 the URL quoted for the IPFIX Information Elements registry http://www.iana.org/assignments/ipfix/ipfix.html does not exist.=20 3. The IANA Note in section 7.2.4 is supposed to be left in the text? If not, is it necessary to mention someplace else the issue of backwards compatibility with the IE value in NetFlow version 9?=20 4. Same question for the IANA note in Section 10.=20 Nits/editorial comments: 1. Section 5.1.1:=20 > Each counter for an Original Flow is divided by the number of time _units_ the Original Flow covers, to derive a mean count rate. What is the meaning of _units_?=20 2. Runing idnits leads to a number of formatting problems that I am sure will be corrected by the RFC Editor.=20 From salvatore.dantonio@uniparthenope.it Wed Nov 14 00:38:03 2012 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 8FB8B21F8466 for ; Wed, 14 Nov 2012 00:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.269 X-Spam-Level: X-Spam-Status: No, score=-0.269 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] 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 h4unNdm+n4QG for ; Wed, 14 Nov 2012 00:37:59 -0800 (PST) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by ietfa.amsl.com (Postfix) with ESMTP id B604121F844C for ; Wed, 14 Nov 2012 00:37:57 -0800 (PST) Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id 61E9716095; Wed, 14 Nov 2012 08:37:53 +0000 (UTC) Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 1d59_9470a710_2e36_11e2_9101_001372515a5c; Wed, 14 Nov 2012 09:37:52 +0100 Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id 406BFC42EE; Wed, 14 Nov 2012 09:37:42 +0100 (CET) Received: by spamk.uniparthenope.it (Postfix, from userid 500) id 3C7C019AC91; Wed, 14 Nov 2012 09:37:42 +0100 (CET) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by spamk.uniparthenope.it (Postfix) with ESMTP id 23BE5C42EE; Wed, 14 Nov 2012 09:37:38 +0100 (CET) Received: from saldantoPC (unknown [192.168.189.124]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id 601CB15D29; Wed, 14 Nov 2012 09:37:48 +0100 (CET) From: "Salvatore D'Antonio" To: "'Benoit Claise'" References: <4FC74398.50805@cisco.com> <4FC89B99.40107@cisco.com> <506DA106.5060705@cisco.com> <50904E1D.7060909@cisco.com> <007301cdbb66$c58d6a10$50a83e30$@dantonio@uniparthenope.it> <509BCC69.6020603@cisco.com> In-Reply-To: <509BCC69.6020603@cisco.com> Date: Wed, 14 Nov 2012 09:37:48 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac29xU9IkpSf/H+BS/yPnTCW9u0T6QEfN2nw Content-Language: it Message-ID: <003801cdc243$53a7b6b0$faf72410$@dantonio@uniparthenope.it> Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01CDC24B.B56C1EB0" X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20121114 #8373409, check: 20121114 clean Cc: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org, ipfix@ietf.org, ipfix-chairs@tools.ietf.org Subject: [IPFIX] R: R: New AD review of draft-ietf-ipfix-flow-selection-tech-10.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, 14 Nov 2012 08:38:03 -0000 Messaggio multipart in formato MIME. ------=_NextPart_000_0039_01CDC24B.B56C1EB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Benoit, =20 My answers inline. =20 Da: Benoit Claise [mailto:bclaise@cisco.com]=20 Inviato: gioved=EC 8 novembre 2012 16:15 A: Salvatore D'Antonio Cc: ipfix@ietf.org; draft-ietf-ipfix-flow-selection-tech@tools.ietf.org; ipfix-chairs@tools.ietf.org Oggetto: Re: R: [IPFIX] New AD review of draft-ietf-ipfix-flow-selection-tech-10.txt =20 Dear Salvatore, I removed the comments on which we agree, for clarity. Dear Benoit, =20 My comments to your comments inline. =20 Da: Benoit Claise [mailto:bclaise@cisco.com]=20 Inviato: marted=EC 30 ottobre 2012 23:01 A: ipfix@ietf.org; draft-ietf-ipfix-flow-selection-tech@tools.ietf.org Cc: ipfix-chairs@tools.ietf.org Oggetto: Re: [IPFIX] New AD review of draft-ietf-ipfix-flow-selection-tech-10.txt =20 =20 Intermediate Flow Selection Process: an Intermediate Process as in [RFC6183 ] that ... =20 =20 The new definition improved a lot: * Intermediate Flow Selection Process =20 An Intermediate Flow Selection Process takes Flow Records as its input and selects a subset of this set as its output. Intermediate Flow Selection Process is a more general concept than Intermediate Selection Process as defined in [RFC6183 ]. While an Intermediate Selection Process selects Flow Records from a sequence based upon criteria-evaluated Flow record values and passes only those Flow Records that match the criteria, an Intermediate Flow Selection Process selects Flow Records using selection criteria applicable to a larger set of Flow characteristics and information. But is there a reason why this definition can't be based on = "intermediate Process" from RFC 6183: Intermediate Process =20 An Intermediate Process takes a record stream as its input from Collecting Processes, Metering Processes, IPFIX File Readers, other Intermediate Processes, or other record sources; performs some transformations on this stream based upon the content of each record, states maintained across multiple records, or other data sources; and passes the transformed record stream as its output to Exporting Processes, IPFIX File Writers, or other Intermediate Processes in order to perform IPFIX Mediation. Typically, an Intermediate Process is hosted by an IPFIX Mediator. Alternatively, an Intermediate Process may be hosted by an Original Exporter. =20 According to the definition of =93Intermediate Process=94 from RFC 6183, = such a process is typically hosted by an IPFIX Mediator. Alternatively, it may = be hosted by an Original Exporter. In my view, an Intermediate Flow = Selection Process could be also hosted by a Collector. Sure. Then the Collector becomes a Collector that contains a mediator function. I don't see the problem. =20 Ok, it=92s clear to me now. I will modify the text of the definition accordingly. =20 Intermediate Process =20 An Intermediate Process takes a record stream as its input from Collecting Processes, Metering Processes, IPFIX File Readers, other Intermediate Processes,=20 My concern if you use your definition is that it doesn't build on the framework RFC 6183 =20 So=20 * Intermediate Flow Selection Process =20 An Intermediate Flow Selection Process is an Intermediate Process = as in [RFC6183 ] that takes Flow Records as its input and selects a subset of this set as its output. Intermediate Flow Selection Process is a more general concept than Intermediate Selection Process as defined in [RFC6183 ]. While an Intermediate Selection Process selects Flow Records from a sequence based upon criteria-evaluated Flow record values and passes only those Flow Records that match the criteria, an Intermediate Flow Selection Process selects Flow Records using selection criteria applicable to a larger set of Flow characteristics and information. =20 4. Flow selection as a Function in the IPFIX Architecture=20 =20 Thanks for your new figure 1. One editorial change: change the + in the left vertical line. Ok, will do. = +=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+ | | | Mediator | | + +-V-------------------+ | | | | Collecting Process | | | + +---------------------+ | | | | Intermediate Flow | | | | | Selection Process | | | + +---------------------+ | | | | Exporting Process | | | + +-|-------------------+ | | = +=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+ | =20 5.1. Flow Filtering=20 Flow Filtering is a deterministic function on the IPFIX Flow Record=20 content. If the relevant flow characteristics are already observable = at packet level (e.g. Flow Keys), Flow Filtering can be applied=20 before aggregation at packet level. In order to be compliant with=20 this document, at least the Property Match Filtering MUST be=20 implemented.=20 This contradicts. In order to be compliant with this document, at least one of the flow selection schemes MUST be implemented. Actually, wrong cut/paste. This contradicts, in section 1: In order to be compliant with this document, at least the Property Match Filtering MUST be implemented. =20 This comment is not clear to me. Both in Section 1 and in Section 5.1 = (Flow Filtering) I used the same sentence =93In order to be compliant with = this document, at least the Property Match Filtering MUST be implemented=94. =20 Solved with version 12. However, I'm wondering if the resolution is correct. version 11: =20 In order to be compliant with this document, at least one of the flow selection schemes MUST be implemented.=20 =20 ... =20 In order to be compliant with this document, at least the Property Match Filtering MUST be implemented. Version 12: In order to be compliant with this document, at least the Property Match Filtering MUST be implemented. Listing all the selection techniques,=20 5 . Flow Selection Techniques . . . . . . . . . . . . . . . . . . 10 5.1 . Flow Filtering . . . . . . . . . . . . . . . . . . . . . . 11 5.1.1 . Property Match Filtering . . . . . . . . . . . . . . . 11 5.1.2 . Hash-based 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 Flow Selection . . . . . . . . . . . 13 5.4 . Flow-state Dependent Packet Selection . . . . . . . . . . 14 It means that a device that implements Flow Sampling was compliant with version 11 thanks to the sentence "In order to be compliant with this document, at least one of the flow selection schemes MUST be = implemented" and is not compliant any longer with version 12 It seems like an important change to me since the WGLC, on which the WG = must agree. =20 I agree. A new WGLC is needed to have feedback on this change from the = WG. =20 Best regards, =20 Salvatore Regards, Benoit =20 =20 _____ =20 Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2012.0.2221 / Database dei virus: 2441/5381 - Data di = rilascio: 07/11/2012 ------=_NextPart_000_0039_01CDC24B.B56C1EB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Benoit,

 

My answers inline.

 

Da: Benoit Claise [mailto:bclaise@cisco.com]
Inviato: gioved=EC 8 novembre 2012 16:15
A: Salvatore D'Antonio
Cc: ipfix@ietf.org; = draft-ietf-ipfix-flow-selection-tech@tools.ietf.org; ipfix-chairs@tools.ietf.org
Oggetto: Re: R: [IPFIX] New AD review of draft-ietf-ipfix-flow-selection-tech-10.txt

 

Dear Salvatore,

I removed the comments on which we agree, for clarity.

Dear Benoit,

 

My comments to your comments = inline.

 

 

 



Intermediate Flow Selection Process: an Intermediate Process as =
in
      [RFC6183] that =
...
 

 

The new definition improved a lot:

 * Intermediate Flow Selection =
Process
 
  &nbs=
p;   An Intermediate Flow Selection Process takes Flow Records =
as its
      input and =
selects a subset of this set as its =
output.
      Intermediate =
Flow Selection Process is a more general concept =
than
      Intermediate =
Selection Process as defined in [RFC6183].  While an
 =
     Intermediate Selection Process selects =
Flow Records from a
      =
sequence based upon criteria-evaluated Flow record values =
and
      passes only =
those Flow Records that match the criteria, =
an
      Intermediate Flow =
Selection Process selects Flow Records =
using
      selection =
criteria applicable to a larger set of =
Flow
      characteristics =
and information.

But is there a reason why this definition can't be = based on "intermediate Process" from RFC 6183:

Intermediate =
Process
 
  &nbs=
p;   An Intermediate Process takes a record stream as its =
input from
      =
Collecting Processes, Metering Processes, IPFIX File =
Readers,
      other =
Intermediate Processes, or other record sources; =
performs
      some =
transformations on this stream based upon the content of =
each
      record, states =
maintained across multiple records, or other =
data
      sources; and =
passes the transformed record stream as its output =
to
      Exporting =
Processes, IPFIX File Writers, or other =
Intermediate
      =
Processes in order to perform IPFIX Mediation.  Typically, =
an
      Intermediate =
Process is hosted by an IPFIX =
Mediator.
      =
Alternatively, an Intermediate Process may be hosted by =
an
      Original =
Exporter.
 
According to the definition of “Intermediate Process” =
from RFC 6183, such a process is typically hosted by an IPFIX Mediator. =
Alternatively, it may be hosted by an Original Exporter. In my view, an =
Intermediate Flow Selection Process could be also hosted by a =
Collector.

Sure. Then the Collector becomes a Collector that = contains a mediator function.
I don't see the problem.

 

Ok, it’s clear to me now. I will modify the text of = the definition accordingly.

 

=A0=A0 Intermediate =
Process
 
=A0=A0=A0=A0=A0 =
An Intermediate Process takes a record stream as its input =
from
=A0=A0=A0=A0=A0 Collecting Processes, =
Metering Processes, IPFIX File =
Readers,
=A0=A0=A0=A0=A0 other Intermediate =
Processes,


My concern if you use your definition is that it doesn't build on the = framework RFC 6183

 

So 

 * Intermediate Flow Selection =
Process
 
  &nbs=
p;   An Intermediate Flow Selection Process is an =
Intermediate Process as =
in
      [RFC6183] that takes Flow Records as =
its
      input and =
selects a subset of this set as its =
output.
      Intermediate =
Flow Selection Process is a more general concept =
than
      Intermediate =
Selection Process as defined in [RFC6183].  While =
an
      Intermediate =
Selection Process selects Flow Records from =
a
      sequence based =
upon criteria-evaluated Flow record values =
and
      passes only =
those Flow Records that match the criteria, =
an
      Intermediate Flow =
Selection Process selects Flow Records =
using
      selection =
criteria applicable to a larger set of =
Flow
      characteristics =
and information.




 




4.  Flow selection as a Function in the IPFIX Architecture
  

Thanks for your new = figure 1.
One editorial change: change the + in the left vertical = line.

Ok, will = do.

      =
+=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D+      =
|
      =
|      |  =
Mediator           =
;   |      =
|
      =
+    +-V-------------------+    =
|      =
|
      =
|    | Collecting Process  |    =
|      =
|
      =
+    +---------------------+    =
|      =
|
      =
|    | Intermediate Flow   |    =
|      =
|
      =
|    | Selection Process   |    =
|      =
|
      =
+    +---------------------+    =
|      =
|
      =
|    |  Exporting Process  |    =
|      =
|
      =
+    +-|-------------------+    =
|      =
|
      =
+=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D+      =
|
     


5.1.  Flow Filtering

   Flow Filtering is a deterministic function on the IPFIX = Flow Record
   content.  If the relevant flow characteristics are = already observable
   at packet level (e.g.  Flow Keys), Flow Filtering can = be applied
   before aggregation at packet level.  In order to be = compliant with
   this document, at least the Property Match Filtering MUST = be
   implemented.

This contradicts.

   In order to be compliant with this document, =
at
   least one of the flow selection =
schemes MUST be implemented.

Actually, wrong cut/paste.
This contradicts, in section 1:

   In order to be compliant with this document, =
at
   least the Property Match Filtering =
MUST be implemented.

 

This comment is not = clear to me. Both in Section 1 and in Section 5.1 (Flow Filtering) I used the = same sentence “In order to be compliant with this document, at least = the Property Match Filtering MUST be = implemented”.

 

Solved with version 12.
However, I'm wondering if the resolution is correct.
version 11:
       

=A0=A0 In order to be compliant with this document, =
at
=A0=A0 least one of the flow selection schemes =
MUST be implemented. =

=A0
=A0=A0=A0...
 
=A0=A0 In order to be compliant with =
this document, at
=A0=A0 least the Property Match =
Filtering MUST be implemented.





Version 12:



=A0=A0=A0 In order to be compliant with this document, =
at
=A0=A0 least the Property Match Filtering MUST =
be implemented.





Listing all the selection techniques, 



=A0=A0 5.=A0 Flow Selection Techniques=A0 . . . . . . . . . . =
. . . . . . . . 10
=A0=A0=A0=A0 5.1.=A0 Flow Filtering . . . . . . . . . . . . . . . =
. . . . . . . 11
=A0=A0=A0=A0=A0=A0 5.1.1.=A0 Property Match Filtering . . . . . . . . =
. . . . . . . 11
=A0=A0=A0=A0=A0=A0 5.1.2.=A0 Hash-based Flow Filtering=A0 . . . . . . =
. . . . . . . . 11
=A0=A0=A0=A0 5.2.=A0 Flow Sampling=A0 . . . . . . . . . . . . . . =
. . . . . . . . 12
=A0=A0=A0=A0=A0=A0 5.2.1.=A0 Systematic sampling=A0 . . . . . . . . . =
. . . . . . . . 12
=A0=A0=A0=A0=A0=A0 5.2.2.=A0 Random Sampling=A0 . . . . . . . . . . . =
. . . . . . . . 12
=A0=A0=A0=A0 5.3.=A0 Flow-state Dependent Flow Selection=A0 . . . =
. . . . . . . . 13
=A0=A0=A0=A0 5.4.=A0 Flow-state Dependent Packet Selection=A0 . . =
. . . . . . . . 14





It means that a device that implements Flow Sampling was compliant with =
version
11 thanks to the sentence "In order to be compliant with this =
document, at
least one of the flow selection schemes MUST be implemented" and is =
not
compliant any longer with version 12

It seems like an important change to me since the WGLC, on which the WG =
must
agree.



 



I agree. A new WGLC is needed to have feedback on this =
change from
the WG.



 



Best regards,



 



Salvatore







Regards, Benoit




























 






 












Nessun
virus nel messaggio.

Controllato da AVG - www.avg.com

Versione: 2012.0.2221 / Database dei virus: 2441/5381 - Data di =
rilascio:
07/11/2012
------=_NextPart_000_0039_01CDC24B.B56C1EB0-- From salvatore.dantonio@uniparthenope.it Wed Nov 14 00:44:23 2012 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 40B7B21F8555 for ; Wed, 14 Nov 2012 00:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.231 X-Spam-Level: X-Spam-Status: No, score=0.231 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] 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 4xBiPXZHKT0e for ; Wed, 14 Nov 2012 00:44:21 -0800 (PST) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by ietfa.amsl.com (Postfix) with ESMTP id 03DBC21F883A for ; Wed, 14 Nov 2012 00:44:21 -0800 (PST) Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id 35DCB16E57; Wed, 14 Nov 2012 08:44:20 +0000 (UTC) Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 1d41_7b054262_2e37_11e2_9101_001372515a5c; Wed, 14 Nov 2012 09:44:19 +0100 Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id F1F58C432D; Wed, 14 Nov 2012 09:44:07 +0100 (CET) Received: by spamk.uniparthenope.it (Postfix, from userid 500) id EB54CC4328; Wed, 14 Nov 2012 09:44:07 +0100 (CET) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by spamk.uniparthenope.it (Postfix) with ESMTP id 848F1C4328; Wed, 14 Nov 2012 09:44:02 +0100 (CET) Received: from saldantoPC (unknown [192.168.189.124]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id D8C1616294; Wed, 14 Nov 2012 09:44:12 +0100 (CET) From: "Salvatore D'Antonio" To: "'Benoit Claise'" , References: <8b9118710c0f73581afe12789d16ae07.squirrel@www.trepanning.net> <50A1290E.6080200@cisco.com> In-Reply-To: <50A1290E.6080200@cisco.com> Date: Wed, 14 Nov 2012 09:44:12 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3A9garAsWIvLsNTZujclndthOpKQBTbdfQ Content-Language: it Message-ID: <003d01cdc244$38cfce80$aa6f6b80$@dantonio@uniparthenope.it> Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01CDC24C.9A943680" X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20121114 #8373409, check: 20121114 clean Cc: ipfix@ietf.org Subject: [IPFIX] R: secdir review of draft-ietf-ipfix-flow-selection-tech 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, 14 Nov 2012 08:44:23 -0000 Messaggio multipart in formato MIME. ------=_NextPart_000_003E_01CDC24C.9A943680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all,=20 =20 I missed Dan=92s e-mail. I apologise for that. =20 I will address Dan=92s comments in the new version of the Draft. =20 Best regards, =20 Salvatore =20 =20 =20 Da: Benoit Claise [mailto:bclaise@cisco.com]=20 Inviato: luned=EC 12 novembre 2012 17:51 A: draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org Cc: ipfix@ietf.org Oggetto: Fwd: secdir review of draft-ietf-ipfix-flow-selection-tech =20 Dear authors, Reading my old emails, I'm not sure that you took into account Dan's feedback. At the very minimum, you should give a reply Regards, Benoit -------- Original Message --------=20 Subject:=20 secdir review of draft-ietf-ipfix-flow-selection-tech Date:=20 Tue, 10 Apr 2012 16:59:43 -0700 (PDT) From:=20 Dan Harkins To:=20 iesg@ietf.org, secdir@ietf.org, draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org =20 Hello, =20 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. =20 This draft describes techniques to select flows which are sets of packets with some common characteristics. The authors have accurately identified what constitutes an attack-- an adversary having the ability to influence flow selection-- and the Security Considerations give a couple examples of this. They seem fine. =20 There is reference to a paper "[GoRe07]" which does not appear in the References and seems to give advice that I think is wrong: use a strong cryptographically strong random number generator to thwart an attack in which parameters of time-based sampling are discovered to predict the selection decision. This attack can be thwarted by using a value that the adversary cannot predict (sort of like an IV for CBC mode) instead of a cryptographically strong random number. That leaves the random number pool to applications that really need it (like a key exchange that does a Diffie-Hellman). I suggest removing the reference to the un-referenced paper and mention a weaker requirement to thwart that attack. =20 regards, =20 Dan. =20 =20 =20 =20 =20 _____ =20 Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2012.0.2221 / Database dei virus: 2441/5390 - Data di = rilascio: 12/11/2012 ------=_NextPart_000_003E_01CDC24C.9A943680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I missed Dan’s e-mail. I apologise for = that.

 

I will address Dan’s comments =A0in the new version = of the Draft.

 

Best regards,

 

Salvatore

 

 

 

Da: Benoit Claise [mailto:bclaise@cisco.com]
Inviato: luned=EC 12 novembre 2012 17:51
A: draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org
Cc: ipfix@ietf.org
Oggetto: Fwd: secdir review of = draft-ietf-ipfix-flow-selection-tech

 

Dear authors,

Reading my old emails, I'm not sure that you took into account Dan's = feedback.
At the very minimum, you should give a reply

Regards, Benoit



-------- Original Message --------

Subject:

secdir review of = draft-ietf-ipfix-flow-selection-tech

Date: =

Tue, 10 Apr 2012 16:59:43 -0700 = (PDT)

From: =

Dan Harkins <dharkins@lounge.org><= /o:p>

To: =

iesg@ietf.org, secdir@ietf.org, d= raft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org

=

 

=A0 Hello,
 
=A0 I =
have reviewed this document as part of the security =
directorate's
ongoing effort to review all IETF =
documents being processed by the
IESG.=A0 These =
comments were written primarily for the benefit of =
the
security area directors.=A0 Document editors =
and WG chairs should treat
these comments just like =
any other last call =
comments.
 
=A0 This =
draft describes techniques to select flows which are sets =
of
packets with some common characteristics. The =
authors have accurately
identified what constitutes =
an attack-- an adversary having the ability
to =
influence flow selection-- and the Security Considerations =
give
a couple examples of this. They seem =
fine.
 
=A0 There is =
reference to a paper "[GoRe07]" which does not appear in =
the
References and seems to give advice that I =
think is wrong: use a strong
cryptographically =
strong random number generator to thwart an attack =
in
which parameters of time-based sampling are =
discovered to predict the
selection decision. This =
attack can be thwarted by using a value that
the =
adversary cannot predict (sort of like an IV for CBC mode) =
instead
of a cryptographically strong random =
number. That leaves the random
number pool to =
applications that really need it (like a key =
exchange
that does a Diffie-Hellman). I suggest =
removing the reference to the
un-referenced paper =
and mention a weaker requirement to thwart =
that
attack.
 <=
/pre>
=A0 =
regards,
 
=A0 =
Dan.
 
 
 



 

 

Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.2221 / Database dei virus: 2441/5390 - Data di = rilascio: 12/11/2012

------=_NextPart_000_003E_01CDC24C.9A943680-- From andrewf@plixer.com Wed Nov 14 14:38:41 2012 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 6769321F8849 for ; Wed, 14 Nov 2012 14:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6] 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 iBtGnVRiA+QY for ; Wed, 14 Nov 2012 14:38:40 -0800 (PST) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id D220F21F8847 for ; Wed, 14 Nov 2012 14:38:39 -0800 (PST) Received: from [10.100.1.132] ([10.100.1.132]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Nov 2012 17:38:38 -0500 Message-ID: <50A41D6E.9070201@plixer.com> Date: Wed, 14 Nov 2012 17:38:38 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/19.0 Thunderbird/19.0a1 MIME-Version: 1.0 To: Paul Aitken References: <50868CB1.3080107@cisco.com> <2EC7CC46-B95E-47E5-8387-DA79F3937B80@tik.ee.ethz.ch> <50869BDC.3070708@plixer.com> <5086A0C5.10202@cisco.com> In-Reply-To: <5086A0C5.10202@cisco.com> Content-Type: multipart/alternative; boundary="------------000405020404090504030508" X-OriginalArrivalTime: 14 Nov 2012 22:38:38.0538 (UTC) FILETIME=[CA2DC2A0:01CDC2B8] Cc: ipfix@ietf.org Subject: Re: [IPFIX] "ID" in Information Element names 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, 14 Nov 2012 22:38:41 -0000 This is a multi-part message in MIME format. --------------000405020404090504030508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Paul, It occurs to me that if well known names keep their case then there is a case for using "AS" in 16 bgpSourceAsNumber unsigned32 identifier current The autonomous system (AS) number of the source IP address. If AS path information for this Flow is only available as an unordered AS set (and not as an ordered AS sequence), then the value of this Information Element is 0. See [RFC4271 ] for a description of BGP-4, and see [RFC1930 ] for the definition of the AS number. [RFC5102 ] 17 bgpDestinationAsNumber unsigned32 identifier current The autonomous system (AS) number of the destination IP address. If AS path information for this Flow is only available as an unordered AS set (and not as an ordered AS sequence), then the value of this Information Element is 0. See [RFC4271 ] for a description of BGP-4, and see [RFC1930 ] for the definition of the AS number. [RFC5102 ] and 128 bgpNextAdjacentAsNumber unsigned32 identifier current The autonomous system (AS) number of the first AS in the AS path to the destination IP address. The path is deduced by looking up the destination IP address of the Flow in the BGP routing information base. If AS path information for this Flow is only available as an unordered AS set (and not as an ordered AS sequence), then the value of this Information Element is 0. See [RFC4271 ] for a description of BGP-4, and see [RFC1930 ] for the definition of the AS number. [RFC5102 ] 129 bgpPrevAdjacentAsNumber unsigned32 identifier current The autonomous system (AS) number of the last AS in the AS path from the source IP address. The path is deduced by looking up the source IP address of the Flow in the BGP routing information base. If AS path information for this Flow is only available as an unordered AS set (and not as an ordered AS sequence), then the value of this Information Element is 0. In case of BGP asymmetry, the bgpPrevAdjacentAsNumber might not be able to report the correct value. See [RFC4271 ] for a description of BGP-4, and see [RFC1930 ] for the definition of the AS number. [RFC5102 ] The uppercase version is used in the description. Just thinking, -Andrew On 10/23/2012 09:51 AM, Paul Aitken wrote: > Thanks Brian and Andrew. > > I've asked IANA to rename "applicationId" and "natPoolId" for > consistency with the other fields. > > I'll leave wlanSSID, ingressVRFID, egressVRFID, and virtualStationUUID > unchanged. > > P. > > > On 23/10/12 14:30, Andrew Feren wrote: >> Hi Paul and Brian, >> >> I agree on renaming applicationId and natPoolId and keeping UUID. >> >> My personal bias is to also keep VRFID, but I can't claim any >> evidence that is an established term. I just prefer to keep it upper >> case, but I won't object either way. >> >> -Andrew >> >> >> On 10/23/2012 08:43 AM, Brian Trammell wrote: >>> Hi, Paul, >>> >>> UUID is an established term too, no? So we should keep that as is. >>> >>> Not sure about VRF. >>> >>> I'd rename applicationId and natPoolId. >>> >>> Cheers, >>> >>> Brian >>> >>> On Oct 23, 2012, at 2:25 PM, Paul Aitken wrote: >>> >>>> I've just been looking at how inconsistently "ID" and "Id" are used >>>> for IE names. >>>> >>>> Since the bulk of the existing names are "...Id", can we assume >>>> that the following are all good: >>>> >>>> vlanId >>>> postVlanId >>>> classificationEngineId >>>> commonPropertiesId >>>> observationPointId >>>> lineCardId >>>> portId >>>> meteringProcessId >>>> exportingProcessId >>>> templateId >>>> wlanChannelId >>>> flowId >>>> observationDomainId >>>> dot1qVlanId >>>> dot1qCustomerVlanId >>>> metroEvcId >>>> pseudoWireId >>>> postDot1qVlanId >>>> postDot1qCustomerVlanId >>>> exportSctpStreamId >>>> connectionTransactionId >>>> selectionSequenceId >>>> selectorId >>>> informationElementId >>>> virtualStationInterfaceId >>>> layer2SegmentId >>>> >>>> >>>> And that the following should change? : >>>> >>>> applicationID -> applicationId >>>> natPoolID -> natPoolId >>>> >>>> >>>> Finally, I'm not sure about the following: >>>> >>>> wlanSSID -> "SSID"seems to be an established term. >>>> ingressVRFID -> should it be "VRFId" ? >>>> egressVRFID -> should it be "VRFId" ? >>>> virtualStationUUID ->should it be "UUId" ? >>>> >>>> >>>> >>>> Feedback? >>>> >>>> Thanks, >>>> P. >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 --------------000405020404090504030508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Paul,

It occurs to me that if well known names keep their case then there is a case for using "AS" in

16 bgpSourceAsNumber unsigned32 identifier current

The autonomous system (AS) number of the source IP address. If AS path information for this Flow is only available as an unordered AS set (and not as an ordered AS sequence), then the value of this Information Element is 0.

See [RFC4271] for a description of BGP-4, and see [RFC1930] for the definition of the AS number.

 [RFC5102]
17 bgpDestinationAsNumber unsigned32 identifier current

The autonomous system (AS) number of the destination IP address. If AS path information for this Flow is only available as an unordered AS set (and not as an ordered AS sequence), then the value of this Information Element is 0.

See [RFC4271] for a description of BGP-4, and see [RFC1930] for the definition of the AS number.

 [RFC5102]
and

128 bgpNextAdjacentAsNumber unsigned32 identifier current

The autonomous system (AS) number of the first AS in the AS path to the destination IP address. The path is deduced by looking up the destination IP address of the Flow in the BGP routing information base. If AS path information for this Flow is only available as an unordered AS set (and not as an ordered AS sequence), then the value of this Information Element is 0.

See [RFC4271] for a description of BGP-4, and see [RFC1930] for the definition of the AS number.

 [RFC5102]
129 bgpPrevAdjacentAsNumber unsigned32 identifier current

The autonomous system (AS) number of the last AS in the AS path from the source IP address. The path is deduced by looking up the source IP address of the Flow in the BGP routing information base. If AS path information for this Flow is only available as an unordered AS set (and not as an ordered AS sequence), then the value of this Information Element is 0. In case of BGP asymmetry, the bgpPrevAdjacentAsNumber might not be able to report the correct value.

See [RFC4271] for a description of BGP-4, and see [RFC1930] for the definition of the AS number.

 [RFC5102]

The uppercase version is used in the description.

Just thinking,
-Andrew


On 10/23/2012 09:51 AM, Paul Aitken wrote:
Thanks Brian and Andrew.

I've asked IANA to rename "applicationId" and "natPoolId" for consistency with the other fields.

I'll leave wlanSSID, ingressVRFID, egressVRFID, and virtualStationUUID unchanged.

P.


On 23/10/12 14:30, Andrew Feren wrote:
Hi Paul and Brian,

I agree on renaming applicationId and natPoolId and keeping UUID.

My personal bias is to also keep VRFID, but I can't claim any evidence that is an established term.  I just prefer to keep it upper case, but I won't object either way.

-Andrew


On 10/23/2012 08:43 AM, Brian Trammell wrote:
Hi, Paul,

UUID is an established term too, no? So we should keep that as is.

Not sure about VRF.

I'd rename applicationId and natPoolId.

Cheers,

Brian

On Oct 23, 2012, at 2:25 PM, Paul Aitken <paitken@cisco.com> wrote:

I've just been looking at how inconsistently "ID" and "Id" are used for IE names.

Since the bulk of the existing names are "...Id", can we assume that the following are all good:

vlanId
postVlanId
classificationEngineId
commonPropertiesId
observationPointId
lineCardId
portId
meteringProcessId
exportingProcessId
templateId
wlanChannelId
flowId
observationDomainId
dot1qVlanId
dot1qCustomerVlanId
metroEvcId
pseudoWireId
postDot1qVlanId
postDot1qCustomerVlanId
exportSctpStreamId
connectionTransactionId
selectionSequenceId
selectorId
informationElementId
virtualStationInterfaceId
layer2SegmentId


And that the following should change? :

applicationID -> applicationId
natPoolID     -> natPoolId


Finally, I'm not sure about the following:

wlanSSID           -> "SSID"seems to be an established term.
ingressVRFID       -> should it be "VRFId" ?
egressVRFID        -> should it be "VRFId" ?
virtualStationUUID ->should it be "UUId" ?



Feedback?

Thanks,
P.
_______________________________________________
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

_______________________________________________
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

--------------000405020404090504030508-- From paitken@cisco.com Wed Nov 14 14:54:32 2012 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 5200421F886A for ; Wed, 14 Nov 2012 14:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.547 X-Spam-Level: X-Spam-Status: No, score=-11.547 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 QJforkLtKV+I for ; Wed, 14 Nov 2012 14:54:31 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 73DB321F8721 for ; Wed, 14 Nov 2012 14:54:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18837; q=dns/txt; s=iport; t=1352933670; x=1354143270; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=GxZ7HEa3STZI6osdkdSZ2Fg9waaFO1Xd/ohlqf9qLB0=; b=L93scAEf3v4EkVuaAFTyStKHblO9b2D+EMWwaa7MdYCnLhfr7BSBZYTa txbObKfJHtcZ6sQRe01uHBtVcHa5hTtWmymk9OWfddfm+rtXdyot/FU2v 0l9fCMd/bF+iBDOyJ9uFIZWC42e/m+2KKrhaHtjBKnst5FAVMB6fr0Xqr c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAFwgpFCQ/khR/2dsb2JhbABEgkmJM7dGgQiCHgEBAQQSAWUBEAsYCRYPCQMCAQIBRQYNAQcBAQUZh2mbMqANklkDlXyFa4htgWuCbw X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="9574512" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 14 Nov 2012 22:54:29 +0000 Received: from [10.55.89.94] (dhcp-10-55-89-94.cisco.com [10.55.89.94]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAEMsSwa011513; Wed, 14 Nov 2012 22:54:28 GMT Message-ID: <50A42124.8060609@cisco.com> Date: Wed, 14 Nov 2012 22:54:28 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Andrew Feren References: <50868CB1.3080107@cisco.com> <2EC7CC46-B95E-47E5-8387-DA79F3937B80@tik.ee.ethz.ch> <50869BDC.3070708@plixer.com> <5086A0C5.10202@cisco.com> <50A41D6E.9070201@plixer.com> In-Reply-To: <50A41D6E.9070201@plixer.com> Content-Type: multipart/alternative; boundary="------------060106030103020006090506" Cc: ipfix@ietf.org Subject: Re: [IPFIX] "ID" in Information Element names 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, 14 Nov 2012 22:54:32 -0000 This is a multi-part message in MIME format. --------------060106030103020006090506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andrew, I agree. There seems to be some inconsistency here. IPFIX-doctors says: o use capital letters for the first letter of each component except for the first one (aka "camel case"). All other letters are non- capitalized, even for acronyms. Exceptions are made for acronyms containing non-capitalized letters, such as 'IPv4' and 'IPv6'. Examples are "sourceMacAddress" and "destinationIPv4Address." So it seems that: "wlanSSID" should be "wlanSsid" "ingressVRFID should be "ingressVrfId" "egressVRFID should be "egressVrfId" "virtualStationUUID" should be "virtualStationUuid". - which all look wrong. Else, the IPFIX-doctors rule should be relaxed to allow the existing names. Or, it should allow reviewer discretion. Thanks, P. On 14/11/12 22:38, Andrew Feren wrote: > Hi Paul, > > It occurs to me that if well known names keep their case then there is > a case for using "AS" in > > 16 bgpSourceAsNumber unsigned32 identifier current > > The autonomous system (AS) number of the source IP address. If AS path > information for this Flow is only available as an unordered AS set > (and not as an ordered AS sequence), then the value of this > Information Element is 0. > > > > > > See [RFC4271 ] for a description of > BGP-4, and see [RFC1930 ] for the > definition of the AS number. > > [RFC5102 ] > 17 bgpDestinationAsNumber unsigned32 identifier current > > The autonomous system (AS) number of the destination IP address. If AS > path information for this Flow is only available as an unordered AS > set (and not as an ordered AS sequence), then the value of this > Information Element is 0. > > > > > > See [RFC4271 ] for a description of > BGP-4, and see [RFC1930 ] for the > definition of the AS number. > > [RFC5102 ] > > and > > 128 bgpNextAdjacentAsNumber unsigned32 identifier current > > The autonomous system (AS) number of the first AS in the AS path to > the destination IP address. The path is deduced by looking up the > destination IP address of the Flow in the BGP routing information > base. If AS path information for this Flow is only available as an > unordered AS set (and not as an ordered AS sequence), then the value > of this Information Element is 0. > > > > > > See [RFC4271 ] for a description of > BGP-4, and see [RFC1930 ] for the > definition of the AS number. > > [RFC5102 ] > 129 bgpPrevAdjacentAsNumber unsigned32 identifier current > > The autonomous system (AS) number of the last AS in the AS path from > the source IP address. The path is deduced by looking up the source IP > address of the Flow in the BGP routing information base. If AS path > information for this Flow is only available as an unordered AS set > (and not as an ordered AS sequence), then the value of this > Information Element is 0. In case of BGP asymmetry, the > bgpPrevAdjacentAsNumber might not be able to report the correct value. > > > > > > See [RFC4271 ] for a description of > BGP-4, and see [RFC1930 ] for the > definition of the AS number. > > [RFC5102 ] > > > The uppercase version is used in the description. > > Just thinking, > -Andrew --------------060106030103020006090506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Andrew,

I agree. There seems to be some inconsistency here.

IPFIX-doctors says:

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

So it seems that:

    "wlanSSID" should be "wlanSsid"
    "ingressVRFID should be "ingressVrfId"
    "egressVRFID should be "egressVrfId"
    "virtualStationUUID" should be "virtualStationUuid".

- which all look wrong.

Else, the IPFIX-doctors rule should be relaxed to allow the existing names. Or, it should allow reviewer discretion.

Thanks,
P.


On 14/11/12 22:38, Andrew Feren wrote:
Hi Paul,

It occurs to me that if well known names keep their case then there is a case for using "AS" in

16 bgpSourceAsNumber unsigned32 identifier current

The autonomous system (AS) number of the source IP address. If AS path information for this Flow is only available as an unordered AS set (and not as an ordered AS sequence), then the value of this Information Element is 0.

See [RFC4271] for a description of BGP-4, and see [RFC1930] for the definition of the AS number.

 [RFC5102]
17 bgpDestinationAsNumber unsigned32 identifier current

The autonomous system (AS) number of the destination IP address. If AS path information for this Flow is only available as an unordered AS set (and not as an ordered AS sequence), then the value of this Information Element is 0.

See [RFC4271] for a description of BGP-4, and see [RFC1930] for the definition of the AS number.

 [RFC5102]
and

128 bgpNextAdjacentAsNumber unsigned32 identifier current

The autonomous system (AS) number of the first AS in the AS path to the destination IP address. The path is deduced by looking up the destination IP address of the Flow in the BGP routing information base. If AS path information for this Flow is only available as an unordered AS set (and not as an ordered AS sequence), then the value of this Information Element is 0.

See [RFC4271] for a description of BGP-4, and see [RFC1930] for the definition of the AS number.

 [RFC5102]
129 bgpPrevAdjacentAsNumber unsigned32 identifier current

The autonomous system (AS) number of the last AS in the AS path from the source IP address. The path is deduced by looking up the source IP address of the Flow in the BGP routing information base. If AS path information for this Flow is only available as an unordered AS set (and not as an ordered AS sequence), then the value of this Information Element is 0. In case of BGP asymmetry, the bgpPrevAdjacentAsNumber might not be able to report the correct value.

See [RFC4271] for a description of BGP-4, and see [RFC1930] for the definition of the AS number.

 [RFC5102]

The uppercase version is used in the description.

Just thinking,
-Andrew

--------------060106030103020006090506-- From bclaise@cisco.com Mon Nov 19 08:14:30 2012 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 76A2921F84EA for ; Mon, 19 Nov 2012 08:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 gAcRPrK8yviV for ; Mon, 19 Nov 2012 08:14:27 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4EB21F849F for ; Mon, 19 Nov 2012 08:14:26 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAJGEOgq019818; Mon, 19 Nov 2012 17:14:24 +0100 (CET) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAJGENjG006005; Mon, 19 Nov 2012 17:14:23 +0100 (CET) Message-ID: <50AA5ADE.2010803@cisco.com> Date: Mon, 19 Nov 2012 17:14:22 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Salvatore D'Antonio" References: <4FC74398.50805@cisco.com> <4FC89B99.40107@cisco.com> <506DA106.5060705@cisco.com> <50904E1D.7060909@cisco.com> <007301cdbb66$c58d6a10$50a83e30$@dantonio@uniparthenope.it> <509BCC69.6020603@cisco.com> <003801cdc243$53a7b6b0$faf72410$@dantonio@uniparthenope.it> In-Reply-To: <003801cdc243$53a7b6b0$faf72410$@dantonio@uniparthenope.it> Content-Type: multipart/alternative; boundary="------------050408080801080208050105" Cc: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org, ipfix@ietf.org, ipfix-chairs@tools.ietf.org Subject: Re: [IPFIX] R: R: New AD review of draft-ietf-ipfix-flow-selection-tech-10.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: Mon, 19 Nov 2012 16:14:30 -0000 This is a multi-part message in MIME format. --------------050408080801080208050105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear Salvatore, Thanks for your feedback. I believe a new version is required, then a WG LC again Regards, Benoit > > Dear Benoit, > > My answers inline. > > *Da:*Benoit Claise [mailto:bclaise@cisco.com] > *Inviato:* giovedì 8 novembre 2012 16:15 > *A:* Salvatore D'Antonio > *Cc:* ipfix@ietf.org; > draft-ietf-ipfix-flow-selection-tech@tools.ietf.org; > ipfix-chairs@tools.ietf.org > *Oggetto:* Re: R: [IPFIX] New AD review of > draft-ietf-ipfix-flow-selection-tech-10.txt > > Dear Salvatore, > > I removed the comments on which we agree, for clarity. > > Dear Benoit, > > My comments to your comments inline. > > *Da:*Benoit Claise [mailto:bclaise@cisco.com] > *Inviato:* martedì 30 ottobre 2012 23:01 > *A:* ipfix@ietf.org ; > draft-ietf-ipfix-flow-selection-tech@tools.ietf.org > > *Cc:* ipfix-chairs@tools.ietf.org > *Oggetto:* Re: [IPFIX] New AD review of > draft-ietf-ipfix-flow-selection-tech-10.txt > > > > Intermediate Flow Selection Process: an Intermediate Process as in > > [RFC6183 ] that ... > > > > The new definition improved a lot: > > * Intermediate Flow Selection Process > > > > An Intermediate Flow Selection Process takes Flow Records as its > > input and selects a subset of this set as its output. > > Intermediate Flow Selection Process is a more general concept than > > Intermediate Selection Process as defined in [RFC6183 ]. While an > > Intermediate Selection Process selects Flow Records from a > > sequence based upon criteria-evaluated Flow record values and > > passes only those Flow Records that match the criteria, an > > Intermediate Flow Selection Process selects Flow Records using > > selection criteria applicable to a larger set of Flow > > characteristics and information. > > But is there a reason why this definition can't be based on > "intermediate Process" from RFC 6183: > > Intermediate Process > > > > An Intermediate Process takes a record stream as its input from > > Collecting Processes, Metering Processes, IPFIX File Readers, > > other Intermediate Processes, or other record sources; performs > > some transformations on this stream based upon the content of each > > record, states maintained across multiple records, or other data > > sources; and passes the transformed record stream as its output to > > Exporting Processes, IPFIX File Writers, or other Intermediate > > Processes in order to perform IPFIX Mediation. Typically, an > > Intermediate Process is hosted by an IPFIX Mediator. > > Alternatively, an Intermediate Process may be hosted by an > > Original Exporter. > > > > According to the definition of "Intermediate Process" from RFC 6183, such a process is typically hosted by an IPFIX Mediator. Alternatively, it may be hosted by an Original Exporter. In my view, an Intermediate Flow Selection Process could be also hosted by a Collector. > > Sure. Then the Collector becomes a Collector that contains a mediator > function. > I don't see the problem. > > Ok, it's clear to me now. I will modify the text of the definition > accordingly. > > Intermediate Process > > An Intermediate Process takes a record stream as its input from > _Collecting Processes_, Metering Processes, IPFIX File Readers, > other Intermediate Processes, > > > My concern if you use your definition is that it doesn't build on the > framework RFC 6183 > > > > So > > * Intermediate Flow Selection Process > > > > _ An Intermediate Flow Selection Process is an Intermediate Process as in_ > > _ [_RFC6183 _] that_ takes Flow Records as its > > input and selects a subset of this set as its output. > > Intermediate Flow Selection Process is a more general concept than > > Intermediate Selection Process as defined in [RFC6183 ]. While an > > Intermediate Selection Process selects Flow Records from a > > sequence based upon criteria-evaluated Flow record values and > > passes only those Flow Records that match the criteria, an > > Intermediate Flow Selection Process selects Flow Records using > > selection criteria applicable to a larger set of Flow > > characteristics and information. > > > > > > > > 4. Flow selection as a Function in the IPFIX Architecture > > Thanks for your new figure 1. > One editorial change: change the + in the left vertical line. > > Ok, will do. > > +======|========================+ | > > | | Mediator | | > > + +-V-------------------+ | | > > | | Collecting Process | | | > > + +---------------------+ | | > > | | Intermediate Flow | | | > > | | Selection Process | | | > > + +---------------------+ | | > > | | Exporting Process | | | > > + +-|-------------------+ | | > > +======|========================+ | > > > > > 5.1. Flow Filtering > > Flow Filtering is a deterministic function on the IPFIX > Flow Record > content. If the relevant flow characteristics are > already observable > at packet level (e.g. Flow Keys), Flow Filtering can > be applied > before aggregation at packet level. In order to be > compliant with > this document, at least the Property Match Filtering > MUST be > implemented. > > This contradicts. > > In order to be compliant with this document, at > > least one of the flow selection schemes MUST be implemented. > > Actually, wrong cut/paste. > This contradicts, in section 1: > > In order to be compliant with this document, at > > least the Property Match Filtering MUST be implemented. > > This comment is not clear to me. Both in Section 1 and in Section > 5.1 (Flow Filtering) I used the same sentence "In order to be > compliant with this document, at least the Property Match > Filtering MUST be implemented". > > Solved with version 12. > However, I'm wondering if the resolution is correct. > version 11: > > In order to be compliant with this document, at > least one of the flow selection schemes MUST be implemented. > > ... > > In order to be compliant with this document, at > least the Property Match Filtering MUST be implemented. > > > Version 12: > > In order to be compliant with this document, at > least the Property Match Filtering MUST be implemented. > > > Listing all the selection techniques, > > 5 . Flow Selection Techniques . . . . . . . . . . . . . . . . . .10 > 5.1 . Flow Filtering . . . . . . . . . . . . . . . . . . . . . .11 > 5.1.1 . Property Match Filtering . . . . . . . . . . . . . . .11 > 5.1.2 . Hash-based 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 Flow Selection . . . . . . . . . . .13 > 5.4 . Flow-state Dependent Packet Selection . . . . . . . . . .14 > > > It means that a device that implements Flow Sampling was compliant > with version 11 thanks to the sentence "In order to be compliant with > this document, at least one of the flow selection schemes MUST be > implemented" and is not compliant any longer with version 12 > It seems like an important change to me since the WGLC, on which the > WG must agree. > > I agree. A new WGLC is needed to have feedback on this change from the WG. > > Best regards, > > Salvatore > > > > Regards, Benoit > > > > > > > ------------------------------------------------------------------------ > > Nessun virus nel messaggio. > Controllato da AVG - www.avg.com > Versione: 2012.0.2221 / Database dei virus: 2441/5381 - Data di > rilascio: 07/11/2012 > --------------050408080801080208050105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear Salvatore,

Thanks for your feedback.
I believe a new version is required, then a WG LC again

Regards, Benoit

Dear Benoit,

 

My answers inline.

 

Da: Benoit Claise [mailto:bclaise@cisco.com]
Inviato: giovedì 8 novembre 2012 16:15
A: Salvatore D'Antonio
Cc: ipfix@ietf.org; draft-ietf-ipfix-flow-selection-tech@tools.ietf.org; ipfix-chairs@tools.ietf.org
Oggetto: Re: R: [IPFIX] New AD review of draft-ietf-ipfix-flow-selection-tech-10.txt

 

Dear Salvatore,

I removed the comments on which we agree, for clarity.

Dear Benoit,

 

My comments to your comments inline.

 

Da: Benoit Claise [mailto:bclaise@cisco.com]
Inviato: martedì 30 ottobre 2012 23:01
A: ipfix@ietf.org; draft-ietf-ipfix-flow-selection-tech@tools.ietf.org
Cc: ipfix-chairs@tools.ietf.org
Oggetto: Re: [IPFIX] New AD review of draft-ietf-ipfix-flow-selection-tech-10.txt

 

 



Intermediate Flow Selection Process: an Intermediate Process as in
      [RFC6183] that ...
 

 

The new definition improved a lot:

 * Intermediate Flow Selection Process
 
      An Intermediate Flow Selection Process takes Flow Records as its
      input and selects a subset of this set as its output.
      Intermediate Flow Selection Process is a more general concept than
      Intermediate Selection Process as defined in [RFC6183].  While an
      Intermediate Selection Process selects Flow Records from a
      sequence based upon criteria-evaluated Flow record values and
      passes only those Flow Records that match the criteria, an
      Intermediate Flow Selection Process selects Flow Records using
      selection criteria applicable to a larger set of Flow
      characteristics and information.

But is there a reason why this definition can't be based on "intermediate Process" from RFC 6183:

Intermediate Process
 
      An Intermediate Process takes a record stream as its input from
      Collecting Processes, Metering Processes, IPFIX File Readers,
      other Intermediate Processes, or other record sources; performs
      some transformations on this stream based upon the content of each
      record, states maintained across multiple records, or other data
      sources; and passes the transformed record stream as its output to
      Exporting Processes, IPFIX File Writers, or other Intermediate
      Processes in order to perform IPFIX Mediation.  Typically, an
      Intermediate Process is hosted by an IPFIX Mediator.
      Alternatively, an Intermediate Process may be hosted by an
      Original Exporter.
 
According to the definition of “Intermediate Process” from RFC 6183, such a process is typically hosted by an IPFIX Mediator. Alternatively, it may be hosted by an Original Exporter. In my view, an Intermediate Flow Selection Process could be also hosted by a Collector.

Sure. Then the Collector becomes a Collector that contains a mediator function.
I don't see the problem.

 

Ok, it’s clear to me now. I will modify the text of the definition accordingly.

 

   Intermediate Process
 
      An Intermediate Process takes a record stream as its input from
      Collecting Processes, Metering Processes, IPFIX File Readers,
      other Intermediate Processes,


My concern if you use your definition is that it doesn't build on the framework RFC 6183

 

So 

 * Intermediate Flow Selection Process
 
      An Intermediate Flow Selection Process is an Intermediate Process as in
      [RFC6183] that takes Flow Records as its
      input and selects a subset of this set as its output.
      Intermediate Flow Selection Process is a more general concept than
      Intermediate Selection Process as defined in [RFC6183].  While an
      Intermediate Selection Process selects Flow Records from a
      sequence based upon criteria-evaluated Flow record values and
      passes only those Flow Records that match the criteria, an
      Intermediate Flow Selection Process selects Flow Records using
      selection criteria applicable to a larger set of Flow
      characteristics and information.




 




4.  Flow selection as a Function in the IPFIX Architecture
  

Thanks for your new figure 1.
One editorial change: change the + in the left vertical line.

Ok, will do.

      +======|========================+      |
      |      |  Mediator              |      |
      +    +-V-------------------+    |      |
      |    | Collecting Process  |    |      |
      +    +---------------------+    |      |
      |    | Intermediate Flow   |    |      |
      |    | Selection Process   |    |      |
      +    +---------------------+    |      |
      |    |  Exporting Process  |    |      |
      +    +-|-------------------+    |      |
      +======|========================+      |
     


5.1.  Flow Filtering

   Flow Filtering is a deterministic function on the IPFIX Flow Record
   content.  If the relevant flow characteristics are already observable
   at packet level (e.g.  Flow Keys), Flow Filtering can be applied
   before aggregation at packet level.  In order to be compliant with
   this document, at least the Property Match Filtering MUST be
   implemented.

This contradicts.

   In order to be compliant with this document, at
   least one of the flow selection schemes MUST be implemented.

Actually, wrong cut/paste.
This contradicts, in section 1:

   In order to be compliant with this document, at
   least the Property Match Filtering MUST be implemented.

 

This comment is not clear to me. Both in Section 1 and in Section 5.1 (Flow Filtering) I used the same sentence “In order to be compliant with this document, at least the Property Match Filtering MUST be implemented”.

 

Solved with version 12.
However, I'm wondering if the resolution is correct.
version 11:
       

   In order to be compliant with this document, at
   least one of the flow selection schemes MUST be implemented. 
 
   ...
 
   In order to be compliant with this document, at
   least the Property Match Filtering MUST be implemented.


Version 12:

    In order to be compliant with this document, at
   least the Property Match Filtering MUST be implemented.


Listing all the selection techniques, 

   5.  Flow Selection Techniques  . . . . . . . . . . . . . . . . . . 10
     5.1.  Flow Filtering . . . . . . . . . . . . . . . . . . . . . . 11
       5.1.1.  Property Match Filtering . . . . . . . . . . . . . . . 11
       5.1.2.  Hash-based 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 Flow Selection  . . . . . . . . . . . 13
     5.4.  Flow-state Dependent Packet Selection  . . . . . . . . . . 14


It means that a device that implements Flow Sampling was compliant with version 11 thanks to the sentence "In order to be compliant with this document, at least one of the flow selection schemes MUST be implemented" and is not compliant any longer with version 12
It seems like an important change to me since the WGLC, on which the WG must agree.

 

I agree. A new WGLC is needed to have feedback on this change from the WG.

 

Best regards,

 

Salvatore



Regards, Benoit






 

 

Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.2221 / Database dei virus: 2441/5381 - Data di rilascio: 07/11/2012


--------------050408080801080208050105-- From internet-drafts@ietf.org Mon Nov 19 11:18:35 2012 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 17A5D21F86EB; Mon, 19 Nov 2012 11:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 Yv-TqHUORQ5C; Mon, 19 Nov 2012 11:18:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCDE21F8425; Mon, 19 Nov 2012 11:18:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121119191834.9520.597.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2012 11:18:34 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-a9n-08.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: Mon, 19 Nov 2012 19:18:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Flow Aggregation for the IP Flow Information Export (IPF= IX) Protocol Author(s) : Brian Trammell Arno Wagner Benoit Claise Filename : draft-ietf-ipfix-a9n-08.txt Pages : 57 Date : 2012-11-19 Abstract: This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export (IPFIX) Protocol to the handling of Aggregated Flows, which are IPFIX Flows representing packets from multiple Original Flows sharing some set of common properties. It does this through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-a9n There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-a9n-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-a9n-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Nov 20 02:11:25 2012 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 D5B0121F879E; Tue, 20 Nov 2012 02:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 XFYSeXDRdtkh; Tue, 20 Nov 2012 02:11:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6601421F8510; Tue, 20 Nov 2012 02:11:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121120101125.7618.74310.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2012 02:11:25 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-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: Tue, 20 Nov 2012 10:11:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Specification of the IP Flow Information eXport (IPFIX) = Protocol for the Exchange of Flow Information Author(s) : Benoit Claise Brian Trammell Filename : draft-ietf-ipfix-protocol-rfc5101bis-03.txt Pages : 68 Date : 2012-11-20 Abstract: This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-protocol-rfc5101bis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Nov 20 02:11:33 2012 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 72CFB21F87EE; Tue, 20 Nov 2012 02:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 cUL0rd4zjZfK; Tue, 20 Nov 2012 02:11:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11FB21F87AC; Tue, 20 Nov 2012 02:11:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121120101132.21471.27662.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2012 02:11:32 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-information-model-rfc5102bis-07.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, 20 Nov 2012 10:11:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Information Model for IP Flow Information eXport (IPFIX) Author(s) : Benoit Claise Brian Trammell Filename : draft-ietf-ipfix-information-model-rfc5102bis-07.txt Pages : 22 Date : 2012-11-20 Abstract: This document provides an overview of the information model for the IP Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX Information Element Registry. It is used by the IPFIX Protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX Protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. This document obsoletes RFC 5102. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc5102= bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-information-model-rfc5102bis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-information-model-rfc51= 02bis-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Tue Nov 20 02:15:52 2012 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 E6A3921F8578 for ; Tue, 20 Nov 2012 02:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.832 X-Spam-Level: X-Spam-Status: No, score=-6.832 tagged_above=-999 required=5 tests=[AWL=-0.233, 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 QdxY-fwBHQjM for ; Tue, 20 Nov 2012 02:15:52 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 45EF421F856B for ; Tue, 20 Nov 2012 02:15:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3A8CCD9309 for ; Tue, 20 Nov 2012 11:15:51 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mWbHLmJv1Xyb for ; Tue, 20 Nov 2012 11:15:50 +0100 (MET) 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 D90BBD9307 for ; Tue, 20 Nov 2012 11:15:50 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Nov 2012 11:15:50 +0100 References: <20121120101125.7618.56952.idtracker@ietfa.amsl.com> To: IPFIX Working Group Message-Id: Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-protocol-rfc5101bis-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: Tue, 20 Nov 2012 10:15:53 -0000 Greetings, all, This revision of RFC5101bis handles all pending open issues on the = document, per discussion in Atlanta and on the list regarding = interoperability testing and clarifications on network byte order. We = believe this revision to be ready for WGLC. Best regards, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-ipfix-protocol-rfc5101bis-03.txt > Date: 20 November 2012 11:11:25 GMT+01:00 > To: trammell@tik.ee.ethz.ch > Cc: bclaise@cisco.com >=20 >=20 > A new version of I-D, draft-ietf-ipfix-protocol-rfc5101bis-03.txt > has been successfully submitted by Brian Trammell and posted to the > IETF repository. >=20 > Filename: draft-ietf-ipfix-protocol-rfc5101bis > Revision: 03 > Title: Specification of the IP Flow Information eXport = (IPFIX) Protocol for the Exchange of Flow Information > Creation date: 2012-11-20 > WG ID: ipfix > Number of pages: 68 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-rfc5101bis-0= 3.txt > Status: = http://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis > Htmlized: = http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-03 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-protocol-rfc5101bis-03= >=20 > Abstract: > This document specifies the IP Flow Information Export (IPFIX) > protocol that serves for transmitting Traffic Flow information over > the network. In order to transmit Traffic Flow information from an > Exporting Process to an information Collecting Process, a common > representation of flow data and a standard means of communicating > them is required. This document describes how the IPFIX Data and > Template Records are carried over a number of transport protocols > from an IPFIX Exporting Process to an IPFIX Collecting Process. = This > document obsoletes RFC 5101. >=20 >=20 >=20 >=20 > The IETF Secretariat From trammell@tik.ee.ethz.ch Tue Nov 20 02:18:05 2012 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 0907C21F857C for ; Tue, 20 Nov 2012 02:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.774 X-Spam-Level: X-Spam-Status: No, score=-6.774 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 wFlDxak+T3hW for ; Tue, 20 Nov 2012 02:18:04 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7DF21F8578 for ; Tue, 20 Nov 2012 02:18:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 41E68D930D for ; Tue, 20 Nov 2012 11:18:03 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9JfmcdEti5W2 for ; Tue, 20 Nov 2012 11:18:03 +0100 (MET) 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 073F0D9307 for ; Tue, 20 Nov 2012 11:18:03 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Nov 2012 11:18:02 +0100 References: <20121120101133.21471.95642.idtracker@ietfa.amsl.com> To: IPFIX Working Group Message-Id: <4FE50D4C-FCD5-49CD-BA87-E566FE34741C@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-information-model-rfc5102bis-07.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, 20 Nov 2012 10:18:05 -0000 Greetings, all, This revision of RFC5102bis handles all pending open issues on the = document after the WGLC that completed 22 October, including the removal = of most content on categorization from Section 5 per discussion in = Atlanta. We believe this revision to be ready for AD review. Best regards, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-ipfix-information-model-rfc5102bis-07.txt > Date: 20 November 2012 11:11:33 GMT+01:00 > To: trammell@tik.ee.ethz.ch > Cc: bclaise@cisco.com >=20 >=20 > A new version of I-D, = draft-ietf-ipfix-information-model-rfc5102bis-07.txt > has been successfully submitted by Brian Trammell and posted to the > IETF repository. >=20 > Filename: draft-ietf-ipfix-information-model-rfc5102bis > Revision: 07 > Title: Information Model for IP Flow Information = eXport (IPFIX) > Creation date: 2012-11-20 > WG ID: ipfix > Number of pages: 22 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-ipfix-information-model-rfc= 5102bis-07.txt > Status: = http://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc5102= bis > Htmlized: = http://tools.ietf.org/html/draft-ietf-ipfix-information-model-rfc5102bis-0= 7 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-information-model-rfc5= 102bis-07 >=20 > Abstract: > This document provides an overview of the information model for the IP > Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX > Information Element Registry. It is used by the IPFIX Protocol for > encoding measured traffic information and information related to the > traffic Observation Point, the traffic Metering Process, and the > Exporting Process. Although developed for the IPFIX Protocol, the = model > is defined in an open way that easily allows using it in other > protocols, interfaces, and applications. This document obsoletes RFC > 5102. >=20 >=20 >=20 >=20 > The IETF Secretariat From trammell@tik.ee.ethz.ch Tue Nov 20 02:19:12 2012 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 6027821F872A for ; Tue, 20 Nov 2012 02:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.739 X-Spam-Level: X-Spam-Status: No, score=-6.739 tagged_above=-999 required=5 tests=[AWL=-0.140, 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 pr2qd-yZ7Pnq for ; Tue, 20 Nov 2012 02:19:11 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C016221F87B6 for ; Tue, 20 Nov 2012 02:19:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 262CDD930B for ; Tue, 20 Nov 2012 11:19:11 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0CZ2ds2K2lwo for ; Tue, 20 Nov 2012 11:19:10 +0100 (MET) 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 DA99CD9307 for ; Tue, 20 Nov 2012 11:19:10 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Nov 2012 11:19:10 +0100 References: <20121119191834.9520.1533.idtracker@ietfa.amsl.com> To: IPFIX Working Group Message-Id: <12A45DB3-5EA6-4EF9-8408-DC23B2C0DC6A@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-a9n-08.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, 20 Nov 2012 10:19:12 -0000 Greetings, all, FYI: this revision consolidates IESG COMMENTs and DISCUSSes on the = document. Best regards, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-ietf-ipfix-a9n-08.txt > Date: 19 November 2012 20:18:34 GMT+01:00 > To: trammell@tik.ee.ethz.ch > Cc: bclaise@cisco.com, arno@wagner.name >=20 >=20 > A new version of I-D, draft-ietf-ipfix-a9n-08.txt > has been successfully submitted by Brian Trammell and posted to the > IETF repository. >=20 > Filename: draft-ietf-ipfix-a9n > Revision: 08 > Title: Flow Aggregation for the IP Flow Information = Export (IPFIX) Protocol > Creation date: 2012-11-20 > WG ID: ipfix > Number of pages: 57 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-ipfix-a9n-08.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-ipfix-a9n > Htmlized: http://tools.ietf.org/html/draft-ietf-ipfix-a9n-08 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-a9n-08 >=20 > Abstract: > This document provides a common implementation-independent basis for > the interoperable application of the IP Flow Information Export > (IPFIX) Protocol to the handling of Aggregated Flows, which are = IPFIX > Flows representing packets from multiple Original Flows sharing some > set of common properties. It does this through a detailed > terminology and a descriptive Intermediate Aggregation Process > architecture, including a specification of methods for Original Flow > counting and counter distribution across intervals. >=20 >=20 >=20 >=20 > The IETF Secretariat From bclaise@cisco.com Thu Nov 22 06:23:39 2012 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 EB1CD21F8789 for ; Thu, 22 Nov 2012 06:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.485 X-Spam-Level: X-Spam-Status: No, score=-10.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 X5O+YGKw6vah for ; Thu, 22 Nov 2012 06:23:39 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB9D21F8743 for ; Thu, 22 Nov 2012 06:23:38 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAMENbSa022155; Thu, 22 Nov 2012 15:23:37 +0100 (CET) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAMENbaG001608; Thu, 22 Nov 2012 15:23:37 +0100 (CET) Message-ID: <50AE3569.8030009@cisco.com> Date: Thu, 22 Nov 2012 15:23:37 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ron Bonica Subject: [IPFIX] IPFIX document status 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, 22 Nov 2012 14:23:40 -0000 Dear all, I went through the following process for me. So let me share with the group. draft-ietf-ipfix-a9n-08 Normative Reference: [RFC5101bis] Informative Reference: [IPFX-MED-PROTO], [IE-DOCTORS], [IPFIX-FLOW-SEL] Status: passed the IESG, will be in the RFC-EDITOR soon draft-ietf-ipfix-ie-doctors-07 Normative Reference: [RFC5101bis], [RFC5102bis] Informative Reference: Status: one DISCUSS, waiting for rfc5102bis to go through the IESG draft-ietf-ipfix-protocol-rfc5101bis-03 Normative Reference: [RFC5102bis] Informative Reference: [IPFX-MED-PROTO] Status: ready for WGLC draft-ietf-ipfix-information-model-rfc5102bis-07 Normative Reference: [RFC5101bis], [IE-DOCTORS] Informative Reference: [IPFX-MED-PROTO] Status: ready for AD review draft-ietf-ipfix-flow-selection-tech-12 Normative Reference: Informative Reference: Status: waiting for the next version to pass the AD review Conclusions: 1. [RFC5101bis], [RFC5102bis], [IPFIX-A9N], and [IE-DOCTORS] have normative references to each others. So they will have to be published together. Out of these four, RFC5101 is the bottleneck. So WGLC should start soon 2. While [IPFX-MED-PROTO] is only an informative reference for some other documents, it would be great to progress this draft so that it could referred to in [RFC5101bis], [RFC5102bis], and [IPFIX-A9N] 3. [IPFIX-FLOW-SEL] doesn't have any reference dependencies. While [IPFIX-FLOW-SEL] is only informative a reference for some other documents, it would be great to progress this draft so that it could referred to in [RFC5101bis], [RFC5102bis], and [IPFIX-A9N] Regards, Benoit From bclaise@cisco.com Thu Nov 22 06:57:00 2012 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 595D221F855C for ; Thu, 22 Nov 2012 06:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.489 X-Spam-Level: X-Spam-Status: No, score=-10.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 3vMvgfijKCDX for ; Thu, 22 Nov 2012 06:56:59 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 69CA921F882F for ; Thu, 22 Nov 2012 06:56:59 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAMEujJQ026012; Thu, 22 Nov 2012 15:56:45 +0100 (CET) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAMEufVM028993; Thu, 22 Nov 2012 15:56:41 +0100 (CET) Message-ID: <50AE3D29.1050101@cisco.com> Date: Thu, 22 Nov 2012 15:56:41 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Liaison Statement Management Tool References: <20121114231447.28588.67908.idtracker@ietfa.amsl.com> In-Reply-To: <20121114231447.28588.67908.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Tony Jeffree , IP Flow Information Export Discussion List , Pat Thaler , Ronald Bonica , Nevil Brownlee , Eric Gray Subject: Re: [IPFIX] New Liaison Statement, "IPFIX WG Liaison Statement to the IEEE 802.1 WG about Data-link Information Elements" 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, 22 Nov 2012 14:57:00 -0000 Dear all, We didn't receive any IEEE feedback regarding this draft, did we? No news means good news? Regards, Benoit > Title: IPFIX WG Liaison Statement to the IEEE 802.1 WG about Data-link Information Elements > Submission Date: 2012-11-05 > URL of the IETF Web page: http://datatracker.ietf.org/liaison/1216/ > Please reply by 2012-11-19 > From: IP Flow Information Export (Eric Gray ) > To: IEEE 802.1 (Tony Jeffree ) > Cc: Eric Gray ,Nevil Brownlee ,Juergen Quittek ,Ronald Bonica ,Benoit Claise ,IP Flow Information Export Discussion List ,Pat Thaler ,Dan Romascanu > Reponse Contact: > Technical Contact: > Purpose: For comment > > Body: > Attachments: > > IPFIX WG Liaison Statement to the IEEE 802.1 WG about Data-link Information Elements > https://datatracker.ietf.org/documents/LIAISON/liaison-2012-11-05-ipfix-ieee-8021-ipfix-wg-liaison-statement-to-the-ieee-8021-wg-about-data-link-information-elements-attachment-1.txt > > > From bclaise@cisco.com Thu Nov 22 07:26:08 2012 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 66C8621F891D for ; Thu, 22 Nov 2012 07:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 tDEmuYo+cFxn for ; Thu, 22 Nov 2012 07:26:07 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7223721F8919 for ; Thu, 22 Nov 2012 07:26:07 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAMFPRa6029099; Thu, 22 Nov 2012 16:25:27 +0100 (CET) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAMFPOWx021406; Thu, 22 Nov 2012 16:25:24 +0100 (CET) Message-ID: <50AE43E4.9060408@cisco.com> Date: Thu, 22 Nov 2012 16:25:24 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: tony@jeffree.co.uk References: <20121114231447.28588.67908.idtracker@ietfa.amsl.com> <50AE3D29.1050101@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070106000704020604080108" Cc: Liaison Statement Management Tool , IP Flow Information Export Discussion List , Pat Thaler , Ronald Bonica , Nevil Brownlee , Eric Gray Subject: Re: [IPFIX] New Liaison Statement, "IPFIX WG Liaison Statement to the IEEE 802.1 WG about Data-link Information Elements" 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, 22 Nov 2012 15:26:08 -0000 This is a multi-part message in MIME format. --------------070106000704020604080108 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear Tony, Thanks for the answer. Surely a problem on our side regarding the dates. How long do you need to collect the WG feedback? Regards, Benoit > Dear Benoit - > > I didn't receive it until after the stated deadline. I have circulated > it to the 802.1 WG for individuals to comment on as they see fit, but > we haven't developed a response from the working group itself. > > Regards, > Tony > > > > On 22 November 2012 14:56, Benoit Claise > wrote: > > Dear all, > > We didn't receive any IEEE feedback regarding this draft, did we? > No news means good news? > > Regards, Benoit > > Title: IPFIX WG Liaison Statement to the IEEE 802.1 WG about > Data-link Information Elements > Submission Date: 2012-11-05 > URL of the IETF Web page: > http://datatracker.ietf.org/liaison/1216/ > Please reply by 2012-11-19 > From: IP Flow Information Export (Eric Gray > ) > To: IEEE 802.1 (Tony Jeffree >) > Cc: Eric Gray ,Nevil Brownlee > >,Juergen Quittek > >,Ronald Bonica > >,Benoit > Claise >,IP Flow > Information Export Discussion List >,Pat Thaler >,Dan Romascanu > > > Reponse Contact: > Technical Contact: > Purpose: For comment > > Body: > Attachments: > > IPFIX WG Liaison Statement to the IEEE 802.1 WG about > Data-link Information Elements > https://datatracker.ietf.org/documents/LIAISON/liaison-2012-11-05-ipfix-ieee-8021-ipfix-wg-liaison-statement-to-the-ieee-8021-wg-about-data-link-information-elements-attachment-1.txt > > > > > --------------070106000704020604080108 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Dear Tony,

Thanks for the answer.
Surely a problem on our side regarding the dates.
How long do you need to collect the WG feedback?

Regards, Benoit
Dear Benoit -

I didn't receive it until after the stated deadline. I have circulated it to the 802.1 WG for individuals to comment on as they see fit, but we haven't developed a response from the working group itself.

Regards,
Tony



On 22 November 2012 14:56, Benoit Claise <bclaise@cisco.com> wrote:
Dear all,

We didn't receive any IEEE feedback regarding this draft, did we?
No news means good news?

Regards, Benoit

Title: IPFIX WG Liaison Statement to the IEEE 802.1 WG about Data-link Information Elements
Submission Date: 2012-11-05
URL of the IETF Web page: http://datatracker.ietf.org/liaison/1216/
Please reply by 2012-11-19
From: IP Flow Information Export (Eric Gray <Eric.Gray@Ericsson.com>)
To: IEEE 802.1 (Tony Jeffree <tony@jeffree.co.uk>)
Cc: Eric Gray <Eric.Gray@Ericsson.com>,Nevil Brownlee <n.brownlee@auckland.ac.nz>,Juergen Quittek <quittek@neclab.eu>,Ronald Bonica <rbonica@juniper.net>,Benoit Claise <bclaise@cisco.com>,IP Flow Information Export Discussion List <ipfix@ietf.org>,Pat Thaler <pthaler@broadcom.com>,Dan Romascanu <dromasca@avaya.com>
Reponse Contact:
Technical Contact:
Purpose: For comment

Body:
Attachments:

     IPFIX WG Liaison Statement to the IEEE 802.1 WG about Data-link Information Elements
     https://datatracker.ietf.org/documents/LIAISON/liaison-2012-11-05-ipfix-ieee-8021-ipfix-wg-liaison-statement-to-the-ieee-8021-wg-about-data-link-information-elements-attachment-1.txt






--------------070106000704020604080108-- From bclaise@cisco.com Thu Nov 22 09:50:31 2012 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 83AEC21F865E for ; Thu, 22 Nov 2012 09:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.04 X-Spam-Level: X-Spam-Status: No, score=-10.04 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 OvkAEGorxM3N for ; Thu, 22 Nov 2012 09:50:30 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 05FA821F8654 for ; Thu, 22 Nov 2012 09:50:29 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAMHeExv012209; Thu, 22 Nov 2012 18:40:15 +0100 (CET) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAMHeCca021422; Thu, 22 Nov 2012 18:40:12 +0100 (CET) Message-ID: <50AE637D.2060006@cisco.com> Date: Thu, 22 Nov 2012 18:40:13 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: tony@jeffree.co.uk References: <20121114231447.28588.67908.idtracker@ietfa.amsl.com> <50AE3D29.1050101@cisco.com> <50AE43E4.9060408@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010809000005070007070908" Cc: Liaison Statement Management Tool , IP Flow Information Export Discussion List , Pat Thaler , Ronald Bonica , Nevil Brownlee , Eric Gray Subject: Re: [IPFIX] New Liaison Statement, "IPFIX WG Liaison Statement to the IEEE 802.1 WG about Data-link Information Elements" 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, 22 Nov 2012 17:50:31 -0000 This is a multi-part message in MIME format. --------------010809000005070007070908 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear IEEE members, Since apparently, there was a mistake with the dates in liaison statement (I'll take the blame for this), please provide your feedback, directly to the IPFIX WG, by the end of next week. That is Nov 30th Regards, Benoit > Dear Benoit > > The intent was for individuals to comment directly rather than for me > to collect feedback. > > Regards, > Tony > > > > On 22 November 2012 15:25, Benoit Claise > wrote: > > Dear Tony, > > Thanks for the answer. > Surely a problem on our side regarding the dates. > How long do you need to collect the WG feedback? > > Regards, Benoit >> Dear Benoit - >> >> I didn't receive it until after the stated deadline. I have >> circulated it to the 802.1 WG for individuals to comment on as >> they see fit, but we haven't developed a response from the >> working group itself. >> >> Regards, >> Tony >> >> >> >> On 22 November 2012 14:56, Benoit Claise > > wrote: >> >> Dear all, >> >> We didn't receive any IEEE feedback regarding this draft, did we? >> No news means good news? >> >> Regards, Benoit >> >> Title: IPFIX WG Liaison Statement to the IEEE 802.1 WG >> about Data-link Information Elements >> Submission Date: 2012-11-05 >> URL of the IETF Web page: >> http://datatracker.ietf.org/liaison/1216/ >> Please reply by 2012-11-19 >> From: IP Flow Information Export (Eric Gray >> ) >> To: IEEE 802.1 (Tony Jeffree > >) >> Cc: Eric Gray >> ,Nevil Brownlee >> > >,Juergen Quittek >> >,Ronald >> Bonica > >,Benoit Claise >> >,IP Flow >> Information Export Discussion List > >,Pat Thaler > >,Dan Romascanu >> > >> Reponse Contact: >> Technical Contact: >> Purpose: For comment >> >> Body: >> Attachments: >> >> IPFIX WG Liaison Statement to the IEEE 802.1 WG >> about Data-link Information Elements >> https://datatracker.ietf.org/documents/LIAISON/liaison-2012-11-05-ipfix-ieee-8021-ipfix-wg-liaison-statement-to-the-ieee-8021-wg-about-data-link-information-elements-attachment-1.txt >> >> >> >> >> > > --------------010809000005070007070908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Dear IEEE members,

Since apparently, there was a mistake with the dates in liaison statement (I'll take the blame for this), please provide your feedback, directly to the IPFIX WG, by the end of next week.
That is Nov 30th

Regards, Benoit
Dear Benoit

The intent was for individuals to comment directly rather than for me to collect feedback.

Regards,
Tony



On 22 November 2012 15:25, Benoit Claise <bclaise@cisco.com> wrote:
Dear Tony,

Thanks for the answer.
Surely a problem on our side regarding the dates.
How long do you need to collect the WG feedback?

Regards, Benoit
Dear Benoit -

I didn't receive it until after the stated deadline. I have circulated it to the 802.1 WG for individuals to comment on as they see fit, but we haven't developed a response from the working group itself.

Regards,
Tony



On 22 November 2012 14:56, Benoit Claise <bclaise@cisco.com> wrote:
Dear all,

We didn't receive any IEEE feedback regarding this draft, did we?
No news means good news?

Regards, Benoit

Title: IPFIX WG Liaison Statement to the IEEE 802.1 WG about Data-link Information Elements
Submission Date: 2012-11-05
URL of the IETF Web page: http://datatracker.ietf.org/liaison/1216/
Please reply by 2012-11-19
From: IP Flow Information Export (Eric Gray <Eric.Gray@Ericsson.com>)
To: IEEE 802.1 (Tony Jeffree <tony@jeffree.co.uk>)
Cc: Eric Gray <Eric.Gray@Ericsson.com>,Nevil Brownlee <n.brownlee@auckland.ac.nz>,Juergen Quittek <quittek@neclab.eu>,Ronald Bonica <rbonica@juniper.net>,Benoit Claise <bclaise@cisco.com>,IP Flow Information Export Discussion List <ipfix@ietf.org>,Pat Thaler <pthaler@broadcom.com>,Dan Romascanu <dromasca@avaya.com>
Reponse Contact:
Technical Contact:
Purpose: For comment

Body:
Attachments:

     IPFIX WG Liaison Statement to the IEEE 802.1 WG about Data-link Information Elements
     https://datatracker.ietf.org/documents/LIAISON/liaison-2012-11-05-ipfix-ieee-8021-ipfix-wg-liaison-statement-to-the-ieee-8021-wg-about-data-link-information-elements-attachment-1.txt








--------------010809000005070007070908-- From tonyjeffree@googlemail.com Thu Nov 22 07:15:25 2012 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 5616A21F8906 for ; Thu, 22 Nov 2012 07:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 CfbxvGAWb0Zd for ; Thu, 22 Nov 2012 07:15:24 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1815521F89F2 for ; Thu, 22 Nov 2012 07:15:23 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so2770985eaa.31 for ; Thu, 22 Nov 2012 07:15:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yGMTZfDaZuXbpfqxMuFOX8vmNqYFFRk5eYeRZwKxYaM=; b=pP0CQD0FHyQ4rN3F5F3YVWdrIkNzK9yzpk6ww30vrKAuhUGfv0kIzFzf6YI9UUlZaR UCaHgGhA1GJBk8TadLRRja6xoeYEXkc+TnpDL/55J+oP3YSLOretm5MMgUb+GdFgiBA1 iR1YD+kJDFqerZtoYLCVtLHAFFAtnt3bQRE4UNx6b08GBeto5ThLVsM6kxGtvSZU4SzF UaxCArd42bPFa5Cn2gF47zwZNMcxIx7aSoKYg8f99ko0lPoWitohAYkvhbX697WfPE9s QMcwjG7sGGsjk27wu3bwlNjUd5v10mreicRknUkw7FXH16GyOxfdV+A7bCAsmPMzs4ka t9Sg== MIME-Version: 1.0 Received: by 10.14.216.70 with SMTP id f46mr2465446eep.12.1353597323203; Thu, 22 Nov 2012 07:15:23 -0800 (PST) Sender: tonyjeffree@googlemail.com Received: by 10.14.209.71 with HTTP; Thu, 22 Nov 2012 07:15:23 -0800 (PST) In-Reply-To: <50AE3D29.1050101@cisco.com> References: <20121114231447.28588.67908.idtracker@ietfa.amsl.com> <50AE3D29.1050101@cisco.com> Date: Thu, 22 Nov 2012 15:15:23 +0000 X-Google-Sender-Auth: eiB2TUH3RXaor4eC-cgzqCgkOrE Message-ID: From: Tony Jeffree To: Benoit Claise Content-Type: multipart/alternative; boundary=047d7b603c1e9e531604cf16ef7b X-Mailman-Approved-At: Thu, 22 Nov 2012 11:35:43 -0800 Cc: Liaison Statement Management Tool , IP Flow Information Export Discussion List , Pat Thaler , Ronald Bonica , Nevil Brownlee , Eric Gray Subject: Re: [IPFIX] New Liaison Statement, "IPFIX WG Liaison Statement to the IEEE 802.1 WG about Data-link Information Elements" X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tony@jeffree.co.uk List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 15:15:25 -0000 --047d7b603c1e9e531604cf16ef7b Content-Type: text/plain; charset=UTF-8 Dear Benoit - I didn't receive it until after the stated deadline. I have circulated it to the 802.1 WG for individuals to comment on as they see fit, but we haven't developed a response from the working group itself. Regards, Tony On 22 November 2012 14:56, Benoit Claise wrote: > Dear all, > > We didn't receive any IEEE feedback regarding this draft, did we? > No news means good news? > > Regards, Benoit > > Title: IPFIX WG Liaison Statement to the IEEE 802.1 WG about Data-link >> Information Elements >> Submission Date: 2012-11-05 >> URL of the IETF Web page: http://datatracker.ietf.org/**liaison/1216/ >> Please reply by 2012-11-19 >> From: IP Flow Information Export (Eric Gray ) >> To: IEEE 802.1 (Tony Jeffree ) >> Cc: Eric Gray ,Nevil Brownlee < >> n.brownlee@auckland.ac.nz>,**Juergen Quittek ,Ronald >> Bonica ,Benoit Claise ,IP Flow >> Information Export Discussion List ,Pat Thaler < >> pthaler@broadcom.com>,Dan Romascanu >> Reponse Contact: >> Technical Contact: >> Purpose: For comment >> >> Body: >> Attachments: >> >> IPFIX WG Liaison Statement to the IEEE 802.1 WG about Data-link >> Information Elements >> https://datatracker.ietf.org/**documents/LIAISON/liaison-** >> 2012-11-05-ipfix-ieee-8021-**ipfix-wg-liaison-statement-to-** >> the-ieee-8021-wg-about-data-**link-information-elements-** >> attachment-1.txt >> >> >> >> > --047d7b603c1e9e531604cf16ef7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear = Benoit -

I didn't r= eceive it until after the stated deadline. I have circulated it to the 802.= 1 WG for individuals to comment on as they see fit, but we haven't deve= loped a response from the working group itself.

Regards,
Tony



On 22 November 2012 14:56, Benoit Claise= <bclaise@cisco.com> wrote:

Title: IPFIX WG Liaison Statement to the IEEE 802.1 WG about Data-link Info= rmation Elements
Submission Date: 2012-11-05
URL of the IETF Web page: http://datatracker.ietf.org/liaison/1216/=
Please reply by 2012-11-19
From: IP Flow Information Export (Eric Gray <Eric.Gray@Ericsson.com>)=
To: IEEE 802.1 (Tony Jeffree <tony@jeffree.co.uk>)
Cc: Eric Gray <Eric.Gray@Ericsson.com>,Nevil Brownlee <n.brownlee@auckland.ac.= nz>,Juergen Quittek <quittek@neclab.eu>,Ronald Bonica <rbonica@juniper.net>,Ben= oit Claise <bclai= se@cisco.com>,IP Flow Information Export Discussion List <ipfix@ietf.org>,Pat Tha= ler <pthaler@b= roadcom.com>,Dan Romascanu <dromasca@avaya.com>
Reponse Contact:
Technical Contact:
Purpose: For comment

Body:
Attachments:

=C2=A0 =C2=A0 =C2=A0IPFIX WG Liaison Statement to the IEEE 802.1 WG about D= ata-link Information Elements
=C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/documents/LIAISON/liaison-2012-11-05-ipfix-ieee-8021-ipfix-wg-liaison-statement-to-th= e-ieee-8021-wg-about-data-link-information-elements-attachmen= t-1.txt





--047d7b603c1e9e531604cf16ef7b-- From tonyjeffree@googlemail.com Thu Nov 22 08:14:19 2012 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 523AE21F845F for ; Thu, 22 Nov 2012 08:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 0TJ955-1TPFj for ; Thu, 22 Nov 2012 08:14:12 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id F2F4721F8466 for ; Thu, 22 Nov 2012 08:14:11 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so5331602eek.31 for ; Thu, 22 Nov 2012 08:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=U0RTkNpr/ocN/W0XkmR99NkPwO5CxLvNNSjPGJAWYSs=; b=H5hYBoZ4c25xtttHAmDLt5HiQB7BpKrD/BW9i7rRi7vC4EzKtRqkHjMNV/UdL+6nHF 7WEneYHQPh/7gwVDcjltakQojaZIqOHtKZ5Knop0SvalGmQUUA88vlT97Uj2dIFPNu76 fsY0M6xV6MyeAxAeJ7Uo6VsIhlnqV5coFM/gHlqza8Oyi9la7ZC3xMvnrQxEw1Jy4YM4 1xKk0Fqr1sMo6pbIriYgSDWx5fQinizBBwZZ9QbpGsNnRHriGVmrU/qW0/HNCdlEyW+F plDGI8NtBjY6EW9VeBz+631R5Ak3iinjO7ivcajNsRG55n1oj+E4Wuw3JNTJjRoZcvaw M8/Q== MIME-Version: 1.0 Received: by 10.14.0.198 with SMTP id 46mr2827668eeb.21.1353600851094; Thu, 22 Nov 2012 08:14:11 -0800 (PST) Sender: tonyjeffree@googlemail.com Received: by 10.14.209.71 with HTTP; Thu, 22 Nov 2012 08:14:11 -0800 (PST) In-Reply-To: <50AE43E4.9060408@cisco.com> References: <20121114231447.28588.67908.idtracker@ietfa.amsl.com> <50AE3D29.1050101@cisco.com> <50AE43E4.9060408@cisco.com> Date: Thu, 22 Nov 2012 16:14:11 +0000 X-Google-Sender-Auth: dpeeKvCLqXFA2AnTrXd1wUOy77o Message-ID: From: Tony Jeffree To: Benoit Claise Content-Type: multipart/alternative; boundary=047d7b62275ee5ace704cf17c19f X-Mailman-Approved-At: Thu, 22 Nov 2012 11:35:43 -0800 Cc: Liaison Statement Management Tool , IP Flow Information Export Discussion List , Pat Thaler , Ronald Bonica , Nevil Brownlee , Eric Gray Subject: Re: [IPFIX] New Liaison Statement, "IPFIX WG Liaison Statement to the IEEE 802.1 WG about Data-link Information Elements" X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tony@jeffree.co.uk List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 16:14:19 -0000 --047d7b62275ee5ace704cf17c19f Content-Type: text/plain; charset=UTF-8 Dear Benoit The intent was for individuals to comment directly rather than for me to collect feedback. Regards, Tony On 22 November 2012 15:25, Benoit Claise wrote: > Dear Tony, > > Thanks for the answer. > Surely a problem on our side regarding the dates. > How long do you need to collect the WG feedback? > > Regards, Benoit > > Dear Benoit - > > I didn't receive it until after the stated deadline. I have circulated > it to the 802.1 WG for individuals to comment on as they see fit, but we > haven't developed a response from the working group itself. > > Regards, > Tony > > > > On 22 November 2012 14:56, Benoit Claise wrote: > >> Dear all, >> >> We didn't receive any IEEE feedback regarding this draft, did we? >> No news means good news? >> >> Regards, Benoit >> >> Title: IPFIX WG Liaison Statement to the IEEE 802.1 WG about Data-link >>> Information Elements >>> Submission Date: 2012-11-05 >>> URL of the IETF Web page: http://datatracker.ietf.org/liaison/1216/ >>> Please reply by 2012-11-19 >>> From: IP Flow Information Export (Eric Gray >>> ) >>> To: IEEE 802.1 (Tony Jeffree ) >>> Cc: Eric Gray ,Nevil >>> Brownlee ,Juergen Quittek ,Ronald >>> Bonica ,Benoit Claise ,IP Flow >>> Information Export Discussion List ,Pat Thaler < >>> pthaler@broadcom.com>,Dan Romascanu >>> Reponse Contact: >>> Technical Contact: >>> Purpose: For comment >>> >>> Body: >>> Attachments: >>> >>> IPFIX WG Liaison Statement to the IEEE 802.1 WG about Data-link >>> Information Elements >>> >>> https://datatracker.ietf.org/documents/LIAISON/liaison-2012-11-05-ipfix-ieee-8021-ipfix-wg-liaison-statement-to-the-ieee-8021-wg-about-data-link-information-elements-attachment-1.txt >>> >>> >>> >>> >> > > --047d7b62275ee5ace704cf17c19f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear = Benoit

The intent was f= or individuals to comment directly rather than for me to collect feedback.<= /font>

Regards,
Tony



On 22 November 2012 15:25, Benoit Claise= <bclaise@cisco.com> wrote:
Dear Tony,

Thanks for the answer.
Surely a problem on our side regarding the dates.
How long do you need to collect the WG feedback?

Regards, Benoit
Dear Benoit -

I didn't receive it until after the stated deadline. I have circulated it to the 802.1 WG for individuals to comment on as they see fit, but we haven't developed a response from the working group itself.

Regards,
Tony



On 22 November 2012 14:56, Benoit Claise <bclaise@cisco.com> wrote:
Dear all,

We didn't receive any IEEE feedback regarding this draft, did we?
No news means good news?

Regards, Benoit

Title: IPFIX WG Liaison Statement to the IEEE 802.1 WG about Data-link Information Elements
Submission Date: 2012-11-05
URL of the IETF Web page: http://datatracker.ietf.org/liaiso= n/1216/
Please reply by 2012-11-19
From: IP Flow Information Export (Eric Gray <Eric.Gray@Ericsson.com>)
To: IEEE 802.1 (Tony Jeffree <tony@jeffree.co.uk>)
Cc: Eric Gray <Eric.Gray@Ericsson.com>,Nevil Brownlee <n.brownlee@auckland.ac.nz>,Juergen Quittek <quittek@neclab.eu>,Ronald Bonica <rbonica@juniper.net>,Benoit Claise <bclaise@cisco.com>,IP Flow Information Export Discussion List <ipfix@ietf.org>,Pat Thaler <pthaler@broadcom.com>,Dan Romascanu <dromasca@avaya.com>
Reponse Contact:
Technical Contact:
Purpose: For comment

Body:
Attachments:

=C2=A0 =C2=A0 =C2=A0IPFIX WG Liaison Statement to the IEE= E 802.1 WG about Data-link Information Elements
=C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/documents/LIAISON/li= aison-2012-11-05-ipfix-ieee-8021-ipfix-wg-liaison-statement-to-the-ieee-802= 1-wg-about-data-link-information-elements-attachment-1.txt







--047d7b62275ee5ace704cf17c19f-- From n.brownlee@auckland.ac.nz Thu Nov 22 13:34:32 2012 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 2687F21F8683 for ; Thu, 22 Nov 2012 13:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.855 X-Spam-Level: X-Spam-Status: No, score=-105.855 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, 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 knGTlaU4xi9W for ; Thu, 22 Nov 2012 13:34:31 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3692321F8672 for ; Thu, 22 Nov 2012 13:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1353620071; x=1385156071; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rc/6EGh4O9ur0AVCLxvv861/JL53UIet5jeHJCvmzvc=; b=NKJc6sD1HAO+XAr7nK+0WJHhoYOxf+gfIlQQoMjqITAs1MD1qPB8nTVt AqUdd+3Byz7IlIBAFVcr0rooGPonJ9AAFlBM+doN1Hjt/QXWkso6yGXhw uCnHNx7rYZH1Ohd9V5UXq5usCvPSq01sJctgE3IaNRmNMn+xZH+WSAmrB w=; X-IronPort-AV: E=Sophos;i="4.83,304,1352026800"; d="scan'208";a="158347990" 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; 23 Nov 2012 10:34:28 +1300 Message-ID: <50AE9A64.90907@auckland.ac.nz> Date: Fri, 23 Nov 2012 10:34:28 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Paul Aitken References: <509D2D65.404@auckland.ac.nz> <509D32B5.4030309@plixer.com> <509D3D0E.1030601@auckland.ac.nz> <509D75BB.6080205@cisco.com> In-Reply-To: <509D75BB.6080205@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] DRAFT minutes of IPFIX meting at IETF 85 -> data-link-layer-monitoring 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, 22 Nov 2012 21:34:32 -0000 Hi Paul: Thanks for pointing that out, I'll change the line in the minutes to say "Will probably need a new revision." Please wait for the feedback from IEEE 802, when we have that (you'll have seen Benoit's emails about it, we're pushing for feedback by 30 November) please publish a new revision with all the changes you've listed, plus any prompted by the IEEE feedback. Cheers, Nevil On 10/11/12 10:29 AM, Paul Aitken wrote: > Nevil, All, > >> Paul Aitken presented (via Meetecho) the Link Layer IEs draft. >> - WGLC for this started 15 Oct 12; it will end after next week's >> (bi-monthly) IEEE 802.3 meeting >> - Juergen commented that the draft has a VXLAN I-D as an >> Informative Reference >> - Brian pointed out that several IPFIX IEs cover VLANs, we >> need to check that the proposed VXLAN IEs will not cause >> interoperation with them >> - Paul will find a VLAN-tag expert to check that >> - Will need a new revision, when that's stable Nevil will >> submit to IESG > > I don't recall that. Why is a new version needed? > > The only issues I can see are the IE names, per Brian's feedback at the > mic (ie, uppercase "Octet"). > > Also for consistency with existing IEs (layer2SegmentId, > layer2OctetDeltaCount, layer2octetTotalCount), the "l2" (that's > "el-two") names should be "layer2". > > So: > > |TBD09| l2octetDeltaCount -> layer2OctetDeltaCount > -> already exists (352) > |TBD10| postMCastL2OctetDeltaCount -> postMCastLayer2OctetDeltaCount > |TBD11| postL2OctetDeltaCount -> postLayer2OctetDeltaCount > |TBD12| minimumL2TotalLength -> minimumLayer2TotalLength > |TBD13| maximumL2TotalLength -> maximumLayer2TotalLength > |TBD14| l2octetTotalCount -> layer2octetTotalCount > -> already exists (353) > |TBD15| droppedL2OctetDeltaCount -> droppedLayer2OctetDeltaCount > |TBD16| droppedL2OctetTotalCount -> droppedLayer2OctetTotalCount > |TBD17| ignoredL2OctetTotalCount -> ignoredLayer2OctetTotalCount > |TBD18| notSentL2OctetTotalCount -> notSentLayer2OctetTotalCount > |TBD19| postL2OctetTotalCount -> postLayer2OctetTotalCount > |TBD20| postMCastL2OctetTotalCount -> postMCastLayer2OctetTotalCount > |TBD21| l2octetDeltaSumOfSquares -> layer2OctetDeltaSumOfSquares > |TBD22| l2octetTotalSumOfSquares -> layer2OctetTotalSumOfSquares > > > Hmm, nobody noticed... > > Shall I quickly make a new version with those changes? > > Or, shall I wait for IEEE feedback? > > Or, simply save those changes for AUTH48? > > > Thanks, > P. > -- --------------------------------------------------------------------- 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 paitken@cisco.com Thu Nov 22 13:37:22 2012 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 C45EE21F8764 for ; Thu, 22 Nov 2012 13:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.6 X-Spam-Level: X-Spam-Status: No, score=-10.6 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 uetCS6Ux7lOQ for ; Thu, 22 Nov 2012 13:37:22 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id B8D6F21F8817 for ; Thu, 22 Nov 2012 13:37:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2926; q=dns/txt; s=iport; t=1353620241; x=1354829841; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=McXpk8RS9zhDfm+GSmR6yhM0F7OcSHKO2DcA3Agir3E=; b=POHao5ubktTlNqoBMCTOkpAaz9twmp0OPvFWnlKlnfTgwoc9Clw1ClyZ c0fASmxGJ98n9EB0oIba0ZQhEWnae0nJXaRnhD1N90kHk9MGy1GtJ/MXU GGHwwWY+GNXXH9uSa1xUQu/1wJe+pzPFSg/V+eaAPV9CZ1/8qtYoCREPT M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACqarlCQ/khL/2dsb2JhbABEDr4Tg0gWc4IeAQEBBCcRMw0BEAsOCgkWDwkDAgECAUUGDQEHAQGICb9/jEKERgOWAYVrileCMj2BaA X-IronPort-AV: E=McAfee;i="5400,1158,6904"; a="9858082" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 22 Nov 2012 21:37:20 +0000 Received: from [10.55.94.134] (dhcp-10-55-94-134.cisco.com [10.55.94.134]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAMLbKPT020590; Thu, 22 Nov 2012 21:37:20 GMT Message-ID: <50AE9B10.4060308@cisco.com> Date: Thu, 22 Nov 2012 21:37:20 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Nevil Brownlee References: <509D2D65.404@auckland.ac.nz> <509D32B5.4030309@plixer.com> <509D3D0E.1030601@auckland.ac.nz> <509D75BB.6080205@cisco.com> <50AE9A64.90907@auckland.ac.nz> In-Reply-To: <50AE9A64.90907@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] DRAFT minutes of IPFIX meting at IETF 85 -> data-link-layer-monitoring 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, 22 Nov 2012 21:37:22 -0000 Nevil, Per Benoit's earlier email, I'll wait until after Nov 30th for any IEEE feedback before producing the (hopefully) final version. P. On 22/11/12 21:34, Nevil Brownlee wrote: > > Hi Paul: > > Thanks for pointing that out, I'll change the line in the minutes > to say "Will probably need a new revision." > > Please wait for the feedback from IEEE 802, when we have that > (you'll have seen Benoit's emails about it, we're pushing for > feedback by 30 November) please publish a new revision with all > the changes you've listed, plus any prompted by the IEEE feedback. > > Cheers, Nevil > > > On 10/11/12 10:29 AM, Paul Aitken wrote: >> Nevil, All, >> >>> Paul Aitken presented (via Meetecho) the Link Layer IEs draft. >>> - WGLC for this started 15 Oct 12; it will end after next week's >>> (bi-monthly) IEEE 802.3 meeting >>> - Juergen commented that the draft has a VXLAN I-D as an >>> Informative Reference >>> - Brian pointed out that several IPFIX IEs cover VLANs, we >>> need to check that the proposed VXLAN IEs will not cause >>> interoperation with them >>> - Paul will find a VLAN-tag expert to check that >>> - Will need a new revision, when that's stable Nevil will >>> submit to IESG >> >> I don't recall that. Why is a new version needed? >> >> The only issues I can see are the IE names, per Brian's feedback at the >> mic (ie, uppercase "Octet"). >> >> Also for consistency with existing IEs (layer2SegmentId, >> layer2OctetDeltaCount, layer2octetTotalCount), the "l2" (that's >> "el-two") names should be "layer2". >> >> So: >> >> |TBD09| l2octetDeltaCount -> layer2OctetDeltaCount >> -> already exists (352) >> |TBD10| postMCastL2OctetDeltaCount -> postMCastLayer2OctetDeltaCount >> |TBD11| postL2OctetDeltaCount -> postLayer2OctetDeltaCount >> |TBD12| minimumL2TotalLength -> minimumLayer2TotalLength >> |TBD13| maximumL2TotalLength -> maximumLayer2TotalLength >> |TBD14| l2octetTotalCount -> layer2octetTotalCount >> -> already exists (353) >> |TBD15| droppedL2OctetDeltaCount -> droppedLayer2OctetDeltaCount >> |TBD16| droppedL2OctetTotalCount -> droppedLayer2OctetTotalCount >> |TBD17| ignoredL2OctetTotalCount -> ignoredLayer2OctetTotalCount >> |TBD18| notSentL2OctetTotalCount -> notSentLayer2OctetTotalCount >> |TBD19| postL2OctetTotalCount -> postLayer2OctetTotalCount >> |TBD20| postMCastL2OctetTotalCount -> postMCastLayer2OctetTotalCount >> |TBD21| l2octetDeltaSumOfSquares -> layer2OctetDeltaSumOfSquares >> |TBD22| l2octetTotalSumOfSquares -> layer2OctetTotalSumOfSquares >> >> >> Hmm, nobody noticed... >> >> Shall I quickly make a new version with those changes? >> >> Or, shall I wait for IEEE feedback? >> >> Or, simply save those changes for AUTH48? >> >> >> Thanks, >> P. >> > > From n.brownlee@auckland.ac.nz Thu Nov 22 19:47:35 2012 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 A6ED221F845D for ; Thu, 22 Nov 2012 19:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.351 X-Spam-Level: X-Spam-Status: No, score=-106.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 LBKJYf3R0cTS for ; Thu, 22 Nov 2012 19:47:31 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3D53721F844D for ; Thu, 22 Nov 2012 19:47:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1353642452; x=1385178452; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=I2mHnpEXTdrlKliHcs7FVLeT+PADHWzQsZFjnYUd0Bo=; b=WfvcF43oojBJ/zHUvLnAWTfjI22VHcVLv4D6MW4Ij4j5POLV6gfbJwMb skqa4bX+gBmsQFlj9uOP/sxKxdHhL3pcvGtVu2oAU/5FJVt6DwG86kQov iiOV8o3TWm2S9z06zek5XQ248653WPyAYVFQImSzGEP//A0FEeYebn5oV s=; X-IronPort-AV: E=Sophos;i="4.83,306,1352026800"; d="scan'208";a="158419428" 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; 23 Nov 2012 16:47:30 +1300 Message-ID: <50AEF1D1.9010809@auckland.ac.nz> Date: Fri, 23 Nov 2012 16:47:29 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5101bis-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: Fri, 23 Nov 2012 03:47:35 -0000 Hi all: Following up on Brian's email dated 20 November ... The WG Last Call for this I-D starts now, and will run until Monday, 10 December. Do please read the draft, and post your comments to the list. It's important that we can show it has been well-considered/reviewed within the WG, so short comments like "yes, this does clearly describe the IPFIX Information Model as we want it to be" are important and useful! Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From bclaise@cisco.com Fri Nov 23 00:54:46 2012 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 CED7221F864D for ; Fri, 23 Nov 2012 00:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.477 X-Spam-Level: X-Spam-Status: No, score=-10.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 C3j2fc54qUjQ for ; Fri, 23 Nov 2012 00:54:46 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDA121F8648 for ; Fri, 23 Nov 2012 00:54:45 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAN8sccH008843; Fri, 23 Nov 2012 09:54:38 +0100 (CET) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAN8sZHN011640; Fri, 23 Nov 2012 09:54:35 +0100 (CET) Message-ID: <50AF39CA.7070706@cisco.com> Date: Fri, 23 Nov 2012 09:54:34 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Nevil Brownlee References: <50AEF1D1.9010809@auckland.ac.nz> In-Reply-To: <50AEF1D1.9010809@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-protocol-rfc5101bis-03 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: Fri, 23 Nov 2012 08:54:46 -0000 Dear all, Nevil, Trying to avoid any potential confusing, correcting the subject to the correct draft name: draft-ietf-ipfix-protocol-rfc5101bis-03 Regards, Benoit > > Hi all: > > Following up on Brian's email dated 20 November ... > > The WG Last Call for this I-D starts now, and will run until Monday, > 10 December. > > Do please read the draft, and post your comments to the list. It's > important that we can show it has been well-considered/reviewed within > the WG, so short comments like "yes, this does clearly describe the > IPFIX Information Model as we want it to be" are important and useful! > > Cheers, Nevil > From akoba@orange.plala.or.jp Sun Nov 25 05:41:25 2012 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 6E85821F8546 for ; Sun, 25 Nov 2012 05:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UfHzpN-ejte for ; Sun, 25 Nov 2012 05:41:24 -0800 (PST) Received: from msa04b.plala.or.jp (msa04.plala.or.jp [IPv6:2400:7800:0:5010::4]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAFD21F8447 for ; Sun, 25 Nov 2012 05:41:23 -0800 (PST) Received: from [192.168.1.12] (really [114.181.213.69]) by msa04b.plala.or.jp with SMTP id <20121125134113.RQGI16835.msa04b.plala.or.jp@[192.168.1.12]>; Sun, 25 Nov 2012 22:41:13 +0900 Date: Sun, 25 Nov 2012 22:41:13 +0900 From: ATSUSHI KOBAYASHI To: ATSUSHI KOBAYASHI , IPFIX Working Group In-Reply-To: <20121125175952.D64A.C996B02F@orange.plala.or.jp> References: <20121125175952.D64A.C996B02F@orange.plala.or.jp> Message-Id: <20121125224113.262B.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.61.01 [ja] X-VirusScan: Outbound; msa04b; Sun, 25 Nov 2012 22:41:13 +0900 Subject: [IPFIX] draft-ietf-ipfix-protocol-rfc5101bis-03 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, 25 Nov 2012 13:41:25 -0000 Dear all, Nevil, I checked the draft, I found some comments and editorial issue. Please see in-line. Regards, Atsushi > > > > > Network Working Group B. Claise, Ed. > Internet Draft Cisco Systems, Inc. > Obsoletes: 5101 B. Trammell, Ed. > Category: Standards Track ETH Zurich > Expires: May 24, 2013 November 20, 2012 > > > Specification of the IP Flow Information eXport (IPFIX) Protocol > for the Exchange of Flow Information > draft-ietf-ipfix-protocol-rfc5101bis-03 > snip > 1.2. IPFIX Documents Overview > > The IPFIX protocol provides network administrators with access to IP > flow information. The architecture for the export of measured IP > flow information out of an IPFIX Exporting Process to a Collecting > Process is defined in [RFC5470], per the requirements defined in > [RFC3917]. This document specifies how IPFIX data records and > templates are carried via a number of transport protocols from IPFIX > Exporting Processes to IPFIX Collecting Processes. > > Four IPFIX optimizations/extensions are currently specified: a > bandwidth saving method for the IPFIX protocol in [RFC5473], an > > > > Standards Track [Page 5] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > efficient method for exporting bidirectional flow in [RFC5103], a > method for the definition and export of complex data structures in > [RFC6313], and the specification of the Protocol for IPFIX Mediations > [IPFIX-MED-PROTO] based on the IPIFX Mediation Framework [RFC6183]. > > IPFIX has a formal description of IPFIX Information Elements, their > name, type and additional semantic information, as specified in > [RFC5102bis], with the export of the Information Element types > specified in [RFC5610]. > > [IPFIX-CONF] specifies a data model for configuring and monitoring > IPFIX and PSAMP compliant devices using the NETCONF protocol, while > the [RFC5815bis] specifies a MIB module for monitoring. Please replace it within entire document. s/RFC5815bis/RFC6615/ snip > > 2. Terminology > > 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]. snip > Traffic Flow or Flow > > There are several definitions of the term 'flow' being used by the > Internet community. Within the context of IPFIX we use the > following definition: > > A Flow is defined as a set of packets passing an Observation Point Comment#1: Why don't you add "frames" to the above sentence? > in the network during a certain time interval. All packets > belonging to a particular Flow have a set of common properties. > Each property is defined as the result of applying a function to > the values of: > > 1. one or more packet header fields (e.g., destination IP > address), transport header fields (e.g., destination port > number), or application header fields (e.g., RTP header > fields [RFC3550]). > > 2. one or more characteristics of the packet itself (e.g., > number of MPLS labels, etc...). > > 3. one or more of fields derived from packet treatment (e.g., > next hop IP address, the output interface, etc...). > > A packet is defined as belonging to a Flow if it completely > satisfies all the defined properties of the Flow. > > Note that the set of packets represented by a Flow may be empty; > > > snip > 8.2 Sequencing Template Management Actions > > Since there is no guarantee of the ordering of exported IPFIX > Messages across SCTP Streams or over UDP, an Exporting Process MUST > sequence all template management actions (i.e., Template Records > defining new templates and Template Withdrawals withdrawing them) > using the Export Time field in the IPFIX Message Header. > > An Exporting Process MUST NOT export a Data Set described by a new Comment#2: It uses two ways; "defined by a new Template", or "described by a new Template". It prefers one way within entire document. > Template in an IPFIX Message with an Export Time before the Export > Time of the IPFIX Message containing that Template. If a new Template > and a Data Set described by it appear in the same IPFIX Message, the > > > > Standards Track [Page 39] > > Internet-Draft IPFIX Protocol Specification November 20, 2012 > > > Template Set containing the Template MUST appear before the Data Set > in the Message. > > An Exporting Process MUST NOT export any Data Sets described by a > withdrawn Template in IPFIX Messages with an Export Time after the > Export Time of the IPFIX Message containing the Template Withdrawal > withdrawing that Template. > Comment#3: I could not understand the following paragraph. If you want to describe another way, please explain it in more detail. > Put another way, a Template only describes Records contained in IPFIX > Messages with the same Export Time as the IPFIX Message containing > Template Record, or a subsequent export time. Likewise, a Template > Withdrawal is only in effect for IPFIX Messages with the same Export > Time as the Template Withdrawal, or a subsequent Export Time. > > Collecting Processes MAY implement a buffer to handle out-of-order > Template management events. > > 8.3. Additional considerations for Template Management over SCTP > > Template Sets and Options Template Sets MAY be sent on any SCTP > stream. Data Sets sent on a given SCTP stream MAY be represented by > Template Records exported on any SCTP stream. > > Template Sets and Options Template Sets MUST be sent reliably and in > order. > > Template Withdrawal Messages MAY be sent on any SCTP stream. Template > Withdrawal Messages MUST be sent reliably, using SCTP-ordered > delivery. Template IDs MAY be reused by sending a Template Withdrawal > Message and/or a new Template Record on a different SCTP stream than > the stream on which the original Template was sent. > > Additional Template Management considerations are given in [IPFIX- > PER-SCTP-STREAM], which specifies an extension to explicitly link > Templates with SCTP streams. In exchange for more restrictive rules > on the assignment of Template Records to SCTP streams, this extension > allows fast, reliable reuse of Template IDs and estimation of Data > Record loss per Template. > Comment#4: It is hard to understand to sentence "estimation of Data Record loss per Template" in the paragraph. From iesg-secretary@ietf.org Mon Nov 26 13:41:52 2012 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 5604821F86C9; Mon, 26 Nov 2012 13:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 tuOC1jNDOnCn; Mon, 26 Nov 2012 13:41:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058B821F86BB; Mon, 26 Nov 2012 13:41:51 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121126214151.20383.12237.idtracker@ietfa.amsl.com> Date: Mon, 26 Nov 2012 13:41:51 -0800 Cc: ipfix chair , ipfix mailing list , RFC Editor Subject: [IPFIX] Protocol Action: 'Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol' to Proposed Standard (draft-ietf-ipfix-a9n-08.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: Mon, 26 Nov 2012 21:41:52 -0000 The IESG has approved the following document: - 'Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol' (draft-ietf-ipfix-a9n-08.txt) as Proposed Standard This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Ronald Bonica and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipfix-a9n/ Technical Summary This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export (IPFIX) Protocol to the handling of Aggregated Flows, which are IPFIX Flows representing packets from multiple Original Flows that share some set of common properties. Working Group Summary This draft attracted real discussion on the IPFIX list, and took time to reach consensus on its final approach, i.e. "through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals." Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? I'm not aware of any, so far. Are there any reviewers that merit special mention as having done a thorough review ... ? Rahul Patel was a strong contributor to the discussion, Paul Aitken provided a very thorough review. Personnel Who is the Document Shepherd? Nevil Brownlee Who is the Responsible Area Director? Ron Bonica RFC Editor Note OLD: In certain circumstances, additional delay at the original Exporter may cause an IAP to close an interval before the last Original Flow(s) accountable to the interval arrives; in this case the IAP SHOULD drop the late Original Flow(s). Accounting of flows lost at an Intermediate Process due to such issues is covered in [I-D.ietf-ipfix-mediation-protocol]. NEW: In certain circumstances, additional delay at the original Exporter may cause an IAP to close an interval before the last Original Flow(s) accountable to the interval arrives; in this case the IAP MAY drop the late Original Flow(s). Accounting of flows lost at an Intermediate Process due to such issues is covered in [I-D.ietf-ipfix-mediation-protocol]. Section 5.3.1 OLD Certain Information Elements for these applications are already provided in the IANA IPFIX Information Elements registry (http://www.iana.org/assignments/ipfix/ipfix.html (e.g. minimumIpTotalLength). NEW Certain Information Elements for these applications are already provided in the IANA IPFIX Information Elements registry [iana-ipfix-assignments] (e.g. minimumIpTotalLength). ============================================ Section 7.2.4 OLD: [IANA NOTE: This Information Element is compatible with Information Element 3 as used in NetFlow version 9.] NEW ============================================ Section 10 OLD: [NOTE for IANA: The text TBDn should be replaced with the respective assigned Information Element numbers where they appear in this document. Note that the deltaFlowCount Information Element has been assigned the number 3, as it is compatible with the corresponding existing (reserved) NetFlow v9 Information Element. Other Information Element numbers should be assigned outside the NetFlow V9 compatibility range, as these Information Elements are not supported by NetFlow V9.] NEW ============================================ Section 2 OLD: Aggregated Flow: A Flow, as defined by [I-D.ietf-ipfix-protocol-rfc5101bis], derived from a set of zero or more original Flows within a defined Aggregation Interval. The primary difference between a Flow and an Aggregated Flow in the general case is that the time interval (i.e., the two-tuple of start and end times) of a Flow is derived from information about the timing of the packets comprising the Flow, while the time interval of an Aggregated Flow is often externally imposed. Note that an Aggregated Flow is defined in the context of an Intermediate Aggregation Process only. Once an Aggregated Flow is exported, it is essentially a Flow as in [I-D.ietf-ipfix-protocol-rfc5101bis] and can be treated as such. NEW Aggregated Flow: A Flow, as defined by [I-D.ietf-ipfix-protocol-rfc5101bis], derived from a set of zero or more original Flows within a defined Aggregation Interval. Note that an Aggregated Flow is defined in the context of an Intermediate Aggregation Process only. Once an Aggregated Flow is exported, it is essentially a Flow as in [I-D.ietf-ipfix-protocol-rfc5101bis] and can be treated as such. ============================================ Section 5.1.1 OLD: Proportional Uniform Distribution: This is like simple uniform distribution, but accounts for the fractional portions of a time interval covered by an Original Flow in the first and last time interval. Each counter for an Original Flow is divided by the number of time _units_ the Original Flow covers, to derive a mean count rate. This rate is then multiplied by the number of time units in the intersection of the duration of the Original Flow and the time interval of each Aggregated Flow. NEW: Proportional Uniform Distribution: This is like simple uniform distribution, but accounts for the fractional portions of a time interval covered by an Original Flow in the first and last time interval. Each counter for an Original Flow is divided by the number of time units the Original Flow covers, to derive a mean count rate. This rate is then multiplied by the number of time units in the intersection of the duration of the Original Flow and the time interval of each Aggregated Flow. From bclaise@cisco.com Tue Nov 27 01:58:30 2012 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 9902821F852B for ; Tue, 27 Nov 2012 01:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=4.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 HbIsa8HoEO0E for ; Tue, 27 Nov 2012 01:58:30 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id AB9D421F8529 for ; Tue, 27 Nov 2012 01:58:29 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAR9wS6V013355 for ; Tue, 27 Nov 2012 10:58:28 +0100 (CET) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAR9wSg9016064 for ; Tue, 27 Nov 2012 10:58:28 +0100 (CET) Message-ID: <50B48EBD.4010909@cisco.com> Date: Tue, 27 Nov 2012 10:58:21 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <20121127032035.635D0B1E002@rfc-editor.org> In-Reply-To: <20121127032035.635D0B1E002@rfc-editor.org> X-Forwarded-Message-Id: <20121127032035.635D0B1E002@rfc-editor.org> Content-Type: multipart/mixed; boundary="------------020101020708010600010300" Subject: [IPFIX] Fwd: [RFC State] has been added to RFC Editor database 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, 27 Nov 2012 09:58:30 -0000 This is a multi-part message in MIME format. --------------020101020708010600010300 Content-Type: multipart/alternative; boundary="------------040409030603020505050809" --------------040409030603020505050809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI. Regards, Benoit -------- Original Message -------- Subject: [RFC State] has been added to RFC Editor database Date: Mon, 26 Nov 2012 19:20:35 -0800 (PST) From: rfc-editor@rfc-editor.org To: trammell@tik.ee.ethz.ch, arno@wagner.name, bclaise@cisco.com CC: ipfix-ads@tools.ietf.org, ipfix-chairs@tools.ietf.org, rfc-editor@rfc-editor.org Author(s), We have received notice that your document draft-ietf-ipfix-a9n-08 has been approved for publication as an RFC. The document has been added to the RFC Editor queue and you can check the status at If you submitted your XML file using the I-D submission tool, we have already retrieved it. If you did not submit the XML file via the I-D submission tool, or if you have an updated version (e.g., updated contact information), please send us the XML file at this time. Please attach the file as draft-ietf-ipfix-a9n-08.xml, and specify any differences between the approved I-D and the document that the XML produces. If you created this document using -ms nroff, please send us the source file. This should help increase the pace with which documents move through the RFC Editor queue. Please let us know if you have any questions. Thank you. The RFC Editor Team --------------040409030603020505050809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI.

Regards, Benoit


-------- Original Message --------
Subject: [RFC State] <draft-ietf-ipfix-a9n-08> has been added to RFC Editor database
Date: Mon, 26 Nov 2012 19:20:35 -0800 (PST)
From: rfc-editor@rfc-editor.org
To: trammell@tik.ee.ethz.ch, arno@wagner.name, bclaise@cisco.com
CC: ipfix-ads@tools.ietf.org, ipfix-chairs@tools.ietf.org, rfc-editor@rfc-editor.org 


Author(s),

We have received notice that your document draft-ietf-ipfix-a9n-08 has
been approved for publication as an RFC.  The document has
been added to the RFC Editor queue and you can check the status at
<http://www.rfc-editor.org/queue2.html#draft-ietf-ipfix-a9n>

If you submitted your XML file using the I-D submission tool, we have
already retrieved it.  If you did not submit the XML file via the I-D
submission tool, or if you have an updated version (e.g., updated
contact information), please send us the XML file at this time. Please
attach the file as draft-ietf-ipfix-a9n-08.xml, and specify 
any differences between the approved I-D and the document that the XML produces.

If you created this document using -ms nroff, please send us the
source file.

This should help increase the pace with which documents move through
the RFC Editor queue. 

Please let us know if you have any questions.

Thank you.

The RFC Editor Team



--------------040409030603020505050809-- --------------020101020708010600010300 Content-Type: text/plain; charset=windows-1252; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" --------------020101020708010600010300-- From janovak@cisco.com Wed Nov 28 02:19:03 2012 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 2192821F85C0 for ; Wed, 28 Nov 2012 02:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 816kpw0Fj+d3 for ; Wed, 28 Nov 2012 02:19:02 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 877C921F84BB for ; Wed, 28 Nov 2012 02:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2271; q=dns/txt; s=iport; t=1354097942; x=1355307542; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=BW18cHZAn+/F6uUVTXOT7FCPRiSUxtSXN7t/kNY6mdk=; b=cQXJTzg+da8qshgpnp8xxSSfqtyzPcqpoDQTDpWOUD1R9AmyjPvhxxq5 Ac72wdwfn5GEX1M7u0B9q5LhNIunq4gxw7NvCEIaNRQKnKQRbp6t+M0k4 wotnuZylm4oigQCH4RKeNWLP6VoHIdgM2gJJnEXBM/dhTbvQS2aCfJ5ye Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQLAEDktVCtJV2d/2dsb2JhbABFwB8WbAeCIAEEOlEBKhRCJgEEG4gHDJ06oTuQH2EDlx2PKIJwgiE X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="147000656" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 28 Nov 2012 10:19:01 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qASAJ06Z011238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 28 Nov 2012 10:19:00 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.161]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 04:19:00 -0600 From: "Jan Novak (janovak)" To: "ipfix@ietf.org" Thread-Topic: Flow set padding with VarLen fields Thread-Index: Ac3NUcKPtV0wtrZYTd2EQud1gGKTag== Date: Wed, 28 Nov 2012 10:19:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.1.21] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPFIX] Flow set padding with VarLen fields 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, 28 Nov 2012 10:19:03 -0000 Hi, I am working on an IPFIX decode containing VarLen fields with quite broad range of the lengths within one flowset: AFCB-1 length =3D FFFF enterprise =3D 00000009 var_length1 =3D 06 var_length2 =3D 1C var_length3 =3D 06 var_length4 =3D 24 AFCB-2 length =3D FFFF enterprise =3D 00000009 var_length1 =3D 06 var_length2 =3D 13 var_length3 =3D 06 var_length4 =3D 15 and the implementation under the test still inserts padding at the end of the flowset. I quite struggle to insert into the flowset decode loop (when interpreting the hex string of characters for one flowset) a criteria how to detect in this situation we got padding. Section 3.3.1 of RFC5101 states that padding can be upto 7 bytes and IE ID 210 "can be used" and the latest: http://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis/?inclu= de_text=3D1 maintains that statement. 7 bytes is quite a large value and even without VarLen fields for records shorter than 7 bytes there is no way to detect what was exported - a zeroed record or padding ?? But one could still assume that padding would always be less than the record length and detect it that way (but I have no way here to actually check the implementation behaves correctly - that's what we are trying to do here). With VarLen in the picture and also with the possibility of length zero there is no way at all to say if we have padding or data as the last 7 bytes. Wouldn't it be possible as part of the "bis" process to either mandate the use of IE 210 for padding or remove the need for alignment at all ?? Who needs that these days - I know some implementations do not simply set any padding at all - wasn't it a requirement from 40 years ago for the first 8 bit processors ?? Tx, Jan The climate of Edinburgh is such that the weak succumb young, and the strong envy them .... Dr. Johnson From paitken@cisco.com Wed Nov 28 07:25:39 2012 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 2145C21F8891 for ; Wed, 28 Nov 2012 07:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ij9Y1PeotjHT for ; Wed, 28 Nov 2012 07:25:38 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6BD21F8867 for ; Wed, 28 Nov 2012 07:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1280; q=dns/txt; s=iport; t=1354116338; x=1355325938; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=95mKFQ3fREgNtat9EaoMdx/ul7pTrmxp0Ak7RUqxXb8=; b=S9HC9mlGLCjpXCrh3jxzfjOwbGe2x6kdmoX1xao8NQMxpZXLKCGe8Ihi ObrlwTpzS87WftYvDpVShlSx44L/v31rWefJs9xqCrvaLSJ5aUySzIIz5 xrJ92naaZ6zoc64Jiu2Fr4MMFlpdtZnNO1VRe/PbJtQwjJlmeHeHhuyKa 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANgrtlCQ/khR/2dsb2JhbABFwBUWc4JdMw09FhgDAgECAUsNCAEBiAudPqFDkQADlgGFa4pZgnA X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="9981108" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 28 Nov 2012 15:25:37 +0000 Received: from [144.254.153.46] (dhcp-144-254-153-46.cisco.com [144.254.153.46]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qASFPaFB007032 for ; Wed, 28 Nov 2012 15:25:37 GMT Message-ID: <50B62CF2.7000700@cisco.com> Date: Wed, 28 Nov 2012 15:25:38 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 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] RFC 3550 jitter 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, 28 Nov 2012 15:25:39 -0000 Dear IPFIX experts, I'd like to request an IPFIX IE for jitter from IANA. RFC 3550 defines a suitable "interarrival jitter". Unfortunately it's measured in "timestamp units": An estimate of the statistical variance of the RTP data packet interarrival time, measured in timestamp units and expressed as an unsigned integer. Therefore it seems we may need multiple IEs: one for units of milliseconds, one for microseconds, one for nanoseconds... Else comparison of two jitter values would be meaningless. So I request your feedback on the following: Name: interarrivalJitterMilliseconds Type: unsigned32 Semantic: quantity Description: interarrival jitter as defined in section 6.4.1 of RFC 3550, measured in milliseconds. Units: milliseconds References: [RFC3550] Name: interarrivalJitterMicroseconds Type: unsigned32 Semantic: quantity Description: interarrival jitter as defined in section 6.4.1 of RFC 3550, measured in microseconds. Units: microseconds References: [RFC3550] Name: interarrivalJitterNanoseconds Type: unsigned32 Semantic: quantity Description: interarrival jitter as defined in section 6.4.1 of RFC 3550, measured in nanoseconds. Units: nanoseconds References: [RFC3550] Thanks, P. From paitken@cisco.com Wed Nov 28 09:30:57 2012 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 2092321F847B for ; Wed, 28 Nov 2012 09:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Slk3qpgWaToz for ; Wed, 28 Nov 2012 09:30:56 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2A22021F8472 for ; Wed, 28 Nov 2012 09:30:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1905; q=dns/txt; s=iport; t=1354123856; x=1355333456; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=mUviFGqgF6jyZJgtB0zuXk0f92zb2bpSnGZu3EEGd3w=; b=M1TjJpxMjLGnCX6CAEEF1y/6WM6xjdX+oNDC+2qjzfNB7x7X+3qN07uB wXz+U7FsL78KMnW3BvcYoBw7EyWIUZmc8GNVsZl4wMa+OG3s9m/fv+TUN w2CfbPLe8m7exaSwrw5qOVTP7QhpFZ1SkwpnFOGnJb5iy+YOsbhPoUpP9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHxJtlCQ/khR/2dsb2JhbABFwBYWc4IeAQEBBAEBATUzAwoRCxgJDAoPCQMCAQIBFTAGDQYCAQGICwy/BgSNTYMzA5YBhWuKWYJw X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147474864" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 28 Nov 2012 17:30:55 +0000 Received: from [144.254.153.46] (dhcp-144-254-153-46.cisco.com [144.254.153.46]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qASHUs1F032193 for ; Wed, 28 Nov 2012 17:30:54 GMT Message-ID: <50B64A4F.6030003@cisco.com> Date: Wed, 28 Nov 2012 17:30:55 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IETF IPFIX Working Group References: <50B62CF2.7000700@cisco.com> In-Reply-To: <50B62CF2.7000700@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] RFC 3550 jitter 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, 28 Nov 2012 17:30:57 -0000 Dear all, I received feedback that the name should include "mean" and 'rfc3550', since there are other jitter metrics which take into account all samples rather than running average based last 16 samples as done by RFC3550. So the proposed names could be rfc3550JitterMeanMilliseconds, rfc3550JitterMeanMicroseconds, and rfc3550JitterMeanNanoseconds. P. On 28/11/12 15:25, Paul Aitken wrote: > Dear IPFIX experts, > > I'd like to request an IPFIX IE for jitter from IANA. RFC 3550 defines > a suitable "interarrival jitter". Unfortunately it's measured in > "timestamp units": > > An estimate of the statistical variance of the RTP data packet > interarrival time, measured in timestamp units and expressed as an > unsigned integer. > > > Therefore it seems we may need multiple IEs: one for units of > milliseconds, one for microseconds, one for nanoseconds... > Else comparison of two jitter values would be meaningless. > > So I request your feedback on the following: > > Name: interarrivalJitterMilliseconds > Type: unsigned32 > Semantic: quantity > Description: interarrival jitter as defined in section 6.4.1 of RFC > 3550, measured in milliseconds. > Units: milliseconds > References: [RFC3550] > > Name: interarrivalJitterMicroseconds > Type: unsigned32 > Semantic: quantity > Description: interarrival jitter as defined in section 6.4.1 of RFC > 3550, measured in microseconds. > Units: microseconds > References: [RFC3550] > > Name: interarrivalJitterNanoseconds > Type: unsigned32 > Semantic: quantity > Description: interarrival jitter as defined in section 6.4.1 of RFC > 3550, measured in nanoseconds. > Units: nanoseconds > References: [RFC3550] > > Thanks, > P. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From andrjohn@cisco.com Wed Nov 28 10:16:19 2012 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 C51CE21F8878 for ; Wed, 28 Nov 2012 10:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+o6ZuFjnByt for ; Wed, 28 Nov 2012 10:16:19 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id C09FA21F8872 for ; Wed, 28 Nov 2012 10:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2537; q=dns/txt; s=iport; t=1354126578; x=1355336178; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=nAHitRsnb7MueRg9waQpxcqfrjvowH/DdGUePR8GOxg=; b=gi21xNOkJtB6FuKRBEkjvDGShlCN2p9rhDRs5fVkLtCf48GfZUo0fm18 CAUVIDvgwPcU7W4g0qwjmIgEI3fS7mgX5+Lt7ai/ZNCCc629tvJT5FtL0 /ST1hhzXuahyl0As6omrSr4HEY8bfySdVFH0Kn7TC6NtC+0f1g5gTpak/ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKpTtlCQ/khN/2dsb2JhbABFwBcWc4IeAQEBBAEBARodNAsOAgsYLhsMMAYTG4d0DL8RBASMOwuDVWEDlgGQRIJwgWw X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="9985583" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 28 Nov 2012 18:16:16 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qASIGGYG024476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Nov 2012 18:16:16 GMT Received: from dhcp-144-254-153-55.cisco.com (dhcp-144-254-153-55.cisco.com [144.254.153.55]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id qASIGE2w016181; Wed, 28 Nov 2012 18:16:15 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Andrew Johnson In-Reply-To: <50AEF1D1.9010809@auckland.ac.nz> Date: Wed, 28 Nov 2012 18:16:14 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50AEF1D1.9010809@auckland.ac.nz> To: IPFIX Working Group X-Mailer: Apple Mail (2.1498) Cc: Nevil Brownlee Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5101bis-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, 28 Nov 2012 18:16:19 -0000 Hi folks I have started looking through the changes and so far see the value in = the various clarifications. I'm a little concerned about the additional = scope field being added to the Metering Process Statistics Options = Template. I see why that's been done, but what about existing = implementations? One minor point, in section 5: Certain time-related Information Elements may be expressed as an offset from this Export Time. For example, Data Records requiring a microsecond precision can export the flow start and end times with the flowStartMicroseconds and flowEndMicroseconds Information Elements [RFC5102bis], which encode the absolute time in microseconds in terms of the NTP epoch, 1 January 1900 at 00:00 UTC, in a 64-bit field. An alternate solution is to export the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements [RFC5102bis] in the Data Record, which respectively report the flow start and end time as negative offsets from the Export Time, as an unsigned 32-bit integer. This latter solution lowers the export bandwidth requirement, saving two bytes per timestamp, while ^^^^^^^^^^^^^^^^^^^^^^^ increasing the load on the Exporter, as the Exporting Process must calculate the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds of every single Data Record before exporting the IPFIX Message. Isn't it saving 4 bytes per timestamp? Regards, Andrew On 23 Nov 2012, at 03:47, Nevil Brownlee = wrote: >=20 > Hi all: >=20 > Following up on Brian's email dated 20 November ... >=20 > The WG Last Call for this I-D starts now, and will run until Monday, > 10 December. >=20 > Do please read the draft, and post your comments to the list. It's > important that we can show it has been well-considered/reviewed within > the WG, so short comments like "yes, this does clearly describe the > IPFIX Information Model as we want it to be" are important and useful! >=20 > Cheers, Nevil >=20 > --=20 > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Thu Nov 29 08:48:55 2012 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 45B9521F8762 for ; Thu, 29 Nov 2012 08:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVAl6N0bB6Kr for ; Thu, 29 Nov 2012 08:48:54 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 855BF21F8761 for ; Thu, 29 Nov 2012 08:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=798; q=dns/txt; s=iport; t=1354207734; x=1355417334; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=KJTM8+nxH5N0NrpgkqvOEE3PCx6Wij5BWiRYxdZCgDE=; b=CrlfQpmDPB0GY3i4GQGMaZPZPDRV1dQX6XbsKNquA4eBE0CnIEOzQO4R Yrr7L2a1GZ289/ZzDtGegojVIInNIlk7DhfKix96xVrlD/mGqEXBV8kpR Vy4cLHOYGN42htUqS7qXzF3r+Ptt+BjJPiVPT6JyuRvD0Edb6LP4SCZPr E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQFAAWRt1CQ/khM/2dsb2JhbABEhWS6NRZzgh4BAQEEAQEBNS8HChELGAkWDwkDAgECARUwBg0GAgEBiAwMvxgEkQEDlgGFa4pZgnI X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="10014917" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 29 Nov 2012 16:48:53 +0000 Received: from [10.55.90.217] (dhcp-10-55-90-217.cisco.com [10.55.90.217]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qATGmrg6017159 for ; Thu, 29 Nov 2012 16:48:53 GMT Message-ID: <50B791F6.9070904@cisco.com> Date: Thu, 29 Nov 2012 16:48:54 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IETF IPFIX Working Group References: <509D6F1D.8030107@cisco.com> In-Reply-To: <509D6F1D.8030107@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] Information Elements errata 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, 29 Nov 2012 16:48:55 -0000 FYI, this has now been done: On 09/11/12 21:01, Paul Aitken wrote: > Dear IPFIXers, > > > FYI, after Brian spotted the "layer2octetTotalCount" typo, I've asked > IANA to fix two IEs: > > > 1. #95 - rename "ApplicationId" to "applicationId" (ie, with a > lowercase "a"). > > - I verified the name in RFC 6795. > > > 2. #353 rename "layer2octetTotalCount" to "layer2OctetTotalCount" (ie, > with a capital "O"). > > Compare with #352 layer2OctetDeltaCount. > - it's a typo carried from > draft-kashima-ipfix-data-link-layer-monitoring, > which I'll correct in draft-ietf-ipfix-data-link-layer-monitoring. > > > P. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix