From owner-psamp@ops.ietf.org Wed Mar 01 04:21:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FENWb-00068G-BV for psamp-archive@lists.ietf.org; Wed, 01 Mar 2006 04:21:37 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEMwc-0003Zo-3i for psamp-archive@lists.ietf.org; Wed, 01 Mar 2006 03:44:26 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FEMhF-0002P2-7I for psamp-archive@lists.ietf.org; Wed, 01 Mar 2006 03:28:35 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEMZ0-000JHo-FZ for psamp-data@psg.com; Wed, 01 Mar 2006 08:20:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEMYy-000JH5-TK for psamp@ops.ietf.org; Wed, 01 Mar 2006 08:20:01 +0000 Received: from [83.65.114.87] (unknown [83.65.114.87]) by kyoto.netlab.nec.de (Postfix) with ESMTP id F330A1BAC4D; Wed, 1 Mar 2006 09:21:15 +0100 (CET) Date: Wed, 01 Mar 2006 09:19:55 +0100 From: Juergen Quittek To: Tanja Zseby , Benoit Claise Cc: psamp Subject: RE: Open Issue 6: Associations ID -> Selection Path Message-ID: <61CE19F9FEEBA1D617DA7D25@[83.65.114.87]> In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA1058FC9@EXCHSRV.fokus.fraunhofer.de> References: <804B13F8F3D94A4AB18B9B01ACB68FA1058FC9@EXCHSRV.fokus.fraunhofer.de> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Status: O Benoit and Tanja, It is good to rename the AssociationID. Would you mind using "selection sequence" or something equivalent) instead of "selection path"'? We have work on path-coupled packet selection (presented last session) and trajectory sampling along a path. Therefore, I am afraid that "selection path" might be confusing. Thanks, Juergen --On 2/27/06 12:59 PM +0100 Tanja Zseby wrote: > Hi Benoit, > > I will modify it in the PSAMP-TECH draft. > > Regards, > Tanja > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Monday, February 27, 2006 12:44 PM > To: Tanja Zseby > Cc: Benoit Claise; psamp > Subject: Re: Open Issue 6: Associations ID -> Selection Path > > Tanja, > > Will you modify the Associations ID into Selection Path in the next > [PSAMP-TECH] version? > Or should I add a short sentence in [PSAMP-PROTO]: "the Selection Path > is referred to as the Associations ID in [PSAMP-TECH]" > My personal choice, in order to avoid any confusion, would go for the > [PSAMP-TECH] modification. > > Regards, Benoit. >> Ok, I made the modifications for the new draft that I will be posting >> soon. >> >> Regards, Benoit. >>> Hi Benoit, >>> >>> I also prefer Selection Path. >>> >>> Kind regards, >>> Tanja >>> >>> Benoit Claise wrote: >>> >>>> Dear all, >>>> >>>> The PSAMP open issue 6 is the following: >>>> >>>> Even if the notion of Associations ID is mentioned in > [PSAMP-TECH], >>>> maybe a term such as SelectionPath or PathID would be more >>>> appropriate. >>>> >>>> The background of this issue is the following. >>>> [PSAMP-TECH] specifies the Associations ID like this: >>>> >>>> ASSOCIATIONS Values: >>> ID, IPFIX Exporting process ID, IDs of other associated >>>> processes> With STREAM ID: Observation point ID AND List of >>>> SELECTOR_IDs >>>> However, we concluded during the last IETF meeting that we don't >>>> need the IPFIX Metering and Exporting Process ID. >>>> So we're left with: >>>> >>>> Values: >>>> >>>> Since we don't associate anymore the observation point with >>>> processes, it was proposed to change the name: >>>> from "Associations ID" to "Selection Path" or "Path ID". >>>> >>>> Personally, I prefer the Selection Path term, along with the >>>> selectionPath I.E. >>>> For the simple reason that we speak of selection methods all over in > >>>> the PSAMP drafts. >>>> >>>> Feedback? >>>> >>>> Regards, Benoit. >>>> >>>> >>>> >>> >> >> >> -- >> to unsubscribe send a message to psamp-request@ops.ietf.org with the >> word 'unsubscribe' in a single line as the message text body. >> archive: > > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Wed Mar 01 05:35:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEObi-0004dc-4S for psamp-archive@lists.ietf.org; Wed, 01 Mar 2006 05:30:58 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEOTL-0007eI-Mp for psamp-archive@lists.ietf.org; Wed, 01 Mar 2006 05:22:21 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEONA-0001p6-9O for psamp-data@psg.com; Wed, 01 Mar 2006 10:15:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [193.174.154.14] (helo=mailhub.fokus.fraunhofer.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FENPt-000Mo6-C7 for psamp@ops.ietf.org; Wed, 01 Mar 2006 09:14:41 +0000 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id k219Ebv08687; Wed, 1 Mar 2006 10:14:37 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Open Issue 6: Associations ID -> Selection Path Date: Wed, 1 Mar 2006 10:14:41 +0100 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA1059080@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open Issue 6: Associations ID -> Selection Path Thread-Index: AcY9CP4JrdGc1ZLEQ7uah8ieXJLDIQAB2crw From: "Zseby, Tanja" To: "Juergen Quittek" , "Benoit Claise" Cc: "psamp" Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Status: O Hi J=FCrgen for me "selection sequence" sounds good. Regards, Tanja=20 > -----Original Message----- > From: Juergen Quittek [mailto:quittek@netlab.nec.de]=20 > Sent: Wednesday, March 01, 2006 9:20 AM > To: Zseby, Tanja; Benoit Claise > Cc: psamp > Subject: RE: Open Issue 6: Associations ID -> Selection Path >=20 > Benoit and Tanja, >=20 > It is good to rename the AssociationID. >=20 > Would you mind using "selection sequence" or something > equivalent) instead of "selection path"'? >=20 > We have work on path-coupled packet selection (presented last=20 > session) and trajectory sampling along a path. > Therefore, I am afraid that "selection path" might be confusing. >=20 > Thanks, >=20 > Juergen >=20 > --On 2/27/06 12:59 PM +0100 Tanja Zseby wrote: >=20 > > Hi Benoit, > > > > I will modify it in the PSAMP-TECH draft. > > > > Regards, > > Tanja > > -----Original Message----- > > From: Benoit Claise [mailto:bclaise@cisco.com] > > Sent: Monday, February 27, 2006 12:44 PM > > To: Tanja Zseby > > Cc: Benoit Claise; psamp > > Subject: Re: Open Issue 6: Associations ID -> Selection Path > > > > Tanja, > > > > Will you modify the Associations ID into Selection Path in the next=20 > > [PSAMP-TECH] version? > > Or should I add a short sentence in [PSAMP-PROTO]: "the=20 > Selection Path=20 > > is referred to as the Associations ID in [PSAMP-TECH]" > > My personal choice, in order to avoid any confusion, would=20 > go for the=20 > > [PSAMP-TECH] modification. > > > > Regards, Benoit. > >> Ok, I made the modifications for the new draft that I will=20 > be posting=20 > >> soon. > >> > >> Regards, Benoit. > >>> Hi Benoit, > >>> > >>> I also prefer Selection Path. > >>> > >>> Kind regards, > >>> Tanja > >>> > >>> Benoit Claise wrote: > >>> > >>>> Dear all, > >>>> > >>>> The PSAMP open issue 6 is the following: > >>>> > >>>> Even if the notion of Associations ID is mentioned in > > [PSAMP-TECH], > >>>> maybe a term such as SelectionPath or PathID would be more=20 > >>>> appropriate. > >>>> > >>>> The background of this issue is the following. > >>>> [PSAMP-TECH] specifies the Associations ID like this: > >>>> > >>>> ASSOCIATIONS Values: >>>> ID, IPFIX Exporting process ID, IDs of other associated > >>>> processes> With STREAM ID: Observation point ID AND List of > >>>> SELECTOR_IDs > >>>> However, we concluded during the last IETF meeting that we don't=20 > >>>> need the IPFIX Metering and Exporting Process ID. > >>>> So we're left with: > >>>> > >>>> Values: > >>>> > >>>> Since we don't associate anymore the observation point with=20 > >>>> processes, it was proposed to change the name: > >>>> from "Associations ID" to "Selection Path" or "Path ID". > >>>> > >>>> Personally, I prefer the Selection Path term, along with the=20 > >>>> selectionPath I.E. > >>>> For the simple reason that we speak of selection methods=20 > all over=20 > >>>> in > > > >>>> the PSAMP drafts. > >>>> > >>>> Feedback? > >>>> > >>>> Regards, Benoit. > >>>> > >>>> > >>>> > >>> > >> > >> > >> -- > >> to unsubscribe send a message to=20 > psamp-request@ops.ietf.org with the=20 > >> word 'unsubscribe' in a single line as the message text body. > >> archive: > > > > > > -- > > to unsubscribe send a message to psamp-request@ops.ietf.org=20 > with the=20 > > word 'unsubscribe' in a single line as the message text body. > > archive: >=20 >=20 >=20 -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Wed Mar 01 05:51:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEOvp-0000tI-DC for psamp-archive@lists.ietf.org; Wed, 01 Mar 2006 05:51:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEOvo-0000QB-0A for psamp-archive@lists.ietf.org; Wed, 01 Mar 2006 05:51:45 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEOqi-0004hE-FF for psamp-data@psg.com; Wed, 01 Mar 2006 10:46:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEOqh-0004gz-9k for psamp@ops.ietf.org; Wed, 01 Mar 2006 10:46:27 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k21AkPx20854; Wed, 1 Mar 2006 11:46:25 +0100 (CET) Received: from [10.61.65.71] (ams-clip-vpn-dhcp327.cisco.com [10.61.65.71]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k21AkOC26239; Wed, 1 Mar 2006 11:46:24 +0100 (CET) Message-ID: <44057B81.1020702@cisco.com> Date: Wed, 01 Mar 2006 11:46:25 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Juergen Quittek CC: Tanja Zseby , psamp Subject: Re: Open Issue 6: Associations ID -> Selection Path References: <804B13F8F3D94A4AB18B9B01ACB68FA1058FC9@EXCHSRV.fokus.fraunhofer.de> <61CE19F9FEEBA1D617DA7D25@[83.65.114.87]> In-Reply-To: <61CE19F9FEEBA1D617DA7D25@[83.65.114.87]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Status: O Juergen, > Benoit and Tanja, > > It is good to rename the AssociationID. > > Would you mind using "selection sequence" or something > equivalent) instead of "selection path"'? Because it contains both the observation point and the selector id(s), "selection path" was selected. "selection sequence" tends to say it's only composed of selector id(s). However, if there is no confusion, this terminology becomes a point of detail. In conclusion: I will change the "Selection Path" to "Selection Sequence", unless someone objects. Regards, Benoit. > > We have work on path-coupled packet selection (presented > last session) and trajectory sampling along a path. > Therefore, I am afraid that "selection path" might be > confusing. > > Thanks, > > Juergen > > --On 2/27/06 12:59 PM +0100 Tanja Zseby wrote: > >> Hi Benoit, >> >> I will modify it in the PSAMP-TECH draft. >> >> Regards, >> Tanja >> -----Original Message----- >> From: Benoit Claise [mailto:bclaise@cisco.com] >> Sent: Monday, February 27, 2006 12:44 PM >> To: Tanja Zseby >> Cc: Benoit Claise; psamp >> Subject: Re: Open Issue 6: Associations ID -> Selection Path >> >> Tanja, >> >> Will you modify the Associations ID into Selection Path in the next >> [PSAMP-TECH] version? >> Or should I add a short sentence in [PSAMP-PROTO]: "the Selection Path >> is referred to as the Associations ID in [PSAMP-TECH]" >> My personal choice, in order to avoid any confusion, would go for the >> [PSAMP-TECH] modification. >> >> Regards, Benoit. >>> Ok, I made the modifications for the new draft that I will be posting >>> soon. >>> >>> Regards, Benoit. >>>> Hi Benoit, >>>> >>>> I also prefer Selection Path. >>>> >>>> Kind regards, >>>> Tanja >>>> >>>> Benoit Claise wrote: >>>> >>>>> Dear all, >>>>> >>>>> The PSAMP open issue 6 is the following: >>>>> >>>>> Even if the notion of Associations ID is mentioned in >> [PSAMP-TECH], >>>>> maybe a term such as SelectionPath or PathID would be more >>>>> appropriate. >>>>> >>>>> The background of this issue is the following. >>>>> [PSAMP-TECH] specifies the Associations ID like this: >>>>> >>>>> ASSOCIATIONS Values: >>>> ID, IPFIX Exporting process ID, IDs of other associated >>>>> processes> With STREAM ID: Observation point ID AND List of >>>>> SELECTOR_IDs >>>>> However, we concluded during the last IETF meeting that we don't >>>>> need the IPFIX Metering and Exporting Process ID. >>>>> So we're left with: >>>>> >>>>> Values: >>>>> >>>>> Since we don't associate anymore the observation point with >>>>> processes, it was proposed to change the name: >>>>> from "Associations ID" to "Selection Path" or "Path ID". >>>>> >>>>> Personally, I prefer the Selection Path term, along with the >>>>> selectionPath I.E. >>>>> For the simple reason that we speak of selection methods all over in >> >>>>> the PSAMP drafts. >>>>> >>>>> Feedback? >>>>> >>>>> Regards, Benoit. >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> to unsubscribe send a message to psamp-request@ops.ietf.org with the >>> word 'unsubscribe' in a single line as the message text body. >>> archive: >> >> >> -- >> to unsubscribe send a message to psamp-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Wed Mar 01 17:21:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEZgz-0001d9-4b for psamp-archive@lists.ietf.org; Wed, 01 Mar 2006 17:21:09 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEZgy-0000q3-8P for psamp-archive@lists.ietf.org; Wed, 01 Mar 2006 17:21:09 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEZa4-000BLf-RL for psamp-data@psg.com; Wed, 01 Mar 2006 22:14:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_50_60,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEZa2-000BLQ-7n for psamp@ops.ietf.org; Wed, 01 Mar 2006 22:13:58 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k21MDuu05179 for ; Wed, 1 Mar 2006 23:13:56 +0100 (CET) Received: from [10.61.65.71] (ams-clip-vpn-dhcp327.cisco.com [10.61.65.71]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k21MDtC19926 for ; Wed, 1 Mar 2006 23:13:55 +0100 (CET) Message-ID: <44061CA3.8010708@cisco.com> Date: Wed, 01 Mar 2006 23:13:55 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: psamp Subject: PROTO-08: Selection Sequence Statistics Report Interpretation Content-Type: multipart/alternative; boundary="------------030602050004000908010702" Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4a4195ffb11c7b0baf82f77b2a730aa9 Status: O This is a multi-part message in MIME format. --------------030602050004000908010702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is a text proposal for the issue 8 PROTO-08 Instead of sending the input sequence number for each selector ID, a counter64 value, associated with every packet, the working group should discuss the possibility to send the information on regular basis with an option template record. Specifically in the case of Composite Selector, we would send multiple times a 64-bit counter in each packet. Regards, Benoit. 7.4.3 Selection Sequence Statistics Report Interpretation A Selector MAY be used in multiple Selection Sequences. However, each use of a Selector must be independent, so each separate logical instance of a Selector MUST maintain its own individual Selection State and statistics. The Selection Sequence Statistics Report Interpretation MUST include the number of observed packets (Population Size) and the number of packets selected (Sample Size) by each instance of its Primitive Selectors. Within a Selection Sequence composed of several Primitive Selectors, the number of packets selected for one Selector is equal to the number of packets observed by the next Selector. The order of the Selectors in the Selection Sequence Statistics Report Interpretation MUST match the order of the Selectors in the Selection Sequence. For every Selection Sequence, the PSAMP Device MUST periodically export a Selection Sequence Statistics Report Interpretation using an Options Template containing the following Information Elements: Scope: selectionSequenceId Non-scope: packetsObserved packetsSelected (first) ... packetsSelected (last) The packetsObserved Information Element [PSAMP-INFO] MUST contain the number of packets seen at the Observation Point, and as a consequence passed to the first Selector in the Selection Sequence. The packetsSelected Information Element [PSAMP-INFO] contains the number of packets selected by a Selector in the Selection Sequence. The Attained Selection Fraction for the Selection Sequence is calculated by dividing the number of observed packets (packetsObserved Information Element) by the value of selected packets (packetsSelected Information Element) for the last Selector. The Attained Selection Fraction can be calculated for each Selector by dividing the number of packets selected for that Selector by the value for the previous Selector. The statistics for the whole sequence SHOULD be taken at a single logical point in time, the input value for a Selector MUST equal the output value of the previous selector. The Selection Sequence Statistics Report Interpretation MUST be exported periodically[CSI1] . Example of Selection Sequence [CSI2] Statistics Report Interpretation: Selection Sequence 7 (Filter->Sampling): Observed 100 (observationPointId 1, Interface 5) Selected 50 (selectorId 5, match IPV4SourceAddress 10.0.0.1) Selected 6 (selectorId 10, Sampler: Random one out-of ten) Selection Sequence 9 (Sampling->Filtering): Observed 100 (observationPointId 1, Interface 5) Selected 10 (selectorId 10, Sampler: Random one out-of ten) Selected 3 (selectorId 5, match IPV4SourceAddress 10.0.0.1) IPFIX Options Template Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 267 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 |0| selectionSequenceId = 301 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Length = 4 |0| packetsObserved = 318 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| packetsSelected = 319 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| packetsSelected = 319 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The associated IPFIX Data Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 267 | Length = 36 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 50 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure K: Example of the Selection Sequence Statistics Report Interpretation Notes: * The Attained Packet Fractions for Selection Sequence 7 are: Filter 10: 50/100 Sampler 5: 6/50 Number of samples selected: 6 * The Attained Packet Fractions for Selection Sequence 9 are: Sampler 5: 10/100 Filter 10: 3/10 Number of samples selected: 3 7.3.1 Basic Packet Reports For each selected packet, the Packet Report MUST contain the following information: - The selectionSequenceId Information Element - Some number of contiguous bytes from the start of the packet, including the packet header (which includes link layer, network layer and other encapsulation headers) and some subsequent bytes of the packet payload. Alternatively, the number of contiguous bytes may start at the beginning of the payload. The dataLinkFrameSection, mplsLabelStackSection, mplsPayloadPacketSection, ipPacketSection, and ipPayloadPacketSection PSAMP Information Elements are available for this use. In the Packet Report, the PSAMP device MUST be capable of exporting the number of observed packets and the number of packets selected by each instance of its Primitive Selectors (as described by the non scope Information Element of the Selection Sequence Statistics Report Interpretation) although it MAY be a configurable option not to include them. If exported, the Attained Selection Fraction may be calculated precisely for the Observed Packet Stream. The Packet Report MAY include only the final selector packetSelected, to act as an index for that selection sequence in the Selection Sequence Statistics Report Interpretation, which also allows the calculation of the Attained Selection Fraction. The contiguous Information Elements ... --------------030602050004000908010702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Here is a text proposal for the issue 8
PROTO-08 Instead of sending the input sequence number for each 
   selector ID, a counter64 value, associated with every packet, the 
   working group should discuss the possibility to send the information 
   on regular basis with an option template record. Specifically in the 
   case of Composite Selector, we would send multiple times a 64-bit 
   counter in each packet. 

Regards, Benoit.
7.4.3    Selection Sequence Statistics Report Interpretation
A Selector MAY be used in multiple Selection Sequences.  However, each use of a Selector must be independent, so each separate logical instance of a Selector MUST maintain its own individual Selection State and statistics.

The Selection Sequence Statistics Report Interpretation MUST include the number of observed packets (Population Size) and the number of packets selected (Sample Size) by each instance of its Primitive Selectors.
Within a Selection Sequence composed of several Primitive Selectors, the number of packets selected for one Selector is equal to the number of packets observed by the next Selector.  The order of the Selectors in the Selection Sequence Statistics Report Interpretation MUST match the order of the Selectors in the Selection Sequence.
For every Selection Sequence, the PSAMP Device MUST periodically export a Selection Sequence Statistics Report Interpretation using an Options Template containing the following Information Elements:
 Scope:         selectionSequenceId
 Non-scope:  packetsObserved
                     packetsSelected (first)
                     …
                     packetsSelected (last)
 
The packetsObserved Information Element [PSAMP-INFO] MUST contain the number of packets seen at the Observation Point, and as a consequence passed to the first Selector in the Selection Sequence.  The packetsSelected Information Element [PSAMP-INFO] contains the number of packets selected by a Selector in the Selection Sequence.
 
The Attained Selection Fraction for the Selection Sequence is calculated by dividing the number of observed packets (packetsObserved Information Element) by the value of selected packets (packetsSelected Information Element) for the last Selector.  The Attained Selection Fraction can be calculated for each Selector by dividing the number of packets selected for that Selector by the value for the previous Selector.
 
The statistics for the whole sequence SHOULD be taken at a single logical point in time, the input value for a Selector MUST equal the output value of the previous selector.
 
The Selection Sequence Statistics Report Interpretation MUST be exported periodically[CSI1] .
 
Example of Selection Sequence [CSI2] Statistics Report Interpretation:
 
 Selection Sequence 7 (Filter->Sampling):
 
   Observed   100  (observationPointId  1, Interface 5)
   Selected    50  (selectorId  5, match IPV4SourceAddress 10.0.0.1)
   Selected     6  (selectorId 10, Sampler: Random one out-of ten)
 
 Selection Sequence 9 (Sampling->Filtering):
 
   Observed   100  (observationPointId  1, Interface 5)
   Selected    10  (selectorId 10, Sampler: Random one out-of ten)
   Selected     3  (selectorId  5, match IPV4SourceAddress 10.0.0.1)
 
IPFIX Options Template Record:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Set ID = 3         |           Length = 26         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Template ID = 267       |        Field Count = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Scope Field Count = 1     |0|  selectionSequenceId = 301  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Scope 1 Length = 4       |0|    packetsObserved = 318    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Field Length = 4        |0|    packetsSelected = 319    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Field Length = 4        |0|    packetsSelected = 319    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The associated IPFIX Data Record:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Set ID =  267       |          Length = 36          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               7                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              100                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              50                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               6                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               9                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              100                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              10                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               3                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    Figure K: Example of the Selection Sequence Statistics Report            
              Interpretation
             
Notes:
* The Attained Packet Fractions for Selection Sequence 7 are:
         Filter 10: 50/100
         Sampler 5: 6/50
         Number of samples selected: 6
 
* The Attained Packet Fractions for Selection Sequence 9 are:
         Sampler 5: 10/100
         Filter 10: 3/10
         Number of samples selected: 3
 
 
7.3.1 Basic Packet Reports
    
For each selected packet, the Packet Report MUST contain the following information:
- The selectionSequenceId Information Element
- Some number of contiguous bytes from the start of the packet, including the packet header (which includes link layer, network layer and other encapsulation headers) and some subsequent bytes of the packet payload.  Alternatively, the number of contiguous bytes may start at the beginning of the payload. The dataLinkFrameSection, mplsLabelStackSection, mplsPayloadPacketSection, ipPacketSection, and ipPayloadPacketSection PSAMP Information Elements are available for this use. 

In the Packet Report, the PSAMP device MUST be capable of exporting the number of observed packets and the number of packets selected by each instance of its Primitive Selectors (as described by the non scope Information Element of the Selection Sequence Statistics Report Interpretation) although it MAY be a configurable option not to include them. If exported, the Attained Selection Fraction may be calculated precisely for the Observed Packet Stream. The Packet Report MAY include only the final selector packetSelected, to act as an index for that selection sequence in the Selection Sequence Statistics Report Interpretation, which also allows the calculation of the Attained Selection Fraction.

The contiguous Information Elements ...



--------------030602050004000908010702-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 08:22:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEnkq-0003Bf-Rk for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 08:22:05 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEnkp-0005lh-IO for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 08:22:04 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEnem-000AJS-9Y for psamp-data@psg.com; Thu, 02 Mar 2006 13:15:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEnel-000AIi-J7 for psamp@ops.ietf.org; Thu, 02 Mar 2006 13:15:47 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 02 Mar 2006 14:15:47 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k22DFk36028055 for ; Thu, 2 Mar 2006 14:15:46 +0100 (MET) Received: from [144.254.153.22] (dhcp-144-254-153-22.cisco.com [144.254.153.22]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA24206 for ; Thu, 2 Mar 2006 13:15:45 GMT Message-ID: <4406F001.8060701@cisco.com> Date: Thu, 02 Mar 2006 13:15:45 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.10) Gecko/20050811 Fedora/1.7.10-1.2.1.legacy X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: psamp@ops.ietf.org Subject: PSAMP archive Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Status: O Who looks after the PSAMP archive? The 2006 archive doesn't default to the Mail Thread Index as previous years do: http://ops.ietf.org/lists/psamp/psamp.2006/ -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 09:00:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEoLs-0007WI-Rz for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 09:00:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEoLs-0007O1-9k for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 09:00:20 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEoHy-000Dd0-V7 for psamp-data@psg.com; Thu, 02 Mar 2006 13:56:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_30_40,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEoHy-000Dco-06 for psamp@ops.ietf.org; Thu, 02 Mar 2006 13:56:18 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k22DuGA04619 for ; Thu, 2 Mar 2006 14:56:16 +0100 (CET) Received: from [10.61.64.255] (ams-clip-vpn-dhcp255.cisco.com [10.61.64.255]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k22DuFC25387 for ; Thu, 2 Mar 2006 14:56:15 +0100 (CET) Message-ID: <4406F97F.9060909@cisco.com> Date: Thu, 02 Mar 2006 14:56:15 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: psamp Subject: PROTO-11: Accuracy Report Interpretation Content-Type: multipart/alternative; boundary="------------080305020706000206000400" Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Status: O This is a multi-part message in MIME format. --------------080305020706000206000400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, We need a way of specifying the accuracy of our reported information, as PSAMP frameworks specifies: "the Report Stream must include information that enables the accuracy of measurements to be determined.". Here is some proposed text. _Section 7.4.4 Accuracy Report Interpretation_ In order for the Collecting Process to determine the inherent accuracy of the reported quantities (for example timestamps), the PSAMP Device SHOULD send an Accuracy Report Interpretation. The Accuracy Report Interpretation MUST be exported by an Option Template Record with a double scope that contains the TemplateId [PSAMP-INFO] and the Information Element for which the accuracy is required. The accuracy SHOULD be reported either with the fixedAccuracy Information Element [PSAMP-INFO], or with the proportionalAccuracy Information Element [PSAMP-INFO]. Accuracy Report Interpretation using the fixedAccuracy Information Element Scope: TemplateId InformationElementId Non-scope: fixedAccuracy Accuracy Report Interpretation using the proportionalAccuracy Information Element Scope: TemplateId InformationElementId Non-scope: proportionalAccuracy For example, the accuracy of an Information Element whose Abstract Data Type is dateTimeMilliSeconds [IPFIX-INFO], for which the unit is specified as milliseconds, can be specified with the fixedAccuracy Information Element with the milliseconds units. In this case, the accuracy is the Information Element value +/- the value reported in the fixedAccuracy. For example, the accuracy of an Information Element to estimate the accuracy of a sampled flow, for which the unit would be specified in octets, can be specified with the proportionalAccuracy Information Element with the octet units. In this case, the accuracy is the Information Element value +/- the value reported in the proportionalAccuracy time Information Element value. Alternatively to reporting either the fixedAccuracy Information Element or the proportionalAccuracy Information Element in the Accuracy Report Interpretation, both Information Elements MAY be present. This scenario could help in more complex situations where the system clock drifts, on the top of having its own accuracy, during the duration of a measurement. If the accuracy of a reported quantity changes on the Metering Process, a new Accuracy Report Interpretation MUST be generated. The Collecting Process MUST keep the accuracy of the latest Accuracy Report Interpretation. Example 1 (to be developed) Records (using template 12): 1. Scope: TemplateId = 5, InformationElementId = 152 Non-scope: fixedAccuracy = 2 => we have a accuracy of +/- 2ms) Example 2 (to be developed): 1. Scope: TemplateId = 5, InformationElementId = 152 Non-scope: proportionalAccuracy = 0.005 => we had an accuracy of +/- 0.5% --------------------- For the PSAMP information model: fixedAccuracy Description: Describes the accuracy of an Information Element, as a negative and positive relative error in absolute value. Abstract Data Type: float64 ElementId: 320 Status: current Units: The units of the Information Element for which is accuracy is specified. proportionalAccuracy Description: Describes the accuracy of an Information Element as a negative and positive relative error, expressed as a value between 0 and 1. Abstract Data Type: float64 ElementId: 321 Status: current Units: None informationElementID Description: Contains the ID of another Information Element. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 303 Status: current Units: None Regards, Benoit. --------------080305020706000206000400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

We need a way of specifying the accuracy of our reported information, as PSAMP frameworks specifies: "the Report Stream must include information that enables the accuracy of measurements to be determined.". Here is some proposed text.

Section 7.4.4 Accuracy Report Interpretation

In order for the Collecting Process to determine the inherent accuracy of the reported quantities (for example timestamps), the PSAMP Device SHOULD send an Accuracy Report Interpretation. 

The Accuracy Report Interpretation MUST be exported by an Option Template Record with a double scope that contains the TemplateId [PSAMP-INFO] and the Information Element for which the accuracy is required.  The accuracy SHOULD be reported either with the fixedAccuracy Information Element [PSAMP-INFO], or with the proportionalAccuracy Information Element [PSAMP-INFO].

Accuracy Report Interpretation using the fixedAccuracy Information Element
 Scope:            TemplateId
                        InformationElementId
 Non-scope:     fixedAccuracy

Accuracy Report Interpretation using the proportionalAccuracy Information Element
 Scope:            TemplateId
                        InformationElementId
 Non-scope:     proportionalAccuracy

For example, the accuracy of an Information Element whose Abstract Data Type is dateTimeMilliSeconds [IPFIX-INFO], for which the unit is specified as milliseconds, can be specified with the fixedAccuracy Information Element with the milliseconds units. In this case, the accuracy is the Information Element value +/- the value reported in the fixedAccuracy.

For example, the accuracy of an Information Element to estimate the accuracy of a sampled flow, for which the unit would be specified in octets, can be specified with the proportionalAccuracy Information Element with the octet units. In this case, the accuracy is the Information Element value +/- the value reported in the proportionalAccuracy time Information Element value.

Alternatively to reporting either the fixedAccuracy Information Element or the proportionalAccuracy Information Element in the Accuracy Report Interpretation, both Information Elements MAY be present. This scenario could help in more complex situations where the system clock drifts, on the top of having its own accuracy, during the duration of a measurement.

If the accuracy of a reported quantity changes on the Metering Process, a new Accuracy Report Interpretation MUST be generated. The Collecting Process MUST keep the accuracy of the latest Accuracy Report Interpretation.

Example 1 (to be developed)
Records (using template 12):
1. Scope: TemplateId = 5, InformationElementId = 152
Non-scope: fixedAccuracy = 2
=> we have a accuracy of +/- 2ms)

Example 2 (to be developed):
1. Scope: TemplateId = 5, InformationElementId = 152
Non-scope: proportionalAccuracy = 0.005
=> we had an accuracy of  +/- 0.5%


---------------------
For the PSAMP information model:

fixedAccuracy
   Description:
      Describes the accuracy of an Information Element, as a negative
      and positive relative error in absolute value.
   Abstract Data Type: float64
   ElementId: 320
   Status: current
   Units: The units of the Information Element for which is accuracy is
      specified.

proportionalAccuracy
Description:
      Describes the accuracy of an Information Element as a negative
      and positive relative error, expressed as a value between 0 and 1.
   Abstract Data Type: float64
   ElementId: 321
   Status: current
   Units: None

 informationElementID
 Description:
      Contains the ID of another Information Element.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 303
   Status: current
   Units: None

Regards, Benoit.
--------------080305020706000206000400-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 09:47:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEp5W-0001A1-Pq for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 09:47:30 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEp5W-0000sh-D7 for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 09:47:30 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEp1A-000H7r-HH for psamp-data@psg.com; Thu, 02 Mar 2006 14:43:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEp19-000H6a-73 for psamp@ops.ietf.org; Thu, 02 Mar 2006 14:42:59 +0000 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 596221BAC99; Thu, 2 Mar 2006 15:44:08 +0100 (CET) Date: Thu, 02 Mar 2006 15:42:58 +0100 From: Juergen Quittek To: Benoit Claise , Andrew Johnson Cc: psamp Subject: Re: PSAMP open issue 18: export rate limit? Message-ID: In-Reply-To: <44046E19.9060100@cisco.com> References: <43A9F344.8010308@cisco.com> <43AC191B.6080803@cisco.com> <44046E19.9060100@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Status: O Ho Benoit, --On 2/28/06 4:36 PM +0100 Benoit Claise wrote: > Dear all, > > After speaking with Andrew and Paul, here is a proposal: > There MUST be a IPFIX Message export rate limit, configurable per Exporting Process. > The Exporting Process MAY rate-limit the export rate on a per Collecting Process basis. I agree with the idea of requesting means for limiting the export rate. I am not sure that we should request that this feature is always enabled as the text above implies by stating "There MUST be ...". Also I do not see a strong reason for requesting that configurability per Exporting Process as a MUST. A single value for all Exporting Processes at a device should be sufficient. What about "An Exporting Process MUST be able to limit the export rate according to a configurable value. The Exporting Process MAY limit the export rate on a per Collecting Process basis." ? Thanks, Juergen > Feedback? > > Regards, Benoit. > >> Hello Benoit and all. >> >> Benoit Claise wrote: >>> Dear all, >>> >>> In [PSAMP-FMWK], the following statement is still un-addressed in >>> [PSAMP-PROTO] >>> PROTO-18 =93The exporting process must have an export rate limit, >>> configurable per Exporting Process=94. >>> See section 8.3 for the details >>> http://www.ietf.org/internet-drafts/draft-ietf-psamp-framework-10.txt >>> >>> >>> First of all, I have a question regarding the requirement itself. >>> Isn't it supposed to mean: =93The exporting process must have an export >>> rate limit, configurable per Collecting Process=94? Otherwise, I don't >>> understand the exact requirement when we have a PSAMP device >>> exporting to multiple collectors! >> >> I would say that each Exporting Process exports to only one collector, >> but can be fed by multiple Metering Processes. Also, each Metering >> Process may feed Multiple Exporting Processes. With this concept we >> can rate limit the Exporting Process and it will only affect one >> collector. >> >> >>> Then, how to address the requirement? >>> Shall we simply update [PSAMP-PROTO] with a sentence such as: "The >>> exporting process MUST have an export rate limit, configurable per >>> Collecting Process"? >>> And that's it? >> >> If we agree that one Exporting Process deals with only one collector >> then this simplifies matters. >> >> >>> Do we keep the export rate limit as a generic term? Or do we define >>> precisely what it mean? Example: number of IPFIX Messages, number of >>> bytes/s, number of records/s? >> >> I think we should pick a MUST, such as we MUST be able to rate limit >> based on the number of data and option records per second, but you MAY >> rate limit on other criteria also, such as bandwidth. This will allow >> some common ground between implementations, useful for people who buy >> from multiple vendors. >> >> Regards >> >> Andrew > > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 09:58:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpGc-0001PD-4s for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 09:58:58 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEpGb-0001IY-N7 for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 09:58:58 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEpDr-000I33-7D for psamp-data@psg.com; Thu, 02 Mar 2006 14:56:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEpDp-000I2p-Uz for psamp@ops.ietf.org; Thu, 02 Mar 2006 14:56:06 +0000 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B198C1BAC4D; Thu, 2 Mar 2006 15:57:15 +0100 (CET) Date: Thu, 02 Mar 2006 15:56:04 +0100 From: Juergen Quittek To: Benoit Claise , psamp Subject: Re: PROTO-12: The observation point report interpretation Message-ID: <688973113917F9A8C7B9B38B@[192.168.1.128]> In-Reply-To: <4404D188.40506@cisco.com> References: <4404D188.40506@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Status: O --On 2/28/06 11:41 PM +0100 Benoit Claise wrote: > Dear all, > > During the last IETF meeting, we discussed the PSAMP issue 12. > > PROTO-12 Discuss how to implement the observation point report > interpretation (if we need one) > The "Associations Report Interpretation" in http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-03.txt, which BTW has been renamed to "Select Path Report Interpretation", currently contains the observationPointId information element, amongst > others: > > Scope: selectionPath > Non-Scope: observationPointId > selectorId (one or more) > > Note that the section also specifies: > > The observationPointID SHOULD be first Information Element and the > optional processes SHOULD be last ones so that the path of the > selected Packet is provided in the logical order. > > [PSAMP-INFO] currently specifies: > > > 6.2.19 observationPointId > > Description: > ID of the observation process. Unique in the observation domain. > Abstract Data Type: octet > ElementId: 320 > > The issue is that a mapping between the observationPointId and the > existing information element(s) such as interfaceId, lineCardId, > or routerId is required, adding some complexity in PSAMP, as yet > another option template is required. > The proposal is that: > 1. we don't define the observationPointId in [PSAMP-INFO], but we > use the any information element (such as interfaceId, lineCardId, > or routerId) to define the observation point This would work as long as there is never a confusion between a selector ID and one of the types used for specifying the observation point. We would avoid this potential hazard by using the observationPointId. The disadvantage in that case would be the need for another option record that specified the observation point identified by that ID. > 2. as the "Select Path Report Interpretation" is composed only of > one observation point and selector Id(s), we simply assume that > the non-selector ID(s) is the observation point. This way, we > avoid the sentence "The observationPointID SHOULD be first > Information Element and the optional processes SHOULD be last ones ." > that impose a new rule in IPFIX: the meaning of a specific I.E. > depends on the order of the I.E. in the record I do not like this approach. If we keep the IE observationPointId, there is no need to care about the position in the option record where it occurs, because its semantics is always clear. > 3. If a more complex observation point is required such as an unique > ID representing a list of interfaces, a new Information Element is > defined and can be used right away. What about a combination of 1. and 3.? We could allow 1. for simple observation points that can be unambiguously identified by an identifier such as the lineCardId. In case of a complex observation point, say three line cards, we could use an observationPointId and have another option record that defines the observation point that is identified by observationPointId. Juergen > Note: an alternate solution would be to have 2 scopes in the "Select > Path Report Interpretation": the selectionPath, and the observation > point. However, this was not considered as a clean solution. > > Here is the text proposal > > Selection Path Report Interpretation > > Each Packet Report contains a selectionPath Information Element that identifies the particular combination of Observation Point and Selector(s) used for its selection. For every selectionPath Information Element in use, the PSAMP Device MUST export a > Selection Path Report Interpretation using an Options Template with the following Information Element: > > Scope: selectionPath > Non-Scope: one Information Element representing the Observation Point > selectorId (one or more) > > The Information Element representing the Observation Point would typically be taken from the ingressInterface, egressInterface, lineCardId, exporterIPv4Address, exporterIPv6Address (specified in [IPFIX-INFO]), but not limited to those: any Information > Element specified in [IFPIX-INFO] or [PSAMP-INFO] can potentially be used. In case of more complex Observation Points (such as a list of interfaces, a bus, etc..), a new Information Element describing the new type of Observation Point must be > specified, along with an option template record describing it in more details (if necessary). > > > If the packets are selected by a Composite Selector, the Selection Path is composed of several Primitive Selectors. In such a case, the Selection Path Report Interpretation MUST contain the list of all the Primitive Selector IDs in the Selection Path. > If multiple Selectors are contained in the Selection Path Report Interpretation, the Selectors ID MUST be identified in the order they are used. > > > > Any feedback? > > > > Regards, Benoit. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 10:07:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpPH-00016i-K3 for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 10:07:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEpPH-0001fe-4f for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 10:07:55 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEpKq-000IfE-6l for psamp-data@psg.com; Thu, 02 Mar 2006 15:03:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEpKo-000If0-V9 for psamp@ops.ietf.org; Thu, 02 Mar 2006 15:03:19 +0000 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 2BFBB1BAC4D; Thu, 2 Mar 2006 16:04:28 +0100 (CET) Date: Thu, 02 Mar 2006 16:03:18 +0100 From: Juergen Quittek To: Benoit Claise , psamp Subject: Re: PROTO-08: Selection Sequence Statistics Report Interpretation Message-ID: <1277B05CBF0731622E0C893B@[192.168.1.128]> In-Reply-To: <44061CA3.8010708@cisco.com> References: <44061CA3.8010708@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Status: O --On 3/1/06 11:13 PM +0100 Benoit Claise wrote: > Dear all, > > Here is a text proposal for the issue 8 > > PROTO-08 Instead of sending the input sequence number for each > selector ID, a counter64 value, associated with every packet, the > working group should discuss the possibility to send the information > on regular basis with an option template record. Specifically in the > case of Composite Selector, we would send multiple times a 64-bit > counter in each packet. I think we should be open for both ways of reporting, i.e. we should allow an implementation to have all counters in each record as well as to send current counter values in option records only now and then. I will send detailed comments on the text below tonight. Thanks, Juergen > Regards, Benoit. > > > > 7.4.3 Selection Sequence Statistics Report Interpretation > A Selector MAY be used in multiple Selection Sequences. However, each use of a Selector must be independent, so each separate logical instance of a Selector MUST maintain its own individual Selection State and statistics. > > The Selection Sequence Statistics Report Interpretation MUST include the number of observed packets (Population Size) and the number of packets selected (Sample Size) by each instance of its Primitive Selectors. > Within a Selection Sequence composed of several Primitive Selectors, the number of packets selected for one Selector is equal to the number of packets observed by the next Selector. The order of the Selectors in the Selection Sequence Statistics > Report Interpretation MUST match the order of the Selectors in the Selection Sequence. > For every Selection Sequence, the PSAMP Device MUST periodically export a Selection Sequence Statistics Report Interpretation using an Options Template containing the following Information Elements: > Scope: selectionSequenceId > Non-scope: packetsObserved > packetsSelected (first) > ... > packetsSelected (last) > > The packetsObserved Information Element [PSAMP-INFO] MUST contain the number of packets seen at the Observation Point, and as a consequence passed to the first Selector in the Selection Sequence. The packetsSelected Information Element [PSAMP-INFO] > contains the number of packets selected by a Selector in the Selection Sequence. > > The Attained Selection Fraction for the Selection Sequence is calculated by dividing the number of observed packets (packetsObserved Information Element) by the value of selected packets (packetsSelected Information Element) for the last Selector. The > Attained Selection Fraction can be calculated for each Selector by dividing the number of packets selected for that Selector by the value for the previous Selector. > > The statistics for the whole sequence SHOULD be taken at a single logical point in time, the input value for a Selector MUST equal the output value of the previous selector. > > The Selection Sequence Statistics Report Interpretation MUST be exported periodically[CSI1] . > > Example of Selection Sequence [CSI2] Statistics Report Interpretation: > > Selection Sequence 7 (Filter->Sampling): > > Observed 100 (observationPointId 1, Interface 5) > Selected 50 (selectorId 5, match IPV4SourceAddress 10.0.0.1) > Selected 6 (selectorId 10, Sampler: Random one out-of ten) > > Selection Sequence 9 (Sampling->Filtering): > > Observed 100 (observationPointId 1, Interface 5) > Selected 10 (selectorId 10, Sampler: Random one out-of ten) > Selected 3 (selectorId 5, match IPV4SourceAddress 10.0.0.1) > > IPFIX Options Template Record: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Set ID = 3 | Length = 26 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Template ID = 267 | Field Count = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Scope Field Count = 1 |0| selectionSequenceId = 301 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Scope 1 Length = 4 |0| packetsObserved = 318 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Field Length = 4 |0| packetsSelected = 319 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Field Length = 4 |0| packetsSelected = 319 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The associated IPFIX Data Record: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Set ID = 267 | Length = 36 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| 7 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| 100 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| 50 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| 6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| 9 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| 100 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| 10 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure K: Example of the Selection Sequence Statistics Report > Interpretation > > Notes: > * The Attained Packet Fractions for Selection Sequence 7 are: > Filter 10: 50/100 > Sampler 5: 6/50 > Number of samples selected: 6 > > * The Attained Packet Fractions for Selection Sequence 9 are: > Sampler 5: 10/100 > Filter 10: 3/10 > Number of samples selected: 3 > > > 7.3.1 Basic Packet Reports > > For each selected packet, the Packet Report MUST contain the following information: > - The selectionSequenceId Information Element > - Some number of contiguous bytes from the start of the packet, including the packet header (which includes link layer, network layer and other encapsulation headers) and some subsequent bytes of the packet payload. Alternatively, the number of > contiguous bytes may start at the beginning of the payload. The dataLinkFrameSection, mplsLabelStackSection, mplsPayloadPacketSection, ipPacketSection, and ipPayloadPacketSection PSAMP Information Elements are available for this use. > > In the Packet Report, the PSAMP device MUST be capable of exporting the number of observed packets and the number of packets selected by each instance of its Primitive Selectors (as described by the non scope Information Element of the Selection > Sequence Statistics Report Interpretation) although it MAY be a configurable option not to include them. If exported, the Attained Selection Fraction may be calculated precisely for the Observed Packet Stream. The Packet Report MAY include only the > final selector packetSelected, to act as an index for that selection sequence in the Selection Sequence Statistics Report Interpretation, which also allows the calculation of the Attained Selection Fraction. > > The contiguous Information Elements ... > > > > > > -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 10:11:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpSQ-0004de-EX for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 10:11:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEpSQ-0001ox-5x for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 10:11:10 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEpOm-000J4i-O5 for psamp-data@psg.com; Thu, 02 Mar 2006 15:07:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEpOm-000J4W-1q for psamp@ops.ietf.org; Thu, 02 Mar 2006 15:07:24 +0000 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 4F82E1BAC4D; Thu, 2 Mar 2006 16:08:33 +0100 (CET) Date: Thu, 02 Mar 2006 16:07:22 +0100 From: Juergen Quittek To: Paul Aitken , psamp@ops.ietf.org Subject: Re: PSAMP archive Message-ID: In-Reply-To: <4406F001.8060701@cisco.com> References: <4406F001.8060701@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Status: O Paul, Thanks for the hint. The list is maintained at the ops.ietf server. The last maintainer I knew was Randy Bush. I will check who it is now and ask for fixing it. Juergen --On 3/2/06 1:15 PM +0000 Paul Aitken wrote: > Who looks after the PSAMP archive? > > The 2006 archive doesn't default to the Mail Thread Index as previous years do: > > http://ops.ietf.org/lists/psamp/psamp.2006/ > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 10:31:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEplm-0000Nj-5K for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 10:31:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEplj-0002T2-SA for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 10:31:10 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEpij-000KtS-NO for psamp-data@psg.com; Thu, 02 Mar 2006 15:28:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEpii-000KtF-U2 for psamp@ops.ietf.org; Thu, 02 Mar 2006 15:28:01 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k22FRvlY010618; Thu, 2 Mar 2006 09:27:58 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 2 Mar 2006 16:27:56 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509721EF2@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Paul Aitken , psamp@ops.ietf.org Subject: RE: PSAMP archive Date: Thu, 2 Mar 2006 16:27:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Status: O I am seeing data there. For the threads, you can go to: https://ops.ietf.org/lists/psamp/psamp.2006/threads.html There is also http://www.ietf.org/WG-WEB-Mail.html and there is: ftp://ftp.ietf.org/ietf-mail-archive/ Hope this helps. Bert > -----Original Message----- > From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org]On > Behalf Of Paul Aitken > Sent: Thursday, March 02, 2006 14:16 > To: psamp@ops.ietf.org > Subject: PSAMP archive > > > Who looks after the PSAMP archive? > > The 2006 archive doesn't default to the Mail Thread Index as previous > years do: > > http://ops.ietf.org/lists/psamp/psamp.2006/ > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 10:44:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpyy-0008Pr-4f for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 10:44:48 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEpyw-0002xh-LM for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 10:44:48 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEpvQ-000LzD-2O for psamp-data@psg.com; Thu, 02 Mar 2006 15:41:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEpvP-000Lyx-7j for psamp@ops.ietf.org; Thu, 02 Mar 2006 15:41:07 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k22Ff6L11949 for ; Thu, 2 Mar 2006 16:41:06 +0100 (CET) Received: from [10.61.64.250] (ams-clip-vpn-dhcp250.cisco.com [10.61.64.250]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k22Ff5C23189 for ; Thu, 2 Mar 2006 16:41:05 +0100 (CET) Message-ID: <44071210.3060408@cisco.com> Date: Thu, 02 Mar 2006 16:41:04 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: psamp Subject: PROTO-17: Encrypted Packets + PROTO-106: extend security considerations on exported Payload Content-Type: multipart/alternative; boundary="------------040107040606010201070909" Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Status: O This is a multi-part message in MIME format. --------------040107040606010201070909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, The two issues we must be fixing are: PROTO-17 "Encrypted Packets: Selectors that interpret packet fields must be configurable to ignore (i.e. not select) encrypted packets, when they are detected". "Since packet encryption alters the meaning of encrypted fields, field match filtering must be configurable to ignore encrypted packets, when detected." I guess we will need extra text for this. PROTO-106 Extend security considerations by a discussion on exported Payload. Consider whether [PSAMP-INFO] or [PSAMP-PROTO] or both is/are the place(s). [CHARTER] says: Selection of the content of packet reports will be cognizant of privacy and anonymity issues while being responsive to the needs of measurement applications, and in accordance with RFC 2804. [RFC3917] says: 4.1. Encryption If encryption is used, the metering process might not be able to access all header fields. A metering process must meet the requirements stated in this section 4 only for packets that have the relevant header fields not encrypted. [PSAMP-PROTO] says: 8 Security Considerations As IPFIX has been selected as the PSAMP export protocol and as the PSAMP security requirements are not stricter than the IPFIX security requirements, refer to the IPFIX export protocol [IPFIX-PROTO] for the security considerations. So what to write? Hereafter a few proposal - in Property Match Filtering section, I would add: "Since encryption alters the meaning of encrypted fields, when the Property Match Filtering classification is based on the encrypted field(s) in the packet, it MUST be able to recognize that the field(s) are not available and not select those packets. Even if they are ignored, the encrypted packets MUST be accounted in the Selector packetObserved Information Element [PSAMP-INFO], part of the Selection Sequence Statistics Report Interpretation." - in Hash-Based Filtering section, I would add: "Since encryption alters the meaning of encrypted fields, when the Hash-Based Filtering classification is based on the encrypted field(s) in the packet, it MUST be able to recognize that the field(s) are not available and not select those packets. Even if they are ignored, the encrypted packets MUST be accounted in the Selector packetObserved Information Element [PSAMP-INFO], part of the Selection Sequence Statistics Report Interpretation." - in the Security Considerations section, I would add next to first sentence (repeated here): As IPFIX has been selected as the PSAMP export protocol and as the PSAMP security requirements are not stricter than the IPFIX security requirements, refer to the IPFIX export protocol [IPFIX-PROTO] for the security considerations. In the basic Packet Report, a PSAMP Device exports some number of contiguous bytes from the start of the packet, including the packet header (which includes link layer, network layer and other encapsulation headers) and some subsequent bytes of the packet payload. The PSAMP Device SHOULD NOT export the full payload of conversations, as this would mean wiretapping [RFC 2804]. Feedback? Regards, Benoit. --------------040107040606010201070909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,
The two issues we must be fixing are:

 PROTO-17 "Encrypted Packets: Selectors that interpret packet fields 
   must be configurable to ignore (i.e. not select) encrypted packets, 
   when they are detected". "Since packet encryption alters the meaning 
   of encrypted fields, field match filtering must be configurable to 
   ignore encrypted packets, when detected." I guess we will need extra 
   text for this. 

 PROTO-106 Extend security considerations by a discussion on exported  
   Payload. Consider whether [PSAMP-INFO] or [PSAMP-PROTO] or both 
   is/are the place(s). 



[CHARTER] says:

Selection of the content of packet reports will be cognizant of privacy and anonymity issues while being responsive to the needs of measurement applications, and in accordance with RFC 2804.

 
[RFC3917] says:
4.1. Encryption

If encryption is used, the metering process might not be able to
access all header fields. A metering process must meet the
requirements stated in this section 4 only for packets that have the
relevant header fields not encrypted.

[PSAMP-PROTO] says:
8 Security Considerations

As IPFIX has been selected as the PSAMP export protocol and as
the PSAMP security requirements are not stricter than the IPFIX security
requirements, refer to the IPFIX export protocol [IPFIX-PROTO] for the security
considerations.


So what to write? Hereafter a few proposal

- in Property Match Filtering section, I would add:

"Since encryption alters the meaning of encrypted fields, when the Property Match Filtering classification is based on the encrypted field(s) in the packet, it MUST be able to recognize that the field(s) are not available and not select those packets. Even if they are ignored, the encrypted packets MUST be accounted in the Selector packetObserved Information Element [PSAMP-INFO], part of the Selection Sequence Statistics Report Interpretation."

- in Hash-Based Filtering section, I would add:

"Since encryption alters the meaning of encrypted fields, when the Hash-Based Filtering classification is based on the encrypted field(s) in the packet, it MUST be able to recognize that the field(s) are not available and not select those packets. Even if they are ignored, the encrypted packets MUST be accounted in the Selector packetObserved Information Element [PSAMP-INFO], part of the Selection Sequence Statistics Report Interpretation."



- in the Security Considerations section, I would add next to first sentence (repeated here):
As IPFIX has been selected as the PSAMP export protocol and as
the PSAMP security requirements are not stricter than the IPFIX security
requirements, refer to the IPFIX export protocol [IPFIX-PROTO] for the security
considerations. 

In the basic Packet Report, a PSAMP Device exports some number of contiguous bytes from the start of the packet, including the packet header (which includes link layer, network layer and other encapsulation headers) and some subsequent bytes of the packet payload. The PSAMP Device SHOULD NOT export the full payload of conversations, as this would mean wiretapping [RFC 2804].
Feedback?

Regards, Benoit.
--------------040107040606010201070909-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 10:59:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqDR-0000pE-Eg for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 10:59:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEqDR-0003uq-01 for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 10:59:45 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEq9i-000NBn-GT for psamp-data@psg.com; Thu, 02 Mar 2006 15:55:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEq9h-000NBF-H8 for psamp@ops.ietf.org; Thu, 02 Mar 2006 15:55:53 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k22FtqE12933; Thu, 2 Mar 2006 16:55:52 +0100 (CET) Received: from [10.61.64.250] (ams-clip-vpn-dhcp250.cisco.com [10.61.64.250]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k22FtpC08352; Thu, 2 Mar 2006 16:55:51 +0100 (CET) Message-ID: <44071587.2010907@cisco.com> Date: Thu, 02 Mar 2006 16:55:51 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Juergen Quittek CC: psamp Subject: Re: PROTO-12: The observation point report interpretation References: <4404D188.40506@cisco.com> <688973113917F9A8C7B9B38B@[192.168.1.128]> In-Reply-To: <688973113917F9A8C7B9B38B@[192.168.1.128]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Status: O Juergen Quittek wrote: > > > --On 2/28/06 11:41 PM +0100 Benoit Claise wrote: > >> Dear all, >> >> During the last IETF meeting, we discussed the PSAMP issue 12. >> >> PROTO-12 Discuss how to implement the observation point report >> interpretation (if we need one) >> The "Associations Report Interpretation" in >> http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-03.txt, >> which BTW has been renamed to "Select Path Report Interpretation", >> currently contains the observationPointId information element, amongst >> others: >> >> Scope: selectionPath >> Non-Scope: observationPointId >> selectorId (one or more) >> >> Note that the section also specifies: >> >> The observationPointID SHOULD be first Information Element and the >> optional processes SHOULD be last ones so that the path of the >> selected Packet is provided in the logical order. >> >> [PSAMP-INFO] currently specifies: >> >> >> 6.2.19 observationPointId >> >> Description: >> ID of the observation process. Unique in the observation domain. >> Abstract Data Type: octet >> ElementId: 320 >> >> The issue is that a mapping between the observationPointId and the >> existing information element(s) such as interfaceId, lineCardId, >> or routerId is required, adding some complexity in PSAMP, as yet >> another option template is required. >> The proposal is that: >> 1. we don't define the observationPointId in [PSAMP-INFO], but we >> use the any information element (such as interfaceId, lineCardId, >> or routerId) to define the observation point > > This would work as long as there is never a confusion between > a selector ID and one of the types used for specifying the > observation point. We would avoid this potential hazard by using > the observationPointId. The disadvantage in that case would be the > need for another option record that specified the observation point > identified by that ID. Yes, yet another option template record... > >> 2. as the "Select Path Report Interpretation" is composed only of >> one observation point and selector Id(s), we simply assume that >> the non-selector ID(s) is the observation point. This way, we >> avoid the sentence "The observationPointID SHOULD be first >> Information Element and the optional processes SHOULD be last ones ." >> that impose a new rule in IPFIX: the meaning of a specific I.E. >> depends on the order of the I.E. in the record > > I do not like this approach. If we keep the IE observationPointId, > there is no need to care about the position in the option record > where it occurs, because its semantics is always clear. This rule has been proposed specifically so that the order is not important. > >> 3. If a more complex observation point is required such as an unique >> ID representing a list of interfaces, a new Information Element is >> defined and can be used right away. > > What about a combination of 1. and 3.? > We could allow 1. for simple observation points that can be > unambiguously identified by an identifier such as the lineCardId. > In case of a complex observation point, say three line cards, > we could use an observationPointId and have another option record > that defines the observation point that is identified by > observationPointId. We could go for that solution, even if I think that it adds complexity to the protocol However, I don't think that this is a good idea to specify this new option template record with scope=observationPointId, as it can quickly become complex and asy ou have to define the logic between multiple I.Es Example: - logical OR of three line cards? - logical AND of ingress line card and egress line card ? - means AND, OR, CONTAINED So I would propose a generic sentence such as: "if the observationPointId is used in the Selection Sequence Report Interpretation, another options template record should clearly described the meaning of the observationPointId" Regards, Benoit. > > Juergen > >> Note: an alternate solution would be to have 2 scopes in the "Select >> Path Report Interpretation": the selectionPath, and the observation >> point. However, this was not considered as a clean solution. >> >> Here is the text proposal >> >> Selection Path Report Interpretation >> >> Each Packet Report contains a selectionPath Information Element that >> identifies the particular combination of Observation Point and >> Selector(s) used for its selection. For every selectionPath >> Information Element in use, the PSAMP Device MUST export a >> Selection Path Report Interpretation using an Options Template with >> the following Information Element: >> >> Scope: selectionPath >> Non-Scope: one Information Element representing the Observation Point >> selectorId (one or more) >> >> The Information Element representing the Observation Point would >> typically be taken from the ingressInterface, egressInterface, >> lineCardId, exporterIPv4Address, exporterIPv6Address (specified in >> [IPFIX-INFO]), but not limited to those: any Information >> Element specified in [IFPIX-INFO] or [PSAMP-INFO] can potentially be >> used. In case of more complex Observation Points (such as a list of >> interfaces, a bus, etc..), a new Information Element describing the >> new type of Observation Point must be >> specified, along with an option template record describing it in more >> details (if necessary). >> >> >> If the packets are selected by a Composite Selector, the Selection >> Path is composed of several Primitive Selectors. In such a case, the >> Selection Path Report Interpretation MUST contain the list of all the >> Primitive Selector IDs in the Selection Path. >> If multiple Selectors are contained in the Selection Path Report >> Interpretation, the Selectors ID MUST be identified in the order they >> are used. >> >> >> >> Any feedback? >> >> >> >> Regards, Benoit. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 11:04:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqHj-00049p-IW for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 11:04:11 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEqHj-000414-0z for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 11:04:11 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEqBx-000NP5-Hr for psamp-data@psg.com; Thu, 02 Mar 2006 15:58:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEqBw-000NOq-Mb for psamp@ops.ietf.org; Thu, 02 Mar 2006 15:58:13 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k22FwBB13089; Thu, 2 Mar 2006 16:58:11 +0100 (CET) Received: from [10.61.64.250] (ams-clip-vpn-dhcp250.cisco.com [10.61.64.250]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k22FwAC10000; Thu, 2 Mar 2006 16:58:10 +0100 (CET) Message-ID: <44071612.6060606@cisco.com> Date: Thu, 02 Mar 2006 16:58:10 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Juergen Quittek CC: psamp Subject: Re: PROTO-08: Selection Sequence Statistics Report Interpretation References: <44061CA3.8010708@cisco.com> <1277B05CBF0731622E0C893B@[192.168.1.128]> In-Reply-To: <1277B05CBF0731622E0C893B@[192.168.1.128]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Status: O Juergen, > > > --On 3/1/06 11:13 PM +0100 Benoit Claise wrote: > >> Dear all, >> >> Here is a text proposal for the issue 8 >> >> PROTO-08 Instead of sending the input sequence number for each >> selector ID, a counter64 value, associated with every packet, the >> working group should discuss the possibility to send the information >> on regular basis with an option template record. Specifically in the >> case of Composite Selector, we would send multiple times a 64-bit >> counter in each packet. > > I think we should be open for both ways of reporting, i.e. we should > allow an implementation to have all counters in each record Exactly. This is the goal of the very last paragraph of this email. If this is not clear, please let me know. Regards, Benoit. > as well as > to send current counter values in option records only now and then. > > I will send detailed comments on the text below tonight. > > Thanks, > > Juergen > >> Regards, Benoit. >> >> >> >> 7.4.3 Selection Sequence Statistics Report Interpretation >> A Selector MAY be used in multiple Selection Sequences. However, >> each use of a Selector must be independent, so each separate logical >> instance of a Selector MUST maintain its own individual Selection >> State and statistics. >> >> The Selection Sequence Statistics Report Interpretation MUST include >> the number of observed packets (Population Size) and the number of >> packets selected (Sample Size) by each instance of its Primitive >> Selectors. >> Within a Selection Sequence composed of several Primitive Selectors, >> the number of packets selected for one Selector is equal to the >> number of packets observed by the next Selector. The order of the >> Selectors in the Selection Sequence Statistics >> Report Interpretation MUST match the order of the Selectors in the >> Selection Sequence. >> For every Selection Sequence, the PSAMP Device MUST periodically >> export a Selection Sequence Statistics Report Interpretation using an >> Options Template containing the following Information Elements: >> Scope: selectionSequenceId >> Non-scope: packetsObserved >> packetsSelected (first) >> ... >> packetsSelected (last) >> >> The packetsObserved Information Element [PSAMP-INFO] MUST contain the >> number of packets seen at the Observation Point, and as a consequence >> passed to the first Selector in the Selection Sequence. The >> packetsSelected Information Element [PSAMP-INFO] >> contains the number of packets selected by a Selector in the >> Selection Sequence. >> >> The Attained Selection Fraction for the Selection Sequence is >> calculated by dividing the number of observed packets >> (packetsObserved Information Element) by the value of selected >> packets (packetsSelected Information Element) for the last Selector. >> The >> Attained Selection Fraction can be calculated for each Selector by >> dividing the number of packets selected for that Selector by the >> value for the previous Selector. >> >> The statistics for the whole sequence SHOULD be taken at a single >> logical point in time, the input value for a Selector MUST equal the >> output value of the previous selector. >> >> The Selection Sequence Statistics Report Interpretation MUST be >> exported periodically[CSI1] . >> >> Example of Selection Sequence [CSI2] Statistics Report Interpretation: >> >> Selection Sequence 7 (Filter->Sampling): >> >> Observed 100 (observationPointId 1, Interface 5) >> Selected 50 (selectorId 5, match IPV4SourceAddress 10.0.0.1) >> Selected 6 (selectorId 10, Sampler: Random one out-of ten) >> >> Selection Sequence 9 (Sampling->Filtering): >> >> Observed 100 (observationPointId 1, Interface 5) >> Selected 10 (selectorId 10, Sampler: Random one out-of ten) >> Selected 3 (selectorId 5, match IPV4SourceAddress 10.0.0.1) >> >> IPFIX Options Template Record: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 3 | Length = 26 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 267 | Field Count = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Scope Field Count = 1 |0| selectionSequenceId = 301 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Scope 1 Length = 4 |0| packetsObserved = 318 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Length = 4 |0| packetsSelected = 319 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Length = 4 |0| packetsSelected = 319 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> The associated IPFIX Data Record: >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 267 | Length = 36 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 7 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 100 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 50 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 6 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 9 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 100 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 10 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 3 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Figure K: Example of the Selection Sequence Statistics Report >> Interpretation >> >> Notes: >> * The Attained Packet Fractions for Selection Sequence 7 are: >> Filter 10: 50/100 >> Sampler 5: 6/50 >> Number of samples selected: 6 >> >> * The Attained Packet Fractions for Selection Sequence 9 are: >> Sampler 5: 10/100 >> Filter 10: 3/10 >> Number of samples selected: 3 >> >> >> 7.3.1 Basic Packet Reports >> >> For each selected packet, the Packet Report MUST contain the >> following information: >> - The selectionSequenceId Information Element >> - Some number of contiguous bytes from the start of the packet, >> including the packet header (which includes link layer, network layer >> and other encapsulation headers) and some subsequent bytes of the >> packet payload. Alternatively, the number of >> contiguous bytes may start at the beginning of the payload. The >> dataLinkFrameSection, mplsLabelStackSection, >> mplsPayloadPacketSection, ipPacketSection, and ipPayloadPacketSection >> PSAMP Information Elements are available for this use. >> >> In the Packet Report, the PSAMP device MUST be capable of exporting >> the number of observed packets and the number of packets selected by >> each instance of its Primitive Selectors (as described by the non >> scope Information Element of the Selection >> Sequence Statistics Report Interpretation) although it MAY be a >> configurable option not to include them. If exported, the Attained >> Selection Fraction may be calculated precisely for the Observed >> Packet Stream. The Packet Report MAY include only the >> final selector packetSelected, to act as an index for that selection >> sequence in the Selection Sequence Statistics Report Interpretation, >> which also allows the calculation of the Attained Selection Fraction. >> >> The contiguous Information Elements ... >> >> >> >> >> >> -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 11:10:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqNr-0006jZ-8z for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 11:10:31 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEqNq-0004JL-R8 for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 11:10:31 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEqKq-000OES-SH for psamp-data@psg.com; Thu, 02 Mar 2006 16:07:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEqKq-000OEG-68 for psamp@ops.ietf.org; Thu, 02 Mar 2006 16:07:24 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 02 Mar 2006 17:07:23 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k22G7M36022320; Thu, 2 Mar 2006 17:07:22 +0100 (MET) Received: from [144.254.153.34] (dhcp-144-254-153-34.cisco.com [144.254.153.34]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA12913; Thu, 2 Mar 2006 16:07:22 GMT Message-ID: <4407183A.4070300@cisco.com> Date: Thu, 02 Mar 2006 16:07:22 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Benoit Claise CC: psamp Subject: Re: PROTO-11: Accuracy Report Interpretation References: <4406F97F.9060909@cisco.com> In-Reply-To: <4406F97F.9060909@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Status: O One comment inline: Benoit Claise wrote: > Dear all, > > We need a way of specifying the accuracy of our reported information, as > PSAMP frameworks specifies: "the Report Stream must include information > that enables the accuracy of measurements to be determined.". Here is > some proposed text. > > _Section 7.4.4 Accuracy Report Interpretation_ > > In order for the Collecting Process to determine the inherent accuracy > of the reported quantities (for example timestamps), the PSAMP Device > SHOULD send an Accuracy Report Interpretation. > > The Accuracy Report Interpretation MUST be exported by an Option > Template Record with a double scope that contains the TemplateId > [PSAMP-INFO] and the Information Element for which the accuracy is > required. If we make the templateId optional then you can have a mechanism for setting the accuracy for all uses of an element. Is this useful / desirable? It seems to me it is, since the measuring accuracy on a router (or measurement device) will generally be fixed. Andrew > The accuracy SHOULD be reported either with the fixedAccuracy > Information Element [PSAMP-INFO], or with the proportionalAccuracy > Information Element [PSAMP-INFO]. > > Accuracy Report Interpretation using the fixedAccuracy Information Element > Scope: TemplateId > InformationElementId > Non-scope: fixedAccuracy > > Accuracy Report Interpretation using the proportionalAccuracy > Information Element > Scope: TemplateId > InformationElementId > Non-scope: proportionalAccuracy > > For example, the accuracy of an Information Element whose Abstract Data > Type is dateTimeMilliSeconds [IPFIX-INFO], for which the unit is > specified as milliseconds, can be specified with the fixedAccuracy > Information Element with the milliseconds units. In this case, the > accuracy is the Information Element value +/- the value reported in the > fixedAccuracy. > > For example, the accuracy of an Information Element to estimate the > accuracy of a sampled flow, for which the unit would be specified in > octets, can be specified with the proportionalAccuracy Information > Element with the octet units. In this case, the accuracy is the > Information Element value +/- the value reported in the > proportionalAccuracy time Information Element value. > > Alternatively to reporting either the fixedAccuracy Information Element > or the proportionalAccuracy Information Element in the Accuracy Report > Interpretation, both Information Elements MAY be present. This scenario > could help in more complex situations where the system clock drifts, on > the top of having its own accuracy, during the duration of a measurement. > > If the accuracy of a reported quantity changes on the Metering Process, > a new Accuracy Report Interpretation MUST be generated. The Collecting > Process MUST keep the accuracy of the latest Accuracy Report Interpretation. > > Example 1 (to be developed) > Records (using template 12): > 1. Scope: TemplateId = 5, InformationElementId = 152 > Non-scope: fixedAccuracy = 2 > => we have a accuracy of +/- 2ms) > > Example 2 (to be developed): > 1. Scope: TemplateId = 5, InformationElementId = 152 > Non-scope: proportionalAccuracy = 0.005 > => we had an accuracy of +/- 0.5% > > > --------------------- > For the PSAMP information model: > > fixedAccuracy > > Description: > Describes the accuracy of an Information Element, as a negative > and positive relative error in absolute value. > Abstract Data Type: float64 > ElementId: 320 > Status: current > Units: The units of the Information Element for which is accuracy is > specified. > > > proportionalAccuracy > > Description: > Describes the accuracy of an Information Element as a negative > and positive relative error, expressed as a value between 0 and 1. > Abstract Data Type: float64 > ElementId: 321 > Status: current > Units: None > > informationElementID > > Description: > Contains the ID of another Information Element. > Abstract Data Type: unsigned16 > Data Type Semantics: identifier > ElementId: 303 > Status: current > Units: None > > Regards, Benoit. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 11:15:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqT1-0000RL-5A for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 11:15:51 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEqSx-0004Uj-MK for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 11:15:51 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEqQL-000Ojb-Kd for psamp-data@psg.com; Thu, 02 Mar 2006 16:13:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEqQK-000OjO-Ur for psamp@ops.ietf.org; Thu, 02 Mar 2006 16:13:05 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 02 Mar 2006 17:13:04 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k22GD336023833; Thu, 2 Mar 2006 17:13:03 +0100 (MET) Received: from [144.254.153.34] (dhcp-144-254-153-34.cisco.com [144.254.153.34]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA13710; Thu, 2 Mar 2006 16:13:03 GMT Message-ID: <4407198F.4090601@cisco.com> Date: Thu, 02 Mar 2006 16:13:03 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Juergen Quittek CC: Benoit Claise , psamp Subject: Re: PSAMP open issue 18: export rate limit? References: <43A9F344.8010308@cisco.com> <43AC191B.6080803@cisco.com> <44046E19.9060100@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Status: O Juergen Quittek wrote: > Ho Benoit, > > --On 2/28/06 4:36 PM +0100 Benoit Claise wrote: > >> Dear all, >> >> After speaking with Andrew and Paul, here is a proposal: >> There MUST be a IPFIX Message export rate limit, configurable per >> Exporting Process. >> The Exporting Process MAY rate-limit the export rate on a per >> Collecting Process basis. > > I agree with the idea of requesting means for limiting the export rate. > I am not sure that we should request that this feature is always enabled > as the text above implies by stating "There MUST be ...". Also I do not > see a strong reason for requesting that configurability per Exporting > Process as a MUST. A single value for all Exporting Processes at a device > should be sufficient. What about IIRC the reason given for limiting the exporting process was so as not to overwhelm the collecting process. With this in mind it makes good sense to limit the exporting process on a per collector basis. That said, I don't strongly object to your proposed change below. Andrew > "An Exporting Process MUST be able to limit the export rate according to a > configurable value. The Exporting Process MAY limit the export rate on > a per Collecting Process basis." ? > > Thanks, > > Juergen > > >> Feedback? >> >> Regards, Benoit. >> >>> Hello Benoit and all. >>> >>> Benoit Claise wrote: >>>> Dear all, >>>> >>>> In [PSAMP-FMWK], the following statement is still un-addressed in >>>> [PSAMP-PROTO] >>>> PROTO-18 “The exporting process must have an export rate limit, >>>> configurable per Exporting Process”. >>>> See section 8.3 for the details >>>> http://www.ietf.org/internet-drafts/draft-ietf-psamp-framework-10.txt >>>> >>>> >>>> First of all, I have a question regarding the requirement itself. >>>> Isn't it supposed to mean: “The exporting process must have an export >>>> rate limit, configurable per Collecting Process”? Otherwise, I don't >>>> understand the exact requirement when we have a PSAMP device >>>> exporting to multiple collectors! >>> >>> I would say that each Exporting Process exports to only one collector, >>> but can be fed by multiple Metering Processes. Also, each Metering >>> Process may feed Multiple Exporting Processes. With this concept we >>> can rate limit the Exporting Process and it will only affect one >>> collector. >>> >>> >>>> Then, how to address the requirement? >>>> Shall we simply update [PSAMP-PROTO] with a sentence such as: "The >>>> exporting process MUST have an export rate limit, configurable per >>>> Collecting Process"? >>>> And that's it? >>> >>> If we agree that one Exporting Process deals with only one collector >>> then this simplifies matters. >>> >>> >>>> Do we keep the export rate limit as a generic term? Or do we define >>>> precisely what it mean? Example: number of IPFIX Messages, number of >>>> bytes/s, number of records/s? >>> >>> I think we should pick a MUST, such as we MUST be able to rate limit >>> based on the number of data and option records per second, but you MAY >>> rate limit on other criteria also, such as bandwidth. This will allow >>> some common ground between implementations, useful for people who buy >>> from multiple vendors. >>> >>> Regards >>> >>> Andrew >> >> >> -- >> to unsubscribe send a message to psamp-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > > > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 11:29:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqgL-0005yP-2i for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 11:29:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEqgK-0005JO-Lh for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 11:29:37 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEqcs-000PoW-3P for psamp-data@psg.com; Thu, 02 Mar 2006 16:26:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEqcr-000PoK-Dg for psamp@ops.ietf.org; Thu, 02 Mar 2006 16:26:01 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 02 Mar 2006 17:26:01 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k22GQ036027444; Thu, 2 Mar 2006 17:26:00 +0100 (MET) Received: from [144.254.153.34] (dhcp-144-254-153-34.cisco.com [144.254.153.34]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA15066; Thu, 2 Mar 2006 16:25:59 GMT Message-ID: <44071C97.3050102@cisco.com> Date: Thu, 02 Mar 2006 16:25:59 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , psamp Subject: Re: PROTO-12: The observation point report interpretation References: <4404D188.40506@cisco.com> <688973113917F9A8C7B9B38B@[192.168.1.128]> <44071587.2010907@cisco.com> In-Reply-To: <44071587.2010907@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Status: O Benoit Claise wrote: > Juergen Quittek wrote: >> --On 2/28/06 11:41 PM +0100 Benoit Claise wrote: [SNIP] >>> The proposal is that: >>> 1. we don't define the observationPointId in [PSAMP-INFO], but we >>> use the any information element (such as interfaceId, lineCardId, >>> or routerId) to define the observation point [SNIP] >>> 2. as the "Select Path Report Interpretation" is composed only of >>> one observation point and selector Id(s), we simply assume that >>> the non-selector ID(s) is the observation point. This way, we >>> avoid the sentence "The observationPointID SHOULD be first >>> Information Element and the optional processes SHOULD be last ones ." >>> that impose a new rule in IPFIX: the meaning of a specific I.E. >>> depends on the order of the I.E. in the record >> >> I do not like this approach. If we keep the IE observationPointId, >> there is no need to care about the position in the option record >> where it occurs, because its semantics is always clear. > This rule has been proposed specifically so that the order is not > important. >> >>> 3. If a more complex observation point is required such as an unique >>> ID representing a list of interfaces, a new Information Element is >>> defined and can be used right away. >> >> What about a combination of 1. and 3.? >> We could allow 1. for simple observation points that can be >> unambiguously identified by an identifier such as the lineCardId. >> In case of a complex observation point, say three line cards, >> we could use an observationPointId and have another option record >> that defines the observation point that is identified by >> observationPointId. > > We could go for that solution, even if I think that it adds complexity > to the protocol > However, I don't think that this is a good idea to specify this new > option template record with scope=observationPointId, as it can quickly > become complex and asy ou have to define the logic between multiple I.Es > Example: > - logical OR of three line cards? > - logical AND of ingress line card and egress line card ? > - means AND, OR, CONTAINED > So I would propose a generic sentence such as: "if the > observationPointId is used in the Selection Sequence Report > Interpretation, another options template record should clearly described > the meaning of the observationPointId" If we simply go for 1 for now, then this does not preclude 3 being added later. The simple case will have an easily identifiable I.E. in the report. In the complex case a new element with clear semantics can be assigned by IANA when needed and used as the observation point identifier. Further detail on the new element can be given by an option record separately. This is just like using a generic observationPointId, but the new elements can be given clearer meaning (e.g. interfaceGroupId => interfaceId 1, 2 AND 3). Andrew -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 16:55:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEvm3-0003aS-FH for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 16:55:51 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEvm2-00077T-5h for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 16:55:51 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEvfG-000MtD-DE for psamp-data@psg.com; Thu, 02 Mar 2006 21:48:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEvfE-000Mt1-P6 for psamp@ops.ietf.org; Thu, 02 Mar 2006 21:48:48 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 02 Mar 2006 22:48:47 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k22Lml36001058; Thu, 2 Mar 2006 22:48:47 +0100 (MET) Received: from [10.61.65.246] (ams-clip-vpn-dhcp502.cisco.com [10.61.65.246]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA17304; Thu, 2 Mar 2006 21:48:46 GMT Message-ID: <4407683D.60604@cisco.com> Date: Thu, 02 Mar 2006 21:48:45 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.10) Gecko/20050811 Fedora/1.7.10-1.2.1.legacy X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: "Wijnen, Bert" CC: psamp@ops.ietf.org Subject: Re: PSAMP archive References: <7D5D48D2CAA3D84C813F5B154F43B15509721EF2@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15509721EF2@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Status: O Bert, >I am seeing data there. > > Sure. It's the default files index. >For the threads, you can go to: > https://ops.ietf.org/lists/psamp/psamp.2006/threads.html > > Sure. But compare https://ops.ietf.org/lists/psamp/psamp.2006 with your choice of any previous year. Notice the difference? The 2006 archive is slightly misconfigured. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 17:20:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEw9R-0006qr-HA for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 17:20:01 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEw9R-0008QK-4V for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 17:20:01 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEw5j-000PKc-Ev for psamp-data@psg.com; Thu, 02 Mar 2006 22:16:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEw5i-000PKP-7O for psamp@ops.ietf.org; Thu, 02 Mar 2006 22:16:10 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k22MG9u06456; Thu, 2 Mar 2006 23:16:09 +0100 (CET) Received: from [10.61.64.250] (ams-clip-vpn-dhcp250.cisco.com [10.61.64.250]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k22MG6C03462; Thu, 2 Mar 2006 23:16:06 +0100 (CET) Message-ID: <44076EA6.4080300@cisco.com> Date: Thu, 02 Mar 2006 23:16:06 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Johnson CC: Juergen Quittek , psamp Subject: Re: PROTO-12: The observation point report interpretation References: <4404D188.40506@cisco.com> <688973113917F9A8C7B9B38B@[192.168.1.128]> <44071587.2010907@cisco.com> <44071C97.3050102@cisco.com> In-Reply-To: <44071C97.3050102@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Status: O Andrew, Juergen, > Benoit Claise wrote: >> Juergen Quittek wrote: >>> --On 2/28/06 11:41 PM +0100 Benoit Claise wrote: > [SNIP] >>>> The proposal is that: >>>> 1. we don't define the observationPointId in [PSAMP-INFO], but we >>>> use the any information element (such as interfaceId, lineCardId, >>>> or routerId) to define the observation point > [SNIP] >>>> 2. as the "Select Path Report Interpretation" is composed only of >>>> one observation point and selector Id(s), we simply assume that >>>> the non-selector ID(s) is the observation point. This way, we >>>> avoid the sentence "The observationPointID SHOULD be first >>>> Information Element and the optional processes SHOULD be last ones ." >>>> that impose a new rule in IPFIX: the meaning of a specific I.E. >>>> depends on the order of the I.E. in the record >>> >>> I do not like this approach. If we keep the IE observationPointId, >>> there is no need to care about the position in the option record >>> where it occurs, because its semantics is always clear. >> This rule has been proposed specifically so that the order is not >> important. >>> >>>> 3. If a more complex observation point is required such as an unique >>>> ID representing a list of interfaces, a new Information Element is >>>> defined and can be used right away. >>> >>> What about a combination of 1. and 3.? >>> We could allow 1. for simple observation points that can be >>> unambiguously identified by an identifier such as the lineCardId. >>> In case of a complex observation point, say three line cards, >>> we could use an observationPointId and have another option record >>> that defines the observation point that is identified by >>> observationPointId. >> >> We could go for that solution, even if I think that it adds >> complexity to the protocol >> However, I don't think that this is a good idea to specify this new >> option template record with scope=observationPointId, as it can >> quickly become complex and asy ou have to define the logic between >> multiple I.Es >> Example: >> - logical OR of three line cards? >> - logical AND of ingress line card and egress line card ? >> - means AND, OR, CONTAINED >> So I would propose a generic sentence such as: "if the >> observationPointId is used in the Selection Sequence Report >> Interpretation, another options template record should clearly >> described the meaning of the observationPointId" > > If we simply go for 1 for now, then this does not preclude 3 being added > later. The simple case will have an easily identifiable I.E. in the > report. > In the complex case a new element with clear semantics can be assigned by > IANA when needed and used as the observation point identifier. Further > detail on the new element can be given by an option record > separately. This > is just like using a generic observationPointId, but the new elements > can be > given clearer meaning (e.g. interfaceGroupId => interfaceId 1, 2 AND 3). I fully agree with this. Regards, Benoit. > > > Andrew -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 17:25:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEwF9-0003IY-6B for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 17:25:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEwF8-0000Fu-OZ for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 17:25:55 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEwC9-000Ps6-0O for psamp-data@psg.com; Thu, 02 Mar 2006 22:22:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEwC8-000Pru-5R for psamp@ops.ietf.org; Thu, 02 Mar 2006 22:22:48 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k22MMln06877 for ; Thu, 2 Mar 2006 23:22:47 +0100 (CET) Received: from [10.61.64.250] (ams-clip-vpn-dhcp250.cisco.com [10.61.64.250]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k22MMiC08934; Thu, 2 Mar 2006 23:22:45 +0100 (CET) Message-ID: <44077034.1010209@cisco.com> Date: Thu, 02 Mar 2006 23:22:44 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Johnson CC: psamp Subject: Re: PROTO-11: Accuracy Report Interpretation References: <4406F97F.9060909@cisco.com> <4407183A.4070300@cisco.com> In-Reply-To: <4407183A.4070300@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Status: O Andrew Johnson wrote: > One comment inline: > > Benoit Claise wrote: >> Dear all, >> >> We need a way of specifying the accuracy of our reported information, >> as PSAMP frameworks specifies: "the Report Stream must include >> information that enables the accuracy of measurements to be >> determined.". Here is some proposed text. >> >> _Section 7.4.4 Accuracy Report Interpretation_ >> >> In order for the Collecting Process to determine the inherent >> accuracy of the reported quantities (for example timestamps), the >> PSAMP Device SHOULD send an Accuracy Report Interpretation. >> The Accuracy Report Interpretation MUST be exported by an Option >> Template Record with a double scope that contains the TemplateId >> [PSAMP-INFO] and the Information Element for which the accuracy is >> required. > > If we make the templateId optional then you can have a mechanism for > setting the accuracy for all uses of an element. Is this useful / > desirable? It seems to me it is, since the measuring accuracy on > a router (or measurement device) will generally be fixed. Good point. "The Accuracy Report Interpretation MUST be exported by an Option Template Record with a double scope that contains the TemplateId [PSAMP-INFO] and the Information Element for which the accuracy is required. " becomes "The Accuracy Report Interpretation MUST be exported by an Option Template Record with a scope that contains the Information Element for which the accuracy is required. In case the accuracy is specific to a template, a second scope containing the templateId value MUST be added to the Option Template Record." Regards, Benoit. > > Andrew > > >> The accuracy SHOULD be reported either with the fixedAccuracy >> Information Element [PSAMP-INFO], or with the proportionalAccuracy >> Information Element [PSAMP-INFO]. >> >> Accuracy Report Interpretation using the fixedAccuracy Information >> Element >> Scope: TemplateId >> InformationElementId >> Non-scope: fixedAccuracy >> >> Accuracy Report Interpretation using the proportionalAccuracy >> Information Element >> Scope: TemplateId >> InformationElementId >> Non-scope: proportionalAccuracy >> >> For example, the accuracy of an Information Element whose Abstract >> Data Type is dateTimeMilliSeconds [IPFIX-INFO], for which the unit is >> specified as milliseconds, can be specified with the fixedAccuracy >> Information Element with the milliseconds units. In this case, the >> accuracy is the Information Element value +/- the value reported in >> the fixedAccuracy. >> >> For example, the accuracy of an Information Element to estimate the >> accuracy of a sampled flow, for which the unit would be specified in >> octets, can be specified with the proportionalAccuracy Information >> Element with the octet units. In this case, the accuracy is the >> Information Element value +/- the value reported in the >> proportionalAccuracy time Information Element value. >> >> Alternatively to reporting either the fixedAccuracy Information >> Element or the proportionalAccuracy Information Element in the >> Accuracy Report Interpretation, both Information Elements MAY be >> present. This scenario could help in more complex situations where >> the system clock drifts, on the top of having its own accuracy, >> during the duration of a measurement. >> >> If the accuracy of a reported quantity changes on the Metering >> Process, a new Accuracy Report Interpretation MUST be generated. The >> Collecting Process MUST keep the accuracy of the latest Accuracy >> Report Interpretation. >> >> Example 1 (to be developed) >> Records (using template 12): >> 1. Scope: TemplateId = 5, InformationElementId = 152 >> Non-scope: fixedAccuracy = 2 >> => we have a accuracy of +/- 2ms) >> >> Example 2 (to be developed): >> 1. Scope: TemplateId = 5, InformationElementId = 152 >> Non-scope: proportionalAccuracy = 0.005 >> => we had an accuracy of +/- 0.5% >> >> >> --------------------- >> For the PSAMP information model: >> >> fixedAccuracy >> >> Description: >> Describes the accuracy of an Information Element, as a >> negative >> and positive relative error in absolute value. >> Abstract Data Type: float64 >> ElementId: 320 >> Status: current >> Units: The units of the Information Element for which is >> accuracy is >> specified. >> >> >> proportionalAccuracy >> >> Description: >> Describes the accuracy of an Information Element as a negative >> and positive relative error, expressed as a value between 0 >> and 1. >> Abstract Data Type: float64 >> ElementId: 321 >> Status: current >> Units: None >> >> informationElementID >> >> Description: >> Contains the ID of another Information Element. >> Abstract Data Type: unsigned16 >> Data Type Semantics: identifier >> ElementId: 303 >> Status: current >> Units: None >> >> Regards, Benoit. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 18:20:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEx5e-00070F-4X for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 18:20:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEx5c-0003OU-RD for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 18:20:10 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEx0U-0003jE-UN for psamp-data@psg.com; Thu, 02 Mar 2006 23:14:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEx0U-0003j3-86 for psamp@ops.ietf.org; Thu, 02 Mar 2006 23:14:50 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k22NEnA09944 for ; Fri, 3 Mar 2006 00:14:49 +0100 (CET) Received: from [10.61.64.250] (ams-clip-vpn-dhcp250.cisco.com [10.61.64.250]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k22NEcC07148 for ; Fri, 3 Mar 2006 00:14:41 +0100 (CET) Message-ID: <44077C54.1070907@cisco.com> Date: Fri, 03 Mar 2006 00:14:28 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: psamp Subject: PROTO-19: The timestamp should be reported to microsecond resolution Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Status: O Dear all, PROTO-19 "the timestamp of observation of the packet at the Observation Point. The timestamp should be reported to microsecond resolution." Nothing is mentioned in this draft regarding this issue. The idea, to fulfill this requirement, is to add a microsecond precision timestamp in the "Basic Packet Report". However, neither in [PSAMP-INFO] nor in [IPFIX-INFO] we do have absolute timestamps except ... that [IPFIX-INFO] specifies the following time stamps: flowStartSeconds, flowEndSeconds, flowStartMilliSeconds, flowEndMilliSeconds, flowStartMicroSeconds, flowEndMicroSeconds, flowStartNanoSeconds, flowEndNanoSeconds. Considering that a PSAMP Packet Report is a flow composed of a single packet, can we reuse the flowStartMicroSeconds Information Element? Or (if you are a purist), the "flow" prefix is confusing in a PSAMP implementation? Please provide your feedback. If the latter, then we must define a new Information Element for the microsecond precision. And, while doing that, we should define the other precision at the same time: second, millisecond, and nanosecond. timeSeconds Description: The absolute time. Abstract Data Type: dateTimeSeconds ElementId: Status: current Units: seconds timeMilliSeconds Description: The absolute time. Abstract Data Type: dateTimeMilliSeconds ElementId: Status: current Units: milliseconds timeMicroSeconds Description: The absolute time. Abstract Data Type: dateTimeMicroSeconds ElementId: Status: current Units: microseconds timeNanoSeconds Description: The absolute time. Abstract Data Type: dateTimeNanoSeconds ElementId: Status: current Units: nanoseconds Regards, Benoit. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 18:25:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FExB4-00009L-NX for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 18:25:46 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FExB3-00047z-E7 for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 18:25:46 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEx7e-0004Mo-DN for psamp-data@psg.com; Thu, 02 Mar 2006 23:22:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEx7d-0004MI-QB for psamp@ops.ietf.org; Thu, 02 Mar 2006 23:22:13 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Mar 2006 00:22:13 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k22NMC36014604; Fri, 3 Mar 2006 00:22:12 +0100 (MET) Received: from [10.61.65.246] (ams-clip-vpn-dhcp502.cisco.com [10.61.65.246]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA26035; Thu, 2 Mar 2006 23:22:12 GMT Message-ID: <44077E23.8000407@cisco.com> Date: Thu, 02 Mar 2006 23:22:11 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.10) Gecko/20050811 Fedora/1.7.10-1.2.1.legacy X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Benoit Claise CC: psamp Subject: Re: PROTO-19: The timestamp should be reported to microsecond resolution References: <44077C54.1070907@cisco.com> In-Reply-To: <44077C54.1070907@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Status: O Benoit, > can we reuse the flowStartMicroSeconds Information Element? > Or (if you are a purist), the "flow" prefix is confusing in a PSAMP > implementation? > Please provide your feedback. From the purist perspective, I would prefer to create the new timestamp elements you list. They're more appropriate than flowStart... and may be of use in other ways in future. > If the latter, then we must define a new Information Element for the > microsecond precision. And, while doing that, we should define the > other precision at the same time: second, millisecond, and nanosecond. Agreed. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 18:39:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FExOl-0001bA-4Y for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 18:39:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FExOk-0005Tr-O3 for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 18:39:55 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FExLt-0005Tw-SC for psamp-data@psg.com; Thu, 02 Mar 2006 23:36:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FExLt-0005Tk-0a for psamp@ops.ietf.org; Thu, 02 Mar 2006 23:36:57 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k22Nat911169; Fri, 3 Mar 2006 00:36:55 +0100 (CET) Received: from [10.61.64.250] (ams-clip-vpn-dhcp250.cisco.com [10.61.64.250]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k22NatC17541; Fri, 3 Mar 2006 00:36:55 +0100 (CET) Message-ID: <44078196.2090609@cisco.com> Date: Fri, 03 Mar 2006 00:36:54 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Juergen Quittek CC: Andrew Johnson , psamp Subject: Re: PSAMP open issue 18: export rate limit? References: <43A9F344.8010308@cisco.com> <43AC191B.6080803@cisco.com> <44046E19.9060100@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Status: O Ho Juergen, > Ho Benoit, > > --On 2/28/06 4:36 PM +0100 Benoit Claise wrote: > >> Dear all, >> >> After speaking with Andrew and Paul, here is a proposal: >> There MUST be a IPFIX Message export rate limit, configurable per >> Exporting Process. >> The Exporting Process MAY rate-limit the export rate on a per >> Collecting Process basis. > > I agree with the idea of requesting means for limiting the export rate. > I am not sure that we should request that this feature is always enabled > as the text above implies by stating "There MUST be ...". Agreed. > Also I do not > see a strong reason for requesting that configurability per Exporting > Process as a MUST. A single value for all Exporting Processes at a device > should be sufficient. What about > > "An Exporting Process MUST be able to limit the export rate according > to a > configurable value. The Exporting Process MAY limit the export rate on > a per Collecting Process basis." ? I support your proposal Regards, Benoit. > > Thanks, > > Juergen > > >> Feedback? >> >> Regards, Benoit. >> >>> Hello Benoit and all. >>> >>> Benoit Claise wrote: >>>> Dear all, >>>> >>>> In [PSAMP-FMWK], the following statement is still un-addressed in >>>> [PSAMP-PROTO] >>>> PROTO-18 “The exporting process must have an export rate limit, >>>> configurable per Exporting Process”. >>>> See section 8.3 for the details >>>> http://www.ietf.org/internet-drafts/draft-ietf-psamp-framework-10.txt >>>> >>>> >>>> First of all, I have a question regarding the requirement itself. >>>> Isn't it supposed to mean: “The exporting process must have an export >>>> rate limit, configurable per Collecting Process”? Otherwise, I don't >>>> understand the exact requirement when we have a PSAMP device >>>> exporting to multiple collectors! >>> >>> I would say that each Exporting Process exports to only one collector, >>> but can be fed by multiple Metering Processes. Also, each Metering >>> Process may feed Multiple Exporting Processes. With this concept we >>> can rate limit the Exporting Process and it will only affect one >>> collector. >>> >>> >>>> Then, how to address the requirement? >>>> Shall we simply update [PSAMP-PROTO] with a sentence such as: "The >>>> exporting process MUST have an export rate limit, configurable per >>>> Collecting Process"? >>>> And that's it? >>> >>> If we agree that one Exporting Process deals with only one collector >>> then this simplifies matters. >>> >>> >>>> Do we keep the export rate limit as a generic term? Or do we define >>>> precisely what it mean? Example: number of IPFIX Messages, number of >>>> bytes/s, number of records/s? >>> >>> I think we should pick a MUST, such as we MUST be able to rate limit >>> based on the number of data and option records per second, but you MAY >>> rate limit on other criteria also, such as bandwidth. This will allow >>> some common ground between implementations, useful for people who buy >>> from multiple vendors. >>> >>> Regards >>> >>> Andrew >> >> >> -- >> to unsubscribe send a message to psamp-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 19:24:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEy5q-0006r1-JB for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 19:24:26 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEy5q-0000XE-6i for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 19:24:26 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEy1c-00099T-IX for psamp-data@psg.com; Fri, 03 Mar 2006 00:20:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_40_50,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEy1b-00098o-M1 for psamp@ops.ietf.org; Fri, 03 Mar 2006 00:20:04 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k230K2D13782 for ; Fri, 3 Mar 2006 01:20:02 +0100 (CET) Received: from [10.61.64.250] (ams-clip-vpn-dhcp250.cisco.com [10.61.64.250]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k230K1C07930 for ; Fri, 3 Mar 2006 01:20:02 +0100 (CET) Message-ID: <44078BB1.9020007@cisco.com> Date: Fri, 03 Mar 2006 01:20:01 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: psamp Subject: PROTO-108 statement that PSAMP-PROTO meets the PSAMP-FMWK requirements Content-Type: multipart/alternative; boundary="------------040407030702090505090901" Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Status: O This is a multi-part message in MIME format. --------------040407030702090505090901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, PROTO-108 Have a statement that this protocol specification meets all requirements for the PSAMP protocol stated in the framework except ... An then have a list of bullets, where at minimum there is stated "not yet covered" or a longer explanation why it is not covered. This would be replacement for the long list of requirements in section 6.1 The section 6.1 was created as an intermediate step while producing the full PSAMP specifications. Therefore, there is no point anymore to explain, next to each [PSAMP-FMWK] requirements, how IPFIX/PSAMP fulfills it... as all is specified in details in the other sections of the draft. The section 6.1 should be removed and the following text proposal should be added at the end of section 6 The PSAMP protocol specifications meets all the protocol requirements stated in the PSAMP framework document [PSAMP-FMWK]: * Extensibility * Parallel measurement processes * Encrypted packets * Indication of information loss * Accuracy * Privacy * Timeliness * Congestion avoidance * Secure export: * Export rate limit * Microsecond timestamp resolution With the choice of IPFIX as PSAMP export protocol, the compression option mentioned in the framework document [PSAMP-FMWK] is not addressed. If you object, please let me know. Regards, Benoit. --------------040407030702090505090901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,
   PROTO-108 Have a statement that this protocol specification  
   meets all requirements for the PSAMP protocol stated in the framework  
   except ... An then have a list of bullets, where at minimum there is 
   stated "not yet covered" or a longer explanation why it is not 
   covered. This would be replacement for the long list of requirements 
   in section 6.1
The section 6.1 was created as an intermediate step while producing the full PSAMP specifications.
Therefore, there is no point anymore to explain, next to each [PSAMP-FMWK] requirements, how IPFIX/PSAMP fulfills it... as all is specified in details in the other sections of the draft.

The section 6.1 should be removed and the following text proposal should be added at the end of section 6
The PSAMP protocol specifications meets all the protocol requirements stated in the PSAMP framework document [PSAMP-FMWK]:
    * Extensibility
    * Parallel measurement processes
    * Encrypted packets 
    * Indication of information loss
    * Accuracy
    * Privacy
    * Timeliness
    * Congestion avoidance
    * Secure export:
    * Export rate limit
    * Microsecond timestamp resolution

With the choice of IPFIX as PSAMP export protocol, the compression option mentioned in the framework document [PSAMP-FMWK] is not addressed.

If you object, please let me know.

Regards, Benoit.



--------------040407030702090505090901-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 19:26:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEy89-0002R0-0W for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 19:26:49 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEy88-0000eY-Jo for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 19:26:48 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEy5W-0009UO-De for psamp-data@psg.com; Fri, 03 Mar 2006 00:24:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEy5V-0009U3-2F for psamp@ops.ietf.org; Fri, 03 Mar 2006 00:24:05 +0000 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id C83431BAC4D; Fri, 3 Mar 2006 01:25:11 +0100 (CET) Date: Fri, 03 Mar 2006 01:24:05 +0100 From: Juergen Quittek To: Benoit Claise , psamp Subject: Re: PROTO-17: Encrypted Packets + PROTO-106: extend security considerations on exported Payload Message-ID: In-Reply-To: <44071210.3060408@cisco.com> References: <44071210.3060408@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Status: O Benoit, I support this solution for PROTO-17. I also support the intention behind the suggested text that addresses PROTO-106. But I do not see how it would be realized. How would an implementation ensure that it does not export the full payload of a conversation? Thanks, Juergen --On 3/2/06 4:41 PM +0100 Benoit Claise wrote: > Dear all, > > > The two issues we must be fixing are: > > PROTO-17 "Encrypted Packets: Selectors that interpret packet fields > must be configurable to ignore (i.e. not select) encrypted packets, > when they are detected". "Since packet encryption alters the meaning > of encrypted fields, field match filtering must be configurable to > ignore encrypted packets, when detected." I guess we will need extra > text for this. > > PROTO-106 Extend security considerations by a discussion on exported > Payload. Consider whether [PSAMP-INFO] or [PSAMP-PROTO] or both > is/are the place(s). > > > > [CHARTER] says: > > > > > > Selection of the content of packet reports will be cognizant of privacy and anonymity issues while being responsive to the needs of measurement applications, and in accordance with RFC 2804. > > > > [RFC3917] says: > > > > 4.1. Encryption > > If encryption is used, the metering process might not be able to > access all header fields. A metering process must meet the > requirements stated in this section 4 only for packets that have the > relevant header fields not encrypted. > > > > > [PSAMP-PROTO] says: > > > > 8 Security Considerations > > As IPFIX has been selected as the PSAMP export protocol and as > the PSAMP security requirements are not stricter than the IPFIX security > requirements, refer to the IPFIX export protocol [IPFIX-PROTO] for the security > considerations. > > > > > > So what to write? Hereafter a few proposal > > - in Property Match Filtering section, I would add: > > > > > > "Since encryption alters the meaning of encrypted fields, when the Property Match Filtering classification is based on the encrypted field(s) in the packet, it MUST be able to recognize that the field(s) are not available and not select those packets. > Even if they are ignored, the encrypted packets MUST be accounted in the Selector packetObserved Information Element [PSAMP-INFO], part of the Selection Sequence Statistics Report Interpretation." > > > > - in Hash-Based Filtering section, I would add: > > > > > "Since encryption alters the meaning of encrypted fields, when the Hash-Based Filtering classification is based on the encrypted field(s) in the packet, it MUST be able to recognize that the field(s) are not available and not select those packets. Even > if they are ignored, the encrypted packets MUST be accounted in the Selector packetObserved Information Element [PSAMP-INFO], part of the Selection Sequence Statistics Report Interpretation." > > > > > - in the Security Considerations section, I would add next to first sentence (repeated here): > > As IPFIX has been selected as the PSAMP export protocol and as > the PSAMP security requirements are not stricter than the IPFIX security > requirements, refer to the IPFIX export protocol [IPFIX-PROTO] for the security > considerations. > > In the basic Packet Report, a PSAMP Device exports some number of contiguous bytes from the start of the packet, including the packet header (which includes link layer, network layer and other encapsulation headers) and some subsequent bytes of the > packet payload. The PSAMP Device SHOULD NOT export the full payload of conversations, as this would mean wiretapping [RFC 2804]. > > > > Feedback? > > Regards, Benoit. > > > > -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 19:31:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEyCc-000619-F4 for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 19:31:26 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEyCc-0000l0-1t for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 19:31:26 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEy8f-0009nz-9a for psamp-data@psg.com; Fri, 03 Mar 2006 00:27:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEy8e-0009nm-Hr for psamp@ops.ietf.org; Fri, 03 Mar 2006 00:27:20 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k230RJS14148; Fri, 3 Mar 2006 01:27:19 +0100 (CET) Received: from [10.61.64.250] (ams-clip-vpn-dhcp250.cisco.com [10.61.64.250]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k230RIC10421; Fri, 3 Mar 2006 01:27:18 +0100 (CET) Message-ID: <44078D66.8080006@cisco.com> Date: Fri, 03 Mar 2006 01:27:18 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Juergen Quittek CC: psamp Subject: Re: PROTO-17: Encrypted Packets + PROTO-106: extend security considerations on exported Payload References: <44071210.3060408@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Status: O Juergen, > > I support this solution for PROTO-17. > > I also support the intention behind the suggested text > that addresses PROTO-106. But I do not see how it would be > realized. How would an implementation ensure that it does > not export the full payload of a conversation? I don't have the answer. [PSAMP-FMWK] is not clearer: * Privacy: selection of the content of Packet Reports will be cognizant of privacy and anonymity issues while being responsive to the needs of measurement applications, and in accordance with [RFC-2804]. Full packet capture of arbitrary packet streams is explicitly out of scope. Do you have a suggestion? Regards, Benoit. > > Thanks, > > Juergen > > --On 3/2/06 4:41 PM +0100 Benoit Claise wrote: > >> Dear all, >> >> >> The two issues we must be fixing are: >> >> PROTO-17 "Encrypted Packets: Selectors that interpret packet fields >> must be configurable to ignore (i.e. not select) encrypted packets, >> when they are detected". "Since packet encryption alters the meaning >> of encrypted fields, field match filtering must be configurable to >> ignore encrypted packets, when detected." I guess we will need extra >> text for this. >> >> PROTO-106 Extend security considerations by a discussion on exported >> Payload. Consider whether [PSAMP-INFO] or [PSAMP-PROTO] or both >> is/are the place(s). >> >> >> >> [CHARTER] says: >> >> >> >> >> >> Selection of the content of packet reports will be cognizant of >> privacy and anonymity issues while being responsive to the needs of >> measurement applications, and in accordance with RFC 2804. >> >> >> >> [RFC3917] says: >> >> >> >> 4.1. Encryption >> >> If encryption is used, the metering process might not be able to >> access all header fields. A metering process must meet the >> requirements stated in this section 4 only for packets that have the >> relevant header fields not encrypted. >> >> >> >> >> [PSAMP-PROTO] says: >> >> >> >> 8 Security Considerations >> >> As IPFIX has been selected as the PSAMP export protocol and as >> the PSAMP security requirements are not stricter than the IPFIX security >> requirements, refer to the IPFIX export protocol [IPFIX-PROTO] for >> the security >> considerations. >> >> >> >> >> >> So what to write? Hereafter a few proposal >> >> - in Property Match Filtering section, I would add: >> >> >> >> >> >> "Since encryption alters the meaning of encrypted fields, when the >> Property Match Filtering classification is based on the encrypted >> field(s) in the packet, it MUST be able to recognize that the >> field(s) are not available and not select those packets. >> Even if they are ignored, the encrypted packets MUST be accounted in >> the Selector packetObserved Information Element [PSAMP-INFO], part of >> the Selection Sequence Statistics Report Interpretation." >> >> >> >> - in Hash-Based Filtering section, I would add: >> >> >> >> >> "Since encryption alters the meaning of encrypted fields, when the >> Hash-Based Filtering classification is based on the encrypted >> field(s) in the packet, it MUST be able to recognize that the >> field(s) are not available and not select those packets. Even >> if they are ignored, the encrypted packets MUST be accounted in the >> Selector packetObserved Information Element [PSAMP-INFO], part of the >> Selection Sequence Statistics Report Interpretation." >> >> >> >> >> - in the Security Considerations section, I would add next to first >> sentence (repeated here): >> >> As IPFIX has been selected as the PSAMP export protocol and as >> the PSAMP security requirements are not stricter than the IPFIX security >> requirements, refer to the IPFIX export protocol [IPFIX-PROTO] for >> the security >> considerations. >> >> In the basic Packet Report, a PSAMP Device exports some number of >> contiguous bytes from the start of the packet, including the packet >> header (which includes link layer, network layer and other >> encapsulation headers) and some subsequent bytes of the >> packet payload. The PSAMP Device SHOULD NOT export the full payload >> of conversations, as this would mean wiretapping [RFC 2804]. >> >> >> >> Feedback? >> >> Regards, Benoit. >> >> >> >> -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 19:36:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEyH5-00038F-RC for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 19:36:03 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEyH5-0000vU-ER for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 19:36:03 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEyD4-000AC7-By for psamp-data@psg.com; Fri, 03 Mar 2006 00:31:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEyD3-000ABv-FO for psamp@ops.ietf.org; Fri, 03 Mar 2006 00:31:53 +0000 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 775941BAC4D; Fri, 3 Mar 2006 01:32:58 +0100 (CET) Date: Fri, 03 Mar 2006 01:31:51 +0100 From: Juergen Quittek To: Benoit Claise , Andrew Johnson Cc: psamp Subject: Re: PROTO-12: The observation point report interpretation Message-ID: <6CA425B2F99521EF0F808045@[192.168.1.128]> In-Reply-To: <44076EA6.4080300@cisco.com> References: <4404D188.40506@cisco.com> <688973113917F9A8C7B9B38B@[192.168.1.128]> <44071587.2010907@cisco.com> <44071C97.3050102@cisco.com> <44076EA6.4080300@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Status: O --On 3/2/06 11:16 PM +0100 Benoit Claise wrote: > > Andrew, Juergen, >> Benoit Claise wrote: >>> Juergen Quittek wrote: >>>> --On 2/28/06 11:41 PM +0100 Benoit Claise wrote: >> [SNIP] >>>>> The proposal is that: >>>>> 1. we don't define the observationPointId in [PSAMP-INFO], but we >>>>> use the any information element (such as interfaceId, lineCardId, >>>>> or routerId) to define the observation point >> [SNIP] >>>>> 2. as the "Select Path Report Interpretation" is composed only of >>>>> one observation point and selector Id(s), we simply assume that >>>>> the non-selector ID(s) is the observation point. This way, we >>>>> avoid the sentence "The observationPointID SHOULD be first >>>>> Information Element and the optional processes SHOULD be last ones ." >>>>> that impose a new rule in IPFIX: the meaning of a specific I.E. >>>>> depends on the order of the I.E. in the record >>>> >>>> I do not like this approach. If we keep the IE observationPointId, >>>> there is no need to care about the position in the option record >>>> where it occurs, because its semantics is always clear. >>> This rule has been proposed specifically so that the order is not >>> important. >>>> >>>>> 3. If a more complex observation point is required such as an unique >>>>> ID representing a list of interfaces, a new Information Element is >>>>> defined and can be used right away. >>>> >>>> What about a combination of 1. and 3.? >>>> We could allow 1. for simple observation points that can be >>>> unambiguously identified by an identifier such as the lineCardId. >>>> In case of a complex observation point, say three line cards, >>>> we could use an observationPointId and have another option record >>>> that defines the observation point that is identified by >>>> observationPointId. >>> >>> We could go for that solution, even if I think that it adds >>> complexity to the protocol >>> However, I don't think that this is a good idea to specify this new >>> option template record with scope=observationPointId, as it can >>> quickly become complex and asy ou have to define the logic between >>> multiple I.Es >>> Example: >>> - logical OR of three line cards? >>> - logical AND of ingress line card and egress line card ? >>> - means AND, OR, CONTAINED >>> So I would propose a generic sentence such as: "if the >>> observationPointId is used in the Selection Sequence Report >>> Interpretation, another options template record should clearly >>> described the meaning of the observationPointId" >> >> If we simply go for 1 for now, then this does not preclude 3 being added >> later. The simple case will have an easily identifiable I.E. in the >> report. >> In the complex case a new element with clear semantics can be assigned by >> IANA when needed and used as the observation point identifier. Further >> detail on the new element can be given by an option record >> separately. This >> is just like using a generic observationPointId, but the new elements >> can be >> given clearer meaning (e.g. interfaceGroupId => interfaceId 1, 2 AND 3). > I fully agree with this. Also fine with me. Thanks, Juergen > Regards, Benoit. >> >> >> Andrew > -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 19:53:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEyYJ-0001Li-Ph for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 19:53:51 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEyYJ-0001S4-BE for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 19:53:51 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEyVM-000BqI-QL for psamp-data@psg.com; Fri, 03 Mar 2006 00:50:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEyVJ-000Bq2-Hn for psamp@ops.ietf.org; Fri, 03 Mar 2006 00:50:46 +0000 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id D62261BAC4D; Fri, 3 Mar 2006 01:51:51 +0100 (CET) Date: Fri, 03 Mar 2006 01:50:45 +0100 From: Juergen Quittek To: Benoit Claise , Andrew Johnson Cc: psamp Subject: Re: PROTO-11: Accuracy Report Interpretation Message-ID: In-Reply-To: <44077034.1010209@cisco.com> References: <4406F97F.9060909@cisco.com> <4407183A.4070300@cisco.com> <44077034.1010209@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Status: O Benoit and Andrew, --On 3/2/06 11:22 PM +0100 Benoit Claise wrote: > > Andrew Johnson wrote: >> One comment inline: >> >> Benoit Claise wrote: >>> Dear all, >>> >>> We need a way of specifying the accuracy of our reported information, >>> as PSAMP frameworks specifies: "the Report Stream must include >>> information that enables the accuracy of measurements to be >>> determined.". Here is some proposed text. >>> >>> _Section 7.4.4 Accuracy Report Interpretation_ >>> >>> In order for the Collecting Process to determine the inherent >>> accuracy of the reported quantities (for example timestamps), the >>> PSAMP Device SHOULD send an Accuracy Report Interpretation. >>> The Accuracy Report Interpretation MUST be exported by an Option >>> Template Record with a double scope that contains the TemplateId >>> [PSAMP-INFO] and the Information Element for which the accuracy is >>> required. >> >> If we make the templateId optional then you can have a mechanism for >> setting the accuracy for all uses of an element. Is this useful / >> desirable? It seems to me it is, since the measuring accuracy on >> a router (or measurement device) will generally be fixed. > Good point. > > "The Accuracy Report Interpretation MUST be exported by an Option Template Record with a double scope that contains the TemplateId [PSAMP-INFO] and the Information Element for which the accuracy is required. " > becomes > "The Accuracy Report Interpretation MUST be exported by an Option Template Record with a scope that contains the Information Element for which the accuracy is required. In case the accuracy is specific to a template, a second scope containing the > templateId value MUST be added to the Option Template Record." > > Regards, Benoit. >> >> Andrew >> >> >>> The accuracy SHOULD be reported either with the fixedAccuracy >>> Information Element [PSAMP-INFO], or with the proportionalAccuracy >>> Information Element [PSAMP-INFO]. >>> >>> Accuracy Report Interpretation using the fixedAccuracy Information >>> Element >>> Scope: TemplateId >>> InformationElementId >>> Non-scope: fixedAccuracy >>> >>> Accuracy Report Interpretation using the proportionalAccuracy >>> Information Element >>> Scope: TemplateId >>> InformationElementId >>> Non-scope: proportionalAccuracy >>> >>> For example, the accuracy of an Information Element whose Abstract >>> Data Type is dateTimeMilliSeconds [IPFIX-INFO], for which the unit is >>> specified as milliseconds, can be specified with the fixedAccuracy >>> Information Element with the milliseconds units. In this case, the >>> accuracy is the Information Element value +/- the value reported in >>> the fixedAccuracy. >>> >>> For example, the accuracy of an Information Element to estimate the >>> accuracy of a sampled flow, for which the unit would be specified in >>> octets, can be specified with the proportionalAccuracy Information >>> Element with the octet units. In this case, the accuracy is the >>> Information Element value +/- the value reported in the >>> proportionalAccuracy time Information Element value. >>> >>> Alternatively to reporting either the fixedAccuracy Information >>> Element or the proportionalAccuracy Information Element in the >>> Accuracy Report Interpretation, both Information Elements MAY be >>> present. This scenario could help in more complex situations where >>> the system clock drifts, on the top of having its own accuracy, >>> during the duration of a measurement. >>> >>> If the accuracy of a reported quantity changes on the Metering >>> Process, a new Accuracy Report Interpretation MUST be generated. The >>> Collecting Process MUST keep the accuracy of the latest Accuracy >>> Report Interpretation. >>> >>> Example 1 (to be developed) >>> Records (using template 12): >>> 1. Scope: TemplateId = 5, InformationElementId = 152 >>> Non-scope: fixedAccuracy = 2 >>> => we have a accuracy of +/- 2ms) The example does not (yet) show how the unit (ms) is determined. >>> Example 2 (to be developed): >>> 1. Scope: TemplateId = 5, InformationElementId = 152 >>> Non-scope: proportionalAccuracy = 0.005 >>> => we had an accuracy of +/- 0.5% >>> >>> >>> --------------------- >>> For the PSAMP information model: >>> >>> fixedAccuracy >>> >>> Description: >>> Describes the accuracy of an Information Element, as a negative >>> and positive relative error in absolute value. What about Description Specifies the maximum possible difference (positive or negative) between the reported value and the actual value for a given Information Element. ? >>> Abstract Data Type: float64 >>> ElementId: 320 >>> Status: current >>> Units: The units of the Information Element for which is accuracy is >>> specified. >>> >>> >>> proportionalAccuracy >>> >>> Description: >>> Describes the accuracy of an Information Element as a negative >>> and positive relative error, expressed as a value between 0 and 1. What about Description Specifies the maximum possible ratio (positive or negative) between the error (difference between reported value and the actual value) and the actual reported value for a given Information Element. ? Thanks, Juergen >>> Abstract Data Type: float64 >>> ElementId: 321 >>> Status: current >>> Units: None >>> >>> informationElementID >>> >>> Description: >>> Contains the ID of another Information Element. >>> Abstract Data Type: unsigned16 >>> Data Type Semantics: identifier >>> ElementId: 303 >>> Status: current >>> Units: None >>> >>> Regards, Benoit. > > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 19:58:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEycf-0002If-AL for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 19:58:21 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEycf-0001d2-1P for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 19:58:21 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEyaD-000CJE-IA for psamp-data@psg.com; Fri, 03 Mar 2006 00:55:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEyaC-000CIk-Qa for psamp@ops.ietf.org; Fri, 03 Mar 2006 00:55:48 +0000 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B3BB31BAC4D; Fri, 3 Mar 2006 01:56:55 +0100 (CET) Date: Fri, 03 Mar 2006 01:55:48 +0100 From: Juergen Quittek To: Paul Aitken , Benoit Claise Cc: psamp Subject: Re: PROTO-19: The timestamp should be reported to microsecond resolution Message-ID: In-Reply-To: <44077E23.8000407@cisco.com> References: <44077C54.1070907@cisco.com> <44077E23.8000407@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Status: O Paul and Benoit, I see no problem with creating "flow-independent" time stamps. However, I would also be fine with the other alternative of using the flow start elements. Thanks, Juergen --On 3/2/06 11:22 PM +0000 Paul Aitken wrote: > Benoit, > >> can we reuse the flowStartMicroSeconds Information Element? >> Or (if you are a purist), the "flow" prefix is confusing in a PSAMP >> implementation? >> Please provide your feedback. > > From the purist perspective, I would prefer to create the new timestamp elements you list. They're more appropriate than flowStart... and may be of use in other ways in future. > >> If the latter, then we must define a new Information Element for the >> microsecond precision. And, while doing that, we should define the >> other precision at the same time: second, millisecond, and nanosecond. > > Agreed. > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 20:17:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEyvZ-0008DY-Q7 for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 20:17:53 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEyvZ-00032X-HI for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 20:17:53 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEypu-000Dic-Od for psamp-data@psg.com; Fri, 03 Mar 2006 01:12:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEypu-000DiN-2s for psamp@ops.ietf.org; Fri, 03 Mar 2006 01:12:02 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k231C0t16757; Fri, 3 Mar 2006 02:12:01 +0100 (CET) Received: from [10.61.64.5] (ams-clip-vpn-dhcp5.cisco.com [10.61.64.5]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k231BxC27593; Fri, 3 Mar 2006 02:11:59 +0100 (CET) Message-ID: <440797DE.6000200@cisco.com> Date: Fri, 03 Mar 2006 02:11:58 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Juergen Quittek CC: Paul Aitken , psamp Subject: Re: PROTO-19: The timestamp should be reported to microsecond resolution References: <44077C54.1070907@cisco.com> <44077E23.8000407@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Status: O Juergen, > Paul and Benoit, > > I see no problem with creating "flow-independent" time stamps. Done in [PSAMP-INFO] and used in [PSAMP-PROTO] Regards, Benoit. > > However, I would also be fine with the other alternative > of using the flow start elements. > > Thanks, > > Juergen > > --On 3/2/06 11:22 PM +0000 Paul Aitken wrote: > >> Benoit, >> >>> can we reuse the flowStartMicroSeconds Information Element? >>> Or (if you are a purist), the "flow" prefix is confusing in a PSAMP >>> implementation? >>> Please provide your feedback. >> >> From the purist perspective, I would prefer to create the new >> timestamp elements you list. They're more appropriate than >> flowStart... and may be of use in other ways in future. >> >>> If the latter, then we must define a new Information Element for the >>> microsecond precision. And, while doing that, we should define the >>> other precision at the same time: second, millisecond, and nanosecond. >> >> Agreed. >> >> -- >> Paul Aitken >> Cisco Systems Ltd, Edinburgh, Scotland. >> >> -- >> to unsubscribe send a message to psamp-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 23:05:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF1XI-00031y-Ow for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 23:05:00 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF1XI-0000oP-FV for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 23:05:00 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF1S1-0002I1-Ak for psamp-data@psg.com; Fri, 03 Mar 2006 03:59:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF1S0-0002Ho-3w for psamp@ops.ietf.org; Fri, 03 Mar 2006 03:59:32 +0000 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id DD37A1BAC4D; Fri, 3 Mar 2006 05:00:37 +0100 (CET) Date: Fri, 03 Mar 2006 04:59:33 +0100 From: Juergen Quittek To: Benoit Claise , psamp Subject: Re: PROTO-108 statement that PSAMP-PROTO meets the PSAMP-FMWK requirements Message-ID: <8A6173402FE916757406F62D@[192.168.1.128]> In-Reply-To: <44078BB1.9020007@cisco.com> References: <44078BB1.9020007@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Status: O --On 3/3/06 1:20 AM +0100 Benoit Claise wrote: > Dear all, > > > PROTO-108 Have a statement that this protocol specification > meets all requirements for the PSAMP protocol stated in the framework > except ... An then have a list of bullets, where at minimum there is > stated "not yet covered" or a longer explanation why it is not > covered. This would be replacement for the long list of requirements > in section 6.1 > > > The section 6.1 was created as an intermediate step while > producing the full PSAMP specifications. > Therefore, there is no point anymore to explain, next to > each [PSAMP-FMWK] requirements, how IPFIX/PSAMP fulfills > it... as all is specified in details in the other sections > of the draft. > > The section 6.1 should be removed and the following text proposal should be added at the end of section 6 > > The PSAMP protocol specifications meets all the protocol > requirements stated in the PSAMP framework document > [PSAMP-FMWK]: > * Extensibility > * Parallel measurement processes > * Encrypted packets > * Indication of information loss > * Accuracy > * Privacy > * Timeliness > * Congestion avoidance > * Secure export: > * Export rate limit > * Microsecond timestamp resolution > > With the choice of IPFIX as PSAMP export protocol, the > compression option mentioned in the framework document > [PSAMP-FMWK] is not addressed. This is much better than the current text. However, it sounds a bit strange to say "meets all" in the first line and "not addressed". What about replacing in the first line "all" with "almost all" and mentioning the exception in the last paragraph: "The only requirements that is not met is export packet compression. With the choice of IPFIX as PSAMP export protocol, the export packet compression option mentioned in the section 8.5 of the framework document [PSAMP-FMWK] is not addressed." > If you object, please let me know. > > Regards, Benoit. Thanks, Juergen -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 02 23:35:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF20j-00011n-V7 for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 23:35:25 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF20j-0001yN-LP for psamp-archive@lists.ietf.org; Thu, 02 Mar 2006 23:35:25 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF1x1-000514-EL for psamp-data@psg.com; Fri, 03 Mar 2006 04:31:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF1x0-00050s-Ha for psamp@ops.ietf.org; Fri, 03 Mar 2006 04:31:34 +0000 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 102391BAC4D; Fri, 3 Mar 2006 05:32:37 +0100 (CET) Date: Fri, 03 Mar 2006 05:31:32 +0100 From: Juergen Quittek To: Benoit Claise Cc: psamp Subject: Re: PSAMP IANA considerations section Message-ID: In-Reply-To: <44031D93.8010404@cisco.com> References: <43A92B20.3020600@cisco.com> <44031D93.8010404@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Status: O Hi Benoit, --On 2/27/06 4:41 PM +0100 Benoit Claise wrote: > > Juergen, > > This open issue should find a solution for the next version of the draft, to be published by Monday. > See inline. >> --On 21.12.2005 11:14 Uhr +0100 Benoit Claise wrote: >> >>> Dear all, >>> >>> Here is a proposal for the IANA considerations section. >>> >>> >>> 1. 9. IANA Considerations >>> >>> The PSAMP Protocol, as set out in this document, has two sets of >>> assigned numbers. Considerations for assigning them are discussed in >>> this section, using the example policies as set out in the >>> "Guidelines for IANA Considerations" document IANA-RFC >>> [RFC2434]. >>> >>> 9.1 IPFIX Related Considerations >>> >>> As the PSAMP protocol uses the IPFIX protocol, refer to the IANA >>> considerations section in [IPFIX-PROTO] for the assignments of >>> numbers used in the protocol and for the numbers used in the >>> information model. >>> >>> 9.2 PSAMP Related Considerations >>> >>> Each new selection method MUST be assigned a unique value for the >>> selectorAlgorithm Information Element. Its configuration >>> parameter(s), along with the way to report it/them with an Options >>> Template, MUST be clearly specified. >>> >>> Each new selection method MUST be assigned a unique value for the >>> selectorAlgorithm Information Element. New assignments for the PSAMP >>> selection method will be administered by IANA, on a First Come First >>> Served basis [RFC 2434], subject to Expert >>> Review [RFC 2434], i.e. review by one of a group of experts >>> designated by an IETF Operations and Management Area Director. The >>> group of experts must double check the Information Elements >>> definitions with already defined Information Elements for >>> completeness, accuracy and redundancy. Those experts will initially >>> be drawn from the Working Group Chairs and document editors of the >>> IPFIX and PSAMP Working Groups. >>> >>> Now, two questions: >>> 1. I'm not too sure whether we should mandate a new IETF RFC for the >>> new selection method description? >> >> This would be a tough requirement. However, it would make sure that the >> new methods is well documented. > So the text proposal is fine with you, right? Yes. Thanks, Juergen -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Fri Mar 03 04:26:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6YN-0007oT-4x for psamp-archive@lists.ietf.org; Fri, 03 Mar 2006 04:26:27 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF6YL-0004Xo-RK for psamp-archive@lists.ietf.org; Fri, 03 Mar 2006 04:26:27 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF6QT-0001ko-ES for psamp-data@psg.com; Fri, 03 Mar 2006 09:18:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF6QS-0001kZ-K3 for psamp@ops.ietf.org; Fri, 03 Mar 2006 09:18:17 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k239IFn16751; Fri, 3 Mar 2006 10:18:15 +0100 (CET) Received: from [10.61.66.104] (ams-clip-vpn-dhcp616.cisco.com [10.61.66.104]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k239IDC02795; Fri, 3 Mar 2006 10:18:13 +0100 (CET) Message-ID: <440809D4.6010301@cisco.com> Date: Fri, 03 Mar 2006 10:18:12 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Juergen Quittek CC: psamp Subject: Re: PROTO-108 statement that PSAMP-PROTO meets the PSAMP-FMWK requirements References: <44078BB1.9020007@cisco.com> <8A6173402FE916757406F62D@[192.168.1.128]> In-Reply-To: <8A6173402FE916757406F62D@[192.168.1.128]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Status: O Hi Juergen, Good catch. Corrected. Thanks and regards, Benoit. > > > --On 3/3/06 1:20 AM +0100 Benoit Claise wrote: > >> Dear all, >> >> >> PROTO-108 Have a statement that this protocol specification >> meets all requirements for the PSAMP protocol stated in the framework >> except ... An then have a list of bullets, where at minimum there is >> stated "not yet covered" or a longer explanation why it is not >> covered. This would be replacement for the long list of requirements >> in section 6.1 >> >> >> The section 6.1 was created as an intermediate step while >> producing the full PSAMP specifications. >> Therefore, there is no point anymore to explain, next to >> each [PSAMP-FMWK] requirements, how IPFIX/PSAMP fulfills >> it... as all is specified in details in the other sections >> of the draft. >> >> The section 6.1 should be removed and the following text > proposal should be added at the end of section 6 >> >> The PSAMP protocol specifications meets all the protocol >> requirements stated in the PSAMP framework document >> [PSAMP-FMWK]: >> * Extensibility >> * Parallel measurement processes >> * Encrypted packets >> * Indication of information loss >> * Accuracy >> * Privacy >> * Timeliness >> * Congestion avoidance >> * Secure export: >> * Export rate limit >> * Microsecond timestamp resolution >> >> With the choice of IPFIX as PSAMP export protocol, the >> compression option mentioned in the framework document >> [PSAMP-FMWK] is not addressed. > > This is much better than the current text. > However, it sounds a bit strange to say "meets all" > in the first line and "not addressed". What about > replacing in the first line "all" with "almost all" > and mentioning the exception in the last paragraph: > > "The only requirements that is not met is export packet > compression. With the choice of IPFIX as PSAMP export protocol, > the export packet compression option mentioned in the section > 8.5 of the framework document [PSAMP-FMWK] is not addressed." > >> If you object, please let me know. >> >> Regards, Benoit. > > Thanks, > > Juergen -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Fri Mar 03 06:33:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF8XZ-0001LV-KK for psamp-archive@lists.ietf.org; Fri, 03 Mar 2006 06:33:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF8XZ-0000Vt-25 for psamp-archive@lists.ietf.org; Fri, 03 Mar 2006 06:33:45 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF8S0-000DkV-RO for psamp-data@psg.com; Fri, 03 Mar 2006 11:28:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [195.37.70.40] (helo=smtp0.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF8Ry-000DkE-Uw for psamp@ops.ietf.org; Fri, 03 Mar 2006 11:27:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A1760200C941; Fri, 3 Mar 2006 12:28:02 +0100 (CET) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22943-01; Fri, 3 Mar 2006 12:28:02 +0100 (CET) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7C493200C8E1; Fri, 3 Mar 2006 12:28:02 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: PSAMP IANA considerations section Date: Fri, 3 Mar 2006 12:27:26 +0100 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0003_01C63EBD.D3D21760" Message-ID: <6D28EBC684A4D94096217AD2FE40087324A64E@venus.office> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: PSAMP IANA considerations section Thread-Index: AcY7tLyTWvcVdDjPTde4RLLUNvfMIQC/N2TQ From: "Thomas Dietz" To: "Benoit Claise" , "Juergen Quittek" Cc: "psamp" X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Status: O This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C63EBD.D3D21760 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Dear Benoit and all, The problem with this is that we want to have well defined selector algorithms, right? So we register a number for each defined algorithm with IANA and mandate a consistant description of the algorithm (propably as RFC). So it gets difficult to have intermediate or vendor specific selector algorithms! I would like to propose a solution for this. However it has the drawback that it makes the definition and usage of vendor specific selector algorithms easier and lifts the pressure of registering new algorithms with IANA. I would change the selectorAlgorithm Information Element from octet to unsigned64. The content would be defined as follows: 6.2.3 selectorAlgorithm Description: Specifies the selector algorithm (e.g., filter, sampler, hash) that was used on a packet. It is exported in the options data flow record to specify how a collector has to interpret a data flow record. The Information Element should be encoded in the following way in an unsigned64 value: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Selector Algorithm Indentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The most significant bit must be set if the selector algorithm is defined by an enterprise and is not registered with IANA. The following 31 bits contain a Selector Algorithm Identifier. This is the value registered with IANA if the enterprise bit E is not set. Otherwise it depends on the Enterprise Number that is encoded in the last 32 bits. The Enterprise Number is the same as defined for Information Element templates. If the Enterprise Bit E is not set the Information Element may be reduced to an unsigned32 data type. If the size is not reduced then the Enterprise number has to be set to 0. The following Selector Algorithms Identifiers are currently defined: * 1 Systematic count-based sampling * 2 Systematic time-based sampling * 3 Random n-out-of-N sampling * 4 Uniform probabilistic sampling * 5 Non-uniform probabilistic sampling * 6 Non-uniform flow state sampling * 7 Match based filtering * 8 Hash based filtering * 9 Router state filtering The parameters for most of these algorithms are defined in this information model. Some parameters - especially those for algorithms 5, 6 and 8 are not covered by this information model since they depend very much on the underlying hardware. Currently there are no hash functions defined. EDITOR'S NOTE: This list may extend to the final version. The "unsigned64" data type is probably not the best choice but keeps the list extensible. Abstract Data Type: unsigned64 Data Type Semantics: identifier ElementId: 302 Status: current The text may still be subject to changes if I expressed myself not clear enough. I hope that makes this element more flexible but still simple enough. Best Regards, Thomas -- Thomas Dietz Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany > -----Original Message----- > From: owner-psamp@ops.ietf.org > [mailto:owner-psamp@ops.ietf.org] On Behalf Of Benoit Claise > Sent: Monday, February 27, 2006 4:41 PM > To: Juergen Quittek > Cc: psamp > Subject: Re: PSAMP IANA considerations section > > Juergen, > > This open issue should find a solution for the next version of the > draft, to be published by Monday. > See inline. > > --On 21.12.2005 11:14 Uhr +0100 Benoit Claise wrote: > > > >> Dear all, > >> > >> Here is a proposal for the IANA considerations section. > >> > >> > >> 1. 9. IANA Considerations > >> > >> The PSAMP Protocol, as set out in this document, has two sets of > >> assigned numbers. Considerations for assigning them are > discussed in > >> this section, using the example policies as set out in the > >> "Guidelines for IANA Considerations" document IANA-RFC > >> [RFC2434]. > >> > >> 9.1 IPFIX Related Considerations > >> > >> As the PSAMP protocol uses the IPFIX protocol, refer to the IANA > >> considerations section in [IPFIX-PROTO] for the assignments of > >> numbers used in the protocol and for the numbers used in the > >> information model. > >> > >> 9.2 PSAMP Related Considerations > >> > >> Each new selection method MUST be assigned a unique value for the > >> selectorAlgorithm Information Element. Its configuration > >> parameter(s), along with the way to report it/them with an Options > >> Template, MUST be clearly specified. > >> > >> Each new selection method MUST be assigned a unique value for the > >> selectorAlgorithm Information Element. New assignments > for the PSAMP > >> selection method will be administered by IANA, on a First > Come First > >> Served basis [RFC 2434], subject to Expert > >> Review [RFC 2434], i.e. review by one of a group of experts > >> designated by an IETF Operations and Management Area > Director. The > >> group of experts must double check the Information Elements > >> definitions with already defined Information Elements for > >> completeness, accuracy and redundancy. Those experts will > initially > >> be drawn from the Working Group Chairs and document editors of the > >> IPFIX and PSAMP Working Groups. > >> > >> Now, two questions: > >> 1. I'm not too sure whether we should mandate a new IETF > RFC for the > >> new selection method description? > > > > This would be a tough requirement. However, it would make > sure that the > > new methods is well documented. > So the text proposal is fine with you, right? > > > >> 2. I'm not too sure whether we should mandate new IANA-registered > >> information elements for the new selection method? > > > > Since we do not have vendor IDs in here, this is the only way of > > achieving > > interoperability. > I had in mind that the selectorAlgorithm could be specified with the > Entreprise Number, for proprietary purposes > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |E| Information Element ident. | Field Length > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure G: Field Specifier format > > > > > >> In other words, can we have proprietary selection > method in the > >> selectorAlgorithm Information Element? > > > > Can't we assign an interval, say [1024 - ...] and declare selection > > methods > > with identifiers in that interval as 'experimental' or even > > 'implementation specific'? > Do we need this if we use a I.E. proprietary definition with the > Entreprise Number? > > Don't forget that the selectorAlgorithm is specified as an octet. > > Regards, Benoit. > > > >> Regards, Benoit. > > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > ------=_NextPart_000_0003_01C63EBD.D3D21760 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcDCCAvgw ggJhoAMCAQICAw9RdTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE3MDkwOTE3WhcNMDYwODE3MDkwOTE3WjBjMQ4wDAYDVQQE EwVEaWV0ejEPMA0GA1UEKhMGVGhvbWFzMRUwEwYDVQQDEwxUaG9tYXMgRGlldHoxKTAnBgkqhkiG 9w0BCQEWGlRob21hcy5EaWV0ekBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA4nhGGaCtAFl95e262kXtWs33/Co8wu3qnQqpmgEkgADwZV1ZGoNphSGYXWmdAO4S C+M2HFzsJ0FJ3eG4KV0IaI+kvuKQdfHbqKSV8OfUTIhwrzjwZVJBvUYagIBF8ksvo37XR8YPg5Hw j/zPFAbRhbGg/mrKj/Za7/P9ouv1onhwigQtOG5qcr3+MHE+I6lmkZM7FrzzNwYSJ0Jq52Q8BUEg LWdhLHnXDFy1d+tCZdtdEK3bKga13+Udc5jC0Yvg8hmY+nrxhUPKcYR038q404eJplla2qtpEC3O IoGTKLYRtcxAtoMQ1VG32AylLKJ59/GQDqXOjr9iCI4qyyj7zwIDAQABozcwNTAlBgNVHREEHjAc gRpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAE2PK+6rLfxJ5o+m3N28Uj0XGeArIfvLtnzZQDvuzz2jaThTjJ7PqULqOzjPsCGT/UsT2Ayo 2ksMnxzcVVIK4iJJlaJ2qJRrORakM2CfmkaxFkrJweezRfMPSp7tlW8QnZ/Johw746jZj5bcnOsV 0gxcXkhfMr9OcjEVsJ6+2eg6MIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkG A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBE aXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIz MTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmlj YXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIs YyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56 fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUw AwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuo SpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMm CZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJ KoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjA dQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn 8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjAp BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6 GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh eILcIRk13iSx0x1G/11fZU8xggNQMIIDTAIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDD1F1MAkGBSsOAwIaBQCgggG8MBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDMwMzExMjcyNFowIwYJKoZIhvcNAQkEMRYEFBOzKgC3 ToqIgXqrSd+JxAMAWwu3MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPUXUwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDD1F1MA0GCSqGSIb3DQEBAQUABIIBAADnJMjs/ioBacUcd6nQ qehcphLK0x5BzXvjOZyxCaTZps+4LfZDbKiwJMUCHWkeTaq2sv1KPsnpagaPF+1/DOtjRL0F+bye WJJg2N9tmzgzW/hOpKmrjNPrL/CBFI1kSA80sftdRagAiqDEUs2pun5orwsN9FOZM/K6X8syPX9g G760X6nMqHHE/JrB3eHzsyXf9dQ2d1BqKx62UcnJcgnXJC3ItexW+vRIjN3LzRYL/UlO/9+oTrEi aVTaXu4Doyw53Vqc+tcKESs+kiX0K2X7AgPT7wGNn3VP492BapJz/ulYfM+vEf8Ixy/VkE7z+62n 6+erYgS4oR2N/pK8T28AAAAAAAA= ------=_NextPart_000_0003_01C63EBD.D3D21760-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Fri Mar 03 06:41:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF8eq-0000O3-BT for psamp-archive@lists.ietf.org; Fri, 03 Mar 2006 06:41:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF8eg-0000hN-8h for psamp-archive@lists.ietf.org; Fri, 03 Mar 2006 06:41:14 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF8be-000Ek3-5S for psamp-data@psg.com; Fri, 03 Mar 2006 11:37:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF8bd-000Ejo-FY for psamp@ops.ietf.org; Fri, 03 Mar 2006 11:37:57 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k23Bbuf26383; Fri, 3 Mar 2006 12:37:56 +0100 (CET) Received: from [10.61.66.104] (ams-clip-vpn-dhcp616.cisco.com [10.61.66.104]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k23BbtC16008; Fri, 3 Mar 2006 12:37:55 +0100 (CET) Message-ID: <44082A92.5060207@cisco.com> Date: Fri, 03 Mar 2006 12:37:54 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ipfix-info@net.doit.wisc.edu, psamp Subject: IPFIX and PSMAP information model: applicability field Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Status: O Dear all, The IPFIX IE's have a property that's not directly displayed in the draft, except in the XML: "applicability". The history behind this "applicability" field is that it should have been used as a guideline, expressing whether a specific Information Element should be used in a data record, an option record or both of them. However, the property is used in [IPFIX-INFO] without any definition - except the values are "option", "data" and "all". While working on the PSAMP information elements, we concluded that this "applicability" field doesn't make sense anymore. 1. It's a guideline anyway, not a specification 2. It's present in the XML text only, while the non-XML text is the authoritative source 3. There are no definitions So the proposal is to remove this "applicability" field from both [IPFIX-INFO] and [PSAMP-INFO]. Feedback? Regards, Benoit. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Fri Mar 03 08:06:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF9zB-0001Ir-Gp for psamp-archive@lists.ietf.org; Fri, 03 Mar 2006 08:06:21 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF9zB-00044G-7u for psamp-archive@lists.ietf.org; Fri, 03 Mar 2006 08:06:21 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF9vE-000MWj-9r for psamp-data@psg.com; Fri, 03 Mar 2006 13:02:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF9vD-000MWR-D6 for psamp@ops.ietf.org; Fri, 03 Mar 2006 13:02:15 +0000 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 261CB1BAC4D; Fri, 3 Mar 2006 14:03:17 +0100 (CET) Date: Fri, 03 Mar 2006 14:02:16 +0100 From: Juergen Quittek To: Benoit Claise , ipfix-info@net.doit.wisc.edu, psamp Subject: Re: IPFIX and PSMAP information model: applicability field Message-ID: <8BE2562ACBC49CF0AD0EBBEB@[192.168.1.128]> In-Reply-To: <44082A92.5060207@cisco.com> References: <44082A92.5060207@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Status: O Benoit, I fully agree to your proposal. Juergen --On 3/3/06 12:37 PM +0100 Benoit Claise wrote: > Dear all, > > The IPFIX IE's have a property that's not directly displayed in the draft, except in the XML: "applicability". > > The history behind this "applicability" field is that it should have been used as a guideline, expressing whether a specific Information Element should be used in a data record, an option record or both of them. However, the property is used in > [IPFIX-INFO] without any definition - except the values are "option", "data" and "all". > > While working on the PSAMP information elements, we concluded that this "applicability" field doesn't make sense anymore. > 1. It's a guideline anyway, not a specification > 2. It's present in the XML text only, while the non-XML text is the authoritative source > 3. There are no definitions > > So the proposal is to remove this "applicability" field from both [IPFIX-INFO] and [PSAMP-INFO]. > Feedback? > > Regards, Benoit. > > > > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Fri Mar 03 08:10:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFA2y-0007yu-0w for psamp-archive@lists.ietf.org; Fri, 03 Mar 2006 08:10:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFA2w-0004GO-Jd for psamp-archive@lists.ietf.org; Fri, 03 Mar 2006 08:10:16 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF9yl-000MrU-Ka for psamp-data@psg.com; Fri, 03 Mar 2006 13:05:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [131.188.37.37] (helo=faui70.informatik.uni-erlangen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF9yj-000MrF-SN for psamp@ops.ietf.org; Fri, 03 Mar 2006 13:05:54 +0000 Received: from faui7as.informatik.uni-erlangen.de (faui7as [131.188.37.230]) by faui70.informatik.uni-erlangen.de (8.9.3p2/8.1.3-FAU) with ESMTP id OAA12380; Fri, 3 Mar 2006 14:05:47 +0100 (MET) Received: from [127.0.0.1] (faui7as.informatik.uni-erlangen.de [131.188.37.230]) by faui7as.informatik.uni-erlangen.de (Postfix) with ESMTP id AE526CC183; Fri, 3 Mar 2006 14:05:46 +0100 (CET) Message-ID: <44083F21.6070508@informatik.uni-erlangen.de> Date: Fri, 03 Mar 2006 14:05:37 +0100 From: Falko Dressler Organization: University of Erlangen-Nuremberg, Germany User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Benoit Claise Cc: ipfix-info@net.doit.wisc.edu, psamp Subject: Re: IPFIX and PSMAP information model: applicability field References: <44082A92.5060207@cisco.com> In-Reply-To: <44082A92.5060207@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Status: O Dear Benoit, dear all, I agree to remove it from the *-info documents. Nevertheless, I think it should be moved to the forthcoming guidelines. Cheers, Falko Benoit Claise wrote: > Dear all, > > The IPFIX IE's have a property that's not directly displayed in the > draft, except in the XML: "applicability". > > The history behind this "applicability" field is that it should have > been used as a guideline, expressing whether a specific Information > Element should be used in a data record, an option record or both of > them. However, the property is used in [IPFIX-INFO] without any > definition - except the values are "option", "data" and "all". > > While working on the PSAMP information elements, we concluded that this > "applicability" field doesn't make sense anymore. > 1. It's a guideline anyway, not a specification > 2. It's present in the XML text only, while the non-XML text is the > authoritative source > 3. There are no definitions > > So the proposal is to remove this "applicability" field from both > [IPFIX-INFO] and [PSAMP-INFO]. > Feedback? > > Regards, Benoit. > > > > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Dr.-Ing. Falko Dressler Computer Networks and Communication Systems University of Erlangen-Nuremberg, Germany Phone: +49 9131 85-27914 / Fax: +49 9131 85-27409 EMail: dressler@informatik.uni-erlangen.de / fd@acm.org WWW: http://www7.informatik.uni-erlangen.de/~dressler/ -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Fri Mar 03 10:10:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBuz-0004mG-AK for psamp-archive@lists.ietf.org; Fri, 03 Mar 2006 10:10:09 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFBuy-0000Gq-Tf for psamp-archive@lists.ietf.org; Fri, 03 Mar 2006 10:10:09 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFBnI-0007C0-00 for psamp-data@psg.com; Fri, 03 Mar 2006 15:02:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_30_40,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFBnH-0007Bm-4I for psamp@ops.ietf.org; Fri, 03 Mar 2006 15:02:11 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k23F29E10054; Fri, 3 Mar 2006 16:02:09 +0100 (CET) Received: from [10.61.66.104] (ams-clip-vpn-dhcp616.cisco.com [10.61.66.104]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k23F28C28976; Fri, 3 Mar 2006 16:02:08 +0100 (CET) Message-ID: <44085A70.3090701@cisco.com> Date: Fri, 03 Mar 2006 16:02:08 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Falko Dressler CC: ipfix-info@net.doit.wisc.edu, psamp Subject: Re: IPFIX and PSMAP information model: applicability field References: <44082A92.5060207@cisco.com> <44083F21.6070508@informatik.uni-erlangen.de> In-Reply-To: <44083F21.6070508@informatik.uni-erlangen.de> Content-Type: multipart/alternative; boundary="------------030308020401070200050807" Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Status: O This is a multi-part message in MIME format. --------------030308020401070200050807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Falko, > Dear Benoit, dear all, > > I agree to remove it from the *-info documents. Nevertheless, I think it > should be moved to the forthcoming guidelines. > That would make sense for the I.Es. that clearly belong to a category. Regards, Benoit. > Cheers, > Falko > > Benoit Claise wrote: > >> Dear all, >> >> The IPFIX IE's have a property that's not directly displayed in the >> draft, except in the XML: "applicability". >> >> The history behind this "applicability" field is that it should have >> been used as a guideline, expressing whether a specific Information >> Element should be used in a data record, an option record or both of >> them. However, the property is used in [IPFIX-INFO] without any >> definition - except the values are "option", "data" and "all". >> >> While working on the PSAMP information elements, we concluded that this >> "applicability" field doesn't make sense anymore. >> 1. It's a guideline anyway, not a specification >> 2. It's present in the XML text only, while the non-XML text is the >> authoritative source >> 3. There are no definitions >> >> So the proposal is to remove this "applicability" field from both >> [IPFIX-INFO] and [PSAMP-INFO]. >> Feedback? >> >> Regards, Benoit. >> >> >> >> >> -- >> to unsubscribe send a message to psamp-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> > > --------------030308020401070200050807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Falko,
Dear Benoit, dear all,

I agree to remove it from the *-info documents. Nevertheless, I think it
should be moved to the forthcoming guidelines.
That would make sense for the I.Es. that clearly belong to a category.

Regards, Benoit.
Cheers,
Falko

Benoit Claise wrote:
  
Dear all,

The IPFIX IE's have a property that's not directly displayed in the
draft, except in the XML: "applicability".

The history behind this "applicability" field is that it should have
been used as a guideline, expressing whether a specific Information
Element should be used in a data record, an option record or both of
them. However, the property is used in [IPFIX-INFO] without any
definition - except the values are "option", "data" and "all".

While working on the PSAMP information elements, we concluded that this
"applicability" field doesn't make sense anymore.
1. It's a guideline anyway, not a specification
2. It's present in the XML text only, while the non-XML text is the
authoritative source
3. There are no definitions

So the proposal is to remove this "applicability" field from both
[IPFIX-INFO] and [PSAMP-INFO].
Feedback?

Regards, Benoit.




-- 
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>

--------------030308020401070200050807-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Fri Mar 03 12:30:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFE76-0000V0-S8 for psamp-archive@lists.ietf.org; Fri, 03 Mar 2006 12:30:48 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFE75-0005uX-BS for psamp-archive@lists.ietf.org; Fri, 03 Mar 2006 12:30:48 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFE1y-000KNt-HK for psamp-data@psg.com; Fri, 03 Mar 2006 17:25:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFE1x-000KNi-Pm for psamp@ops.ietf.org; Fri, 03 Mar 2006 17:25:29 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Mar 2006 18:25:29 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k23HPS36011123; Fri, 3 Mar 2006 18:25:28 +0100 (MET) Received: from [10.61.82.135] (ams-clip-vpn-dhcp4744.cisco.com [10.61.82.135]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA22161; Fri, 3 Mar 2006 17:25:27 GMT Message-ID: <44087C07.8050103@cisco.com> Date: Fri, 03 Mar 2006 17:25:27 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , psamp Subject: Re: PROTO-17: Encrypted Packets + PROTO-106: extend security considerations on exported Payload References: <44071210.3060408@cisco.com> <44078D66.8080006@cisco.com> In-Reply-To: <44078D66.8080006@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Status: O Benoit Claise wrote: > Juergen, >> >> I support this solution for PROTO-17. >> >> I also support the intention behind the suggested text >> that addresses PROTO-106. But I do not see how it would be >> realized. How would an implementation ensure that it does >> not export the full payload of a conversation? > I don't have the answer. > [PSAMP-FMWK] is not clearer: > > * Privacy: selection of the content of Packet Reports will be > cognizant of privacy and anonymity issues while being > responsive to the needs of measurement applications, and in > accordance with [RFC-2804]. Full packet capture of arbitrary > packet streams is explicitly out of scope. > Do you have a suggestion? I think that the best we can do, and the spirit of the text, is to simply not explain or make any special provisions for the capture of full packets. While our protocol may be used in such a way, it will not be designed with this in mind. We are creating a tool, we cannot limit what the tool will be used for. Andrew -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Fri Mar 03 15:39:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFH3t-00073D-11 for psamp-archive@lists.ietf.org; Fri, 03 Mar 2006 15:39:41 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFH3s-00042n-Dq for psamp-archive@lists.ietf.org; Fri, 03 Mar 2006 15:39:41 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFGuz-000Afw-3V for psamp-data@psg.com; Fri, 03 Mar 2006 20:30:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFGux-000Afk-RI for psamp@ops.ietf.org; Fri, 03 Mar 2006 20:30:28 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Mar 2006 21:30:27 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k23KUQ36009777 for ; Fri, 3 Mar 2006 21:30:26 +0100 (MET) Received: from [10.61.82.135] (ams-clip-vpn-dhcp4744.cisco.com [10.61.82.135]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id UAA09185 for ; Fri, 3 Mar 2006 20:30:25 GMT Message-ID: <4408A761.5070707@cisco.com> Date: Fri, 03 Mar 2006 20:30:25 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: psamp Subject: Proposal for PSAMP-PROTO section 6.5.2.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Status: O Hello all Below is the proposed text for the PSAMP protocol section 6.5.2.6 (Hash-Based Filtering) and for the changes to the Basic Packet Report to include the result of a Packet Digest Function. Things to note: - The input to the hash function is mandated and fixed. - CRC, IPSX and BOB MAY be used for filtering or packet digest. - To ensure interoperability certain configurable ranges are mandated. Are these ranges appropriate? - To stop someone has snooped the hash configuration from shaping their traffic to manipulate detection the initialisation value is optional. Is this sufficient? Does it only work with BOB? Suggested change to basic packet report text: =================================================================== For each selected packet, the Packet Report MUST contain the following information: - ... - The hash value (digestHashValue) generated by the digest hash function. If there are no digest functions in the selection sequence then no element needs to be sent. If there are more than one digest function then each hash value must be included in the same order as they appear in the selection sequence. =================================================================== Potentially we can add this to the example: =================================================================== IPFIX Template Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 260 | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | selectionPath = 321 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | digestHashValue = 326 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ipHeaderPacketSection = 313 | Field Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The associated IPFIX Data Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 260 | Length = 24 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x9123 0613 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x4500 005B | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xA174 0000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF11 832E | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure D: Example of a Basic Packet Report =================================================================== Note: this means that any digest hash function must take the same parameters as a selection hash function. I think this is currently the best option for interoperability. Secondly we will need a report to communicate the configuration of the hash-based selector to the Collecting Process. =================================================================== 6.5.2.6 Hash-Based Filtering In hash based selection a hash function is run on IPv4 traffic the following fields MUST be used as input to that hash function: - IP identification field - Flags field - Fragment offset - Source IP address - Destination IP address - A number of bytes from the IP payload. The number of bytes and starting offset MUST be configurable if possible. For the bytes taken from the IP payload, IPSX has a fixed offset of 0 bytes and a fixed size of 8 bytes. The number and offset of payload bytes in the BOB function MUST be configurable. If any of the configured set of bytes from the IP payload are unavailable then 0 MUST be used, which may result in a different value than if the hash function is run on a subset of the input. The minimum configuration ranges MUST be as follows: Number of bytes: from 8 to 32 Offset: from 0 to 64 If the selected payload bytes are not available and the hash function can take a variable sized input then the hash function MUST be run with the information which is available and a shorter size. Passing 0 as a substitute for missing payload bytes is only acceptable if the hash function takes a fixed size as is the case with IPSX. If the hash function can take a initialisation value then this value MUST be configurable. A hash-based selection function MAY be configurable as a digest function. Any selection process which is configured as a digest function MUST have the output value included in the basic packet report for any selected packet. Each hash function used as a hash-based selector requires it's own value for the selectorAlgorithm. Currently we have BOB (6), IPSX (7) and CRC (8) defined and any MAY be used for either either Filtering or creating a Packet Digest. Only BOB is recommended though and SHOULD be used. The REQUIRED algorithm specific Information Elements in case of hash based selection are: hashIPPayloadOffset - The configured or set payload offset hashIPPayloadSize - The configured or set payload size hashOutputRangeMin - One or more values for the beginning of each potential output range. hashOutputRangeMax - One or more values for the end of each potential output range. hashSelectedRangeMin - One or more values for the beginning of each selected range. hashSelectedRangeMax - One or more values for the end of each selected range. hashDigestOutput - A boolean value, TRUE if the output from this selector has been configured to be included in the packet report as a packet digest. NOTE: If more than one selection or output range needs to be sent then the minimum and maximum elements may be repeated as needed. These MUST make one or more non-overlapping ranges. The elements SHOULD be sent as pairs of minimum and maximum in ascending order, however if they are sent out of order then there will only be one way to interpret the ranges to produce a non-overlapping range and the Collecting Process MUST be prepared to accept and decode this. The following algorithm specific Information Element MAY be sent, but is optional for security considerations: hashInitialiserValue - The initialiser value to the hash function. Example of a hash based filter Selector, whose configuration is: Hash Function = BOB Hash IP Payload Offset = 0 Hash IP Payload Size = 16 Hash Initialiser Value = 0x9A3F9A3F Hash Output Range = 0 to 0xFFFFFFFF Hash Selected Range = 100 to 200 and 400 to 500 IPFIX Options Template Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 50 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 269 | Field Count = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 |0| selectorId = 300 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Length = 4 |0| selectorAlgorithm = 302 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 |0| hashIPpayloadOffset = 327 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| hashIPpayloadSize = 328 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| hashInitialiserValue = 329 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| hashOutputRangeMin = 330 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| hashOutputRangeMax = 331 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| hashSeletionRangeMin = 332 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| hashSeletionRangeMax = 333 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| hashSeletionRangeMin = 332 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| hashSeletionRangeMax = 333 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Associated IPFIX Data Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 266 | Length = 45 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 0 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 16 | 0x9A3F9A ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 3F | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 0 | 0xFFFFFF ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... FF | ... 100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... 200 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... 400 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... 500 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+ Figure K: Example of the Selector Report Interpretation, for Hash Based Filtering Notes: * A selectorAlgorithm value of 6 represents hash-based Filtering using the BOB algorithm. =================================================================== -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Fri Mar 03 17:52:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFJ87-0001kv-26 for psamp-archive@lists.ietf.org; Fri, 03 Mar 2006 17:52:11 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFJ86-0001IW-EI for psamp-archive@lists.ietf.org; Fri, 03 Mar 2006 17:52:11 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFJ3Q-000Lww-Si for psamp-data@psg.com; Fri, 03 Mar 2006 22:47:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFJ3P-000Lwf-Bp for psamp@ops.ietf.org; Fri, 03 Mar 2006 22:47:19 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k23MlII08441; Fri, 3 Mar 2006 23:47:18 +0100 (CET) Received: from [10.61.66.104] (ams-clip-vpn-dhcp616.cisco.com [10.61.66.104]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k23MlHC17125; Fri, 3 Mar 2006 23:47:17 +0100 (CET) Message-ID: <4408C775.90202@cisco.com> Date: Fri, 03 Mar 2006 23:47:17 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Thomas Dietz CC: Juergen Quittek , psamp Subject: Re: PSAMP IANA considerations section References: <6D28EBC684A4D94096217AD2FE40087324A64E@venus.office> In-Reply-To: <6D28EBC684A4D94096217AD2FE40087324A64E@venus.office> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Status: O Dear Thomas, If I wanted to specify a new algorithm (filter, sampler, hash) private for my company, I would do the following: - specify a proprietary I.E., whose name is selectorAlgorithm, exactly the same one as in [PSAMP-INFO] - I would make sure I don't re-use the existing selectorAlgorithm values as specified in [PSAMP-INFO] and IANA So I would start from a higher range. What I'm describing is already possible with IPFIX, as a generic mechanism. Section 3.2 of [IPFIX-PROTO] doesn't preclude the use an existing IPFIX I.E. name as an enterprise specific I.E. As this is a generic mechanism, why limit this to the selectorAlgorithm I.E. description? Example 1: I want to redefine the octetDeltaCount with an Entreprise ID to contain the MPLS header Example 2: I want to add some extra reasons to the flowEndReason So why not add the same remark in some other I.E. description? So I fail to understand what we gain by adding this in the Information Element description? It doesn't even simplify the Collector job: - If it receives selectorAlgorithm without Enterprise ID, it knows where to look up the meaning - If it receives selectorAlgorithm with Enterprise ID, it must look in the specific enterprise registry. In conclusion, I don't see the need for explaining in a I.E. description what is possible by the IPFIX protocol Regards, Benoit. > Dear Benoit and all, > > The problem with this is that we want to have well defined selector > algorithms, right? So we register a number for each defined algorithm with > IANA and mandate a consistant description of the algorithm (propably as > RFC). So it gets difficult to have intermediate or vendor specific selector > algorithms! I would like to propose a solution for this. However it has the > drawback that it makes the definition and usage of vendor specific selector > algorithms easier and lifts the pressure of registering new algorithms with > IANA. > > I would change the selectorAlgorithm Information Element from octet to > unsigned64. The content would be defined as follows: > > 6.2.3 selectorAlgorithm > > Description: > Specifies the selector algorithm (e.g., filter, sampler, hash) > that was used on a packet. It is exported in the options data > flow record to specify how a collector has to interpret a data > flow record. The Information Element should be encoded in the > following way in an unsigned64 value: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |E| Selector Algorithm Indentifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The most significant bit must be set if the selector algorithm is > defined by an enterprise and is not registered with IANA. The > following 31 bits contain a Selector Algorithm Identifier. This > is the value registered with IANA if the enterprise bit E is not > set. Otherwise it depends on the Enterprise Number that is > encoded in the last 32 bits. The Enterprise Number is the same > as defined for Information Element templates. If the Enterprise > Bit E is not set the Information Element may be reduced to an > unsigned32 data type. If the size is not reduced then the > Enterprise number has to be set to 0. > > The following Selector Algorithms Identifiers are currently > defined: > * 1 Systematic count-based sampling > * 2 Systematic time-based sampling > * 3 Random n-out-of-N sampling > * 4 Uniform probabilistic sampling > * 5 Non-uniform probabilistic sampling > * 6 Non-uniform flow state sampling > * 7 Match based filtering > * 8 Hash based filtering > * 9 Router state filtering > > The parameters for most of these algorithms are defined in this > information model. Some parameters - especially those for > algorithms 5, 6 and 8 are not covered by this information model > since they depend very much on the underlying hardware. > Currently there are no hash functions defined. > > EDITOR'S NOTE: This list may extend to the final version. The > "unsigned64" data type is probably not the best choice but keeps the > list extensible. > Abstract Data Type: unsigned64 > Data Type Semantics: identifier > ElementId: 302 > Status: current > > The text may still be subject to changes if I expressed myself not clear > enough. > > I hope that makes this element more flexible but still simple enough. > > Best Regards, > > Thomas > > -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Mar 06 04:21:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGBuN-0005Qi-5O for psamp-archive@lists.ietf.org; Mon, 06 Mar 2006 04:21:39 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGBuN-0007yo-2d for psamp-archive@lists.ietf.org; Mon, 06 Mar 2006 04:21:39 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGBkb-0006aZ-Sy for psamp-archive@lists.ietf.org; Mon, 06 Mar 2006 04:11:35 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGBcU-000Ltv-7s for psamp-data@psg.com; Mon, 06 Mar 2006 09:03:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [195.37.70.40] (helo=smtp0.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGBcR-000Ltf-MY for psamp@ops.ietf.org; Mon, 06 Mar 2006 09:03:08 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id E98DF200C8E1; Mon, 6 Mar 2006 10:03:11 +0100 (CET) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30172-01; Mon, 6 Mar 2006 10:03:11 +0100 (CET) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C41792007D79; Mon, 6 Mar 2006 10:03:11 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Proposal for PSAMP-PROTO section 6.5.2.6 Date: Mon, 6 Mar 2006 10:02:19 +0100 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0018_01C64105.0E02E330" Message-ID: <6D28EBC684A4D94096217AD2FE40087324A735@venus.office> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Proposal for PSAMP-PROTO section 6.5.2.6 Thread-Index: AcY/AoaY1OZcu2YqSlyzAppqugg80QB+ayAA From: "Thomas Dietz" To: "Andrew Johnson" , "psamp" X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: e06437eb72f6703f11713d345be8298a Status: O This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C64105.0E02E330 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Andrew and all, I know I am too late to make it for this version but just one small comment for wording. > =================================================================== > 6.5.2.6 Hash-Based Filtering > > In hash based selection a hash function is run on IPv4 traffic > the following fields MUST be used as input to that hash function: > - IP identification field > - Flags field > - Fragment offset > - Source IP address > - Destination IP address > - A number of bytes from the IP payload. The number of bytes > and starting offset MUST be configurable if possible. I would propose - A number of bytes from the IP payload. The number of bytes and starting offset MUST be configurable if the hash function supports it. BTW, Andrew, I very much appriciate your work on the hash functions. Now this looks really consistent. Best Regards, Thomas -- Thomas Dietz E-mail: Thomas.Dietz@netlab.nec.de Network Laboratories Phone: +49 6221 90511-28 NEC Europe Ltd. Fax: +49 6221 90511-55 Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.netlab.nec.de > -----Original Message----- > From: owner-psamp@ops.ietf.org > [mailto:owner-psamp@ops.ietf.org] On Behalf Of Andrew Johnson > Sent: Friday, March 03, 2006 9:30 PM > To: psamp > Subject: Proposal for PSAMP-PROTO section 6.5.2.6 > > Hello all > > Below is the proposed text for the PSAMP protocol section 6.5.2.6 > (Hash-Based Filtering) and for the changes to the Basic Packet > Report to include the result of a Packet Digest Function. > > Things to note: > - The input to the hash function is mandated and fixed. > - CRC, IPSX and BOB MAY be used for filtering or packet digest. > - To ensure interoperability certain configurable ranges are > mandated. Are these ranges appropriate? > - To stop someone has snooped the hash configuration from shaping > their traffic to manipulate detection the initialisation value > is optional. Is this sufficient? Does it only work with BOB? > > > Suggested change to basic packet report text: > > =================================================================== > For each selected packet, the Packet Report MUST contain the > following information: > - ... > - The hash value (digestHashValue) generated by the digest hash > function. If there are no digest functions in the selection > sequence then no element needs to be sent. If there are more than > one digest function then each hash value must be included in > the same order as they appear in the selection sequence. > =================================================================== > > Potentially we can add this to the example: > > =================================================================== > IPFIX Template Record: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 20 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 260 | Field Count = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | selectionPath = 321 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | digestHashValue = 326 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ipHeaderPacketSection = 313 | Field Length = 12 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The associated IPFIX Data Record: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 260 | Length = 24 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 9 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x9123 0613 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x4500 005B | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0xA174 0000 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0xFF11 832E | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure D: Example of a Basic Packet Report > =================================================================== > > Note: this means that any digest hash function must take the same > parameters as a selection hash function. I think this is currently > the best option for interoperability. > > > Secondly we will need a report to communicate the configuration > of the hash-based selector to the Collecting Process. > > =================================================================== > 6.5.2.6 Hash-Based Filtering > > In hash based selection a hash function is run on IPv4 traffic > the following fields MUST be used as input to that hash function: > - IP identification field > - Flags field > - Fragment offset > - Source IP address > - Destination IP address > - A number of bytes from the IP payload. The number of bytes > and starting offset MUST be configurable if possible. > > For the bytes taken from the IP payload, IPSX has a fixed offset > of 0 bytes and a fixed size of 8 bytes. The number and offset of > payload bytes in the BOB function MUST be configurable. If any > of the configured set of bytes from the IP payload are unavailable > then 0 MUST be used, which may result in a different value than > if the hash function is run on a subset of the input. > > The minimum configuration ranges MUST be as follows: > Number of bytes: from 8 to 32 > Offset: from 0 to 64 > > If the selected payload bytes are not available and the hash function > can take a variable sized input then the hash function MUST be run > with the information which is available and a shorter size. Passing > 0 as a substitute for missing payload bytes is only acceptable if > the hash function takes a fixed size as is the case with IPSX. > > If the hash function can take a initialisation value then this > value MUST be configurable. > > A hash-based selection function MAY be configurable as a digest > function. Any selection process which is configured as a digest > function MUST have the output value included in the basic packet > report for any selected packet. > > Each hash function used as a hash-based selector requires it's own > value for the selectorAlgorithm. Currently we have BOB (6), IPSX (7) > and CRC (8) defined and any MAY be used for either either Filtering > or creating a Packet Digest. Only BOB is recommended though and > SHOULD be used. > > The REQUIRED algorithm specific Information Elements in case of hash > based selection are: > > hashIPPayloadOffset - The configured or set payload offset > hashIPPayloadSize - The configured or set payload size > hashOutputRangeMin - One or more values for the beginning of > each potential output range. > hashOutputRangeMax - One or more values for the end of each > potential output range. > hashSelectedRangeMin - One or more values for the beginning of > each selected range. > hashSelectedRangeMax - One or more values for the end of each > selected range. > hashDigestOutput - A boolean value, TRUE if the output from > this selector has been configured to be > included in the packet report as a packet > digest. > > NOTE: If more than one selection or output range needs to be sent > then the minimum and maximum elements may be repeated as needed. > These MUST make one or more non-overlapping ranges. The elements > SHOULD be sent as pairs of minimum and maximum in ascending order, > however if they are sent out of order then there will only be one > way to interpret the ranges to produce a non-overlapping range and > the Collecting Process MUST be prepared to accept and decode this. > > The following algorithm specific Information Element MAY be sent, > but is optional for security considerations: > hashInitialiserValue - The initialiser value to the hash function. > > Example of a hash based filter Selector, whose configuration is: > Hash Function = BOB > Hash IP Payload Offset = 0 > Hash IP Payload Size = 16 > Hash Initialiser Value = 0x9A3F9A3F > Hash Output Range = 0 to 0xFFFFFFFF > Hash Selected Range = 100 to 200 and 400 to 500 > > IPFIX Options Template Record: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 3 | Length = 50 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 269 | Field Count = 8 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope Field Count = 1 |0| selectorId = 300 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope 1 Length = 4 |0| selectorAlgorithm = 302 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 1 |0| hashIPpayloadOffset = 327 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| hashIPpayloadSize = 328 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| hashInitialiserValue = 329 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| hashOutputRangeMin = 330 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| hashOutputRangeMax = 331 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| hashSeletionRangeMin = 332 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| hashSeletionRangeMax = 333 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| hashSeletionRangeMin = 332 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| hashSeletionRangeMax = 333 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Associated IPFIX Data Record: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 266 | Length = 45 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 22 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 6 | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... 0 | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... 16 | 0x9A3F9A ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... 3F | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... 0 | 0xFFFFFF ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... FF | ... 100 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | ... 200 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | ... 400 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | ... 500 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+ > > Figure K: Example of the Selector Report Interpretation, > for Hash Based Filtering > > Notes: > * A selectorAlgorithm value of 6 represents hash-based Filtering > using the BOB algorithm. > > =================================================================== > > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > ------=_NextPart_000_0018_01C64105.0E02E330 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcDCCAvgw ggJhoAMCAQICAw9RdTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE3MDkwOTE3WhcNMDYwODE3MDkwOTE3WjBjMQ4wDAYDVQQE EwVEaWV0ejEPMA0GA1UEKhMGVGhvbWFzMRUwEwYDVQQDEwxUaG9tYXMgRGlldHoxKTAnBgkqhkiG 9w0BCQEWGlRob21hcy5EaWV0ekBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA4nhGGaCtAFl95e262kXtWs33/Co8wu3qnQqpmgEkgADwZV1ZGoNphSGYXWmdAO4S C+M2HFzsJ0FJ3eG4KV0IaI+kvuKQdfHbqKSV8OfUTIhwrzjwZVJBvUYagIBF8ksvo37XR8YPg5Hw j/zPFAbRhbGg/mrKj/Za7/P9ouv1onhwigQtOG5qcr3+MHE+I6lmkZM7FrzzNwYSJ0Jq52Q8BUEg LWdhLHnXDFy1d+tCZdtdEK3bKga13+Udc5jC0Yvg8hmY+nrxhUPKcYR038q404eJplla2qtpEC3O IoGTKLYRtcxAtoMQ1VG32AylLKJ59/GQDqXOjr9iCI4qyyj7zwIDAQABozcwNTAlBgNVHREEHjAc gRpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAE2PK+6rLfxJ5o+m3N28Uj0XGeArIfvLtnzZQDvuzz2jaThTjJ7PqULqOzjPsCGT/UsT2Ayo 2ksMnxzcVVIK4iJJlaJ2qJRrORakM2CfmkaxFkrJweezRfMPSp7tlW8QnZ/Johw746jZj5bcnOsV 0gxcXkhfMr9OcjEVsJ6+2eg6MIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkG A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBE aXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIz MTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmlj YXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIs YyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56 fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUw AwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuo SpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMm CZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJ KoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjA dQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn 8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjAp BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6 GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh eILcIRk13iSx0x1G/11fZU8xggNQMIIDTAIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDD1F1MAkGBSsOAwIaBQCgggG8MBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDMwNjA5MDIxOVowIwYJKoZIhvcNAQkEMRYEFCi0Raxc 9P9dpY/1lMsnFYkC/QI+MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPUXUwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDD1F1MA0GCSqGSIb3DQEBAQUABIIBAClav3vH95cXKIF7rLh7 KiCPLrGLz4FEwnp+v7jR5McwkJN1fj0770+LxMtd/8PycnSVYjHX+5lIYTa2NlO0s0fB4fGy5Qxa PgaQaDgdmfMdpKt5l0sLUZoqH6IhvKOUeFdZ2TbO2BZjhQ8VKy59QnnyOs7aaYX5z/ndoYJLunKd Hhyy0hBoA5F/DeeCjeD1MysEqjv0ebPP7S84mWB/J2AvId9UD89jHEI3TWeezi4QLb/fQlt1uotQ ySswUS1ssORmUjbIvFA/qTReP++AiCSO0vH2lHr/i9w04y0cvWHMzD6vskKQCMMRswkPWkB1w2Jm wwsZVteTss+BkDa77xAAAAAAAAA= ------=_NextPart_000_0018_01C64105.0E02E330-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Mar 06 06:48:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGEC0-000471-2D for psamp-archive@lists.ietf.org; Mon, 06 Mar 2006 06:48:00 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGEBy-0005Zh-OY for psamp-archive@lists.ietf.org; Mon, 06 Mar 2006 06:48:00 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGE7p-000791-Er for psamp-data@psg.com; Mon, 06 Mar 2006 11:43:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGE7o-00078h-QY for psamp@ops.ietf.org; Mon, 06 Mar 2006 11:43:40 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 06 Mar 2006 12:43:39 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k26Bhd36018837 for ; Mon, 6 Mar 2006 12:43:39 +0100 (MET) Received: from [10.61.82.33] (ams-clip-vpn-dhcp4642.cisco.com [10.61.82.33]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA02394 for ; Mon, 6 Mar 2006 11:43:38 GMT Message-ID: <440C206A.9050902@cisco.com> Date: Mon, 06 Mar 2006 11:43:38 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.10) Gecko/20050811 Fedora/1.7.10-1.2.1.legacy X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: psamp Subject: PSAMP: ipHeaderPacketSection and mplsLabelStackSection Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Status: O Dear psampers, We have a new open issue in PSAMP-INFO: Should the ipHeaderPacketSection and mplsLabelStackSection also report payload contents if the specified section length is longer than the IP header or stack size, respectively? ipHeaderPacketSection is currently defined as: This information element carries a series of octets from the start of the IP header of a sampled packet. mplsLabelStackSection is currently defined as: This information element carries the first n octets from the MPLS label stack of a sampled packet. Potential resolutions include: (1) We define the behaviour when the requested ipHeaderPacketSection or mplsLabelStackSectionsection size is larger than the actual amount of IP header / label stack data available. (1a) We define that only IP header / label stack octets are included. (1b) We define that the section contains a series of octets starting from the beginning of the IP header / label stack and continuing through the payload up to the limit of the available data. (2) We say nothing, and leave it as implimentation defined behaviour. I believe that allowing these sections to continue into the payload per (1b) is potentially the most useful solution. It saves configuring the capture of seperate header and payload elements where capture of the header and first few octets of the payload are desired for packet identification and analysis. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Mar 06 13:37:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGKZv-0000qi-MZ for psamp-archive@lists.ietf.org; Mon, 06 Mar 2006 13:37:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGKZu-00050L-8Y for psamp-archive@lists.ietf.org; Mon, 06 Mar 2006 13:37:07 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGKSs-000649-IX for psamp-data@psg.com; Mon, 06 Mar 2006 18:29:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [131.188.37.37] (helo=faui70.informatik.uni-erlangen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGKSq-00063p-CM for psamp@ops.ietf.org; Mon, 06 Mar 2006 18:29:48 +0000 Received: from faui7as.informatik.uni-erlangen.de (faui7as [131.188.37.230]) by faui70.informatik.uni-erlangen.de (8.9.3p2/8.1.3-FAU) with ESMTP id TAA01552; Mon, 6 Mar 2006 19:29:43 +0100 (MET) Received: from [127.0.0.1] (faui7as.informatik.uni-erlangen.de [131.188.37.230]) by faui7as.informatik.uni-erlangen.de (Postfix) with ESMTP id 18072CC20D; Mon, 6 Mar 2006 19:29:43 +0100 (CET) Message-ID: <440C7F92.7@informatik.uni-erlangen.de> Date: Mon, 06 Mar 2006 19:29:38 +0100 From: Falko Dressler Organization: University of Erlangen-Nuremberg, Germany User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Paul Aitken Cc: psamp Subject: Re: PSAMP: ipHeaderPacketSection and mplsLabelStackSection References: <440C206A.9050902@cisco.com> In-Reply-To: <440C206A.9050902@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Status: O Paul, this is indeed a difficult issue. At the first look, I was about saying "yes, 1b) is the best solution because it provides the highest flexibility". Nevertheless, I fear that many applications will derrive that allow to monitor packet payload but do not offer to analyze the packet header, i.e. such monitors are just "remote-pcap-devices". This is quite fine but makes most of PSAMP functionality (IEs) unnecessary. 1a) is maybe too hard and 2) says "nothing" so may final answer is either 2) or we need to elaborate a 1c) Cheers, Falko Paul Aitken wrote: > Dear psampers, > > We have a new open issue in PSAMP-INFO: > > Should the ipHeaderPacketSection and mplsLabelStackSection also > report payload contents if the specified section length is longer > than the IP header or stack size, respectively? > > > ipHeaderPacketSection is currently defined as: > > This information element carries a series of octets from the start > of the IP header of a sampled packet. > > > mplsLabelStackSection is currently defined as: > > This information element carries the first n octets from the MPLS > label stack of a sampled packet. > > > Potential resolutions include: > > (1) We define the behaviour when the requested ipHeaderPacketSection > or mplsLabelStackSectionsection size is larger than the actual amount of > IP header / label stack data available. > > (1a) We define that only IP header / label stack octets are included. > > (1b) We define that the section contains a series of octets starting > from the beginning of the IP header / label stack and continuing > through the payload up to the limit of the available data. > > (2) We say nothing, and leave it as implimentation defined behaviour. > > > I believe that allowing these sections to continue into the payload per > (1b) is potentially the most useful solution. > > It saves configuring the capture of seperate header and payload elements > where capture of the header and first few octets of the payload are > desired for packet identification and analysis. > -- Dr.-Ing. Falko Dressler Computer Networks and Communication Systems University of Erlangen-Nuremberg, Germany Phone: +49 9131 85-27914 / Fax: +49 9131 85-27409 EMail: dressler@informatik.uni-erlangen.de / fd@acm.org WWW: http://www7.informatik.uni-erlangen.de/~dressler/ -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Tue Mar 07 05:01:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZ0s-00080H-6G for psamp-archive@lists.ietf.org; Tue, 07 Mar 2006 05:01:54 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGZ0r-0004Pg-T4 for psamp-archive@lists.ietf.org; Tue, 07 Mar 2006 05:01:54 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGYsm-000D57-8M for psamp-data@psg.com; Tue, 07 Mar 2006 09:53:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGYsk-000D4v-P5 for psamp@ops.ietf.org; Tue, 07 Mar 2006 09:53:31 +0000 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6CE9D1BAC4D; Tue, 7 Mar 2006 10:54:06 +0100 (CET) Date: Tue, 07 Mar 2006 10:53:37 +0100 From: Juergen Quittek To: Paul Aitken , psamp Subject: Re: PSAMP: ipHeaderPacketSection and mplsLabelStackSection Message-ID: In-Reply-To: <440C206A.9050902@cisco.com> References: <440C206A.9050902@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Status: O --On 3/6/06 11:43 AM +0000 Paul Aitken wrote: > Dear psampers, > > We have a new open issue in PSAMP-INFO: > > Should the ipHeaderPacketSection and mplsLabelStackSection also > report payload contents if the specified section length is longer > than the IP header or stack size, respectively? > > > ipHeaderPacketSection is currently defined as: > > This information element carries a series of octets from the start > of the IP header of a sampled packet. > > > mplsLabelStackSection is currently defined as: > > This information element carries the first n octets from the MPLS > label stack of a sampled packet. Whatever we choose, we should add a few words on this issue in the IE description. Thanks, Juergen > > Potential resolutions include: > > (1) We define the behaviour when the requested ipHeaderPacketSection > or mplsLabelStackSectionsection size is larger than the actual amount of > IP header / label stack data available. > > (1a) We define that only IP header / label stack octets are included. > > (1b) We define that the section contains a series of octets starting > from the beginning of the IP header / label stack and continuing > through the payload up to the limit of the available data. > > (2) We say nothing, and leave it as implimentation defined behaviour. > > > I believe that allowing these sections to continue into the payload per (1b) is potentially the most useful solution. > > It saves configuring the capture of seperate header and payload elements where capture of the header and first few octets of the payload are desired for packet identification and analysis. > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Tue Mar 07 09:04:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGcnt-0003iO-0m for psamp-archive@lists.ietf.org; Tue, 07 Mar 2006 09:04:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGcns-0003l6-Jy for psamp-archive@lists.ietf.org; Tue, 07 Mar 2006 09:04:45 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGcgf-0008qv-S4 for psamp-data@psg.com; Tue, 07 Mar 2006 13:57:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGcgf-0008qh-5R for psamp@ops.ietf.org; Tue, 07 Mar 2006 13:57:17 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 07 Mar 2006 05:57:17 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,171,1139212800"; d="scan'208"; a="23135333:sNHT23060988" Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k27DvDWc004114; Tue, 7 Mar 2006 08:57:15 -0500 (EST) Received: from [144.254.153.34] (dhcp-144-254-153-34.cisco.com [144.254.153.34]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA19586; Tue, 7 Mar 2006 13:57:12 GMT Message-ID: <440D9138.8050208@cisco.com> Date: Tue, 07 Mar 2006 13:57:12 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Falko Dressler CC: Paul Aitken , psamp Subject: Re: PSAMP: ipHeaderPacketSection and mplsLabelStackSection References: <440C206A.9050902@cisco.com> <440C7F92.7@informatik.uni-erlangen.de> In-Reply-To: <440C7F92.7@informatik.uni-erlangen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Status: O Hi all Falko Dressler wrote: > Paul, > > this is indeed a difficult issue. At the first look, I was about saying > "yes, 1b) is the best solution because it provides the highest > flexibility". Nevertheless, I fear that many applications will derrive > that allow to monitor packet payload but do not offer to analyze the > packet header, i.e. such monitors are just "remote-pcap-devices". This > is quite fine but makes most of PSAMP functionality (IEs) unnecessary. I agree that 1b is the obvious choice, for the following reasons: Firstly a PSAMP device offering the ipHeaderPacketSection will not have to understand how to parse the IP header(s) making the implementation easier and faster. Secondly, most people who are using this IE will want to capture all or part of the TCP/UDP header in order to retrieve the ports etc. and 1b will allow all this information to be gathered in a single neat packet section. On a related note I think we should clearly state that the ipPayloadPacketSection starts after the IPv6 extension headers to give consistency between its use for IPv4 and IPv6 packets. regards Andrew > 1a) is maybe too hard and 2) says "nothing" > > so may final answer is either 2) or we need to elaborate a 1c) > > Cheers, > Falko > > Paul Aitken wrote: >> Dear psampers, >> >> We have a new open issue in PSAMP-INFO: >> >> Should the ipHeaderPacketSection and mplsLabelStackSection also >> report payload contents if the specified section length is longer >> than the IP header or stack size, respectively? >> >> >> ipHeaderPacketSection is currently defined as: >> >> This information element carries a series of octets from the start >> of the IP header of a sampled packet. >> >> >> mplsLabelStackSection is currently defined as: >> >> This information element carries the first n octets from the MPLS >> label stack of a sampled packet. >> >> >> Potential resolutions include: >> >> (1) We define the behaviour when the requested ipHeaderPacketSection >> or mplsLabelStackSectionsection size is larger than the actual amount of >> IP header / label stack data available. >> >> (1a) We define that only IP header / label stack octets are included. >> >> (1b) We define that the section contains a series of octets starting >> from the beginning of the IP header / label stack and continuing >> through the payload up to the limit of the available data. >> >> (2) We say nothing, and leave it as implimentation defined behaviour. >> >> >> I believe that allowing these sections to continue into the payload per >> (1b) is potentially the most useful solution. >> >> It saves configuring the capture of seperate header and payload elements >> where capture of the header and first few octets of the payload are >> desired for packet identification and analysis. >> > -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Wed Mar 08 04:21:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGur5-000171-Lv for psamp-archive@lists.ietf.org; Wed, 08 Mar 2006 04:21:15 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGur5-0000rK-AR for psamp-archive@lists.ietf.org; Wed, 08 Mar 2006 04:21:15 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGul7-0009ZC-TJ for psamp-data@psg.com; Wed, 08 Mar 2006 09:15:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_30_40,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGul7-0009Yk-0H for psamp@ops.ietf.org; Wed, 08 Mar 2006 09:15:05 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k289F3c09021; Wed, 8 Mar 2006 10:15:03 +0100 (CET) Received: from [10.61.65.92] (ams-clip-vpn-dhcp348.cisco.com [10.61.65.92]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k289F2C05278; Wed, 8 Mar 2006 10:15:02 +0100 (CET) Message-ID: <440EA096.3020106@cisco.com> Date: Wed, 08 Mar 2006 10:15:02 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Thomas Dietz CC: Andrew Johnson , psamp Subject: Re: Proposal for PSAMP-PROTO section 6.5.2.6 References: <6D28EBC684A4D94096217AD2FE40087324A735@venus.office> In-Reply-To: <6D28EBC684A4D94096217AD2FE40087324A735@venus.office> Content-Type: multipart/alternative; boundary="------------000503090100080805000004" Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Status: O This is a multi-part message in MIME format. --------------000503090100080805000004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thomas, Corrected in the source document. Regards, Benoit. > Dear Andrew and all, > > I know I am too late to make it for this version but just one small comment > for wording. > > >> =================================================================== >> 6.5.2.6 Hash-Based Filtering >> >> In hash based selection a hash function is run on IPv4 traffic >> the following fields MUST be used as input to that hash function: >> - IP identification field >> - Flags field >> - Fragment offset >> - Source IP address >> - Destination IP address >> - A number of bytes from the IP payload. The number of bytes >> and starting offset MUST be configurable if possible. >> > > I would propose > > - A number of bytes from the IP payload. The number of bytes > and starting offset MUST be configurable if the hash function > supports it. > > BTW, Andrew, I very much appriciate your work on the hash functions. Now > this looks really consistent. > > Best Regards, > > Thomas > > --------------000503090100080805000004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thomas,

Corrected in the source document.

Regards, Benoit.
Dear Andrew and all,

I know I am too late to make it for this version but just one small comment
for wording.

  
===================================================================
6.5.2.6 Hash-Based Filtering

In hash based selection a hash function is run on IPv4 traffic
the following fields MUST be used as input to that hash function:
  - IP identification field
  - Flags field
  - Fragment offset
  - Source IP address
  - Destination IP address
  - A number of bytes from the IP payload.  The number of bytes
    and starting offset MUST be configurable if possible.
    

I would propose 

   - A number of bytes from the IP payload.  The number of bytes
     and starting offset MUST be configurable if the hash function
     supports it.

BTW, Andrew, I very much appriciate your work on the hash functions. Now
this looks really consistent.

Best Regards,

Thomas

--------------000503090100080805000004-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Wed Mar 08 15:04:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH4t8-0007fU-LO for psamp-archive@lists.ietf.org; Wed, 08 Mar 2006 15:04:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH4t6-0006ea-5G for psamp-archive@lists.ietf.org; Wed, 08 Mar 2006 15:04:02 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH4m3-000BJC-48 for psamp-data@psg.com; Wed, 08 Mar 2006 19:56:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.88.209.10] (helo=beniaminus.red.cert.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH4m1-000BIt-Vo for psamp@ops.ietf.org; Wed, 08 Mar 2006 19:56:42 +0000 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.18) with ESMTP id k28JuZ7W005313 for ; Wed, 8 Mar 2006 14:56:39 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k28Jt1MP005195 for ; Wed, 8 Mar 2006 14:55:01 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k28Jt0um005181; Wed, 08 Mar 2006 14:55:01 -0500 (EST) Received: from [128.237.245.4] (vpn-10-25-4-12.remote.cert.org [10.25.4.12]) by villemus.indigo.cert.org (8.12.11/8.12.11/2.55) with ESMTP id k28Jt0xf011693; Wed, 8 Mar 2006 14:55:00 -0500 In-Reply-To: <43984458.8070008@cisco.com> References: <43971E77.1010806@cisco.com> <43984458.8070008@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4-331735358" Message-Id: <691529BB-4B0B-4780-8EF5-753808541389@cert.org> Cc: ipfix-protocol@net.doit.wisc.edu, psamp Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: semantics of multiple identical Information Elements in a template Date: Wed, 8 Mar 2006 14:54:52 -0500 To: Benoit Claise X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.54 on 192.88.209.10 Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Status: O This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-4-331735358 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Benoit, Regarding multiple identical information elements, you proposed the following a couple of months ago: > In section 8 "Template Management", after the following paragraph... > > If a specific Information Element is required by a Template but is > not available in observed packets, the Exporting Process MAY choose > to export Flow Records without this Information Element in a Data > Record defined by a new Template. > > I would add: > > If an Information Element is required more than once in Template, > the different occurrences of this Information Element SHOULD follow > the logical order of their treatments by the Metering Process. For > example, if a selected packet goes through two hash functions, and > if the two hash values are sent within a single template, the first > occurrence of the hash value should belong to the first hash > function in the Metering Process. For example, when exporting the > two source IP addresses of an IPv4 in IPv4 packets, the first > sourceIPv4Address Information Element occurrence should be the IPv4 > address of the outer header, while the second occurrence should be > the inner header one. > > In section 9 "The Collecting Process's Side", at the very end, I > would add: > The Collector MUST support the use of Templates containing > multiple occurrences of > the similar Information Elements. > > Note: this text should solve the section 3.1.2.1 "Multiple IE of > same field type" open issue in draft-boschi-ipfix-implementation- > guidelines-00.txt Regards, Benoit. I'm probably a bit late to the party on this, but yes, this seems exactly the right thing to do for IPFIX version 0x000A. However, I think we should be more explicit about the semantics implied by this approach, and more restrictive on the applicability of multiple information elements in order to avoid any grey areas that might be used by implementors to overload multiple IE support in mutually unintelligible ways. Specifically, in investigating whether multiple information elements would be applicable for biflows -- exporting a forward direction counter in the first counter IE and a reverse direction counter in the second counter IE -- I realized you could argue that, because the reverse counters are related to the "second" direction seen at the Metering Process, you could use two IEs (say, octetTotalCount), have the first be the forward counter, the second be the reverse counter, and dispense with having to define any new information elements. However, what would the limits be on this approach? Say I wanted to export forward and reverse non-key header fields, say, tcpSequenceNumber. Would this conflict with a Collecting Process expecting to receive data about some sort of (admittedly ill-advised) TCP-in-TCP tunneling scheme? At this point I realized that overloading multiple IE support for the biflow case is probably not the right thing to do, at least with multiple IE support expressed as above. However, the language in the protocol document should make it explicit that only certain semantics are currently permitted with multiple identical information elements. (As an aside, note that as this example is written, it _does_ obviate the need for all but one of the mplsLabelStackEntry IEs, since the label stack is "unwrapped" by the Metering Process in a defined order.) Regards, Brian --Apple-Mail-4-331735358 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFEDzaR4/8LCZ4pwvYRAgaaAJ9dHDktGQzQwwiwCpg/uk6PDVWsSwCfROKn rUO0Rros0wtzuSdYQHxMg4M= =r0gX -----END PGP SIGNATURE----- --Apple-Mail-4-331735358-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Wed Mar 08 16:47:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5fD-0004GS-Ta for psamp-archive@lists.ietf.org; Wed, 08 Mar 2006 15:53:44 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH5f9-0000wG-OE for psamp-archive@lists.ietf.org; Wed, 08 Mar 2006 15:53:40 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH5br-000GJs-0g for psamp-data@psg.com; Wed, 08 Mar 2006 20:50:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH5bq-000GJK-7R for psamp@ops.ietf.org; Wed, 08 Mar 2006 20:50:14 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k28Ko3BX001311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 20:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FH5bf-0002rs-3I; Wed, 08 Mar 2006 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: psamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-psamp-info-04.txt Message-Id: Date: Wed, 08 Mar 2006 15:50:03 -0500 Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Packet Sampling Working Group of the IETF. Title : Information Model for Packet Sampling Exports Author(s) : T. Dietz, et al. Filename : draft-ietf-psamp-info-04.txt Pages : 36 Date : 2006-3-8 This memo defines an information model for the Packet Sampling (PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the sampling process. As the PSAMP protocol is based on the IPFIX protocol, this information model is an extension to the IPFIX information model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-psamp-info-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-psamp-info-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-psamp-info-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-8142028.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-psamp-info-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-psamp-info-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-8142028.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 09 06:59:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHJnn-0000Ji-3g for psamp-archive@lists.ietf.org; Thu, 09 Mar 2006 06:59:31 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHJnl-0007VX-R0 for psamp-archive@lists.ietf.org; Thu, 09 Mar 2006 06:59:31 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHJgF-0004MI-DT for psamp-data@psg.com; Thu, 09 Mar 2006 11:51:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHJgE-0004M2-B1 for psamp@ops.ietf.org; Thu, 09 Mar 2006 11:51:42 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k29Bpex20159 for ; Thu, 9 Mar 2006 12:51:40 +0100 (CET) Received: from [10.61.81.41] (ams-clip-vpn-dhcp4394.cisco.com [10.61.81.41]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k29BpdC10747 for ; Thu, 9 Mar 2006 12:51:39 +0100 (CET) Message-ID: <441016CB.3050506@cisco.com> Date: Thu, 09 Mar 2006 12:51:39 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: psamp Subject: New version of the protocol draft draft-ietf-psamp-protocol-04.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Status: RO Dear all, As promised during the last IETF meeting in Vancouver, a new version of the PSAMP protocol draft has been posted. All the outstanding issues have been resolved. Please review it carefully. Note: the draft has been submitted before the deadline, so it should appear pretty soon. Regards, Benoit. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Sun Mar 12 18:23:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIZu8-0003cq-3z for psamp-archive@lists.ietf.org; Sun, 12 Mar 2006 18:23:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIZu6-0006sX-Q4 for psamp-archive@lists.ietf.org; Sun, 12 Mar 2006 18:23:16 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FIZnc-000F0c-6m for psamp-data@psg.com; Sun, 12 Mar 2006 23:16:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FIZna-000F0E-Rp for psamp@ops.ietf.org; Sun, 12 Mar 2006 23:16:31 +0000 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B26F81BAC99 for ; Mon, 13 Mar 2006 00:16:27 +0100 (CET) Date: Mon, 13 Mar 2006 00:08:46 +0100 From: Juergen Quittek To: psamp@ops.ietf.org Subject: draft meeting agenda for Dallas Message-ID: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Dear all, Below please find the draft agenda for our session in Dallas. Please send me a message if you have suggestions for changes. The session will be after the IPFIX session and in the same room as IPFIX. Since we might have remote participants, it would be great if the presenters sent me their slides in advance of the session for uploading them. It looks like a rather short session. Still it is necessary to take minutes. Is there a volunteer? See you at the session, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de Packet Sampling WG (psamp) IETF #65 Wednesday March 22 at 1510-1610 ================================= Chair: Juergen Quittek AGENDA: 1) Agenda bashing, WG Status, PSAMP documents status ( 5 min) 2) PSAMP protocol (Benoit Claise) (15 min) - draft-ietf-psamp-protocol-03.txt 3) PSAMP information model (Paul Aitken) (15 min) - draft-ietf-psamp-info-04.txt 4) PSAMP MIB (Juergen Quittek) (15 min) - draft-ietf-psamp-mib-05.txt 5) Wrap up ( 5 min) - review of action points INTERNET DRAFTS: Packet Sampling (PSAMP) Protocol Specifications http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-03.txt Information Model for Packet Sampling Exports http://www.ietf.org/internet-drafts/draft-ietf-psamp-info-04.txt Definitions of Managed Objects for Packet Sampling http://www.ietf.org/internet-drafts/draft-ietf-psamp-mib-05.txt RELATED DRAFTS: IPFIX Protocol Specification http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-19.txt Information Model for IP Flow Information Export http://www.ietf.org/internet-drafts/draft-ietf-ipfix-info-11.txt Managed Objects for IPFIX concentrator http://www.ietf.org/internet-drafts/draft-kobayashi-ipfix-concentrator-mib-01.txt -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Tue Mar 21 19:26:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrB6-0004lB-GT for psamp-archive@lists.ietf.org; Tue, 21 Mar 2006 19:26:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLrB4-0003ov-Ux for psamp-archive@lists.ietf.org; Tue, 21 Mar 2006 19:26:20 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLr3o-0001aZ-7e for psamp-data@psg.com; Wed, 22 Mar 2006 00:18:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [163.221.82.75] (helo=mailrelay.naist.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLr3n-0001aJ-2T for psamp@ops.ietf.org; Wed, 22 Mar 2006 00:18:47 +0000 Received: from mailpost.naist.jp (mailscan.naist.jp [163.221.82.70]) by mailrelay.naist.jp (Postfix) with ESMTP id BBC4F1C51; Wed, 22 Mar 2006 09:18:45 +0900 (JST) Received: from [127.0.0.1] (sh.naist.jp [163.221.10.10]) by mailpost.naist.jp (Postfix) with ESMTP id 0F42B1C31; Wed, 22 Mar 2006 09:18:44 +0900 (JST) Message-ID: <442097D5.1000801@is.aist-nara.ac.jp> Date: Wed, 22 Mar 2006 09:18:29 +0900 From: Youki Kadobayashi User-Agent: Thunderbird 1.5 (X11/20060322) MIME-Version: 1.0 To: Benoit Claise CC: psamp Subject: Re: New version of the protocol draft draft-ietf-psamp-protocol-04.txt References: <441016CB.3050506@cisco.com> In-Reply-To: <441016CB.3050506@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hello, I still cannot access the protocol-04 draft... I searched across datatracker, IETF tools page and ftp.ietf.org, but none of them had the latest one. Would you please send it to this list? Thanks, Youki Kadobayashi WIDE project Benoit Claise wrote: > Dear all, > > As promised during the last IETF meeting in Vancouver, a new version of > the PSAMP protocol draft has been posted. > All the outstanding issues have been resolved. > Please review it carefully. > > Note: the draft has been submitted before the deadline, so it should > appear pretty soon. > > Regards, Benoit. > > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Tue Mar 21 23:32:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLv1i-0006eb-UL for psamp-archive@lists.ietf.org; Tue, 21 Mar 2006 23:32:54 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLv1h-0003pu-Bt for psamp-archive@lists.ietf.org; Tue, 21 Mar 2006 23:32:54 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLuva-000Gve-Kh for psamp-data@psg.com; Wed, 22 Mar 2006 04:26:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_40_50,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLuvZ-000GvO-Jf for psamp@ops.ietf.org; Wed, 22 Mar 2006 04:26:33 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2M4QRt05893; Wed, 22 Mar 2006 05:26:27 +0100 (CET) Received: from [10.21.99.165] (sjc-vpn1-933.cisco.com [10.21.99.165]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2M4QLC27435; Wed, 22 Mar 2006 05:26:24 +0100 (CET) Message-ID: <4420D1ED.40405@cisco.com> Date: Tue, 21 Mar 2006 22:26:21 -0600 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Youki Kadobayashi CC: psamp Subject: Re: New version of the protocol draft draft-ietf-psamp-protocol-04.txt References: <441016CB.3050506@cisco.com> <442097D5.1000801@is.aist-nara.ac.jp> In-Reply-To: <442097D5.1000801@is.aist-nara.ac.jp> Content-Type: multipart/alternative; boundary="------------050908020902090401050300" Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb This is a multi-part message in MIME format. --------------050908020902090401050300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Youki, Thanks for pointing that out. We posted the draft on time, then received: The Secretariat CANNOT process your Internet-Draft submission due to following reason(s): * All Internet-Drafts must include the following statement: Copyright (C) The Internet Society (2006). We reposted... However, the draft doesn't appear! Anyway, in the mean time, please look at: http://www.employees.org/~bclaise/public_files/draft-ietf-psamp-protocol-04.txt Sorry for the inconvenience. Regards, Benoit. > Hello, > > I still cannot access the protocol-04 draft... > I searched across datatracker, IETF tools page and > ftp.ietf.org, but none of them had the latest one. > > Would you please send it to this list? > > Thanks, > Youki Kadobayashi > WIDE project > > Benoit Claise wrote: >> Dear all, >> >> As promised during the last IETF meeting in Vancouver, a new version >> of the PSAMP protocol draft has been posted. >> All the outstanding issues have been resolved. >> Please review it carefully. >> >> Note: the draft has been submitted before the deadline, so it should >> appear pretty soon. >> >> Regards, Benoit. >> >> >> -- >> to unsubscribe send a message to psamp-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> --------------050908020902090401050300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Youki,

Thanks for pointing that out.
We posted the draft on time, then received:
The Secretariat CANNOT process your Internet-Draft submission due to
following reason(s):  * All Internet-Drafts must include the following
statement:

Copyright (C) The Internet Society (2006).
We reposted... However, the draft doesn't appear!

Anyway, in the mean time, please look at: http://www.employees.org/~bclaise/public_files/draft-ietf-psamp-protocol-04.txt

Sorry for the inconvenience.
Regards, Benoit.
Hello,

I still cannot access the protocol-04 draft...
I searched across datatracker, IETF tools page and
ftp.ietf.org, but none of them had the latest one.

Would you please send it to this list?

Thanks,
    Youki Kadobayashi
    WIDE project

Benoit Claise wrote:
Dear all,

As promised during the last IETF meeting in Vancouver, a new version of the PSAMP protocol draft has been posted.
All the outstanding issues have been resolved.
Please review it carefully.

Note: the draft has been submitted before the deadline, so it should appear pretty soon.

Regards, Benoit.


-- 
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>


--------------050908020902090401050300-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Wed Mar 22 17:00:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMBNp-0006Ec-DO for psamp-archive@lists.ietf.org; Wed, 22 Mar 2006 17:00:49 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMBNn-0004aJ-TV for psamp-archive@lists.ietf.org; Wed, 22 Mar 2006 17:00:49 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMBGi-0005sh-UM for psamp-data@psg.com; Wed, 22 Mar 2006 21:53:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [163.221.82.75] (helo=mailrelay.naist.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMBGd-0005sJ-I0 for psamp@ops.ietf.org; Wed, 22 Mar 2006 21:53:28 +0000 Received: from mailpost.naist.jp (mailscan.naist.jp [163.221.82.70]) by mailrelay.naist.jp (Postfix) with ESMTP id 042431E4F; Thu, 23 Mar 2006 06:53:19 +0900 (JST) Received: from [127.0.0.1] (sh.naist.jp [163.221.10.10]) by mailpost.naist.jp (Postfix) with ESMTP id 7C5661B0C; Thu, 23 Mar 2006 06:53:17 +0900 (JST) Message-ID: <4421C74E.4020407@is.aist-nara.ac.jp> Date: Thu, 23 Mar 2006 06:53:18 +0900 From: Youki Kadobayashi User-Agent: Thunderbird 1.5 (X11/20060322) MIME-Version: 1.0 To: Andrew Johnson CC: psamp Subject: Re: Proposal for PSAMP-PROTO section 6.5.2.6 References: <4408A761.5070707@cisco.com> In-Reply-To: <4408A761.5070707@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b This is a minor point.. Andrew Johnson wrote: > NOTE: If more than one selection or output range needs to be sent > then the minimum and maximum elements may be repeated as needed. This part talks about both output ranges and selection ranges. > These MUST make one or more non-overlapping ranges. Perhaps you are talking about selection ranges here, since multiple digest hash functions can take overlapping output ranges... > The elements > SHOULD be sent as pairs of minimum and maximum in ascending order, > however if they are sent out of order then there will only be one > way to interpret the ranges to produce a non-overlapping range and > the Collecting Process MUST be prepared to accept and decode this. > > The following algorithm specific Information Element MAY be sent, > but is optional for security considerations: > hashInitialiserValue - The initialiser value to the hash function. > > Example of a hash based filter Selector, whose configuration is: > Hash Function = BOB > Hash IP Payload Offset = 0 > Hash IP Payload Size = 16 > Hash Initialiser Value = 0x9A3F9A3F > Hash Output Range = 0 to 0xFFFFFFFF > Hash Selected Range = 100 to 200 and 400 to 500 Thanks, Youki Kadobayashi WIDE Project -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 23 01:37:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMJS8-0007o6-7M for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 01:37:48 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMJS6-0001rC-TA for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 01:37:48 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMJNC-000Dea-3A for psamp-data@psg.com; Thu, 23 Mar 2006 06:32:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMJNB-000DeN-9x for psamp@ops.ietf.org; Thu, 23 Mar 2006 06:32:41 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 23 Mar 2006 07:32:40 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2N6Wc36002430; Thu, 23 Mar 2006 07:32:39 +0100 (MET) Received: from [10.89.16.65] (rcdn-vpn-cluster-1-65.cisco.com [10.89.16.65]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id GAA27488; Thu, 23 Mar 2006 06:32:37 GMT Message-ID: <44224104.4050102@cisco.com> Date: Thu, 23 Mar 2006 06:32:36 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Youki Kadobayashi CC: psamp Subject: Re: Proposal for PSAMP-PROTO section 6.5.2.6 References: <4408A761.5070707@cisco.com> <4421C74E.4020407@is.aist-nara.ac.jp> In-Reply-To: <4421C74E.4020407@is.aist-nara.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Youki Kadobayashi wrote: > This is a minor point.. > > Andrew Johnson wrote: >> NOTE: If more than one selection or output range needs to be sent >> then the minimum and maximum elements may be repeated as needed. > > This part talks about both output ranges and selection ranges. > >> These MUST make one or more non-overlapping ranges. > > Perhaps you are talking about selection ranges here, > since multiple digest hash functions can take overlapping > output ranges... No, I am talking about either selection or output range. This is for communicating the ranged of a single digest hash function, so overlapping ranges do not make sense. Furthermore, an overlapping range could just be communicated by sending the larger range, e.g. 1 to 10 plus 5 to 15 => 1 to 15. Although it is recommended that the range I.E.s are sent in a sensible order this is not mandated. As such, the min and max values could be sent in any order (and a collector MUST cope with this). This works OK because there is only one way to interpret the list as long as there can be no overlaps. regards Andrew > > The elements >> SHOULD be sent as pairs of minimum and maximum in ascending order, >> however if they are sent out of order then there will only be one >> way to interpret the ranges to produce a non-overlapping range and >> the Collecting Process MUST be prepared to accept and decode this. >> >> The following algorithm specific Information Element MAY be sent, >> but is optional for security considerations: >> hashInitialiserValue - The initialiser value to the hash function. >> >> Example of a hash based filter Selector, whose configuration is: >> Hash Function = BOB >> Hash IP Payload Offset = 0 >> Hash IP Payload Size = 16 >> Hash Initialiser Value = 0x9A3F9A3F >> Hash Output Range = 0 to 0xFFFFFFFF >> Hash Selected Range = 100 to 200 and 400 to 500 > > Thanks, > Youki Kadobayashi > WIDE Project > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 23 02:11:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMJz9-0007ce-2R for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 02:11:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMJz7-0003KH-G1 for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 02:11:55 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMJvd-000FOE-23 for psamp-data@psg.com; Thu, 23 Mar 2006 07:08:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [163.221.82.75] (helo=mailrelay.naist.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMJvb-000FO0-Be for psamp@ops.ietf.org; Thu, 23 Mar 2006 07:08:15 +0000 Received: from mailpost.naist.jp (mailscan.naist.jp [163.221.82.70]) by mailrelay.naist.jp (Postfix) with ESMTP id DE6C71E83 for ; Thu, 23 Mar 2006 16:08:10 +0900 (JST) Received: from [127.0.0.1] (sh.naist.jp [163.221.10.10]) by mailpost.naist.jp (Postfix) with ESMTP id 450131E7A for ; Thu, 23 Mar 2006 16:08:10 +0900 (JST) Message-ID: <4422495B.3070704@is.aist-nara.ac.jp> Date: Thu, 23 Mar 2006 16:08:11 +0900 From: Youki Kadobayashi User-Agent: Thunderbird 1.5 (X11/20060322) MIME-Version: 1.0 To: psamp@ops.ietf.org Subject: Re: Proposal for PSAMP-PROTO section 6.5.2.6 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Dear PSAMP folks, I am interested in the network attack tracing scenario of trajectory sampling, as documented in the Section 6.2.1.2 of draft-ietf-psamp-sample-tech-07. Here's my comments to draft-ietf-psamp-protocol-04 regarding hash-based filtering: In section 6.5.2.6 it doesn't mention IPv6. I assume you will refer readers to (or copy texts from) the Section 6.2.3.3 of draft-ietf-psamp-sample-tech-07. If this is the case, I find potential weakness here. Attacker can evade trajectory sampling if 1) he can arbitarily choose byte number 10,11,14,15,16 of IPv6 src/dest addresses, and 2) hash selection range S is known to the attacker. 1) is feasible since it is EUI-64, and 2) is feasible if S remains identical Internet-wide, for a long period of time. Regarding the BOB hash function: I wonder if someone have evaluated the cryptographic soundness (i.e., one-wayness and collision resistance) of BOB. If so, it would be useful to point at the cryptanalysis document of BOB. If not, I can volunteer to ask nearby cryptographers to look at it. If BOB is found not to be collision resistant, attacker may come up with very fast algorithm to manipulate IP payload (or IP-ID field) so that every attack packet evades detection. N.B. I am aware of the folllowing paper, where the authors conducted statistical (that is, not cryptoanalytic) testing of IPSX and BOB. http://public.research.att.com/~duffield/papers/31-085A.pdf Maybe this is a reccuring topic though. P.S. Kudos to all of your standardization efforts. -- Youki Kadobayashi WIDE Project -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 23 18:45:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMZUv-0004Ns-Nv for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 18:45:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMZUu-0004jg-Eb for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 18:45:45 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMZPi-000PNP-DI for psamp-data@psg.com; Thu, 23 Mar 2006 23:40:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMZPg-000PMR-Gv for psamp@ops.ietf.org; Thu, 23 Mar 2006 23:40:20 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2NNeJt19365 for ; Fri, 24 Mar 2006 00:40:19 +0100 (CET) Received: from [10.82.224.34] (rtp-vpn1-34.cisco.com [10.82.224.34]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2NNeGC09895 for ; Fri, 24 Mar 2006 00:40:17 +0100 (CET) Message-ID: <442331E0.4030904@cisco.com> Date: Thu, 23 Mar 2006 17:40:16 -0600 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: psamp Subject: encrypted packets Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Dear all, The current text says "Since encryption alters the meaning of encrypted fields, when the Property Match Filtering classification is based on the encrypted field(s) in the packet, it MUST be able to recognize that the field(s) are not available and MUST NOT select those packets." For clarification purposes (even if the intend was there already) I would like to change it to: "Since encryption alters the meaning of encrypted fields, when the Property Match Filtering classification is based on the encrypted field(s) in the packet, it MUST be able to recognize that the field(s) are not available and MUST NOT select those packets unless specifically directed by the Information Element description." Regards, Benoit. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 23 19:32:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMaDg-0005XD-E0 for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 19:32:00 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMaDe-00029Y-Ly for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 19:32:00 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMa9m-000955-AS for psamp-data@psg.com; Fri, 24 Mar 2006 00:27:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_30_40,HTML_MESSAGE,HTML_TITLE_EMPTY,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMa9j-00094g-NG for psamp@ops.ietf.org; Fri, 24 Mar 2006 00:27:56 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2O0Rs122173; Fri, 24 Mar 2006 01:27:54 +0100 (CET) Received: from [10.82.224.34] (rtp-vpn1-34.cisco.com [10.82.224.34]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2O0RqC09807; Fri, 24 Mar 2006 01:27:52 +0100 (CET) Message-ID: <44233D08.5080108@cisco.com> Date: Thu, 23 Mar 2006 18:27:52 -0600 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ipfix , psamp Subject: Source ID -> Observation Domain Id? Content-Type: multipart/alternative; boundary="------------020101030407050604040503" Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. --------------020101030407050604040503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, During his review, Bert was confused by the sourceId being the unique Id for the observation domain - [IPFIX-ARCH] sect 5.4 last line s/Source ID/Domain ID/ ?? Or should the section title be somthing about "Source" ?? I am getting a bit confused about DOmain and Source ID I guess? Protocol doc does indeed speak about SOurce ID. I agree that this confusing, and should be changed. However, this must be changed in ALL IPFIX and PSAMP documents. Information model: sourceId -> observationDomainId Protocol: Source ID -> Observation Domain ID Any objections before starting to change the documents? Regards, Benoit. --------------020101030407050604040503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

During his review, Bert was confused by the sourceId being the unique Id for the observation domain
- [IPFIX-ARCH] sect 5.4 last line
  s/Source ID/Domain ID/ ??
  Or should the section title be somthing about "Source" ??
  I am getting a bit confused about DOmain and Source ID I guess?
  Protocol doc does indeed speak about SOurce ID.
I agree that this confusing, and should be changed. However, this must be changed in ALL IPFIX and PSAMP documents.
Information model: sourceId -> observationDomainId
Protocol: Source ID -> Observation Domain ID

Any objections before starting to change the documents?

Regards, Benoit.


--------------020101030407050604040503-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 23 20:07:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMam0-0004ww-Ir for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 20:07:28 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMZog-0008Uz-03 for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 19:06:10 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FMZmD-0007p1-47 for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 19:03:38 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMZjV-0003d7-3U for psamp-data@psg.com; Fri, 24 Mar 2006 00:00:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMZjU-0003a5-E2 for psamp@ops.ietf.org; Fri, 24 Mar 2006 00:00:48 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2O00bR20570; Fri, 24 Mar 2006 01:00:37 +0100 (CET) Received: from [10.82.224.34] (rtp-vpn1-34.cisco.com [10.82.224.34]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2O00ZC24119; Fri, 24 Mar 2006 01:00:35 +0100 (CET) Message-ID: <442336A2.8020902@cisco.com> Date: Thu, 23 Mar 2006 18:00:34 -0600 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Thomas Dietz CC: psamp Subject: 2 small corrections for the PSAMP MIB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi Thomas, 1. Replace psampTemplateTable by psampTemplateRecordTable psampTemplateRecordTable OBJECT-TYPE SYNTAX SEQUENCE OF PsampTemplateRecordEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists templates used by the exporter." ::= { psampReporting 3 } psampTemplateRecordEntry OBJECT-TYPE SYNTAX PsampTemplateRecordEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the psampTemplateTable." <----------- INDEX { psampTemplateRecordId, psampTemplateRecordIndex } ::= { psampTemplateRecordTable 1 } 2. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. There are no read-write :) Regards, Benoit. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 23 20:07:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMam7-000537-0E for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 20:07:35 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMam5-0003oW-NK for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 20:07:34 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMaiD-000EM2-M8 for psamp-data@psg.com; Fri, 24 Mar 2006 01:03:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMaiD-000ELq-2Q for psamp@ops.ietf.org; Fri, 24 Mar 2006 01:03:33 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 24 Mar 2006 02:03:32 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2O13V36028026; Fri, 24 Mar 2006 02:03:31 +0100 (MET) Received: from [10.89.20.15] (rcdn-vpn-cluster-2-15.cisco.com [10.89.20.15]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id BAA13902; Fri, 24 Mar 2006 01:03:29 GMT Message-ID: <4423455F.7040007@cisco.com> Date: Fri, 24 Mar 2006 01:03:27 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.10) Gecko/20050811 Fedora/1.7.10-1.2.1.legacy X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Benoit Claise CC: ipfix , psamp Subject: Re: [ipfix] Source ID -> Observation Domain Id? References: <44233D08.5080108@cisco.com> In-Reply-To: <44233D08.5080108@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Benoit, > Any objections before starting to change the documents? No objection. I agree, because the definition is: sourceId An identifier of an Observation Domain So obviously it's "Observation Domain ID". Unfortunately it requires a small change in several places. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 23 20:12:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMar9-0001gi-CH for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 20:12:47 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMZom-0008Uz-59 for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 19:06:16 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FMZh2-0007lC-MU for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 18:58:22 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMZXI-0000nP-Kg for psamp-data@psg.com; Thu, 23 Mar 2006 23:48:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMZXH-0000nE-U2 for psamp@ops.ietf.org; Thu, 23 Mar 2006 23:48:12 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2NNmA719841 for ; Fri, 24 Mar 2006 00:48:10 +0100 (CET) Received: from [10.82.224.34] (rtp-vpn1-34.cisco.com [10.82.224.34]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2NNm9C13360 for ; Fri, 24 Mar 2006 00:48:09 +0100 (CET) Message-ID: <442333B9.7020105@cisco.com> Date: Thu, 23 Mar 2006 17:48:09 -0600 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: psamp Subject: PSAMP-MIB reference in the PSAMP protocol draft Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Dear all, As discussed during the PSAMP meeting, the [PSAMP-MIB] reference has been moved from the normative reference section to the informative reference section. Regards, Benoit -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 23 20:39:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMbHD-0001R9-49 for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 20:39:43 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMa7A-0001eZ-8Q for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 19:25:16 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FMZsG-0008Ri-0b for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 19:09:53 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMZnb-0004dn-Os for psamp-data@psg.com; Fri, 24 Mar 2006 00:05:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMZna-0004cg-SS for psamp@ops.ietf.org; Fri, 24 Mar 2006 00:05:03 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 24 Mar 2006 01:05:02 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2O05136019590 for ; Fri, 24 Mar 2006 01:05:01 +0100 (MET) Received: from [10.89.16.19] (rcdn-vpn-cluster-1-19.cisco.com [10.89.16.19]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA08852; Fri, 24 Mar 2006 00:05:00 GMT Message-ID: <442337AB.1080706@cisco.com> Date: Fri, 24 Mar 2006 00:04:59 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Johnson CC: psamp Subject: Re: Proposal for PSAMP-PROTO section 6.5.2.6 References: <4408A761.5070707@cisco.com> In-Reply-To: <4408A761.5070707@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Hi all There is a contradiction in the proposed text that I would like to correct. Andrew Johnson wrote: [SNIP] > 6.5.2.6 Hash-Based Filtering > [SNIP] > For the bytes taken from the IP payload, IPSX has a fixed offset > of 0 bytes and a fixed size of 8 bytes. The number and offset of > payload bytes in the BOB function MUST be configurable. If any > of the configured set of bytes from the IP payload are unavailable > then 0 MUST be used, which may result in a different value than > if the hash function is run on a subset of the input. Here, for a hash function with a variable length input, it says that you must pass in 0 for the missing bytes. This disagrees with the text below and I would like to simply remove the last sentence. > The minimum configuration ranges MUST be as follows: > Number of bytes: from 8 to 32 > Offset: from 0 to 64 > > If the selected payload bytes are not available and the hash function > can take a variable sized input then the hash function MUST be run > with the information which is available and a shorter size. Passing > 0 as a substitute for missing payload bytes is only acceptable if > the hash function takes a fixed size as is the case with IPSX. The above text is quite clear, and contrary to the previous original paragraph. regards Andrew -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Mar 23 21:36:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMcAX-0001k3-RQ for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 21:36:53 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMcAX-0007KE-Ep for psamp-archive@lists.ietf.org; Thu, 23 Mar 2006 21:36:53 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMc74-000MWU-Qi for psamp-data@psg.com; Fri, 24 Mar 2006 02:33:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMc74-000MWH-7L for psamp@ops.ietf.org; Fri, 24 Mar 2006 02:33:18 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 24 Mar 2006 03:33:17 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2O2XH36007848 for ; Fri, 24 Mar 2006 03:33:17 +0100 (MET) Received: from [10.89.20.15] (rcdn-vpn-cluster-2-15.cisco.com [10.89.20.15]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id CAA20810 for ; Fri, 24 Mar 2006 02:33:13 GMT Message-ID: <44235A65.7050301@cisco.com> Date: Fri, 24 Mar 2006 02:33:09 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.10) Gecko/20050811 Fedora/1.7.10-1.2.1.legacy X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: psamp Subject: PSAMP: ipHeaderPacketSection and mplsLabelStackSection References: <440C206A.9050902@cisco.com> In-Reply-To: <440C206A.9050902@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Dear psampers, As I presented in yesterday's PSAMP WG meeting, PSAMP-INFO has one open issue which must be solved: > Should the ipHeaderPacketSection and mplsLabelStackSection also > report payload contents if the specified section length is longer > than the IP header or stack size, respectively? Actually, it also applies to the dataLinkFrameSection which "carries the first n octets from the data link frame of a sampled packet." - but if sufficient length is specified, does it continue on to also report the L3 header and even the L3 payload? Sometimes capture of some octets of the payload information is very useful - eg, to capture the UDP/TCP port numbers, or for protocol analysis. But in yesterday's WG meeting, it was pointed out that there may be scenarios where capture of payload information is undesireable and maybe even illegal. So clearly we need to find a way to control access to the payload information. So below, I present two possible solutions for discussion. Others may be possible too. Please express your opinions immediately so we can resolve and close this issue. Thanks. (1) Use multiple information elements, eg: ipPacketSection - IP header, continuing into the payload ipHeaderPacketSection - IP header only ipPayloadPacketSection - IP payload only dataLinkFrameSection - data link frame, continuing into L3 dataLinkHeaderFrameSection - data link header only mplsPacketSection - MPLS label stack, cont into payload mplsLabelStackSection - MPLS label stack only mplsPayloadPacketSection - MPLS payload only - export of the relevant IEs can be ommitted when access to payload information is undesireable. - how can you capture port or protocol information without knowing some payload bytes? (2) Use the existing information elements, with an application specific configuration knob controlling whether they continue into the next section or not: ipHeaderPacketSection - IP header, optionally cont into payload ipPayloadPacketSection - IP payload only dataLinkFrameSection - data link frame, continuing into L3 mplsLabelStackSection - MPLS label stack, opt cont into payload mplsPayloadPacketSection - MPLS payload only - how will the exporter report whether or not the configuration knob is set? With another IE? Regarding the length of packet sections, the common rule (regardless of the IE definition) is that the exact amount of requested octets must be exported as was defined in the template (ie, no padding short sections with zero), else a new template must be sent either with the available length or using variable length encoding. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Fri Mar 24 02:55:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMh8c-0006hl-HX for psamp-archive@lists.ietf.org; Fri, 24 Mar 2006 02:55:14 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMh8b-0002RF-4r for psamp-archive@lists.ietf.org; Fri, 24 Mar 2006 02:55:14 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMh1v-000Ic7-Jm for psamp-data@psg.com; Fri, 24 Mar 2006 07:48:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.88.209.10] (helo=beniaminus.red.cert.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMh1u-000Ibt-J5 for psamp@ops.ietf.org; Fri, 24 Mar 2006 07:48:18 +0000 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.19) with ESMTP id k2O7mGMV012469 for ; Fri, 24 Mar 2006 02:48:16 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k2O7kjWK012420 for ; Fri, 24 Mar 2006 02:46:45 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k2O7kjGI012416; Fri, 24 Mar 2006 02:46:45 -0500 (EST) Received: from [204.96.112.212] (vpn-10-25-4-12.remote.cert.org [10.25.4.12]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.56) with ESMTP id k2O7khsj002965; Fri, 24 Mar 2006 02:46:44 -0500 In-Reply-To: <4423455F.7040007@cisco.com> References: <44233D08.5080108@cisco.com> <4423455F.7040007@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--477040694" Message-Id: Cc: ipfix , psamp , Paul Aitken Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix] Source ID -> Observation Domain Id? Date: Fri, 24 Mar 2006 01:46:40 -0600 To: Benoit Claise X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.3) Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1--477040694 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Benoit, Also agreed on this point - all other objects with identifiers have identifier names of the form Id; it's worth changing this for consistency. Note this will also require a change to the name of the sourceId IE in the information model. Regards, Brian On Mar 23, 2006, at 7:03 PM, Paul Aitken wrote: > Benoit, > >> Any objections before starting to change the documents? > > No objection. I agree, because the definition is: > > sourceId An identifier of an Observation Domain > > So obviously it's "Observation Domain ID". > > Unfortunately it requires a small change in several places. > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: --Apple-Mail-1--477040694 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFEI6Pj4/8LCZ4pwvYRArgMAKDsf3EC+PFLFXMCKbnW9LS5e+LvxgCfR9my XvtZwvCQglZtNA7g9WRQtAA= =xQ8d -----END PGP SIGNATURE----- --Apple-Mail-1--477040694-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Fri Mar 24 03:45:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMhvI-00050y-5v for psamp-archive@lists.ietf.org; Fri, 24 Mar 2006 03:45:32 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMhvG-00045I-O9 for psamp-archive@lists.ietf.org; Fri, 24 Mar 2006 03:45:32 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMhpn-000MJs-S0 for psamp-data@psg.com; Fri, 24 Mar 2006 08:39:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMhpm-000MJd-N8 for psamp@ops.ietf.org; Fri, 24 Mar 2006 08:39:51 +0000 Received: from n-dietz.office (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id BFEB81BAC4D; Fri, 24 Mar 2006 09:38:27 +0100 (CET) From: Thomas Dietz Organization: Network Laboratories, NEC Europe Ltd. To: "Benoit Claise" Subject: Re: Source ID -> Observation Domain Id? Date: Fri, 24 Mar 2006 09:39:12 +0100 User-Agent: KMail/1.9.1 Cc: "ipfix" , "psamp" References: <44233D08.5080108@cisco.com> In-Reply-To: <44233D08.5080108@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6535597.7Y5OsT002L"; protocol="application/pkcs7-signature"; micalg=sha1 Content-Transfer-Encoding: 7bit Message-Id: <200603240939.16597.Thomas.Dietz@netlab.nec.de> Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 --nextPart6535597.7Y5OsT002L Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Benoit, I also agree. It makes things even clearer. Regards, Thomas Am Freitag, 24. M=E4rz 2006 01:27 schrieb Benoit Claise: > Dear all, > > During his review, Bert was confused by the sourceId being the unique Id > for the observation domain > > > - [IPFIX-ARCH] sect 5.4 last line > s/Source ID/Domain ID/ ?? > Or should the section title be somthing about "Source" ?? > I am getting a bit confused about DOmain and Source ID I guess? > Protocol doc does indeed speak about SOurce ID. > > I agree that this confusing, and should be changed. However, this must be > changed in ALL IPFIX and PSAMP documents. Information model: sourceId -> > observationDomainId > Protocol: Source ID -> Observation Domain ID > > Any objections before starting to change the documents? > > Regards, Benoit. --nextPart6535597.7Y5OsT002L Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/DCCAvgw ggJhoAMCAQICAw9RdTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE3MDkwOTE3WhcNMDYwODE3MDkwOTE3WjBjMQ4wDAYDVQQE EwVEaWV0ejEPMA0GA1UEKhMGVGhvbWFzMRUwEwYDVQQDEwxUaG9tYXMgRGlldHoxKTAnBgkqhkiG 9w0BCQEWGlRob21hcy5EaWV0ekBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA4nhGGaCtAFl95e262kXtWs33/Co8wu3qnQqpmgEkgADwZV1ZGoNphSGYXWmdAO4S C+M2HFzsJ0FJ3eG4KV0IaI+kvuKQdfHbqKSV8OfUTIhwrzjwZVJBvUYagIBF8ksvo37XR8YPg5Hw j/zPFAbRhbGg/mrKj/Za7/P9ouv1onhwigQtOG5qcr3+MHE+I6lmkZM7FrzzNwYSJ0Jq52Q8BUEg LWdhLHnXDFy1d+tCZdtdEK3bKga13+Udc5jC0Yvg8hmY+nrxhUPKcYR038q404eJplla2qtpEC3O IoGTKLYRtcxAtoMQ1VG32AylLKJ59/GQDqXOjr9iCI4qyyj7zwIDAQABozcwNTAlBgNVHREEHjAc gRpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAE2PK+6rLfxJ5o+m3N28Uj0XGeArIfvLtnzZQDvuzz2jaThTjJ7PqULqOzjPsCGT/UsT2Ayo 2ksMnxzcVVIK4iJJlaJ2qJRrORakM2CfmkaxFkrJweezRfMPSp7tlW8QnZ/Johw746jZj5bcnOsV 0gxcXkhfMr9OcjEVsJ6+2eg6MYICGjCCAhYCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECAw9RdTAHBgUrDgMCGqCBizAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMjQwODM5MTJaMCMGCSqGSIb3DQEJBDEWBBSapTZPpTOd gOBCsLAIvm8zJzC3vDAsBgkqhkiG9w0BCQ8xHzAdMA0GCWCGSAFlAwQBAgUAMAwGCCqGSIb3DQMH BQAwCwYJKoZIhvcNAQEBBIIBAGOJkTI4lkVFKbe+DH++3QaBhTSVgZxJUf0EqqxCezXMJZkh4XXk GfmCI3tF+bbQYqYg3CzDYus2AkoVbUpwWC7AyH30D1H2FxRY8PvLgsAjJLzCFp33dsjQ/+7iQt3U WDeIxvVumHZy/Q0imUvzXNpLUURtJdN2W+5cLSJ8TxSac6tUp3er8HrceWvxItPIAt8Fxb/XPJ/r hcKV8Qigq4hmlNWNXOc2vaeIGRGDv/r4fdp411ap4hMc4rH6LZ/wIfPrRVITy9gCQNUTcY7QndwH 5DutKT1ckUPPQGU/mUVAtkMdE6LgrT6jrXRcWz3u+IubwqxD61eSfpKHP3Naw1sAAAAAAAA= --nextPart6535597.7Y5OsT002L-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Fri Mar 24 03:49:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMhzP-0000xp-DQ for psamp-archive@lists.ietf.org; Fri, 24 Mar 2006 03:49:47 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMhzK-0004F3-Vm for psamp-archive@lists.ietf.org; Fri, 24 Mar 2006 03:49:47 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMhuu-000MsZ-Ne for psamp-data@psg.com; Fri, 24 Mar 2006 08:45:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMhut-000MsL-Kx for psamp@ops.ietf.org; Fri, 24 Mar 2006 08:45:08 +0000 Received: from n-dietz.office (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 08D111BAC4D; Fri, 24 Mar 2006 09:43:45 +0100 (CET) From: Thomas Dietz Organization: Network Laboratories, NEC Europe Ltd. To: Paul Aitken Subject: Re: PSAMP: ipHeaderPacketSection and mplsLabelStackSection Date: Fri, 24 Mar 2006 09:44:38 +0100 User-Agent: KMail/1.9.1 Cc: psamp References: <440C206A.9050902@cisco.com> <44235A65.7050301@cisco.com> In-Reply-To: <44235A65.7050301@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7887154.LQPo4GyebP"; protocol="application/pkcs7-signature"; micalg=sha1 Content-Transfer-Encoding: 7bit Message-Id: <200603240944.38909.Thomas.Dietz@netlab.nec.de> Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c --nextPart7887154.LQPo4GyebP Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Paul, I vote for solution number 2. I don't think we need an information element= =20 that represents your "knob". The collector needs to have some knowledge abo= ut=20 the protocol anyway, so it can decode the data into something useful. So it= =20 also should know when the header ends and the payload starts. If it just ge= ts=20 the header bytes its OK. If it gets more then go on... Regards, Thomas Am Freitag, 24. M=E4rz 2006 03:33 schrieb Paul Aitken: > Dear psampers, > > As I presented in yesterday's PSAMP WG meeting, PSAMP-INFO has one open > > issue which must be solved: > > Should the ipHeaderPacketSection and mplsLabelStackSection also > > report payload contents if the specified section length is longer > > than the IP header or stack size, respectively? > > Actually, it also applies to the dataLinkFrameSection which "carries the > first n octets from the data link frame of a sampled packet." > > - but if sufficient length is specified, does it continue on to also > report the L3 header and even the L3 payload? > > Sometimes capture of some octets of the payload information is very > useful - eg, to capture the UDP/TCP port numbers, or for protocol analysi= s. > > But in yesterday's WG meeting, it was pointed out that there may be > scenarios where capture of payload information is undesireable and maybe > even illegal. So clearly we need to find a way to control access to the > payload information. > > So below, I present two possible solutions for discussion. Others may be > possible too. > > Please express your opinions immediately so we can resolve and close > this issue. > > Thanks. > > > (1) Use multiple information elements, eg: > > ipPacketSection - IP header, continuing into the payload > ipHeaderPacketSection - IP header only > ipPayloadPacketSection - IP payload only > > dataLinkFrameSection - data link frame, continuing into L3 > dataLinkHeaderFrameSection - data link header only > > mplsPacketSection - MPLS label stack, cont into payload > mplsLabelStackSection - MPLS label stack only > mplsPayloadPacketSection - MPLS payload only > > > - export of the relevant IEs can be ommitted > when access to payload information is undesireable. > > - how can you capture port or protocol information > without knowing some payload bytes? > > > (2) Use the existing information elements, with an application specific > configuration knob controlling whether they continue into the next > section or not: > > ipHeaderPacketSection - IP header, optionally cont into payload > ipPayloadPacketSection - IP payload only > > dataLinkFrameSection - data link frame, continuing into L3 > > mplsLabelStackSection - MPLS label stack, opt cont into payload > mplsPayloadPacketSection - MPLS payload only > > > - how will the exporter report whether or not > the configuration knob is set? With another IE? > > > Regarding the length of packet sections, the common rule (regardless of > the IE definition) is that the exact amount of requested octets must be > exported as was defined in the template (ie, no padding short sections > with zero), else a new template must be sent either with the available > length or using variable length encoding. --nextPart7887154.LQPo4GyebP Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/DCCAvgw ggJhoAMCAQICAw9RdTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE3MDkwOTE3WhcNMDYwODE3MDkwOTE3WjBjMQ4wDAYDVQQE EwVEaWV0ejEPMA0GA1UEKhMGVGhvbWFzMRUwEwYDVQQDEwxUaG9tYXMgRGlldHoxKTAnBgkqhkiG 9w0BCQEWGlRob21hcy5EaWV0ekBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA4nhGGaCtAFl95e262kXtWs33/Co8wu3qnQqpmgEkgADwZV1ZGoNphSGYXWmdAO4S C+M2HFzsJ0FJ3eG4KV0IaI+kvuKQdfHbqKSV8OfUTIhwrzjwZVJBvUYagIBF8ksvo37XR8YPg5Hw j/zPFAbRhbGg/mrKj/Za7/P9ouv1onhwigQtOG5qcr3+MHE+I6lmkZM7FrzzNwYSJ0Jq52Q8BUEg LWdhLHnXDFy1d+tCZdtdEK3bKga13+Udc5jC0Yvg8hmY+nrxhUPKcYR038q404eJplla2qtpEC3O IoGTKLYRtcxAtoMQ1VG32AylLKJ59/GQDqXOjr9iCI4qyyj7zwIDAQABozcwNTAlBgNVHREEHjAc gRpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAE2PK+6rLfxJ5o+m3N28Uj0XGeArIfvLtnzZQDvuzz2jaThTjJ7PqULqOzjPsCGT/UsT2Ayo 2ksMnxzcVVIK4iJJlaJ2qJRrORakM2CfmkaxFkrJweezRfMPSp7tlW8QnZ/Johw746jZj5bcnOsV 0gxcXkhfMr9OcjEVsJ6+2eg6MYICGjCCAhYCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECAw9RdTAHBgUrDgMCGqCBizAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMjQwODQ0MzhaMCMGCSqGSIb3DQEJBDEWBBSWMRLLq6Wh C1QRv9vupEmz5Ut2qjAsBgkqhkiG9w0BCQ8xHzAdMA0GCWCGSAFlAwQBAgUAMAwGCCqGSIb3DQMH BQAwCwYJKoZIhvcNAQEBBIIBAGKe7iz1Zr5O16O5qN97WiVOZPnRzzhUQdP/d4wPAGydkbx+4he9 FuODynCiy0PXGYY9bbG1omcgNQYvGCkCllWfrM2QFC8TcSg2dEwrPaoEvq4HEMR66ZQc2O0X8BGr oPaXyfIFe8pBR4Or9Vkuw8LtGIRRPnpebW9e5syQLsWDpauTOZKPJSLwrLaul+1xSgUSr4PE0hwV vTQrbExCy5LyTSv37VRODnHjj20nQS0UVxwqeTvtvW7TZtsKepotVMd5wv+jXj7B48VrprEbvzAL zbUNtpj2ZQahv62+qTB3s7eK6tsI3ip9BSP3G1jiyt+TK6BHXzEnNK5wnHdyEFEAAAAAAAA= --nextPart7887154.LQPo4GyebP-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Fri Mar 24 05:07:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMjCZ-00067F-VZ for psamp-archive@lists.ietf.org; Fri, 24 Mar 2006 05:07:27 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMjCX-0007jH-63 for psamp-archive@lists.ietf.org; Fri, 24 Mar 2006 05:07:27 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMj8g-0002gh-Qe for psamp-data@psg.com; Fri, 24 Mar 2006 10:03:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [134.2.12.32] (helo=mx5.informatik.uni-tuebingen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMj8e-0002gN-Ho for psamp@ops.ietf.org; Fri, 24 Mar 2006 10:03:25 +0000 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id F01FF115 for ; Fri, 24 Mar 2006 11:03:22 +0100 (MET) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 14674-01 for ; Fri, 24 Mar 2006 11:03:15 +0100 (NFT) Received: from [127.0.0.1] (c64.informatik.uni-tuebingen.de [134.2.168.129]) by mx3.informatik.uni-tuebingen.de (Postfix) with SMTP id 1B1C0141 for ; Fri, 24 Mar 2006 11:03:13 +0100 (MET) Message-ID: <4423C3C4.30608@informatik.uni-tuebingen.de> Date: Fri, 24 Mar 2006 11:02:44 +0100 From: Gerhard Muenz User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: psamp Subject: Re: PSAMP: ipHeaderPacketSection and mplsLabelStackSection References: <440C206A.9050902@cisco.com> <44235A65.7050301@cisco.com> <200603240944.38909.Thomas.Dietz@netlab.nec.de> In-Reply-To: <200603240944.38909.Thomas.Dietz@netlab.nec.de> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Dear Thomas, Paul, I think Paul's concerns are important. Example: The standard IP header is 20 bytes long, but may be longer with options. You use a template with ipHeaderPacketSection and length 40 and want to export an IP packet that has a standard header only. There is payload which is indicated by the total length in the IP header. If the monitor now "blanks" the IP payload, your collector does not know if the payload originally was blank or not. The capability to decode the IP header information does not help. As a third solution, variable length IEs could be used (see draft-ietf-ipfix-protocol). Regards, Gerhard Thomas Dietz wrote: > Paul, > > I vote for solution number 2. I don't think we need an information element > that represents your "knob". The collector needs to have some knowledge about > the protocol anyway, so it can decode the data into something useful. So it > also should know when the header ends and the payload starts. If it just gets > the header bytes its OK. If it gets more then go on... > > Regards, > > Thomas > > Am Freitag, 24. März 2006 03:33 schrieb Paul Aitken: >> Dear psampers, >> >> As I presented in yesterday's PSAMP WG meeting, PSAMP-INFO has one open >> >> issue which must be solved: >>> Should the ipHeaderPacketSection and mplsLabelStackSection also >>> report payload contents if the specified section length is longer >>> than the IP header or stack size, respectively? >> Actually, it also applies to the dataLinkFrameSection which "carries the >> first n octets from the data link frame of a sampled packet." >> >> - but if sufficient length is specified, does it continue on to also >> report the L3 header and even the L3 payload? >> >> Sometimes capture of some octets of the payload information is very >> useful - eg, to capture the UDP/TCP port numbers, or for protocol analysis. >> >> But in yesterday's WG meeting, it was pointed out that there may be >> scenarios where capture of payload information is undesireable and maybe >> even illegal. So clearly we need to find a way to control access to the >> payload information. >> >> So below, I present two possible solutions for discussion. Others may be >> possible too. >> >> Please express your opinions immediately so we can resolve and close >> this issue. >> >> Thanks. >> >> >> (1) Use multiple information elements, eg: >> >> ipPacketSection - IP header, continuing into the payload >> ipHeaderPacketSection - IP header only >> ipPayloadPacketSection - IP payload only >> >> dataLinkFrameSection - data link frame, continuing into L3 >> dataLinkHeaderFrameSection - data link header only >> >> mplsPacketSection - MPLS label stack, cont into payload >> mplsLabelStackSection - MPLS label stack only >> mplsPayloadPacketSection - MPLS payload only >> >> >> - export of the relevant IEs can be ommitted >> when access to payload information is undesireable. >> >> - how can you capture port or protocol information >> without knowing some payload bytes? >> >> >> (2) Use the existing information elements, with an application specific >> configuration knob controlling whether they continue into the next >> section or not: >> >> ipHeaderPacketSection - IP header, optionally cont into payload >> ipPayloadPacketSection - IP payload only >> >> dataLinkFrameSection - data link frame, continuing into L3 >> >> mplsLabelStackSection - MPLS label stack, opt cont into payload >> mplsPayloadPacketSection - MPLS payload only >> >> >> - how will the exporter report whether or not >> the configuration knob is set? With another IE? >> >> >> Regarding the length of packet sections, the common rule (regardless of >> the IE definition) is that the exact amount of requested octets must be >> exported as was defined in the template (ie, no padding short sections >> with zero), else a new template must be sent either with the available >> length or using variable length encoding. -- Dipl.-Ing. Gerhard Münz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 EMail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Fri Mar 24 07:51:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMllF-0001A0-9h for psamp-archive@lists.ietf.org; Fri, 24 Mar 2006 07:51:25 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMllE-00056B-K3 for psamp-archive@lists.ietf.org; Fri, 24 Mar 2006 07:51:25 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMlf0-000J7D-SE for psamp-data@psg.com; Fri, 24 Mar 2006 12:44:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMlez-000J6w-8m for psamp@ops.ietf.org; Fri, 24 Mar 2006 12:44:57 +0000 Received: from n-dietz.office (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 107BC1BAC4D; Fri, 24 Mar 2006 13:43:33 +0100 (CET) From: Thomas Dietz Organization: Network Laboratories, NEC Europe Ltd. To: Gerhard Muenz Subject: Re: PSAMP: ipHeaderPacketSection and mplsLabelStackSection Date: Fri, 24 Mar 2006 13:44:17 +0100 User-Agent: KMail/1.9.1 Cc: psamp References: <440C206A.9050902@cisco.com> <200603240944.38909.Thomas.Dietz@netlab.nec.de> <4423C3C4.30608@informatik.uni-tuebingen.de> In-Reply-To: <4423C3C4.30608@informatik.uni-tuebingen.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1683523.hl8SENBDuT"; protocol="application/pkcs7-signature"; micalg=sha1 Content-Transfer-Encoding: 7bit Message-Id: <200603241344.22667.Thomas.Dietz@netlab.nec.de> Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e --nextPart1683523.hl8SENBDuT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Gerhard and all, I understand now that there are two decisions to take: 1 - do we allow payload in those IEs 2 - how do we encode it So, I guess we all agreed that it may be benefitial in some cases to includ= e=20 payload in those IEs. So the question remains how do I encode it that the=20 collector nows that there is payload and it is the real payload and not=20 something that was just nulled to hide content. I then would propose to use variable length elements by default. It is a lo= cal=20 decision of the exporter if it will always export only header bytes or if i= t=20 will include some bytes of the payload. The local=20 configuration/implementation may impose a maximum limit of those chunks but= =20 again thats a design and implementation decision of the exporter. The collector should be able to decide where the header ends and the payloa= d=20 starts (if any payload is in). Paul, I hope this also meets your requirements. Best Regards, Thomas Am Freitag, 24. M=E4rz 2006 11:02 schrieb Gerhard Muenz: > Dear Thomas, Paul, > > I think Paul's concerns are important. > > Example: > The standard IP header is 20 bytes long, but may be longer with options. > You use a template with ipHeaderPacketSection and length 40 and want to > export an IP packet that has a standard header only. There is payload > which is indicated by the total length in the IP header. > If the monitor now "blanks" the IP payload, your collector does not know > if the payload originally was blank or not. The capability to decode the > IP header information does not help. > > As a third solution, variable length IEs could be used (see > draft-ietf-ipfix-protocol). > > Regards, > Gerhard > > Thomas Dietz wrote: > > Paul, > > > > I vote for solution number 2. I don't think we need an information > > element that represents your "knob". The collector needs to have some > > knowledge about the protocol anyway, so it can decode the data into > > something useful. So it also should know when the header ends and the > > payload starts. If it just gets the header bytes its OK. If it gets more > > then go on... > > > > Regards, > > > > Thomas > > > > Am Freitag, 24. M=E4rz 2006 03:33 schrieb Paul Aitken: > >> Dear psampers, > >> > >> As I presented in yesterday's PSAMP WG meeting, PSAMP-INFO has one open > >> > >> issue which must be solved: > >>> Should the ipHeaderPacketSection and mplsLabelStackSection also > >>> report payload contents if the specified section length is longer > >>> than the IP header or stack size, respectively? > >> > >> Actually, it also applies to the dataLinkFrameSection which "carries t= he > >> first n octets from the data link frame of a sampled packet." > >> > >> - but if sufficient length is specified, does it continue on to also > >> report the L3 header and even the L3 payload? > >> > >> Sometimes capture of some octets of the payload information is very > >> useful - eg, to capture the UDP/TCP port numbers, or for protocol > >> analysis. > >> > >> But in yesterday's WG meeting, it was pointed out that there may be > >> scenarios where capture of payload information is undesireable and may= be > >> even illegal. So clearly we need to find a way to control access to the > >> payload information. > >> > >> So below, I present two possible solutions for discussion. Others may = be > >> possible too. > >> > >> Please express your opinions immediately so we can resolve and close > >> this issue. > >> > >> Thanks. > >> > >> > >> (1) Use multiple information elements, eg: > >> > >> ipPacketSection - IP header, continuing into the paylo= ad > >> ipHeaderPacketSection - IP header only > >> ipPayloadPacketSection - IP payload only > >> > >> dataLinkFrameSection - data link frame, continuing into L3 > >> dataLinkHeaderFrameSection - data link header only > >> > >> mplsPacketSection - MPLS label stack, cont into payload > >> mplsLabelStackSection - MPLS label stack only > >> mplsPayloadPacketSection - MPLS payload only > >> > >> > >> - export of the relevant IEs can be ommitted > >> when access to payload information is undesireable. > >> > >> - how can you capture port or protocol information > >> without knowing some payload bytes? > >> > >> > >> (2) Use the existing information elements, with an application specific > >> configuration knob controlling whether they continue into the next > >> section or not: > >> > >> ipHeaderPacketSection - IP header, optionally cont into payload > >> ipPayloadPacketSection - IP payload only > >> > >> dataLinkFrameSection - data link frame, continuing into L3 > >> > >> mplsLabelStackSection - MPLS label stack, opt cont into payload > >> mplsPayloadPacketSection - MPLS payload only > >> > >> > >> - how will the exporter report whether or not > >> the configuration knob is set? With another IE? > >> > >> > >> Regarding the length of packet sections, the common rule (regardless of > >> the IE definition) is that the exact amount of requested octets must be > >> exported as was defined in the template (ie, no padding short sections > >> with zero), else a new template must be sent either with the available > >> length or using variable length encoding. --nextPart1683523.hl8SENBDuT Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/DCCAvgw ggJhoAMCAQICAw9RdTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE3MDkwOTE3WhcNMDYwODE3MDkwOTE3WjBjMQ4wDAYDVQQE EwVEaWV0ejEPMA0GA1UEKhMGVGhvbWFzMRUwEwYDVQQDEwxUaG9tYXMgRGlldHoxKTAnBgkqhkiG 9w0BCQEWGlRob21hcy5EaWV0ekBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA4nhGGaCtAFl95e262kXtWs33/Co8wu3qnQqpmgEkgADwZV1ZGoNphSGYXWmdAO4S C+M2HFzsJ0FJ3eG4KV0IaI+kvuKQdfHbqKSV8OfUTIhwrzjwZVJBvUYagIBF8ksvo37XR8YPg5Hw j/zPFAbRhbGg/mrKj/Za7/P9ouv1onhwigQtOG5qcr3+MHE+I6lmkZM7FrzzNwYSJ0Jq52Q8BUEg LWdhLHnXDFy1d+tCZdtdEK3bKga13+Udc5jC0Yvg8hmY+nrxhUPKcYR038q404eJplla2qtpEC3O IoGTKLYRtcxAtoMQ1VG32AylLKJ59/GQDqXOjr9iCI4qyyj7zwIDAQABozcwNTAlBgNVHREEHjAc gRpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAE2PK+6rLfxJ5o+m3N28Uj0XGeArIfvLtnzZQDvuzz2jaThTjJ7PqULqOzjPsCGT/UsT2Ayo 2ksMnxzcVVIK4iJJlaJ2qJRrORakM2CfmkaxFkrJweezRfMPSp7tlW8QnZ/Johw746jZj5bcnOsV 0gxcXkhfMr9OcjEVsJ6+2eg6MYICGjCCAhYCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECAw9RdTAHBgUrDgMCGqCBizAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMjQxMjQ0MTdaMCMGCSqGSIb3DQEJBDEWBBRp21O0mUJc RI7Inx3XQ3lofHm13TAsBgkqhkiG9w0BCQ8xHzAdMA0GCWCGSAFlAwQBAgUAMAwGCCqGSIb3DQMH BQAwCwYJKoZIhvcNAQEBBIIBADnOWdsxyLxYgirxS736E0KsrIQeYlrexU2cVMMGhDGkxgZ8fgCq OPS9c6B+Kvc25bkJrKx+DrWGgRlgWy31ovPsAXw8RlVwggCq1iwCsvNVBQMJz0QJm49W2aX3JcBx I1/rJWEG5Lc3b4hcgiT9U/9HBCCm3LjAlkPfBt0UMD4OFyMgjR0D4q13MtSb8gffwew9rpNDA7i+ NpzEvLi9167DuNy5LSI1nQWigVgWoVw3G1N+dxeE2HPFEj79kWvH3p5x6dkxEASxMNpeWhYQRoji GJ2Wlh4dYklaOualgZBE/Q6btkjUppg34+5GMZf/9ns94WA97vKzplaseUZKVNQAAAAAAAA= --nextPart1683523.hl8SENBDuT-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Sat Mar 25 11:48:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNBwF-0001W4-FE for psamp-archive@lists.ietf.org; Sat, 25 Mar 2006 11:48:31 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNBwF-0006oO-4r for psamp-archive@lists.ietf.org; Sat, 25 Mar 2006 11:48:31 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNBnT-0003S0-Fb for psamp-data@psg.com; Sat, 25 Mar 2006 16:39:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNBnS-0003RN-M6 for psamp@ops.ietf.org; Sat, 25 Mar 2006 16:39:26 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 25 Mar 2006 17:39:25 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2PGdP36029037; Sat, 25 Mar 2006 17:39:25 +0100 (MET) Received: from [10.61.81.117] (ams-clip-vpn-dhcp4470.cisco.com [10.61.81.117]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA04864; Sat, 25 Mar 2006 16:39:21 GMT Message-ID: <44257239.7080404@cisco.com> Date: Sat, 25 Mar 2006 16:39:21 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.10) Gecko/20050811 Fedora/1.7.10-1.2.1.legacy X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Thomas Dietz CC: Gerhard Muenz , psamp Subject: Re: PSAMP: ipHeaderPacketSection and mplsLabelStackSection References: <440C206A.9050902@cisco.com> <200603240944.38909.Thomas.Dietz@netlab.nec.de> <4423C3C4.30608@informatik.uni-tuebingen.de> <200603241344.22667.Thomas.Dietz@netlab.nec.de> In-Reply-To: <200603241344.22667.Thomas.Dietz@netlab.nec.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Thomas, > I understand now that there are two decisions to take: > > 1 - do we allow payload in those IEs > 2 - how do we encode it > > So, I guess we all agreed that it may be benefitial in some cases to include > payload in those IEs. So the question remains how do I encode it that the > collector nows that there is payload and it is the real payload and not > something that was just nulled to hide content. I'd say that this text says you're not allowed to do that: If insufficient octets are available for the length specified in the template, the packet section must be sent with a new template using either a fixed length Information Element of the necessary size or a variable length Information Element. It's not permissible to pad a short packet section to a longer length. Reasons: 1. "insufficient octets are available" because of a security concern (rather than because they simply didn't exist). 2. nulling payload to hide the content is essentially padding out the packet section to the necessary length, which is explicitly forbidden by the last line. > I then would propose to use variable length elements by default. It's definitely necessary if you want to export the packet from the start of the IP header to the end of the L4 info to get the port numbers (assuming that the header packet section runs right through into the payload). > It is a local > decision of the exporter if it will always export only header bytes or if it > will include some bytes of the payload. The local > configuration/implementation may impose a maximum limit of those chunks but > again thats a design and implementation decision of the exporter. You're clearly in favour of solution (2). I also favour this solution. > The collector should be able to decide where the header ends and the payload > starts (if any payload is in). > > Paul, I hope this also meets your requirements. Yes, thanks. So I propose to adopt solution (2) unless anyone raises serious objections by next Friday. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Sat Mar 25 11:48:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNBwR-0001bp-I3 for psamp-archive@lists.ietf.org; Sat, 25 Mar 2006 11:48:43 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNBwR-0006oe-8q for psamp-archive@lists.ietf.org; Sat, 25 Mar 2006 11:48:43 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNBqA-0003cR-Nf for psamp-data@psg.com; Sat, 25 Mar 2006 16:42:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNBqA-0003cE-6n for psamp@ops.ietf.org; Sat, 25 Mar 2006 16:42:14 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 25 Mar 2006 17:42:13 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2PGgD36029285; Sat, 25 Mar 2006 17:42:13 +0100 (MET) Received: from [10.61.81.117] (ams-clip-vpn-dhcp4470.cisco.com [10.61.81.117]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA05098; Sat, 25 Mar 2006 16:42:12 GMT Message-ID: <442572E3.7060302@cisco.com> Date: Sat, 25 Mar 2006 16:42:11 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.10) Gecko/20050811 Fedora/1.7.10-1.2.1.legacy X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Gerhard Muenz CC: psamp Subject: Re: PSAMP: ipHeaderPacketSection and mplsLabelStackSection References: <440C206A.9050902@cisco.com> <44235A65.7050301@cisco.com> <200603240944.38909.Thomas.Dietz@netlab.nec.de> <4423C3C4.30608@informatik.uni-tuebingen.de> In-Reply-To: <4423C3C4.30608@informatik.uni-tuebingen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Gerhard, > I think Paul's concerns are important. > > Example: > The standard IP header is 20 bytes long, but may be longer with options. > You use a template with ipHeaderPacketSection and length 40 and want to > export an IP packet that has a standard header only. There is payload > which is indicated by the total length in the IP header. > If the monitor now "blanks" the IP payload, your collector does not know > if the payload originally was blank or not. The capability to decode the > IP header information does not help. Blanking the payload is not allowed. See my reply to Thomas. Instead, the application would have been configured to only export header information (no payload info), so it would have to create a new template either with the necessary fixed length, or with a variable length. > As a third solution, variable length IEs could be used (see > draft-ietf-ipfix-protocol). This is allowed by solution (2). -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Sun Mar 26 16:20:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNcfM-0004Wi-H4 for psamp-archive@lists.ietf.org; Sun, 26 Mar 2006 16:20:52 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNcfK-0000zO-7h for psamp-archive@lists.ietf.org; Sun, 26 Mar 2006 16:20:52 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNcX8-000IDD-D4 for psamp-data@psg.com; Sun, 26 Mar 2006 21:12:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNcX5-000ICz-AW for psamp@ops.ietf.org; Sun, 26 Mar 2006 21:12:19 +0000 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6CE9C1BAC4D for ; Sun, 26 Mar 2006 23:10:38 +0200 (CEST) Date: Sun, 26 Mar 2006 23:12:12 +0100 From: Juergen Quittek To: psamp@ops.ietf.org Subject: draft minutes of PSAMP session at IETF #65 Message-ID: <46FA20AED501BAEFA7504731@753F3B888A9969457862729D> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Dear all, Draft minutes of our session in Dallas are available at . Please check them and send your comments to this list. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Mar 27 00:03:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNjsc-00037Z-Ht for psamp-archive@lists.ietf.org; Mon, 27 Mar 2006 00:03:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNjsb-00021M-8H for psamp-archive@lists.ietf.org; Mon, 27 Mar 2006 00:03:02 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNjjA-000Hil-Tc for psamp-data@psg.com; Mon, 27 Mar 2006 04:53:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNjjA-000HiU-1r for psamp@ops.ietf.org; Mon, 27 Mar 2006 04:53:16 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 27 Mar 2006 06:53:15 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2R4rE36012652; Mon, 27 Mar 2006 06:53:14 +0200 (MEST) Received: from [10.61.80.60] (ams-clip-vpn-dhcp4157.cisco.com [10.61.80.60]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id FAA01604; Mon, 27 Mar 2006 05:53:09 +0100 (BST) Message-ID: <44276FB5.5060004@cisco.com> Date: Mon, 27 Mar 2006 05:53:09 +0100 From: Andrew Johnson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Paul Aitken CC: Gerhard Muenz , psamp Subject: Re: PSAMP: ipHeaderPacketSection and mplsLabelStackSection References: <440C206A.9050902@cisco.com> <44235A65.7050301@cisco.com> <200603240944.38909.Thomas.Dietz@netlab.nec.de> <4423C3C4.30608@informatik.uni-tuebingen.de> <442572E3.7060302@cisco.com> In-Reply-To: <442572E3.7060302@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Paul Aitken wrote: > Gerhard, > >> I think Paul's concerns are important. >> >> Example: >> The standard IP header is 20 bytes long, but may be longer with options. >> You use a template with ipHeaderPacketSection and length 40 and want to >> export an IP packet that has a standard header only. There is payload >> which is indicated by the total length in the IP header. >> If the monitor now "blanks" the IP payload, your collector does not know >> if the payload originally was blank or not. The capability to decode the >> IP header information does not help. > > Blanking the payload is not allowed. See my reply to Thomas. > > Instead, the application would have been configured to only export > header information (no payload info), so it would have to create a new > template either with the necessary fixed length, or with a variable length. I think something for implementers to consider, would be to allow a configurable amount of IP payload in the header packet section. If you want the first 8 bytes of payload + all of the IPv4 or IPv6 packet, then you couldn't pick a fixed size to cover all cases without it being large enough to grab a large part of the payload in some cases. regards Andrew -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Mar 27 03:27:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNn4v-0002G7-CV for psamp-archive@lists.ietf.org; Mon, 27 Mar 2006 03:27:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNn4t-0001eF-Co for psamp-archive@lists.ietf.org; Mon, 27 Mar 2006 03:27:57 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNmut-0001en-Sq for psamp-data@psg.com; Mon, 27 Mar 2006 08:17:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [134.2.12.32] (helo=mx5.informatik.uni-tuebingen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNmur-0001eS-ON for psamp@ops.ietf.org; Mon, 27 Mar 2006 08:17:34 +0000 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 73E7711B; Mon, 27 Mar 2006 10:17:32 +0200 (MST) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 14746-02; Mon, 27 Mar 2006 10:17:30 +0200 (DFT) Received: from [127.0.0.1] (c64.informatik.uni-tuebingen.de [134.2.168.129]) by mx3.informatik.uni-tuebingen.de (Postfix) with SMTP id CDDEA145; Mon, 27 Mar 2006 10:17:29 +0200 (MST) Message-ID: <44279F7C.50607@informatik.uni-tuebingen.de> Date: Mon, 27 Mar 2006 10:17:00 +0200 From: Gerhard Muenz User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Paul Aitken Cc: psamp Subject: Re: PSAMP: ipHeaderPacketSection and mplsLabelStackSection References: <440C206A.9050902@cisco.com> <44235A65.7050301@cisco.com> <200603240944.38909.Thomas.Dietz@netlab.nec.de> <4423C3C4.30608@informatik.uni-tuebingen.de> <442572E3.7060302@cisco.com> In-Reply-To: <442572E3.7060302@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090800030604010202000100" X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 This is a cryptographically signed message in MIME format. --------------ms090800030604010202000100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Paul, Fine for me. I did not realize that the specification for ipPayloadPacketSection changed since -03. Regards, Gerhard Paul Aitken wrote: > Gerhard, > >> I think Paul's concerns are important. >> >> Example: >> The standard IP header is 20 bytes long, but may be longer with options. >> You use a template with ipHeaderPacketSection and length 40 and want to >> export an IP packet that has a standard header only. There is payload >> which is indicated by the total length in the IP header. >> If the monitor now "blanks" the IP payload, your collector does not know >> if the payload originally was blank or not. The capability to decode the >> IP header information does not help. > > Blanking the payload is not allowed. See my reply to Thomas. > > Instead, the application would have been configured to only export > header information (no payload info), so it would have to create a new > template either with the necessary fixed length, or with a variable length. > > >> As a third solution, variable length IEs could be used (see >> draft-ietf-ipfix-protocol). > > This is allowed by solution (2). > -- Dipl.-Ing. Gerhard Münz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 EMail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms090800030604010202000100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICEFnnd0ztch8/FKZyDU4aYM8wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDIxMDE3MjI0OVoX DTA3MDIxMDE3MjI0OVowbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOJTlGpd UzaDtPwN+ScPJAXpfQletJ+7B/Zr5MDTyHrAGyXcwsWZB6y7PEO+blM2X66y7+e0kRZVUJYo ycFQZ2dOFS+L2cwNeiea0fEi4wGZ507kYPsFWlYFmB0dRTTTrz6zQaxpsBllvJsTHeYKJ5hc gXyP4la+7ArnYidjqcEpwJqiIO5BNIiX/6WR70tDb7cgJgA2VTgLgWWUbD3cPc9lP0wgEjVB 1/KBZ7F1gVKWCatZSsjBUnf9OO9/DexMdeKCtho06/56ddljFbwwLO4kzy06yzdFlruUWtHZ /hE+IwN/twj+Iv9B6Q2buWICUZi8GHzUKK4CoKsYW93ah5sCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEArrY1DQ7N6RiHFbjBcsmGfm0IqlCOH+X1c77jMwjR2TFYlsb9urRP ZaFFhVo6lKmZSw2+0QPXhtG6hkFCruSzqRA2Xc+ePpm/nftGLrE4kXsnza35lqfCYfKBVk/i 5ugddlcc3FzyCcBnCOOy+XCt5JfweGCkbsMyuVL1oTRHv88wggMVMIICfqADAgECAhBZ53dM 7XIfPxSmcg1OGmDPMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjAyMTAxNzIyNDlaFw0wNzAyMTAxNzIyNDlaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDiU5RqXVM2g7T8DfknDyQF6X0JXrSf uwf2a+TA08h6wBsl3MLFmQesuzxDvm5TNl+usu/ntJEWVVCWKMnBUGdnThUvi9nMDXonmtHx IuMBmedO5GD7BVpWBZgdHUU0068+s0GsabAZZbybEx3mCieYXIF8j+JWvuwK52InY6nBKcCa oiDuQTSIl/+lke9LQ2+3ICYANlU4C4FllGw93D3PZT9MIBI1QdfygWexdYFSlgmrWUrIwVJ3 /Tjvfw3sTHXigrYaNOv+enXZYxW8MCzuJM8tOss3RZa7lFrR2f4RPiMDf7cI/iL/QekNm7li AlGYvBh81CiuAqCrGFvd2oebAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAK62 NQ0OzekYhxW4wXLJhn5tCKpQjh/l9XO+4zMI0dkxWJbG/bq0T2WhRYVaOpSpmUsNvtED14bR uoZBQq7ks6kQNl3Pnj6Zv537Ri6xOJF7J82t+ZanwmHygVZP4uboHXZXHNxc8gnAZwjjsvlw reSX8HhgpG7DMrlS9aE0R7/PMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBZ53dM 7XIfPxSmcg1OGmDPMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA2MDMyNzA4MTcwMFowIwYJKoZIhvcNAQkEMRYEFFUaiRr5Kg+Y MFVeOJBdJhiMULUWMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ Wed3TO1yHz8UpnINThpgzzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQWed3TO1yHz8UpnINThpgzzANBgkqhkiG 9w0BAQEFAASCAQDZfrEP45vpeL9WNs3Not51JopbWwPbguoC1H91WdHfM4zb0UsZfh1621rW eQXaC1ng6Cepy2n6Rlkw+KOHgXKpXZOypq5Jk+wQHEPLNhljRoPbrYPOdC8jbo4LOAmDj2ob Hx3irDfWSQ1orl9adfV4xMx+6AJS+wqAUgQrAeLXkVVcGpf7oTskHQp5+NYbEAd186A6dX7k 1vmQoinWDrCw6nnvWmfm09KLt4DTDBu2F6KyMTjJuIZBs3WnH1s4W9OEnXyM1KUya1ajzFxq O2ohIAAYnX2priaOLzTvl6mgOoqW9+ormHxdRlpvtRoI1dOvh6IuRt6rgwZzON8AYcQ/AAAA AAAA --------------ms090800030604010202000100-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Mar 27 03:36:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNnCm-0006QM-7g for psamp-archive@lists.ietf.org; Mon, 27 Mar 2006 03:36:04 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNnCk-0001xv-V5 for psamp-archive@lists.ietf.org; Mon, 27 Mar 2006 03:36:04 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNn8J-0002Mm-Ir for psamp-data@psg.com; Mon, 27 Mar 2006 08:31:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNn8I-0002Ma-QJ for psamp@ops.ietf.org; Mon, 27 Mar 2006 08:31:27 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2R8VNRp012699; Mon, 27 Mar 2006 02:31:24 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Mar 2006 10:31:22 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509A15AB5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Psamp (E-mail)" Cc: "Juergen Quittek (E-mail)" Subject: mailing list is being moved Date: Mon, 27 Mar 2006 10:31:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 We are in the process of moving the PSAMP mailing list from psamp@ops.ietf.org to psamp@ietf.org All current subscribers are bing moved to to the new list as well. Pls keep an eye on announcement regarding the move. If you do post just around the swithcover, you may want to check if your posting made it to the archives, and if not, then re-post. You'll get a message when the actual cutover happens. At that time, we will also unsubscribe you all from the list at ops.ietf.org Bert and Juergen -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Mar 27 05:10:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNogU-0000S0-Bi for psamp-archive@lists.ietf.org; Mon, 27 Mar 2006 05:10:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNogT-0006Rr-B9 for psamp-archive@lists.ietf.org; Mon, 27 Mar 2006 05:10:50 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNoZn-0007D2-ES for psamp-data@psg.com; Mon, 27 Mar 2006 10:03:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNoZk-0007CE-Vz for psamp@ops.ietf.org; Mon, 27 Mar 2006 10:03:54 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 27 Mar 2006 12:03:49 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2RA3m36027377; Mon, 27 Mar 2006 12:03:48 +0200 (MEST) Received: from [10.61.82.49] (ams-clip-vpn-dhcp4658.cisco.com [10.61.82.49]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA22640; Mon, 27 Mar 2006 11:03:47 +0100 (BST) Message-ID: <4427B882.1060202@cisco.com> Date: Mon, 27 Mar 2006 11:03:46 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.10) Gecko/20050811 Fedora/1.7.10-1.2.1.legacy X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Andrew Johnson CC: Gerhard Muenz , psamp Subject: Re: PSAMP: ipHeaderPacketSection and mplsLabelStackSection References: <440C206A.9050902@cisco.com> <44235A65.7050301@cisco.com> <200603240944.38909.Thomas.Dietz@netlab.nec.de> <4423C3C4.30608@informatik.uni-tuebingen.de> <442572E3.7060302@cisco.com> <44276FB5.5060004@cisco.com> In-Reply-To: <44276FB5.5060004@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Andrew, > I think something for implementers to consider, would be to allow a > configurable amount of IP payload in the header packet section. If > you want the first 8 bytes of payload + all of the IPv4 or IPv6 > packet, then you couldn't pick a fixed size to cover all cases > without it being large enough to grab a large part of the payload > in some cases. So instead of a boolean [don't]continue-into-payload switch, an application could provide a configurable continue-into-payload count of n octets, being zero or more depending on the user and legal requirements. Being an application specific thing, this isn't something for either the protocol or info model to dictate. But since we don't have a PSAMP Implimentation Guide, I propose these texts: ipHeaderPacketSection Description: This information element carries a series of octets from the start of the IP header of a sampled packet. An application may append zero or more payload octets to the end of the ipHeaderPacketSection. The size of the exported section may be constrained due to limitations in the IPFIX protocol. mplsLabelStackSection Description: This information element carries the first n octets from the MPLS label stack of a sampled packet. An application may append zero or more payload octets to the end of the mplsLabelStackSection. See [RFC3031] for the specification of MPLS packets. See [RFC3032] for the specification of the MPLS label stack. The size of the exported section may be constrained due to limitations in the IPFIX protocol. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Mar 27 05:34:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNp3P-0006RI-Ry for psamp-archive@lists.ietf.org; Mon, 27 Mar 2006 05:34:31 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNp3P-0007j6-FE for psamp-archive@lists.ietf.org; Mon, 27 Mar 2006 05:34:31 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNowh-0009Q3-IN for psamp-data@psg.com; Mon, 27 Mar 2006 10:27:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.1 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNowg-0009Ps-Ur for psamp@ops.ietf.org; Mon, 27 Mar 2006 10:27:35 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 27 Mar 2006 12:27:34 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2RARX36005288 for ; Mon, 27 Mar 2006 12:27:33 +0200 (MEST) Received: from [10.61.64.122] (ams-clip-vpn-dhcp122.cisco.com [10.61.64.122]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA24607; Mon, 27 Mar 2006 11:27:27 +0100 (BST) Message-ID: <4427BE0E.7030408@cisco.com> Date: Mon, 27 Mar 2006 11:27:26 +0100 From: Andrew Johnson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Paul Aitken CC: psamp Subject: Re: PSAMP: ipHeaderPacketSection and mplsLabelStackSection References: <440C206A.9050902@cisco.com> <44235A65.7050301@cisco.com> <200603240944.38909.Thomas.Dietz@netlab.nec.de> <4423C3C4.30608@informatik.uni-tuebingen.de> <442572E3.7060302@cisco.com> <44276FB5.5060004@cisco.com> <4427B882.1060202@cisco.com> In-Reply-To: <4427B882.1060202@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Paul, Paul Aitken wrote: > Andrew, > >> I think something for implementers to consider, would be to allow a >> configurable amount of IP payload in the header packet section. If >> you want the first 8 bytes of payload + all of the IPv4 or IPv6 >> packet, then you couldn't pick a fixed size to cover all cases >> without it being large enough to grab a large part of the payload >> in some cases. > > So instead of a boolean [don't]continue-into-payload switch, an > application could provide a configurable continue-into-payload count of > n octets, being zero or more depending on the user and legal requirements. Yes. > Being an application specific thing, this isn't something for either the > protocol or info model to dictate. But since we don't have a PSAMP > Implimentation Guide, I propose these texts: Well just because we don't have an implementation guide at the moment, doesn't mean we won't in the future. If something is best left to the implementation guide then I don't think we should have to adjust the model or protocol documents. > ipHeaderPacketSection > > Description: > This information element carries a series of octets from the start > of the IP header of a sampled packet. > > An application may append zero or more payload octets to the end > of the ipHeaderPacketSection. > > The size of the exported section may be constrained due to > limitations in the IPFIX protocol. > > > mplsLabelStackSection > > Description: > This information element carries the first n octets from the MPLS > label stack of a sampled packet. > > An application may append zero or more payload octets to the end > of the mplsLabelStackSection. The wording of this sounds as though it would allow a few octets from the MPLS stack (not all) then a few octets from the payload. The previous description isn't so bad as it doesn't talk about n octets of the header. I would prefer something like: This information element carries a series of octets from the start of of the IP header of a sampled packet. The size of the packet section is controlled by the PSAMP device and MAY continue into the payload. The element MUST NOT contain any padding and if the PSAMP device is configured to stop after n octets, at the end of the IP header or after m octets of payload, the size of the field must be adjusted to match the number of bytes exported using either a variable length field or a template containing a field of the correct size. regards Andrew > See [RFC3031] for the specification of MPLS packets. > See [RFC3032] for the specification of the MPLS label stack. > > The size of the exported section may be constrained due to > limitations in the IPFIX protocol. > -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Mar 27 06:42:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNq6k-0008Nd-T4 for psamp-archive@lists.ietf.org; Mon, 27 Mar 2006 06:42:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNq6j-0001te-Fr for psamp-archive@lists.ietf.org; Mon, 27 Mar 2006 06:42:02 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNq2Q-000F8D-CP for psamp-data@psg.com; Mon, 27 Mar 2006 11:37:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNq2O-000F7z-Ls for psamp@ops.ietf.org; Mon, 27 Mar 2006 11:37:33 +0000 Received: from n-dietz.office (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id C2EE11BAC4D; Mon, 27 Mar 2006 13:35:47 +0200 (CEST) From: Thomas Dietz Organization: Network Laboratories, NEC Europe Ltd. To: Andrew Johnson Subject: Re: PSAMP: ipHeaderPacketSection and mplsLabelStackSection Date: Mon, 27 Mar 2006 13:37:22 +0200 User-Agent: KMail/1.9.1 Cc: Paul Aitken , psamp References: <440C206A.9050902@cisco.com> <4427B882.1060202@cisco.com> <4427BE0E.7030408@cisco.com> In-Reply-To: <4427BE0E.7030408@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6026755.azouhPl5zx"; protocol="application/pkcs7-signature"; micalg=sha1 Content-Transfer-Encoding: 7bit Message-Id: <200603271337.27086.Thomas.Dietz@netlab.nec.de> Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 --nextPart6026755.azouhPl5zx Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Andrew, Paul, I agree to Andrews comments and I like his wording very much. I think this= =20 makes the IE really clear. I guess we will get something like an=20 Implementation Guide as more and more people will implement PSAMP. Regards, Thomas Am Montag, 27. M=E4rz 2006 12:27 schrieb Andrew Johnson: > Paul, > > Paul Aitken wrote: > > Andrew, > > > >> I think something for implementers to consider, would be to allow a > >> configurable amount of IP payload in the header packet section. If > >> you want the first 8 bytes of payload + all of the IPv4 or IPv6 > >> packet, then you couldn't pick a fixed size to cover all cases > >> without it being large enough to grab a large part of the payload > >> in some cases. > > > > So instead of a boolean [don't]continue-into-payload switch, an > > application could provide a configurable continue-into-payload count of > > n octets, being zero or more depending on the user and legal > > requirements. > > Yes. > > > Being an application specific thing, this isn't something for either the > > protocol or info model to dictate. But since we don't have a PSAMP > > Implimentation Guide, I propose these texts: > > Well just because we don't have an implementation guide at the moment, > doesn't mean we won't in the future. If something is best left to the > implementation guide then I don't think we should have to adjust the > model or protocol documents. > > > ipHeaderPacketSection > > > > Description: > > This information element carries a series of octets from the start > > of the IP header of a sampled packet. > > > > An application may append zero or more payload octets to the end > > of the ipHeaderPacketSection. > > > > The size of the exported section may be constrained due to > > limitations in the IPFIX protocol. > > > > > > mplsLabelStackSection > > > > Description: > > This information element carries the first n octets from the MPLS > > label stack of a sampled packet. > > > > An application may append zero or more payload octets to the end > > of the mplsLabelStackSection. > > The wording of this sounds as though it would allow a few octets from the > MPLS stack (not all) then a few octets from the payload. The previous > description isn't so bad as it doesn't talk about n octets of the header. > > I would prefer something like: > This information element carries a series of octets from the start of > of the IP header of a sampled packet. The size of the packet section > is controlled by the PSAMP device and MAY continue into the payload. > > The element MUST NOT contain any padding and if the PSAMP device is > configured to stop after n octets, at the end of the IP header or > after m octets of payload, the size of the field must be adjusted > to match the number of bytes exported using either a variable length > field or a template containing a field of the correct size. > > regards > > Andrew > > > See [RFC3031] for the specification of MPLS packets. > > See [RFC3032] for the specification of the MPLS label stack. > > > > The size of the exported section may be constrained due to > > limitations in the IPFIX protocol. > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: =2D-=20 Thomas Dietz Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany --nextPart6026755.azouhPl5zx Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/DCCAvgw ggJhoAMCAQICAw9RdTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE3MDkwOTE3WhcNMDYwODE3MDkwOTE3WjBjMQ4wDAYDVQQE EwVEaWV0ejEPMA0GA1UEKhMGVGhvbWFzMRUwEwYDVQQDEwxUaG9tYXMgRGlldHoxKTAnBgkqhkiG 9w0BCQEWGlRob21hcy5EaWV0ekBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA4nhGGaCtAFl95e262kXtWs33/Co8wu3qnQqpmgEkgADwZV1ZGoNphSGYXWmdAO4S C+M2HFzsJ0FJ3eG4KV0IaI+kvuKQdfHbqKSV8OfUTIhwrzjwZVJBvUYagIBF8ksvo37XR8YPg5Hw j/zPFAbRhbGg/mrKj/Za7/P9ouv1onhwigQtOG5qcr3+MHE+I6lmkZM7FrzzNwYSJ0Jq52Q8BUEg LWdhLHnXDFy1d+tCZdtdEK3bKga13+Udc5jC0Yvg8hmY+nrxhUPKcYR038q404eJplla2qtpEC3O IoGTKLYRtcxAtoMQ1VG32AylLKJ59/GQDqXOjr9iCI4qyyj7zwIDAQABozcwNTAlBgNVHREEHjAc gRpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAE2PK+6rLfxJ5o+m3N28Uj0XGeArIfvLtnzZQDvuzz2jaThTjJ7PqULqOzjPsCGT/UsT2Ayo 2ksMnxzcVVIK4iJJlaJ2qJRrORakM2CfmkaxFkrJweezRfMPSp7tlW8QnZ/Johw746jZj5bcnOsV 0gxcXkhfMr9OcjEVsJ6+2eg6MYICGjCCAhYCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECAw9RdTAHBgUrDgMCGqCBizAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMjcxMTM3MjNaMCMGCSqGSIb3DQEJBDEWBBQd332ml+29 mWfsHHzX2/8RMmvHjjAsBgkqhkiG9w0BCQ8xHzAdMA0GCWCGSAFlAwQBAgUAMAwGCCqGSIb3DQMH BQAwCwYJKoZIhvcNAQEBBIIBAK9+uYDc9JMGKBzX0rbvN4UDHtzAAqjLjZxBKZlh7dfZmUqdyr+0 D58xyrQlC9YVhEL5aEsVq7IHs0et12jxi9dwS/7J4t5gwEm0e3zPY66r74ACaIoBq7d9wYGoACT+ Tuv+RBwHFYTu6SfXsAOEqH941/T1vhkOM18Zji9zEhRBMu4pEQd8u7FQX7w8Dw1U2caqcvYua5lP SYR4FIt82SEN6b2W4uFs+7g/BEp7QsjqUxEmEk9WpmmKsn7IolKio7PBMZZCH2afvo8sNU5Q45Mz vHv0mhQ6QOkNojgGmJz1ADQ1aoWjQouSE2X1xn3sVssc4E671QT9yqwVwCKlnd4AAAAAAAA= --nextPart6026755.azouhPl5zx-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From psamp-bounces@ietf.org Tue Mar 28 04:56:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOAwa-0007D6-2U; Tue, 28 Mar 2006 04:56:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOAwY-00078p-WC for psamp@ietf.org; Tue, 28 Mar 2006 04:56:55 -0500 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOAwX-0001wJ-O6 for psamp@ietf.org; Tue, 28 Mar 2006 04:56:54 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2S9unuK005827; Tue, 28 Mar 2006 03:56:50 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Mar 2006 11:56:48 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509AA143E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: psamp@ietf.org Date: Tue, 28 Mar 2006 11:56:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: "Juergen Quittek \(E-mail\)" Subject: [PSAMP] PSAMP mailing list is moving. X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: psamp-bounces@ietf.org We are moving the WG mailing list from old: psamp@ops.ietf.org New: psamp@ietf.org All subscription have been moved to the new list as well. You list administrator is Juergen. If you get this message, pls start posting to the new email address. The old one is being dismantled as we speak. Bert _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From owner-psamp@ops.ietf.org Tue Mar 28 05:56:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOBrt-0003LK-3D for psamp-archive@lists.ietf.org; Tue, 28 Mar 2006 05:56:09 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOBrs-0004ia-QO for psamp-archive@lists.ietf.org; Tue, 28 Mar 2006 05:56:09 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOBj8-000N2T-5g for psamp-data@psg.com; Tue, 28 Mar 2006 10:47:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOBj7-000N2H-KK for psamp@ops.ietf.org; Tue, 28 Mar 2006 10:47:05 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k2SAl3uV025106 for ; Tue, 28 Mar 2006 04:47:04 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Mar 2006 12:47:01 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509AA148A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: psamp@ops.ietf.org Subject: FW: [PSAMP] PSAMP mailing list is moving. Date: Tue, 28 Mar 2006 12:47:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 PSAMP WG members, You should all have received the below posting to our new (moved) WG mailing list. This is th last message to the psamp@ops.ietf.org Please use the new list from now on. I will be un-sub-scribing all of you from the old list, right after posting this message. You (should) have been sub-scribed to the new list by now (you have not gotten a subscribe message, but you should have seen the below posting to the new list by me). If you did not get the below message, then pls go to https://www1.ietf.org/mailman/listinfo/psamp and (re-)sub-scribe yourself to the new (and current) PSAMP WG mailing list. Bert -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Tuesday, March 28, 2006 11:57 To: psamp@ietf.org Cc: Juergen Quittek (E-mail) Subject: [PSAMP] PSAMP mailing list is moving. We are moving the WG mailing list from old: psamp@ops.ietf.org New: psamp@ietf.org All sub-scription have been moved to the new list as well. You list administrator is Juergen. If you get this message, pls start posting to the new email address. The old one is being dismantled as we speak. Bert _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From psamp-bounces@ietf.org Thu Mar 30 15:50:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP46H-0006s8-R8; Thu, 30 Mar 2006 15:50:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP46G-0006s3-MY for psamp@ietf.org; Thu, 30 Mar 2006 15:50:36 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP46G-0007QJ-2g for psamp@ietf.org; Thu, 30 Mar 2006 15:50:36 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2UKoZO26769; Thu, 30 Mar 2006 22:50:35 +0200 (CEST) Received: from [10.61.81.195] (ams-clip-vpn-dhcp4548.cisco.com [10.61.81.195]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2UKoUC04254; Thu, 30 Mar 2006 22:50:30 +0200 (CEST) Message-ID: <442C4496.5010200@cisco.com> Date: Thu, 30 Mar 2006 22:50:30 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Benoit Claise References: <44233D08.5080108@cisco.com> <200603240939.16597.Thomas.Dietz@netlab.nec.de> <442BF1B5.3020507@cisco.com> In-Reply-To: <442BF1B5.3020507@cisco.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: psamp@ietf.org, ipfix Subject: [PSAMP] Re: [ipfix] Re: Source ID -> Observation Domain Id? -> New Definition proposals X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0928019968==" Errors-To: psamp-bounces@ietf.org This is a multi-part message in MIME format. --===============0928019968== Content-Type: multipart/alternative; boundary="------------010900090802060008010502" This is a multi-part message in MIME format. --------------010900090802060008010502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id k2UKoZO26769 [re-posting to include the new psamp mailing list] Regards, Benoit. > Dear all, > > Considering also that we proposed to change the "Source ID" to "Observa= tion Domain ID", we have to change the two definitions (Observation Domai= n and Source ID) in all the IPFIX and PSAMP drafts. > > Here is the old "Observation Domain" definition > > An Observation Domain is the largest set of Observation Points for=20 > which Flow information can be aggregated by a Metering Process. =20 > Each Observation Domain presents itself using a unique ID to the=20 > Collecting Process to identify the IPFIX Messages it generates. For= =20 > example, a router line card may be an observation domain if it is=20 > composed of several interfaces, each of which is an Observation=20 > Point. Every Observation Point is associated with an Observation=20 > Domain.=20 > Here is the new "Observation Domain" proposal. > > An Observation Domain is the largest set of Observation Points fo= r > which Flow information can be aggregated by a Metering Process. > For example, a router line card may be an Observation Domain if i= t > is composed of several interfaces, each of which is an Observatio= n > Point. In the IPFIX Message it generates, the Observation Domain > includes its Observation Domain ID, which is a unique per=20 > Exporting Process. > That way, the Collecting Process can identify the specific=20 > Observation > Domain from the Exporter that sends the IPFIX Messages. Every > Observation Point is associated with an Observation Domain. > > Here is the old "Source ID" definition > Source ID=20 > A 32-bit identifier of the Observation Domain that is=20 > locally unique to the Exporting Process. The Exporting=20 > Process uses the Source ID to uniquely identify to the=20 > Collecting Process the Observation Domain that metered the=20 > Flows. Collecting Processes SHOULD use the combination the=20 > combination of the Exporter (exporterIPv4Address,=20 > exporterIPv6Address, or exportingProcessId) and the Source=20 > ID field to separate different export streams originating=20 > from the same Exporting Process. The Source ID SHOULD be 0=20 > when no specific Source ID is relevant for the entire IPFIX=20 > Message. For example, when exporting the Exporting Process=20 > Statistics, or in case of hierarchy of Collector when=20 > aggregated data records are exported. The Source ID MUST be= =20 > zero when the IPFIX Message contains data records with=20 > different Source ID values defined as scopes.=20 > Here is the new "Observation Domain ID" definition > A 32-bit identifier of the Observation Domain that is=20 > locally unique to the Exporting Process. The Exporting=20 > Process uses the Observation Domain ID to uniquely identify = to the=20 > Collecting Process the Observation Domain that metered the=20 > Flows. Collecting Processes SHOULD use the combination the=20 > combination of the Exporter (exporterIPv4Address,=20 > exporterIPv6Address, or exportingProcessId) and the Observat= ion > Domain ID field to separate different export streams origina= ting=20 > from the same Exporting Process. The Observation Domain ID = SHOULD be 0=20 > when no specific Observation Domain ID is relevant for the e= ntire IPFIX=20 > Message. For example, when exporting the Exporting Process=20 > Statistics, or in case of hierarchy of Collector when=20 > aggregated data records are exported. =20 > > The last sentence of the definition, on which Bert had also a comment, = has been removed from the definition: > =20 > > - sect 3.1 under SOurce ID > I do not understand the last sentence. WHat does it mean? > pls clarify in text. > > It's now part of the section "3.4.2.1 Scope". I agree that having this = sentence was not too clear, as the readers don't know the notion of scope= at this stage of the draft. > =20 > The Source ID MUST be=20 > zero when the IPFIX Message contains data records with=20 > different Source ID values defined as scopes.=20 > > Feedback? > Note: I will post the next version of the protocol draft by tomorrow, a= s agreed. > > Regards, Benoit. >> Benoit, >> >> I also agree. It makes things even clearer. >> >> Regards, Thomas >> >> Am Freitag, 24. M=E4rz 2006 01:27 schrieb Benoit Claise: >> =20 >>> Dear all, >>> >>> During his review, Bert was confused by the sourceId being the unique= Id >>> for the observation domain >>> >>> >>> - [IPFIX-ARCH] sect 5.4 last line >>> s/Source ID/Domain ID/ ?? >>> Or should the section title be somthing about "Source" ?? >>> I am getting a bit confused about DOmain and Source ID I guess? >>> Protocol doc does indeed speak about SOurce ID. >>> >>> I agree that this confusing, and should be changed. However, this mus= t be >>> changed in ALL IPFIX and PSAMP documents. Information model: sourceId= -> >>> observationDomainId >>> Protocol: Source ID -> Observation Domain ID >>> >>> Any objections before starting to change the documents? >>> >>> Regards, Benoit. >>> =20 > --------------010900090802060008010502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [re-posting to include the new psamp mailing list]

Regards, Benoit.
Dear all,

Considering also that we proposed to change the "Source ID" to "Observation Domain ID", we have to change the two definitions (Observation Domain and Source ID) in all the IPFIX and PSAMP drafts.

Here is the old "Observation Domain" definition

   An Observation Domain is the largest set of Observation Points for 
   which Flow information can be aggregated by a Metering Process.  
   Each Observation Domain presents itself using a unique ID to the 
   Collecting Process to identify the IPFIX Messages it generates.  For 
   example, a router line card may be an observation domain if it is 
   composed of several interfaces, each of which is an Observation 
   Point.  Every Observation Point is associated with an Observation 
   Domain.
Here is the new "Observation Domain" proposal.

      An Observation Domain is the largest set of Observation Points for
      which Flow information can be aggregated by a Metering Process.
      For example, a router line card may be an Observation Domain if it
      is composed of several interfaces, each of which is an Observation
      Point. In the IPFIX Message it generates, the Observation Domain
      includes its Observation Domain ID, which is a unique per Exporting Process.
      That way, the Collecting Process can identify the specific Observation
      Domain from the Exporter that sends the IPFIX Messages. Every
      Observation Point is associated with an Observation Domain. 

Here is the old "Source ID" definition
   Source ID 
           A 32-bit identifier of the Observation Domain that is 
           locally unique to the Exporting Process.  The Exporting 
           Process uses the Source ID to uniquely identify to the 
           Collecting Process the Observation Domain that metered the 
           Flows.  Collecting Processes SHOULD use the combination the 
           combination of the Exporter (exporterIPv4Address, 
           exporterIPv6Address, or exportingProcessId) and the Source 
           ID field to separate different export streams originating 
           from the same Exporting Process.  The Source ID SHOULD be 0 
           when no specific Source ID is relevant for the entire IPFIX 
           Message.  For example, when exporting the Exporting Process 
           Statistics, or in case of hierarchy of Collector when 
           aggregated data records are exported.  The Source ID MUST be 
           zero when the IPFIX Message contains data records with 
           different Source ID values defined as scopes. 
Here is the new "Observation Domain ID" definition
           A 32-bit identifier of the Observation Domain that is 
           locally unique to the Exporting Process.  The Exporting 
           Process uses the Observation Domain ID to uniquely identify to the 
           Collecting Process the Observation Domain that metered the 
           Flows.  Collecting Processes SHOULD use the combination the 
           combination of the Exporter (exporterIPv4Address, 
           exporterIPv6Address, or exportingProcessId) and the Observation
           Domain ID field to separate different export streams originating 
           from the same Exporting Process.  The Observation Domain ID SHOULD be 0 
           when no specific Observation Domain ID is relevant for the entire IPFIX 
           Message.  For example, when exporting the Exporting Process 
           Statistics, or in case of hierarchy of Collector when 
           aggregated data records are exported.  

The last sentence of the definition, on which Bert had also a comment, has been removed from the definition:
- sect 3.1 under SOurce ID
I do not understand the last sentence. WHat does it mean?
pls clarify in text.
It's now part of the section "3.4.2.1 Scope". I agree that having this sentence was not too clear, as the readers don't know the notion of scope at this stage of the draft.
 
           The Source ID MUST be 
           zero when the IPFIX Message contains data records with 
           different Source ID values defined as scopes. 

Feedback?
Note: I will post the next version of the protocol draft by tomorrow, as agreed.

Regards, Benoit.
Benoit,

I also agree. It makes things even clearer.

Regards, Thomas

Am Freitag, 24. März 2006 01:27 schrieb Benoit Claise:
  
Dear all,

During his review, Bert was confused by the sourceId being the unique Id
for the observation domain


	- [IPFIX-ARCH] sect 5.4 last line
	  s/Source ID/Domain ID/ ??
	  Or should the section title be somthing about "Source" ??
	  I am getting a bit confused about DOmain and Source ID I guess?
	  Protocol doc does indeed speak about SOurce ID.

I agree that this confusing, and should be changed. However, this must be
changed in ALL IPFIX and PSAMP documents. Information model: sourceId ->
observationDomainId
Protocol: Source ID -> Observation Domain ID

Any objections before starting to change the documents?

Regards, Benoit.


--------------010900090802060008010502-- --===============0928019968== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp --===============0928019968==-- From psamp-bounces@ietf.org Fri Mar 31 02:43:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPEIQ-0004NF-RB; Fri, 31 Mar 2006 02:43:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPEIQ-0004MP-E3 for psamp@ietf.org; Fri, 31 Mar 2006 02:43:50 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPEIK-0002SM-Qs for psamp@ietf.org; Fri, 31 Mar 2006 02:43:45 -0500 Received: from n-dietz.office (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 4AE0F1BAC4D; Fri, 31 Mar 2006 09:41:33 +0200 (CEST) From: Thomas Dietz To: Benoit Claise Date: Fri, 31 Mar 2006 09:43:36 +0200 User-Agent: KMail/1.9.1 References: <44233D08.5080108@cisco.com> <200603240939.16597.Thomas.Dietz@netlab.nec.de> <442BF1B5.3020507@cisco.com> In-Reply-To: <442BF1B5.3020507@cisco.com> Organization: Network Laboratories, NEC Europe Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603310943.37129.Thomas.Dietz@netlab.nec.de> X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: psamp , ipfix Subject: [PSAMP] Re: Source ID -> Observation Domain Id? -> New Definition proposals X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: psamp-bounces@ietf.org Dear Benoit, the text is fine. I just pointed at some wording issues inside. Regards, Thomas Am Donnerstag, 30. M=E4rz 2006 16:56 schrieb Benoit Claise: > Dear all, > > Considering also that we proposed to change the "Source ID" to "Observati= on > Domain ID", we have to change the two definitions (Observation Domain and > Source ID) in all the IPFIX and PSAMP drafts. > > Here is the old "Observation Domain" definition > > An Observation Domain is the largest set of Observation Points for > which Flow information can be aggregated by a Metering Process. > Each Observation Domain presents itself using a unique ID to the > Collecting Process to identify the IPFIX Messages it generates. For > example, a router line card may be an observation domain if it is > composed of several interfaces, each of which is an Observation > Point. Every Observation Point is associated with an Observation > Domain. > > Here is the new "Observation Domain" proposal. > > An Observation Domain is the largest set of Observation Points for > which Flow information can be aggregated by a Metering Process. > For example, a router line card may be an Observation Domain if it > is composed of several interfaces, each of which is an Observation > Point. In the IPFIX Message it generates, the Observation Domain > includes its Observation Domain ID, which is a unique per ^^^ is unique per > Exporting Process. > That way, the Collecting Process can identify the specific > Observation > Domain from the Exporter that sends the IPFIX Messages. Every > Observation Point is associated with an Observation Domain. > > Here is the old "Source ID" definition > > Source ID > A 32-bit identifier of the Observation Domain that is > locally unique to the Exporting Process. The Exporting > Process uses the Source ID to uniquely identify to the > Collecting Process the Observation Domain that metered the > Flows. Collecting Processes SHOULD use the combination the > combination of the Exporter (exporterIPv4Address, > exporterIPv6Address, or exportingProcessId) and the Source > ID field to separate different export streams originating > from the same Exporting Process. The Source ID SHOULD be 0 > when no specific Source ID is relevant for the entire IPFIX > Message. For example, when exporting the Exporting Process > Statistics, or in case of hierarchy of Collector when > aggregated data records are exported. The Source ID MUST be > zero when the IPFIX Message contains data records with > different Source ID values defined as scopes. > > Here is the new "Observation Domain ID" definition > A 32-bit identifier of the Observation Domain that is > locally unique to the Exporting Process. The Exporting > Process uses the Observation Domain ID to uniquely identify to > the Collecting Process the Observation Domain that metered the Flows.=20 > Collecting Processes SHOULD use the combination the combination of the ^^^^^^^^^^^^^^^^ delete once =20 > Exporter (exporterIPv4Address, > exporterIPv6Address, or exportingProcessId) and the Observation > Domain ID field to separate different export streams originati= ng > from the same Exporting Process. The Observation Domain ID > SHOULD be 0 when no specific Observation Domain ID is relevant for the > entire IPFIX Message. For example, when exporting the Exporting Process > Statistics, or in case of hierarchy of Collector when > aggregated data records are exported. > > The last sentence of the definition, on which Bert had also a comment, has > been removed from the definition: > > - sect 3.1 under SOurce ID > I do not understand the last sentence. WHat does it mean? > pls clarify in text. > > It's now part of the section "3.4.2.1 Scope". I agree that having this > sentence was not too clear, as the readers don't know the notion of scope > at this stage of the draft. > > The Source ID MUST be > zero when the IPFIX Message contains data records with > different Source ID values defined as scopes. > I guess you already changed "Source ID" to "Observation Domain ID" here... > Feedback? > Note: I will post the next version of the protocol draft by tomorrow, as > agreed. > > Regards, Benoit. > > > Benoit, > > > > I also agree. It makes things even clearer. > > > > Regards, Thomas > > > > Am Freitag, 24. M=E4rz 2006 01:27 schrieb Benoit Claise: > >> Dear all, > >> > >> During his review, Bert was confused by the sourceId being the unique = Id > >> for the observation domain > >> > >> > >> - [IPFIX-ARCH] sect 5.4 last line > >> s/Source ID/Domain ID/ ?? > >> Or should the section title be somthing about "Source" ?? > >> I am getting a bit confused about DOmain and Source ID I guess? > >> Protocol doc does indeed speak about SOurce ID. > >> > >> I agree that this confusing, and should be changed. However, this must > >> be changed in ALL IPFIX and PSAMP documents. Information model: source= Id > >> -> observationDomainId > >> Protocol: Source ID -> Observation Domain ID > >> > >> Any objections before starting to change the documents? > >> > >> Regards, Benoit. =2D-=20 Thomas Dietz Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Fri Mar 31 02:48:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPENB-0006tr-8J; Fri, 31 Mar 2006 02:48:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPEN8-0006tR-Uw for psamp@ietf.org; Fri, 31 Mar 2006 02:48:42 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPEN8-0002fh-9I for psamp@ietf.org; Fri, 31 Mar 2006 02:48:42 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2V7mat06353; Fri, 31 Mar 2006 09:48:36 +0200 (CEST) Received: from [144.254.7.92] (dhcp-peg3-vl30-144-254-7-92.cisco.com [144.254.7.92]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2V7mZC07480; Fri, 31 Mar 2006 09:48:35 +0200 (CEST) Message-ID: <442CDED2.5040702@cisco.com> Date: Fri, 31 Mar 2006 09:48:34 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Thomas Dietz References: <44233D08.5080108@cisco.com> <200603240939.16597.Thomas.Dietz@netlab.nec.de> <442BF1B5.3020507@cisco.com> <200603310943.37129.Thomas.Dietz@netlab.nec.de> In-Reply-To: <200603310943.37129.Thomas.Dietz@netlab.nec.de> X-Spam-Score: 0.5 (/) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae Cc: psamp , ipfix Subject: [PSAMP] Re: Source ID -> Observation Domain Id? -> New Definition proposals X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1567024372==" Errors-To: psamp-bounces@ietf.org This is a multi-part message in MIME format. --===============1567024372== Content-Type: multipart/alternative; boundary="------------020308020205050106000803" This is a multi-part message in MIME format. --------------020308020205050106000803 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id k2V7mat06353 Thanks Thomas, Corrected. Regards, Benoit. > Dear Benoit, > > the text is fine. I just pointed at some wording issues inside. > > Regards, > > Thomas > > Am Donnerstag, 30. M=E4rz 2006 16:56 schrieb Benoit Claise: > =20 >> Dear all, >> >> Considering also that we proposed to change the "Source ID" to "Observ= ation >> Domain ID", we have to change the two definitions (Observation Domain = and >> Source ID) in all the IPFIX and PSAMP drafts. >> >> Here is the old "Observation Domain" definition >> >> An Observation Domain is the largest set of Observation Points for >> which Flow information can be aggregated by a Metering Process. >> Each Observation Domain presents itself using a unique ID to the >> Collecting Process to identify the IPFIX Messages it generates. Fo= r >> example, a router line card may be an observation domain if it is >> composed of several interfaces, each of which is an Observation >> Point. Every Observation Point is associated with an Observation >> Domain. >> >> Here is the new "Observation Domain" proposal. >> >> An Observation Domain is the largest set of Observation Points f= or >> which Flow information can be aggregated by a Metering Process. >> For example, a router line card may be an Observation Domain if = it >> is composed of several interfaces, each of which is an Observati= on >> Point. In the IPFIX Message it generates, the Observation Domain >> includes its Observation Domain ID, which is a unique per >> =20 > ^^^ is unique per > > =20 >> Exporting Process. >> That way, the Collecting Process can identify the specific >> Observation >> Domain from the Exporter that sends the IPFIX Messages. Every >> Observation Point is associated with an Observation Domain. >> >> Here is the old "Source ID" definition >> >> Source ID >> A 32-bit identifier of the Observation Domain that is >> locally unique to the Exporting Process. The Exporting >> Process uses the Source ID to uniquely identify to the >> Collecting Process the Observation Domain that metered the >> Flows. Collecting Processes SHOULD use the combination the >> combination of the Exporter (exporterIPv4Address, >> exporterIPv6Address, or exportingProcessId) and the Source >> ID field to separate different export streams originating >> from the same Exporting Process. The Source ID SHOULD be 0 >> when no specific Source ID is relevant for the entire IPFIX >> Message. For example, when exporting the Exporting Process >> Statistics, or in case of hierarchy of Collector when >> aggregated data records are exported. The Source ID MUST b= e >> zero when the IPFIX Message contains data records with >> different Source ID values defined as scopes. >> >> Here is the new "Observation Domain ID" definition >> A 32-bit identifier of the Observation Domain that is >> locally unique to the Exporting Process. The Exporting >> Process uses the Observation Domain ID to uniquely identify= to >> the Collecting Process the Observation Domain that metered the Flows.=20 >> Collecting Processes SHOULD use the combination the combination of the >> =20 > ^^^^^^^^^^^^^^^^ delete once =20 > > =20 >> Exporter (exporterIPv4Address, >> exporterIPv6Address, or exportingProcessId) and the Observa= tion >> Domain ID field to separate different export streams origin= ating >> from the same Exporting Process. The Observation Domain ID >> SHOULD be 0 when no specific Observation Domain ID is relevant for the >> entire IPFIX Message. For example, when exporting the Exporting Proce= ss >> Statistics, or in case of hierarchy of Collector when >> aggregated data records are exported. >> >> The last sentence of the definition, on which Bert had also a comment,= has >> been removed from the definition: >> >> - sect 3.1 under SOurce ID >> I do not understand the last sentence. WHat does it mean? >> pls clarify in text. >> >> It's now part of the section "3.4.2.1 Scope". I agree that having this >> sentence was not too clear, as the readers don't know the notion of sc= ope >> at this stage of the draft. >> >> The Source ID MUST be >> zero when the IPFIX Message contains data records with >> different Source ID values defined as scopes. >> >> =20 > > I guess you already changed "Source ID" to "Observation Domain ID" here= ... > > =20 >> Feedback? >> Note: I will post the next version of the protocol draft by tomorrow, = as >> agreed. >> >> Regards, Benoit. >> >> =20 >>> Benoit, >>> >>> I also agree. It makes things even clearer. >>> >>> Regards, Thomas >>> >>> Am Freitag, 24. M=E4rz 2006 01:27 schrieb Benoit Claise: >>> =20 >>>> Dear all, >>>> >>>> During his review, Bert was confused by the sourceId being the uniqu= e Id >>>> for the observation domain >>>> >>>> >>>> - [IPFIX-ARCH] sect 5.4 last line >>>> s/Source ID/Domain ID/ ?? >>>> Or should the section title be somthing about "Source" ?? >>>> I am getting a bit confused about DOmain and Source ID I guess? >>>> Protocol doc does indeed speak about SOurce ID. >>>> >>>> I agree that this confusing, and should be changed. However, this mu= st >>>> be changed in ALL IPFIX and PSAMP documents. Information model: sour= ceId >>>> -> observationDomainId >>>> Protocol: Source ID -> Observation Domain ID >>>> >>>> Any objections before starting to change the documents? >>>> >>>> Regards, Benoit. >>>> =20 > > =20 --------------020308020205050106000803 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id k2V7mat06353 Thanks Thomas,

Corrected.

Regards, Benoit.
Dear Benoit,

the text is fine. I just pointed at some wording issues inside.

Regards,

Thomas

Am Donnerstag, 30. M=E4rz 2006 16:56 schrieb Benoit Claise:
  
Dear all,

Considering also that we proposed to change the "Source ID" to "Observati=
on
Domain ID", we have to change the two definitions (Observation Domain and
Source ID) in all the IPFIX and PSAMP drafts.

Here is the old "Observation Domain" definition

   An Observation Domain is the largest set of Observation Points for
   which Flow information can be aggregated by a Metering Process.
   Each Observation Domain presents itself using a unique ID to the
   Collecting Process to identify the IPFIX Messages it generates.  For
   example, a router line card may be an observation domain if it is
   composed of several interfaces, each of which is an Observation
   Point.  Every Observation Point is associated with an Observation
   Domain.

Here is the new "Observation Domain" proposal.

      An Observation Domain is the largest set of Observation Points for
      which Flow information can be aggregated by a Metering Process.
      For example, a router line card may be an Observation Domain if it
      is composed of several interfaces, each of which is an Observation
      Point. In the IPFIX Message it generates, the Observation Domain
      includes its Observation Domain ID, which is a unique per
    
                                                 =
   ^^^ is unique per

  
Exporting Process.
      That way, the Collecting Process can identify the specific
Observation
      Domain from the Exporter that sends the IPFIX Messages. Every
      Observation Point is associated with an Observation Domain.

Here is the old "Source ID" definition

   Source ID
           A 32-bit identifier of the Observation Domain that is
           locally unique to the Exporting Process.  The Exporting
           Process uses the Source ID to uniquely identify to the
           Collecting Process the Observation Domain that metered the
           Flows.  Collecting Processes SHOULD use the combination the
           combination of the Exporter (exporterIPv4Address,
           exporterIPv6Address, or exportingProcessId) and the Source
           ID field to separate different export streams originating
           from the same Exporting Process.  The Source ID SHOULD be 0
           when no specific Source ID is relevant for the entire IPFIX
           Message.  For example, when exporting the Exporting Process
           Statistics, or in case of hierarchy of Collector when
           aggregated data records are exported.  The Source ID MUST be
           zero when the IPFIX Message contains data records with
           different Source ID values defined as scopes.

Here is the new "Observation Domain ID" definition
           A 32-bit identifier of the Observation Domain that is
           locally unique to the Exporting Process.  The Exporting
           Process uses the Observation Domain ID to uniquely identify to
the Collecting Process the Observation Domain that metered the Flows.=20
Collecting Processes SHOULD use the combination the combination of the
    
                                  ^^^^^^^^^^^^^^^=
^ delete once  =20

  
Exporter (exporterIPv4Address,
           exporterIPv6Address, or exportingProcessId) and the Observatio=
n
           Domain ID field to separate different export streams originati=
ng
           from the same Exporting Process.  The Observation Domain ID
SHOULD be 0 when no specific Observation Domain ID is relevant for the
entire IPFIX Message.  For example, when exporting the Exporting Process
Statistics, or in case of hierarchy of Collector when
           aggregated data records are exported.

The last sentence of the definition, on which Bert had also a comment, ha=
s
been removed from the definition:

    - sect 3.1 under SOurce ID
    I do not understand the last sentence. WHat does it mean?
    pls clarify in text.

It's now part of the section "3.4.2.1 Scope". I agree that having this
sentence was not too clear, as the readers don't know the notion of scope
at this stage of the draft.

           The Source ID MUST be
           zero when the IPFIX Message contains data records with
           different Source ID values defined as scopes.

    

I guess you already changed "Source ID" to "Observation Domain ID" here...

  
Feedback?
Note: I will post the next version of the protocol draft by tomorrow, as
agreed.

Regards, Benoit.

    
Benoit,

I also agree. It makes things even clearer.

Regards, Thomas

Am Freitag, 24. M=E4rz 2006 01:27 schrieb Benoit Claise:
      
Dear all,

During his review, Bert was confused by the sourceId being the unique Id
for the observation domain


	- [IPFIX-ARCH] sect 5.4 last line
	  s/Source ID/Domain ID/ ??
	  Or should the section title be somthing about "Source" ??
	  I am getting a bit confused about DOmain and Source ID I guess?
	  Protocol doc does indeed speak about SOurce ID.

I agree that this confusing, and should be changed. However, this must
be changed in ALL IPFIX and PSAMP documents. Information model: sourceId
-> observationDomainId
Protocol: Source ID -> Observation Domain ID

Any objections before starting to change the documents?

Regards, Benoit.

--------------020308020205050106000803-- --===============1567024372== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp --===============1567024372==--