From paitken@cisco.com Mon Sep 3 08:11:44 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A8B21F8670 for ; Mon, 3 Sep 2012 08:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.492 X-Spam-Level: X-Spam-Status: No, score=-10.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yutLlhKRNS1v for ; Mon, 3 Sep 2012 08:11:43 -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 8480921F8564 for ; Mon, 3 Sep 2012 08:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=4440; q=dns/txt; s=iport; t=1346685102; x=1347894702; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=tXqSn3t9uHUicNcsltLv2N/Wb/eHwjaj2iqJ4vQWylA=; b=QDeZuTils88D6Dhbx9XZkzvMHP1apnqZeyBcp/aIWdRsn0XlT4TPdIPE BPSGF1ovTixusAGV387trx+LSaWiDtgfzZSCBKZJJx1mHntNW0zinw1L7 JcwklMZEeb2FWSNyxk4Z2foFD3RNxVOGr/pXTb2rkcpef+Ti0myoBReQJ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQGALTHRFCQ/khL/2dsb2JhbABFs26HNYEHgiEBAQQSAVgNARALBB0WDwkDAgECAUUGDQEHAQEFGYdrC5pin2OSMAOVWYEUhEuIVIFngmQ X-IronPort-AV: E=Sophos;i="4.80,360,1344211200"; d="scan'208,217";a="76430700" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 03 Sep 2012 15:11:37 +0000 Received: from [10.55.93.132] (dhcp-10-55-93-132.cisco.com [10.55.93.132]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q83FBbQf031998; Mon, 3 Sep 2012 15:11:37 GMT Message-ID: <5044C8A9.6090703@cisco.com> Date: Mon, 03 Sep 2012 16:11:37 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Brian Trammell References: <20120831165653.9430.22489.idtracker@ietfa.amsl.com> In-Reply-To: <20120831165653.9430.22489.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------060200050909090100070003" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-ie-doctors-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 15:11:44 -0000 This is a multi-part message in MIME format. --------------060200050909090100070003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, All, There's a disconnect between RFC 5610 and IANA's IPFIX registry which affects ie-doctors: Section 3.7 of RFC 5610 defines IE units and states, "new types may be added on a First Come First Served [RFC5226 ] basis." Cection 4.4. of IE-doctors confirms: "Note that the Units subregistry is maintained on a First Come, First Served basis." However IANA's registry states that Expert Review is required. See http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-information-element-units I suggest that Expert Review is more correct, since FCFS has no review. From RFC 5226: There is no substantive review of the request, other than to ensure that it is well-formed and doesn't duplicate an existing assignment. Currently anyone could request any new units, and IANA would have to honour the request even if it was stupid or irrelevant. Whereas with Expert Review, stupid requests could be rejected since "approval by a Designated Expert is required." Regarding Expert Review, RFC 5226 says: The required documentation and review criteria for use by the Designated Expert should be provided when defining the registry. For example, see Sections 6 and 7.2 in [RFC3748]. Currently the "IPFIX Information Elements" and "IPFIX Information Element Units" require Expert Review without defining any documentation or review criteria. We should address that, eg, "Experts must double check the ...whatever... with already defined label types for completeness, accuracy, relevance, and redundancy." P. --------------060200050909090100070003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian, All,

There's a disconnect between RFC 5610 and IANA's IPFIX registry which affects ie-doctors:

Section 3.7 of RFC 5610 defines IE units and states, "new types may be added on a First Come First Served [RFC5226] basis."

Cection 4.4. of IE-doctors confirms: "Note that the Units subregistry is maintained on a First Come, First Served basis."

However IANA's registry states that Expert Review is required. See http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-information-element-units


I suggest that Expert Review is more correct, since FCFS has no review. From RFC 5226:
            There is no substantive
            review of the request, other than to ensure that it is
            well-formed and doesn't duplicate an existing assignment.

Currently anyone could request any new units, and IANA would have to honour the request even if it was stupid or irrelevant.
Whereas with Expert Review, stupid requests could be rejected since "approval by a Designated Expert is required."


Regarding Expert Review, RFC 5226 says:
            The required documentation and review
            criteria for use by the Designated Expert should be provided
            when defining the registry.  For example, see Sections 6 and
            7.2 in [RFC3748].

Currently the "IPFIX Information Elements" and "IPFIX Information Element Units" require Expert Review without defining any documentation or review criteria.

We should address that, eg, "Experts must double check the ...whatever... with already defined label types for completeness, accuracy, relevance, and redundancy."

P.
--------------060200050909090100070003-- From trammell@tik.ee.ethz.ch Mon Sep 3 09:43:03 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF5E21F867A for ; Mon, 3 Sep 2012 09:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.355 X-Spam-Level: X-Spam-Status: No, score=-6.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DEDFTr3RlKf for ; Mon, 3 Sep 2012 09:43:00 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4495621F8671 for ; Mon, 3 Sep 2012 09:42:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 790BED9304; Mon, 3 Sep 2012 18:42: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 UkNGD3ZQZMfm; Mon, 3 Sep 2012 18:42:55 +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 3F384D9300; Mon, 3 Sep 2012 18:42:55 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <5044C8A9.6090703@cisco.com> Date: Mon, 3 Sep 2012 18:42:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <56DE85D5-8B82-4351-826F-2B5D75E3F95C@tik.ee.ethz.ch> References: <20120831165653.9430.22489.idtracker@ietfa.amsl.com> <5044C8A9.6090703@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1278) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-ie-doctors-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 16:43:03 -0000 Hi, Paul, Interesting.=20 I hadn't checked the registry, but I can say that the FCFS policy for = Units was intentional: imagine a an enterprise-specific information = element designed to do something very odd with unorthodox units, say, = counting rats crawling around in the underfloor space in a data center = (perhaps to attempt to correlate packet loss with rodent infestation). = Now, the IEs for this would be ESIEs, but since this is a research = study, we'd want to annotate the data (stored in files) with 5610 type = information records.=20 However, on review, perhaps Units in the IANA registry should cover only = those IEs in the IANA registry, and if you want to do something really = odd, you should leave units blank and explain "expressed in rats per = cubic meter as measured by the Yoyodyne Underfloor Rat Counter model 19" = in the informationElementDescription field. But that was the intent. If we decide this, the proper thing to do is to go with the registry as = is and change IE-DOCTORS to update RFC 5610. Cheers, Brian On Sep 3, 2012, at 5:11 PM, Paul Aitken wrote: > Brian, All, >=20 > There's a disconnect between RFC 5610 and IANA's IPFIX registry which = affects ie-doctors: >=20 > Section 3.7 of RFC 5610 defines IE units and states, "new types may be = added on a First Come First Served [RFC5226] basis." >=20 > Cection 4.4. of IE-doctors confirms: "Note that the Units subregistry = is maintained on a First Come, First Served basis." >=20 > However IANA's registry states that Expert Review is required. See = http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-information-element-= units >=20 >=20 > I suggest that Expert Review is more correct, since FCFS has no = review. =46rom RFC 5226: > There is no substantive > review of the request, other than to ensure that it is > well-formed and doesn't duplicate an existing assignment. >=20 >=20 > Currently anyone could request any new units, and IANA would have to = honour the request even if it was stupid or irrelevant. > Whereas with Expert Review, stupid requests could be rejected since = "approval by a Designated Expert is required." >=20 >=20 > Regarding Expert Review, RFC 5226 says: > The required documentation and review > criteria for use by the Designated Expert should be = provided > when defining the registry. For example, see Sections 6 = and > 7.2 in [RFC3748]. >=20 >=20 > Currently the "IPFIX Information Elements" and "IPFIX Information = Element Units" require Expert Review without defining any documentation = or review criteria. >=20 > We should address that, eg, "Experts must double check the = ...whatever... with already defined label types for completeness, = accuracy, relevance, and redundancy." >=20 > P. >=20 >=20 >=20 From paitken@cisco.com Mon Sep 3 10:09:04 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C73C21F86D5 for ; Mon, 3 Sep 2012 10:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.495 X-Spam-Level: X-Spam-Status: No, score=-10.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+nxSlMfLDEg for ; Mon, 3 Sep 2012 10:09:03 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7BB21F86D1 for ; Mon, 3 Sep 2012 10:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1830; q=dns/txt; s=iport; t=1346692143; x=1347901743; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Gh4hrDBFqfBlyXPaH6gOsdpX7oDvnhoRp/x5hZiWfvI=; b=Wy2eVX+MNj8jxd9y/rpyDyYrDJdIl8UimBJ3uxC4TzM+I7sPuOcaivdy M0wMnuUqTHV3UZYF+uTl7TFCD7dEZtroVmuz+uRd23IGfCIkrrFW1lzRV 4lUX9AdE5HJSJ3m4avUpD+HFlZBjvi8nMvyAwgQGfIfI6/DEa69tZyqnU E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQGAP/iRFCQ/khR/2dsb2JhbABFs2+HNYEHgiABAQEDARIBJTMNAQULCyEWDwkDAgECAUUGDQEHAQEeh2UGmlufbpIwA5VZhV+IVIFngmQ X-IronPort-AV: E=Sophos;i="4.80,360,1344211200"; d="scan'208";a="7769920" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 03 Sep 2012 17:08:59 +0000 Received: from [10.55.93.132] (dhcp-10-55-93-132.cisco.com [10.55.93.132]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q83H8vau004459; Mon, 3 Sep 2012 17:08:59 GMT Message-ID: <5044E42A.7050303@cisco.com> Date: Mon, 03 Sep 2012 18:08:58 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Brian Trammell References: <20120831165653.9430.22489.idtracker@ietfa.amsl.com> <5044C8A9.6090703@cisco.com> <56DE85D5-8B82-4351-826F-2B5D75E3F95C@tik.ee.ethz.ch> In-Reply-To: <56DE85D5-8B82-4351-826F-2B5D75E3F95C@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] draft-ietf-ipfix-ie-doctors-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 17:09:04 -0000 Brian, > Hi, Paul, > > Interesting. > > I hadn't checked the registry, but I can say that the FCFS policy for Units was intentional: imagine a an enterprise-specific information element designed to do something very odd with unorthodox units, say, counting rats crawling around in the underfloor space in a data center (perhaps to attempt to correlate packet loss with rodent infestation). Now, the IEs for this would be ESIEs, but since this is a research study, we'd want to annotate the data (stored in files) with 5610 type information records. ie, 5610 allows units to be expressed for enterprise-specific IEs. > However, on review, perhaps Units in the IANA registry should cover only those IEs in the IANA registry, and if you want to do something really odd, you should leave units blank and explain "expressed in rats per cubic meter as measured by the Yoyodyne Underfloor Rat Counter model 19" in the informationElementDescription field. But that was the intent. This would prevent 5610 from working properly, since I couldn't created a "rats" unit for my ESIEs. And if an IE is already in IANA's IPFIX registry, then it already has a type - so there'd be no need for it in 5610. > If we decide this, the proper thing to do is to go with the registry as is and change IE-DOCTORS to update RFC 5610. I think the "IPFIX units" registry should be subject to expert review - which allows enterprises to request "rats" for their enterprise-specific IEs if they want to use 5610, provided they can convince the expert reviewer that they have an IPFIX-enabled rat counter. However, it ensures that IANA won't assign a lot of stupid units which may be requested by miscreants. If all agree, then I'd be happy for IE-docs to update 5610 (and leave the registry unchanged). P. From trammell@tik.ee.ethz.ch Mon Sep 3 10:53:11 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F1621F8597 for ; Mon, 3 Sep 2012 10:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7vSCb9JAKgm for ; Mon, 3 Sep 2012 10:53:10 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9407421F8592 for ; Mon, 3 Sep 2012 10:53:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 785D5D9304; Mon, 3 Sep 2012 19:53:09 +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 jGNy4i2jNrdQ; Mon, 3 Sep 2012 19:53:09 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 10641D9300; Mon, 3 Sep 2012 19:53:09 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <5044E42A.7050303@cisco.com> Date: Mon, 3 Sep 2012 19:53:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <918337CC-0D0B-4AB9-B3F7-BE4AC6828CE5@tik.ee.ethz.ch> References: <20120831165653.9430.22489.idtracker@ietfa.amsl.com> <5044C8A9.6090703@cisco.com> <56DE85D5-8B82-4351-826F-2B5D75E3F95C@tik.ee.ethz.ch> <5044E42A.7050303@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1278) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-ie-doctors-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 17:53:11 -0000 Hi, Paul, As the registry (to date) has been de facto expert review (and there = have been no registrations), I don't see any problem with this. However, can IE-DOCTORS update 5610? 5610 is Standards Track, and = IE-DOCTORS targets BCP. If not, this would be a technical erratum on = 5610. Cheers, Brian On Sep 3, 2012, at 7:08 PM, Paul Aitken wrote: > Brian, >=20 >> Hi, Paul, >>=20 >> Interesting. >>=20 >> I hadn't checked the registry, but I can say that the FCFS policy for = Units was intentional: imagine a an enterprise-specific information = element designed to do something very odd with unorthodox units, say, = counting rats crawling around in the underfloor space in a data center = (perhaps to attempt to correlate packet loss with rodent infestation). = Now, the IEs for this would be ESIEs, but since this is a research = study, we'd want to annotate the data (stored in files) with 5610 type = information records. >=20 > ie, 5610 allows units to be expressed for enterprise-specific IEs. >=20 >=20 >> However, on review, perhaps Units in the IANA registry should cover = only those IEs in the IANA registry, and if you want to do something = really odd, you should leave units blank and explain "expressed in rats = per cubic meter as measured by the Yoyodyne Underfloor Rat Counter model = 19" in the informationElementDescription field. But that was the intent. >=20 > This would prevent 5610 from working properly, since I couldn't = created a "rats" unit for my ESIEs. >=20 > And if an IE is already in IANA's IPFIX registry, then it already has = a type - so there'd be no need for it in 5610. >=20 >=20 >> If we decide this, the proper thing to do is to go with the registry = as is and change IE-DOCTORS to update RFC 5610. >=20 > I think the "IPFIX units" registry should be subject to expert review = - which allows enterprises to request "rats" for their = enterprise-specific IEs if they want to use 5610, provided they can = convince the expert reviewer that they have an IPFIX-enabled rat = counter. >=20 > However, it ensures that IANA won't assign a lot of stupid units which = may be requested by miscreants. >=20 > If all agree, then I'd be happy for IE-docs to update 5610 (and leave = the registry unchanged). >=20 > P. From n.brownlee@auckland.ac.nz Wed Sep 5 17:32:34 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D6721F8550 for ; Wed, 5 Sep 2012 17:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRHStt1raS6f for ; Wed, 5 Sep 2012 17:32:29 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id DFEE721F8526 for ; Wed, 5 Sep 2012 17:32:28 -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=1346891549; x=1378427549; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=xmJzBc9G68XkYzpfTLoB6o+dh7ftekvpsRHHWbbiTCE=; b=VOul/aUGfCEB6ZfczMwzQIcn4+YxVfKY9QNNRKLTw/IrnZQ9HooHe/RF KGAmUB0C+YgoxTYCLISMkamUm3Y9C/942yXr2k+nKXB8+0fh+6EMf+dq1 eAhi2BLOIewlELvz3KqYPLGPZOe5d6dJ5qwG8hg1Y2qletmKO9NQLHqLY 4=; X-IronPort-AV: E=Sophos;i="4.80,377,1344168000"; d="scan'208";a="143439734" 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; 06 Sep 2012 12:32:28 +1200 Message-ID: <5047EF1B.5070706@auckland.ac.nz> Date: Thu, 06 Sep 2012 12:32:27 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: ipfix Working Group References: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> In-Reply-To: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Fwd: Help the NomCom: Nominations and Feedback 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, 06 Sep 2012 00:32:34 -0000 -------- Original Message -------- Subject: Help the NomCom: Nominations and Feedback Date: Wed, 5 Sep 2012 17:21:29 -0700 From: NomCom Chair To: Working Group Chairs The IETF Nominations Committee (NomCom) is currently seeking nominations for individuals to serve on the IESG, IAB, and IAOC. Additionally, this is an announcement that the NomCom is seeking feedback on individuals who have accepted nominations for IETF leadership positions. It is very important to the NomCom process that we get input from a broad spectrum of the community. Therefore, in case members of your working group do not read the IETF announcement and discussion lists, the NomCom would appreciate your help in disseminating the following information. The NomCom website contains information about this year's NomCom including the positions we are seeking to fill, and the qualifications required for these positions: https://www.ietf.org/group/nomcom/2012/ The NomCom is accepting nominations until September 24. Nominations for any position can be made using the following web tool: https://www.ietf.org/group/nomcom/2012/nominate Feedback about individuals who the NomCom is considering can be providing using the following web tool: https://www.ietf.org/group/nomcom/2012/input The feedback tool provides a list of individuals who have agreed to be considered for each position. We will be updating this list in the coming weeks as more individuals accept nominations. Feedback provided to the NomCom is kept strictly confidential! Note that use of the NomCom web tools require an ietf.org (i.e., datatracker) account. You can create an ietf.org account by visiting the following URL: https://datatracker.ietf.org/accounts/create/ As an alternative to using the web tools, you can send email to the NomCom at nomcom12@ietf.org to make a nomination or provide input to the committee. Thank you for your help, - Matt Lepinski nomcom-chair@ietf.org From paitken@cisco.com Thu Sep 6 03:46:02 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBB421F861D for ; Thu, 6 Sep 2012 03:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrTpJWM95+h3 for ; Thu, 6 Sep 2012 03:46:01 -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 7631121F84F5 for ; Thu, 6 Sep 2012 03:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=911; q=dns/txt; s=iport; t=1346928361; x=1348137961; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=UgMeDaITCFVyW+WLbNloXvV6TLd19ICco7iSQKGhtLE=; b=H47Sr0ElOOpuyJpGpKIn1sv5InKE9m18UcEotJ5ZMARm8ylgXOTWoNW1 YozEhuS6i2n5Xhwv2IDptrjjyqYt3L4U3MnrcTDWD8zHNrwm238yuNrFG 7hAM0+Ibl/Z8ZRb5bg/uLfzxo7ZeGNmfDbSQPejY+HU0kfdg4rXwiasc2 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFALd9SFCQ/khN/2dsb2JhbABFhT+1X4EHgjkBJUA9FhgDAgECAUsNCAEBBRmHawuZLIEooBmRVgOVWYVfiFSBZ4Jk X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="76502407" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 06 Sep 2012 10:46:00 +0000 Received: from [10.55.93.132] (dhcp-10-55-93-132.cisco.com [10.55.93.132]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q86Ak0kN018309 for ; Thu, 6 Sep 2012 10:46:00 GMT Message-ID: <50487EE8.5020707@cisco.com> Date: Thu, 06 Sep 2012 11:46:00 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] enterprise ID 0 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, 06 Sep 2012 10:46:02 -0000 Since enterprise ID zero is reserved for IANA (per http://www.iana.org/assignments/enterprise-numbers), and since the IPFIX config model defines "ieEnterpriseNumber" with zero == IANA : ieId, ieName, ieEnterpriseNumber: The property to be matched is specified by either ieId or ieName, specifying the ID or name of the Information Element, respectively. If ieEnterpriseNumber is zero (which is the default), this Information Element is registered in the IANA registry of IPFIX Information Elements [IANA-IPFIX]. A non-zero value of ieEnterpriseNumber specifies an enterprise-specific Information Element. and since there are no exclusions against Enterprise Number == 0 in RFC 5101 or 5101bis, can we conclude that it's _not_ an error for an Exporting Process to send IANA-IEs with E == 1 and Enterprise Number == 0 ? Thanks, P. From trammell@tik.ee.ethz.ch Thu Sep 6 05:29:05 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF0B21F8604 for ; Thu, 6 Sep 2012 05:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEoGQWiSaC-s for ; Thu, 6 Sep 2012 05:29:05 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id EA32821F85C0 for ; Thu, 6 Sep 2012 05:29:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8E036D9499; Thu, 6 Sep 2012 14:29:00 +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 pAN4PMJLE4yU; Thu, 6 Sep 2012 14:29:00 +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 60D42D9323; Thu, 6 Sep 2012 14:29:00 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <50487EE8.5020707@cisco.com> Date: Thu, 6 Sep 2012 14:29:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50487EE8.5020707@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1278) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] enterprise ID 0 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, 06 Sep 2012 12:29:05 -0000 Hi, Paul, Yep. I would say an EP SHOULD NOT export such a thing, but that a CP MUST = accept it as an IANA IE. Is this a note for 5101-bis? Cheers, Brian On Sep 6, 2012, at 12:46 PM, Paul Aitken wrote: > Since enterprise ID zero is reserved for IANA (per = http://www.iana.org/assignments/enterprise-numbers), >=20 > and since the IPFIX config model defines "ieEnterpriseNumber" with = zero =3D=3D IANA : >=20 > ieId, ieName, ieEnterpriseNumber: The property to be matched is > specified by either ieId or ieName, specifying the ID or name of > the Information Element, respectively. If ieEnterpriseNumber is > zero (which is the default), this Information Element is > registered in the IANA registry of IPFIX Information Elements > [IANA-IPFIX]. A non-zero value of ieEnterpriseNumber specifies = an > enterprise-specific Information Element. >=20 >=20 > and since there are no exclusions against Enterprise Number =3D=3D 0 = in RFC 5101 or 5101bis, >=20 > can we conclude that it's _not_ an error for an Exporting Process to = send IANA-IEs with E =3D=3D 1 and Enterprise Number =3D=3D 0 ? >=20 > Thanks, > P. >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From andrewf@plixer.com Thu Sep 6 06:37:56 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4243A21F84AF for ; Thu, 6 Sep 2012 06:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ya69nyuKOMfU for ; Thu, 6 Sep 2012 06:37:55 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 3941B21F851E for ; Thu, 6 Sep 2012 06:37:55 -0700 (PDT) Received: from [10.100.1.132] ([65.175.140.2]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Sep 2012 09:37:53 -0400 Message-ID: <5048A731.2040500@plixer.com> Date: Thu, 06 Sep 2012 09:37:53 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/18.0 Thunderbird/18.0a1 MIME-Version: 1.0 To: Brian Trammell References: <50487EE8.5020707@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Sep 2012 13:37:53.0820 (UTC) FILETIME=[D11DEDC0:01CD8C34] Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] enterprise ID 0 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, 06 Sep 2012 13:37:56 -0000 As I understand the question we are only talking about the case where the datatype and semantics are identical for IANA-IE and (IANA-IE & 0x8000) and not some weird second IE space. I'm OK with Brian's suggestion of EP SHOULD NOT and CP MUST. I also think it is worth stating explicitly. I'm pretty sure my CP will not currently accept IEs sent this way, but that can be fixed easily enough. -Andrew On 09/06/2012 08:29 AM, Brian Trammell wrote: > Hi, Paul, > > Yep. > > I would say an EP SHOULD NOT export such a thing, but that a CP MUST accept it as an IANA IE. > > Is this a note for 5101-bis? > > Cheers, > > Brian > > On Sep 6, 2012, at 12:46 PM, Paul Aitken wrote: > >> Since enterprise ID zero is reserved for IANA (per http://www.iana.org/assignments/enterprise-numbers), >> >> and since the IPFIX config model defines "ieEnterpriseNumber" with zero == IANA : >> >> ieId, ieName, ieEnterpriseNumber: The property to be matched is >> specified by either ieId or ieName, specifying the ID or name of >> the Information Element, respectively. If ieEnterpriseNumber is >> zero (which is the default), this Information Element is >> registered in the IANA registry of IPFIX Information Elements >> [IANA-IPFIX]. A non-zero value of ieEnterpriseNumber specifies an >> enterprise-specific Information Element. >> >> >> and since there are no exclusions against Enterprise Number == 0 in RFC 5101 or 5101bis, >> >> can we conclude that it's _not_ an error for an Exporting Process to send IANA-IEs with E == 1 and Enterprise Number == 0 ? >> >> Thanks, >> P. >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Thu Sep 6 06:46:00 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DFC21F8652 for ; Thu, 6 Sep 2012 06:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLevA6qh+Zl2 for ; Thu, 6 Sep 2012 06:45:59 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 92E4D21F8650 for ; Thu, 6 Sep 2012 06:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=682; q=dns/txt; s=iport; t=1346939159; x=1348148759; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JbmJB2vwE0yzorH4wiAxrk3vp4aTeykfXTNAmvNtwl0=; b=iTmI/lfZeUKZ0bDZlcAoSan47dlCnVXVfxvdvFEqFy3elwhprC9lfrLF djU2o4VbCR34CamWOaShYgG7pHcfyCYm9j/0a/4Egg/eLZ/pMQ1RSJDlD TOCkiLM+TObaq1zbK1Vs/JThD08xPdEeX/Fng0YoSHM75QUnOli48ln/P 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANqnSFCQ/khN/2dsb2JhbABFux6BB4IgAQEBAwESASVAAQULCyEWDwkDAgECAUUGDQEHAQEeh2UGmmygHZFWA5VZhV+IVIFngmQ X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="7844679" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 06 Sep 2012 13:45:58 +0000 Received: from [10.55.93.132] (dhcp-10-55-93-132.cisco.com [10.55.93.132]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q86DjvPK017837; Thu, 6 Sep 2012 13:45:58 GMT Message-ID: <5048A916.8040106@cisco.com> Date: Thu, 06 Sep 2012 14:45:58 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Andrew Feren References: <50487EE8.5020707@cisco.com> <5048A731.2040500@plixer.com> In-Reply-To: <5048A731.2040500@plixer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] enterprise ID 0 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, 06 Sep 2012 13:46:00 -0000 Andrew, > As I understand the question we are only talking about the case where > the datatype and semantics are identical for IANA-IE and (IANA-IE & > 0x8000) and not some weird second IE space. That's a good point - there could be a second "parallel" IE space here. We could potentially use this in future if we ever get to 32k IANA elements. > I'm OK with Brian's suggestion of EP SHOULD NOT and CP MUST. I also > think it is worth stating explicitly. So we define equivalence between the two? > I'm pretty sure my CP will not currently accept IEs sent this way, > but that can be fixed easily enough. That's why I asked! :-) Thanks, P. From paitken@cisco.com Mon Sep 10 14:30:00 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A6521F8766 for ; Mon, 10 Sep 2012 14:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXc79ss4fAaS for ; Mon, 10 Sep 2012 14:30:00 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2F53821F8763 for ; Mon, 10 Sep 2012 14:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=265; q=dns/txt; s=iport; t=1347312600; x=1348522200; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=2ukf/D+EmYv8XDoam6PoeW0vEp9qqbC+DZpxr+9tiFs=; b=WDKM7hh+4vA8R1aav4JaIsXXheLixzAZ+X/u5p4Gf/zUlK7yCmTscqy9 aGLXAEhg3vWZ2CtxPZXr0E5ii1LpkTZc/NtKAzw9hLvUZ/I+6yPCDhUnQ BDa2G1j7/Xq8U2Gtr8nhPtwxMYSSWZaUw1Njkm3tfg2yUU+rvrUcia1fP o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAHAElbTlCQ/khM/2dsb2JhbABFjgWtU4EHgjkBJTMNPRYYAwIBAgFLDQgBAR6HbpozgSigIZFCA5VdhV+IV4Fngmc X-IronPort-AV: E=Sophos;i="4.80,400,1344211200"; d="scan'208";a="7939545" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 10 Sep 2012 21:29:59 +0000 Received: from [10.61.87.78] (ams3-vpn-dhcp5967.cisco.com [10.61.87.78]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8ALTw7x008967 for ; Mon, 10 Sep 2012 21:29:59 GMT Message-ID: <504E5BDA.1080003@cisco.com> Date: Mon, 10 Sep 2012 22:30:02 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] IANA IPFIX as normative reference? 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, 10 Sep 2012 21:30:00 -0000 Dear experts, Should new drafts / RFCs cite RFC5102 or IANA's IPFIX registry? Can the IANA registry be cited as a normative reference? (I recall the question being asked recently, though I don't recall a definitive answer.) Thanks, Gerhard and Paul From trammell@tik.ee.ethz.ch Tue Sep 11 04:30:24 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F73521F876A for ; Tue, 11 Sep 2012 04:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aOWo2NJFEzZ for ; Tue, 11 Sep 2012 04:30:23 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4E821F8744 for ; Tue, 11 Sep 2012 04:30:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C19ABD9309; Tue, 11 Sep 2012 13:30:21 +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 uZ52zif3OL33; Tue, 11 Sep 2012 13:30:21 +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 7955AD9308; Tue, 11 Sep 2012 13:30:21 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <504E5BDA.1080003@cisco.com> Date: Tue, 11 Sep 2012 13:30:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <82B78421-04F2-46AF-AA64-B582507D1F4E@tik.ee.ethz.ch> References: <504E5BDA.1080003@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1278) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IANA IPFIX as normative reference? 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, 11 Sep 2012 11:30:24 -0000 hi Paul, all, if I get a say, I'd say "IANA" and "yes". This is the assumption = presently made in ie-doctors and 5101bis/5102bis. Cheers, Brian On Sep 10, 2012, at 11:30 PM, Paul Aitken wrote: > Dear experts, >=20 > Should new drafts / RFCs cite RFC5102 or IANA's IPFIX registry? >=20 > Can the IANA registry be cited as a normative reference? >=20 > (I recall the question being asked recently, though I don't recall a = definitive answer.) >=20 > Thanks, > Gerhard and Paul > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Tue Sep 11 04:33:42 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B004121F86F9 for ; Tue, 11 Sep 2012 04:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnEnw+CiN1th for ; Tue, 11 Sep 2012 04:33:41 -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 E6C5121F8736 for ; Tue, 11 Sep 2012 04:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=806; q=dns/txt; s=iport; t=1347363221; x=1348572821; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=5YMf+CjTBbJANJJfooAvjFvPFZ66FnbmoQym/wqYChU=; b=k+JrhIwQkEIJ8e+oi4bONuVNLxU7AtZqWSv7q0KTVal9zob9Sgx4/J8S JIe3HjHc1wzCvHF0C+wmIUtCOB5ckcNOCfHqLGqToWUOIshehYhwX6ofM zMa+l5+P38JwyKJBvIRpbMyTg6QXTzF9x+2g5Vs1fd8PS62AdSXrWNWne g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAFcgT1CQ/khM/2dsb2JhbABFhUC2EIEHgiABAQEDAQEBAQ8BJTMDCgEFCwsYCRYPCQMCAQIBFTAGDQEFAgEBHodoBgubQ6BNBIsQhiYDlV2FX4hXgWeCZw X-IronPort-AV: E=Sophos;i="4.80,404,1344211200"; d="scan'208";a="7960647" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 11 Sep 2012 11:33:38 +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 q8BBXbjL026301; Tue, 11 Sep 2012 11:33:38 GMT Message-ID: <504F2191.1080405@cisco.com> Date: Tue, 11 Sep 2012 12:33:37 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Brian Trammell References: <504E5BDA.1080003@cisco.com> <82B78421-04F2-46AF-AA64-B582507D1F4E@tik.ee.ethz.ch> In-Reply-To: <82B78421-04F2-46AF-AA64-B582507D1F4E@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] IANA IPFIX as normative reference? 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, 11 Sep 2012 11:33:42 -0000 Brian, +1. I'd like to do the same in IPFIX-config, which is currently in AUTH48. Does this assumption need chair / AD approval? Thanks, P. > hi Paul, all, > > if I get a say, I'd say "IANA" and "yes". This is the assumption presently made in ie-doctors and 5101bis/5102bis. > > Cheers, > > Brian > > On Sep 10, 2012, at 11:30 PM, Paul Aitken wrote: > >> Dear experts, >> >> Should new drafts / RFCs cite RFC5102 or IANA's IPFIX registry? >> >> Can the IANA registry be cited as a normative reference? >> >> (I recall the question being asked recently, though I don't recall a definitive answer.) >> >> Thanks, >> Gerhard and Paul >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Wed Sep 12 01:16:52 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454A521F865F for ; Wed, 12 Sep 2012 01:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.757 X-Spam-Level: X-Spam-Status: No, score=-4.757 tagged_above=-999 required=5 tests=[AWL=-2.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZko+sem7myj for ; Wed, 12 Sep 2012 01:16:51 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id F30F721F865C for ; Wed, 12 Sep 2012 01:16:50 -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 q8C8GjIW007879; Wed, 12 Sep 2012 10:16:45 +0200 (CEST) Received: from [10.60.67.93] (ams-bclaise-89112.cisco.com [10.60.67.93]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8C8GiSK007715; Wed, 12 Sep 2012 10:16:44 +0200 (CEST) Message-ID: <505044EC.50908@cisco.com> Date: Wed, 12 Sep 2012 10:16:44 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Paul Aitken References: <504E5BDA.1080003@cisco.com> <82B78421-04F2-46AF-AA64-B582507D1F4E@tik.ee.ethz.ch> <504F2191.1080405@cisco.com> In-Reply-To: <504F2191.1080405@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IANA IPFIX as normative reference? 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, 12 Sep 2012 08:16:52 -0000 Dear all, > Brian, > > +1. I'd like to do the same in IPFIX-config, which is currently in > AUTH48. Agreed. > > Does this assumption need chair / AD approval? Approved. Let's use the IANA's IPFIX registry, as a normative reference, from now on. Regards, Benoit (OPS AD hat on) > Thanks, > P. > >> hi Paul, all, >> >> if I get a say, I'd say "IANA" and "yes". This is the assumption >> presently made in ie-doctors and 5101bis/5102bis. >> >> Cheers, >> >> Brian >> >> On Sep 10, 2012, at 11:30 PM, Paul Aitken wrote: >> >>> Dear experts, >>> >>> Should new drafts / RFCs cite RFC5102 or IANA's IPFIX registry? >>> >>> Can the IANA registry be cited as a normative reference? >>> >>> (I recall the question being asked recently, though I don't recall a >>> definitive answer.) >>> >>> Thanks, >>> Gerhard and Paul >>> _______________________________________________ >>> 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 muenz@net.in.tum.de Wed Sep 12 13:58:06 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3262221F861E for ; Wed, 12 Sep 2012 13:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruT0PN+WJ+nI for ; Wed, 12 Sep 2012 13:58:05 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id D9B7A21F8578 for ; Wed, 12 Sep 2012 13:57:43 -0700 (PDT) Received: from [192.168.2.36] (g229243070.adsl.alicedsl.de [92.229.243.70]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 3D02B188DEBD; Wed, 12 Sep 2012 22:57:40 +0200 (CEST) Message-ID: <5050F71C.9060508@net.in.tum.de> Date: Wed, 12 Sep 2012 22:57:00 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Aitken References: <50487EE8.5020707@cisco.com> <5048A731.2040500@plixer.com> <5048A916.8040106@cisco.com> In-Reply-To: <5048A916.8040106@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] enterprise ID 0 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, 12 Sep 2012 20:58:06 -0000 Hi, An enterprise number parameter also appears in the IPFIX MIB (see ipfixTemplateDefinitionEnterpriseNumber): DESCRIPTION "IANA enterprise number of the authority defining the Information Element identifier in this Template Record. Enterprise numbers are assigned by IANA. A current list of all assignments is available from . This object must be zero(0) for all standard Information Elements registered with IANA. A current list of these elements is available from ." A zero value for this MIB parameter or for the enterprise number parameters appearing in IPFIX CONFIG does not imply that a zero enterprise number value appears in any IPFIX message. I think it is clear that enterprise-specific IEs must have a non-zero enterprise number, and therefore there should not be a problem if data models take the forbidden zero value as an indicator for IANA-IEs. Thanks, Gerhard On 06.09.2012 15:45, Paul Aitken wrote: > Andrew, > >> As I understand the question we are only talking about the case where >> the datatype and semantics are identical for IANA-IE and (IANA-IE & >> 0x8000) and not some weird second IE space. > > That's a good point - there could be a second "parallel" IE space here. > We could potentially use this in future if we ever get to 32k IANA elements. > > >> I'm OK with Brian's suggestion of EP SHOULD NOT and CP MUST. I also >> think it is worth stating explicitly. > > So we define equivalence between the two? > > >> I'm pretty sure my CP will not currently accept IEs sent this way, >> but that can be fixed easily enough. > > That's why I asked! :-) > > > Thanks, > P. > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > From n.brownlee@auckland.ac.nz Wed Sep 12 15:32:52 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF3821F8514 for ; Wed, 12 Sep 2012 15:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axhp6uC5vgJq for ; Wed, 12 Sep 2012 15:32:51 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 94A1021F8504 for ; Wed, 12 Sep 2012 15:32:49 -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=1347489171; x=1379025171; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=wRJDjTjmgOnm4MP0kVrLD3P62Gxym7yO3OVO0wkeh4U=; b=HV0aDrdSwNHZaUMgyQsZS8ftjD4YJI2DmmYNUXXNZHm7ki/6dd3yhKhB n0m3oZNRR32sa9ENI8gIwIzRzJlGwOPvJCRLgMD6vfyTw1s/gq4j6zNXN 5tAGJ9w83cN3S2MI5K+k5g8CxrBTZSt78G2egHpIg1S2EeXmqSVLGdAGw o=; X-IronPort-AV: E=Sophos;i="4.80,413,1344168000"; d="scan'208";a="144739038" 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; 13 Sep 2012 10:32:47 +1200 Message-ID: <50510D8E.9040500@auckland.ac.nz> Date: Thu, 13 Sep 2012 10:32:46 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ronald Bonica Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: [IPFIX] Shepherd write-up for draft-ietf-ipfix-a9n-06.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 22:32:53 -0000 Hi Ron: I'm sending this shepherd write-up to you since Benoit is one of this draft's authors. Please start the process of submitting it to IESG for us. Cheers, Nevil Document: draft-ietf-ipfix-a9n-06.txt Title: Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol Editors: Brian Trammell, Arno Wagner, Benoit Claise Intended status: Standards Track (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Standards Track. Needs to be so that all implementations will aggregate IPFIX flow data in the same way. Yes, its header says 'Standards Track.' (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export (IPFIX) Protocol to the handling of Aggregated Flows, which are IPFIX Flows representing packets from multiple Original Flows that share some set of common properties. Working Group Summary This draft attracted real discussion on the IPFIX list, and took time to reach consensus on its final approach, i.e. "through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals." Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? I'm not aware of any, so far. Are there any reviewers that merit special mention as having done a thorough review ... ? Rahul Patel was a strong contributor to the discussion, Paul Aitken provided a very thorough review. Personnel Who is the Document Shepherd? Nevil Brownlee Who is the Responsible Area Director? Benoit Claise (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have followed this draft carefully from its -00 version, particularly it's notion of of 'spatial aggregation,' a topic which needs careful definition of its terms! I feel that it is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. This draft follows tha IPFIX naming conventions; those are its only external dependencies. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No (but see section 8). (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes (see section 8 for more detail) (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. We (the IPFIX WG) were unaware of any IPR for this draft until it was in WG Last Call. Carter Bullard raised the question, we now have two IPR decparations (Avaya and Cisco) and no others have come forward. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG as a whole has reached strong consensus on this draft. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. ID-nits says "0 errors" (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal reviews required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? Normative reference to I-D 5101-bis. IPFIX 5101bis (and 5102bis) are close to WG Last Call, that's now the WG's highest-priority activity. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The draft's IANA Considerations only requires some new IPFIX Information Elements to be assigned, its instructions for that are clear and consistent. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No sections in a formal language. -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From trammell@tik.ee.ethz.ch Fri Sep 14 06:35:01 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3B521F849A for ; Fri, 14 Sep 2012 06:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFwVZfKTWZHU for ; Fri, 14 Sep 2012 06:34:59 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3B61421F8498 for ; Fri, 14 Sep 2012 06:34:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C01CDD930D; Fri, 14 Sep 2012 15:34:57 +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 3ll7dIgl-tlH; Fri, 14 Sep 2012 15:34:57 +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 8C016D930A; Fri, 14 Sep 2012 15:34:57 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <918337CC-0D0B-4AB9-B3F7-BE4AC6828CE5@tik.ee.ethz.ch> Date: Fri, 14 Sep 2012 15:34:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <699C6609-B366-4771-8718-FDEC11F23C08@tik.ee.ethz.ch> References: <20120831165653.9430.22489.idtracker@ietfa.amsl.com> <5044C8A9.6090703@cisco.com> <56DE85D5-8B82-4351-826F-2B5D75E3F95C@tik.ee.ethz.ch> <5044E42A.7050303@cisco.com> <918337CC-0D0B-4AB9-B3F7-BE4AC6828CE5@tik.ee.ethz.ch> To: Paul Aitken X-Mailer: Apple Mail (2.1278) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-ie-doctors-04.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, 14 Sep 2012 13:35:01 -0000 Hi, Paul, all, On reflection, I can't really see how fixing the status of the Units = registry in 5610 would be in scope for this draft; therefore, in my = opinion, ie-doctors-04 is in its present state ready for the IESG, with = the note that a revision addressing comments/discusses from the IESG = will also include an update to note that Units is extended subject to = Expert Review, and to correct Benoit's address. I'm still not certain as to the best approach to fix 5610 with respect = to its definition of the Units registry as FCFS; would a technical = erratum suffice? (Is there an AD in the house with an opinion? :) ) Best regards, Brian On Sep 3, 2012, at 7:53 PM, Brian Trammell wrote: > Hi, Paul, >=20 > As the registry (to date) has been de facto expert review (and there = have been no registrations), I don't see any problem with this. >=20 > However, can IE-DOCTORS update 5610? 5610 is Standards Track, and = IE-DOCTORS targets BCP. If not, this would be a technical erratum on = 5610. >=20 > Cheers, >=20 > Brian >=20 >=20 > On Sep 3, 2012, at 7:08 PM, Paul Aitken wrote: >=20 >> Brian, >>=20 >>> Hi, Paul, >>>=20 >>> Interesting. >>>=20 >>> I hadn't checked the registry, but I can say that the FCFS policy = for Units was intentional: imagine a an enterprise-specific information = element designed to do something very odd with unorthodox units, say, = counting rats crawling around in the underfloor space in a data center = (perhaps to attempt to correlate packet loss with rodent infestation). = Now, the IEs for this would be ESIEs, but since this is a research = study, we'd want to annotate the data (stored in files) with 5610 type = information records. >>=20 >> ie, 5610 allows units to be expressed for enterprise-specific IEs. >>=20 >>=20 >>> However, on review, perhaps Units in the IANA registry should cover = only those IEs in the IANA registry, and if you want to do something = really odd, you should leave units blank and explain "expressed in rats = per cubic meter as measured by the Yoyodyne Underfloor Rat Counter model = 19" in the informationElementDescription field. But that was the intent. >>=20 >> This would prevent 5610 from working properly, since I couldn't = created a "rats" unit for my ESIEs. >>=20 >> And if an IE is already in IANA's IPFIX registry, then it already has = a type - so there'd be no need for it in 5610. >>=20 >>=20 >>> If we decide this, the proper thing to do is to go with the registry = as is and change IE-DOCTORS to update RFC 5610. >>=20 >> I think the "IPFIX units" registry should be subject to expert review = - which allows enterprises to request "rats" for their = enterprise-specific IEs if they want to use 5610, provided they can = convince the expert reviewer that they have an IPFIX-enabled rat = counter. >>=20 >> However, it ensures that IANA won't assign a lot of stupid units = which may be requested by miscreants. >>=20 >> If all agree, then I'd be happy for IE-docs to update 5610 (and leave = the registry unchanged). >>=20 >> P. >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Fri Sep 14 12:29:58 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8183A21F8532 for ; Fri, 14 Sep 2012 12:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lg3yo1ocCFua for ; Fri, 14 Sep 2012 12:29:57 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 49D3D21F852C for ; Fri, 14 Sep 2012 12:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6119; q=dns/txt; s=iport; t=1347650997; x=1348860597; h=message-id:date:from:mime-version:to:subject; bh=UZCRfGoY11VmFwLPSZLXSyDZmWBSdPzDQUnd+gwafJs=; b=CM2I08Q6OqnrOdW9kF34K2tzlJiVKVsp9vnqrrSBm/R9M11tfdRN6ZQ0 1nrzAfgHvFMcMKX25kh2bezncbSq7WTmuKlBZgSLCpwuVkfsDzp+fLd5D MEGRfGwckQUybuqhEM383FihLFkr69z6cGpiSzYXirI64dR6Qz2LkTnfw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAP2EU1CQ/khR/2dsb2JhbABFi2awJIEHgjkBWA09FhgDAgECAUsNCAEBHodrC5oTgSigJJIHA5VhgRSETIhYgWmCZw X-IronPort-AV: E=Sophos;i="4.80,424,1344211200"; d="scan'208,217";a="8048729" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 14 Sep 2012 19:29:56 +0000 Received: from [10.55.89.228] (dhcp-10-55-89-228.cisco.com [10.55.89.228]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8EJTt3l022405 for ; Fri, 14 Sep 2012 19:29:55 GMT Message-ID: <505385B4.9010108@cisco.com> Date: Fri, 14 Sep 2012 20:29:56 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: multipart/alternative; boundary="------------090103070804080707030604" Subject: [IPFIX] revising IPFIX IES 281 and 282 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, 14 Sep 2012 19:29:58 -0000 This is a multi-part message in MIME format. --------------090103070804080707030604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear experts, I propose to request that IANA modify IEs 281 and 282 to remove "NAT64" from their descriptions, to make them generic post-NAT-IPv6-adddress fields per their names. And also take the opportunity to update "draft-ietf-behave-v6v4-xlate-stateful-12" to RFC6146. ie, removing the text in *red* below, and adding the text in *green*. Perhaps we should add some other NAT RFCs, or entirely remove the last sentence, "See ... for specification" ? Support? Feedback? Objections? Thanks, P. 281 postNATSourceIPv6Address ipv6Address current The definition of this Information Element is identical to the definition of Information Element 'sourceIPv6Address', except that it reports a modified value caused by a *NAT64* middlebox function after the packet passed the Observation Point. See [RFC2460] for the definition of the Source Address field in the IPv6 header. See [RFC3234] for the definition of middleboxes. See *http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-12* *RFC6146* for nat64 specification. 282 postNATDestinationIPv6Address ipv6Address current The definition of this Information Element is identical to the definition of Information Element 'destinationIPv6Address', except that it reports a modified value caused by a *NAT64* middlebox function after the packet passed the Observation Point. See [RFC2460] for the definition of the Destination Address field in the IPv6 header. See [RFC3234] for the definition of middleboxes. See *http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-12* *RFC6146* for nat64 specification. --------------090103070804080707030604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear experts,


I propose to request that IANA modify IEs 281 and 282 to remove "NAT64" from their descriptions, to make them generic post-NAT-IPv6-adddress fields per their names.
And also take the opportunity to update "draft-ietf-behave-v6v4-xlate-stateful-12" to RFC6146.

ie, removing the text in red below, and adding the text in green.

Perhaps we should add some other NAT RFCs, or entirely remove the last sentence, "See ... for specification" ?

Support? Feedback? Objections?

Thanks,
P.


281    postNATSourceIPv6Address    ipv6Address    current

          The definition of this Information Element is identical to
          the definition of Information Element 'sourceIPv6Address', except that
          it reports a modified value caused by a NAT64 middlebox function after
          the packet passed the Observation Point.
          
          See [RFC2460] for the definition of the Source Address field in the IPv6
          header. See [RFC3234] for the definition of middleboxes. See
          http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-12 RFC6146 for
          nat64 specification.


282    postNATDestinationIPv6Address    ipv6Address    current

          The definition of this Information Element is identical to
          the definition of Information Element 'destinationIPv6Address', except
          that it reports a modified value caused by a NAT64 middlebox function
          after the packet passed the Observation Point.
          
          See [RFC2460] for the definition of the Destination Address field in the
          IPv6 header. See [RFC3234] for the definition of middleboxes. See
          http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-12 RFC6146 for
          nat64 specification.
       
--------------090103070804080707030604-- From andrewf@plixer.com Fri Sep 14 13:35:42 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6644A21F8567 for ; Fri, 14 Sep 2012 13:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBtG++QTwiDP for ; Fri, 14 Sep 2012 13:35:41 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD0D21F8566 for ; Fri, 14 Sep 2012 13:35:41 -0700 (PDT) Received: from [10.100.1.132] ([10.100.1.132]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Sep 2012 16:35:40 -0400 Message-ID: <5053951B.5090108@plixer.com> Date: Fri, 14 Sep 2012 16:35:39 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/18.0 Thunderbird/18.0a1 MIME-Version: 1.0 To: Paul Aitken References: <505385B4.9010108@cisco.com> In-Reply-To: <505385B4.9010108@cisco.com> Content-Type: multipart/alternative; boundary="------------010109010000040208060101" X-OriginalArrivalTime: 14 Sep 2012 20:35:40.0187 (UTC) FILETIME=[8123FEB0:01CD92B8] Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] revising IPFIX IES 281 and 282 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, 14 Sep 2012 20:35:42 -0000 This is a multi-part message in MIME format. --------------010109010000040208060101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit At the very least I would think the references should be in the references field. Probably applies equally to IEs: 46, 101, 208, 281, 282, 304, 361, 362, 368, 369 46, 208, 368, 369 puts the reference in the description and references. The others in the above list have references only in the description. All other IEs have any references in the references field. I also noticed that there is a mixed bag of links I can click on and text URLs that I need to copy and past. As for removing NAT64 from the description my initial reaction is that it is a good idea. -Andrew On 09/14/2012 03:29 PM, Paul Aitken wrote: > Dear experts, > > > I propose to request that IANA modify IEs 281 and 282 to remove > "NAT64" from their descriptions, to make them generic > post-NAT-IPv6-adddress fields per their names. > And also take the opportunity to update > "draft-ietf-behave-v6v4-xlate-stateful-12" to RFC6146. > > ie, removing the text in *red* below, and adding the text in *green*. > > Perhaps we should add some other NAT RFCs, or entirely remove the last > sentence, "See ... for specification" ? > > Support? Feedback? Objections? > > Thanks, > P. > > > 281 postNATSourceIPv6Address ipv6Address current > > The definition of this Information Element is identical to > the definition of Information Element 'sourceIPv6Address', > except that > it reports a modified value caused by a *NAT64* middlebox > function after > the packet passed the Observation Point. > > See [RFC2460] for the definition of the Source Address field > in the IPv6 > header. See [RFC3234] for the definition of middleboxes. See > *http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-12* > *RFC6146* for > nat64 specification. > > > 282 postNATDestinationIPv6Address ipv6Address current > > The definition of this Information Element is identical to > the definition of Information Element > 'destinationIPv6Address', except > that it reports a modified value caused by a *NAT64* > middlebox function > after the packet passed the Observation Point. > > See [RFC2460] for the definition of the Destination Address > field in the > IPv6 header. See [RFC3234] for the definition of > middleboxes. See > *http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-12* > *RFC6146* for > nat64 specification. > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------010109010000040208060101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
At the very least I would think the references should be in the references field.

Probably applies equally to IEs: 46, 101, 208, 281, 282, 304, 361, 362, 368, 369

46, 208, 368, 369 puts the reference in the description and references.  The others in the above list have references only in the description.  All other IEs have any references in the references field.

I also noticed that there is a mixed bag of links I can click on and text URLs that I need to copy and past.

As for removing NAT64 from the description my initial reaction is that it is a good idea.

-Andrew

On 09/14/2012 03:29 PM, Paul Aitken wrote:
Dear experts,


I propose to request that IANA modify IEs 281 and 282 to remove "NAT64" from their descriptions, to make them generic post-NAT-IPv6-adddress fields per their names.
And also take the opportunity to update "draft-ietf-behave-v6v4-xlate-stateful-12" to RFC6146.

ie, removing the text in red below, and adding the text in green.

Perhaps we should add some other NAT RFCs, or entirely remove the last sentence, "See ... for specification" ?

Support? Feedback? Objections?

Thanks,
P.


281    postNATSourceIPv6Address    ipv6Address    current

          The definition of this Information Element is identical to
          the definition of Information Element 'sourceIPv6Address', except that
          it reports a modified value caused by a NAT64 middlebox function after
          the packet passed the Observation Point.
          
          See [RFC2460] for the definition of the Source Address field in the IPv6
          header. See [RFC3234] for the definition of middleboxes. See
          http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-12 RFC6146 for
          nat64 specification.


282    postNATDestinationIPv6Address    ipv6Address    current

          The definition of this Information Element is identical to
          the definition of Information Element 'destinationIPv6Address', except
          that it reports a modified value caused by a NAT64 middlebox function
          after the packet passed the Observation Point.
          
          See [RFC2460] for the definition of the Destination Address field in the
          IPv6 header. See [RFC3234] for the definition of middleboxes. See
          http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-12 RFC6146 for
          nat64 specification.
        


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

--------------010109010000040208060101-- From bclaise@cisco.com Mon Sep 17 02:33:27 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4750421F8452 for ; Mon, 17 Sep 2012 02:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.778 X-Spam-Level: X-Spam-Status: No, score=-4.778 tagged_above=-999 required=5 tests=[AWL=-2.180, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6er12HQyiVK4 for ; Mon, 17 Sep 2012 02:33:26 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA2121F844A for ; Mon, 17 Sep 2012 02:33:25 -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 q8H9XMBZ009633 for ; Mon, 17 Sep 2012 11:33:22 +0200 (CEST) Received: from [10.149.4.124] (dhcp-10-149-4-124.cisco.com [10.149.4.124]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8H9XLK2001507 for ; Mon, 17 Sep 2012 11:33:21 +0200 (CEST) Message-ID: <5056EE61.9000706@cisco.com> Date: Mon, 17 Sep 2012 11:33:21 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <20120914162319.27359.99481.idtracker@ietfa.amsl.com> In-Reply-To: <20120914162319.27359.99481.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120914162319.27359.99481.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000703050100010901000207" Subject: [IPFIX] Fwd: Expert for "IP Flow Information Export (IPFIX) Entities Classification Engine IDs" 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, 17 Sep 2012 09:33:27 -0000 This is a multi-part message in MIME format. --------------000703050100010901000207 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit FYI. Regards, Benoit. -------- Original Message -------- Subject: Expert for "IP Flow Information Export (IPFIX) Entities Classification Engine IDs" Date: Fri, 14 Sep 2012 09:23:19 -0700 From: IESG Secretary To: iana@iana.org CC: iesg@ietf.org IANA: The IESG has approved Nevil Brownlee (n.brownlee@auckland.ac.nz) as the primary expert and Juergen Quittek (quittek@neclab.eu) as the secondary expert for "IP Flow Information Export (IPFIX) Entities Classification Engine IDs." Best regards, IESG Secretary On Sep 11, 2012, at 9:26 AM, Benoit Claise via RT wrote: http://www.iana.org/assignments/ipfix/ipfix.xml#classification-engine-ids require an expert. The draft behind this IANA discussion is http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-10 Exactly like for the http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-mpls-label-type, I propose: Primary expert - Nevil Brownlee and Secondary expert - Juergen Quittek --------------000703050100010901000207 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit FYI.

Regards, Benoit.


-------- Original Message --------
Subject: Expert for "IP Flow Information Export (IPFIX) Entities Classification Engine IDs"
Date: Fri, 14 Sep 2012 09:23:19 -0700
From: IESG Secretary <iesg-secretary@ietf.org>
To: iana@iana.org
CC: iesg@ietf.org 


IANA:

The IESG has approved Nevil Brownlee  (n.brownlee@auckland.ac.nz) as the 
primary expert and Juergen Quittek (quittek@neclab.eu) as the secondary 
expert for "IP Flow Information Export (IPFIX) Entities Classification Engine IDs."

Best regards,
IESG Secretary


On Sep 11, 2012, at 9:26 AM, Benoit Claise via RT wrote:

http://www.iana.org/assignments/ipfix/ipfix.xml#classification-engine-ids require an expert.
The draft behind this IANA discussion is 
http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-10
Exactly like for the 
http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-mpls-label-type, I 
propose:
    Primary expert - Nevil Brownlee and Secondary expert - Juergen Quittek



--------------000703050100010901000207-- From bclaise@cisco.com Mon Sep 17 03:23:07 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6938921F85C3 for ; Mon, 17 Sep 2012 03:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.708 X-Spam-Level: X-Spam-Status: No, score=-8.708 tagged_above=-999 required=5 tests=[AWL=1.891, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO4wySww0Mpx for ; Mon, 17 Sep 2012 03:23:06 -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 674B621F85B4 for ; Mon, 17 Sep 2012 03:23:06 -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 q8HAN0FJ016046; Mon, 17 Sep 2012 12:23:00 +0200 (CEST) Received: from [10.149.4.124] (dhcp-10-149-4-124.cisco.com [10.149.4.124]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8HAMwwj012498; Mon, 17 Sep 2012 12:22:58 +0200 (CEST) Message-ID: <5056FA02.2060805@cisco.com> Date: Mon, 17 Sep 2012 12:22:58 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Aitken References: <50293594.4030006@cisco.com> In-Reply-To: <50293594.4030006@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] IANA IPFIX announcement mailing list? 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, 17 Sep 2012 10:23:07 -0000 Hi Paul, Having a formal process might imply some overhead on the IANA people. However, I believe into a light process, initiated by one of the IPFIX experts here. For example, every month, an email would be sent to this list, with the new IEs as a "FYI" Regards, Benoit. > Dear Chairs, AD, > > Could IANA support an IPFIX-announce mailing list, to which new > information element allocations / changes / etc are sent? > > ie, a lower-volume mailing list than the IPFIX list, for those who are > only interested in new IEs. > > Else, can the IPFIX mailing list survive in perpetuity, with IANA > posting announcements there with a special/known/fixed format which > can easily be filtered? > > Today, announcements may, or may not, be sent to the IPFIX list; > there's no official policy. Perhaps IE-doctors should discuss this. > > Thanks, > P. > > From paitken@cisco.com Mon Sep 17 05:08:23 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93ACB21F864D for ; Mon, 17 Sep 2012 05:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPYZks9NtEWX for ; Mon, 17 Sep 2012 05:08:22 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7698021F8618 for ; Mon, 17 Sep 2012 05:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=421; q=dns/txt; s=iport; t=1347883702; x=1349093302; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=RGVulHBp5JJo8JCJNxRoWQP5ueK0IlyiXq4TNFOGBPo=; b=QF+nPFwsoY496YfyjezywwKBecVFdt7C41RPIRasRyLRQWb4DX5WxPWa 4c3c12MdY4z5Q6LptnNmp9aJFFc6GUQqeGWsmiO8KMkDqnW/sN7Hl7tJP oBpI3d5t3g877s8Kgfs6SKniSA9Bzw+ET18+bu+ylAI7T2UVebz4ThKlN Q=; X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="8094124" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 17 Sep 2012 12:08:18 +0000 Received: from [10.55.85.91] (dhcp-10-55-85-91.cisco.com [10.55.85.91]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8HC8Htf009353; Mon, 17 Sep 2012 12:08:17 GMT Message-ID: <505712B4.7050003@cisco.com> Date: Mon, 17 Sep 2012 13:08:20 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Benoit Claise References: <50293594.4030006@cisco.com> <5056FA02.2060805@cisco.com> In-Reply-To: <5056FA02.2060805@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] IANA IPFIX announcement mailing list? 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, 17 Sep 2012 12:08:23 -0000 Benoit, > Having a formal process might imply some overhead on the IANA people. > However, I believe into a light process, initiated by one of the IPFIX > experts here. > For example, every month, an email would be sent to this list, with > the new IEs as a "FYI" Since I am the only private (non-RFC) requester of new Information Elements and registry changes, I'll make a point of announcing them. P. From bclaise@cisco.com Mon Sep 17 05:14:20 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5778E21F8645 for ; Mon, 17 Sep 2012 05:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.749 X-Spam-Level: X-Spam-Status: No, score=-8.749 tagged_above=-999 required=5 tests=[AWL=1.850, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LX5RgDyXBfr for ; Mon, 17 Sep 2012 05:14:19 -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 8859A21F85ED for ; Mon, 17 Sep 2012 05:14:19 -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 q8HCED62029537; Mon, 17 Sep 2012 14:14:14 +0200 (CEST) Received: from [10.149.0.72] (dhcp-10-149-0-72.cisco.com [10.149.0.72]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8HCEAXw012734; Mon, 17 Sep 2012 14:14:10 +0200 (CEST) Message-ID: <50571412.2040203@cisco.com> Date: Mon, 17 Sep 2012 14:14:10 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Aitken References: <50293594.4030006@cisco.com> <5056FA02.2060805@cisco.com> <505712B4.7050003@cisco.com> In-Reply-To: <505712B4.7050003@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] IANA IPFIX announcement mailing list? 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, 17 Sep 2012 12:14:20 -0000 Thanks Paul! Regards, Benoit. > Benoit, > >> Having a formal process might imply some overhead on the IANA people. >> However, I believe into a light process, initiated by one of the >> IPFIX experts here. >> For example, every month, an email would be sent to this list, with >> the new IEs as a "FYI" > > Since I am the only private (non-RFC) requester of new Information > Elements and registry changes, I'll make a point of announcing them. > > P. > > From bclaise@cisco.com Tue Sep 18 06:33:30 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A84721F8607 for ; Tue, 18 Sep 2012 06:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.756 X-Spam-Level: X-Spam-Status: No, score=-8.756 tagged_above=-999 required=5 tests=[AWL=1.843, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbDczZ3sspCF for ; Tue, 18 Sep 2012 06:33:29 -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 D778921F8604 for ; Tue, 18 Sep 2012 06:33:28 -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 q8IDXQWI010108; Tue, 18 Sep 2012 15:33:27 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8IDXP5J004536; Tue, 18 Sep 2012 15:33:26 +0200 (CEST) Message-ID: <50587825.9020305@cisco.com> Date: Tue, 18 Sep 2012 15:33:25 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Brian Trammell References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Promotion of Enterprise-Specific IEs to IANA IEs 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, 18 Sep 2012 13:33:30 -0000 Dear all, [catching up with emails after my vacation] I believe that "IE equivalence options template" (solution 2) sounds like a nice idea but will not work in real live. In a perfect world, all the EPs would export this "IE equivalence options template" and the CP could ONLY rely on this mechanism. We don't live in a perfect world, so not all EPs will export this options template. This implies that the CPs need anyway a plan B: hard coding the mapping, potentially received from IANA. This is the exact same example as RFC5610. It's not implemented by all EPs (because we don't live in a perfect world), so the CPs must sometimes hard code the information, and they can rely on RFC5610 only. Now, I would like to hear from the collectors people on the list: - Would the "IE equivalence options template" be an important improvements? Warning: assuming that only some EPs might implement this feature! - What about the fact that the collectors don't update the registry frequently from IANA, as an argument for the solution (2) below? Do you update from IANA? Yes/No? how frequently? Regards, Benoit. > Greetings, all, > > To close the discussion from Vancouver, we have two proposals under consideration for handling the transition of enterprise-specific IEs used for testing, research, or other pre-standardization purposes to IANA IEs: > > (1) The addition of an Enterprise-specific Reference column to the IANA registry, which would include PEN(s) and IE number(s) which have a description compatible with the IANA-registered IE; this is covered in the present revision of the IE-DOCTORS draft. The advantage of this is it provides a central registry; however, it presumes a model in which CPs are either frequently updated or periodically retrieve new registration information from IANA, and requires all users of ESIE codepoints replaced with an IANA codepoint to register that information with IANA. > > (2) The definition of an IE equivalence options template, which would define the equivalence of a set of IANA and enterprise-specific IEs. This would be sent by EPs which had updated an IE from an older enterprise-specific codepoint to a new IANA codepoint; this would be covered in a new draft which Paul Aitken has (I think) already started work on. This has the advantage that equivalence is not dependent on the IANA registry. Benoit noted that this required the EP to (i) send additional information on session startup and (ii) to be updated both to use the new IANA codepoint as well as to send this additional information: a CP would not know an old ESIE was equivalent to a newer IANA IE if the EP it was receiving data from had not been updated. > > As I see it, there are four possible ways forward: > > (a) Support both methods: Leave approach (1) in IE-DOCTORS, develop a draft describing approach (2). > > (b) Support only the IANA method: leave approach (1) in IE-DOCTORS. > > (c) Support only the Options method: remove approach (1) from IE-DOCTORS, develop a draft describing approach (2). > > (d) Defer the question and leave ESIE promotion an open issue: remove approach (1) from IE-DOCTORS with no present decision on a draft about approach (2). > > I suppose I'm in favor of option (a), since each approach has its own use cases, as long as we're clear in both IE-DOCTORS and the equivalence options draft about the applicability of each approach. > > Thoughts? > > Cheers, > > Brian > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > > From paitken@cisco.com Tue Sep 18 06:48:45 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415A121F8764 for ; Tue, 18 Sep 2012 06:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5V1KMbFw6Al for ; Tue, 18 Sep 2012 06:48:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id DEB1D21F8762 for ; Tue, 18 Sep 2012 06:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5113; q=dns/txt; s=iport; t=1347976124; x=1349185724; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lmre3gCguI/o7fDulS3NdMnLju/KW12orfuNAFrbvhU=; b=TiHi34hasUeHlxu3JrKWj/sh3HvXCcBlLNvRim1jcdSshEle0gf64XOS e2pmrp3MsXTgGfML4VYVD6h/HKg07Z1IsuCu94M1AYHJtYmC2t+4R0ina L39KSk5otbyaqA29pPaRHmeoNC7M/vLP1qk+ZoM4Ol6qy69o55F9BEmRu Q=; X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="143985936" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 18 Sep 2012 13:48:42 +0000 Received: from [144.254.153.46] (dhcp-144-254-153-46.cisco.com [144.254.153.46]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8IDmfst008435; Tue, 18 Sep 2012 13:48:42 GMT Message-ID: <50587BB9.8010108@cisco.com> Date: Tue, 18 Sep 2012 14:48:41 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Benoit Claise References: <50587825.9020305@cisco.com> In-Reply-To: <50587825.9020305@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Promotion of Enterprise-Specific IEs to IANA IEs 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, 18 Sep 2012 13:48:45 -0000 Benoit, 0. Your argument that "we don't live in a perfect world" doesn't hold in this case. Although the world may be imperfect, IPFIX implementers MUST follow the defined standards. I can't simply put the wrong export version, or use the wrong set ID, or the wrong field sizes, or send NFv5 to your IPFIX collector, and simply claim "but we don't live in a perfect world!". 1. If the equivalence options template is mandated as the IPFIX mechanism, then EPs MUST implement it to be IPFIX compliant, perfect world or not. 1a. Whereas, if we give a choice of two mechanisms, some may choose one, some may choose the other, and we'll have only ourselves to blame for the ensuing mess. 2. Regardless of what collector experts say on this list, we know that some enterprises lock down their network configuration and spend a lot of time testing updates before rolling them out in their networks. Allowing a device to update on the fly using an unverified third-party configuration (even if it is from IANA) would be entirely unacceptable. P. On 18/09/12 14:33, Benoit Claise wrote: > Dear all, > > [catching up with emails after my vacation] > > I believe that "IE equivalence options template" (solution 2) sounds > like a nice idea but will not work in real live. > In a perfect world, all the EPs would export this "IE equivalence > options template" and the CP could ONLY rely on this mechanism. > We don't live in a perfect world, so not all EPs will export this > options template. This implies that the CPs need anyway a plan B: hard > coding the mapping, potentially received from IANA. > > This is the exact same example as RFC5610. It's not implemented by all > EPs (because we don't live in a perfect world), so the CPs must > sometimes hard code the information, and they can rely on RFC5610 only. > > Now, I would like to hear from the collectors people on the list: > - Would the "IE equivalence options template" be an important > improvements? Warning: assuming that only some EPs might implement > this feature! > - What about the fact that the collectors don't update the registry > frequently from IANA, as an argument for the solution (2) below? > Do you update from IANA? Yes/No? how frequently? > > Regards, Benoit. > >> Greetings, all, >> >> To close the discussion from Vancouver, we have two proposals under >> consideration for handling the transition of enterprise-specific IEs >> used for testing, research, or other pre-standardization purposes to >> IANA IEs: >> >> (1) The addition of an Enterprise-specific Reference column to the >> IANA registry, which would include PEN(s) and IE number(s) which have >> a description compatible with the IANA-registered IE; this is covered >> in the present revision of the IE-DOCTORS draft. The advantage of >> this is it provides a central registry; however, it presumes a model >> in which CPs are either frequently updated or periodically retrieve >> new registration information from IANA, and requires all users of >> ESIE codepoints replaced with an IANA codepoint to register that >> information with IANA. >> >> (2) The definition of an IE equivalence options template, which would >> define the equivalence of a set of IANA and enterprise-specific IEs. >> This would be sent by EPs which had updated an IE from an older >> enterprise-specific codepoint to a new IANA codepoint; this would be >> covered in a new draft which Paul Aitken has (I think) already >> started work on. This has the advantage that equivalence is not >> dependent on the IANA registry. Benoit noted that this required the >> EP to (i) send additional information on session startup and (ii) to >> be updated both to use the new IANA codepoint as well as to send this >> additional information: a CP would not know an old ESIE was >> equivalent to a newer IANA IE if the EP it was receiving data from >> had not been updated. >> >> As I see it, there are four possible ways forward: >> >> (a) Support both methods: Leave approach (1) in IE-DOCTORS, develop a >> draft describing approach (2). >> >> (b) Support only the IANA method: leave approach (1) in IE-DOCTORS. >> >> (c) Support only the Options method: remove approach (1) from >> IE-DOCTORS, develop a draft describing approach (2). >> >> (d) Defer the question and leave ESIE promotion an open issue: remove >> approach (1) from IE-DOCTORS with no present decision on a draft >> about approach (2). >> >> I suppose I'm in favor of option (a), since each approach has its own >> use cases, as long as we're clear in both IE-DOCTORS and the >> equivalence options draft about the applicability of each approach. >> >> Thoughts? >> >> Cheers, >> >> 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 From bclaise@cisco.com Tue Sep 18 07:23:15 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52EE21F8744 for ; Tue, 18 Sep 2012 07:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.793 X-Spam-Level: X-Spam-Status: No, score=-4.793 tagged_above=-999 required=5 tests=[AWL=-2.194, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uY1fVTX7IV2 for ; Tue, 18 Sep 2012 07:23:15 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id B197821F8743 for ; Tue, 18 Sep 2012 07:23:14 -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 q8IENDkt016069; Tue, 18 Sep 2012 16:23:13 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8IENCBC019747; Tue, 18 Sep 2012 16:23:12 +0200 (CEST) Message-ID: <505883D0.5060709@cisco.com> Date: Tue, 18 Sep 2012 16:23:12 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Aitken References: <50587825.9020305@cisco.com> <50587BB9.8010108@cisco.com> In-Reply-To: <50587BB9.8010108@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Promotion of Enterprise-Specific IEs to IANA IEs 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, 18 Sep 2012 14:23:16 -0000 Hi Paul, > Benoit, > > 0. Your argument that "we don't live in a perfect world" doesn't hold > in this case. Although the world may be imperfect, IPFIX implementers > MUST follow the defined standards. I can't simply put the wrong export > version, or use the wrong set ID, or the wrong field sizes, or send > NFv5 to your IPFIX collector, and simply claim "but we don't live in a > perfect world!". There is a big difference here between your examples above and what we discuss here. Your examples deal with the basis IPFIX protocol: RFC5101 or RFC5101bis. The "IE equivalence options template" would be an extension, exactly like RFC5610. RFC 5610 is Standards Track From RFC 5610: an Exporting Process exporting data using Templates containing enterprise-specific Information Elements SHOULD export an Information Element type record for each enterprise-specific Information Element it exports. So it's standards track, and it's a SHOULD. However, is it implemented? Vendors might implement the base IPFIX, but the customers/vendors/collectors take a decision for each extension. > > 1. If the equivalence options template is mandated as the IPFIX > mechanism, then EPs MUST implement it to be IPFIX compliant, perfect > world or not. Even if this new RFC contains a "MUST", this doesn't change anything to the logic. It's not because the IETF produces Standards Track RFCs with "MUST's" that they are implemented. > > 1a. Whereas, if we give a choice of two mechanisms, some may choose > one, some may choose the other, and we'll have only ourselves to blame > for the ensuing mess. No disagreement on this one. > > 2. Regardless of what collector experts say on this list, we know that > some enterprises lock down their network configuration and spend a lot > of time testing updates before rolling them out in their networks. > Allowing a device to update on the fly using an unverified third-party > configuration (even if it is from IANA) would be entirely unacceptable. I propose to let the collector people answer what (un)acceptable. Regards, Benoit. > > P. > > > On 18/09/12 14:33, Benoit Claise wrote: >> Dear all, >> >> [catching up with emails after my vacation] >> >> I believe that "IE equivalence options template" (solution 2) sounds >> like a nice idea but will not work in real live. >> In a perfect world, all the EPs would export this "IE equivalence >> options template" and the CP could ONLY rely on this mechanism. >> We don't live in a perfect world, so not all EPs will export this >> options template. This implies that the CPs need anyway a plan B: >> hard coding the mapping, potentially received from IANA. >> >> This is the exact same example as RFC5610. It's not implemented by >> all EPs (because we don't live in a perfect world), so the CPs must >> sometimes hard code the information, and they can rely on RFC5610 only. >> >> Now, I would like to hear from the collectors people on the list: >> - Would the "IE equivalence options template" be an important >> improvements? Warning: assuming that only some EPs might implement >> this feature! >> - What about the fact that the collectors don't update the registry >> frequently from IANA, as an argument for the solution (2) below? >> Do you update from IANA? Yes/No? how frequently? >> >> Regards, Benoit. >> >>> Greetings, all, >>> >>> To close the discussion from Vancouver, we have two proposals under >>> consideration for handling the transition of enterprise-specific IEs >>> used for testing, research, or other pre-standardization purposes to >>> IANA IEs: >>> >>> (1) The addition of an Enterprise-specific Reference column to the >>> IANA registry, which would include PEN(s) and IE number(s) which >>> have a description compatible with the IANA-registered IE; this is >>> covered in the present revision of the IE-DOCTORS draft. The >>> advantage of this is it provides a central registry; however, it >>> presumes a model in which CPs are either frequently updated or >>> periodically retrieve new registration information from IANA, and >>> requires all users of ESIE codepoints replaced with an IANA >>> codepoint to register that information with IANA. >>> >>> (2) The definition of an IE equivalence options template, which >>> would define the equivalence of a set of IANA and >>> enterprise-specific IEs. This would be sent by EPs which had updated >>> an IE from an older enterprise-specific codepoint to a new IANA >>> codepoint; this would be covered in a new draft which Paul Aitken >>> has (I think) already started work on. This has the advantage that >>> equivalence is not dependent on the IANA registry. Benoit noted that >>> this required the EP to (i) send additional information on session >>> startup and (ii) to be updated both to use the new IANA codepoint as >>> well as to send this additional information: a CP would not know an >>> old ESIE was equivalent to a newer IANA IE if the EP it was >>> receiving data from had not been updated. >>> >>> As I see it, there are four possible ways forward: >>> >>> (a) Support both methods: Leave approach (1) in IE-DOCTORS, develop >>> a draft describing approach (2). >>> >>> (b) Support only the IANA method: leave approach (1) in IE-DOCTORS. >>> >>> (c) Support only the Options method: remove approach (1) from >>> IE-DOCTORS, develop a draft describing approach (2). >>> >>> (d) Defer the question and leave ESIE promotion an open issue: >>> remove approach (1) from IE-DOCTORS with no present decision on a >>> draft about approach (2). >>> >>> I suppose I'm in favor of option (a), since each approach has its >>> own use cases, as long as we're clear in both IE-DOCTORS and the >>> equivalence options draft about the applicability of each approach. >>> >>> Thoughts? >>> >>> Cheers, >>> >>> 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 > > From bclaise@cisco.com Tue Sep 18 09:33:43 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9FB21F862A for ; Tue, 18 Sep 2012 09:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.45 X-Spam-Level: X-Spam-Status: No, score=-4.45 tagged_above=-999 required=5 tests=[AWL=-2.452, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3V27NYiJsxH for ; Tue, 18 Sep 2012 09:33:42 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id 92E0821F864A for ; Tue, 18 Sep 2012 09:33:42 -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 q8IGXfod029408 for ; Tue, 18 Sep 2012 18:33:41 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8IGXdHo004369 for ; Tue, 18 Sep 2012 18:33:39 +0200 (CEST) Message-ID: <5058A263.6010407@cisco.com> Date: Tue, 18 Sep 2012 18:33:39 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <4FFE3987.7050101@auckland.ac.nz> In-Reply-To: <4FFE3987.7050101@auckland.ac.nz> X-Forwarded-Message-Id: <4FFE3987.7050101@auckland.ac.nz> Content-Type: multipart/alternative; boundary="------------000106040204050309030009" Subject: [IPFIX] Closing the gap(s) in the IPFIX IANA registry: Re: [IANA #584408] General Request for Assignment (ipfix) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:33:43 -0000 This is a multi-part message in MIME format. --------------000106040204050309030009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Just one observation. With this new IE 300 assigned, we now closed one of the gap within the IPFIX IE registry [http://www.iana.org/assignments/ipfix/ipfix.xml]. That's good news! Historically, we started the IE assignments above 300 for the PSAMP related IEs... while both the IPFIX and PSAMP efforts were under way. Some more gaps to close with the range [1-127] and the registry will look like a clean(er) registry. http://tools.ietf.org/html/draft-yourtchenko-cisco-ies-04 should help in that matter. Regards, Benoit. -------- Original Message -------- Subject: Re: [IPFIX] [IANA #584408] General Request for Assignment (ipfix) Date: Thu, 12 Jul 2012 14:42:15 +1200 From: Nevil Brownlee To: iana-prot-param-comment@iana.org CC: ipfix Working Group Hi Amanda: This one is OK, please allocate it as IE 300. Cheers, Nevil On 11/07/12 8:26 PM, Amanda Baber via RT wrote: > Hi Nevil, > > Resending this one. > > thanks, > Amanda > > On Wed Jun 27 06:21:42 2012, amanda.baber wrote: >> Hi Nevil, >> >> Another request from Paul Aitken here. >> >> thanks, >> Amanda >> >> === >> >> Contact Name: >> Paul Aitken >> >> Contact Email: >> paitken@cisco.com >> >> Type of Assignment: >> IPFIX information elements. >> >> Registry: >> http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-information-elements >> >> Description: >> New field, observationDomainName, complementing the existing >> observationDomainId (#149). >> >> Additional Info: >> Name: observationDomainName >> Type: string >> Semantic: - >> Description: The name of an observation domain identified by an >> observationDomainId. >> References: See observationDomainId #149. > > -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --------------000106040204050309030009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Just one observation.
With this new IE 300 assigned, we now closed one of the gap within the IPFIX IE registry [http://www.iana.org/assignments/ipfix/ipfix.xml]. That's good news!
Historically,  we started the IE assignments above 300 for the PSAMP related IEs... while both the IPFIX and PSAMP efforts were under way.

Some more gaps to close with the range [1-127] and the registry will look like a clean(er) registry.
http://tools.ietf.org/html/draft-yourtchenko-cisco-ies-04 should help in that matter.

Regards, Benoit.
 
-------- Original Message --------
Subject: Re: [IPFIX] [IANA #584408] General Request for Assignment (ipfix)
Date: Thu, 12 Jul 2012 14:42:15 +1200
From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
To: iana-prot-param-comment@iana.org
CC: ipfix Working Group <ipfix@ietf.org> 


Hi Amanda:

This one is OK, please allocate it as IE 300.

Cheers, Nevil



On 11/07/12 8:26 PM, Amanda Baber via RT wrote:
> Hi Nevil,
>
> Resending this one.
>
> thanks,
> Amanda
>
> On Wed Jun 27 06:21:42 2012, amanda.baber wrote:
>> Hi Nevil,
>>
>> Another request from Paul Aitken here.
>>
>> thanks,
>> Amanda
>>
>> ===
>>
>> Contact Name:
>> Paul Aitken
>>
>> Contact Email:
>> paitken@cisco.com
>>
>> Type of Assignment:
>> IPFIX information elements.
>>
>> Registry:
>> http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-information-elements
>>
>> Description:
>> New field, observationDomainName, complementing the existing
>> observationDomainId (#149).
>>
>> Additional Info:
>> Name: observationDomainName
>> Type: string
>> Semantic: -
>> Description: The name of an observation domain identified by an
>> observationDomainId.
>> References: See observationDomainId #149.
>
>


-- 
---------------------------------------------------------------------
 Nevil Brownlee                    Computer Science Department | ITS
 Phone: +64 9 373 7599 x88941             The University of Auckland
 FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand


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



--------------000106040204050309030009-- From internet-drafts@ietf.org Wed Sep 19 03:33:16 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422FD21F8782; Wed, 19 Sep 2012 03:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bZegeyL27F8; Wed, 19 Sep 2012 03:33:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B614821F86AB; Wed, 19 Sep 2012 03:33:15 -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.34 Message-ID: <20120919103315.27064.47179.idtracker@ietfa.amsl.com> Date: Wed, 19 Sep 2012 03:33:15 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-ie-doctors-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 10:33:16 -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 : Guidelines for Authors and Reviewers of IPFIX Informatio= n Elements Author(s) : Brian Trammell Benoit Claise Filename : draft-ietf-ipfix-ie-doctors-05.txt Pages : 33 Date : 2012-09-19 Abstract: This document provides guidelines for the definition of IPFIX Information Elements for addition to the IANA IPFIX Information Element registry, in order to extend the applicability of the IPFIX protocol to new operations and management areas. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-ie-doctors There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-ie-doctors-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-ie-doctors-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From andrewf@plixer.com Thu Sep 20 13:14:45 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F36F21E804B for ; Thu, 20 Sep 2012 13:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaVgpOnXGjIF for ; Thu, 20 Sep 2012 13:14:44 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 2697B21E803F for ; Thu, 20 Sep 2012 13:14:43 -0700 (PDT) Received: from [10.100.1.132] ([10.100.1.132]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Sep 2012 16:14:42 -0400 Message-ID: <505B7931.5020404@plixer.com> Date: Thu, 20 Sep 2012 16:14:41 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/18.0 Thunderbird/18.0a1 MIME-Version: 1.0 To: Benoit Claise References: <50587825.9020305@cisco.com> In-Reply-To: <50587825.9020305@cisco.com> Content-Type: multipart/alternative; boundary="------------040203000608080709050100" X-OriginalArrivalTime: 20 Sep 2012 20:14:42.0534 (UTC) FILETIME=[91FFE060:01CD976C] Cc: ipfix@ietf.org Subject: Re: [IPFIX] Promotion of Enterprise-Specific IEs to IANA IEs 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, 20 Sep 2012 20:14:45 -0000 This is a multi-part message in MIME format. --------------040203000608080709050100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/18/2012 09:33 AM, Benoit Claise wrote: > Dear all, > > [catching up with emails after my vacation] > > I believe that "IE equivalence options template" (solution 2) sounds > like a nice idea but will not work in real live. > In a perfect world, all the EPs would export this "IE equivalence > options template" and the CP could ONLY rely on this mechanism. > We don't live in a perfect world, so not all EPs will export this > options template. This implies that the CPs need anyway a plan B: hard > coding the mapping, potentially received from IANA. The argument that this will not work in real life confuses me. The base protocol doesn't have a required way to share IE information (equivalence or other). Plan A (not plan B) is, therefore, hard coded IE information. Plan B is any other option. If an EP can give me useful information about an IE it is in my (and my customers') interest to use it for that EP even if not all EPs will send that information. Are you proposing that there should never be a plan B? > > This is the exact same example as RFC5610. It's not implemented by all > EPs (because we don't live in a perfect world), so the CPs must > sometimes hard code the information, and they can rely on RFC5610 only. Exactly! (I read the end of that sentence as "they can[not] rely on RFC5610 only". I assume that was just a typo :-) > > Now, I would like to hear from the collectors people on the list: > - Would the "IE equivalence options template" be an important > improvements? Warning: assuming that only some EPs might implement > this feature! I have seen no need for IE equivalence yet, but let's assume the need is on the horizon. In that case I think Brian left out option 3 in his original email. Extend 5610. At IETF 84 Chris Inacio presented an idea to export a URI to XML ( http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IET84_IPFIX&chapter=part_10). Brian further suggested it made sense to extend 5610 to do this. It seems like IE equivalence would fit within that work. This way we can have a plan A and plan B instead of an alphabet soup of plans. I do see a large and looming need for sharing vendor IE information. Especially for security and policy information as in Chris's example. > > - What about the fact that the collectors don't update the registry > frequently from IANA, as an argument for the solution (2) below? > Do you update from IANA? Yes/No? how frequently? Yes I update from IANA. I do this by importing the XML from the IANA site. Currently this is done statically prior to each new release, but I anticipate the ability to update installed collectors in the near future. > > Regards, Benoit. > >> Greetings, all, >> >> To close the discussion from Vancouver, we have two proposals under >> consideration for handling the transition of enterprise-specific IEs >> used for testing, research, or other pre-standardization purposes to >> IANA IEs: >> >> (1) The addition of an Enterprise-specific Reference column to the >> IANA registry, which would include PEN(s) and IE number(s) which have >> a description compatible with the IANA-registered IE; this is covered >> in the present revision of the IE-DOCTORS draft. The advantage of >> this is it provides a central registry; however, it presumes a model >> in which CPs are either frequently updated or periodically retrieve >> new registration information from IANA, and requires all users of >> ESIE codepoints replaced with an IANA codepoint to register that >> information with IANA. >> >> (2) The definition of an IE equivalence options template, which would >> define the equivalence of a set of IANA and enterprise-specific IEs. >> This would be sent by EPs which had updated an IE from an older >> enterprise-specific codepoint to a new IANA codepoint; this would be >> covered in a new draft which Paul Aitken has (I think) already >> started work on. This has the advantage that equivalence is not >> dependent on the IANA registry. Benoit noted that this required the >> EP to (i) send additional information on session startup and (ii) to >> be updated both to use the new IANA codepoint as well as to send this >> additional information: a CP would not know an old ESIE was >> equivalent to a newer IANA IE if the EP it was receiving data from >> had not been updated. >> >> As I see it, there are four possible ways forward: >> >> (a) Support both methods: Leave approach (1) in IE-DOCTORS, develop a >> draft describing approach (2). >> >> (b) Support only the IANA method: leave approach (1) in IE-DOCTORS. >> >> (c) Support only the Options method: remove approach (1) from >> IE-DOCTORS, develop a draft describing approach (2). >> >> (d) Defer the question and leave ESIE promotion an open issue: remove >> approach (1) from IE-DOCTORS with no present decision on a draft >> about approach (2). >> >> I suppose I'm in favor of option (a), since each approach has its own >> use cases, as long as we're clear in both IE-DOCTORS and the >> equivalence options draft about the applicability of each approach. I if you replace "IE equivalence options template" with "extend 5610" then I support (a) too. -Andrew --------------040203000608080709050100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/18/2012 09:33 AM, Benoit Claise wrote:
Dear all,

[catching up with emails after my vacation]

I believe that "IE equivalence options template" (solution 2) sounds like a nice idea but will not work in real live.
In a perfect world, all the EPs would export this "IE equivalence options template" and the CP could ONLY rely on this mechanism.
We don't live in a perfect world, so not all EPs will export this options template. This implies that the CPs need anyway a plan B: hard coding the mapping, potentially received from IANA.

The argument that this will not work in real life confuses me.  The base protocol doesn't have a required way to share IE information (equivalence or other).  Plan A (not plan B) is, therefore, hard coded IE information.  Plan B is any other option.  If an EP can give me useful information about an IE it is in my (and my customers') interest to use it for that EP even if not all EPs will send that information.  Are you proposing that there should never be a plan B?


This is the exact same example as RFC5610. It's not implemented by all EPs (because we don't live in a perfect world), so the CPs must sometimes hard code the information, and they can rely on RFC5610 only.

Exactly!  (I read the end of that sentence as "they can[not] rely on RFC5610 only".  I assume that was just a typo :-)


Now, I would like to hear from the collectors people on the list:
- Would the "IE equivalence options template" be an important improvements? Warning: assuming that only some EPs might implement this feature!

I have seen no need for IE equivalence yet, but let's assume the need is on the horizon.  In that case I think Brian left out option 3 in his original email.  Extend 5610.

At IETF 84 Chris Inacio presented an idea to export a URI to XML ( http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IET84_IPFIX&chapter=part_10).  Brian further suggested it made sense to extend 5610 to do this.  It seems like IE equivalence would fit within that work.  This way we can have a plan A and plan B instead of an alphabet soup of plans.

I do see a large and looming need for sharing vendor IE information.  Especially for security and policy information as in Chris's example.


- What about the fact that the collectors don't update the registry frequently from IANA, as an argument for the solution (2) below?
Do you update from IANA? Yes/No? how frequently?

Yes I update from IANA.  I do this by importing the XML from the IANA site.  Currently this is done statically prior to each new release, but I anticipate the ability to update installed collectors in the near future. 



Regards, Benoit.

Greetings, all,

To close the discussion from Vancouver, we have two proposals under consideration for handling the transition of enterprise-specific IEs used for testing, research, or other pre-standardization purposes to IANA IEs:

(1) The addition of an Enterprise-specific Reference column to the IANA registry, which would include PEN(s) and IE number(s) which have a description compatible with the IANA-registered IE; this is covered in the present revision of the IE-DOCTORS draft. The advantage of this is it provides a central registry; however, it presumes a model in which CPs are either frequently updated or periodically retrieve new registration information from IANA, and requires all users of ESIE codepoints replaced with an IANA codepoint to register that information with IANA.

(2) The definition of an IE equivalence options template, which would define the equivalence of a set of IANA and enterprise-specific IEs. This would be sent by EPs which had updated an IE from an older enterprise-specific codepoint to a new IANA codepoint; this would be covered in a new draft which Paul Aitken has (I think) already started work on. This has the advantage that equivalence is not dependent on the IANA registry. Benoit noted that this required the EP to (i) send additional information on session startup and (ii) to be updated both to use the new IANA codepoint as well as to send this additional information: a CP would not know an old ESIE was equivalent to a newer IANA IE if the EP it was receiving data from had not been updated.

As I see it, there are four possible ways forward:

(a) Support both methods: Leave approach (1) in IE-DOCTORS, develop a draft describing approach (2).

(b) Support only the IANA method: leave approach (1) in IE-DOCTORS.

(c) Support only the Options method: remove approach (1) from IE-DOCTORS, develop a draft describing approach (2).

(d) Defer the question and leave ESIE promotion an open issue: remove approach (1) from IE-DOCTORS with no present decision on a draft about approach (2).

I suppose I'm in favor of option (a), since each approach has its own use cases, as long as we're clear in both IE-DOCTORS and the equivalence options draft about the applicability of each approach.

I if you replace "IE equivalence options template" with "extend 5610" then I support (a) too.

-Andrew
--------------040203000608080709050100-- From internet-drafts@ietf.org Mon Sep 24 00:53:43 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1272621F857D; Mon, 24 Sep 2012 00:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.217 X-Spam-Level: X-Spam-Status: No, score=-102.217 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4efbzsaQ9PP; Mon, 24 Sep 2012 00:53:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8143321F84E6; Mon, 24 Sep 2012 00:53:42 -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.34 Message-ID: <20120924075342.26429.47912.idtracker@ietfa.amsl.com> Date: Mon, 24 Sep 2012 00:53:42 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-flow-selection-tech-12.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 07:53:43 -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-12.txt Pages : 36 Date : 2012-09-24 Abstract: Flow selection 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. Flow selection reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for Flow selection and presents Flow selection techniques. It provides an information model for configuring Flow selection techniques and discusses what information about 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-flow-selection-tech-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bclaise@cisco.com Mon Sep 24 02:43:55 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94AE421F8604 for ; Mon, 24 Sep 2012 02:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.576 X-Spam-Level: X-Spam-Status: No, score=-4.576 tagged_above=-999 required=5 tests=[AWL=-1.978, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2u00J+z30T-v for ; Mon, 24 Sep 2012 02:43:53 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id A2DDE21F8645 for ; Mon, 24 Sep 2012 02:43:51 -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 q8O9hmrZ012878; Mon, 24 Sep 2012 11:43:48 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8O9hlTr001749; Mon, 24 Sep 2012 11:43:47 +0200 (CEST) Message-ID: <50602B53.1060908@cisco.com> Date: Mon, 24 Sep 2012 11:43:47 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Andrew Feren References: <50587825.9020305@cisco.com> <505B7931.5020404@plixer.com> In-Reply-To: <505B7931.5020404@plixer.com> Content-Type: multipart/alternative; boundary="------------090704090905050308070904" Cc: ipfix@ietf.org Subject: Re: [IPFIX] Promotion of Enterprise-Specific IEs to IANA IEs 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, 24 Sep 2012 09:43:55 -0000 This is a multi-part message in MIME format. --------------090704090905050308070904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andrew, Thanks for your feedback. See in line. > On 09/18/2012 09:33 AM, Benoit Claise wrote: >> Dear all, >> >> [catching up with emails after my vacation] >> >> I believe that "IE equivalence options template" (solution 2) sounds >> like a nice idea but will not work in real live. >> In a perfect world, all the EPs would export this "IE equivalence >> options template" and the CP could ONLY rely on this mechanism. >> We don't live in a perfect world, so not all EPs will export this >> options template. This implies that the CPs need anyway a plan B: >> hard coding the mapping, potentially received from IANA. > > The argument that this will not work in real life confuses me. The > base protocol doesn't have a required way to share IE information > (equivalence or other). Plan A (not plan B) is, therefore, hard coded > IE information. Yes. > Plan B is any other option. If an EP can give me useful information > about an IE it is in my (and my customers') interest to use it for > that EP even if not all EPs will send that information. Are you > proposing that there should never be a plan B? No. I'm advocating that, if the plan B is the "IE equivalence options template", that will not work. > >> >> This is the exact same example as RFC5610. It's not implemented by >> all EPs (because we don't live in a perfect world), so the CPs must >> sometimes hard code the information, and they can rely on RFC5610 only. > > Exactly! (I read the end of that sentence as "they can[not] rely on > RFC5610 only". I assume that was just a typo :-) Yes, a typo. "And they can not] rely on RFC5610 only". Thanks for the correction. > >> >> Now, I would like to hear from the collectors people on the list: >> - Would the "IE equivalence options template" be an important >> improvement? Warning: assuming that only some EPs might implement >> this feature! > > I have seen no need for IE equivalence yet, but let's assume the need > is on the horizon. In that case I think Brian left out option 3 in > his original email. Extend 5610. > > At IETF 84 Chris Inacio presented an idea to export a URI to XML ( > http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IET84_IPFIX&chapter=part_10). This solution makes more way more sense, for the following reasons: 1. The URI would get the entire list of IEs in XML format, similar to IANA 2. All enterprise-specific IEs for the specific vendor would be included 3. The URI could include some more metadata, if needed. For example, the mapping between the mapping between entreprise-specific and IANA. 4. If a single router from a specific vendor sends that URI, the collector receives all the mappings. The point 4 is my primary argument against "IE equivalence options template". - "IE equivalence options template" must be sent from _all _the exporters (because different exporters support different sets of IEs) for the collector to rely on the mechanism. And we know there are different platforms, with different software versions, even from a single vendor. - Sending the URI only needs to be sent from a single exporter (from that vendor) and the collector gets all the required information. Note that the collector could even be hard coded the URI in the collector, as this should not change. Regards, Benoit (as a contributor) > Brian further suggested it made sense to extend 5610 to do this. It > seems like IE equivalence would fit within that work. This way we can > have a plan A and plan B instead of an alphabet soup of plans. > > I do see a large and looming need for sharing vendor IE information. > Especially for security and policy information as in Chris's example. > >> >> - What about the fact that the collectors don't update the registry >> frequently from IANA, as an argument for the solution (2) below? >> Do you update from IANA? Yes/No? how frequently? > > Yes I update from IANA. I do this by importing the XML from the IANA > site. Currently this is done statically prior to each new release, > but I anticipate the ability to update installed collectors in the > near future. > > >> >> Regards, Benoit. >> >>> Greetings, all, >>> >>> To close the discussion from Vancouver, we have two proposals under >>> consideration for handling the transition of enterprise-specific IEs >>> used for testing, research, or other pre-standardization purposes to >>> IANA IEs: >>> >>> (1) The addition of an Enterprise-specific Reference column to the >>> IANA registry, which would include PEN(s) and IE number(s) which >>> have a description compatible with the IANA-registered IE; this is >>> covered in the present revision of the IE-DOCTORS draft. The >>> advantage of this is it provides a central registry; however, it >>> presumes a model in which CPs are either frequently updated or >>> periodically retrieve new registration information from IANA, and >>> requires all users of ESIE codepoints replaced with an IANA >>> codepoint to register that information with IANA. >>> >>> (2) The definition of an IE equivalence options template, which >>> would define the equivalence of a set of IANA and >>> enterprise-specific IEs. This would be sent by EPs which had updated >>> an IE from an older enterprise-specific codepoint to a new IANA >>> codepoint; this would be covered in a new draft which Paul Aitken >>> has (I think) already started work on. This has the advantage that >>> equivalence is not dependent on the IANA registry. Benoit noted that >>> this required the EP to (i) send additional information on session >>> startup and (ii) to be updated both to use the new IANA codepoint as >>> well as to send this additional information: a CP would not know an >>> old ESIE was equivalent to a newer IANA IE if the EP it was >>> receiving data from had not been updated. >>> >>> As I see it, there are four possible ways forward: >>> >>> (a) Support both methods: Leave approach (1) in IE-DOCTORS, develop >>> a draft describing approach (2). >>> >>> (b) Support only the IANA method: leave approach (1) in IE-DOCTORS. >>> >>> (c) Support only the Options method: remove approach (1) from >>> IE-DOCTORS, develop a draft describing approach (2). >>> >>> (d) Defer the question and leave ESIE promotion an open issue: >>> remove approach (1) from IE-DOCTORS with no present decision on a >>> draft about approach (2). >>> >>> I suppose I'm in favor of option (a), since each approach has its >>> own use cases, as long as we're clear in both IE-DOCTORS and the >>> equivalence options draft about the applicability of each approach. > > I if you replace "IE equivalence options template" with "extend 5610" > then I support (a) too. > > -Andrew --------------090704090905050308070904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Andrew,

Thanks for your feedback.
See in line.
On 09/18/2012 09:33 AM, Benoit Claise wrote:
Dear all,

[catching up with emails after my vacation]

I believe that "IE equivalence options template" (solution 2) sounds like a nice idea but will not work in real live.
In a perfect world, all the EPs would export this "IE equivalence options template" and the CP could ONLY rely on this mechanism.
We don't live in a perfect world, so not all EPs will export this options template. This implies that the CPs need anyway a plan B: hard coding the mapping, potentially received from IANA.

The argument that this will not work in real life confuses me.  The base protocol doesn't have a required way to share IE information (equivalence or other).  Plan A (not plan B) is, therefore, hard coded IE information. 
Yes.
Plan B is any other option.  If an EP can give me useful information about an IE it is in my (and my customers') interest to use it for that EP even if not all EPs will send that information.  Are you proposing that there should never be a plan B?
No. I'm advocating that, if the plan B is the "IE equivalence options template", that will not work.


This is the exact same example as RFC5610. It's not implemented by all EPs (because we don't live in a perfect world), so the CPs must sometimes hard code the information, and they can rely on RFC5610 only.

Exactly!  (I read the end of that sentence as "they can[not] rely on RFC5610 only".  I assume that was just a typo :-)
Yes, a typo. "And they can not] rely on RFC5610 only". Thanks for the correction.



Now, I would like to hear from the collectors people on the list:
- Would the "IE equivalence options template" be an important improvement? Warning: assuming that only some EPs might implement this feature!

I have seen no need for IE equivalence yet, but let's assume the need is on the horizon.  In that case I think Brian left out option 3 in his original email.  Extend 5610.

At IETF 84 Chris Inacio presented an idea to export a URI to XML ( http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IET84_IPFIX&chapter=part_10). 
This solution makes more way more sense, for the following reasons:
1. The URI would get the entire list of IEs in XML format, similar to IANA
2. All enterprise-specific IEs for the specific vendor would be included
3. The URI could include some more metadata, if needed.
     For example, the mapping between the mapping between entreprise-specific and IANA.
4. If a single router from a specific vendor sends that URI, the collector receives all the mappings.

The point 4 is my primary argument against "IE equivalence options template".
- "IE equivalence options template" must be sent from all the exporters (because different exporters support different sets of IEs) for the collector to rely on the mechanism. And we know there are different platforms, with different software versions, even from a single vendor.
- Sending the URI only needs to be sent from a single exporter (from that vendor) and the collector gets all the required information. Note that the collector could even be hard coded the URI in the collector, as this should not change.

Regards, Benoit (as a contributor)

Brian further suggested it made sense to extend 5610 to do this.  It seems like IE equivalence would fit within that work.  This way we can have a plan A and plan B instead of an alphabet soup of plans.

I do see a large and looming need for sharing vendor IE information.  Especially for security and policy information as in Chris's example.


- What about the fact that the collectors don't update the registry frequently from IANA, as an argument for the solution (2) below?
Do you update from IANA? Yes/No? how frequently?

Yes I update from IANA.  I do this by importing the XML from the IANA site.  Currently this is done statically prior to each new release, but I anticipate the ability to update installed collectors in the near future. 



Regards, Benoit.

Greetings, all,

To close the discussion from Vancouver, we have two proposals under consideration for handling the transition of enterprise-specific IEs used for testing, research, or other pre-standardization purposes to IANA IEs:

(1) The addition of an Enterprise-specific Reference column to the IANA registry, which would include PEN(s) and IE number(s) which have a description compatible with the IANA-registered IE; this is covered in the present revision of the IE-DOCTORS draft. The advantage of this is it provides a central registry; however, it presumes a model in which CPs are either frequently updated or periodically retrieve new registration information from IANA, and requires all users of ESIE codepoints replaced with an IANA codepoint to register that information with IANA.

(2) The definition of an IE equivalence options template, which would define the equivalence of a set of IANA and enterprise-specific IEs. This would be sent by EPs which had updated an IE from an older enterprise-specific codepoint to a new IANA codepoint; this would be covered in a new draft which Paul Aitken has (I think) already started work on. This has the advantage that equivalence is not dependent on the IANA registry. Benoit noted that this required the EP to (i) send additional information on session startup and (ii) to be updated both to use the new IANA codepoint as well as to send this additional information: a CP would not know an old ESIE was equivalent to a newer IANA IE if the EP it was receiving data from had not been updated.

As I see it, there are four possible ways forward:

(a) Support both methods: Leave approach (1) in IE-DOCTORS, develop a draft describing approach (2).

(b) Support only the IANA method: leave approach (1) in IE-DOCTORS.

(c) Support only the Options method: remove approach (1) from IE-DOCTORS, develop a draft describing approach (2).

(d) Defer the question and leave ESIE promotion an open issue: remove approach (1) from IE-DOCTORS with no present decision on a draft about approach (2).

I suppose I'm in favor of option (a), since each approach has its own use cases, as long as we're clear in both IE-DOCTORS and the equivalence options draft about the applicability of each approach.

I if you replace "IE equivalence options template" with "extend 5610" then I support (a) too.

-Andrew

--------------090704090905050308070904-- From paitken@cisco.com Mon Sep 24 05:16:06 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E37021F866E for ; Mon, 24 Sep 2012 05:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i15l4ua4Zm1C for ; Mon, 24 Sep 2012 05:16:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id DC29321F85EF for ; Mon, 24 Sep 2012 05:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4808; q=dns/txt; s=iport; t=1348488965; x=1349698565; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=jR6LQVMYVgtnhwqoRZ6qiT/2/+wvseQVZuv8DwMoltU=; b=hMURXlpzpI5dBkdO46UYaQ3LppAGrwwYxcrOVkZniFAqt6B6nZBiDZ23 z607BzHJSzYgyWa64TnsjgD4ZZNhpeqlGgataeAm6w8IUpeWnbYGWZdMx roxmOtl1XmeA1QH5zJLoDpBftHCPa8U9RGDCDByLMK0uYbmnfYkYioC8q o=; X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208,217";a="144277443" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 24 Sep 2012 12:15:58 +0000 Received: from [10.61.110.74] (dhcp-10-61-110-74.cisco.com [10.61.110.74]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8OCFwYp027753; Mon, 24 Sep 2012 12:15:58 GMT Message-ID: <50604F01.8030104@cisco.com> Date: Mon, 24 Sep 2012 13:16:01 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Benoit Claise References: <50587825.9020305@cisco.com> <505B7931.5020404@plixer.com> <50602B53.1060908@cisco.com> In-Reply-To: <50602B53.1060908@cisco.com> Content-Type: multipart/alternative; boundary="------------080205010802080801070408" Cc: ipfix@ietf.org Subject: Re: [IPFIX] Promotion of Enterprise-Specific IEs to IANA IEs 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, 24 Sep 2012 12:16:06 -0000 This is a multi-part message in MIME format. --------------080205010802080801070408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Benoit, > 4. If a single router from a specific vendor sends that URI, the > collector receives all the mappings. > > The point 4 is my primary argument against "IE equivalence options > template". > - "IE equivalence options template" must be sent from _all _the > exporters (because different exporters support different sets of IEs) > for the collector to rely on the mechanism. And we know there are > different platforms, with different software versions, even from a > single vendor. That's not quite correct. If each box must send it's own unique equivalence option, then each box would require a unique URI for the collector to obtain the correct mapping for that device alone. Since you clearly see that a single URI is sufficient for all devices from a vendor, then a single option template from a single device is also sufficient for all devices from a vendor, since the option would contain the exact same information as the URI. > - Sending the URI only needs to be sent from a single exporter (from > that vendor) and the collector gets all the required information. Similarly for the equivalence option. Consider the mechanism versus the content: there are two mechanisms (option versus URI), while the underlying content is the same. > Note that the collector could even be hard coded the URI in the > collector, as this should not change. Consider how the URI mechanism would handle versioning. ie, an enterprise-specific IE changes from A to B to C. If the latest URI says A is B and B is C (as it must), then older EPs from before the B to C change, which truly do export B, may not be interpreted correctly. Whereas with the equivalence option mechanism, an older device could export the "A to B" equivalence without the "B to C" equivalence. P. --------------080205010802080801070408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Benoit,

4. If a single router from a specific vendor sends that URI, the collector receives all the mappings.

The point 4 is my primary argument against "IE equivalence options template".
- "IE equivalence options template" must be sent from all the exporters (because different exporters support different sets of IEs) for the collector to rely on the mechanism. And we know there are different platforms, with different software versions, even from a single vendor.

That's not quite correct.

If each box must send it's own unique equivalence option, then each box would require a unique URI for the collector to obtain the correct mapping for that device alone.

Since you clearly see that a single URI is sufficient for all devices from a vendor, then a single option template from a single device is also sufficient for all devices from a vendor, since the option would contain the exact same information as the URI.


- Sending the URI only needs to be sent from a single exporter (from that vendor) and the collector gets all the required information.

Similarly for the equivalence option.

Consider the mechanism versus the content: there are two mechanisms (option versus URI), while the underlying content is the same.


Note that the collector could even be hard coded the URI in the collector, as this should not change.

Consider how the URI mechanism would handle versioning. ie, an enterprise-specific IE changes from A to B to C. If the latest URI says A is B and B is C (as it must), then older EPs from before the B to C change, which truly do export B, may not be interpreted correctly.

Whereas with the equivalence option mechanism, an older device could export the "A to B" equivalence without the "B to C" equivalence.

P.

--------------080205010802080801070408-- From andrewf@plixer.com Mon Sep 24 06:04:06 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A5721F869F for ; Mon, 24 Sep 2012 06:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGTUXa7fWfrU for ; Mon, 24 Sep 2012 06:04:05 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 541A621F869E for ; Mon, 24 Sep 2012 06:04:05 -0700 (PDT) Received: from [10.100.1.132] ([10.100.1.132]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Sep 2012 09:04:00 -0400 Message-ID: <50605A40.90906@plixer.com> Date: Mon, 24 Sep 2012 09:04:00 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/18.0 Thunderbird/18.0a1 MIME-Version: 1.0 To: Paul Aitken References: <50587825.9020305@cisco.com> <505B7931.5020404@plixer.com> <50602B53.1060908@cisco.com> <50604F01.8030104@cisco.com> In-Reply-To: <50604F01.8030104@cisco.com> Content-Type: multipart/alternative; boundary="------------030805070806080704050505" X-OriginalArrivalTime: 24 Sep 2012 13:04:00.0364 (UTC) FILETIME=[1084AAC0:01CD9A55] Cc: ipfix@ietf.org Subject: Re: [IPFIX] Promotion of Enterprise-Specific IEs to IANA IEs 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, 24 Sep 2012 13:04:06 -0000 This is a multi-part message in MIME format. --------------030805070806080704050505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Paul, On 09/24/2012 08:16 AM, Paul Aitken wrote: > Benoit, > >> 4. If a single router from a specific vendor sends that URI, the >> collector receives all the mappings. >> >> The point 4 is my primary argument against "IE equivalence options >> template". >> - "IE equivalence options template" must be sent from _all _the >> exporters (because different exporters support different sets of IEs) >> for the collector to rely on the mechanism. And we know there are >> different platforms, with different software versions, even from a >> single vendor. > > That's not quite correct. > > If each box must send it's own unique equivalence option, then each > box would require a unique URI for the collector to obtain the correct > mapping for that device alone. > > Since you clearly see that a single URI is sufficient for all devices > from a vendor, then a single option template from a single device is > also sufficient for all devices from a vendor, since the option would > contain the exact same information as the URI. Benoit can correct me if I am not understanding him correctly, but I think he is envisioning something a bit broader than just the mapping needed for a single device. I think what Benoit has in mind is a URI to a vendor maintained IANA like registry. This registry would have info about all of that vendors information elements. >> - Sending the URI only needs to be sent from a single exporter (from >> that vendor) and the collector gets all the required information. > > Similarly for the equivalence option. > > Consider the mechanism versus the content: there are two mechanisms > (option versus URI), while the underlying content is the same. > > >> Note that the collector could even be hard coded the URI in the >> collector, as this should not change. > > Consider how the URI mechanism would handle versioning. ie, an > enterprise-specific IE changes from A to B to C. If the latest URI > says A is B and B is C (as it must), then older EPs from before the B > to C change, which truly do export B, may not be interpreted correctly. > > Whereas with the equivalence option mechanism, an older device could > export the "A to B" equivalence without the "B to C" equivalence. First I thought the idea was to declare the "equivalence" of a vendor IE to some now standard IE. I suppose a large vendor might have to IEs (say A and C) that are both equivalent to some new standard IE B. Maybe A and C each only ever exported a subset of the values now standard for B, whatever. If I can say that A is equivalent to B and I can say B is equivalent to C then I better also be able to say that A is equivalent to C.... Ahhh. OK as I type this out I think I see where you are going. Let's be more specific with my above example A exports values (1 and 2) C exports values (3 and 4) B exports values (1, 2, 3, 4) saying A is equivalent to C is a bit bizarre. Maybe equivalence is the wrong word. Anyone have a better suggestion? I think this is a pretty compelling argument for each vendor maintaining a single registry. I'm not really interested in versioning beyond getting the latest (most complete definition). Maintaining a per exporter registry seems like a lot of work with not a lot of upside. I'll give this some more thought though. -Andrew --------------030805070806080704050505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Paul,

On 09/24/2012 08:16 AM, Paul Aitken wrote:
Benoit,

4. If a single router from a specific vendor sends that URI, the collector receives all the mappings.

The point 4 is my primary argument against "IE equivalence options template".
- "IE equivalence options template" must be sent from all the exporters (because different exporters support different sets of IEs) for the collector to rely on the mechanism. And we know there are different platforms, with different software versions, even from a single vendor.

That's not quite correct.

If each box must send it's own unique equivalence option, then each box would require a unique URI for the collector to obtain the correct mapping for that device alone.

Since you clearly see that a single URI is sufficient for all devices from a vendor, then a single option template from a single device is also sufficient for all devices from a vendor, since the option would contain the exact same information as the URI.
Benoit can correct me if I am not understanding him correctly, but I think he is envisioning something a bit broader than just the mapping needed for a single device.  I think what Benoit has in mind is a URI to a vendor maintained IANA like registry.  This registry would have info about all of that vendors information elements.

- Sending the URI only needs to be sent from a single exporter (from that vendor) and the collector gets all the required information.

Similarly for the equivalence option.

Consider the mechanism versus the content: there are two mechanisms (option versus URI), while the underlying content is the same.


Note that the collector could even be hard coded the URI in the collector, as this should not change.

Consider how the URI mechanism would handle versioning. ie, an enterprise-specific IE changes from A to B to C. If the latest URI says A is B and B is C (as it must), then older EPs from before the B to C change, which truly do export B, may not be interpreted correctly.

Whereas with the equivalence option mechanism, an older device could export the "A to B" equivalence without the "B to C" equivalence.

First I thought the idea was to declare the "equivalence" of a vendor IE to some now standard IE.  I suppose a large vendor might have to IEs (say A and C) that are both equivalent to some new standard IE B.  Maybe A and C each only ever exported a subset of the values now standard for B, whatever.  If I can say that A is equivalent to B and I can say B is equivalent to C then I better also be able to say that A is equivalent to C.... Ahhh.

OK as I type this out I think I see where you are going.  Let's be more specific with my above example

A exports values (1 and 2)
C exports values (3 and 4)
B exports values (1, 2, 3, 4)

saying A is equivalent to C is a bit bizarre.  Maybe equivalence is the wrong word.  Anyone have a better suggestion?

I think this is a pretty compelling argument for each vendor maintaining a single registry.  I'm not really interested in versioning beyond getting the latest (most complete definition).  Maintaining a per exporter registry seems like a lot of work with not a lot of upside.

I'll give this some more thought though.

-Andrew
--------------030805070806080704050505-- From salvatore.dantonio@uniparthenope.it Mon Sep 24 08:47:13 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73B021F87C1 for ; Mon, 24 Sep 2012 08:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wy8UUjZ1PjMU for ; Mon, 24 Sep 2012 08:47:13 -0700 (PDT) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by ietfa.amsl.com (Postfix) with ESMTP id BCD7A21F87BC for ; Mon, 24 Sep 2012 08:47:11 -0700 (PDT) Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id 34BFE13C5C; Mon, 24 Sep 2012 15:47:09 +0000 (UTC) Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 1d8a_1949da4c_065f_11e2_9101_001372515a5c; Mon, 24 Sep 2012 17:47:08 +0200 Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id 811BDC42EE; Mon, 24 Sep 2012 17:47:06 +0200 (CEST) Received: by spamk.uniparthenope.it (Postfix, from userid 500) id 7C66D19AC91; Mon, 24 Sep 2012 17:47:06 +0200 (CEST) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by spamk.uniparthenope.it (Postfix) with ESMTP id A97F9C42EE; Mon, 24 Sep 2012 17:46:39 +0200 (CEST) Received: from saldantoPC (host146-36-static.254-95-b.business.telecomitalia.it [95.254.36.146]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id 755CA15C4D; Mon, 24 Sep 2012 17:46:36 +0200 (CEST) From: "Salvatore D'Antonio" To: "'Benoit Claise'" , , References: <4FC74398.50805@cisco.com> <4FC89B99.40107@cisco.com> In-Reply-To: <4FC89B99.40107@cisco.com> Date: Mon, 24 Sep 2012 17:46:35 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0/4uKSjQqQGbWhTn2Mo/IlIfvWlBaggegQ Content-Language: it Message-ID: <004901cd9a6b$c82e7b40$588b71c0$@dantonio@uniparthenope.it> Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01CD9A7C.8BB74B40" X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20120924 #7915620, check: 20120924 clean Cc: ipfix-chairs@tools.ietf.org Subject: [IPFIX] R: New AD review of draft-ietf-ipfix-flow-selection-tech-10.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 15:47:13 -0000 Messaggio multipart in formato MIME. ------=_NextPart_000_004A_01CD9A7C.8BB74B40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Benoit, =20 The new version of the Internet Draft on Flow Selection Techniques has = been published. =20 Answers to your comments inline. =20 Best regards, =20 Salvatore =20 Da: Benoit Claise [mailto:bclaise@cisco.com]=20 Inviato: venerd=EC 1 giugno 2012 12:38 A: ipfix@ietf.org; draft-ietf-ipfix-flow-selection-tech@tools.ietf.org Cc: ipfix-chairs@tools.ietf.org Oggetto: New AD review of draft-ietf-ipfix-flow-selection-tech-10.txt =20 Dear authors, I'm performing the (new) AD review of draft-ietf-ipfix-flow-selection-tech-10.txt Lucky you, an extra pair of eyes specifically looking at your draft=20 If some points have been discussed already on the mailing list, let me = know. I have to admit that I have not been following the latest iterations of = this draft. IMHO, this document needs some more work...=20 I don't think that this document is really in line with the other Intermediate Processes documents:=20 http://tools.ietf.org/html/rfc6235 http://tools.ietf.org/html/draft-ietf-ipfix-a9n-03 Note that I might have some more comments once all the points in this = email are addressed, as there are many ;-) However, I'm available for a conf. call to clarify my points if you want = to=20 See in-line.=20 Internet Engineering Task Force S. D'Antonio = Internet-Draft University of Napoli = Intended status: Standards Track "Parthenope" = Expires: October 25, 2012 T. Zseby = CAIDA/FhG FOKUS = C. Henke = Tektronix Communication Berlin = L. Peluso = University of Napoli = April 23, 2012 = Flow Selection Techniques=20 draft-ietf-ipfix-flow-selection-tech-11.txt=20 Abstract=20 Flow selection is the process of selecting a subset of flows from all = observed flows. The Flow Selection Process may be located at an=20 observation point, or on an IPFIX Mediator. Flow selection reduces=20 the effort of post-processing flow data and transferring Flow=20 Records. This document describes motivations for flow selection and=20 presents flow selection techniques. It provides an information model = for configuring flow selection techniques and discusses what=20 information about a flow selection process should be exported.=20 - Be consistent with terms capitalization. Flow, Observation Point, for example, are not capitalized in the abstract =20 Done. The following paragraph is good and consistent with the other IPFIX documents, but make sure you include all the terms that you need. This document is consistent with the terminology introduced in [RFC5101], [RFC5470], [RFC5475] and [RFC3917]. As in [RFC5101] and [RFC5476], the first letter of each IPFIX-specific and PSAMP-specific term is capitalized along with the flow selection specific terms defined here. Requirements Language=20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20 document are to be interpreted as described in RFC 2119 [RFC2119].=20 Status of this Memo=20 This Internet-Draft is submitted in full conformance with the=20 provisions of BCP 78 and BCP 79.=20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF). Note that other groups may also distribute=20 working documents as Internet-Drafts. The list of current Internet-=20 Drafts is at http://datatracker.ietf.org/drafts/current/.=20 Internet-Drafts are draft documents valid for a maximum of six months = and may be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference=20 material or to cite them other than as "work in progress."=20 This Internet-Draft will expire on October 25, 2012.=20 D'Antonio, et al. Expires October 25, 2012 [Page 1] = =20 Internet-Draft Flow Selection Techniques April 2012 = Copyright Notice=20 Copyright (c) 2012 IETF Trust and the persons identified as the=20 document authors. All rights reserved.=20 This document is subject to BCP 78 and the IETF Trust's Legal=20 Provisions Relating to IETF Documents=20 (http://trustee.ietf.org/license-info) in effect on the date of=20 publication of this document. Please review these documents=20 carefully, as they describe your rights and restrictions with respect = to this document. Code Components extracted from this document must=20 include Simplified BSD License text as described in Section 4.e of=20 the Trust Legal Provisions and are provided without warranty as=20 described in the Simplified BSD License.=20 This document may contain material from IETF Documents or IETF=20 Contributions published or made publicly available before November=20 10, 2008. The person(s) controlling the copyright in some of this=20 material may not have granted the IETF Trust the right to allow=20 modifications of such material outside the IETF Standards Process.=20 Without obtaining an adequate license from the person(s) controlling=20 the copyright in such materials, this document may not be modified=20 outside the IETF Standards Process, and derivative works of it may=20 not be created outside the IETF Standards Process, except to format=20 it for publication as an RFC or to translate it into languages other=20 than English.=20 D'Antonio, et al. Expires October 25, 2012 [Page 2] = =20 Internet-Draft Flow Selection Techniques April 2012 = Table of Contents=20 1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 = 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 = 3. Difference between Flow Selection and Packet Selection . . . . 7 = 4. Flow selection as a Function in the IPFIX Architecture . . . . 8 = 4.1. Flow selection during the Metering Process . . . . . . . . 10 = 4.2. Flow selection during the Exporting Process . . . . . . . 10 = 4.3. Flow selection as a function of the IPFIX Mediator . . . . 10 = 5. Flow Selection Techniques . . . . . . . . . . . . . . . . . . 11 = 5.1. Flow Filtering . . . . . . . . . . . . . . . . . . . . . . 11 = 5.1.1. Property Match Filtering . . . . . . . . . . . . . . . 11 = 5.1.2. Hash-based Flow Filtering . . . . . . . . . . . . . . 12 = 5.2. Flow Sampling . . . . . . . . . . . . . . . . . . . . . . 12 = 5.2.1. Systematic sampling . . . . . . . . . . . . . . . . . 12 = 5.2.2. Random Sampling . . . . . . . . . . . . . . . . . . . 13 = 5.3. Flow-state Dependent Flow Selection . . . . . . . . . . . 13 = 5.4. Flow-state Dependent Packet Selection . . . . . . . . . . 14 = 6. Configuration of Flow Selection Techniques . . . . . . . . . . 14 = 6.1. Flow Selection Parameters . . . . . . . . . . . . . . . . 16 = 6.2. Description of Flow-state Dependent Packet Selection . . . 18 = 7. Information Model for Flow Selection Configuration and=20 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 18 = 7.1. flowSelectorAlgorithm . . . . . . . . . . . . . . . . . . 20 = 7.2. flowSelectedOctetDeltaCount . . . . . . . . . . . . . . . 21 = 7.3. flowSelectedPacketDeltaCount . . . . . . . . . . . . . . . 21 = 7.4. flowSelectedFlowDeltaCount . . . . . . . . . . . . . . . . 21 = 7.5. selectorIDTotalFlowsObserved . . . . . . . . . . . . . . . 22 = 7.6. selectorIDTotalFlowsSelected . . . . . . . . . . . . . . . 22 = 7.7. samplingFlowInterval . . . . . . . . . . . . . . . . . . . 22 = 7.8. samplingFlowSpace . . . . . . . . . . . . . . . . . . . . 23 = 7.9. flowSamplingTimeInterval . . . . . . . . . . . . . . . . . 23 = 7.10. flowSamplingTimeSpace . . . . . . . . . . . . . . . . . . 24 = 7.11. hashFlowDomain . . . . . . . . . . . . . . . . . . . . . . 24 = 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 = 8.1. Registration of Information Elements . . . . . . . . . . . 24 = 8.2. Registration of Object Identifier . . . . . . . . . . . . 32 = 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 = 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 = 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 = 11.1. Normative References . . . . . . . . . . . . . . . . . . . 34 = 11.2. Informative References . . . . . . . . . . . . . . . . . . 34 = Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 = Don't you have to include the non-normative XML in the appendix, as it = was done for RFC5102, RFC5103?=20 D'Antonio, et al. Expires October 25, 2012 [Page 3] = =20 Internet-Draft Flow Selection Techniques April 2012 = 1. Scope=20 This document describes flow selection techniques for network traffic = measurements. A flow is defined as a set of packets with common=20 properties as described in [RFC5101]. Flow selection can be done to=20 limit the resource demands for capturing, storing, exporting and=20 post-processing of Flow Records. It also can be used to select a=20 particular set of flows that are of interest to a specific=20 application. This document provides a categorization of flow=20 selection techniques and describes configuration and reporting=20 parameters for them. In order to be compliant with this document, at = least one of the flow selection schemes MUST be implemented. That=20 means that the configuration parameters as well as the reporting=20 Information Elements for this particular scheme MUST be supported.=20 Last sentence could be fine, but express that the way to configure the Intermediate Flow Selection Process is out of scope of this document. =20 Ok, the sentence has been removed. This document also addresses configuration and reporting parameters=20 for flow-state dependent packet selection as described in [RFC5475],=20 although this technique is categorized as packet selection. The=20 reason is that flow-state dependent packet selection techniques often = aim at the reduction of resources for flow capturing and flow=20 processing. Furthermore, they were only briefly discussed in=20 Not sure what "they" refers to =20 Fixed. [RFC5475]. Therefore we included configuration and reporting=20 considerations for such techniques in this document.=20 please remove "we", "us", "our" from the draft. Done. 2. Terminology=20 This document is consistent with the terminology introduced in=20 [RFC5101], [RFC5470], [RFC5475] and [RFC3917]. As in [RFC5101] and=20 [RFC5476], the first letter of each IPFIX-specific and PSAMP-specific = term is capitalized along with the flow selection specific terms=20 defined here.=20 * Packet Classification=20 Packet Classification is a process by which packets are mapped to=20 specific Flow Records based on packet properties or external=20 properties (e.g. interface). The properties (e.g. header=20 information, packet content, AS number) make up the Flow Key. In=20 case a Flow Record for a specific Flow Key already exists the Flow = Record is updated, otherwise a new Flow Record is created.=20 How is this different that the Metering Process (RFC5101)? Packet Classification is a function of the Metering Process. =20 Metering Process =20 The Metering Process generates Flow Records. Inputs to the process are packet headers and characteristics observed at an Observation Point, and packet treatment at the Observation Point (for example, the selected output interface). =20 The Metering Process consists of a set of functions that includes packet header capturing, timestamping, sampling, classifying, and maintaining Flow Records. =20 The maintenance of Flow Records may include creating new records, updating existing ones, computing Flow statistics, deriving further Flow properties, detecting Flow expiration, passing Flow Records to the Exporting Process, and deleting Flow Records. What is the connection with the Metering Process? Figure 1 seems to suggest that Packet Classification is a subset of the Metering Process... Your interpretation is correct. * Packet Aggregation Process=20 In the IPFIX Metering Process the Packet Aggregation Process=20 aggregates packet data into flow data and forms the Flow Records.=20 How is this different from the Metering Process? The definition of Packet Aggregation Process has been removed. =20 After the aggregation step only the aggregated flow information is = available. Information about individual packets is lost.=20 D'Antonio, et al. Expires October 25, 2012 [Page 4] = =20 Internet-Draft Flow Selection Techniques April 2012 = * Flow Selection Process=20 A Flow Selection Process takes Flow Records as its input and=20 selects a subset of this set as its output. A Flow Selection=20 Process MAY run in several places within the IPFIX architecture.=20 A Flow Selection Process MAY be part of an IPFIX Metering Process, = Exporting Process or as an Intermediate Selection Process as=20 defined for the IPFIX Mediator [RFC6183].=20 If you look at the RFC6235, you will see=20 Intermediate Anonymization Process: An intermediate process that takes Data Records and transforms them into Anonymized Data Records. =20 To be perfect correct, the correct way is like it's done in http://tools.ietf.org/html/draft-ietf-ipfix-a9n-03 Intermediate Aggregation Process: an Intermediate Process as in [RFC6183 ] that aggregates records, based upon a set of Flow Keys or functions applied to fields from the record. What should be done here is=20 Intermediate Flow Selection Process: an Intermediate Process as in [RFC6183 ] that ... =20 Btw, you will see that "Intermediate Flow Selection Process" is already defined in the figure where you get it right. Finally, your sentence "A Flow Selection Process MAY be part of an IPFIX Metering Process, Exporting Process or as an Intermediate Selection = Process as=20 defined for the IPFIX Mediator [RFC6183]. ": - must contain "A Intermediate Flow Selection Process MAY be part of an IPFIX Metering Process ..." - must be reflected in figure 1, where I only see the Intermediate Flow Selection Process in the IPFIX Mediator. Could also be present in = Exporting Process and in the Metering Process. As figure 1 is the only figure, all possibilities must be displayed. See as an example http://tools.ietf.org/html/draft-ietf-ipfix-a9n-03 figure 1 A new definition of Intermediate Flow Selection Process and a new figure have been included in the Draft..=20 * Flow Selection State=20 A Flow Selection Process SHOULD maintain state information for use = normally, we try to avoid MAY/SHOULD/MUST in definition =20 Fixed by the Flow Selector. At a given time, the Flow Selection State=20 may depend on flows and packets observed at and before that time,=20 as well as other variables. Examples include:=20 (i) sequence number of packets and accounted Flow Records;=20 (ii) number of selected flows;=20 (iii) number of observed flows;=20 (iv) current flow cache occupancy;=20 (v) flow specific counters, lower and upper bounds;=20 (vi) flow selection timeout intervals.=20 * Flow Selector=20 A Flow Selector defines the action of a Flow Selection Process on=20 a single flow of its input. The Flow Selector can make use of the = following information in order to establish whether a flow has to=20 be selected or not:=20 (i) the content of the Flow Record;=20 (ii) any state information related to the Metering Process or=20 Exporting Process;=20 (iii) any Flow Selection State that may be maintained by the=20 Flow Selection Process.=20 I see many terms:=20 Packet Classification, Packet Aggregation Process, Flow Selection = Process, Flow Selection State, Intermediate Process, Intermediate Selection = Process, etc... Please have a new figure that put combines all these terms. Something = such as the figure in section 3.1 from http://tools.ietf.org/html/rfc5474 It might be your figure 1, but I don't even see those terms in there, or figure 3 in http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10 Figure 1 has been modified to address this comment. =20 * Complete Flow=20 A Complete Flow consists of all the packets that enter the Flow=20 Selection Process within the flow time-out interval, and which=20 belong to the same flow as defined by the flow definition in=20 D'Antonio, et al. Expires October 25, 2012 [Page 5] = =20 Internet-Draft Flow Selection Techniques April 2012 = [RFC5470]. For this definition only packets that arrive at the=20 Flow Selection Process are considered. That means, packets that=20 are not observed at the Flow Selection Process because of prior=20 packet selection or packet loss are not considered as belonging to = the Complete Flow.=20 what does the second sentence add? The second sentence has been removed. * Flow Filtering=20 Flow Filtering selects flows based on a deterministic function on=20 the Flow Record content, Flow Selection State, external properties = (e.g. ingress interface) or external events (e.g violated Access=20 Control List). If the relevant parts of the Flow Record content=20 can already be observed at packet level (e.g. Flow Keys from=20 packet header fields) Flow Filtering can be performed at packet=20 level by Property Match Filtering as described in [RFC5475].=20 * Hash-based Flow Filtering=20 Hash-based Flow Filtering is a deterministic flow filter function=20 that selects flows based on a Hash Function. The Hash Function is = calculated over parts of the Flow Record content or external=20 properties which are called the Hash Domain. If the hash value=20 falls into a predefined Hash Selection Range the flow is selected. = Hash-based Flow Filtering can already applied at packet level, in=20 which case the Hash Domain MUST contain the Flow Key of the=20 packet. In case Hash-based Flow Filtering is used to select the=20 same subset of flows at different observation points, the Hash=20 Domain MUST comprise parts of the packet or flow thar are=20 invariant on the packet/flow path. Also refer to the according=20 Trajectory Sampling Application Example on packet level in=20 [RFC5475]=20 * Flow-state Dependent Flow Selection=20 Flow-state Dependent Flow Selection is a selection function that=20 selects or drops flows based on the current Flow Selection State.=20 The selection can be either deterministic, random or non-uniform=20 random.=20 * Flow-state Dependent Packet Selection=20 Flow-state Dependent Packet Selection is a selection function that = selects or drops packets based on the current Flow Selection=20 State. The selection can be either deterministic, random or non-=20 uniform random. Flow-state Dependent Packet Selection can be used = to prefer the selection of packets belonging to specific flows.=20 For example the selection probability of packets belonging to=20 flows that are already within the Flow Cache may be higher than=20 D'Antonio, et al. Expires October 25, 2012 [Page 6] = =20 Internet-Draft Flow Selection Techniques April 2012 = for packets that have not been recorded yet.=20 * Flow Sampling=20 Flow Sampling selects flows based on Flow Record sequence or=20 arrival times (e.g. entry in flow cache, arrival time at Exporter=20 or Mediator). The selection can be systematic (e.g. every n-th=20 flow) or based on a random function (e.g. select each Flow Record=20 with probability p, or randomly select n out of N Flow Records).=20 3. Difference between Flow Selection and Packet Selection=20 Flow selection differs from packet selection described in [RFC5475].=20 Packet selection techniques consider packets as the basic element and = the parent population consists of all packets observed at an=20 observation point. In contrast to this the basic elements in flow=20 selection are the flows. The parent population consists of all=20 observed flows and the selection process operates on the flows. The=20 major characteristics of flow selection are the following:=20 - Flow selection takes flows as basic elements. For packet=20 selection, packets are considered as basic elements.=20 - Flow selection can only take place after Packet=20 Classification, because the classification rules determine to = which flow a packet belongs. Packet selection can be applied = before and after Packet Classification.=20 I don't understand the last sentence. An example has been added to clarify the sentence. - Flow selection operates on Complete Flows. That means that=20 after the Flow Selection Process either all packets of the=20 flow are kept or all packets of the flow are discarded. That = means that if the flow selection is preceded by a packet=20 selection process the Complete Flow consists only of the=20 packets that were not discarded during the packet selection.=20 There are some techniques that are difficult to unambiguously=20 categorize into one of the categories. Here we give some guidance=20 how to categorize such techniques:=20 - Techniques that can be considered as both packet and flow=20 selection: some packet selection techniques result in the=20 selection of Complete Flows and therefore can be considered=20 as packet or as flow selection at the same time. An example=20 is Property Match Filtering of all packets to a specific=20 destination address. If flows are defined based on=20 destination addresses, such a packet selection also results=20 in a flow selection and can be considered as packet or flow=20 D'Antonio, et al. Expires October 25, 2012 [Page 7] = =20 Internet-Draft Flow Selection Techniques April 2012 = selection.=20 - Flow-state Dependent Packet Selection (as described in=20 [RFC5475]): there exist techniques that select packets based=20 on the flow state, e.g. based on the number of already=20 observed packets belonging to the flow. Examples of these=20 techniques from the literature are "Sample and Hold" [EsVa01] = "Fast Filtered Sampling" [MSZC10] or the "Sticky Sampling"=20 algorithm presented in [MaMo02]. Such techniques can be used = to influence which flows are captured (e.g. increase the=20 selection of packets belonging to large flows) and reduce the = number of flows that need to be stored in the flow cache.=20 Nevertheless, such techniques do not necessarily select=20 Complete Flows, because they do not ensure that all packets=20 of a selected flow are captured. Therefore Flow-state=20 Dependent Packet Selection methods that do not ensure that=20 either all or no packets of a flow are selected strictly=20 speaking have to be considered as packet selection techniques = and not as flow selection techniques.=20 4. Flow selection as a Function in the IPFIX Architecture=20 Figure 1 shows the IPFIX reference model as defined in [RFC5470] and=20 shows the Packet Classification and Packet Aggregation Process in the = Metering Process.=20 D'Antonio, et al. Expires October 25, 2012 [Page 8] = =20 Internet-Draft Flow Selection Techniques April 2012 = Packet(s) coming in to Observation Point(s)=20 | |=20 v v=20 +----------------+---------------------------+ +-----+-------+ = | Metering Process | | | = | | | | = | packet header capturing | | | = | | |...| Metering | = | timestamping | | Process N | = | | | | | = | packet sampling | | | = | | | | | = | (packet classification) | | | = | | | | | = | packet filtering* | | | = | | | | | = | (packet aggregation)* | | | = | | | | | = +--------|-----------------------------------+ +-----|-------+ = Flow Records Flow Records | |=20 +----------------------+----------------------+=20 |=20 +----------------------|-----------------+=20 | Exporting Process* |=20 +----------------------+-----------------+=20 | IPFIX (Flow Records)=20 v=20 +-------------------------|-----------------------+=20 | IPFIX Mediator | |=20 | v |=20 | Collecting Process(es) |=20 | | |=20 | Intermediate Flow Selection Process (*) |=20 | | |=20 | Exporting Process(es) (*) |=20 +-------------------------|-----------------------+=20 v=20 IPFIX=20 (*) indicates where flow selection can take place.=20 Figure 1: Flow selection in the IPFIX Architecture=20 Please express the physical boundary between the Exporter and the IPFIX Mediator Why is packet classification in brackets? (packet aggregation), do you mean the Intermediate Aggregation Process = in http://tools.ietf.org/html/draft-ietf-ipfix-a9n-03? The figure has been completely changed. In contrast to packet selection, flow selection is always applied=20 after the packets are classified into flows. Flows can be selected=20 at different stages of the measurement chain:=20 D'Antonio, et al. Expires October 25, 2012 [Page 9] = =20 Internet-Draft Flow Selection Techniques April 2012 = 1. during the Metering Process=20 2. during Exporting Process(es)=20 3. during an Intermediate Selection Process on a Mediator=20 It's not "during" but "in".=20 =20 Fixed. Please display the 3 points above in the figure Done. =20 4.1. Flow selection during the Metering Process=20 In the Packet Aggregation Process the packet information is used to=20 update the Flow Records in the flow cache. Flow selection that is=20 applied before aggregation equals a packet selection process. The=20 flow still consists of individual packets. Those are then selected=20 based on the classification information, i.e. based on the flow they=20 belong to. Flow selection before aggregation can be based on the=20 fields of the Flow Key (also on a hash value over these fields), but=20 not based on characteristics that are only available after packet=20 aggregation (e.g. flow size, flow duration). Flow selection during=20 the Metering Process is applied to reduce resources for all=20 succeeding processes or to select specific flows of interest in case=20 such flow characteristics are already observable at packet level=20 (e.g. flows to specific IP addresses). In contrast, Flow-state=20 Dependent Packet Selection is a packet selection method, because it=20 does not necessarily select Complete Flows.=20 4.2. Flow selection during the Exporting Process=20 The Flow Selection Process at the Exporter is similar to an=20 Intermediate Selection Process as described in [RFC6183] and works on = Flow records. Flow selection during the Exporting Process can=20 therefore also depend on flow characteristics that are only visible=20 after the aggregation of packets, such as flow size and flow=20 duration. =20 Why can't this be done in the Metering Process as well? Changes have been made to section 4.2 to address this comment. The Exporting Process may implement policies for exporting=20 only a subset of the Flow Records which have been stored in the=20 system memory in order to unload flow export and flow post-=20 processing. Flow selection during the Exporting Process may select=20 only the subset of Flow Records which are of interest to the users=20 application, or select only as many Flow Records as can be handled by = the available resources (e.g. limited export link capacity).=20 4.3. Flow selection as a function of the IPFIX Mediator=20 As shown in Figure 1, flow selection can be performed as an=20 Please rewrite these section 4.* based on the Intermediate Flow = Selection Process, and not flow selection, which is not defined. =20 Done. Intermediate Process within an IPFIX Mediator [RFC6183]. The=20 Intermediate Selection Process takes Flow Record stream as its input=20 and selects Flow Records from a sequence based upon criteria-=20 evaluated record values. The Intermediate Selection Process can=20 again apply a flow selection technique to obtain flows of interest to = the application. Further, the Intermediate Selection Process can=20 D'Antonio, et al. Expires October 25, 2012 [Page 10] = =20 Internet-Draft Flow Selection Techniques April 2012 = base its selection decision on the correlation of data from different = observation points,=20 or most of the time Exporters (which btw, you should show this in the figure) See figure A in RFC 6183 Observation Points replaced by Exporters. =20 e.g. by only selecting flows that were at least=20 recorded on two observation points.=20 5. Flow Selection Techniques=20 A flow selection technique selects either all or none of the packets=20 I see sometimes flow selection, sometimes flow selection technique, sometimes selection technique, sometimes flow selection scheme, sometimesflow selection methods, sometimes Flow Selection Process which should really be the Intermediate Flow Selection Process...=20 It's difficult to read the draft, as it misses some cohesion: this = clearly shows that different parts of the document have been written by = different persons.=20 Please review the entire document with a fresh mind, as if you would discover for the first time, and you will see what I mean.=20 The entire draft needs some improvements on that matter. =20 The document has been reviewed.=20 The terms =93scheme=94 and =93method=94 replaced by technique. of a flow, otherwise the technique has to be considered as packet=20 selection. We distinguish between Flow Filtering and Flow Sampling.=20 5.1. Flow Filtering=20 Flow Filtering is a deterministic function on the IPFIX Flow Record=20 content. If the relevant flow characteristics are already observable = at packet level (e.g. Flow Keys), Flow Filtering can be applied=20 before aggregation at packet level. In order to be compliant with=20 this document, at least the Property Match Filtering MUST be=20 implemented.=20 This contradicts. In order to be compliant with this document, at least one of the flow selection schemes MUST be implemented. =20 Ok, agreed. The contradiction has been fixed. =20 5.1.1. Property Match Filtering=20 Property Match Filtering can be performed similarly to Property Match = Filtering for packet selection described in [RFC5475]. The=20 difference is that, instead of packet fields, Flow Record fields are=20 here used to derive the selection decision. Property Match Filtering = is typically used to select a specific subset of the flows that are=20 of interest to a particular application (e.g. all flows to a specific = destination, all large flows, etc.). Properties on which the=20 filtering is based can be Flow Keys, Flow Timestamps, or Per-Flow=20 Counters described in [RFC5102]. Examples of properties are the flow = size in bytes, the number of packets in the flow, the observation=20 time of the first or last packet, or the maximum packet length. An=20 example is to select flows with more than a threshold number of=20 observed octets. The selection criteria can be a specific value, a=20 set of specific values, or an interval. For example, a flow is=20 selected if destinationIPv4Address and the total number of packets of = the flow equal two predefined values. Property Match Filtering can=20 be applied during the Metering Process if the properties are already=20 observable at the packet level (e.g. Flow Key fields). For example, = a flow is selected if sourceIPv4Address and sourceIPv4PrefixLength=20 equal, respectively, two specific values.=20 There are content-based Property Match Filtering techniques that=20 require a computation on the current flow cache. An example is the=20 selection of the largest flows or a percentage of flows with the=20 longest lifetime. This type of Property Match Filtering is also used = in flow selection techniques that react to external events (e.g.=20 D'Antonio, et al. Expires October 25, 2012 [Page 11] = =20 Internet-Draft Flow Selection Techniques April 2012 = resource constraint). For example when the flow cache is full, the=20 Flow Record with the lowest flow volume per current flow life time=20 may be deleted.=20 5.1.2. Hash-based Flow Filtering=20 Hash-based Flow Filtering uses a Hash Function h to map the Flow Key=20 c onto a Hash Range R. A flow is selected if the hash value h(c) is=20 within the Hash Selection Range S, which is a subset of R. Hash-based = Flow Filtering can be used to emulate a random sampling process but=20 still enable the correlation between selected flow subsets at=20 different observation points. Hash-based Flow Filtering is similar=20 to Hash-based Packet Selection, and in fact is identical when Hash-=20 based Packet Selection uses the Flow Key that defines the flow as the = hash input. Nevertheless there may be the incentive to apply Hash-=20 based Flow Filtering not on the packet level during the Metering=20 Process, for example when the size of the selection range and=20 therefore the sampling probability is dependent on the number of=20 observed flows.=20 5.2. Flow Sampling=20 Flow Sampling operates on Flow Record sequence or arrival times. It=20 can use either a systematic or a random function for the selection=20 process. Flow Sampling usually aims at the selection of a=20 representative subset of all flows in order to estimate=20 characteristics of the whole set (e.g. mean flow size in the=20 network).=20 5.2.1. Systematic sampling=20 Systematic sampling is a deterministic selection function.=20 Systematic sampling may be a periodic selection of the N-th Flow=20 Record which arrives at the Exporting or Intermediate Selection=20 Process. =20 Intermediate Flow Selection Process Systematic sampling MAY be applied during the Metering=20 Process. An example would be to create, besides the Flow cache of=20 selected flows, an additional data structure that saves the Flow Keys = of the flows that are not selected. The selection of a flow would=20 then be based on the first packet of a flow. Everytime a packet=20 belonging to a new flow (which is neither in the data structure of=20 the selected or not selected flows) arrives at the measurement point, = what is a measurement point? Measurement point replaced with Observation Point. =20 a counter is increased. In case the counter is increased to a=20 multiple of N a new flow cache entry is created, and in case the=20 counter is not a multiple of N the Flow Key is added to the data=20 structure for not selected flows.=20 Systematic sampling can also be time-based. Time-based systematic=20 sampling is applied by only creating flows that are observed between=20 flows -> Flows all over the doc. Done. D'Antonio, et al. Expires October 25, 2012 [Page 12] = =20 Internet-Draft Flow Selection Techniques April 2012 = time-based start and stop triggers. The time interval may be applied = at packet level during the Metering Process or after aggregation on=20 flow level, e.g. by selecting a flow arriving at the Exporting=20 Process every n seconds.=20 5.2.2. Random Sampling=20 Random flow sampling is based on a random process which requires the=20 calculation of random numbers. One can differentiate between n-out-N = and probabilistic flow sampling.=20 5.2.2.1. n-out-of-N Flow Sampling=20 In n-out-of-N Sampling, n elements are selected out of the parent=20 population that consists of N elements. One example would be to=20 generate n different random numbers in the range [1,N] and select all = flows that have a flow position equal to one of the random numbers.=20 5.2.2.2. Probabilistic Flow Sampling=20 In probabilistic Sampling, the decision whether or not a flow is=20 selected is made in accordance with a predefined selection=20 probability. For probabilistic Sampling, the Sample Size can vary=20 for different trials. The selection probability does not necessarily = have to be the same for each flow. Therefore, we distinguish between = uniform probabilistic sampling (with the same selection probability=20 for all flows) and non-uniform probabilistic sampling (where the=20 selection probability can vary for different flows). For non-uniform = probabilistic Flow Sampling the sampling probability may be adjusted=20 according to the Flow Record content. An example would be to=20 increase the selection probability of large volume flows over small=20 volume flows as described in the Smart Sampling technique [DuLT01].=20 5.3. Flow-state Dependent Flow Selection=20 Flow-state Dependent Flow Selection can be a deterministic or random=20 flow selection process based on the Flow Record content and the flow=20 state which may be kept additionally for each of the flows. External = processes may update counters, bounds and timers for each of the Flow = Records and the Flow Selection Process utilises this information for=20 the selection decision. A review of Flow-state Dependent Flow=20 Selection techniques that aim at the selection of the most frequent=20 items by keeping additional flow state information can be found in=20 [CoHa08]. Flow-state Dependent Flow Selection can only be applied=20 after packet aggregation, when a packet has been assigned to a flow.=20 The selection process then decides based upon the flow state for each = flow if it is kept in the flow cache or not. Two Flow State=20 Dependent Flow Selection Algorithms are here described:=20 D'Antonio, et al. Expires October 25, 2012 [Page 13] = =20 Internet-Draft Flow Selection Techniques April 2012 = The frequent algorithm [KaPS03] is a technique that aims at the=20 selection of all flows that at least exceed a 1/k fraction of the=20 Observed Packet Stream. =20 to come back to one of my previous point, please add Observed Packet = Stream to the extra figure=20 The algorithm has only a flow cache of size=20 k-1 and each flow in the cache has an additional counter. The=20 counter is incremented each time a packet belonging to the flow in=20 the flow cache is observed. In case the observed packet does not=20 belong to any flow all counters are decremented and if any of the=20 flow counters has a value of zero the flow is replaced with a flow=20 formed from the new packet.=20 Lossy counting is a selection technique that identifies all flows=20 whose packet count exceeds a certain percentage of the whole observed = packet stream (e.g. 5% of all packets) with a certain estimation=20 error e. Lossy counting separates the observed packet stream in=20 windows of size N=3D1/e, where N is an amount of consecutive packets. = For each observed flow an additional counter will be held in the flow = state. The counter is incremented each time a packet belonging to=20 the flow is observed and all counters are decremented at the end of=20 each window and all flows with a counter of zero are removed from the = flow cache.=20 5.4. Flow-state Dependent Packet Selection=20 Flow-state Dependent Packet Selection is not a flow selection=20 technique but a packet selection technique. Nevertheless we will=20 describe configuration and reporting parameters for this technique in = this document. An example is the "Sample and Hold" algorithm=20 [EsVa01] that tries to prefer large volume flows in the selection.=20 When a packet arrives it is selected when a Flow Record for this=20 packet already exists. In case there is no Flow Record, the packet=20 is selected by a certain probability that is dependent on the packet=20 size.=20 6. Configuration of Flow Selection Techniques=20 This section describes the configuration parameters of the flow=20 selection techniques presented above. It provides the basis for an=20 information model to be adopted in order to configure the Flow=20 Selection Process within an IPFIX Device. The actual information=20 model with the Information Elements (IEs) for the configuration is=20 described together with the reporting IEs in section 7. The=20 following table gives an overview of the defined selection=20 techniques, where they can be applied and what their input parameters = are. Depending on where the flow selection techniques are applied=20 different input parameters can be configured.=20 Overview of Flow Selection Techniques:=20 D'Antonio, et al. Expires October 25, 2012 [Page 14] = =20 Internet-Draft Flow Selection Techniques April 2012 = +------------------+-----------------+------------------------------+ = | Location | Selection | Selection Input | = | | Method | | = +------------------+-----------------+------------------------------+ = | During the | Flow-state | packet sampling | = location is not "during" but "in" =20 Fixed. | Metering Process | Dependent | probabilities, Flow | = | based on Packets | Packet | Selection State, packet | = | | Selection | properties | = I still don't get why "in the Metering Process" means, on packets? =20 =93On packets=94 has been removed. +------------------+-----------------+------------------------------+ = should=20 | | Property Match | Flow record IEs, Selection | = | | Flow Filtering | Interval | = +------------------+-----------------+------------------------------+ = | | Hash-based Flow | selection range, Hash | = | | Filtering | Function, Flow Key, (seed) | = +------------------+-----------------+------------------------------+ = | | Time-based | flow position (derived from | = | | Systematic Flow | arrival time of packets), | = | | Sampling | flow selection state | = +------------------+-----------------+------------------------------+ = | | Sequence-based | flow position (derived from | = | | Systematic Flow | packet position), flow | = | | Sampling | selection state | = +------------------+-----------------+------------------------------+ = | | Random Flow | random number generator or | = | | Sampling | list and packet position, | = | | | flow state | = +------------------+-----------------+------------------------------+ = This location above applies to the 6 column, right? so make a big cell = out for "in the Metering Process based on packets" Same remark below. I was not able to create a big cell applying to the 6 columns. I simply = used the same text in the 6 columns.=20 | Exporting / | Property Match | Flow Record content, filter | = | Intermediate | Flow Filtering | function | = | Selection | | | = | Process | | | = +------------------+-----------------+------------------------------+ = | | Hash-based Flow | selection range, Hash | = | | Filtering | Function, hash input (Flow | = | | | Keys and other flow | = | | | properties) | = +------------------+-----------------+------------------------------+ = | | Flow-state | flow state parameters, | = | | Dependent Flow | random number generator or | = | | Selection | list | = +------------------+-----------------+------------------------------+ = | | Time-based | flow arrival time, flow | = | | Systematic Flow | state | = | | Sampling | | = +------------------+-----------------+------------------------------+ = | | Sequence-based | flow position, flow state | = | | Systematic Flow | | = | | Sampling | | = D'Antonio, et al. Expires October 25, 2012 [Page 15] = =20 Internet-Draft Flow Selection Techniques April 2012 = | | Random Flow | random number generator or | = | | Sampling | list and flow position, flow | = | | | state | = +------------------+-----------------+------------------------------+ = Not sure what the "flow position". Below, you use "Spacing" for this concept. Table 1: Overview of Flow Selection Techniques=20 6.1. Flow Selection Parameters=20 In this section, we define what parameters are required to describe=20 the most common Flow Selection techniques.=20 You see, yet another new term, which is not in the terminology: Flow Selection And on the top of my head, it was not defined in any other documents referenced in the terminology =20 The section title has been changed. Flow Selection Parameters:=20 For Property Match Filtering:=20 - Information Element as specified in [iana-ipfix-assignments]):=20 Specifies the Information Element which is used as the property=20 in the filter expression.=20 - Selection Value or Value Interval:=20 Specifies the value or interval of the filter expression.=20 Packets and Flow Record that have a value equal to the Selection=20 Value or within the Interval will be selected.=20 For Hash-based Flow Filtering:=20 - Hash Domain:=20 Specifies the bits from the packet or flow which are taken as the = hash input to the Hash Function.=20 - Hash Function:=20 Specifies the name of the Hash Function that is used to calculate = the hash value. Possible Hash Functions are BOB [RFC5475], IPSX=20 [RFC5475], CRC-32 [Bra75]=20 - Hash Selection Range:=20 Flows that have a hash value within the Hash Selection Range are=20 selected. The Hash Selection Range can be a value interval or=20 arbitrary hash values within the Hash Range of the Hash Function. = - Random Seed or Initializer Value:=20 Some Hash Functions require an initializing value. In order to=20 make the selection decision more secure one can choose a random=20 seed that configures the hash function.=20 For Flow-state Dependent Flow Selection:=20 D'Antonio, et al. Expires October 25, 2012 [Page 16] = =20 Internet-Draft Flow Selection Techniques April 2012 = - frequency threshold:=20 Specifies the frequency threshold s for flow state dependent flow = selection techniques that try to find the most frequent items=20 within a dataset. All flows which exceed the defined threshold=20 will be selected.=20 - accuracy parameter:=20 specifies the accuracy parameter e for techniques that deal with=20 the frequent items problems. The accuracy parameter defines the=20 maximum error, i.e. no flows that have a true frequency less than = ( s - e) N are selected, where s is the frequency threshold and N = is the total number of packets.=20 The above list of parameters for Flow-state Dependent Flow Selection=20 techniques is suitable for the presented frequent item and lossy=20 counting algorithms. Nevertheless a variety of techniques exist with = very specific parameters which are not defined here.=20 For Systematic time-based Flow Sampling:=20 - Interval length (in usec)=20 Defines the length of the sampling interval during which flows=20 are selected.=20 - Spacing (in usec)=20 The spacing parameter defines the spacing in usec between the end = of one sampling interval and the start of the next succeeding=20 interval.=20 For Systematic count-based Flow Sampling:=20 - Interval length=20 Defines the number of flows that are selected within the sampling = interval.=20 - Spacing=20 The spacing parameter defines the spacing in number of observed=20 flows between the end of one sampling interval and the start of=20 the next succeeding interval.=20 For random n-out-of-N Flow Sampling:=20 - Population Size N=20 The Population Size N is the number of all flows in the=20 Population from which the sample is drawn.=20 D'Antonio, et al. Expires October 25, 2012 [Page 17] = =20 Internet-Draft Flow Selection Techniques April 2012 = - Sampling Size n=20 The sampling size n is the number of flows that are randomly=20 drawn from the population N.=20 For probabilistic Flow Sampling:=20 - Sampling probability p=20 The sampling probability p defines the probability by which each=20 of the observed flows is selected.=20 6.2. Description of Flow-state Dependent Packet Selection=20 The configuration of Flow-state Dependent Packet Selection has not=20 been described in [RFC5475] therefore the parameters are defined=20 here:=20 For Flow-state Dependent Packet Selection:=20 - packet selection probability per possible flow state interval=20 Defines multiple {flow interval, packet selection probability}=20 value pairs that configure the sampling probability depending on=20 the current flow state.=20 - additional parameters=20 For the configuration of flow state dependent packet selection=20 additional parameters or packet properties may be required, e.g.=20 the packet size ([EsVa01])=20 7. Information Model for Flow Selection Configuration and Reporting=20 In this section we describe Information Elements (IEs) that MUST be=20 This section specifies ... Modified. =20 exported by a flow selection process in order to support the=20 Flow Selection Process=20 =20 Done interpretation of measurement results from flow measurements where=20 only some flows are selected. =20 "from flow measurements where only some flows are selected. " Do you need that? Isn't it by default what a Flow Selection Process = does? =20 Right. The sentence has been removed. =20 The information is mainly used to=20 report how many packets and flows have been observed in total and how = many of them were selected. This helps for instance to calculate the = Attained Selection Fraction (see also [RFC5476]), which is an=20 important parameter to provide an accuracy statement. The IEs can=20 provide reporting information about Flow Records, packets or bytes.=20 The reported metrics are total number of elements and the number of=20 selected elements. From this the number of dropped elements can be=20 derived. All counters SHOULD be exported and reset when a new=20 measurement interval starts.=20 I disagree here. It depends which IEs you use: deltaCounter or = totalCounter Search for those two terms in http://www.iana.org/assignments/ipfix/ipfix.xml In order to avoid ambiguity, this sentence has been removed. List of Flow Selection Information Elements:=20 D'Antonio, et al. Expires October 25, 2012 [Page 18] = =20 Internet-Draft Flow Selection Techniques April 2012 = +------+-------------------------+-------+--------------------------+ = | ID | Name | ID | Name | = +------+-------------------------+-------+--------------------------+ = | 301 | selectionSequenceID | 302 | selectorID | = +------+-------------------------+-------+--------------------------+ = | TBD1 | flowSelectorAlgorithm | 1 | octetDeltaCount | = +------+-------------------------+-------+--------------------------+ = | TBD2 | flowSelectedOctetDeltaC | 2 | packetDeltaCount | = | | ount | | | = +------+-------------------------+-------+--------------------------+ = | TBD3 | flowSelectedPacketDelta | 3 | originalFlowsPresent | = | | Count | | | = +------+-------------------------+-------+--------------------------+ = | TBD4 | flowSelectedFlowDeltaCo | TBD5 | selectorIDTotalFlowsObse | = | | unt | | rved | = +------+-------------------------+-------+--------------------------+ = | TBD6 | selectorIDTotalFlowsSel | TBD7 | samplingFlowInterval | = | | ected | | | = +------+-------------------------+-------+--------------------------+ = | TBD8 | samplingFlowSpace | 309 | samplingSize | = +------+-------------------------+-------+--------------------------+ = | 310 | samplingPopulation | 311 | samplingProbability | = +------+-------------------------+-------+--------------------------+ = | TBD9 | flowSamplingTimeInterva | TBD10 | flowSamplingTimeSpace | = | | l | | | = +------+-------------------------+-------+--------------------------+ = | 326 | digestHashValue | TBD11 | hashFlowOffset | = +------+-------------------------+-------+--------------------------+ = | TBD1 | hashFlowSize | 329 | hashOutputRangeMin | = | 2 | | | | = +------+-------------------------+-------+--------------------------+ = | 330 | hashOutputRangeMax | 331 | hashSelectedRangeMin | = +------+-------------------------+-------+--------------------------+ = | 332 | hashSelectedRangeMax | 333 | hashDigestOutput | = +------+-------------------------+-------+--------------------------+ = | 334 | hashInitialiserValue | 320 | absoluteError | = +------+-------------------------+-------+--------------------------+ = | 321 | relativeError | 336 | upperCILimit | = +------+-------------------------+-------+--------------------------+ = | 337 | lowerCILimit | 338 | confidenceLevel | = +------+-------------------------+-------+--------------------------+ = Table 2: Flow Selection Information Elements=20 D'Antonio, et al. Expires October 25, 2012 [Page 19] = =20 Internet-Draft Flow Selection Techniques April 2012 = 7.1. flowSelectorAlgorithm=20 Description:=20 This Information Element identifies the flow selection=20 method(e.g., Filtering, Sampling) that is applied by the Flow=20 Selection Process. Most of these methods have parameters as=20 decribed in Section 6. Further Information Elements are needed to = fully specify packet selection with these methods and all their=20 parameters. =20 Why do you speak about "packet selection" in the flowSelectorAlgorithm?=20 =20 =20 Fixed. =20 Further method identifiers may be added to the list=20 below. It might be necessary to define new Information Elements=20 to specify their parameters. The flowSelectorAlgorithm registry=20 is maintained by IANA. New assignments for the registry will be=20 administered by IANA and are subject to Expert Review [RFC5226].=20 The registry can be updated when specifications of the new=20 method(s) and any new Information Elements are provided.=20 +----+------------------------+--------------------------+=20 | ID | Method | Parameters |=20 +----+------------------------+--------------------------+=20 | 1 | Systematic count-based | flowSamplingInterval |=20 | | Sampling | flowSamplingSpace |=20 +----+------------------------+--------------------------+=20 | 2 | Systematic time-based | flowSamplingTimeInterval |=20 | | Sampling | flowSamplingTimeSpace |=20 +----+------------------------+--------------------------+=20 | 3 | Random n-out-of-N | samplingSize |=20 | | Sampling | samplingPopulation |=20 +----+------------------------+--------------------------+=20 | 4 | Uniform probabilistic | samplingProbability |=20 | | Sampling | |=20 +----+------------------------+--------------------------+=20 | 5 | Property Match | Information Element |=20 | | Filtering | Value Range |=20 +----+------------------------+--------------------------+=20 | Hash-based Filtering | hashInitialiserValue |=20 +----+------------------------+ hashFlowDomain |=20 | 6 | using BOB | hashSelectedRangeMin |=20 +----+------------------------+ hashSelectedRangeMax |=20 | 7 | using IPSX | hashOutputRangeMin |=20 +----+------------------------+ hashOutputRangeMax |=20 | 8 | using CRC | |=20 +----+------------------------+--------------------------+=20 | 9 | Flow State Dependent | No agreed Parameters |=20 | | Flow Selection | |=20 +----+------------------------+--------------------------+=20 D'Antonio, et al. Expires October 25, 2012 [Page 20] = =20 Internet-Draft Flow Selection Techniques April 2012 = Abstract Data Type: unsigned16=20 ElementId: TBD1=20 Data Type Semantics: identifier=20 Status: Proposed=20 7.2. flowSelectedOctetDeltaCount=20 Description:=20 This Information Element specifies the volume in octets of all=20 flows that are selected during the Flow Selection Process since=20 the previous report.=20 Abstract Data Type: unsigned64=20 ElementId: TBD2=20 Units: Octets=20 Status: Proposed=20 7.3. flowSelectedPacketDeltaCount=20 Description:=20 This Information Element specifies the volume in packets of all=20 flows that were selected during the Flow Selection Process since=20 the previous report.=20 Abstract Data Type: unsigned64=20 ElementId: TBD3=20 Units: Packets=20 Status: Proposed=20 7.4. flowSelectedFlowDeltaCount=20 Description:=20 This Information Element specifies the number of Flows that were=20 selected during the Flow Selection Process since the last report.=20 Abstract Data Type: unsigned64=20 D'Antonio, et al. Expires October 25, 2012 [Page 21] = =20 Internet-Draft Flow Selection Techniques April 2012 = ElementId: TBD4=20 Units: Flows=20 Status: Proposed=20 7.5. selectorIDTotalFlowsObserved=20 Description:=20 This Information Element specifies the total number of flows=20 observed by a Selector, for a specific value of SelectorId. This=20 Information Element should be used in an Options Template scoped=20 to the observation to which it refers. See Section 3.4.2.1 of the = IPFIX protocol document [RFC5101] .=20 Abstract Data Type: unsigned64=20 ElementId: TBD5=20 Units: Flows=20 Status: Proposed=20 7.6. selectorIDTotalFlowsSelected=20 Description:=20 This Information Element specifies the total number of flows=20 selected by a Selector, for a specific value of SelectorId. This=20 Information Element should be used in an Options Template scoped=20 to the observation to which it refers. See Section 3.4.2.1 of the = IPFIX protocol document [RFC5101].=20 Abstract Data Type: unsigned64=20 ElementId: TBD6=20 Units: Flows=20 Status: Proposed=20 7.7. samplingFlowInterval=20 Description:=20 This Information Element specifies the number of flows that are=20 consecutively sampled. A value of 100 means that 100 consecutive=20 D'Antonio, et al. Expires October 25, 2012 [Page 22] = =20 Internet-Draft Flow Selection Techniques April 2012 = flows are sampled. For example, this Information Element may be=20 used to describe the configuration of a systematic count-based=20 Sampling Selector.=20 Abstract Data Type: unsigned64=20 ElementId: TBD7=20 Units: Flows=20 Status: Proposed=20 7.8. samplingFlowSpace=20 Description:=20 This Information Element specifies the number of flows between two = "samplingFlowInterval"s. A value of 100 means that the next=20 interval starts 100 flows (which are not sampled) after the=20 current "samplingFlowInterval" is over. For example, this=20 Information Element may be used to describe the configuration of a = systematic count-based Sampling Selector.=20 The text above mentions: For Systematic count-based Flow Sampling:=20 - Interval length=20 Defines the number of flows that are selected within the sampling = interval.=20 - Spacing=20 The spacing parameter defines the spacing in number of observed=20 flows between the end of one sampling interval and the start of=20 the next succeeding interval. So be consistent between "Space", "Spacing", and position (see one of my previous comments" Space has been replaced with Spacing in samplingFlowSpace and in flowSamplingTimeSpace. Abstract Data Type: unsigned64=20 ElementId: TBD8=20 Units: Flows=20 Status: Proposed=20 7.9. flowSamplingTimeInterval=20 Description:=20 This Information Element specifies the time interval in=20 microseconds during which all arriving flows are sampled. For=20 example, this Information Element may be used to describe the=20 configuration of a systematic time-based Sampling Selector.=20 The text above mentions: For Systematic time-based Flow Sampling:=20 - Interval length (in usec)=20 Defines the length of the sampling interval during which flows=20 are selected.=20 - Spacing (in usec)=20 The spacing parameter defines the spacing in usec between the end = of one sampling interval and the start of the next succeeding=20 interval.=20 So be consistent between "Space", "Spacing", and position (see one of my previous comments" Abstract Data Type: unsigned64=20 ElementId: TBD9=20 Units: microseconds=20 Status: Proposed=20 D'Antonio, et al. Expires October 25, 2012 [Page 23] = =20 Internet-Draft Flow Selection Techniques April 2012 = 7.10. flowSamplingTimeSpace=20 Description:=20 This Information Element specifies the time interval in=20 microseconds between two "flowSamplingTimeInterval"s. A value of=20 100 means that the next interval starts 100 microseconds (during=20 which no flows are sampled) after the current=20 "flowsamplingTimeInterval" is over. For example, this Information = Element may used to describe the configuration of a systematic=20 time-based Sampling Selector.=20 Same remark. Abstract Data Type: unsigned64=20 ElementId: TBD10=20 Units: microseconds=20 Status: Proposed=20 7.11. hashFlowDomain=20 Description:=20 This Information Element specifies the Information Elements that=20 are used by the Hash-based flow Selection Selector as the Hash=20 Domain.=20 Abstract Data Type: unsigned16=20 ElementId: TBD11=20 Data Type Semantics: identifier=20 Status: Proposed=20 8. IANA Considerations=20 8.1. Registration of Information Elements=20 IANA will register the following IEs in the IPFIX Information=20 Elements registry at http://www.iana.org/assignments/ipfix/ipfix.xml: = D'Antonio, et al. Expires October 25, 2012 [Page 24] = =20 Internet-Draft Flow Selection Techniques April 2012 = +-----+----------------+--------+---------+-------+-----------------+ = | Val | Name | Data | Data | Statu | Description | = | ue | | Type | Type | s | | = | | | | Semanti | | | = | | | | cs | | | = +-----+----------------+--------+---------+-------+-----------------+ = | 1 | flowSelectorAl | unsign | identif | Propo | This | = | | gorithm | ed16 | ier | sed | Information | = | | | | | | Element | = | | | | | | identifies the | = | | | | | | flow selection | = | | | | | | method(e.g., | = | | | | | | Filtering, | = | | | | | | Sampling) that | = | | | | | | is applied by | = | | | | | | the Flow | = | | | | | | Selection | = | | | | | | Process | = +-----+----------------+--------+---------+-------+-----------------+ = | 2 | flowSelectedOc | unsign | Octets | Propo | This | = | | tetDeltaCount | ed64 | | sed | Information | = | | | | | | Element | = | | | | | | specifies the | = | | | | | | volume in | = | | | | | | octets of all | = | | | | | | flows that are | = | | | | | | selected during | = | | | | | | the Flow | = | | | | | | Selection | = | | | | | | Process since | = | | | | | | the previous | = | | | | | | report. | = +-----+----------------+--------+---------+-------+-----------------+ = | 3 | flowSelectedPa | unsign | Packets | Propo | This | = | | cketDeltaCount | ed64 | | sed | Information | = | | | | | | Element | = | | | | | | specifies the | = | | | | | | volume in | = | | | | | | packets of all | = | | | | | | flows that were | = | | | | | | selected during | = | | | | | | the Flow | = | | | | | | Selection | = | | | | | | Process since | = | | | | | | the previous | = | | | | | | report. | = +-----+----------------+--------+---------+-------+-----------------+ = D'Antonio, et al. Expires October 25, 2012 [Page 25] = =20 Internet-Draft Flow Selection Techniques April 2012 = +-----+----------------+--------+---------+-------+-----------------+ = | 4 | flowSelectedFl | unsign | Flows | Propo | This | = | | owDeltaCount | ed64 | | sed | Information | = | | | | | | Element | = | | | | | | specifies the | = | | | | | | number of Flows | = | | | | | | that were | = | | | | | | selected during | = | | | | | | the Flow | = | | | | | | Selection | = | | | | | | Process since | = | | | | | | the last | = | | | | | | report. | = +-----+----------------+--------+---------+-------+-----------------+ = | 5 | selectorIDTota | unsign | Flows | Propo | This | = | | lFlowsObserved | ed64 | | sed | Information | = | | | | | | Element | = | | | | | | specifies the | = | | | | | | total number of | = | | | | | | flows observed | = | | | | | | by a Selector, | = | | | | | | for a specific | = | | | | | | value of | = | | | | | | SelectorId. | = | | | | | | This | = | | | | | | Information | = | | | | | | Element should | = | | | | | | be used in an | = | | | | | | Options | = | | | | | | Template scoped | = | | | | | | to the | = | | | | | | observation to | = | | | | | | which it | = | | | | | | refers. See | = | | | | | | Section 3.4.2.1 | = | | | | | | of the IPFIX | = | | | | | | protocol | = | | | | | | document | = | | | | | | [RFC5101] | = +-----+----------------+--------+---------+-------+-----------------+ = D'Antonio, et al. Expires October 25, 2012 [Page 26] = =20 Internet-Draft Flow Selection Techniques April 2012 = +-----+----------------+--------+---------+-------+-----------------+ = | 6 | selectorIDTota | unsign | Flows | Propo | This | = | | lFlowsSelected | ed64 | | sed | Information | = | | | | | | Element | = | | | | | | specifies the | = | | | | | | total number of | = | | | | | | flows selected | = | | | | | | by a Selector, | = | | | | | | for a specific | = | | | | | | value of | = | | | | | | SelectorId. | = | | | | | | This | = | | | | | | Information | = | | | | | | Element should | = | | | | | | be used in an | = | | | | | | Options | = | | | | | | Template scoped | = | | | | | | to the | = | | | | | | observation to | = | | | | | | which it | = | | | | | | refers. See | = | | | | | | Section 3.4.2.1 | = | | | | | | of the IPFIX | = | | | | | | protocol | = | | | | | | document | = | | | | | | [RFC5101]. | = +-----+----------------+--------+---------+-------+-----------------+ = D'Antonio, et al. Expires October 25, 2012 [Page 27] = =20 Internet-Draft Flow Selection Techniques April 2012 = +-----+----------------+--------+---------+-------+-----------------+ = | 7 | samplingFlowIn | unsign | Flows | Propo | This | = | | terval | ed64 | | sed | Information | = | | | | | | Element | = | | | | | | specifies the | = | | | | | | number of flows | = | | | | | | that are | = | | | | | | consecutively | = | | | | | | sampled. A | = | | | | | | value of 100 | = | | | | | | means that 100 | = | | | | | | consecutive | = | | | | | | flows are | = | | | | | | sampled. For | = | | | | | | example, this | = | | | | | | Information | = | | | | | | Element may be | = | | | | | | used to | = | | | | | | describe the | = | | | | | | configuration | = | | | | | | of a systematic | = | | | | | | count-based | = | | | | | | Sampling | = | | | | | | Selector. | = +-----+----------------+--------+---------+-------+-----------------+ = D'Antonio, et al. Expires October 25, 2012 [Page 28] = =20 Internet-Draft Flow Selection Techniques April 2012 = +-----+----------------+--------+---------+-------+-----------------+ = | 8 | samplingFlowSp | unsign | Flows | Propo | This | = | | ace | ed64 | | sed | Information | = | | | | | | Element | = | | | | | | specifies the | = | | | | | | number of flows | = | | | | | | between two | = | | | | | | "samplingFlowIn | = | | | | | | terval"s. A | = | | | | | | value of 100 | = | | | | | | means that the | = | | | | | | next interval | = | | | | | | starts 100 | = | | | | | | flows (which | = | | | | | | are not | = | | | | | | sampled) after | = | | | | | | the current | = | | | | | | "samplingFlowI | = | | | | | | nterval" is ove | = | | | | | | r.For example, | = | | | | | | this | = | | | | | | Information | = | | | | | | Element may b | = | | | | | | e used to | = | | | | | | describe the | = | | | | | | configuration | = | | | | | | of a systemat | = | | | | | | iccount-based | = | | | | | | Sampling | = | | | | | | Selector. | = +-----+----------------+--------+---------+-------+-----------------+ = D'Antonio, et al. Expires October 25, 2012 [Page 29] = =20 Internet-Draft Flow Selection Techniques April 2012 = +-----+----------------+--------+---------+-------+-----------------+ = | 9 | flowSamplingTi | unsign | microse | Propo | This | = | | meInterval | ed64 | conds | sed | Information | = | | | | | | Element | = | | | | | | specifies the | = | | | | | | time interval | = | | | | | | in microseconds | = | | | | | | during which | = | | | | | | all arriving | = | | | | | | flows are | = | | | | | | sampled. For | = | | | | | | example, this | = | | | | | | Information | = | | | | | | Element may be | = | | | | | | used to | = | | | | | | describe the | = | | | | | | configuration | = | | | | | | of a systematic | = | | | | | | time-based | = | | | | | | Sampling | = | | | | | | Selector. | = +-----+----------------+--------+---------+-------+-----------------+ = D'Antonio, et al. Expires October 25, 2012 [Page 30] = =20 Internet-Draft Flow Selection Techniques April 2012 = +-----+----------------+--------+---------+-------+-----------------+ = | 10 | flowSamplingTi | unsign | microse | Propo | This | = | | meSpace | ed64 | conds | sed | Information | = | | | | | | Element | = | | | | | | specifies the | = | | | | | | time interval | = | | | | | | in microseconds | = | | | | | | between two | = | | | | | | "flowSamplingTi | = | | | | | | meInterval"s. | = | | | | | | Avalue of 100 | = | | | | | | means that the | = | | | | | | next interval | = | | | | | | starts 100 | = | | | | | | microseconds | = | | | | | | (during which | = | | | | | | no flows are | = | | | | | | sampled) after | = | | | | | | the current | = | | | | | | "flowsamplingT | = | | | | | | imeInterval" is | = | | | | | | over. For | = | | | | | | example, this | = | | | | | | Information | = | | | | | | Element may | = | | | | | | used to | = | | | | | | describe the | = | | | | | | configuration | = | | | | | | of a systemat | = | | | | | | ictime-based | = | | | | | | Sampling | = | | | | | | Selector. | = +-----+----------------+--------+---------+-------+-----------------+ = | 11 | hashFlowDomain | unsign | identif | Propo | This | = | | | ed16 | ier | sed | Information | = | | | | | | Element | = | | | | | | specifies the | = | | | | | | Information | = | | | | | | Elements that | = | | | | | | are used by the | = | | | | | | Hash-based flow | = | | | | | | Selection | = | | | | | | Selector as the | = | | | | | | Hash Domain. | = +-----+----------------+--------+---------+-------+-----------------+ = Table 3: Flow Selection methods=20 D'Antonio, et al. Expires October 25, 2012 [Page 31] = =20 Internet-Draft Flow Selection Techniques April 2012 = 8.2. Registration of Object Identifier=20 IANA will register the following OID in the IPFIX-SELECTOR-MIB=20 Functions sub-registry at http://www.iana.org/assignments/smi-numbers = according to the procedures set forth in [I-D.dkcm-ipfix-rfc5815bis]=20 Should be http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03 Btw, this draft is right now in AUTH48 See http://www.rfc-editor.org/authors/rfc6632.txt http://www.rfc-editor.org/authors/rfc6615.txt Btw, you must mention that you want a new entry under=20 Sub-registry Name: IPFIX-SELECTOR-MIB Functions See http://tools.ietf.org/html/draft-ietf-ipfix-psamp-mib-04#section-8 = for an example The text has been modified. +---------+-----------------------+---------------------+-----------+ = | Decimal | Name | Description | Reference | = +---------+-----------------------+---------------------+-----------+ = | 1 | flowSelectorAlgorithm | This Object | [RFCyyyy] | = | | | Identifier | | = | | | identifies the flow | | = | | | selection method | | = | | | (e.g., Filtering, | | = | | | Sampling) that is | | = | | | applied by the Flow | | = | | | Selection Process | | = +---------+-----------------------+---------------------+-----------+ = Table 4: Information Elements to be registered=20 You can't use the value 1. IANA will decide what is the next available value. Right. The value has been removed. Editor's Note (to be removed prior to publication): the RFC editor is = asked to replace "yyyy" in this document by the number of the RFC=20 when the assignment has been made.=20 9. Security Considerations=20 The described flow sampling techniques and the hash-based flow=20 filtering technique aim at the selection of a representative subset=20 of flows in order to make an accurate estimation of the population.=20 Not always, right? For example, it's not the goal of "Property Match Filtering" Section on Security Considerations has been rewritten. =20 An adversary may have incentives to influence the selection of flows, = for example to circumvent accounting.=20 Security considerations concerning the choice of a Hash Function for=20 Hash-based Packet Selection have been discussed in Section 6.2.3 of=20 [RFC5475] and are also appropriate for Hash-Based Flow Selection.=20 This section discussed a number of potential attacks to craft Streams = I see Observed Packet Stream and Packet Stream in RFC5475, I see Data Stream in RFC5470, but not Stream alone.=20 I guess you want to say Packet Stream that are disproportionately detected and/or discover the Hash=20 Function parameters, the vulnerabilities of different Hash Functions=20 to these attacks, and practices to minimize these vulnerabilities.=20 For other sampling approaches a user can gain knowledge about the=20 start and stop triggers in time-based systematic Sampling, e.g., by=20 sending test packets. This knowledge might allow users to modify=20 their send schedule in a way that their packets are=20 disproportionately selected or not selected. For random Sampling, a=20 cryptographically strong random number generator should be used in=20 D'Antonio, et al. Expires October 25, 2012 [Page 32] = =20 Internet-Draft Flow Selection Techniques April 2012 = order to prevent that an advisory can predict the selection decision=20 [GoRe07].=20 Further security threats can occur when Sampling parameters are=20 configured or communicated to other entities. The protocol(s) for=20 the configuration and reporting of Sampling parameters are out of=20 scope of this document. Nevertheless, a set of initial requirements=20 for future configuration and reporting protocols are stated below:=20 1. Protection against disclosure of configuration information: Flow=20 Flow -> Flow Sampling selection configuration information describes the selection=20 process and its parameters. This information can be useful to=20 attackers. Attackers may craft packets that never fit the=20 selection criteria in order to prevent flows to be seen by the=20 selection process. They can also craft a lot of packets that fit = the selection criteria and overload or bias subsequent processes. = Therefore any transmission of configuration data (e.g., to=20 configure a process or to report its actual status) should be=20 protected by encryption.=20 2. Protection against modification of configuration information: If=20 wrong configuration information is sent to the flow selection=20 process, it can lead to a malfunction of the selection process.=20 Also if wrong configuration information is reported from the=20 selection process to other processes it can lead to wrong=20 estimations at subsequent processes. Therefore any protocol that = transmits configuration information should prevent that an=20 attacker can modify configuration information. Data integrity=20 can be achieved by authenticating the data.=20 3. Protection against malicious nodes sending configuration=20 information: The remote configuration of flow selection methods=20 should be protected against access by unauthorized nodes. This=20 can be achieved by access control lists at the selection devices=20 selection devices? Do you mean IPFIX Exporter? and source authentication. The reporting of configuration data=20 from a selection process has to be protected in the same way.=20 That means that also protocols that report configuration data=20 from the selection process to other processes need to protect=20 against unauthorized nodes reporting configuration information.=20 The security threats that originate from communicating configuration=20 information to and from selection processes cannot be assessed solely = with the information given in this document. A further more detailed = assessment of security threats is necessary when a specific protocol=20 for the configuration or reporting configuration data is proposed.=20 D'Antonio, et al. Expires October 25, 2012 [Page 33] = =20 Internet-Draft Flow Selection Techniques April 2012 = 10. Acknowledgments=20 We would like to thank the IPFIX group, especially Brian Trammell,=20 Paul Aitken and Benoit Claise for fruitful discussions and for=20 proofreading the document.=20 11. References=20 11.1. Normative References=20 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=20 Requirement Levels", BCP 14, RFC 2119, March 1997.=20 [RFC5101] Claise, B., "Specification of the IP Flow Information=20 Export (IPFIX) Protocol for the Exchange of IP Traffic=20 Flow Information", RFC 5101, January 2008.=20 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.=20 Meyer, "Information Model for IP Flow Information Export", = RFC 5102, January 2008.=20 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. = Raspall, "Sampling and Filtering Techniques for IP Packet=20 Selection", RFC 5475, March 2009.=20 [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling=20 (PSAMP) Protocol Specifications", RFC 5476, March 2009.=20 11.2. Informative References=20 [Bra75] Brayer, K., "Evaluation of 32 Degree Polynomials in Error=20 Detection on the SATIN IV Autovon Error Patterns",=20 National Technical Information Service p.74, August 1975.=20 [CoHa08] Cormode, G. and M. Hadjieleftheriou, "Finding frequent=20 items in data streams", Journal, Proceedings of the Very=20 Large DataBase Endowment VLDB Endowment, Volume 1 Issue 2, = August 2008, August 2008.=20 [DuLT01] Duffield, N., Lund, C., and M. Thorup, "Charging from=20 Sampled Network Usage", ACM Internet Measurement Workshop=20 IMW 2001, San Francisco, USA, November 2001.=20 [EsVa01] Estan, C. and G,. Varghese, "New Directions in Traffic=20 Measurement and Accounting: Focusing on the Elephants,=20 Ignoring the Mice", ACM SIGCOMM Internet Measurement=20 Workshop 2001, San Francisco (CA), November 2001.=20 D'Antonio, et al. Expires October 25, 2012 [Page 34] = =20 Internet-Draft Flow Selection Techniques April 2012 = [KaPS03] Karp, R., Papadimitriou, C., and S. S. Shenker, "A simple=20 algorithm for finding frequent elements in sets and=20 bags.", ACM Transactions on Database Systems, Volume 28,=20 51-55, 2003, March 2003.=20 [MSZC10] Mai, J., Sridharan, A., Zang, H., and C. Chuah, "Fast=20 Filtered Sampling", Computer Networks Volume 54, Issue 11, = Pages 1885-1898, ISSN 1389-1286, January 2010.=20 [MaMo02] Manku, G. and R. Motwani, "Approximate Frequency Counts=20 over Data Streams", Proceedings of the International=20 Conference on Very large DataBases (VLDB) pages 346--357,=20 2002, Hong Kong, China, 2002.=20 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,=20 "Requirements for IP Flow Information Export (IPFIX)",=20 RFC 3917, October 2004.=20 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an=20 IANA Considerations Section in RFCs", BCP 26, RFC 5226,=20 May 2008.=20 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,=20 "Architecture for IP Flow Information Export", RFC 5470,=20 March 2009.=20 [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi,=20 "IP Flow Information Export (IPFIX) Mediation: Framework", = RFC 6183, April 2011.=20 [iana-ipfix-assignments]=20 "IP Flow Information Export Information Elements", 2007,=20 .=20 Authors' Addresses=20 Salvatore D'Antonio=20 University of Napoli "Parthenope"=20 Centro Direzionale di Napoli Is. C4=20 Naples 80143=20 Italy=20 Phone: +39 081 5476766=20 Email: salvatore.dantonio@uniparthenope.it=20 D'Antonio, et al. Expires October 25, 2012 [Page 35] = =20 Internet-Draft Flow Selection Techniques April 2012 = Tanja Zseby=20 CAIDA/FhG FOKUS=20 San Diego Supercomputer Center (SDSC)=20 University of California, San Diego (UCSD)=20 9500 Gilman Drive=20 La Jolla CA 92093-0505=20 USA=20 Email: tanja@caida.org=20 Christian Henke=20 Tektronix Communication Berlin=20 Wohlrabedamm 32=20 Berlin 13629=20 Germany=20 Phone: +49 17 2323 8717=20 Email: christian.henke@tektronix.com=20 Lorenzo Peluso=20 University of Napoli=20 Via Claudio 21=20 Napoli 80125=20 Italy=20 Phone: +39 081 7683821=20 Email: lorenzo.peluso@unina.it=20 D'Antonio, et al. Expires October 25, 2012 [Page 36] = =20 _____ =20 Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2012.0.1913 / Database dei virus: 2425/5036 - Data di = rilascio: 31/05/2012 ------=_NextPart_000_004A_01CD9A7C.8BB74B40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Benoit,

 

The new version of the Internet Draft on Flow = Selection Techniques has been published.

 

Answers to your comments inline.

 

Best regards,

 

Salvatore

 

Da: Benoit Claise [mailto:bclaise@cisco.com]
Inviato: venerd=EC 1 giugno 2012 12:38
A: ipfix@ietf.org; = draft-ietf-ipfix-flow-selection-tech@tools.ietf.org
Cc: ipfix-chairs@tools.ietf.org
Oggetto: New AD review of = draft-ietf-ipfix-flow-selection-tech-10.txt

 

Dear authors,

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

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

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

See in-line.


Internet = Engineering Task Force           &n= bsp;           &nb= sp;     S. D'Antonio
Internet-Draft         &= nbsp;           &n= bsp;           &nb= sp;    University of Napoli
Intended status: Standards Track           &n= bsp;           &nb= sp;    "Parthenope"
Expires: October 25, 2012           &nb= sp;           &nbs= p;            = ;   T. Zseby
           &nb= sp;           &nbs= p;            = ;            =          CAIDA/FhG FOKUS
           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;   C. Henke
           &nb= sp;           &nbs= p;            = ;      Tektronix Communication Berlin
           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;  L. Peluso
           &nb= sp;           &nbs= p;            = ;            =     University of Napoli
           &nb= sp;           &nbs= p;            = ;            =           April 23, 2012


            &= nbsp;          Flow Selection Techniques
            &= nbsp; draft-ietf-ipfix-flow-selection-tech-11.txt

Abstract

   Flow selection is the process of selecting a subset of = flows from all
   observed flows.  The Flow Selection Process may be = located at an
   observation point, or on an IPFIX Mediator.  Flow = selection reduces
   the effort of post-processing flow data and transferring = Flow
   Records.  This document describes motivations for flow selection and
   presents flow selection techniques.  It provides an information model
   for configuring flow selection techniques and discusses = what
   information about a flow selection process should be = exported.

- Be consistent with terms capitalization. Flow, = Observation Point, for example, are not capitalized in the abstract

 

Done.


The following paragraph is good and consistent with the other IPFIX = documents, but make sure you include all the terms that you need.

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


Requirements Language

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

Status of this Memo

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

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

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

   This Internet-Draft will expire on October 25, 2012.



D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;    [Page 1]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


Copyright Notice

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

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

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

























D'Antonio, et al.       Expires October = 25, = 2012           &nb= sp;    [Page 2]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


Table of Contents

   1.  Scope  . . . . . . . . . . . . . . . . . . . = . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . = . . . . . . . . .  4
   3.  Difference between Flow Selection and Packet = Selection . . . .  7
   4.  Flow selection as a Function in the IPFIX = Architecture . . . .  8
     4.1.  Flow selection during the Metering = Process . . . . . . . . 10
     4.2.  Flow selection during the Exporting Process  . . . . . . . 10
     4.3.  Flow selection as a function of the = IPFIX Mediator . . . . 10
   5.  Flow Selection Techniques  . . . . . . . . . = . . . . . . . . . 11
     5.1.  Flow Filtering . . . . . . . . . . . = . . . . . . . . . . . 11
       5.1.1.  Property Match = Filtering . . . . . . . . . . . . . . . 11
       5.1.2.  Hash-based Flow Filtering  . . . . . . . . . . . . . . 12
     5.2.  Flow Sampling  . . . . . . . . = . . . . . . . . . . . . . . 12
       5.2.1.  Systematic = sampling  . . . . . . . . . . . . . . . . . 12
       5.2.2.  Random Sampling  = . . . . . . . . . . . . . . . . . . . 13
     5.3.  Flow-state Dependent Flow = Selection  . . . . . . . . . . . 13
     5.4.  Flow-state Dependent Packet = Selection  . . . . . . . . . . 14
   6.  Configuration of Flow Selection Techniques . . . . = . . . . . . 14
     6.1.  Flow Selection Parameters  . . = . . . . . . . . . . . . . . 16
     6.2.  Description of Flow-state Dependent = Packet Selection . . . 18
   7.  Information Model for Flow Selection Configuration = and
       Reporting  . . . . . . . . . . = . . . . . . . . . . . . . . . . 18
     7.1.  flowSelectorAlgorithm  . . . . = . . . . . . . . . . . . . . 20
     7.2.  flowSelectedOctetDeltaCount  . = . . . . . . . . . . . . . . 21
     7.3.  flowSelectedPacketDeltaCount . . . . = . . . . . . . . . . . 21
     7.4.  flowSelectedFlowDeltaCount . . . . . = . . . . . . . . . . . 21
     7.5.  selectorIDTotalFlowsObserved . . . . = . . . . . . . . . . . 22
     7.6.  selectorIDTotalFlowsSelected . . . . = . . . . . . . . . . . 22
     7.7.  samplingFlowInterval . . . . . . . . = . . . . . . . . . . . 22
     7.8.  samplingFlowSpace  . . . . . . = . . . . . . . . . . . . . . 23
     7.9.  flowSamplingTimeInterval . . . . . . = . . . . . . . . . . . 23
     7.10. flowSamplingTimeSpace  . . . . . . . = . . . . . . . . . . . 24
     7.11. hashFlowDomain . . . . . . . . . . . . . = . . . . . . . . . 24
   8.  IANA Considerations  . . . . . . . . . . . . = . . . . . . . . . 24
     8.1.  Registration of Information Elements = . . . . . . . . . . . 24
     8.2.  Registration of Object = Identifier  . . . . . . . . . . . . 32
   9.  Security Considerations  . . . . . . . . . . = . . . . . . . . . 32
   10. Acknowledgments  . . . . . . . . . . . . . . . . . = . . . . . . 34
   11. References . . . . . . . . . . . . . . . . . . . . . . = . . . . 34
     11.1. Normative References . . . . . . . . . . = . . . . . . . . . 34
     11.2. Informative References . . . . . . . . . = . . . . . . . . . 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . = . . . . 35

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









D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;    [Page 3]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


1.  Scope

   This document describes flow selection techniques for = network traffic
   measurements.  A flow is defined as a set of packets = with common
   properties as described in [RFC5101].  Flow selection = can be done to
   limit the resource demands for capturing, storing, = exporting and
   post-processing of Flow Records.  It also can be used = to select a
   particular set of flows that are of interest to a specific =
   application.  This document provides a categorization = of flow
   selection techniques and describes configuration and = reporting
   parameters for them.  In order to be compliant with = this document, at
   least one of the flow selection schemes MUST be = implemented.  That
   means that the configuration parameters as well as the = reporting
   Information Elements for this particular scheme MUST be = supported.

Last sentence could be fine, but express that the = way to configure the Intermediate Flow Selection Process is out of scope of = this document.

 

Ok, the sentence has been removed.


   This document also addresses configuration and reporting parameters
   for flow-state dependent packet selection as described in [RFC5475],
   although this technique is categorized as packet = selection.  The
   reason is that flow-state dependent packet selection = techniques often
   aim at the reduction of resources for flow capturing and = flow
   processing.  Furthermore, they were only briefly = discussed in

Not sure what "they" refers to

 

Fixed.



   [RFC5475].  Therefore we included configuration and reporting
   considerations for such techniques in this document. =


please remove "we", "us", "our" from the = draft.

Done.



2.  Terminology

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


   * Packet Classification

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


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

Packet Classification is a function of the Metering = Process.

 

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

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

Your interpretation is correct.


   * Packet Aggregation Process

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

How is this different from the Metering = Process?

The definition of Packet Aggregation Process has been = removed.

 

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



D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;    [Page 4]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   * Flow Selection Process

      A Flow Selection Process takes Flow = Records as its input and
      selects a subset of this set as its output.  A Flow Selection
      Process MAY run in several places within = the IPFIX architecture.
      A Flow Selection Process MAY be part of = an IPFIX Metering Process,
      Exporting Process or as an Intermediate Selection Process as
      defined for the IPFIX Mediator [RFC6183]. =


If you look at the RFC6235, you will see 

=A0=A0 Intermediate Anonymization Process:=A0=A0 An intermediate =
process that
=A0=A0=A0=A0=A0 takes Data Records and =
transforms them into Anonymized =
Data
=A0=A0=A0=A0=A0 =
Records.
 

To be perfect = correct, the correct way is like it's done in http://tools.= ietf.org/html/draft-ietf-ipfix-a9n-03

=A0=A0 Intermediate Aggregation Process:=A0=A0 an Intermediate =
Process as in
=A0=A0=A0=A0=A0 [RFC6183] that aggregates records, based upon a set =
of Flow Keys
=A0=A0=A0=A0=A0 or functions applied =
to fields from the record.

What should be done here is 

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

Btw, you will see that "Intermediate Flow = Selection Process" is already defined in the figure where you get it = right.

Finally, your sentence "A Flow Selection Process MAY be part of an = IPFIX Metering Process,  Exporting Process or as an Intermediate = Selection Process as
defined for the IPFIX Mediator [RFC6183]. ":
- must contain "A Intermediate Flow Selection Process MAY be part = of an IPFIX Metering Process ..."
- must be reflected in figure 1, where I only see the Intermediate Flow Selection Process in the IPFIX Mediator. Could also be present in = Exporting Process and in the Metering Process. As figure 1 is the only figure, all possibilities must be displayed. See as an example http://tools.= ietf.org/html/draft-ietf-ipfix-a9n-03 figure 1

A new definition of Intermediate Flow = Selection Process and a new figure have been included in the Draft.. =


   * Flow Selection State

      A Flow Selection Process SHOULD maintain = state information for use

normally, we try to avoid MAY/SHOULD/MUST in = definition

 

Fixed



      by the Flow = Selector.  At a given time, the Flow Selection State
      may depend on flows and packets observed = at and before that time,
      as well as other variables.  = Examples include:

        (i)   sequence = number of packets and accounted Flow Records;

        (ii)  number of selected = flows;

        (iii) number of observed = flows;

        (iv)  current flow cache occupancy;

        (v)   flow specific counters, lower and upper bounds;

        (vi)  flow selection = timeout intervals.

   * Flow Selector

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

        (i)   the content = of the Flow Record;

        (ii)  any state = information related to the Metering Process or
            &= nbsp; Exporting Process;

        (iii) any Flow Selection = State that may be maintained by the
            &= nbsp; Flow Selection Process.

I see many terms: 

Packet Classification, Packet Aggregation Process, Flow Selection =
Process, Flow Selection State, Intermediate Process, Intermediate =
Selection Process, etc...

Please have a new figure that put combines all = these terms. Something such as the figure in section 3.1 from http://tools.ietf.org/html/rf= c5474
It might be your figure 1, but I don't even see those terms in there, or = figure 3 in http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10=

Figure 1 has been modified to address this = comment.

 

   * Complete Flow

      A Complete Flow consists of all the = packets that enter the Flow
      Selection Process within the flow = time-out interval, and which
      belong to the same flow as defined by the = flow definition in



D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;    [Page 5]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


      [RFC5470].  For this definition only packets that arrive at the
      Flow Selection Process are = considered.  That means, packets that
      are not observed at the Flow Selection = Process because of prior
      packet selection or packet loss are not considered as belonging to
      the Complete Flow.

what does the second sentence add?

The second sentence = has been removed.


   * Flow Filtering

      Flow Filtering selects flows based on a deterministic function on
      the Flow Record content, Flow Selection = State, external properties
      (e.g. ingress interface) or external = events (e.g violated Access
      Control List).  If the relevant = parts of the Flow Record content
      can already be observed at packet level (e.g.  Flow Keys from
      packet header fields) Flow Filtering can = be performed at packet
      level by Property Match Filtering as = described in [RFC5475].



   * Hash-based Flow Filtering

      Hash-based Flow Filtering is a = deterministic flow filter function
      that selects flows based on a Hash Function.  The Hash Function is
      calculated over parts of the Flow Record = content or external
      properties which are called the Hash Domain.  If the hash value
      falls into a predefined Hash Selection = Range the flow is selected.
      Hash-based Flow Filtering can already = applied at packet level, in
      which case the Hash Domain MUST contain = the Flow Key of the
      packet.  In case Hash-based Flow = Filtering is used to select the
      same subset of flows at different = observation points, the Hash
      Domain MUST comprise parts of the packet = or flow thar are
      invariant on the packet/flow path.  = Also refer to the according
      Trajectory Sampling Application Example = on packet level in
      [RFC5475]

   * Flow-state Dependent Flow Selection

      Flow-state Dependent Flow Selection is a selection function that
      selects or drops flows based on the = current Flow Selection State.
      The selection can be either = deterministic, random or non-uniform
      random.

   * Flow-state Dependent Packet Selection

      Flow-state Dependent Packet Selection is = a selection function that
      selects or drops packets based on the = current Flow Selection
      State.  The selection can be either deterministic, random or non-
      uniform random.  Flow-state = Dependent Packet Selection can be used
      to prefer the selection of packets = belonging to specific flows.
      For example the selection probability of = packets belonging to
      flows that are already within the Flow = Cache may be higher than



D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;    [Page 6]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


      for packets that have not been recorded = yet.

   * Flow Sampling

      Flow Sampling selects flows based on Flow = Record sequence or
      arrival times (e.g. entry in flow cache, = arrival time at Exporter
      or Mediator).  The selection can be systematic (e.g. every n-th
      flow) or based on a random function (e.g. = select each Flow Record
      with probability p, or randomly select n = out of N Flow Records).


3.  Difference between Flow Selection and Packet Selection

   Flow selection differs from packet selection described in [RFC5475].

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

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

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

I don't understand the last sentence.

An example has been = added to clarify the sentence.


   -       Flow selection = operates on Complete Flows.  That means that
           after the = Flow Selection Process either all packets of the
           flow are = kept or all packets of the flow are discarded.  That
           means that = if the flow selection is preceded by a packet
           selection = process the Complete Flow consists only of the
           packets = that were not discarded during the packet selection.

   There are some techniques that are difficult to = unambiguously
   categorize into one of the categories.  Here we give = some guidance
   how to categorize such techniques:

   -       Techniques that can = be considered as both packet and flow
           selection: = some packet selection techniques result in the
           selection = of Complete Flows and therefore can be considered
           as packet = or as flow selection at the same time.  An example
           is Property = Match Filtering of all packets to a specific
           destination address.  If flows are defined based on
           destination addresses, such a packet selection also results
           in a flow selection and can be considered as packet or flow



D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;    [Page 7]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


           selection. =

   -       Flow-state Dependent = Packet Selection (as described in
           [RFC5475]): = there exist techniques that select packets based
           on the flow = state, e.g. based on the number of already
           observed = packets belonging to the flow.  Examples of these
           techniques = from the literature are "Sample and Hold" [EsVa01]
           "Fast Filtered Sampling" [MSZC10] or the "Sticky Sampling"
           algorithm presented in [MaMo02].  Such techniques can be used
           to = influence which flows are captured (e.g. increase the
           selection = of packets belonging to large flows) and reduce the
           number of = flows that need to be stored in the flow cache.
           = Nevertheless, such techniques do not necessarily select
           Complete = Flows, because they do not ensure that all packets
           of a = selected flow are captured.  Therefore Flow-state
           Dependent = Packet Selection methods that do not ensure that
           either all = or no packets of a flow are selected strictly
           speaking = have to be considered as packet selection techniques
           and not as = flow selection techniques.


4.  Flow selection as a Function in the IPFIX Architecture

   Figure 1 shows the IPFIX reference model as defined in = [RFC5470] and
   shows the Packet Classification and Packet Aggregation = Process in the
   Metering Process.

























D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;    [Page 8]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


           &nb= sp;           Packet(s) coming in to Observation Point(s)
           &nb= sp;           &nbs= p; |            =             &= nbsp;            |
           &nb= sp;           &nbs= p; v            =             &= nbsp;            v
        +----------------+---------------------------+   = +-----+-------+
        |          Metering Process           =        |   = |            = |
        |            =             &= nbsp;           &n= bsp;       |   |            = |
        |   packet = header capturing          &nbs= p;       |   = |            = |
        |        |            =             &= nbsp;          |...| Metering    |
        |   timestamping          &= nbsp;           &n= bsp;      |   | Process N   |
        |        |            =             &= nbsp;          |   |            = |
        |   packet sampling           = ;            =    |   = |            = |
        |        |            =             &= nbsp;          |   |            = |
        |   (packet = classification)         &nbs= p;        |   |            = |
        |        |            =             &= nbsp;          |   |            = |
        |   packet filtering*          &nb= sp;           &nbs= p; |   = |            = |
        |        |            =             &= nbsp;          |   = |            = |
        |   (packet aggregation)*          =           |   = |            = |
        |        |            =             &= nbsp;          |   |            = |
        +--------|-----------------------------------+   = +-----|-------+
            = Flow Records           =             &= nbsp;           Flow Records

       &nbs= p;         |            =             &= nbsp;           &n= bsp;        |

       &nbs= p;         +----------------------+----------------------+
           &nb= sp;           &nbs= p;            = ;    |
           &nb= sp;     +----------------------|-----------------+
           &nb= sp;     | Exporting Process*           = ;          |
           &nb= sp;     +----------------------+-----------------+
           &nb= sp;           &nbs= p;            = ;    |  IPFIX (Flow Records)
           &nb= sp;           &nbs= p;            = ;    v
           &nb= sp;  +-------------------------|-----------------------+
           &nb= sp;  |  IPFIX Mediator         |            =            |
           &nb= sp;  |            =              v            =            |
           &nb= sp;  |            =    Collecting = Process(es)          &n= bsp; |
           &nb= sp;  |            =              |            =            |
           &nb= sp;  |      Intermediate Flow Selection Process (*)    |
           &nb= sp;  |            =              |            =            |
           &nb= sp;  |            =    Exporting Process(es) (*)           &nbs= p; |
           &nb= sp;  +-------------------------|-----------------------+
           &nb= sp;           &nbs= p;            = ;    v
           &nb= sp;           &nbs= p;            = ;  IPFIX

         (*) indicates where = flow selection can take place.

            = Figure 1: Flow selection in the IPFIX Architecture

Please express the physical boundary between the = Exporter and the IPFIX Mediator

Why is packet classification in brackets?
(packet aggregation), do you mean the Intermediate Aggregation Process = in http://tools.= ietf.org/html/draft-ietf-ipfix-a9n-03?

The figure has been completely = changed.


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




D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;    [Page 9]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   1.  during the Metering Process

   2.  during Exporting Process(es)

   3.  during an Intermediate Selection Process on a = Mediator

It's not "during" but "in". =

 

Fixed.


Please display the 3 points above in the figure

Done.

 


4.1.  Flow selection during the Metering Process


   In the Packet Aggregation Process the packet information is = used to
   update the Flow Records in the flow cache.  Flow = selection that is
   applied before aggregation equals a packet selection process.  The
   flow still consists of individual packets.  Those are = then selected
   based on the classification information, i.e. based on the = flow they
   belong to.  Flow selection before aggregation can be = based on the
   fields of the Flow Key (also on a hash value over these = fields), but
   not based on characteristics that are only available after = packet
   aggregation (e.g. flow size, flow duration).  Flow = selection during
   the Metering Process is applied to reduce resources for all =
   succeeding processes or to select specific flows of = interest in case
   such flow characteristics are already observable at packet = level
   (e.g. flows to specific IP addresses).  In contrast, Flow-state
   Dependent Packet Selection is a packet selection method, = because it
   does not necessarily select Complete Flows.

4.2.  Flow selection during the Exporting Process

   The Flow Selection Process at the Exporter is similar to an =
   Intermediate Selection Process as described in [RFC6183] = and works on
   Flow records.  Flow selection during the Exporting = Process can
   therefore also depend on flow characteristics that are only visible
   after the aggregation of packets, such as flow size and = flow
   duration. 

Why can't this be done in the Metering Process as = well?

Changes have been made to section 4.2 to address this = comment.



The Exporting Process may implement policies for = exporting
   only a subset of the Flow Records which have been stored in = the
   system memory in order to unload flow export and flow post- =
   processing.  Flow selection during the Exporting = Process may select
   only the subset of Flow Records which are of interest to = the users
   application, or select only as many Flow Records as can be = handled by
   the available resources (e.g. limited export link = capacity).

4.3.  Flow selection as a function of the IPFIX Mediator

   As shown in Figure 1, flow selection can be performed as an =

Please rewrite these section 4.* based on the = Intermediate Flow Selection Process, and not flow selection, which is not = defined.

 

Done.



   Intermediate Process within an IPFIX = Mediator [RFC6183].  The
   Intermediate Selection Process takes Flow Record stream as = its input
   and selects Flow Records from a sequence based upon = criteria-
   evaluated record values.  The Intermediate Selection = Process can
   again apply a flow selection technique to obtain flows of = interest to
   the application.  Further, the Intermediate Selection = Process can



D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 10]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   base its selection decision on the correlation of data from different
   observation points,

or most of the time Exporters (which btw, you = should show this in the figure)
See figure A in RFC 6183

Observation Points replaced by = Exporters.

 

e.g. by only selecting flows that were at least =
   recorded on two observation points.





5.  Flow Selection Techniques

   A flow selection technique selects either all or none of = the packets

I see sometimes flow selection, sometimes flow = selection technique, sometimes selection technique, sometimes flow selection = scheme, sometimesflow selection methods, sometimes Flow Selection Process which = should really be the Intermediate Flow Selection Process...
It's difficult to read the draft, as it misses some cohesion: this = clearly shows that different parts of the document have been written by = different persons.
Please review the entire document with a fresh mind, as if you would = discover for the first time, and you will see what I mean.
The entire draft needs some improvements on that matter.

 

The document has been reviewed.

The terms “scheme” and “method” = replaced by technique.




   of a flow, otherwise the technique has = to be considered as packet
   selection.  We distinguish between Flow Filtering and = Flow Sampling.

5.1.  Flow Filtering

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

This contradicts.

=A0=A0 In order to be compliant with this document, =
at
=A0=A0 least one of the flow selection schemes =
MUST be implemented.
 
Ok, agreed. The contradiction has been =
fixed.




 
5.1.1.  Property Match =
Filtering 



   Property Match Filtering can be performed similarly to =
Property Match 

   Filtering for packet selection described in =
[RFC5475].  The 

   difference is that, instead of packet fields, Flow Record =
fields are 

   here used to derive the selection decision.  Property =
Match Filtering 

   is typically used to select a specific subset of the flows =
that are 

   of interest to a particular application (e.g. all flows to =
a specific 

   destination, all large flows, etc.).  Properties on =
which the 

   filtering is based can be Flow Keys, Flow Timestamps, or =
Per-Flow 

   Counters described in [RFC5102].  Examples of =
properties are the flow 

   size in bytes, the number of packets in the flow, the =
observation 

   time of the first or last packet, or the maximum packet =
length.  An 

   example is to select flows with more than a threshold =
number of 

   observed octets.  The selection criteria can be a =
specific value, a 

   set of specific values, or an interval.  For example, =
a flow is 

   selected if destinationIPv4Address and the total number of =
packets of 

   the flow equal two predefined values.  Property Match =
Filtering can 

   be applied during the Metering Process if the properties =
are already 

   observable at the packet level (e.g.  Flow Key =
fields).  For example, 

   a flow is selected if sourceIPv4Address and =
sourceIPv4PrefixLength 

   equal, respectively, two specific values. 



   There are content-based Property Match Filtering techniques =
that 

   require a computation on the current flow cache.  An =
example is the 

   selection of the largest flows or a percentage of flows =
with the 

   longest lifetime.  This type of Property Match =
Filtering is also used 

   in flow selection techniques that react to external events =
(e.g. 







D'Antonio, et al.       Expires October =
25, =
2012           &nb=
sp;   [Page 11] 

=A0

Internet-Draft          =
Flow Selection =
Techniques          &nb=
sp;  April 2012 





   resource constraint).  For example when the flow cache =
is full, the 

   Flow Record with the lowest flow volume per current flow =
life time 

   may be deleted. 



5.1.2.  Hash-based Flow Filtering 



   Hash-based Flow Filtering uses a Hash Function h to map the =
Flow Key 

   c onto a Hash Range R. A flow is selected if the hash value =
h(c) is 

   within the Hash Selection Range S, which is a subset of R. =
Hash-based 

   Flow Filtering can be used to emulate a random sampling =
process but 

   still enable the correlation between selected flow subsets =
at 

   different observation points.  Hash-based Flow =
Filtering is similar 

   to Hash-based Packet Selection, and in fact is identical =
when Hash- 

   based Packet Selection uses the Flow Key that defines the =
flow as the 

   hash input.  Nevertheless there may be the incentive =
to apply Hash- 

   based Flow Filtering not on the packet level during the =
Metering 

   Process, for example when the size of the selection range =
and 

   therefore the sampling probability is dependent on the =
number of 

   observed flows. 



5.2.  Flow Sampling 



   Flow Sampling operates on Flow Record sequence or arrival =
times.  It 

   can use either a systematic or a random function for the =
selection 

   process.  Flow Sampling usually aims at the selection =
of a 

   representative subset of all flows in order to estimate =


   characteristics of the whole set (e.g. mean flow size in =
the 

   network). 



5.2.1.  Systematic sampling 



   Systematic sampling is a deterministic selection function. =


   Systematic sampling may be a periodic selection of the N-th =
Flow 

   Record which arrives at the Exporting or Intermediate =
Selection 

   Process. 

Intermediate Flow Selection Process

Systematic sampling MAY be applied during the = Metering
   Process.  An example would be to create, besides the = Flow cache of
   selected flows, an additional data structure that saves the = Flow Keys
   of the flows that are not selected.  The selection of = a flow would
   then be based on the first packet of a flow.  = Everytime a packet
   belonging to a new flow (which is neither in the data = structure of
   the selected or not selected flows) arrives at the = measurement point,

what is a measurement point?

Measurement point replaced with Observation = Point.

 

   a counter is increased.  In case = the counter is increased to a
   multiple of N a new flow cache entry is created, and in = case the
   counter is not a multiple of N the Flow Key is added to the = data
   structure for not selected flows.

   Systematic sampling can also be time-based.  = Time-based systematic
   sampling is applied by only creating flows that are = observed between

flows -> Flows all over the doc.

Done.


D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 12]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   time-based start and stop triggers.  The time interval = may be applied
   at packet level during the Metering Process or after = aggregation on
   flow level, e.g. by selecting a flow arriving at the = Exporting
   Process every n seconds.

5.2.2.  Random Sampling

   Random flow sampling is based on a random process which = requires the
   calculation of random numbers.  One can differentiate = between n-out-N
   and probabilistic flow sampling.

5.2.2.1.  n-out-of-N Flow Sampling

   In n-out-of-N Sampling, n elements are selected out of the = parent
   population that consists of N elements.  One example = would be to
   generate n different random numbers in the range [1,N] and = select all
   flows that have a flow position equal to one of the random numbers.

5.2.2.2.  Probabilistic Flow Sampling

   In probabilistic Sampling, the decision whether or not a = flow is
   selected is made in accordance with a predefined selection =
   probability.  For probabilistic Sampling, the Sample = Size can vary
   for different trials.  The selection probability does = not necessarily
   have to be the same for each flow.  Therefore, we = distinguish between
   uniform probabilistic sampling (with the same selection probability
   for all flows) and non-uniform probabilistic sampling = (where the
   selection probability can vary for different flows).  = For non-uniform
   probabilistic Flow Sampling the sampling probability may be adjusted
   according to the Flow Record content.  An example = would be to
   increase the selection probability of large volume flows = over small
   volume flows as described in the Smart Sampling technique [DuLT01].

5.3.  Flow-state Dependent Flow Selection

   Flow-state Dependent Flow Selection can be a deterministic = or random
   flow selection process based on the Flow Record content and = the flow
   state which may be kept additionally for each of the = flows.  External
   processes may update counters, bounds and timers for each = of the Flow
   Records and the Flow Selection Process utilises this = information for
   the selection decision.  A review of Flow-state = Dependent Flow
   Selection techniques that aim at the selection of the most frequent
   items by keeping additional flow state information can be = found in
   [CoHa08].  Flow-state Dependent Flow Selection can = only be applied
   after packet aggregation, when a packet has been assigned = to a flow.
   The selection process then decides based upon the flow = state for each
   flow if it is kept in the flow cache or not.  Two Flow = State
   Dependent Flow Selection Algorithms are here described: =



D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 13]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   The frequent algorithm [KaPS03] is a technique that aims at = the
   selection of all flows that at least exceed a 1/k fraction = of the
   Observed Packet Stream. 

to come back to one of my previous point, please = add Observed Packet Stream to the extra figure

The algorithm has only a flow cache of size
   k-1 and each flow in the cache has an additional = counter.  The
   counter is incremented each time a packet belonging to the = flow in
   the flow cache is observed.  In case the observed = packet does not
   belong to any flow all counters are decremented and if any = of the
   flow counters has a value of zero the flow is replaced with = a flow
   formed from the new packet.

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

5.4.  Flow-state Dependent Packet Selection

   Flow-state Dependent Packet Selection is not a flow = selection
   technique but a packet selection technique.  = Nevertheless we will
   describe configuration and reporting parameters for this = technique in
   this document.  An example is the "Sample and = Hold" algorithm
   [EsVa01] that tries to prefer large volume flows in the = selection.
   When a packet arrives it is selected when a Flow Record for = this
   packet already exists.  In case there is no Flow = Record, the packet
   is selected by a certain probability that is dependent on = the packet
   size.


6.  Configuration of Flow Selection Techniques

   This section describes the configuration parameters of the = flow
   selection techniques presented above.  It provides the = basis for an
   information model to be adopted in order to configure the = Flow
   Selection Process within an IPFIX Device.  The actual = information
   model with the Information Elements (IEs) for the = configuration is
   described together with the reporting IEs in section = 7.  The
   following table gives an overview of the defined selection =
   techniques, where they can be applied and what their input parameters
   are.  Depending on where the flow selection techniques = are applied
   different input parameters can be configured.

   Overview of Flow Selection Techniques:



D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 14]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   +------------------+-----------------+------------------------------+ =
   | = Location         | Selection       | Selection Input           &n= bsp;  |
   |            =       | Method          |            =             &= nbsp;     |
   +------------------+-----------------+------------------------------+ =
   | During the       | Flow-state      | packet sampling           = ;   |

location is not "during" but = "in"

 

Fixed.



   | = Metering Process | Dependent       | probabilities, Flow          | =
   | based on Packets | Packet          | Selection = State, packet      |
   |            =       | Selection       | properties          &nb= sp;        |

I still don't get why "in the Metering = Process" means, on packets?

 

“On packets” has been = removed.



   +------------------+-----------------+------------------------------+ =

should

   |            =       | Property Match  | Flow record IEs, Selection   | =
   |            =       | Flow Filtering  | Interval           = ;          |
   = +------------------+-----------------+------------------------------+
   |            =       | Hash-based Flow | selection range, Hash        |
   |            =       | Filtering       | Function, Flow Key, (seed)   |
   = +------------------+-----------------+------------------------------+
   |            =       | Time-based      | flow position (derived = from  |
   |            =       | Systematic Flow | arrival time of packets),    | =
   |            =       | Sampling        | flow selection state         |
   +------------------+-----------------+------------------------------+ =
   |            =       | Sequence-based  | flow position (derived from  |
   |            =       | Systematic Flow | packet position), = flow       |
   |            =       | Sampling        | selection state           &n= bsp;  |
   +------------------+-----------------+------------------------------+ =
   |            =       | Random Flow     | random number generator = or   |
   |            =       | Sampling        | list and packet position,    |
   |            =       |            =      | flow = state           &n= bsp;       |
   +------------------+-----------------+------------------------------+ =

This location above applies to the 6 column, right? = so make a big cell out for "in the Metering Process based on = packets"
Same remark below.
I was not able to create a big cell = applying to the 6 columns. I simply used the same text in the 6 columns.

   | = Exporting /      | Property Match  | Flow Record = content, filter  |
   | Intermediate     | Flow = Filtering  | function           = ;          |
   | Selection        |            =      |            =             &= nbsp;     |
   | Process          |            =      |            =             &= nbsp;     |
   +------------------+-----------------+------------------------------+ =
   |            =       | Hash-based Flow | selection range, Hash        |
   |            =       | Filtering       | Function, hash input (Flow   |
   |            =       |            =      | Keys and other = flow          |
   |            =       |            =      | = properties)          &n= bsp;       |
   = +------------------+-----------------+------------------------------+
   |            =       | Flow-state      | flow state parameters,       |
   |            =       | Dependent Flow  | random number generator or   | =
   |            =       | Selection       | list           &nb= sp;           &nbs= p; |
   = +------------------+-----------------+------------------------------+
   |            =       | Time-based      | flow arrival time, flow      |
   |            =       | Systematic Flow | state           &n= bsp;            |
   |            =       | Sampling        |            =             &= nbsp;     |
   +------------------+-----------------+------------------------------+ =
   |            =       | Sequence-based  | flow position, flow state    | =
   |            =       | Systematic Flow |            =             &= nbsp;     |
   |            =       | Sampling        |            =             &= nbsp;     |



D'Antonio, et al.       Expires = October 25, 2012           &nb= sp;   [Page 15]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   |            =       | Random Flow     | random number generator = or   |
   |            =       | Sampling        | list and flow = position, flow |
   |            =       |            =      | = state           &n= bsp;            |
   +------------------+-----------------+------------------------------+ =

Not sure what the "flow position".
Below, you use "Spacing" for this concept.


           &nb= sp;  Table 1: Overview of Flow Selection Techniques

6.1.  Flow Selection Parameters

   In this section, we define what parameters are required to describe
   the most common Flow Selection techniques.

You see, yet another new term, which is not in the terminology: Flow Selection
And on the top of my head, it was not defined in any other documents = referenced in the terminology

 

The section title has been changed.


   Flow Selection Parameters:

   For Property Match Filtering:

   -   Information Element as specified in [iana-ipfix-assignments]):
       Specifies the Information Element = which is used as the property
       in the filter expression.

   -   Selection Value or Value Interval:
       Specifies the value or interval of = the filter expression.
       Packets and Flow Record that have a = value equal to the Selection
       Value or within the Interval will = be selected.

   For Hash-based Flow Filtering:

   -   Hash Domain:
       Specifies the bits from the packet = or flow which are taken as the
       hash input to the Hash Function. =

   -   Hash Function:
       Specifies the name of the Hash = Function that is used to calculate
       the hash value.  Possible Hash Functions are BOB [RFC5475], IPSX
       [RFC5475], CRC-32 [Bra75]

   -   Hash Selection Range:
       Flows that have a hash value within = the Hash Selection Range are
       selected.  The Hash Selection = Range can be a value interval or
       arbitrary hash values within the = Hash Range of the Hash Function.

   -   Random Seed or Initializer Value:
       Some Hash Functions require an initializing value.  In order to
       make the selection decision more = secure one can choose a random
       seed that configures the hash = function.

   For Flow-state Dependent Flow Selection:




D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 16]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   -   frequency threshold:
       Specifies the frequency threshold s = for flow state dependent flow
       selection techniques that try to = find the most frequent items
       within a dataset.  All flows = which exceed the defined threshold
       will be selected.

   -   accuracy parameter:
       specifies the accuracy parameter e = for techniques that deal with
       the frequent items problems.  = The accuracy parameter defines the
       maximum error, i.e. no flows that = have a true frequency less than
       ( s - e) N are selected, where s is = the frequency threshold and N
       is the total number of packets. =

   The above list of parameters for Flow-state Dependent Flow Selection
   techniques is suitable for the presented frequent item and = lossy
   counting algorithms.  Nevertheless a variety of = techniques exist with
   very specific parameters which are not defined here.

   For Systematic time-based Flow Sampling:

   -   Interval length (in usec)
       Defines the length of the sampling interval during which flows
       are selected.

   -   Spacing (in usec)
       The spacing parameter defines the = spacing in usec between the end
       of one sampling interval and the = start of the next succeeding
       interval.

   For Systematic count-based Flow Sampling:

   -   Interval length
       Defines the number of flows that = are selected within the sampling
       interval.

   -   Spacing
       The spacing parameter defines the = spacing in number of observed
       flows between the end of one = sampling interval and the start of
       the next succeeding interval.

   For random n-out-of-N Flow Sampling:

   -   Population Size N
       The Population Size N is the number = of all flows in the
       Population from which the sample is = drawn.






D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 17]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   -   Sampling Size n
       The sampling size n is the number = of flows that are randomly
       drawn from the population N.

   For probabilistic Flow Sampling:

   -   Sampling probability p
       The sampling probability p defines = the probability by which each
       of the observed flows is selected. =

6.2.  Description of Flow-state Dependent Packet Selection

   The configuration of Flow-state Dependent Packet Selection = has not
   been described in [RFC5475] therefore the parameters are = defined
   here:

   For Flow-state Dependent Packet Selection:

   -   packet selection probability per possible = flow state interval
       Defines multiple {flow interval, = packet selection probability}
       value pairs that configure the = sampling probability depending on
       the current flow state.

   -   additional parameters
       For the configuration of flow state dependent packet selection
       additional parameters or packet = properties may be required, e.g.
       the packet size ([EsVa01])


7.  Information Model for Flow Selection Configuration and = Reporting

   In this section we describe Information Elements (IEs) that = MUST be

This section specifies ...

Modified.

 

   exported by a flow selection process = in order to support the

Flow Selection Process

 

Done



   interpretation of measurement results = from flow measurements where
   only some flows are selected. 

"from flow measurements where only some flows = are selected. "
Do you need that?  Isn't it by default what a Flow Selection = Process does?

 

Right. The sentence has been = removed.

 



The information is mainly used to
   report how many packets and flows have been observed in = total and how
   many of them were selected.  This helps for instance = to calculate the
   Attained Selection Fraction (see also [RFC5476]), which is = an
   important parameter to provide an accuracy statement.  = The IEs can
   provide reporting information about Flow Records, packets = or bytes.
   The reported metrics are total number of elements and the = number of
   selected elements.  From this the number of dropped = elements can be
   derived.  All counters SHOULD be exported and reset = when a new
   measurement interval starts.

I disagree here. It depends which IEs you use: = deltaCounter or totalCounter
Search for those two terms in http://www.iana.= org/assignments/ipfix/ipfix.xml

In order to avoid ambiguity, this sentence = has been removed.


   List of Flow Selection Information Elements:





D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 18]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   +------+-------------------------+-------+--------------------------+ =
   | ID   | Name           &nb= sp;        | ID    | Name           &nb= sp;         |
   +------+-------------------------+-------+--------------------------+ =
   | 301  | = selectionSequenceID     | 302   | selectorID          &nb= sp;    |
   = +------+-------------------------+-------+--------------------------+
   | TBD1 | flowSelectorAlgorithm   | 1     | octetDeltaCount          | =
   +------+-------------------------+-------+--------------------------+ =
   | TBD2 | flowSelectedOctetDeltaC | = 2     | packetDeltaCount         | =
   |      | ount           &nb= sp;        |       |            =             &= nbsp; |
   +------+-------------------------+-------+--------------------------+ =
   | TBD3 | flowSelectedPacketDelta | = 3     | originalFlowsPresent     |
   |      | Count           &n= bsp;       |       |            =             &= nbsp; |
   +------+-------------------------+-------+--------------------------+ =
   | TBD4 | flowSelectedFlowDeltaCo | TBD5  | selectorIDTotalFlowsObse |
   |      | unt           &nbs= p;         |       | rved           &nb= sp;         |
   +------+-------------------------+-------+--------------------------+ =
   | TBD6 | selectorIDTotalFlowsSel | TBD7  | samplingFlowInterval     |
   |      | ected           &n= bsp;       |       |            =             &= nbsp; |
   +------+-------------------------+-------+--------------------------+ =
   | TBD8 | = samplingFlowSpace       | 309   | samplingSize          &= nbsp;  |
   +------+-------------------------+-------+--------------------------+ =
   | 310  | = samplingPopulation      | 311   | samplingProbability      | =
   +------+-------------------------+-------+--------------------------+ =
   | TBD9 | flowSamplingTimeInterva | TBD10 | flowSamplingTimeSpace    |
   |      | l            =            |       = |            =             &= nbsp; |
   +------+-------------------------+-------+--------------------------+ =
   | 326  | digestHashValue         | TBD11 = | hashFlowOffset          = ; |
   +------+-------------------------+-------+--------------------------+ =
   | TBD1 | = hashFlowSize          &= nbsp; | 329   | = hashOutputRangeMin       |
   | 2    |            =              |       = |            =             &= nbsp; |
   +------+-------------------------+-------+--------------------------+ =
   | 330  | = hashOutputRangeMax      | 331   | hashSelectedRangeMin     | =
   +------+-------------------------+-------+--------------------------+ =
   | 332  | hashSelectedRangeMax    | 333   | hashDigestOutput         | =
   +------+-------------------------+-------+--------------------------+ =
   | 334  | hashInitialiserValue    | 320   | absoluteError          =   |
   +------+-------------------------+-------+--------------------------+ =
   | 321  | relativeError          = | 336   | upperCILimit          &= nbsp;  |
   = +------+-------------------------+-------+--------------------------+
   | 337  | lowerCILimit          &= nbsp; | 338   | confidenceLevel          | =
   +------+-------------------------+-------+--------------------------+ =

            &= nbsp;  Table 2: Flow Selection Information Elements








D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 19]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


7.1.  flowSelectorAlgorithm

   Description:

      This Information Element identifies the = flow selection
      method(e.g., Filtering, Sampling) that is applied by the Flow
      Selection Process.  Most of these = methods have parameters as
      decribed in Section 6.  Further = Information Elements are needed to
      fully specify packet selection with these methods and all their
      parameters. 

Why do you speak about "packet selection" = in the flowSelectorAlgorithm?

 

 

Fixed.

 

Further method identifiers may be added to the list =
      below.  It might be necessary to = define new Information Elements
      to specify their parameters.  The flowSelectorAlgorithm registry
      is maintained by IANA.  New = assignments for the registry will be
      administered by IANA and are subject to = Expert Review [RFC5226].
      The registry can be updated when = specifications of the new
      method(s) and any new Information = Elements are provided.


   = +----+------------------------+--------------------------+
   | ID |        Method          |      Parameters          | =
   = +----+------------------------+--------------------------+
   | 1  | Systematic count-based | flowSamplingInterval     |
   |    | Sampling           = ;    | flowSamplingSpace        | =
   = +----+------------------------+--------------------------+
   | 2  | Systematic time-based  | flowSamplingTimeInterval |
   |    | Sampling           = ;    | flowSamplingTimeSpace    |
   = +----+------------------------+--------------------------+
   | 3  | Random = n-out-of-N      | samplingSize          &= nbsp;  |
   |    | Sampling           = ;    | samplingPopulation       |
   = +----+------------------------+--------------------------+
   | 4  | Uniform probabilistic  | samplingProbability      |
   |    | Sampling           = ;    |            =             &= nbsp; |
   = +----+------------------------+--------------------------+
   | 5  | Property Match         | Information Element      |
   |    | Filtering          &nbs= p;   | Value Range           &n= bsp;  |
   = +----+------------------------+--------------------------+
   |   Hash-based Filtering      | hashInitialiserValue     |
   +----+------------------------+ hashFlowDomain          = ; |
   | 6  | using BOB           &nbs= p;  | hashSelectedRangeMin     |
   +----+------------------------+ hashSelectedRangeMax     |
   | 7  | using IPSX           &nb= sp; | hashOutputRangeMin       |
   +----+------------------------+ hashOutputRangeMax       |
   | 8  | using CRC           &nbs= p;  |            =             &= nbsp; |
   = +----+------------------------+--------------------------+
   | 9  | Flow State Dependent   | No = agreed Parameters     |
   |    | Flow = Selection         |            =             &= nbsp; |
   = +----+------------------------+--------------------------+ =




D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 20]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   Abstract Data Type: unsigned16

   ElementId: TBD1

   Data Type Semantics: identifier

   Status: Proposed

7.2.  flowSelectedOctetDeltaCount

   Description:

      This Information Element specifies the = volume in octets of all
      flows that are selected during the Flow Selection Process since
      the previous report.

   Abstract Data Type: unsigned64

   ElementId: TBD2

   Units: Octets

   Status: Proposed

7.3.  flowSelectedPacketDeltaCount

   Description:

      This Information Element specifies the = volume in packets of all
      flows that were selected during the Flow Selection Process since
      the previous report.

   Abstract Data Type: unsigned64

   ElementId: TBD3

   Units: Packets

   Status: Proposed

7.4.  flowSelectedFlowDeltaCount

   Description:

      This Information Element specifies the = number of Flows that were
      selected during the Flow Selection = Process since the last report.

   Abstract Data Type: unsigned64



D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 21]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   ElementId: TBD4

   Units: Flows

   Status: Proposed

7.5.  selectorIDTotalFlowsObserved

   Description:

      This Information Element specifies the = total number of flows
      observed by a Selector, for a specific = value of SelectorId.  This
      Information Element should be used in an = Options Template scoped
      to the observation to which it = refers.  See Section 3.4.2.1 of the
      IPFIX protocol document [RFC5101] .

   Abstract Data Type: unsigned64

   ElementId: TBD5

   Units: Flows

   Status: Proposed

7.6.  selectorIDTotalFlowsSelected

   Description:

      This Information Element specifies the = total number of flows
      selected by a Selector, for a specific = value of SelectorId.  This
      Information Element should be used in an = Options Template scoped
      to the observation to which it = refers.  See Section 3.4.2.1 of the
      IPFIX protocol document [RFC5101].

   Abstract Data Type: unsigned64

   ElementId: TBD6

   Units: Flows

   Status: Proposed

7.7.  samplingFlowInterval

   Description:

      This Information Element specifies the = number of flows that are
      consecutively sampled.  A value of = 100 means that 100 consecutive



D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 22]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


      flows are sampled.  For example, = this Information Element may be
      used to describe the configuration of a systematic count-based
      Sampling Selector.

   Abstract Data Type: unsigned64

   ElementId: TBD7

   Units: Flows

   Status: Proposed

7.8.  samplingFlowSpace

   Description:

      This Information Element specifies the = number of flows between two
      "samplingFlowInterval"s.  = A value of 100 means that the next
      interval starts 100 flows (which are not sampled) after the
      current "samplingFlowInterval" = is over.  For example, this
      Information Element may be used to = describe the configuration of a
      systematic count-based Sampling Selector. =

The text above mentions:

   For Systematic count-based Flow Sampling:

   -   Interval length
       Defines the number of flows that = are selected within the sampling
       interval.

   -   Spacing
       The spacing parameter defines the = spacing in number of observed
       flows between the end of one = sampling interval and the start of
       the next succeeding interval.

So be consistent between "Space", "Spacing", and = position (see one of my previous comments"

Space has been replaced with Spacing in samplingFlowSpace and in flowSamplingTimeSpace.


   Abstract Data Type: unsigned64

   ElementId: TBD8

   Units: Flows

   Status: Proposed

7.9.  flowSamplingTimeInterval

   Description:

      This Information Element specifies the = time interval in
      microseconds during which all arriving = flows are sampled.  For
      example, this Information Element may be = used to describe the
      configuration of a systematic time-based Sampling Selector.

The text above mentions:
   For Systematic time-based Flow Sampling:

   -   Interval length (in usec)
       Defines the length of the sampling interval during which flows
       are selected.

   -   Spacing (in usec)
       The spacing parameter defines the = spacing in usec between the end
       of one sampling interval and the = start of the next succeeding
       interval.

So be consistent between "Space", "Spacing", and = position (see one of my previous comments"


   Abstract Data Type: unsigned64

   ElementId: TBD9

   Units: microseconds

   Status: Proposed




D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 23]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


7.10.  flowSamplingTimeSpace

   Description:

      This Information Element specifies the = time interval in
      microseconds between two "flowSamplingTimeInterval"s.  A value of
      100 means that the next interval starts = 100 microseconds (during
      which no flows are sampled) after the = current
      "flowsamplingTimeInterval" is over.  For example, this Information
      Element may used to describe the = configuration of a systematic
      time-based Sampling Selector. =

Same remark.


   Abstract Data Type: unsigned64

   ElementId: TBD10

   Units: microseconds

   Status: Proposed

7.11.  hashFlowDomain

   Description:

      This Information Element specifies the Information Elements that
      are used by the Hash-based flow Selection Selector as the Hash
      Domain.

   Abstract Data Type: unsigned16

   ElementId: TBD11

   Data Type Semantics: identifier

   Status: Proposed


8.  IANA Considerations

8.1.  Registration of Information Elements

   IANA will register the following IEs in the IPFIX = Information
   Elements registry at http://www.iana.= org/assignments/ipfix/ipfix.xml:








D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 24]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   +-----+----------------+--------+---------+-------+-----------------+ =
   | Val | Name           | Data   | Data    | Statu | Description     |
   | ue  = |            =     | Type   | Type    | s     |            =      |
   |     |            =     |        | Semanti |       = |            =      |
   |     |            =     |        | = cs      |       = |            =      |
   = +-----+----------------+--------+---------+-------+-----------------+
   | 1   | flowSelectorAl | unsign | identif | Propo = | This            | =
   |     | gorithm        | ed16   | ier     | sed   | Information     |
   |     |            =     |        |         = |       | Element         |
   |     |            =     |        |         |       | identifies the  |
   |     |            =     |        |         = |       | flow selection  |
   |     |            =     |        |         = |       | method(e.g.,    |
   |     |            =     |        = |         |       | Filtering,      |
   |     |            =     |        |         = |       | Sampling) that  |
   |     |            =     |        |         = |       | is applied by   |
   |     |            =     |        |         = |       | the Flow        |
   |     |            =     |        |         = |       | Selection       |
   |     |            =     |        |         = |       | Process         |
   +-----+----------------+--------+---------+-------+-----------------+ =
   | 2   | flowSelectedOc | unsign | Octets  | = Propo | This            | =
   |     | tetDeltaCount  | = ed64   |         | sed   | Information     |
   |     |            =     |        |         = |       | Element         |
   |     |            =     |        |         = |       | specifies the   |
   |     |            =     |        |         = |       | volume in       |
   |     |            =     |        |         = |       | octets of all   |
   |     |            =     |        |         = |       | flows that are  |
   |     |            =     |        |         |       | selected during |
   |     |            =     |        |         = |       | the Flow        |
   |     |            =     |        |         = |       | Selection       |
   |     |            =     |        |         = |       | Process since   |
   |     |            =     |        |         = |       | the previous    |
   |     |            =     |        |         = |       | report.         |
   +-----+----------------+--------+---------+-------+-----------------+ =
   | 3   | flowSelectedPa | unsign | Packets | Propo = | This            | =
   |     | cketDeltaCount | = ed64   |         | sed   | Information     |
   |     |            =     |        |         = |       | Element         |
   |     |            =     |        |         = |       | specifies the   |
   |     |            =     |        |         = |       | volume in       |
   |     |            =     |        |         = |       | packets of all  |
   |     |            =     |        |         = |       | flows that were |
   |     = |            =     |        |         |       | selected during |
   |     |            =     |        |         = |       | the Flow        |
   |     |            =     |        |         = |       | Selection       |
   |     |            =     |        |         = |       | Process since   |
   |     |            =     |        |         = |       | the previous    |
   |     |            =     |        |         = |       | report.         |
   +-----+----------------+--------+---------+-------+-----------------+ =




D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 25]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   +-----+----------------+--------+---------+-------+-----------------+ =
   | 4   | flowSelectedFl | unsign | = Flows   | Propo | = This            |
   |     | owDeltaCount   | ed64   |         | sed   | Information     |
   |     |            =     |        |         = |       | Element         |
   |     |            =     |        |         = |       | specifies the   |
   |     |            =     |        |         = |       | number of Flows |
   |     |            =     |        |         = |       | that were       |
   |     |            =     |        |         = |       | selected during |
   |     |            =     |        |         |       | the Flow        |
   |     |            =     |        |         = |       | Selection       |
   |     |            =     |        |         = |       | Process since   |
   |     |            =     |        |         = |       | the last        |
   |     |            =     |        |         = |       | report.         |
   +-----+----------------+--------+---------+-------+-----------------+ =
   | 5   | selectorIDTota | unsign | = Flows   | Propo | = This            |
   |     | lFlowsObserved | = ed64   |         | sed   | Information     |
   |     |            =     |        |         = |       | Element         |
   |     |            =     |        |         = |       | specifies the   |
   |     |            =     |        |         = |       | total number of |
   |     |            =     |        |         = |       | flows observed  |
   |     |            =     |        |         = |       | by a Selector,  |
   |     |            =     |        |         = |       | for a specific  |
   |     = |            =     |        |         |       | value of        |
   |     |            =     |        |         = |       | SelectorId.     |
   |     |            =     |        |         = |       | This            = |
   |     |            =     |        |         = |       | Information     |
   |     |            =     |        |         = |       | Element should  |
   |     |            =     |        |         = |       | be used in an   |
   |     |            =     |        |         = |       | Options         |
   |     = |            =     |        |         |       | Template scoped |
   |     |            =     |        |         = |       | to the          |
   |     |            =     |        |         = |       | observation to  |
   |     |            =     |        |         |       | which it        |
   |     |            =     |        |         = |       | refers.  See    |
   |     |            =     |        |         = |       | Section 3.4.2.1 |
   |     |            =     |        |         = |       | of the IPFIX    |
   |     |            =     |        |         |       | = protocol        |
   |     |            =     |        |         = |       | document        |
   |     |            =     |        |         = |       | [RFC5101]       |
   = +-----+----------------+--------+---------+-------+-----------------+











D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 26]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   = +-----+----------------+--------+---------+-------+-----------------+
   | 6   | selectorIDTota | unsign | = Flows   | Propo | = This            |
   |     | lFlowsSelected | = ed64   |         | sed   | Information     |
   |     |            =     |        |         = |       | Element         |
   |     = |            =     |        |         |       | specifies the   |
   |     |            =     |        |         = |       | total number of |
   |     |            =     |        |         = |       | flows selected  |
   |     |            =     |        |         = |       | by a Selector,  |
   |     |            =     |        |         = |       | for a specific  |
   |     |            =     |        |         = |       | value of        |
   |     |            =     |        |         = |       | SelectorId.     |
   |     = |            =     |        |         |       | = This            |
   |     |            =     |        |         = |       | Information     |
   |     |            =     |        |         = |       | Element should  |
   |     |            =     |        |         |       | be used in an   |
   |     |            =     |        |         = |       | Options         |
   |     |            =     |        |         = |       | Template scoped |
   |     |            =     |        |         = |       | to the          |
   |     |            =     |        |         |       | observation to  |
   |     |            =     |        |         = |       | which it        |
   |     |            =     |        |         = |       | refers.  See    |
   |     |            =     |        = |         |       | Section 3.4.2.1 |
   |     |            =     |        |         = |       | of the IPFIX    |
   |     |            =     |        |         = |       | protocol        |
   |     |            =     |        |         = |       | document        |
   |     |            =     |        |         = |       | [RFC5101].      |
   +-----+----------------+--------+---------+-------+-----------------+ =
























D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 27]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   +-----+----------------+--------+---------+-------+-----------------+ =
   | 7   | samplingFlowIn | unsign | = Flows   | Propo | = This            |
   |     | terval         | = ed64   |         | sed   | Information     |
   |     |            =     |        |         = |       | Element         |
   |     |            =     |        |         = |       | specifies the   |
   |     |            =     |        |         = |       | number of flows |
   |     |            =     |        |         = |       | that are        |
   |     |            =     |        |         = |       | consecutively   |
   |     |            =     |        |         = |       | sampled.  A     |
   |     |            =     |        |         |       | value of 100    | =
   |     |            =     |        |         = |       | means that 100  |
   |     |            =     |        |         = |       | consecutive     |
   |     |            =     |        |         = |       | flows are       |
   |     |            =     |        |         = |       | sampled.  For   |
   |     |            =     |        |         = |       | example, this   |
   |     |            =     |        |         = |       | Information     |
   |     |            =     |        |         |       | Element may be  |
   |     |            =     |        |         = |       | used to         |
   |     |            =     |        |         = |       | describe the    |
   |     |            =     |        |         = |       | configuration   |
   |     |            =     |        |         = |       | of a systematic |
   |     |            =     |        |         = |       | count-based     |
   |     |            =     |        |         = |       | Sampling        |
   |     |            =     |        |         |       | Selector.       |
   +-----+----------------+--------+---------+-------+-----------------+ =


























D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 28]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   +-----+----------------+--------+---------+-------+-----------------+ =
   | 8   | samplingFlowSp | unsign | = Flows   | Propo | = This            |
   |     | ace            | ed64   |         | sed   | Information     |
   |     |            =     |        |         = |       | Element         |
   |     |            =     |        |         = |       | specifies the   |
   |     |            =     |        |         = |       | number of flows |
   |     |            =     |        |         |       | between = two     |
   |     |            =     |        |         = |       | "samplingFlowIn |
   |     |            =     |        |         = |       | terval"s.  A    |
   |     |            =     |        |         = |       |  value of 100   |
   |     |            =     |        |         = |       |  means that the |
   |     |            =     |        |         = |       |  next interval  |
   |     |            =     |        |         = |       |  starts 100     |
   |     = |            =     |        |         |       |  flows (which   | =
   |     |            =     |        |         = |       |  are not        |
   |     |            =     |        |         = |       |  sampled) after |
   |     |            =     |        |         = |       |  the current    |
   |     |            =     |        |         = |       |  "samplingFlowI |
   |     |            =     |        |         = |       | nterval" is ove |
   |     |            =     |        |         = |       | r.For example,  |
   |     |            =     |        |         |       |   = this          |
   |     |            =     |        |         = |       |   Information   |
   |     |            =     |        |         = |       |   Element may b |
   |     |            =     |        = |         |       | e used to       |
   |     |            =     |        |         = |       |   describe the  |
   |     |            =     |        |         = |       |   configuration |
   |     |            =     |        |         = |       |   of a systemat |
   |     |            =     |        |         = |       | iccount-based   |
   |     |            =     |        |         = |       |   Sampling      |
   |     |            =     |        |         = |       |   Selector.     |
   = +-----+----------------+--------+---------+-------+-----------------+




















D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 29]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   = +-----+----------------+--------+---------+-------+-----------------+
   | 9   | flowSamplingTi | unsign | microse | Propo = | This            | =
   |     | = meInterval     | ed64   | conds   | sed   | Information     |
   |     |            =     |        |         = |       | Element         |
   |     |            =     |        |         |       | specifies the   |
   |     |            =     |        |         = |       | time interval   |
   |     |            =     |        |         = |       | in microseconds |
   |     |            =     |        = |         |       | during which    | =
   |     |            =     |        |         = |       | all arriving    |
   |     |            =     |        |         = |       | flows are       |
   |     |            =     |        |         = |       | sampled.  For   |
   |     |            =     |        |         = |       | example, this   |
   |     |            =     |        |         = |       | Information     |
   |     |            =     |        |         = |       | Element may be  |
   |     |            =     |        |         |       | used to         |
   |     |            =     |        |         = |       | describe the    |
   |     |            =     |        |         = |       | configuration   |
   |     |            =     |        |         = |       | of a systematic |
   |     |            =     |        |         = |       | time-based      |
   |     |            =     |        |         = |       | Sampling        |
   |     |            =     |        |         = |       | Selector.       |
   = +-----+----------------+--------+---------+-------+-----------------+





























D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 30]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   = +-----+----------------+--------+---------+-------+-----------------+
   | 10  | flowSamplingTi | unsign | microse | Propo | This            | =
   |     | meSpace        | ed64   | conds   | sed   | = Information     |
   |     |            =     |        |         = |       | Element         |
   |     |            =     |        |         = |       | specifies the   |
   |     |            =     |        |         = |       | time interval   |
   |     |            =     |        |         = |       | in microseconds |
   |     |            =     |        |         |       | between = two     |
   |     |            =     |        |         = |       | "flowSamplingTi |
   |     |            =     |        |         = |       | meInterval"s.   |
   |     |            =     |        |         = |       | Avalue of 100   |
   |     |            =     |        |         = |       |  means that the |
   |     |            =     |        |         = |       |  next interval  |
   |     |            =     |        |         = |       |  starts 100     |
   |     = |            =     |        |         |       |  microseconds   | =
   |     |            =     |        |         = |       |  (during which  |
   |     |            =     |        |         = |       |  no flows are   |
   |     |            =     |        |         = |       |  sampled) after |
   |     |            =     |        |         = |       |  the current    |
   |     |            =     |        |         = |       |  "flowsamplingT |
   |     |            =     |        |         = |       | imeInterval" is |
   |     = |            =     |        |         |       |   over.  = For    |
   |     |            =     |        |         = |       |   example, this |
   |     |            =     |        |         = |       |   Information   |
   |     |            =     |        |         |       |   Element = may   |
   |     |            =     |        |         = |       |   used to       |
   |     |            =     |        |         = |       |   describe the  |
   |     |            =     |        |         = |       |   configuration |
   |     |            =     |        |         |       |   of a systemat |
   |     |            =     |        |         = |       | ictime-based    |
   |     |            =     |        |         = |       |   Sampling      |
   |     |            =     |        = |         |       |   Selector.     |
   +-----+----------------+--------+---------+-------+-----------------+ =
   | 11  | hashFlowDomain | unsign | identif | Propo | This            | =
   |     |            =     | ed16   | ier     | sed   | Information     |
   |     |            =     |        |         = |       | Element         |
   |     |            =     |        |         = |       | specifies the   |
   |     |            =     |        |         = |       | Information     |
   |     |            =     |        |         |       | Elements that   |
   |     |            =     |        |         = |       | are used by the |
   |     |            =     |        |         = |       | Hash-based flow |
   |     |            =     |        |         = |       | Selection       |
   |     |            =     |        |         = |       | Selector as the |
   |     |            =     |        |         = |       | Hash Domain.    |
   +-----+----------------+--------+---------+-------+-----------------+ =

            &= nbsp;         Table 3: Flow Selection methods




D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 31]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


8.2.  Registration of Object Identifier

   IANA will register the following OID in the = IPFIX-SELECTOR-MIB
   Functions sub-registry at http://www.iana.org/= assignments/smi-numbers
   according to the procedures set forth in [I-D.dkcm-ipfix-rfc5815bis]

Should be http:/= /tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03
Btw, this draft is right now in AUTH48
See http://www.rfc-edi= tor.org/authors/rfc6632.txt
http://www.rfc-edi= tor.org/authors/rfc6615.txt

Btw,  you must  mention that you want a new entry under = 

Sub-registry Name: IPFIX-SELECTOR-MIB =
Functions
See http://tools.ietf.org/html/draft-ietf-ipfix-psamp-mib-04#section-8=
 for an example


The text has been modified.


   +---------+-----------------------+---------------------+-----------+ =
   | Decimal | = Name           &nb= sp;      | Description         | = Reference |
   +---------+-----------------------+---------------------+-----------+ =
   | 1       | = flowSelectorAlgorithm | This Object         | [RFCyyyy] = |
   |         |            =            | Identifier          |           |
   |         |            =            | identifies the flow = |           |
   |         |            =            | selection method    = |           |
   |         |            =            | (e.g., Filtering,   = |           |
   |         |            =            | Sampling) that is   |           |
   |         |            =            | applied by the Flow = |           |
   |         |            =            | Selection Process   = |           |
   = +---------+-----------------------+---------------------+-----------+

            &= nbsp; Table 4: Information Elements to be registered

You can't use the value 1. IANA will decide what is = the next available value.

Right. The value has been removed.


   Editor's Note (to be removed prior to publication): the RFC = editor is
   asked to replace "yyyy" in this document by the = number of the RFC
   when the assignment has been made.


9.  Security Considerations

   The described flow sampling techniques and the hash-based = flow
   filtering technique aim at the selection of a = representative subset
   of flows in order to make an accurate estimation of the population.

Not always, right?  For example, it's not the = goal of "Property Match Filtering"

Section on Security Considerations has been = rewritten.

 

   An adversary may have incentives to = influence the selection of flows,
   for example to circumvent accounting.

   Security considerations concerning the choice of a Hash = Function for
   Hash-based Packet Selection have been discussed in Section = 6.2.3 of
   [RFC5475] and are also appropriate for Hash-Based Flow = Selection.
   This section discussed a number of potential attacks to = craft Streams

I see Observed Packet Stream and Packet Stream in RFC5475,  I see Data Stream in RFC5470, but not Stream alone.
I guess you want to say Packet Stream

   that are disproportionately detected = and/or discover the Hash
   Function parameters, the vulnerabilities of different Hash Functions
   to these attacks, and practices to minimize these = vulnerabilities.

   For other sampling approaches a user can gain knowledge = about the
   start and stop triggers in time-based systematic Sampling, = e.g., by
   sending test packets.  This knowledge might allow = users to modify
   their send schedule in a way that their packets are
   disproportionately selected or not selected.  For = random Sampling, a
   cryptographically strong random number generator should be = used in



D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 32]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   order to prevent that an advisory can predict the selection decision
   [GoRe07].

   Further security threats can occur when Sampling parameters = are
   configured or communicated to other entities.  The protocol(s) for
   the configuration and reporting of Sampling parameters are = out of
   scope of this document.  Nevertheless, a set of = initial requirements
   for future configuration and reporting protocols are stated = below:

   1.  Protection against disclosure of configuration information: Flow

Flow -> Flow Sampling

       selection = configuration information describes the selection
       process and its parameters.  = This information can be useful to
       attackers.  Attackers may = craft packets that never fit the
       selection criteria in order to = prevent flows to be seen by the
       selection process.  They can = also craft a lot of packets that fit
       the selection criteria and overload = or bias subsequent processes.
       Therefore any transmission of configuration data (e.g., to
       configure a process or to report = its actual status) should be
       protected by encryption.

   2.  Protection against modification of configuration information: If
       wrong configuration information is = sent to the flow selection
       process, it can lead to a = malfunction of the selection process.
       Also if wrong configuration = information is reported from the
       selection process to other = processes it can lead to wrong
       estimations at subsequent = processes.  Therefore any protocol that
       transmits configuration information = should prevent that an
       attacker can modify configuration information.  Data integrity
       can be achieved by authenticating = the data.

   3.  Protection against malicious nodes sending = configuration
       information: The remote = configuration of flow selection methods
       should be protected against access = by unauthorized nodes.  This
       can be achieved by access control = lists at the selection devices

selection devices? Do you mean IPFIX Exporter?

       and source authentication.  The reporting of configuration data =
       from a selection process has to be protected in the same way.
       That means that also protocols that = report configuration data
       from the selection process to other processes need to protect
       against unauthorized nodes = reporting configuration information.

   The security threats that originate from communicating configuration
   information to and from selection processes cannot be = assessed solely
   with the information given in this document.  A = further more detailed
   assessment of security threats is necessary when a specific protocol
   for the configuration or reporting configuration data is = proposed.






D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 33]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


10.  Acknowledgments

   We would like to thank the IPFIX group, especially Brian = Trammell,
   Paul Aitken and Benoit Claise for fruitful discussions and = for
   proofreading the document.


11.  References

11.1.  Normative References

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

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

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

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

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

11.2.  Informative References

   [Bra75]    Brayer, K., "Evaluation of = 32 Degree Polynomials in Error
            &= nbsp; Detection on the SATIN IV Autovon Error Patterns",
            &= nbsp; National Technical Information Service p.74, August 1975.

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

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

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



D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 34]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


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

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

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

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

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

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

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

   [iana-ipfix-assignments]
            &= nbsp; "IP Flow Information Export Information Elements", 2007,
            &= nbsp; <http://www.i= ana.org/assignments/ipfix/ipfix.xml>.


Authors' Addresses

   Salvatore D'Antonio
   University of Napoli "Parthenope"
   Centro Direzionale di Napoli Is. C4
   Naples  80143
   Italy

   Phone: +39 081 5476766
   Email: salvatore.dantonio@un= iparthenope.it






D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 35]
=A0
Internet-Draft          = Flow Selection Techniques          &nb= sp;  April 2012


   Tanja Zseby
   CAIDA/FhG FOKUS
   San Diego Supercomputer Center (SDSC)
   University of California, San Diego (UCSD)
   9500 Gilman Drive
   La Jolla  CA 92093-0505
   USA

   Email: tanja@caida.org


   Christian Henke
   Tektronix Communication Berlin
   Wohlrabedamm 32
   Berlin  13629
   Germany

   Phone: +49 17 2323 8717
   Email: christian.henke@tektronix.c= om


   Lorenzo Peluso
   University of Napoli
   Via Claudio 21
   Napoli  80125
   Italy

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






















D'Antonio, et al.       Expires October = 25, 2012           &nb= sp;   [Page 36]

 

Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.1913 / Database dei virus: 2425/5036 - Data di = rilascio: 31/05/2012

------=_NextPart_000_004A_01CD9A7C.8BB74B40-- From paitken@cisco.com Mon Sep 24 12:50:05 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B59C21F88BF for ; Mon, 24 Sep 2012 12:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgpGB6e2hRmV for ; Mon, 24 Sep 2012 12:50:04 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 07E8221F88B8 for ; Mon, 24 Sep 2012 12:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11724; q=dns/txt; s=iport; t=1348516203; x=1349725803; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=p4e0LuN6V8lRTevmB2n+xDFoxXPhtvdrpj+6Sabhel4=; b=LBv4ptIokUKEODkIwz10FDG/LhbkVBTxKv2qTq65oyj+9JarVdwmNr88 EFBYoplMBM3PoqpmGR5g5lYnehN9RwBvJlFhbWdsgcJRgzCzatGI5yB1j xQhx62Im52vqIZMOHElFsLJQ9dc5xN09T5Sm5k9VgyERRxhYfKzgY5jTS s=; X-IronPort-AV: E=Sophos;i="4.80,477,1344211200"; d="scan'208,217";a="144302148" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 24 Sep 2012 19:49:58 +0000 Received: from [10.61.110.74] (dhcp-10-61-110-74.cisco.com [10.61.110.74]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8OJnvii019212; Mon, 24 Sep 2012 19:49:57 GMT Message-ID: <5060B969.4050705@cisco.com> Date: Mon, 24 Sep 2012 20:50:01 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Andrew Feren References: <50587825.9020305@cisco.com> <505B7931.5020404@plixer.com> <50602B53.1060908@cisco.com> <50604F01.8030104@cisco.com> <50605A40.90906@plixer.com> In-Reply-To: <50605A40.90906@plixer.com> Content-Type: multipart/alternative; boundary="------------040104080408070505030806" Cc: ipfix@ietf.org Subject: Re: [IPFIX] Promotion of Enterprise-Specific IEs to IANA IEs 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, 24 Sep 2012 19:50:05 -0000 This is a multi-part message in MIME format. --------------040104080408070505030806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andrew, The idea was that the equivalence option could map any IEspec to any other IEspec. Although it'd be commonly used to map enterprise specific to IANA standard, it could also map enterprise to enterprise, and even IANA standard to enterprise specific, or IANA standard to IANA standard. In fact it could also map between MIB / enterprise / IANA. Regarding A/B/C below, imagine that enterprise specific IE A exports uint8 values 1 and 2. Later, enterprise specific IE B increases the size to uint16 and adds new values 0x123 and 0x45678, so A isn't exported anymore. Then B is replaced by the standardised version, C - so neither A nor B are required anymore. However, older devices still export B. As an older device, the equivalence option coming from this device wouldn't know about C, so it'd just report that A has been replaced by B. Whereas the URI mechanism would report that A is now B and B is now C, without any way to determine when (in code / release terms) the equivalence happened - so collectors might only expect C, which would be incorrect since older devices could still be exporting B (or indeed, A). P. On 24/09/12 14:04, Andrew Feren wrote: > Hi Paul, > > On 09/24/2012 08:16 AM, Paul Aitken wrote: >> Benoit, >> >>> 4. If a single router from a specific vendor sends that URI, the >>> collector receives all the mappings. >>> >>> The point 4 is my primary argument against "IE equivalence options >>> template". >>> - "IE equivalence options template" must be sent from _all _the >>> exporters (because different exporters support different sets of >>> IEs) for the collector to rely on the mechanism. And we know there >>> are different platforms, with different software versions, even from >>> a single vendor. >> >> That's not quite correct. >> >> If each box must send it's own unique equivalence option, then each >> box would require a unique URI for the collector to obtain the >> correct mapping for that device alone. >> >> Since you clearly see that a single URI is sufficient for all devices >> from a vendor, then a single option template from a single device is >> also sufficient for all devices from a vendor, since the option would >> contain the exact same information as the URI. > Benoit can correct me if I am not understanding him correctly, but I > think he is envisioning something a bit broader than just the mapping > needed for a single device. I think what Benoit has in mind is a URI > to a vendor maintained IANA like registry. This registry would have > info about all of that vendors information elements. > >>> - Sending the URI only needs to be sent from a single exporter (from >>> that vendor) and the collector gets all the required information. >> >> Similarly for the equivalence option. >> >> Consider the mechanism versus the content: there are two mechanisms >> (option versus URI), while the underlying content is the same. >> >> >>> Note that the collector could even be hard coded the URI in the >>> collector, as this should not change. >> >> Consider how the URI mechanism would handle versioning. ie, an >> enterprise-specific IE changes from A to B to C. If the latest URI >> says A is B and B is C (as it must), then older EPs from before the B >> to C change, which truly do export B, may not be interpreted correctly. >> >> Whereas with the equivalence option mechanism, an older device could >> export the "A to B" equivalence without the "B to C" equivalence. > > First I thought the idea was to declare the "equivalence" of a vendor > IE to some now standard IE. I suppose a large vendor might have to > IEs (say A and C) that are both equivalent to some new standard IE B. > Maybe A and C each only ever exported a subset of the values now > standard for B, whatever. If I can say that A is equivalent to B and > I can say B is equivalent to C then I better also be able to say that > A is equivalent to C.... Ahhh. > > OK as I type this out I think I see where you are going. Let's be > more specific with my above example > > A exports values (1 and 2) > C exports values (3 and 4) > B exports values (1, 2, 3, 4) > > saying A is equivalent to C is a bit bizarre. Maybe equivalence is > the wrong word. Anyone have a better suggestion? > > I think this is a pretty compelling argument for each vendor > maintaining a single registry. I'm not really interested in > versioning beyond getting the latest (most complete definition). > Maintaining a per exporter registry seems like a lot of work with not > a lot of upside. > > I'll give this some more thought though. > > -Andrew --------------040104080408070505030806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Andrew,

The idea was that the equivalence option could map any IEspec to any other IEspec. Although it'd be commonly used to map enterprise specific to IANA standard, it could also map enterprise to enterprise, and even IANA standard to enterprise specific, or IANA standard to IANA standard. In fact it could also map between MIB / enterprise / IANA.

Regarding A/B/C below, imagine that enterprise specific IE A exports uint8 values 1 and 2. Later, enterprise specific IE B increases the size to uint16 and adds new values 0x123 and 0x45678, so A isn't exported anymore. Then B is replaced by the standardised version, C - so neither A nor B are required anymore.

However, older devices still export B. As an older device, the equivalence option coming from this device wouldn't know about C, so it'd just report that A has been replaced by B.

Whereas the URI mechanism would report that A is now B and B is now C, without any way to determine when (in code / release terms) the equivalence happened - so collectors might only expect C, which would be incorrect since older devices could still be exporting B (or indeed, A).

P.


On 24/09/12 14:04, Andrew Feren wrote:
Hi Paul,

On 09/24/2012 08:16 AM, Paul Aitken wrote:
Benoit,

4. If a single router from a specific vendor sends that URI, the collector receives all the mappings.

The point 4 is my primary argument against "IE equivalence options template".
- "IE equivalence options template" must be sent from all the exporters (because different exporters support different sets of IEs) for the collector to rely on the mechanism. And we know there are different platforms, with different software versions, even from a single vendor.

That's not quite correct.

If each box must send it's own unique equivalence option, then each box would require a unique URI for the collector to obtain the correct mapping for that device alone.

Since you clearly see that a single URI is sufficient for all devices from a vendor, then a single option template from a single device is also sufficient for all devices from a vendor, since the option would contain the exact same information as the URI.
Benoit can correct me if I am not understanding him correctly, but I think he is envisioning something a bit broader than just the mapping needed for a single device.  I think what Benoit has in mind is a URI to a vendor maintained IANA like registry.  This registry would have info about all of that vendors information elements.

- Sending the URI only needs to be sent from a single exporter (from that vendor) and the collector gets all the required information.

Similarly for the equivalence option.

Consider the mechanism versus the content: there are two mechanisms (option versus URI), while the underlying content is the same.


Note that the collector could even be hard coded the URI in the collector, as this should not change.

Consider how the URI mechanism would handle versioning. ie, an enterprise-specific IE changes from A to B to C. If the latest URI says A is B and B is C (as it must), then older EPs from before the B to C change, which truly do export B, may not be interpreted correctly.

Whereas with the equivalence option mechanism, an older device could export the "A to B" equivalence without the "B to C" equivalence.

First I thought the idea was to declare the "equivalence" of a vendor IE to some now standard IE.  I suppose a large vendor might have to IEs (say A and C) that are both equivalent to some new standard IE B.  Maybe A and C each only ever exported a subset of the values now standard for B, whatever.  If I can say that A is equivalent to B and I can say B is equivalent to C then I better also be able to say that A is equivalent to C.... Ahhh.

OK as I type this out I think I see where you are going.  Let's be more specific with my above example

A exports values (1 and 2)
C exports values (3 and 4)
B exports values (1, 2, 3, 4)

saying A is equivalent to C is a bit bizarre.  Maybe equivalence is the wrong word.  Anyone have a better suggestion?

I think this is a pretty compelling argument for each vendor maintaining a single registry.  I'm not really interested in versioning beyond getting the latest (most complete definition).  Maintaining a per exporter registry seems like a lot of work with not a lot of upside.

I'll give this some more thought though.

-Andrew

--------------040104080408070505030806-- From bclaise@cisco.com Mon Sep 24 14:58:40 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41A821F866B for ; Mon, 24 Sep 2012 14:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.629 X-Spam-Level: X-Spam-Status: No, score=-4.629 tagged_above=-999 required=5 tests=[AWL=-2.031, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ypffnY9-pbr for ; Mon, 24 Sep 2012 14:58:39 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id F01FD21F862A for ; Mon, 24 Sep 2012 14:58:37 -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 q8OLwZkc028759; Mon, 24 Sep 2012 23:58:35 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8OLwYAU018259; Mon, 24 Sep 2012 23:58:34 +0200 (CEST) Message-ID: <5060D78A.5060807@cisco.com> Date: Mon, 24 Sep 2012 23:58:34 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Andrew Feren References: <50587825.9020305@cisco.com> <505B7931.5020404@plixer.com> <50602B53.1060908@cisco.com> <50604F01.8030104@cisco.com> <50605A40.90906@plixer.com> In-Reply-To: <50605A40.90906@plixer.com> Content-Type: multipart/alternative; boundary="------------020702080006040601080902" Cc: ipfix@ietf.org Subject: Re: [IPFIX] Promotion of Enterprise-Specific IEs to IANA IEs 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, 24 Sep 2012 21:58:40 -0000 This is a multi-part message in MIME format. --------------020702080006040601080902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, > Hi Paul, > > On 09/24/2012 08:16 AM, Paul Aitken wrote: >> Benoit, >> >>> 4. If a single router from a specific vendor sends that URI, the >>> collector receives all the mappings. >>> >>> The point 4 is my primary argument against "IE equivalence options >>> template". >>> - "IE equivalence options template" must be sent from _all _the >>> exporters (because different exporters support different sets of >>> IEs) for the collector to rely on the mechanism. And we know there >>> are different platforms, with different software versions, even from >>> a single vendor. >> >> That's not quite correct. >> >> If each box must send it's own unique equivalence option, then each >> box would require a unique URI for the collector to obtain the >> correct mapping for that device alone. >> >> Since you clearly see that a single URI is sufficient for all devices >> from a vendor, then a single option template from a single device is >> also sufficient for all devices from a vendor, since the option would >> contain the exact same information as the URI. > Benoit can correct me if I am not understanding him correctly, but I > think he is envisioning something a bit broader than just the mapping > needed for a single device. I think what Benoit has in mind is a URI > to a vendor maintained IANA like registry. This registry would have > info about all of that vendors information elements. Exactly. > >>> - Sending the URI only needs to be sent from a single exporter (from >>> that vendor) and the collector gets all the required information. >> >> Similarly for the equivalence option. >> >> Consider the mechanism versus the content: there are two mechanisms >> (option versus URI), while the underlying content is the same. Not quite. The "IE equivalence options template" is for the situation when one exporter upgraded his software, and is aware of one new IE mapping (due to the software upgrade). This "IE equivalence options template" is basically telling: "mister collector, you were receiving enterprise-specific IE X from me, and now I'm sending you the IANA IE Y: the two are equivalent" The "IE equivalence options template" has the context of the exporter only, while the URI solution contains a URI to a vendor maintained IANA like registry >> >> >>> Note that the collector could even be hard coded the URI in the >>> collector, as this should not change. >> >> Consider how the URI mechanism would handle versioning. ie, an >> enterprise-specific IE changes from A to B to C. If the latest URI >> says A is B and B is C (as it must), then older EPs from before the B >> to C change, which truly do export B, may not be interpreted correctly. >> >> Whereas with the equivalence option mechanism, an older device could >> export the "A to B" equivalence without the "B to C" equivalence. I'm not convinced this is a real use case. > > First I thought the idea was to declare the "equivalence" of a vendor > IE to some now standard IE. I suppose a large vendor might have to > IEs (say A and C) that are both equivalent to some new standard IE B. > Maybe A and C each only ever exported a subset of the values now > standard for B, whatever. If I can say that A is equivalent to B and > I can say B is equivalent to C then I better also be able to say that > A is equivalent to C.... Ahhh. > > OK as I type this out I think I see where you are going. Let's be > more specific with my above example > > A exports values (1 and 2) > C exports values (3 and 4) > B exports values (1, 2, 3, 4) > > saying A is equivalent to C is a bit bizarre. Maybe equivalence is > the wrong word. Anyone have a better suggestion? > > I think this is a pretty compelling argument for each vendor > maintaining a single registry. I'm not really interested in > versioning beyond getting the latest (most complete definition). > Maintaining a per exporter registry seems like a lot of work with not > a lot of upside. I share the same view. Regards, Benoit (as a contributor) > > I'll give this some more thought though. > > -Andrew --------------020702080006040601080902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi,
Hi Paul,

On 09/24/2012 08:16 AM, Paul Aitken wrote:
Benoit,

4. If a single router from a specific vendor sends that URI, the collector receives all the mappings.

The point 4 is my primary argument against "IE equivalence options template".
- "IE equivalence options template" must be sent from all the exporters (because different exporters support different sets of IEs) for the collector to rely on the mechanism. And we know there are different platforms, with different software versions, even from a single vendor.

That's not quite correct.

If each box must send it's own unique equivalence option, then each box would require a unique URI for the collector to obtain the correct mapping for that device alone.

Since you clearly see that a single URI is sufficient for all devices from a vendor, then a single option template from a single device is also sufficient for all devices from a vendor, since the option would contain the exact same information as the URI.
Benoit can correct me if I am not understanding him correctly, but I think he is envisioning something a bit broader than just the mapping needed for a single device.  I think what Benoit has in mind is a URI to a vendor maintained IANA like registry.  This registry would have info about all of that vendors information elements.
Exactly.

- Sending the URI only needs to be sent from a single exporter (from that vendor) and the collector gets all the required information.

Similarly for the equivalence option.

Consider the mechanism versus the content: there are two mechanisms (option versus URI), while the underlying content is the same.
Not quite.
The "IE equivalence options template" is for the situation when one exporter upgraded his software, and is aware of one new IE mapping (due to the software upgrade).
This "IE equivalence options template" is basically telling: "mister collector, you were receiving enterprise-specific IE X from me, and now I'm sending you the IANA IE Y: the two are equivalent"

The "IE equivalence options template"  has the context of the exporter only, while the URI solution contains a URI to a vendor maintained IANA like registry


Note that the collector could even be hard coded the URI in the collector, as this should not change.

Consider how the URI mechanism would handle versioning. ie, an enterprise-specific IE changes from A to B to C. If the latest URI says A is B and B is C (as it must), then older EPs from before the B to C change, which truly do export B, may not be interpreted correctly.

Whereas with the equivalence option mechanism, an older device could export the "A to B" equivalence without the "B to C" equivalence.
I'm not convinced this is a real use case.

First I thought the idea was to declare the "equivalence" of a vendor IE to some now standard IE.  I suppose a large vendor might have to IEs (say A and C) that are both equivalent to some new standard IE B.  Maybe A and C each only ever exported a subset of the values now standard for B, whatever.  If I can say that A is equivalent to B and I can say B is equivalent to C then I better also be able to say that A is equivalent to C.... Ahhh.

OK as I type this out I think I see where you are going.  Let's be more specific with my above example

A exports values (1 and 2)
C exports values (3 and 4)
B exports values (1, 2, 3, 4)

saying A is equivalent to C is a bit bizarre.  Maybe equivalence is the wrong word.  Anyone have a better suggestion?

I think this is a pretty compelling argument for each vendor maintaining a single registry.  I'm not really interested in versioning beyond getting the latest (most complete definition).  Maintaining a per exporter registry seems like a lot of work with not a lot of upside.
I share the same view.

Regards, Benoit (as a contributor)

I'll give this some more thought though.

-Andrew

--------------020702080006040601080902-- From paitken@cisco.com Mon Sep 24 15:18:55 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67981F0C8A for ; Mon, 24 Sep 2012 15:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtU7zIxrB3WR for ; Mon, 24 Sep 2012 15:18:55 -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 14F481F041D for ; Mon, 24 Sep 2012 15:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1471; q=dns/txt; s=iport; t=1348525135; x=1349734735; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=HGcAiBVbgYG6/ULLILoFRZP6P3pGOf7MxNbin0+OsV8=; b=Th/aYYbQow00v26RJoYoy3l2Hq1mltPhcjJ933jS5DO9ci9EEgpr7W2W rBp7hhJwc4JKYAQFIayKZjWADbJ2Yx5+jp1feF1Pp7k0ZjOLjRWknSnkp 8xFPcLwhS8edPUyGCKnSe51xOyzlK/WDswCzX3ZkPuO4zeFv5T7yOiNY0 c=; X-IronPort-AV: E=Sophos;i="4.80,477,1344211200"; d="scan'208";a="8288271" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 24 Sep 2012 22:18:54 +0000 Received: from [10.61.87.239] (ams3-vpn-dhcp6128.cisco.com [10.61.87.239]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8OMIrkO026799; Mon, 24 Sep 2012 22:18:53 GMT Message-ID: <5060DC4D.2010301@cisco.com> Date: Mon, 24 Sep 2012 23:18:53 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Benoit Claise References: <50587825.9020305@cisco.com> <505B7931.5020404@plixer.com> <50602B53.1060908@cisco.com> <50604F01.8030104@cisco.com> <50605A40.90906@plixer.com> <5060D78A.5060807@cisco.com> In-Reply-To: <5060D78A.5060807@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Promotion of Enterprise-Specific IEs to IANA IEs 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, 24 Sep 2012 22:18:55 -0000 Benoit, >>> Consider the mechanism versus the content: there are two mechanisms >>> (option versus URI), while the underlying content is the same. > Not quite. > The "IE equivalence options template" is for the situation when one > exporter upgraded his software, and is aware of one new IE mapping > (due to the software upgrade). > This "IE equivalence options template" is basically telling: "mister > collector, you were receiving enterprise-specific IE X from me, and > now I'm sending you the IANA IE Y: the two are equivalent" > > The "IE equivalence options template" has the context of the exporter > only, while the URI solution contains a URI to a vendor maintained > IANA like registry Unless the new code can determine exactly what the previous version was, and knows exactly which IEs that version exported, it can't export such a specific equivalence option. So the normal situation would be for the new code to export a table with all the equivalences which it knows. Also from an implementation perspective, it's easier to build the equivalence table into every new product and export the whole table, rather than determine the correct subset for the old code versus current code. A simply collector could simply merge all the equivalence options into an equivalence superset in order to know all possible equivalences in the network. ie there's no need to maintain device-specific equivalences. P. From bclaise@cisco.com Mon Sep 24 15:26:04 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCCA1F0C8E for ; Mon, 24 Sep 2012 15:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.629 X-Spam-Level: X-Spam-Status: No, score=-4.629 tagged_above=-999 required=5 tests=[AWL=-2.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwnZ0etPq0+A for ; Mon, 24 Sep 2012 15:26:03 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id 500EA1F041D for ; Mon, 24 Sep 2012 15:26:03 -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 q8OMQ2fL001423; Tue, 25 Sep 2012 00:26:02 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8OMQ1mA003458; Tue, 25 Sep 2012 00:26:01 +0200 (CEST) Message-ID: <5060DDF9.8000000@cisco.com> Date: Tue, 25 Sep 2012 00:26:01 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Aitken References: <50587825.9020305@cisco.com> <505B7931.5020404@plixer.com> <50602B53.1060908@cisco.com> <50604F01.8030104@cisco.com> <50605A40.90906@plixer.com> <5060D78A.5060807@cisco.com> <5060DC4D.2010301@cisco.com> In-Reply-To: <5060DC4D.2010301@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Promotion of Enterprise-Specific IEs to IANA IEs 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, 24 Sep 2012 22:26:04 -0000 On 25/09/2012 00:18, Paul Aitken wrote: > Benoit, > >>>> Consider the mechanism versus the content: there are two mechanisms >>>> (option versus URI), while the underlying content is the same. >> Not quite. >> The "IE equivalence options template" is for the situation when one >> exporter upgraded his software, and is aware of one new IE mapping >> (due to the software upgrade). >> This "IE equivalence options template" is basically telling: "mister >> collector, you were receiving enterprise-specific IE X from me, and >> now I'm sending you the IANA IE Y: the two are equivalent" >> >> The "IE equivalence options template" has the context of the >> exporter only, while the URI solution contains a URI to a vendor >> maintained IANA like registry > > Unless the new code can determine exactly what the previous version > was, and knows exactly which IEs that version exported, it can't > export such a specific equivalence option. Good! It was the next point I wanted to address.... > > So the normal situation would be for the new code to export a table > with all the equivalences which it knows. > > Also from an implementation perspective, it's easier to build the > equivalence table into every new product and export the whole table, > rather than determine the correct subset for the old code versus > current code. > > A simply collector could simply merge all the equivalence options into > an equivalence superset in order to know all possible equivalences in > the network. ie there's no need to maintain device-specific equivalences. Instead, just point the collector to the URI with all the information. That's way easier for everybody: the exporters and the collector. Regards, Benoit (as a contributor) > > P. > > From paitken@cisco.com Mon Sep 24 15:36:33 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A461F0C90 for ; Mon, 24 Sep 2012 15:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Mr2B8+-CwbU for ; Mon, 24 Sep 2012 15:36:33 -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 012DF1F041D for ; Mon, 24 Sep 2012 15:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=935; q=dns/txt; s=iport; t=1348526193; x=1349735793; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JtNgwvBAOGswVvrH95Tj/2gHL4wpeWbJ+wrkuPYv2JA=; b=bgj04P36+r08+aSUbH3MdDkwQ53bi/pLKN1E0Eb2oHIJYDje3hKEVE5a SAkcHvrQ6Nvjzj10HgKl4wwMKPVoQfmbM3B17GMvrWqxat9Rqqd6SnDLO q5ggDHR1Ztfx4l//cV8Wejsp82r17xA7GJ6DyWiPAhXnSc3YCSfglZDBc I=; X-IronPort-AV: E=Sophos;i="4.80,477,1344211200"; d="scan'208";a="76942198" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 24 Sep 2012 22:36:29 +0000 Received: from [10.61.87.239] (ams3-vpn-dhcp6128.cisco.com [10.61.87.239]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8OMaSEX009573; Mon, 24 Sep 2012 22:36:29 GMT Message-ID: <5060E06C.90704@cisco.com> Date: Mon, 24 Sep 2012 23:36:28 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Benoit Claise References: <50587825.9020305@cisco.com> <505B7931.5020404@plixer.com> <50602B53.1060908@cisco.com> <50604F01.8030104@cisco.com> <50605A40.90906@plixer.com> <5060D78A.5060807@cisco.com> <5060DC4D.2010301@cisco.com> <5060DDF9.8000000@cisco.com> In-Reply-To: <5060DDF9.8000000@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Promotion of Enterprise-Specific IEs to IANA IEs 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, 24 Sep 2012 22:36:34 -0000 Benoit, > Instead, just point the collector to the URI with all the information. > That's way easier for everybody: the exporters and the collector. My constant point is that there's no way that network operators will allow this. Network configuration is locked down, and only changeable during pre-planned maintenance windows. At such times, only known-good and pre-tested configurations are rolled out. The equivalence option can be tested in isolation in a lab, and the configuration proven. There's no external influence upon the configuration. Whereas the URI mechanism cannot be tested in isolation because it's dependent upon the URI content, which could be modified at any time without notice. Also, this introduces a new attack vector upon the collector - ie, by feeding it malformed or incorrect data through the URI. So from a network operator point of view, I wouldn't buy that. P. From internet-drafts@ietf.org Wed Sep 26 06:17:25 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968C521F8870; Wed, 26 Sep 2012 06:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0SL4R5TAnIz; Wed, 26 Sep 2012 06:17:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB7521F8699; Wed, 26 Sep 2012 06:17:25 -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.34 Message-ID: <20120926131725.13434.68444.idtracker@ietfa.amsl.com> Date: Wed, 26 Sep 2012 06:17:25 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-ie-doctors-06.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 13:17:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Guidelines for Authors and Reviewers of IPFIX Informatio= n Elements Author(s) : Brian Trammell Benoit Claise Filename : draft-ietf-ipfix-ie-doctors-06.txt Pages : 33 Date : 2012-09-26 Abstract: This document provides guidelines for the definition of IPFIX Information Elements for addition to the IANA IPFIX Information Element registry, in order to extend the applicability of the IPFIX protocol to new operations and management areas. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-ie-doctors There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-ie-doctors-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-ie-doctors-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sat Sep 29 04:35:12 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8849721F859A; Sat, 29 Sep 2012 04:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmBRE6IWLSzz; Sat, 29 Sep 2012 04:35:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0408421F8475; Sat, 29 Sep 2012 04:35:12 -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.34 Message-ID: <20120929113512.2019.55314.idtracker@ietfa.amsl.com> Date: Sat, 29 Sep 2012 04:35:12 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-information-model-rfc5102bis-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 11:35:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Information Model for IP Flow Information eXport (IPFIX) Author(s) : Benoit Claise Brian Trammell Filename : draft-ietf-ipfix-information-model-rfc5102bis-05.txt Pages : 27 Date : 2012-09-29 Abstract: This document provides an overview of the information model for the IP Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX Information Element Registry. It is used by the IPFIX Protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX Protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. This document obsoletes RFC 5102. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc5102= bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-information-model-rfc5102bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-information-model-rfc51= 02bis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Sat Sep 29 04:49:52 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769CC21F8555 for ; Sat, 29 Sep 2012 04:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.932 X-Spam-Level: X-Spam-Status: No, score=-6.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Te1pRCyJBooR for ; Sat, 29 Sep 2012 04:49:51 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C631E21F8550 for ; Sat, 29 Sep 2012 04:49:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 27F20D9309 for ; Sat, 29 Sep 2012 13:49:50 +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 xXhFQqX6qfKR for ; Sat, 29 Sep 2012 13:49:50 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E602BD9305 for ; Sat, 29 Sep 2012 13:49:49 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 29 Sep 2012 13:49:49 +0200 References: <20120929113512.2019.55314.idtracker@ietfa.amsl.com> To: IETF IPFIX Working Group Message-Id: Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [IPFIX] Fwd: I-D Action: draft-ietf-ipfix-information-model-rfc5102bis-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 11:49:52 -0000 Greetings, all, This revision of 5102bis fixes outstanding open issues on the draft, by = removing the the outdated table of NetFlow V9 information elements, and = harmonizes with changes to ie-doctors during IESG processing.=20 Cheers, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [IPFIX] I-D Action: = draft-ietf-ipfix-information-model-rfc5102bis-05.txt > Date: September 29, 2012 1:35:12 PM 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 : Information Model for IP Flow Information = eXport (IPFIX) > Author(s) : Benoit Claise > Brian Trammell > Filename : = draft-ietf-ipfix-information-model-rfc5102bis-05.txt > Pages : 27 > Date : 2012-09-29 >=20 > Abstract: > This document provides an overview of the information model for the IP > Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX > Information Element Registry. It is used by the IPFIX Protocol for > encoding measured traffic information and information related to the > traffic Observation Point, the traffic Metering Process, and the > Exporting Process. Although developed for the IPFIX Protocol, the = model > is defined in an open way that easily allows using it in other > protocols, interfaces, and applications. This document obsoletes RFC > 5102. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc510= 2bis >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-ipfix-information-model-rfc5102bis-0= 5 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-information-model-rfc5= 102bis-05 >=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