From bclaise@cisco.com Sun May 12 14:09:15 2013 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 8FA1021F8BB7; Sun, 12 May 2013 14:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.388 X-Spam-Level: X-Spam-Status: No, score=-10.388 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, DIET_1=0.083, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKRA0M5g9VNy; Sun, 12 May 2013 14:09:11 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 37A9121F8B45; Sun, 12 May 2013 14:09:07 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4CL960i007396; Sun, 12 May 2013 23:09:06 +0200 (CEST) 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 r4CL8XRG019594; Sun, 12 May 2013 23:08:49 +0200 (CEST) Message-ID: <519004D1.20005@cisco.com> Date: Sun, 12 May 2013 23:08:33 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ted Lemon References: <20130512161855.10646.39371.idtracker@ietfa.amsl.com> In-Reply-To: <20130512161855.10646.39371.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------090308020304090102070209" Cc: "ipfix@ietf.org" , The IESG , draft-ietf-ipfix-flow-selection-tech@tools.ietf.org, ipfix-chairs@tools.ietf.org Subject: Re: [IPFIX] Ted Lemon's No Objection on draft-ietf-ipfix-flow-selection-tech-16: (with COMMENT) 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, 12 May 2013 21:09:16 -0000 This is a multi-part message in MIME format. --------------090308020304090102070209 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Ted, > Ted Lemon has entered the following ballot position for > draft-ietf-ipfix-flow-selection-tech-16: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The terms "Intermediate Flow Selection Process" and "Intermediate > Selection Process" are so similar that I had to read the glossary entry > for the former several times in order to catch the difference. If > possible, it would be better to use a different name to refer to this > process. I realize this is a central bit of terminology in this draft, so > the request may seem a bit extreme, but it looks like it's been newly > introduced in this particular draft, so it's not too late to do something > about it. I'm not convinced that fixing it is worth the trouble, but I > raise the issue because it tripped me up; it will probably trip up other > new readers of the document. Just replying to this COMMENT above. Here is a little bit of history. RFC 6183, IP Flow Information Export (IPFIX) Mediation: Framework, specified a couple of terms. Those terms (and "Intermediate Selection Process" was one of them) were generic terms to be used by the different RFCs: RFC 6235, draft-ietf-ipfix-a9n-08, draft-ietf-ipfix-flow-selection-tech-16 , draft-ietf-ipfix-mediation-protocol-04 However, when developing draft-ietf-ipfix-flow-selection-tech-16, the authors realized that the "Intermediate Selection Process" definition [RFC6183] was not suitable. Hence the redefinition into "Intermediate Flow Selection Process". This was discussed recently on the IPFIX mailing list, and the conclusion was to add the section 4 "Difference between Intermediate Flow Selection Process and Intermediate Selection Process" While the situation is not ideal, my advice would be to leave the situation as it is. I let the authors respond to the rest. Note: maybe you meant 6.1.2 in your next comment. Regards, Benoit > > In section 6.2.1, I assume that the flow key is substantially smaller > than the flow cache entry, but this is a bit surprising. I'm assuming the > flow cache entry is somehow a heavier-weight thing, but it's not obvious > what that extra weight is. I went looking for a definition of "flow > cache" and didn't find one in any of the referenced RFCs. It might be > helpful to have a glossary entry that briefly describes the flow cache. > Presumably it's just the set of all flow records; if so, the definition > of flow record in 5101 doesn't give me a basis for thinking that it's > much larger than a flow key. None of this is intended to imply that the > text is wrong; just that it might help to have a bit more exposition on > the topic. > > 6.2.2.1: what's a flow position? > > Aside from these observations, which may or may not actually be helpful, > the document looks good—thanks for doing the work! > > > > --------------090308020304090102070209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Ted,
Ted Lemon has entered the following ballot position for
draft-ietf-ipfix-flow-selection-tech-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.




----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The terms "Intermediate Flow Selection Process" and "Intermediate
Selection Process" are so similar that I had to read the glossary entry
for the former several times in order to catch the difference. If
possible, it would be better to use a different name to refer to this
process. I realize this is a central bit of terminology in this draft, so
the request may seem a bit extreme, but it looks like it's been newly
introduced in this particular draft, so it's not too late to do something
about it.   I'm not convinced that fixing it is worth the trouble, but I
raise the issue because it tripped me up; it will probably trip up other
new readers of the document.
Just replying to this COMMENT above.

Here is a little bit of history.
RFC 6183, IP Flow Information Export (IPFIX) Mediation: Framework, specified a couple of terms. Those terms (and  "Intermediate Selection Process" was one of them) were generic terms to be used by the different RFCs: RFC 6235,
draft-ietf-ipfix-a9n-08, draft-ietf-ipfix-flow-selection-tech-16, draft-ietf-ipfix-mediation-protocol-04
However, when developing draft-ietf-ipfix-flow-selection-tech-16, the authors realized that the "Intermediate Selection Process" definition [RFC6183] was not suitable. Hence the redefinition into "Intermediate Flow Selection Process".

This was discussed recently on the IPFIX mailing list, and the conclusion was to add the section 4 "Difference between Intermediate Flow Selection Process and Intermediate Selection Process"

While the situation is not ideal, my advice would be to leave the situation as it is.

I let the authors respond to the rest.
Note: maybe you meant 6.1.2 in your next comment.

Regards, Benoit

In section 6.2.1, I assume that the flow key is substantially smaller
than the flow cache entry, but this is a bit surprising. I'm assuming the
flow cache entry is somehow a heavier-weight thing, but it's not obvious
what that extra weight is. I went looking for a definition of "flow
cache" and didn't find one in any of the referenced RFCs. It might be
helpful to have a glossary entry that briefly describes the flow cache.
Presumably it's just the set of all flow records; if so, the definition
of flow record in 5101 doesn't give me a basis for thinking that it's
much larger than a flow key. None of this is intended to imply that the
text is wrong; just that it might help to have a bit more exposition on
the topic.

6.2.2.1: what's a flow position?

Aside from these observations, which may or may not actually be helpful,
the document looks good—thanks for doing the work!

--------------090308020304090102070209-- From Ted.Lemon@nominum.com Sun May 12 14:41:51 2013 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 AEF0121F8B18; Sun, 12 May 2013 14:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrRic7aSC7MD; Sun, 12 May 2013 14:41:44 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id C4B4321F8624; Sun, 12 May 2013 14:41:43 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUZAMl5aNaWHfA2T7TOCzbkOUbaWiHFI7@postini.com; Sun, 12 May 2013 14:41:43 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 272BC1B80B0; Sun, 12 May 2013 14:41:43 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1A60B19005D; Sun, 12 May 2013 14:41:43 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 12 May 2013 14:41:43 -0700 From: Ted Lemon To: Benoit Claise Thread-Topic: Ted Lemon's No Objection on draft-ietf-ipfix-flow-selection-tech-16: (with COMMENT) Thread-Index: AQHOT1T18x5ykKt+c0eY8FBv9M1KiJkCiaoA Date: Sun, 12 May 2013 21:41:42 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077517E445@mbx-01.win.nominum.com> References: <20130512161855.10646.39371.idtracker@ietfa.amsl.com> <519004D1.20005@cisco.com> In-Reply-To: <519004D1.20005@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B63077517E445mbx01winnominum_" MIME-Version: 1.0 Cc: "ipfix@ietf.org" , The IESG , "" , "" Subject: Re: [IPFIX] Ted Lemon's No Objection on draft-ietf-ipfix-flow-selection-tech-16: (with COMMENT) 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, 12 May 2013 21:41:51 -0000 --_000_8D23D4052ABE7A4490E77B1A012B63077517E445mbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On May 12, 2013, at 5:08 PM, Benoit Claise > wrote: This was discussed recently on the IPFIX mailing list, and the conclusion w= as to add the section 4 "Difference between Intermediate Flow Selection Pro= cess and Intermediate Selection Process" While the situation is not ideal, my advice would be to leave the situation= as it is. I figured it was something like that, but I felt I had to ask. :) --_000_8D23D4052ABE7A4490E77B1A012B63077517E445mbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: <8E696B15666D94448BC3ACE5BAF2B76B@nominum.com> Content-Transfer-Encoding: quoted-printable
On May 12, 2013, at 5:08 PM, Benoit Claise <bclaise@cisco.com> wrote:
This was discussed recently on the IPFIX mailing list, and the conclusion was t= o add the section 4 "Difference between Intermediate Flow Selection Pr= ocess and Intermediate Selection Process"

While the situation is not ideal, my advice would be to leave the situation as i= t is.

I figured it was something like that, but I felt I had to ask. :)

--_000_8D23D4052ABE7A4490E77B1A012B63077517E445mbx01winnominum_-- From trammell@tik.ee.ethz.ch Thu May 16 08:45:42 2013 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 0B6E521F901F for ; Thu, 16 May 2013 08:45:42 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eErSeC3GagtN for ; Thu, 16 May 2013 08:45:36 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id F358121F92EB for ; Thu, 16 May 2013 08:45:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id EBD1AD9309 for ; Thu, 16 May 2013 17:45:05 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2FZgIcRrxxDS for ; Thu, 16 May 2013 17:45:05 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id AFB2AD9308 for ; Thu, 16 May 2013 17:45:05 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 16 May 2013 17:45:05 +0200 Message-Id: <8A033836-640F-4E7B-BCD4-79051464DD3A@tik.ee.ethz.ch> To: IETF IPFIX Working Group Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [IPFIX] initiatorOctets/initiatorPackets/responderOctets/responderPackets change X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 15:45:42 -0000 Greetings, all, Following a previous suggestion to update propose we modify the names = and definitions of the initiatorOctets(231), responderOctets(232), = initiatorPackets(298), and responderPackets(299) as follows, (1) to = bring them in line with the naming of other IPFIX Information Elements, = (2) to allow them to be used by RFC 5103-compliant biflow Exporting = Processes, and (3) to ensure (especially in the case of 298 and 299) = that the descriptions are interoperably implemented. I think the proposed descriptions reflect the intent of the present = descriptions, within the context of RFC 5103 terminology, and should = therefore not have any impact on interoperability; I note that the = description of IEs 298 and 299 are, however, not decipherable as = written, so I may be taking some necessary liberty with my = interpretation. Element ID: 232 Name: appOctetDeltaCount Data Type: unsigned64 Semantics: deltaCounter Description: The number of octets, excluding IP header(s) and Layer 4 transport = protocol header(s), observed for this Flow at the Observation Point = since the previous report (if any). Element ID: 233 Name: reverseAppOctetDeltaCount Data Type: unsigned64 Semantics: deltaCounter Description: The number of octets, excluding IP header(s) and Layer 4 transport = protocol header(s), observed for the reverse direction of this Flow, as = defined in RFC 5103, at the Observation Point since the previous report = (if any). If present in a Flow Record along with appOctetDeltaCount, = causes appOctetDeltaCount to refer to the forward direction of the Flow. = If present in a Flow Record, implies that that Flow Record is exported = with direction assigned by the initiator (as in section 5.1 of RFC = 5103), unless contradicted by a biflowDirection Information Element = present in the Flow Record or otherwise applicable to the Flow Record's = scope. Element ID: 298 Name: appPacketDeltaCount Data Type: unsigned64 Semantics: deltaCounter Description: The number of packets containing at least one octet beyond the IP = header(s) and Layer 4 transport protocol header(s), observed for this = Flow at the Observation Point since the previous report (if any). Element ID: 299 Name: reverseAppPacketDeltaCount Data Type: unsigned64 Semantics: deltaCounter Description: The number of packets containing at least one octet beyond the IP = header(s) and Layer 4 transport protocol header(s), observed for the = reverse direction of this Flow, as defined in RFC 5103, at the = Observation Point since the previous report (if any). If present in a = Flow Record along with appPacketDeltaCount, causes appPacketDeltaCount = to refer to the forward direction of the Flow. If present in a Flow = Record, implies that that Flow Record is exported with direction = assigned by the initiator (as in section 5.1 of RFC 5103), unless = contradicted by a biflowDirection Information Element present in the = Flow Record or otherwise applicable to the Flow Record's scope. Following discussion on the list, I intend to submit this proposed = change to the IE-DOCTORS for review. Thoughts? Many thanks, best regards, Brian= From paitken@cisco.com Thu May 16 09:10:08 2013 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 75DC721F93A5 for ; Thu, 16 May 2013 09:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwP9Q0sYTUrg for ; Thu, 16 May 2013 09:10:04 -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 C757521F93B1 for ; Thu, 16 May 2013 09:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3726; q=dns/txt; s=iport; t=1368720604; x=1369930204; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=jhzgV8u/f4d7kR6pAjCLkY/rGaUPAwvk5PCg8whN8K0=; b=GrbVEssp0wwM6DGuH2xRg32i4itjAiP6gYLM9buhI6HKmoUcyJoqh//L R0AhfBWAxSBe4+FDTKua20emtERKizmzJ3JE1CCh3VnjU9DznLkw7s62N 1i/kiF6GL9dV5nH6hezpXjO11FKgfrrbfu16RW31hyL81FXTrhicURtpl 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAMoDlVGQ/khL/2dsb2JhbABbgwc3wUZ9FnSCHwEBAQQBAQE1NgoBEAsYCRYECwkDAgECARUwBg0BBQIBAYgIDL0qBIJUjEsHg1UDlziGHosigViBOTs X-IronPort-AV: E=Sophos;i="4.87,684,1363132800"; d="scan'208";a="13977482" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 16 May 2013 16:10:02 +0000 Received: from [10.61.197.177] ([10.61.197.177]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4GG9xwS006106; Thu, 16 May 2013 16:09:59 GMT Message-ID: <519504D8.3000400@cisco.com> Date: Thu, 16 May 2013 17:10:00 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Brian Trammell References: <8A033836-640F-4E7B-BCD4-79051464DD3A@tik.ee.ethz.ch> In-Reply-To: <8A033836-640F-4E7B-BCD4-79051464DD3A@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] initiatorOctets/initiatorPackets/responderOctets/responderPackets change X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 16:10:08 -0000 Brian, 1. Some mistake in the numbering in your new definitions: you've written 232 and 233 instead of 231 and 232. 2. What's the significance of "app" in these names? "Applicable"? "Application"? "Appearing"? "Appended"? "Approved"? "Appropriate"? "Approximate"? ... P. On 16/05/13 16:45, Brian Trammell wrote: > Greetings, all, > > Following a previous suggestion to update propose we modify the names and definitions of the initiatorOctets(231), responderOctets(232), initiatorPackets(298), and responderPackets(299) as follows, (1) to bring them in line with the naming of other IPFIX Information Elements, (2) to allow them to be used by RFC 5103-compliant biflow Exporting Processes, and (3) to ensure (especially in the case of 298 and 299) that the descriptions are interoperably implemented. > > I think the proposed descriptions reflect the intent of the present descriptions, within the context of RFC 5103 terminology, and should therefore not have any impact on interoperability; I note that the description of IEs 298 and 299 are, however, not decipherable as written, so I may be taking some necessary liberty with my interpretation. > > > Element ID: 232 > Name: appOctetDeltaCount > Data Type: unsigned64 > Semantics: deltaCounter > Description: > > The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any). > > > Element ID: 233 > Name: reverseAppOctetDeltaCount > Data Type: unsigned64 > Semantics: deltaCounter > Description: > > The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for the reverse direction of this Flow, as defined in RFC 5103, at the Observation Point since the previous report (if any). If present in a Flow Record along with appOctetDeltaCount, causes appOctetDeltaCount to refer to the forward direction of the Flow. If present in a Flow Record, implies that that Flow Record is exported with direction assigned by the initiator (as in section 5.1 of RFC 5103), unless contradicted by a biflowDirection Information Element present in the Flow Record or otherwise applicable to the Flow Record's scope. > > > Element ID: 298 > Name: appPacketDeltaCount > Data Type: unsigned64 > Semantics: deltaCounter > Description: > > The number of packets containing at least one octet beyond the IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any). > > > Element ID: 299 > Name: reverseAppPacketDeltaCount > Data Type: unsigned64 > Semantics: deltaCounter > Description: > > The number of packets containing at least one octet beyond the IP header(s) and Layer 4 transport protocol header(s), observed for the reverse direction of this Flow, as defined in RFC 5103, at the Observation Point since the previous report (if any). If present in a Flow Record along with appPacketDeltaCount, causes appPacketDeltaCount to refer to the forward direction of the Flow. If present in a Flow Record, implies that that Flow Record is exported with direction assigned by the initiator (as in section 5.1 of RFC 5103), unless contradicted by a biflowDirection Information Element present in the Flow Record or otherwise applicable to the Flow Record's scope. > > > Following discussion on the list, I intend to submit this proposed change to the IE-DOCTORS for review. > > Thoughts? > > Many thanks, best regards, > > Brian > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Fri May 17 00:45:39 2013 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 3E2E621F9227 for ; Fri, 17 May 2013 00:45:39 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mq5J05L5T2ue for ; Fri, 17 May 2013 00:45:34 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4769E21F8BC5 for ; Fri, 17 May 2013 00:45:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3256AD930C for ; Fri, 17 May 2013 09:45:32 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SDT5haijRQIb for ; Fri, 17 May 2013 09:45:32 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 034FBD9308 for ; Fri, 17 May 2013 09:45:32 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 17 May 2013 09:45:31 +0200 References: <615A5850-507D-4248-8B32-5A0EDEA0F3A3@tik.ee.ethz.ch> To: IETF IPFIX Working Group Message-Id: <38AF2656-2265-458E-9100-65DAD967458D@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [IPFIX] Fwd: initiatorOctets/initiatorPackets/responderOctets/responderPackets change 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, 17 May 2013 07:45:39 -0000 Oops, hit reply instead of reply all... Begin forwarded message: > From: Brian Trammell > Subject: Re: [Sender: ipfix-bounces@ietf.org] [IPFIX] = initiatorOctets/initiatorPackets/responderOctets/responderPackets change > Date: 16 May 2013 19:22:10 GMT+02:00 > To: Paul Aitken >=20 > Hi, Paul, >=20 > Indeed, decrement the numbers in the definition. >=20 > "app" is intended to abbreviate "application". Not a huge fan of this = name, but I can't come up with anything more precise that isn't = significantly longer. "layer7"? "overTransport"? "transported"?=20 >=20 > Regards, >=20 > Brian >=20 > Sent from my iPhone >=20 > On 16.05.2013, at 18:10, Paul Aitken wrote: >=20 >> Brian, >>=20 >> 1. Some mistake in the numbering in your new definitions: you've = written 232 and 233 instead of 231 and 232. >>=20 >> 2. What's the significance of "app" in these names? "Applicable"? = "Application"? "Appearing"? "Appended"? "Approved"? "Appropriate"? = "Approximate"? ... >>=20 >> P. >>=20 >>=20 >> On 16/05/13 16:45, Brian Trammell wrote: >>> Greetings, all, >>>=20 >>> Following a previous suggestion to update propose we modify the = names and definitions of the initiatorOctets(231), responderOctets(232), = initiatorPackets(298), and responderPackets(299) as follows, (1) to = bring them in line with the naming of other IPFIX Information Elements, = (2) to allow them to be used by RFC 5103-compliant biflow Exporting = Processes, and (3) to ensure (especially in the case of 298 and 299) = that the descriptions are interoperably implemented. >>>=20 >>> I think the proposed descriptions reflect the intent of the present = descriptions, within the context of RFC 5103 terminology, and should = therefore not have any impact on interoperability; I note that the = description of IEs 298 and 299 are, however, not decipherable as = written, so I may be taking some necessary liberty with my = interpretation. >>>=20 >>>=20 >>> Element ID: 232 >>> Name: appOctetDeltaCount >>> Data Type: unsigned64 >>> Semantics: deltaCounter >>> Description: >>>=20 >>> The number of octets, excluding IP header(s) and Layer 4 transport = protocol header(s), observed for this Flow at the Observation Point = since the previous report (if any). >>>=20 >>>=20 >>> Element ID: 233 >>> Name: reverseAppOctetDeltaCount >>> Data Type: unsigned64 >>> Semantics: deltaCounter >>> Description: >>>=20 >>> The number of octets, excluding IP header(s) and Layer 4 transport = protocol header(s), observed for the reverse direction of this Flow, as = defined in RFC 5103, at the Observation Point since the previous report = (if any). If present in a Flow Record along with appOctetDeltaCount, = causes appOctetDeltaCount to refer to the forward direction of the Flow. = If present in a Flow Record, implies that that Flow Record is exported = with direction assigned by the initiator (as in section 5.1 of RFC = 5103), unless contradicted by a biflowDirection Information Element = present in the Flow Record or otherwise applicable to the Flow Record's = scope. >>>=20 >>>=20 >>> Element ID: 298 >>> Name: appPacketDeltaCount >>> Data Type: unsigned64 >>> Semantics: deltaCounter >>> Description: >>>=20 >>> The number of packets containing at least one octet beyond the IP = header(s) and Layer 4 transport protocol header(s), observed for this = Flow at the Observation Point since the previous report (if any). >>>=20 >>>=20 >>> Element ID: 299 >>> Name: reverseAppPacketDeltaCount >>> Data Type: unsigned64 >>> Semantics: deltaCounter >>> Description: >>>=20 >>> The number of packets containing at least one octet beyond the IP = header(s) and Layer 4 transport protocol header(s), observed for the = reverse direction of this Flow, as defined in RFC 5103, at the = Observation Point since the previous report (if any). If present in a = Flow Record along with appPacketDeltaCount, causes appPacketDeltaCount = to refer to the forward direction of the Flow. If present in a Flow = Record, implies that that Flow Record is exported with direction = assigned by the initiator (as in section 5.1 of RFC 5103), unless = contradicted by a biflowDirection Information Element present in the = Flow Record or otherwise applicable to the Flow Record's scope. >>>=20 >>>=20 >>> Following discussion on the list, I intend to submit this proposed = change to the IE-DOCTORS for review. >>>=20 >>> Thoughts? >>>=20 >>> Many thanks, best regards, >>>=20 >>> Brian >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix From andrewf@plixer.com Fri May 17 07:10:53 2013 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 9AA5621F937B for ; Fri, 17 May 2013 07:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIGEqOcLJQI8 for ; Fri, 17 May 2013 07:10:49 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [64.140.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id 29D2021F93EC for ; Fri, 17 May 2013 07:10:49 -0700 (PDT) Received: from [10.11.1.15] ([10.11.1.15]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 May 2013 10:10:47 -0400 Message-ID: <51963A69.70908@plixer.com> Date: Fri, 17 May 2013 10:10:49 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Brian Trammell References: <615A5850-507D-4248-8B32-5A0EDEA0F3A3@tik.ee.ethz.ch> <38AF2656-2265-458E-9100-65DAD967458D@tik.ee.ethz.ch> In-Reply-To: <38AF2656-2265-458E-9100-65DAD967458D@tik.ee.ethz.ch> Content-Type: multipart/alternative; boundary="------------010507030807090709080009" X-OriginalArrivalTime: 17 May 2013 14:10:47.0729 (UTC) FILETIME=[542B4A10:01CE5308] Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Fwd: initiatorOctets/initiatorPackets/responderOctets/responderPackets change 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, 17 May 2013 14:10:53 -0000 This is a multi-part message in MIME format. --------------010507030807090709080009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Brian, If you are looking for consistency I'd go with "layer7". There are already 3 "layer2" IEs including 2 octet counts (layer2OctetDeltaCount and layer2OctetTotalCount). Also the the table of values for classificationEngineId (101) all use L# or layer # in their descriptions. -Andrew On 05/17/2013 03:45 AM, Brian Trammell wrote: > Oops, hit reply instead of reply all... > > Begin forwarded message: > >> From: Brian Trammell >> Subject: Re: [Sender: ipfix-bounces@ietf.org] [IPFIX] initiatorOctets/initiatorPackets/responderOctets/responderPackets change >> Date: 16 May 2013 19:22:10 GMT+02:00 >> To: Paul Aitken >> >> Hi, Paul, >> >> Indeed, decrement the numbers in the definition. >> >> "app" is intended to abbreviate "application". Not a huge fan of this name, but I can't come up with anything more precise that isn't significantly longer. "layer7"? "overTransport"? "transported"? >> >> Regards, >> >> Brian >> >> Sent from my iPhone >> >> On 16.05.2013, at 18:10, Paul Aitken wrote: >> >>> Brian, >>> >>> 1. Some mistake in the numbering in your new definitions: you've written 232 and 233 instead of 231 and 232. >>> >>> 2. What's the significance of "app" in these names? "Applicable"? "Application"? "Appearing"? "Appended"? "Approved"? "Appropriate"? "Approximate"? ... >>> >>> P. >>> >>> >>> On 16/05/13 16:45, Brian Trammell wrote: >>>> Greetings, all, >>>> >>>> Following a previous suggestion to update propose we modify the names and definitions of the initiatorOctets(231), responderOctets(232), initiatorPackets(298), and responderPackets(299) as follows, (1) to bring them in line with the naming of other IPFIX Information Elements, (2) to allow them to be used by RFC 5103-compliant biflow Exporting Processes, and (3) to ensure (especially in the case of 298 and 299) that the descriptions are interoperably implemented. >>>> >>>> I think the proposed descriptions reflect the intent of the present descriptions, within the context of RFC 5103 terminology, and should therefore not have any impact on interoperability; I note that the description of IEs 298 and 299 are, however, not decipherable as written, so I may be taking some necessary liberty with my interpretation. >>>> >>>> >>>> Element ID: 232 >>>> Name: appOctetDeltaCount >>>> Data Type: unsigned64 >>>> Semantics: deltaCounter >>>> Description: >>>> >>>> The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any). >>>> >>>> >>>> Element ID: 233 >>>> Name: reverseAppOctetDeltaCount >>>> Data Type: unsigned64 >>>> Semantics: deltaCounter >>>> Description: >>>> >>>> The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for the reverse direction of this Flow, as defined in RFC 5103, at the Observation Point since the previous report (if any). If present in a Flow Record along with appOctetDeltaCount, causes appOctetDeltaCount to refer to the forward direction of the Flow. If present in a Flow Record, implies that that Flow Record is exported with direction assigned by the initiator (as in section 5.1 of RFC 5103), unless contradicted by a biflowDirection Information Element present in the Flow Record or otherwise applicable to the Flow Record's scope. >>>> >>>> >>>> Element ID: 298 >>>> Name: appPacketDeltaCount >>>> Data Type: unsigned64 >>>> Semantics: deltaCounter >>>> Description: >>>> >>>> The number of packets containing at least one octet beyond the IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any). >>>> >>>> >>>> Element ID: 299 >>>> Name: reverseAppPacketDeltaCount >>>> Data Type: unsigned64 >>>> Semantics: deltaCounter >>>> Description: >>>> >>>> The number of packets containing at least one octet beyond the IP header(s) and Layer 4 transport protocol header(s), observed for the reverse direction of this Flow, as defined in RFC 5103, at the Observation Point since the previous report (if any). If present in a Flow Record along with appPacketDeltaCount, causes appPacketDeltaCount to refer to the forward direction of the Flow. If present in a Flow Record, implies that that Flow Record is exported with direction assigned by the initiator (as in section 5.1 of RFC 5103), unless contradicted by a biflowDirection Information Element present in the Flow Record or otherwise applicable to the Flow Record's scope. >>>> >>>> >>>> Following discussion on the list, I intend to submit this proposed change to the IE-DOCTORS for review. >>>> >>>> Thoughts? >>>> >>>> Many thanks, best regards, >>>> >>>> Brian >>>> _______________________________________________ >>>> 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 --------------010507030807090709080009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Brian,

If you are looking for consistency I'd go with "layer7".  There are already 3 "layer2" IEs including 2 octet counts (layer2OctetDeltaCount and layer2OctetTotalCount).

Also the the table of values for  classificationEngineId (101) all use L# or layer # in their descriptions.

-Andrew



On 05/17/2013 03:45 AM, Brian Trammell wrote:
Oops, hit reply instead of reply all...

Begin forwarded message:


From: Brian Trammell <trammell@tik.ee.ethz.ch>
Subject: Re: [Sender: ipfix-bounces@ietf.org] [IPFIX] initiatorOctets/initiatorPackets/responderOctets/responderPackets change
Date: 16 May 2013 19:22:10 GMT+02:00
To: Paul Aitken <paitken@cisco.com>

Hi, Paul,

Indeed, decrement the numbers in the definition.

"app" is intended to abbreviate "application". Not a huge fan of this name, but I can't come up with anything more precise that isn't significantly longer. "layer7"? "overTransport"? "transported"? 

Regards,

Brian

Sent from my iPhone

On 16.05.2013, at 18:10, Paul Aitken <paitken@cisco.com> wrote:


Brian,

1. Some mistake in the numbering in your new definitions: you've written 232 and 233 instead of 231 and 232.

2. What's the significance of "app" in these names? "Applicable"? "Application"? "Appearing"? "Appended"? "Approved"? "Appropriate"? "Approximate"? ...

P.


On 16/05/13 16:45, Brian Trammell wrote:

Greetings, all,

Following a previous suggestion to update  propose we modify the names and definitions of the initiatorOctets(231), responderOctets(232), initiatorPackets(298), and responderPackets(299) as follows, (1) to bring them in line with the naming of other IPFIX Information Elements, (2) to allow them to be used by RFC 5103-compliant biflow Exporting Processes, and (3) to ensure (especially in the case of 298 and 299) that the descriptions are interoperably implemented.

I think the proposed descriptions reflect the intent of the present descriptions, within the context of RFC 5103 terminology, and should therefore not have any impact on interoperability; I note that the description of IEs 298 and 299 are, however, not decipherable as written, so I may be taking some necessary liberty with my interpretation.


Element ID: 232
Name:       appOctetDeltaCount
Data Type:  unsigned64
Semantics:  deltaCounter
Description:

The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any).


Element ID: 233
Name:       reverseAppOctetDeltaCount
Data Type:  unsigned64
Semantics:  deltaCounter
Description:

The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for the reverse direction of this Flow, as defined in RFC 5103, at the Observation Point since the previous report (if any). If present in a Flow Record along with appOctetDeltaCount, causes appOctetDeltaCount to refer to the forward direction of the Flow. If present in a Flow Record, implies that that Flow Record is exported with direction assigned by the initiator (as in section 5.1 of RFC 5103), unless contradicted by a biflowDirection Information Element present in the Flow Record or otherwise applicable to the Flow Record's scope.


Element ID: 298
Name:       appPacketDeltaCount
Data Type:  unsigned64
Semantics:  deltaCounter
Description:

The number of packets containing at least one octet beyond the IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any).


Element ID: 299
Name:       reverseAppPacketDeltaCount
Data Type:  unsigned64
Semantics:  deltaCounter
Description:

The number of packets containing at least one octet beyond the IP header(s) and Layer 4 transport protocol header(s), observed for the reverse direction of this Flow, as defined in RFC 5103, at the Observation Point since the previous report (if any). If present in a Flow Record along with appPacketDeltaCount, causes appPacketDeltaCount to refer to the forward direction of the Flow. If present in a Flow Record, implies that that Flow Record is exported with direction assigned by the initiator (as in section 5.1 of RFC 5103), unless contradicted by a biflowDirection Information Element present in the Flow Record or otherwise applicable to the Flow Record's scope.


Following discussion on the list, I intend to submit this proposed change to the IE-DOCTORS for review.

Thoughts?

Many thanks, best regards,

Brian
_______________________________________________
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

--------------010507030807090709080009-- From trammell@tik.ee.ethz.ch Fri May 17 07:34:01 2013 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 1209921F9347 for ; Fri, 17 May 2013 07:34:01 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsJoRxDH+a-X for ; Fri, 17 May 2013 07:33:56 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 15E8121F92B7 for ; Fri, 17 May 2013 07:33:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8FCF7D9312; Fri, 17 May 2013 16:33:53 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YfomiR-pwWWZ; Fri, 17 May 2013 16:33:53 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (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 36879D9307; Fri, 17 May 2013 16:33:53 +0200 (MEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: <51963A69.70908@plixer.com> Date: Fri, 17 May 2013 16:33:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <615A5850-507D-4248-8B32-5A0EDEA0F3A3@tik.ee.ethz.ch> <38AF2656-2265-458E-9100-65DAD967458D@tik.ee.ethz.ch> <51963A69.70908@plixer.com> To: Andrew Feren X-Mailer: Apple Mail (2.1503) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Fwd: initiatorOctets/initiatorPackets/responderOctets/responderPackets change 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, 17 May 2013 14:34:01 -0000 Hi, Andrew. Hm... Good point. Thanks. (Pedantically: "everything under Layer 4" might also include layer 5 -- = if you're of the opinion that HTTP is really a session layer nowadays -- = but I think most everyone will understand what is meant.) So I amend my proposal to: Element ID: 231 Name: layer7OctetDeltaCount Data Type: unsigned64 Semantics: deltaCounter Description: The number of octets, excluding IP header(s) and Layer 4 transport = protocol header(s), observed for this Flow at the Observation Point = since the previous report (if any). Element ID: 232 Name: reverseLayer7OctetDeltaCount Data Type: unsigned64 Semantics: deltaCounter Description: The number of octets, excluding IP header(s) and Layer 4 transport = protocol header(s), observed for the reverse direction of this Flow, as = defined in RFC 5103, at the Observation Point since the previous report = (if any). If present in a Flow Record along with layer7OctetDeltaCount, = causes layer7OctetDeltaCount to refer to the forward direction of the = Flow. If present in a Flow Record, implies that that Flow Record is = exported with direction assigned by the initiator (as in section 5.1 of = RFC 5103), unless contradicted by a biflowDirection Information Element = present in the Flow Record or otherwise applicable to the Flow Record's = scope. Element ID: 298 Name: layer7PacketDeltaCount Data Type: unsigned64 Semantics: deltaCounter Description: The number of packets containing at least one octet beyond the IP = header(s) and Layer 4 transport protocol header(s), observed for this = Flow at the Observation Point since the previous report (if any). Element ID: 299 Name: reverseLayer7PacketDeltaCount Data Type: unsigned64 Semantics: deltaCounter Description: The number of packets containing at least one octet beyond the IP = header(s) and Layer 4 transport protocol header(s), observed for the = reverse direction of this Flow, as defined in RFC 5103, at the = Observation Point since the previous report (if any). If present in a = Flow Record along with layer7PacketDeltaCount, causes = layer7PacketDeltaCount to refer to the forward direction of the Flow. If = present in a Flow Record, implies that that Flow Record is exported with = direction assigned by the initiator (as in section 5.1 of RFC 5103), = unless contradicted by a biflowDirection Information Element present in = the Flow Record or otherwise applicable to the Flow Record's scope. Cheers, Brian On May 17, 2013, at 4:10 PM, Andrew Feren wrote: > Hi Brian, >=20 > If you are looking for consistency I'd go with "layer7". There are = already 3 "layer2" IEs including 2 octet counts (layer2OctetDeltaCount = and layer2OctetTotalCount). >=20 > Also the the table of values for classificationEngineId (101) all use = L# or layer # in their descriptions. >=20 > -Andrew >=20 >=20 >=20 > On 05/17/2013 03:45 AM, Brian Trammell wrote: >> Oops, hit reply instead of reply all... >>=20 >> Begin forwarded message: >>=20 >>=20 >>> From: Brian Trammell >>>=20 >>> Subject: Re: [Sender:=20 >>> ipfix-bounces@ietf.org >>> ] [IPFIX] = initiatorOctets/initiatorPackets/responderOctets/responderPackets change >>> Date: 16 May 2013 19:22:10 GMT+02:00 >>> To: Paul Aitken=20 >>> >>>=20 >>>=20 >>> Hi, Paul, >>>=20 >>> Indeed, decrement the numbers in the definition. >>>=20 >>> "app" is intended to abbreviate "application". Not a huge fan of = this name, but I can't come up with anything more precise that isn't = significantly longer. "layer7"? "overTransport"? "transported"?=20 >>>=20 >>> Regards, >>>=20 >>> Brian >>>=20 >>> Sent from my iPhone >>>=20 >>> On 16.05.2013, at 18:10, Paul Aitken=20 >>> >>> wrote: >>>=20 >>>=20 >>>> Brian, >>>>=20 >>>> 1. Some mistake in the numbering in your new definitions: you've = written 232 and 233 instead of 231 and 232. >>>>=20 >>>> 2. What's the significance of "app" in these names? "Applicable"? = "Application"? "Appearing"? "Appended"? "Approved"? "Appropriate"? = "Approximate"? ... >>>>=20 >>>> P. >>>>=20 >>>>=20 >>>> On 16/05/13 16:45, Brian Trammell wrote: >>>>=20 >>>>> Greetings, all, >>>>>=20 >>>>> Following a previous suggestion to update propose we modify the = names and definitions of the initiatorOctets(231), responderOctets(232), = initiatorPackets(298), and responderPackets(299) as follows, (1) to = bring them in line with the naming of other IPFIX Information Elements, = (2) to allow them to be used by RFC 5103-compliant biflow Exporting = Processes, and (3) to ensure (especially in the case of 298 and 299) = that the descriptions are interoperably implemented. >>>>>=20 >>>>> I think the proposed descriptions reflect the intent of the = present descriptions, within the context of RFC 5103 terminology, and = should therefore not have any impact on interoperability; I note that = the description of IEs 298 and 299 are, however, not decipherable as = written, so I may be taking some necessary liberty with my = interpretation. >>>>>=20 >>>>>=20 >>>>> Element ID: 232 >>>>> Name: appOctetDeltaCount >>>>> Data Type: unsigned64 >>>>> Semantics: deltaCounter >>>>> Description: >>>>>=20 >>>>> The number of octets, excluding IP header(s) and Layer 4 transport = protocol header(s), observed for this Flow at the Observation Point = since the previous report (if any). >>>>>=20 >>>>>=20 >>>>> Element ID: 233 >>>>> Name: reverseAppOctetDeltaCount >>>>> Data Type: unsigned64 >>>>> Semantics: deltaCounter >>>>> Description: >>>>>=20 >>>>> The number of octets, excluding IP header(s) and Layer 4 transport = protocol header(s), observed for the reverse direction of this Flow, as = defined in RFC 5103, at the Observation Point since the previous report = (if any). If present in a Flow Record along with appOctetDeltaCount, = causes appOctetDeltaCount to refer to the forward direction of the Flow. = If present in a Flow Record, implies that that Flow Record is exported = with direction assigned by the initiator (as in section 5.1 of RFC = 5103), unless contradicted by a biflowDirection Information Element = present in the Flow Record or otherwise applicable to the Flow Record's = scope. >>>>>=20 >>>>>=20 >>>>> Element ID: 298 >>>>> Name: appPacketDeltaCount >>>>> Data Type: unsigned64 >>>>> Semantics: deltaCounter >>>>> Description: >>>>>=20 >>>>> The number of packets containing at least one octet beyond the IP = header(s) and Layer 4 transport protocol header(s), observed for this = Flow at the Observation Point since the previous report (if any). >>>>>=20 >>>>>=20 >>>>> Element ID: 299 >>>>> Name: reverseAppPacketDeltaCount >>>>> Data Type: unsigned64 >>>>> Semantics: deltaCounter >>>>> Description: >>>>>=20 >>>>> The number of packets containing at least one octet beyond the IP = header(s) and Layer 4 transport protocol header(s), observed for the = reverse direction of this Flow, as defined in RFC 5103, at the = Observation Point since the previous report (if any). If present in a = Flow Record along with appPacketDeltaCount, causes appPacketDeltaCount = to refer to the forward direction of the Flow. If present in a Flow = Record, implies that that Flow Record is exported with direction = assigned by the initiator (as in section 5.1 of RFC 5103), unless = contradicted by a biflowDirection Information Element present in the = Flow Record or otherwise applicable to the Flow Record's scope. >>>>>=20 >>>>>=20 >>>>> Following discussion on the list, I intend to submit this proposed = change to the IE-DOCTORS for review. >>>>>=20 >>>>> Thoughts? >>>>>=20 >>>>> Many thanks, best regards, >>>>>=20 >>>>> Brian >>>>> _______________________________________________ >>>>> IPFIX mailing list >>>>>=20 >>>>> IPFIX@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipfix >> _______________________________________________ >> IPFIX mailing list >>=20 >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >=20 From n.brownlee@auckland.ac.nz Tue May 21 19:13:27 2013 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 4CA5D21F930A for ; Tue, 21 May 2013 19:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ME0slWdygN0D for ; Tue, 21 May 2013 19:13:22 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id A733221F92CB for ; Tue, 21 May 2013 19:13:21 -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=1369188802; x=1400724802; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=8BxYtOnm+/dZRVJyjysXPNBIb7eZMgKagckjaPj5cfY=; b=Cbcg2JNTQQSLEEfNRNjPnMlvJ54+DV7kqwxiAnZU53ckfxLD63M2Mob4 JvtEyo35hoDff25mBLQbiENdiCSTJE3MUc7WoK8u7UYKePi6yer8QUsHY /So+12rRIco8xUy4BW46pLQdozZST6aDSleenoZNa1vL2bGa6PM287bRp s=; X-IronPort-AV: E=Sophos;i="4.87,718,1363086000"; d="scan'208";a="188192153" 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; 22 May 2013 14:13:19 +1200 Message-ID: <519C29BE.8050001@auckland.ac.nz> Date: Wed, 22 May 2013 14:13:18 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Questions about compliance statement in IPFIX-selection-techniqes draft 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, 22 May 2013 02:13:27 -0000 Hi all: draft-ietf-ipfix-flow-selection-tech-16 is now in IESG Evaluation; it currently has a blocking DISCUSS Section 6.1 contains a compliance statement, which says "In order to be compliant with this document, at least the Property Match Filtering MUST be implemented." The AD concerned asks whether we could remove this requirement. This was triggered by a remark in my Shepherd statement for this draft, which said "This draft raised IPR concerns, in the same manner as the PSAMP selection draft had done. Nick Duffield (AT&T) commented that the AT&T IPR claim relates only to statistical sampling, and PSAMP handled this by saying "at least on of the sampling techniques must be implemented." In this draft, we have tightened that up a little by saying "a conforming implementation MUST implement at least the Property Match Filtering." I realise now that the IPR in question was that relating to draft-krishnan-opsawg-large-flow-load-balancing, which was discussed on the IPFIX list back in Feb/Mar 2013; the issue that raised was cleared by the company concerned making an IPR declaration. That leaves us with the question about the compliance requirement. The motivation for this remains the same as it was for RFC 5475, "Sampling and Filtering Techniques for IP Packet Selection," the statement in section 6.1 simply refines it a little, and makes it clear to implementors what's needed for a minimal conforming implementation. So now, I need some feedback from the WG. Please send a note to the list saying "yes, keep the compliance statement in section 6.1" or "no, delete the compliance statement in section 6.1. Real soon now, please! Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From bclaise@cisco.com Tue May 21 23:35:42 2013 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 2CCDC21F9399 for ; Tue, 21 May 2013 23:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.417 X-Spam-Level: X-Spam-Status: No, score=-10.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s35jztG+LXHC for ; Tue, 21 May 2013 23:35:37 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id A89B921F8607 for ; Tue, 21 May 2013 23:35:36 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4M6ZUZO015790; Wed, 22 May 2013 08:35:30 +0200 (CEST) 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 r4M6Z4dV007920; Wed, 22 May 2013 08:35:19 +0200 (CEST) Message-ID: <519C6718.901@cisco.com> Date: Wed, 22 May 2013 08:35:04 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nevil Brownlee References: <519C29BE.8050001@auckland.ac.nz> In-Reply-To: <519C29BE.8050001@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] Questions about compliance statement in IPFIX-selection-techniqes draft 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, 22 May 2013 06:35:42 -0000 Hi Nevil, "yes, keep the compliance statement in section 6.1". I want to keep the consistency to makes it clear to implementors what's needed for a minimal conforming implementation, and to be similar to RFC 5475 Regards, Benoit (as a contributor) > Hi all: > > draft-ietf-ipfix-flow-selection-tech-16 is now in IESG Evaluation; > it currently has a blocking DISCUSS > > Section 6.1 contains a compliance statement, which says > "In order to be compliant with this document, at least the > Property Match Filtering MUST be implemented." > The AD concerned asks whether we could remove this requirement. > > This was triggered by a remark in my Shepherd statement for this draft, > which said > "This draft raised IPR concerns, in the same manner as the PSAMP > selection draft had done. Nick Duffield (AT&T) commented that > the AT&T IPR claim relates only to statistical sampling, and PSAMP > handled this by saying "at least on of the sampling techniques > must be implemented." > In this draft, we have tightened that up a little by saying > "a conforming implementation MUST implement at least the > Property Match Filtering." > I realise now that the IPR in question was that relating to > draft-krishnan-opsawg-large-flow-load-balancing, which was discussed > on the IPFIX list back in Feb/Mar 2013; the issue that raised was > cleared by the company concerned making an IPR declaration. > > That leaves us with the question about the compliance requirement. > The motivation for this remains the same as it was for RFC 5475, > "Sampling and Filtering Techniques for IP Packet Selection," > the statement in section 6.1 simply refines it a little, and makes it > clear to implementors what's needed for a minimal conforming > implementation. > > So now, I need some feedback from the WG. Please send a note to > the list saying > "yes, keep the compliance statement in section 6.1" or > "no, delete the compliance statement in section 6.1. > > Real soon now, please! > > Cheers, Nevil > > > From paitken@cisco.com Wed May 22 00:58:18 2013 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 8E58621F89AF for ; Wed, 22 May 2013 00:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbJ8bjFZi4GG for ; Wed, 22 May 2013 00:58:14 -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 E72EA21F9193 for ; Wed, 22 May 2013 00:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3483; q=dns/txt; s=iport; t=1369209489; x=1370419089; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=bpd0pQ3NzVCEtj6liVd3M3aKsbtSMkHeNwkkul33uTA=; b=JElveCNh6f2OntgpGtaauSC/vyW9ipt4F+xaYz4axOD7OP5zpk0xCdjS 4I0p/85xTPGSeaL/hz9PITMtPeeoWVNixdrwAodPiM5gCUnUgYjidJ92G qFUDWOzwqZ4l+x7AesQjvA5cOlN2YPo6WshPTQAJRhcAtVnJQvioBMbua U=; X-IronPort-AV: E=Sophos;i="4.87,718,1363132800"; d="scan'208";a="14100783" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 22 May 2013 07:58:06 +0000 Received: from [10.61.218.250] ([10.61.218.250]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4M7w3QQ001130; Wed, 22 May 2013 07:58:04 GMT Message-ID: <519C7A8C.6090105@cisco.com> Date: Wed, 22 May 2013 08:58:04 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Benoit Claise References: <519C29BE.8050001@auckland.ac.nz> <519C6718.901@cisco.com> In-Reply-To: <519C6718.901@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] Questions about compliance statement in IPFIX-selection-techniqes draft 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, 22 May 2013 07:58:18 -0000 Benoit, Nevil, All, Option 3, "yes and no". A clear specification of the compliance criteria is a must. However, with the current compliance statement an implementation of all the specified Flow Sampling techniques without Property Match Filtering, is not compliant. Similarly, a device which implements Hash-based Flow Filtering rather than Property Match Filtering is not compliant. We can't predict what future device requirements will be or how the draft will be used. Therefore the choice of Property Match Filtering as the compliance criteria seems somewhat arbitrary. It may seem like an obvious choice today, but in future might turn out like the 640KB limit. We don't want this to be a decision we regret with hindsight as we struggle with an awkward implementation of Property Match Filteringsimply to claim compliance. So I'd prefer the compliance statement to say, "In order to be compliant with this document, at least one of the Filtering or Sampling techniques MUST be implemented." Or, "... at least one of the Intermediate Flow Selection Process Techniques specified in section 6 MUST be implemented". P. On 22/05/13 07:35, Benoit Claise wrote: > Hi Nevil, > > "yes, keep the compliance statement in section 6.1". > I want to keep the consistency to makes it clear to implementors > what's needed for a minimal conforming > implementation, and to be similar to RFC 5475 > > Regards, Benoit (as a contributor) >> Hi all: >> >> draft-ietf-ipfix-flow-selection-tech-16 is now in IESG Evaluation; >> it currently has a blocking DISCUSS >> >> Section 6.1 contains a compliance statement, which says >> "In order to be compliant with this document, at least the >> Property Match Filtering MUST be implemented." >> The AD concerned asks whether we could remove this requirement. >> >> This was triggered by a remark in my Shepherd statement for this draft, >> which said >> "This draft raised IPR concerns, in the same manner as the PSAMP >> selection draft had done. Nick Duffield (AT&T) commented that >> the AT&T IPR claim relates only to statistical sampling, and PSAMP >> handled this by saying "at least on of the sampling techniques >> must be implemented." >> In this draft, we have tightened that up a little by saying >> "a conforming implementation MUST implement at least the >> Property Match Filtering." >> I realise now that the IPR in question was that relating to >> draft-krishnan-opsawg-large-flow-load-balancing, which was discussed >> on the IPFIX list back in Feb/Mar 2013; the issue that raised was >> cleared by the company concerned making an IPR declaration. >> >> That leaves us with the question about the compliance requirement. >> The motivation for this remains the same as it was for RFC 5475, >> "Sampling and Filtering Techniques for IP Packet Selection," >> the statement in section 6.1 simply refines it a little, and makes it >> clear to implementors what's needed for a minimal conforming >> implementation. >> >> So now, I need some feedback from the WG. Please send a note to >> the list saying >> "yes, keep the compliance statement in section 6.1" or >> "no, delete the compliance statement in section 6.1. >> >> Real soon now, please! >> >> Cheers, Nevil >> >> >> > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Wed May 22 04:57:50 2013 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 4347321F92BC for ; Wed, 22 May 2013 04:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIzP-Ty+oTXx for ; Wed, 22 May 2013 04:57:39 -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 CBEBE21F9246 for ; Wed, 22 May 2013 04:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8918; q=dns/txt; s=iport; t=1369223859; x=1370433459; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=41Lvdkql+56l4jRnV8wCY3TC7AhW0NkHc9MGGK1F7xY=; b=kY3EH8scWnJQXhSVWdGF/uSKTu/hVI+K35EOuDVGBwRUXDztd19QbFJg FwUxnB7Welaj/rC4N7HBxVwmM63FrRwm4BOrG0kaahFOKQSQF6TWIIBJM aWZ8auEX2PAEdTAfHOuBGBFtDdGN0fBKAKhqfxCaQkMyZ/yRX0zT9RoYH k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8GAMaxnFGQ/khM/2dsb2JhbABagwgwwWuBAxZ0giMBAQECAgEBATU2CgEQCxEDAQIBCRYPCQMCAQIBFSgIBg0BBQIBAReHcgy6aIJUjCQiBwaDTgOXOIYeiyKDEA X-IronPort-AV: E=Sophos;i="4.87,719,1363132800"; d="scan'208";a="82757117" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 22 May 2013 11:57:34 +0000 Received: from [144.254.153.46] (dhcp-144-254-153-46.cisco.com [144.254.153.46]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4MBvW2X013266; Wed, 22 May 2013 11:57:32 GMT Message-ID: <519CB2AD.8050903@cisco.com> Date: Wed, 22 May 2013 12:57:33 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Brian Trammell References: <615A5850-507D-4248-8B32-5A0EDEA0F3A3@tik.ee.ethz.ch> <38AF2656-2265-458E-9100-65DAD967458D@tik.ee.ethz.ch> <51963A69.70908@plixer.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] initiatorOctets/initiatorPackets/responderOctets/responderPackets change 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, 22 May 2013 11:57:50 -0000 Brian, The existing IANA definitions and cisco definitions of these fields are in terms of "layer 4". I believe it's wrong to rename them to "layer7". There would be a difference between the "layer 4" and "layer 7" definitions if there's layer 6 encryption or EBCDIC/ASCII conversion. These fields were requested by cisco; they're documented in Appendix A here: http://www.cisco.com/en/US/docs/ios/solutions_docs/avc/ios_xe3_8/avc_soln_guide_iosxe3_8_full.pdf Although that doesn't give us ownership of these fields, if you change them then we'll no longer be compliant with the fields we requested :-( P. On 17/05/13 15:33, Brian Trammell wrote: > Hi, Andrew. > > Hm... Good point. Thanks. > > (Pedantically: "everything under Layer 4" might also include layer 5 -- if you're of the opinion that HTTP is really a session layer nowadays -- but I think most everyone will understand what is meant.) > > So I amend my proposal to: > > Element ID: 231 > Name: layer7OctetDeltaCount > Data Type: unsigned64 > Semantics: deltaCounter > Description: > > The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any). > > > Element ID: 232 > Name: reverseLayer7OctetDeltaCount > Data Type: unsigned64 > Semantics: deltaCounter > Description: > > The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for the reverse direction of this Flow, as defined in RFC 5103, at the Observation Point since the previous report (if any). If present in a Flow Record along with layer7OctetDeltaCount, causes layer7OctetDeltaCount to refer to the forward direction of the Flow. If present in a Flow Record, implies that that Flow Record is exported with direction assigned by the initiator (as in section 5.1 of RFC 5103), unless contradicted by a biflowDirection Information Element present in the Flow Record or otherwise applicable to the Flow Record's scope. > > > Element ID: 298 > Name: layer7PacketDeltaCount > Data Type: unsigned64 > Semantics: deltaCounter > Description: > > The number of packets containing at least one octet beyond the IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any). > > > Element ID: 299 > Name: reverseLayer7PacketDeltaCount > Data Type: unsigned64 > Semantics: deltaCounter > Description: > > The number of packets containing at least one octet beyond the IP header(s) and Layer 4 transport protocol header(s), observed for the reverse direction of this Flow, as defined in RFC 5103, at the Observation Point since the previous report (if any). If present in a Flow Record along with layer7PacketDeltaCount, causes layer7PacketDeltaCount to refer to the forward direction of the Flow. If present in a Flow Record, implies that that Flow Record is exported with direction assigned by the initiator (as in section 5.1 of RFC 5103), unless contradicted by a biflowDirection Information Element present in the Flow Record or otherwise applicable to the Flow Record's scope. > > Cheers, > > Brian > > On May 17, 2013, at 4:10 PM, Andrew Feren wrote: > >> Hi Brian, >> >> If you are looking for consistency I'd go with "layer7". There are already 3 "layer2" IEs including 2 octet counts (layer2OctetDeltaCount and layer2OctetTotalCount). >> >> Also the the table of values for classificationEngineId (101) all use L# or layer # in their descriptions. >> >> -Andrew >> >> >> >> On 05/17/2013 03:45 AM, Brian Trammell wrote: >>> Oops, hit reply instead of reply all... >>> >>> Begin forwarded message: >>> >>> >>>> From: Brian Trammell >>>> >>>> Subject: Re: [Sender: >>>> ipfix-bounces@ietf.org >>>> ] [IPFIX] initiatorOctets/initiatorPackets/responderOctets/responderPackets change >>>> Date: 16 May 2013 19:22:10 GMT+02:00 >>>> To: Paul Aitken >>>> >>>> >>>> >>>> Hi, Paul, >>>> >>>> Indeed, decrement the numbers in the definition. >>>> >>>> "app" is intended to abbreviate "application". Not a huge fan of this name, but I can't come up with anything more precise that isn't significantly longer. "layer7"? "overTransport"? "transported"? >>>> >>>> Regards, >>>> >>>> Brian >>>> >>>> Sent from my iPhone >>>> >>>> On 16.05.2013, at 18:10, Paul Aitken >>>> >>>> wrote: >>>> >>>> >>>>> Brian, >>>>> >>>>> 1. Some mistake in the numbering in your new definitions: you've written 232 and 233 instead of 231 and 232. >>>>> >>>>> 2. What's the significance of "app" in these names? "Applicable"? "Application"? "Appearing"? "Appended"? "Approved"? "Appropriate"? "Approximate"? ... >>>>> >>>>> P. >>>>> >>>>> >>>>> On 16/05/13 16:45, Brian Trammell wrote: >>>>> >>>>>> Greetings, all, >>>>>> >>>>>> Following a previous suggestion to update propose we modify the names and definitions of the initiatorOctets(231), responderOctets(232), initiatorPackets(298), and responderPackets(299) as follows, (1) to bring them in line with the naming of other IPFIX Information Elements, (2) to allow them to be used by RFC 5103-compliant biflow Exporting Processes, and (3) to ensure (especially in the case of 298 and 299) that the descriptions are interoperably implemented. >>>>>> >>>>>> I think the proposed descriptions reflect the intent of the present descriptions, within the context of RFC 5103 terminology, and should therefore not have any impact on interoperability; I note that the description of IEs 298 and 299 are, however, not decipherable as written, so I may be taking some necessary liberty with my interpretation. >>>>>> >>>>>> >>>>>> Element ID: 232 >>>>>> Name: appOctetDeltaCount >>>>>> Data Type: unsigned64 >>>>>> Semantics: deltaCounter >>>>>> Description: >>>>>> >>>>>> The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any). >>>>>> >>>>>> >>>>>> Element ID: 233 >>>>>> Name: reverseAppOctetDeltaCount >>>>>> Data Type: unsigned64 >>>>>> Semantics: deltaCounter >>>>>> Description: >>>>>> >>>>>> The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for the reverse direction of this Flow, as defined in RFC 5103, at the Observation Point since the previous report (if any). If present in a Flow Record along with appOctetDeltaCount, causes appOctetDeltaCount to refer to the forward direction of the Flow. If present in a Flow Record, implies that that Flow Record is exported with direction assigned by the initiator (as in section 5.1 of RFC 5103), unless contradicted by a biflowDirection Information Element present in the Flow Record or otherwise applicable to the Flow Record's scope. >>>>>> >>>>>> >>>>>> Element ID: 298 >>>>>> Name: appPacketDeltaCount >>>>>> Data Type: unsigned64 >>>>>> Semantics: deltaCounter >>>>>> Description: >>>>>> >>>>>> The number of packets containing at least one octet beyond the IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any). >>>>>> >>>>>> >>>>>> Element ID: 299 >>>>>> Name: reverseAppPacketDeltaCount >>>>>> Data Type: unsigned64 >>>>>> Semantics: deltaCounter >>>>>> Description: >>>>>> >>>>>> The number of packets containing at least one octet beyond the IP header(s) and Layer 4 transport protocol header(s), observed for the reverse direction of this Flow, as defined in RFC 5103, at the Observation Point since the previous report (if any). If present in a Flow Record along with appPacketDeltaCount, causes appPacketDeltaCount to refer to the forward direction of the Flow. If present in a Flow Record, implies that that Flow Record is exported with direction assigned by the initiator (as in section 5.1 of RFC 5103), unless contradicted by a biflowDirection Information Element present in the Flow Record or otherwise applicable to the Flow Record's scope. >>>>>> >>>>>> >>>>>> Following discussion on the list, I intend to submit this proposed change to the IE-DOCTORS for review. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Many thanks, best regards, >>>>>> >>>>>> Brian >>>>>> _______________________________________________ >>>>>> 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 From trammell@tik.ee.ethz.ch Thu May 23 02:25:53 2013 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 4457B21F91B8 for ; Thu, 23 May 2013 02:25:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RB6gFMo+0u0h for ; Thu, 23 May 2013 02:25:48 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 7A83A21F91AB for ; Thu, 23 May 2013 02:25:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 19E36D9493; Thu, 23 May 2013 11:25:42 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9P4s7AgmfRgS; Thu, 23 May 2013 11:25:41 +0200 (MEST) Received: from [10.99.48.182] (unknown [213.0.81.93]) (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 69ECDD9314; Thu, 23 May 2013 11:25:41 +0200 (MEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: <519CB2AD.8050903@cisco.com> Date: Thu, 23 May 2013 11:25:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <615A5850-507D-4248-8B32-5A0EDEA0F3A3@tik.ee.ethz.ch> <38AF2656-2265-458E-9100-65DAD967458D@tik.ee.ethz.ch> <51963A69.70908@plixer.com> <519CB2AD.8050903@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1503) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] initiatorOctets/initiatorPackets/responderOctets/responderPackets change X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 09:25:53 -0000 hi, Paul, all, On 22 May 2013, at 13:57, Paul Aitken wrote: > Brian, >=20 > The existing IANA definitions and cisco definitions of these fields = are in terms of "layer 4". I believe it's wrong to rename them to = "layer7". >=20 > There would be a difference between the "layer 4" and "layer 7" = definitions if there's layer 6 encryption or EBCDIC/ASCII conversion. I have the same problem with naming them layer7, actually. They're _not_ = "layer4", though, since they count octets above the layer 4 headers. I = suppose we could call them layer5, but that would almost certainly = confuse everyone. Whether it would be more or less confusing than the = _current_ names, though, I'm not sure. > These fields were requested by cisco; they're documented in Appendix A = here: > = http://www.cisco.com/en/US/docs/ios/solutions_docs/avc/ios_xe3_8/avc_soln_= guide_iosxe3_8_full.pdf >=20 > Although that doesn't give us ownership of these fields, if you change = them then we'll no longer be compliant with the fields we requested :-( As specified, these four IEs that can never be unambiguously implemented = by an RFC 5103 EP, since the presence of these IEs may or may not = reverse the sense of forward and reverse direction. (There is a separate = issue here, that 298 and 299 are presently so unclearly specified in my = opinion as to be completely unimplementable. This will need to be fixed, = but we can set that aside for the moment.) We certainly don't want to = break existing implementations (any revision, per ie-doctors, must be = interoperable; breaking existing implementations would not be). I'd thought that the intent of these IEs was to implement something = similar to what I'd proposed to change the descriptions to. This would = appear not to be the case. Since we have an RFC 5103 EP, on which these = IEs are not implementable, and we need to export the fields as specified = in my proposal, I withdraw my request to consider the redefinition of = these four IEs; we simply won't use them. However, I would like to hear = the community's opinion on the utility of the following two _new_ = Information Elements. Element ID: TBA Name: layer7OctetDeltaCount Data Type: unsigned64 Semantics: deltaCounter Description: The number of octets, excluding IP header(s) and Layer 4 transport = protocol header(s), observed for this Flow at the Observation Point = since the previous report (if any). Element ID: TBA Name: layer7PacketDeltaCount Data Type: unsigned64 Semantics: deltaCounter Description: The number of packets containing at least one octet beyond the IP = header(s) and Layer 4 transport protocol header(s), observed for this = Flow at the Observation Point since the previous report (if any). (We intend to use 5103 as specified for the reverse directions thereof). Many thanks, best regards, Brian > On 17/05/13 15:33, Brian Trammell wrote: >> Hi, Andrew. >>=20 >> Hm... Good point. Thanks. >>=20 >> (Pedantically: "everything under Layer 4" might also include layer 5 = -- if you're of the opinion that HTTP is really a session layer nowadays = -- but I think most everyone will understand what is meant.) >>=20 >> On May 17, 2013, at 4:10 PM, Andrew Feren wrote: >>=20 >>> Hi Brian, >>>=20 >>> If you are looking for consistency I'd go with "layer7". There are = already 3 "layer2" IEs including 2 octet counts (layer2OctetDeltaCount = and layer2OctetTotalCount). >>>=20 >>> Also the the table of values for classificationEngineId (101) all = use L# or layer # in their descriptions. >>>=20 >>> -Andrew >>>=20 >>>=20 >>>=20 >>> On 05/17/2013 03:45 AM, Brian Trammell wrote: >>>> Oops, hit reply instead of reply all... >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>=20 >>>>> From: Brian Trammell >>>>>=20 >>>>> Subject: Re: [Sender: >>>>> ipfix-bounces@ietf.org >>>>> ] [IPFIX] = initiatorOctets/initiatorPackets/responderOctets/responderPackets change >>>>> Date: 16 May 2013 19:22:10 GMT+02:00 >>>>> To: Paul Aitken >>>>> >>>>>=20 >>>>>=20 >>>>> Hi, Paul, >>>>>=20 >>>>> Indeed, decrement the numbers in the definition. >>>>>=20 >>>>> "app" is intended to abbreviate "application". Not a huge fan of = this name, but I can't come up with anything more precise that isn't = significantly longer. "layer7"? "overTransport"? "transported"? >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Brian >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>> On 16.05.2013, at 18:10, Paul Aitken >>>>> >>>>> wrote: >>>>>=20 >>>>>=20 >>>>>> Brian, >>>>>>=20 >>>>>> 1. Some mistake in the numbering in your new definitions: you've = written 232 and 233 instead of 231 and 232. >>>>>>=20 >>>>>> 2. What's the significance of "app" in these names? "Applicable"? = "Application"? "Appearing"? "Appended"? "Approved"? "Appropriate"? = "Approximate"? ... >>>>>>=20 >>>>>> P. >>>>>>=20 >>>>>>=20 >>>>>> On 16/05/13 16:45, Brian Trammell wrote: >>>>>>=20 >>>>>>> Greetings, all, >>>>>>>=20 >>>>>>> Following a previous suggestion to update propose we modify the = names and definitions of the initiatorOctets(231), responderOctets(232), = initiatorPackets(298), and responderPackets(299) as follows, (1) to = bring them in line with the naming of other IPFIX Information Elements, = (2) to allow them to be used by RFC 5103-compliant biflow Exporting = Processes, and (3) to ensure (especially in the case of 298 and 299) = that the descriptions are interoperably implemented. >>>>>>>=20 >>>>>>> I think the proposed descriptions reflect the intent of the = present descriptions, within the context of RFC 5103 terminology, and = should therefore not have any impact on interoperability; I note that = the description of IEs 298 and 299 are, however, not decipherable as = written, so I may be taking some necessary liberty with my = interpretation. >>>>>>>=20 >>>>>>>=20 >>>>>>> Element ID: 232 >>>>>>> Name: appOctetDeltaCount >>>>>>> Data Type: unsigned64 >>>>>>> Semantics: deltaCounter >>>>>>> Description: >>>>>>>=20 >>>>>>> The number of octets, excluding IP header(s) and Layer 4 = transport protocol header(s), observed for this Flow at the Observation = Point since the previous report (if any). >>>>>>>=20 >>>>>>>=20 >>>>>>> Element ID: 233 >>>>>>> Name: reverseAppOctetDeltaCount >>>>>>> Data Type: unsigned64 >>>>>>> Semantics: deltaCounter >>>>>>> Description: >>>>>>>=20 >>>>>>> The number of octets, excluding IP header(s) and Layer 4 = transport protocol header(s), observed for the reverse direction of this = Flow, as defined in RFC 5103, at the Observation Point since the = previous report (if any). If present in a Flow Record along with = appOctetDeltaCount, causes appOctetDeltaCount to refer to the forward = direction of the Flow. If present in a Flow Record, implies that that = Flow Record is exported with direction assigned by the initiator (as in = section 5.1 of RFC 5103), unless contradicted by a biflowDirection = Information Element present in the Flow Record or otherwise applicable = to the Flow Record's scope. >>>>>>>=20 >>>>>>>=20 >>>>>>> Element ID: 298 >>>>>>> Name: appPacketDeltaCount >>>>>>> Data Type: unsigned64 >>>>>>> Semantics: deltaCounter >>>>>>> Description: >>>>>>>=20 >>>>>>> The number of packets containing at least one octet beyond the = IP header(s) and Layer 4 transport protocol header(s), observed for this = Flow at the Observation Point since the previous report (if any). >>>>>>>=20 >>>>>>>=20 >>>>>>> Element ID: 299 >>>>>>> Name: reverseAppPacketDeltaCount >>>>>>> Data Type: unsigned64 >>>>>>> Semantics: deltaCounter >>>>>>> Description: >>>>>>>=20 >>>>>>> The number of packets containing at least one octet beyond the = IP header(s) and Layer 4 transport protocol header(s), observed for the = reverse direction of this Flow, as defined in RFC 5103, at the = Observation Point since the previous report (if any). If present in a = Flow Record along with appPacketDeltaCount, causes appPacketDeltaCount = to refer to the forward direction of the Flow. If present in a Flow = Record, implies that that Flow Record is exported with direction = assigned by the initiator (as in section 5.1 of RFC 5103), unless = contradicted by a biflowDirection Information Element present in the = Flow Record or otherwise applicable to the Flow Record's scope. >>>>>>>=20 >>>>>>>=20 >>>>>>> Following discussion on the list, I intend to submit this = proposed change to the IE-DOCTORS for review. >>>>>>>=20 >>>>>>> Thoughts? >>>>>>>=20 >>>>>>> Many thanks, best regards, >>>>>>>=20 >>>>>>> Brian >>>>>>> _______________________________________________ >>>>>>> IPFIX mailing list >>>>>>>=20 >>>>>>> IPFIX@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>> _______________________________________________ >>>> IPFIX mailing list >>>>=20 >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Thu May 23 02:40:45 2013 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 ED52121F8E9A for ; Thu, 23 May 2013 02:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBBEY6KnXH46 for ; Thu, 23 May 2013 02:40:39 -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 806CF21F8BBC for ; Thu, 23 May 2013 02:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1431; q=dns/txt; s=iport; t=1369302039; x=1370511639; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=nmm1IDC75/bKAIJfMg/BZ8CPuymvxLLzW2I7n35achk=; b=OEoFJvDoLcJp4VxXUkaZwiTmHQxnu2qRy/hV8veiHMPagiszyfz7vPj6 Y8nnOkPSgxB+tKx8IDGy+KA0Id7MwoHbPKKX1dO0toavIyTJtu9kBYcPj rpaKXRvZoMewOP3v9KR8srF1aIDx6mW7m5ueG7oqrrZzHiBuUHmv8u2dW Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAA3jnVGQ/khR/2dsb2JhbABagwjCW4EKFnSCIwEBAQMBOEABBQsLIRYPCQMCAQIBRQYNAQcBARCHcwa6WYJUjEkHg1QDlziGHosigxA7 X-IronPort-AV: E=Sophos;i="4.87,727,1363132800"; d="scan'208";a="14127314" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 23 May 2013 09:40:38 +0000 Received: from [10.61.202.219] ([10.61.202.219]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4N9eZVr026723; Thu, 23 May 2013 09:40:36 GMT Message-ID: <519DE413.3070002@cisco.com> Date: Thu, 23 May 2013 10:40:35 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Brian Trammell References: <615A5850-507D-4248-8B32-5A0EDEA0F3A3@tik.ee.ethz.ch> <38AF2656-2265-458E-9100-65DAD967458D@tik.ee.ethz.ch> <51963A69.70908@plixer.com> <519CB2AD.8050903@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] layer7OctetDeltaCount / layer7PacketDeltaCount X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 09:40:45 -0000 Brian, > I would like to hear the community's opinion on the utility of the following two _new_ Information Elements. > > > Element ID: TBA > Name: layer7OctetDeltaCount > Data Type: unsigned64 > Semantics: deltaCounter > Description: > > The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any). > > > Element ID: TBA > Name: layer7PacketDeltaCount > Data Type: unsigned64 > Semantics: deltaCounter > Description: > > The number of packets containing at least one octet beyond the IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any). Using "layer 7" in the name and "layer 4" in the definition leaves it unclear whether layer 6 should be included. Yesterday I got to wondering what exactly a layer 4 packet is. Put another way, how often do we send packets which don't have any layer 4 content? Now I'm wondering the same about layer 7 - ie, what sort of packets would - and more importantly _would not_ - be counted by layer7PacketDeltaCount ? BTW, recall the Extended Field Specifier Format? How useful if all these IEs could be grouped under a single pair of "packetCount" and "octetCount" IEs with multiple extensions, eg packetCount.{layerN}.{delta|total}. P. From trammell@tik.ee.ethz.ch Thu May 23 02:47:30 2013 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 7E77421F92C5 for ; Thu, 23 May 2013 02:47:30 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQqC-FiODjBO for ; Thu, 23 May 2013 02:47: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 922BE21F958B for ; Thu, 23 May 2013 02:47:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id EC784D9314; Thu, 23 May 2013 11:47:23 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pSdKat49fB23; Thu, 23 May 2013 11:47:23 +0200 (MEST) Received: from [10.99.48.182] (unknown [213.0.81.93]) (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 5452AD930B; Thu, 23 May 2013 11:47:23 +0200 (MEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: <519DE413.3070002@cisco.com> Date: Thu, 23 May 2013 11:47:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <09AE8F00-629B-4252-802E-7C8FB6D19B0F@tik.ee.ethz.ch> References: <615A5850-507D-4248-8B32-5A0EDEA0F3A3@tik.ee.ethz.ch> <38AF2656-2265-458E-9100-65DAD967458D@tik.ee.ethz.ch> <51963A69.70908@plixer.com> <519CB2AD.8050903@cisco.com> <519DE413.3070002@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1503) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] layer7OctetDeltaCount / layer7PacketDeltaCount X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 09:47:30 -0000 Hi, Paul, all, On 23 May 2013, at 11:40, Paul Aitken wrote: > Brian, >=20 >> I would like to hear the community's opinion on the utility of the = following two _new_ Information Elements. >>=20 >>=20 >> Element ID: TBA >> Name: layer7OctetDeltaCount >> Data Type: unsigned64 >> Semantics: deltaCounter >> Description: >>=20 >> The number of octets, excluding IP header(s) and Layer 4 transport = protocol header(s), observed for this Flow at the Observation Point = since the previous report (if any). >>=20 >>=20 >> Element ID: TBA >> Name: layer7PacketDeltaCount >> Data Type: unsigned64 >> Semantics: deltaCounter >> Description: >>=20 >> The number of packets containing at least one octet beyond the IP = header(s) and Layer 4 transport protocol header(s), observed for this = Flow at the Observation Point since the previous report (if any). >=20 > Using "layer 7" in the name and "layer 4" in the definition leaves it = unclear whether layer 6 should be included. Point. What's layer 6 in the IETF IP stack, though? Let's back off from layering for a moment. How about = "transportedOctetDeltaCount"? The packet IE naming is harder though. "nonemptyPacketDeltaCount"? > Yesterday I got to wondering what exactly a layer 4 packet is. Put = another way, how often do we send packets which don't have any layer 4 = content? Now I'm wondering the same about layer 7 - ie, what sort of = packets would - and more importantly _would not_ - be counted by = layer7PacketDeltaCount ? All the time. TCP handshakes and pure ACKs, for one (these are the ones = I care about). SCTP control chunks. =20 > BTW, recall the Extended Field Specifier Format? How useful if all = these IEs could be grouped under a single pair of "packetCount" and = "octetCount" IEs with multiple extensions, eg = packetCount.{layerN}.{delta|total}. That'd be great. However, I'd like to implement these counters well = before the complete revision of the Information Model implied by = Extended Field Specifiers is complete. Cheers, Brian= From internet-drafts@ietf.org Thu May 23 02:52:25 2013 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 06A6721F96F2; Thu, 23 May 2013 02:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxHl-nU4dBEn; Thu, 23 May 2013 02:52:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC56021F96D2; Thu, 23 May 2013 02:52:19 -0700 (PDT) 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.50 Message-ID: <20130523095219.20366.21761.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 02:52:19 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-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: Thu, 23 May 2013 09:52:25 -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-07.txt Pages : 69 Date : 2013-05-23 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 a 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-protocol-rfc5101bis-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Thu May 23 02:55:18 2013 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 398EE21F95EA for ; Thu, 23 May 2013 02:55:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-h-hRLrzNlE for ; Thu, 23 May 2013 02:55:13 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3249621F9727 for ; Thu, 23 May 2013 02:55:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 94D30D930B for ; Thu, 23 May 2013 11:55:11 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gAXtNq0+ZqsD for ; Thu, 23 May 2013 11:55:11 +0200 (MEST) Received: from [10.99.48.182] (unknown [213.0.81.93]) (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 2C94ED9323 for ; Thu, 23 May 2013 11:55:09 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 23 May 2013 11:55:08 +0200 References: <20130523095219.20366.21761.idtracker@ietfa.amsl.com> To: IETF IPFIX Working Group Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [IPFIX] Fwd: I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-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: Thu, 23 May 2013 09:55:18 -0000 Greetings, all, This revision contains edits in response to a Security Directorate = review from IETF LC, as well as adding a new section on privacy = considerations for collected data, requested as part of a DISCUSS on the = flow selection techniques draft. Best regards, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [IPFIX] I-D Action: = draft-ietf-ipfix-protocol-rfc5101bis-07.txt > Date: 23 May 2013 11:52:19 GMT+02:00 > To: i-d-announce@ietf.org > Cc: ipfix@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Flow Information Export Working = Group of the IETF. >=20 > Title : 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-07.txt > Pages : 69 > Date : 2013-05-23 >=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 a 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 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-07 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-protocol-rfc5101bis-07= >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From internet-drafts@ietf.org Fri May 24 03:18:09 2013 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 9D9E621F938E; Fri, 24 May 2013 03:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26CnSWGxnt4f; Fri, 24 May 2013 03:18:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7F721F93A3; Fri, 24 May 2013 03:18:04 -0700 (PDT) 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.50 Message-ID: <20130524101803.20027.89438.idtracker@ietfa.amsl.com> Date: Fri, 24 May 2013 03:18:03 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-flow-selection-tech-17.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, 24 May 2013 10:18:09 -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 Selection Techniques Author(s) : Salvatore D'Antonio Tanja Zseby Christian Henke Lorenzo Peluso Filename : draft-ietf-ipfix-flow-selection-tech-17.txt Pages : 33 Date : 2013-05-24 Abstract: Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-flow-selection-tech-17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From n.brownlee@auckland.ac.nz Mon May 27 15:19:08 2013 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 1AE0F21F8F20 for ; Mon, 27 May 2013 15:19:08 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j66Y8vMyeQTo for ; Mon, 27 May 2013 15:19:03 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id C65D321F8EDF for ; Mon, 27 May 2013 15:19:00 -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=1369693143; x=1401229143; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=72QXUCEybWs4Dl37zgo/1LFIH1YC/2y8khPDJtXU/ZA=; b=bdg0qUs2JJWUZFCnXWsCuPBFLGApmyY9KeMNjUffYMJx981PYocsIeKc dB7k7u7ecMmNhnOc4c5JP1NjIvmGGedzVONUfAohbN2M43Ao1j5w2WtKC 0o2W8xl1n2lo9gHdAvUHk2l8EIeWQljFXifg7aoXG9zR8wCFGOg4EaBC3 w=; X-IronPort-AV: E=Sophos;i="4.87,753,1363086000"; d="scan'208";a="190125931" 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; 28 May 2013 10:18:54 +1200 Message-ID: <51A3DBCE.50409@auckland.ac.nz> Date: Tue, 28 May 2013 10:18:54 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tanja Zseby References: <20130524102536.24137.68217.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Christian Henke , IPFIX Working Group , Lorenzo Peluso , Nevil Brownlee Subject: Re: [IPFIX] Compliance Statement (Pete Resnick's DISCUSS) 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, 27 May 2013 22:19:08 -0000 Hi Selection Tech authors: We really do have to get back to Pete with a clear consensus on this. From the few replies to my posting to the list on this, my proposal on the consensus so far is to replace the sentence in section 6.1 as follows: OLD: In order to be compliant with this document, at least the Property Match Filtering SHOULD be implemented. NEW: In order to be compliant with IPFIX, at least one of this document's flow filtering schemes MUST be implemented. This would make it mirror the compliance statement in RFC 5475 (PSAMP packet selection. So now, please email the list to say "yes, the proposed NEW above is OK," or to suggest something better. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From trammell@tik.ee.ethz.ch Mon May 27 15:37:01 2013 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 EED3921F8F0F for ; Mon, 27 May 2013 15:37:01 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IcPC51SErXO for ; Mon, 27 May 2013 15:36:57 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3723021F8F00 for ; Mon, 27 May 2013 15:36:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 94B88D9305; Tue, 28 May 2013 00:36:55 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uX9V8VbCjRbF; Tue, 28 May 2013 00:36:55 +0200 (MEST) Received: from [192.168.254.111] (alesia-0145420816.pck.nerim.net [62.212.101.192]) (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 0013BD9304; Tue, 28 May 2013 00:36:49 +0200 (MEST) References: <20130524102536.24137.68217.idtracker@ietfa.amsl.com> <51A3DBCE.50409@auckland.ac.nz> Mime-Version: 1.0 (1.0) In-Reply-To: <51A3DBCE.50409@auckland.ac.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B329) From: Brian Trammell Date: Tue, 28 May 2013 00:36:48 +0200 To: Nevil Brownlee Cc: Tanja Zseby , Nevil Brownlee , Lorenzo Peluso , Christian Henke , IPFIX Working Group Subject: Re: [IPFIX] Compliance Statement (Pete Resnick's DISCUSS) 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, 27 May 2013 22:37:02 -0000 The new proposed text is IMO better. Cheers, Brian Sent from my iPhone On 28.05.2013, at 00:18, Nevil Brownlee wrote: > > Hi Selection Tech authors: > > We really do have to get back to Pete with a clear consensus on this. > > From the few replies to my posting to the list on this, my proposal > on the consensus so far is to replace the sentence in section 6.1 as > follows: > > OLD: In order to be compliant with this document, at least the > Property Match Filtering SHOULD be implemented. > > NEW: In order to be compliant with IPFIX, at least one of > this document's flow filtering schemes MUST be implemented. > > This would make it mirror the compliance statement in RFC 5475 (PSAMP > packet selection. > > So now, please email the list to say "yes, the proposed NEW above > is OK," or to suggest something better. > > Cheers, Nevil > > -- > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From salvatore.dantonio@uniparthenope.it Mon May 27 21:15:36 2013 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 481CF21F941D for ; Mon, 27 May 2013 21:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.585 X-Spam-Level: ** X-Spam-Status: No, score=2.585 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_QP_LONG_LINE=1.396, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSVyZttj3EQ0 for ; Mon, 27 May 2013 21:15:32 -0700 (PDT) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by ietfa.amsl.com (Postfix) with ESMTP id B1A1721F9413 for ; Mon, 27 May 2013 21:15:31 -0700 (PDT) Received: from mailk.uniparthenope.it (unknown [192.168.241.110]) by mail.uniparthenope.it (Postfix) with ESMTP id D11F142369 for ; Tue, 28 May 2013 04:15:29 +0000 (UTC) Received: from mail.uniparthenope.it (unknown [192.168.241.244]) by mailk.uniparthenope.it (Postfix) with ESMTP id E35061244DF for ; Tue, 28 May 2013 06:15:25 +0200 (CEST) Received: by mail.uniparthenope.it (Postfix, from userid 108) id 9828242338; Tue, 28 May 2013 06:15:25 +0200 (CEST) Received: from SalvatorePC (unknown [2.237.123.176]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id E97DE42338; Tue, 28 May 2013 06:15:24 +0200 (CEST) From: "Salvatore D'Antonio" To: "'Nevil Brownlee'" References: <20130524102536.24137.68217.idtracker@ietfa.amsl.com> <51A3DBCE.50409@auckland.ac.nz> In-Reply-To: <51A3DBCE.50409@auckland.ac.nz> Date: Tue, 28 May 2013 06:16:34 +0200 Message-ID: <000001ce5b5a$23cd3b80$6b67b280$@uniparthenope.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGUfdI8H6y9AJxBdDwgcnyx2wYYTwH0PJhqAnEds1+ZaoyaQA== Content-Language: it X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 46716 [May 28 2013] X-KLMS-AntiSpam-Version: 5.2.4 X-KLMS-AntiSpam-Envelope-From: salvatore.dantonio@uniparthenope.it X-KLMS-AntiSpam-Spf: none X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 2413030, 2413045, 2413021 X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server 8.0.0.455, bases: 2013/05/27 22:45:00 #10148571; khse: 2013-03-01 08:35:03 X-KLMS-AntiVirus-Status: Clean, skipped Cc: tanja.zseby@tuwien.ac.at, 'Lorenzo Peluso' , 'Christian Henke' , 'IPFIX Working Group' Subject: [IPFIX] R: Compliance Statement (Pete Resnick's DISCUSS) 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, 28 May 2013 04:15:36 -0000 Dear Nevil, yes, the new proposed text " In order to be compliant with IPFIX, at = least one of this document's flow filtering schemes MUST be implemented." is = ok. Best regards, Salvatore -----Messaggio originale----- Da: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz]=20 Inviato: marted=EC 28 maggio 2013 00:19 A: Tanja Zseby Cc: Salvatore D'Antonio; Nevil Brownlee; Christian Henke; Lorenzo = Peluso; Juergen Quittek; IPFIX Working Group Oggetto: Re: Compliance Statement (Pete Resnick's DISCUSS) Hi Selection Tech authors: We really do have to get back to Pete with a clear consensus on this. From the few replies to my posting to the list on this, my proposal on = the consensus so far is to replace the sentence in section 6.1 as follows: OLD: In order to be compliant with this document, at least the Property Match Filtering SHOULD be implemented. NEW: In order to be compliant with IPFIX, at least one of this document's flow filtering schemes MUST be implemented. This would make it mirror the compliance statement in RFC 5475 (PSAMP = packet selection. So now, please email the list to say "yes, the proposed NEW above is = OK," or to suggest something better. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand ----- Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2013.0.2904 / Database dei virus: 3184/6361 - Data di = rilascio: 27/05/2013 ****************************************************************************** IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO Il 5 per mille all'Universita' degli Studi di Napoli "Parthenope" incrementa le borse di studio agli studenti - codice fiscale 80018240632 http://www.uniparthenope.it/index.php/5xmille http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille Questa informativa e' inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente. From n.brownlee@auckland.ac.nz Tue May 28 16:10:00 2013 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 7993521E8053 for ; Tue, 28 May 2013 16:10:00 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVobiHythK51 for ; Tue, 28 May 2013 16:09:55 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 1983E11E80AE for ; Tue, 28 May 2013 16:09:53 -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=1369782595; x=1401318595; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=y1opFkLV3cxgs8s59lGJ2Jqqb1QKGIERT/UFXaUB0q4=; b=J2Yl3aa3ifxM334ReCv978Aznp2teZBY5+bxLXni9aVMpyG6Ypu4b0bo SXLf8yzrT5tTECHH2qhMqoNjJSy/Xk03Pc47xqaJwc+4KurgHeN2ewjTa ZxpuhPdOIHfziu5znJZO987CzPkzpWN1pH8FMuAaiOE8UC6BvKR0qYTYG 0=; X-IronPort-AV: E=Sophos;i="4.87,760,1363086000"; d="scan'208";a="190627427" 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; 29 May 2013 11:09:52 +1200 Message-ID: <51A5393F.3060301@auckland.ac.nz> Date: Wed, 29 May 2013 11:09:51 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Pete Resnick References: <20130524102536.24137.68217.idtracker@ietfa.amsl.com> <51A3DBCE.50409@auckland.ac.nz> In-Reply-To: <51A3DBCE.50409@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joel Jaeggli , IPFIX Working Group Subject: Re: [IPFIX] DISCUSS on draft-ietf-ipfix-flow-selection-tech-17 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, 28 May 2013 23:10:00 -0000 Hi Pete: Following up on your 'compliance statement' issue (now that we've established that it wasn't raised by an IPR question), I asked the draft authors and the IPFIX list for opinions on this From the replies to my posting to the list on this, the WG consensus is that we do want to have c compliance statement. Therefore we now want to replace the sentence in section 6.1 as follows: OLD: In order to be compliant with this document, at least the Property Match Filtering SHOULD be implemented. NEW: In order to be compliant with IPFIX, at least one of this document's flow filtering schemes MUST be implemented. This would make it mirror the compliance statement in RFC 5475 (PSAMP packet selection. Would that be OK with you, please? Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From internet-drafts@ietf.org Thu May 30 02:38:38 2013 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 CB5E821F96AC; Thu, 30 May 2013 02:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utlU3z3VujU4; Thu, 30 May 2013 02:38:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D965121F915C; Thu, 30 May 2013 02:38:37 -0700 (PDT) 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.50 Message-ID: <20130530093837.20218.41405.idtracker@ietfa.amsl.com> Date: Thu, 30 May 2013 02:38:37 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-flow-selection-tech-18.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, 30 May 2013 09:38:39 -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 Selection Techniques Author(s) : Salvatore D'Antonio Tanja Zseby Christian Henke Lorenzo Peluso Filename : draft-ietf-ipfix-flow-selection-tech-18.txt Pages : 33 Date : 2013-05-30 Abstract: Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-flow-selection-tech-18 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/