From majordomo@mil.doit.wisc.edu Wed Mar 01 18:29:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEaks-00079X-I4 for ipfix-archive@lists.ietf.org; Wed, 01 Mar 2006 18:29:14 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEakr-0003y3-6t for ipfix-archive@lists.ietf.org; Wed, 01 Mar 2006 18:29:14 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FEaUo-0003XY-00 for ipfix-list@mil.doit.wisc.edu; Wed, 01 Mar 2006 17:12:38 -0600 Received: from beniaminus.red.cert.org ([192.88.209.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FEaUm-0003XT-00 for ipfix@net.doit.wisc.edu; Wed, 01 Mar 2006 17:12:37 -0600 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.18) with ESMTP id k21NCZSZ012410 for ; Wed, 1 Mar 2006 18:12:35 -0500 Received: from [10.11.57.191] (vpn-10-25-4-9.remote.cert.org [10.25.4.9]) by villemus.indigo.cert.org (8.12.11/8.12.11/2.55) with ESMTP id k21NCYYg008111 for ; Wed, 1 Mar 2006 18:12:34 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--261205928" To: ipfix@net.doit.wisc.edu From: Brian Trammell Subject: [ipfix] Message Source ID and template scoping Date: Thu, 2 Mar 2006 00:12:30 +0100 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 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Status: O This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1--261205928 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Greetings, In reviewing IPFIX-PROTO 19 during the interoperability event in Salzburg, I noticed what I believe to be an inconsistency in the definition of the Source ID message header field and the sourceId information element, and how these interact with template management. The relevant language: (from 3.1, p. 13) 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. (from 3.4.1, p. 18) Template ID Each of the newly generated Template Records is given a unique Template ID. This uniqueness is local to the Observation Domain that generated the Template ID. Template IDs 0-255 are reserved for Template Sets, Options Template Sets, and other reserved Sets yet to be created. Template IDs of Data Sets are numbered from 256 to 65535. There are no constraints regarding the order of the Template ID allocation. First, there's a typographical error (that may already be corrected in the working draft; I'm not sure) in the Source ID definition; on line 4: "the Collecting Process the Observation Domain" - should be "the Observation Domain". These two paragraphs would seem to imply that the preferred way for Collecting Processes to manage templates is by (Source ID, Template ID) tuple (since Source ID is the observation domain identifier). However, this will lead to issues during aggregation, during which a single IPFIX Message may contain multiple Flow Records with different Source IDs (via Options Records or via the sourceId IE on each Flow Record). In this case, every _record_ is still scoped to a Source ID, but the templates no longer are. An exporter then has no way to ensure Template IDs associated with records from multiple upstream Observation Domains will not collide, and a collector accepting Source ID = 0 messages from multiple exporters may also run into Template ID collision problems. One way around this on the _collector_ side would be to manage templates by (Source ID, exporter (IPv(4,6)Address,ProcessId), Template ID) tuples, but this places further burdens on the collector to determine when two different Template IDs really are the same. I would suggest instead that the Source ID of 0 be reserved* (using SHOULD NOT language); that _every_ IPFIX Message should have a valid (non-zero) Source ID; and that the source ID of a record is defined at the most specific of the enclosing message's Source ID, any Source ID attached to the record by an Options Record, then any Source ID attached directly to the record (via the sourceId IE). The suggested new language is as follows: 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 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 NOT 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 SHOULD identify the default Observation Domain for the Exporting Process, or a virtual Observation Domain containing only the Exporting Process. The Source ID of each record MUST be taken to be the most specific Source ID applicable to the record. * This is really something of an implementation convenience; it allows implementations which use IPFIX templates internally for record encoding and decoding to scope internal templates - those which will never leave the Process - by the (0, Template ID) source/ template tuple. Thoughts? - Brian --Apple-Mail-1--261205928 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) iD8DBQFEBipj4/8LCZ4pwvYRAvAFAKCM5NKgCKzhE0GkrqVbP0Ilt3xZIgCg6OG0 P3MgvppAheHrGpnPu7gMYAg= =036e -----END PGP SIGNATURE----- --Apple-Mail-1--261205928-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 02 04:35:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEkDt-0001W2-2H for ipfix-archive@lists.ietf.org; Thu, 02 Mar 2006 04:35:49 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEkDr-0005nI-Kv for ipfix-archive@lists.ietf.org; Thu, 02 Mar 2006 04:35:49 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FEjyj-00010g-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 Mar 2006 03:20:09 -0600 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FEjyh-00010Z-00 for ipfix@net.doit.wisc.edu; Thu, 02 Mar 2006 03:20:07 -0600 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id CBB04120 for ; Thu, 2 Mar 2006 10:20:05 +0100 (NFT) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12608-01 for ; Thu, 2 Mar 2006 10:19:58 +0100 (NFT) Received: from [127.0.0.1] (c64.informatik.uni-tuebingen.de [134.2.168.129]) by mx5.informatik.uni-tuebingen.de (Postfix) with SMTP id AF3D911C for ; Thu, 2 Mar 2006 10:19:57 +0100 (NFT) Message-ID: <4406B8A9.4060101@informatik.uni-tuebingen.de> Date: Thu, 02 Mar 2006 10:19:37 +0100 From: Gerhard Muenz User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Message Source ID and template scoping References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050407060809080104090407" X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Status: O This is a cryptographically signed message in MIME format. --------------ms050407060809080104090407 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Brian, all, I agree with your suggestion. In my opinion, the Source ID should identify the Exporting Process and every IPFIX messages sent by this Exporting Process has to contain its Source ID. This is important for the collector in order to associate the right Template(s). Thus, the collector can manage the Templates based on the Source IDs only. In case of a concentrator, the used Source ID would be the Source ID of the Exporting Process within the concentrator. If you want to keep the information about the original exporters, you can put this information into the individual flow records or option records using the exportingProcessId, exporterIPv6Address or exporterIPv4Address. If a device runs more than one Exporting Processes, than it would use a different Source ID for each. If we really need to export statistics that are not specific to any Exporting Processes of a device, we could do as Brian suggests: assign another Source ID to the device that is exclusively used for that purpose. Btw, I do not understand the following sentence in the definition of Source ID: "The Exporting Process uses the Source ID to uniquely identify to the Collecting Process that metered the Flows." Does a Collecting Process meter flows? Regards, Gerhard Brian Trammell wrote: > Greetings, >=20 > In reviewing IPFIX-PROTO 19 during the interoperability event in > Salzburg, I noticed what I believe to be an inconsistency in the > definition of the Source ID message header field and the sourceId > information element, and how these interact with template management. > The relevant language: >=20 > (from 3.1, p. 13) > 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. >=20 > (from 3.4.1, p. 18) > Template ID > Each of the newly generated Template Records is given a unique > Template ID. This uniqueness is local to the Observation > Domain that generated the Template ID. Template IDs 0-255 are > reserved for Template Sets, Options Template Sets, and other > reserved Sets yet to be created. Template IDs of Data Sets > are numbered from 256 to 65535. There are no constraints > regarding the order of the Template ID allocation. >=20 > First, there's a typographical error (that may already be corrected in > the working draft; I'm not sure) in the Source ID definition; on line 4= : > "the Collecting Process the Observation Domain" - should be "the > Observation Domain". >=20 > These two paragraphs would seem to imply that the preferred way for > Collecting Processes to manage templates is by (Source ID, Template ID) > tuple (since Source ID is the observation domain identifier). However, > this will lead to issues during aggregation, during which a single IPFI= X > Message may contain multiple Flow Records with different Source IDs (vi= a > Options Records or via the sourceId IE on each Flow Record). In this > case, every _record_ is still scoped to a Source ID, but the templates > no longer are. An exporter then has no way to ensure Template IDs > associated with records from multiple upstream Observation Domains will > not collide, and a collector accepting Source ID =3D 0 messages from > multiple exporters may also run into Template ID collision problems. On= e > way around this on the _collector_ side would be to manage templates by > (Source ID, exporter(IPv(4,6)Address,ProcessId), Template ID) tuples, > but this places further burdens on the collector to determine when two > different Template IDs really are the same. >=20 > I would suggest instead that the Source ID of 0 be reserved* (using > SHOULD NOT language); that _every_ IPFIX Message should have a valid > (non-zero) Source ID; and that the source ID of a record is defined at > the most specific of the enclosing message's Source ID, any Source ID > attached to the record by an Options Record, then any Source ID attache= d > directly to the record (via the sourceId IE). >=20 > The suggested new language is as follows: >=20 > 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 that metered the Flows. Collecting Proce= sses > 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. >=20 > The Source ID SHOULD NOT 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 SHOULD > identify the default Observation Domain for the Exporting > Process, > or a virtual Observation Domain containing only the Exporting > Process. > The Source ID of each record MUST be taken to be the most > specific > Source ID applicable to the record. >=20 >=20 > * This is really something of an implementation convenience; it allows > implementations which use IPFIX templates internally for record encodin= g > and decoding to scope internal templates - those which will never leave > the Process - by the (0, Template ID) source/template tuple. >=20 > Thoughts? >=20 > - Brian >=20 --=20 Dipl.-Ing. Gerhard M=FCnz 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 --------------ms050407060809080104090407 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 HAYJKoZIhvcNAQkFMQ8XDTA2MDMwMjA5MTkzN1owIwYJKoZIhvcNAQkEMRYEFPrO2vFOx4BX qxJf3hYFtbn65QQ8MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ Wed3TO1yHz8UpnINThpgzzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQWed3TO1yHz8UpnINThpgzzANBgkqhkiG 9w0BAQEFAASCAQCXw3NnelHv5vOBwntBDT4hdF40j2aK68FIAPysHYIQQcWKm5rm6A/cAeLX rYk6HN/ssR5fF+NKPwt0y8oB327crVR1UqncL72JUSvyxz8JC725JBvgkdRVBwWVoJfBjpkh QvTklpkIY6ClkvYE61qSqA0wtRTA3x7ET2xHLc/lv8kOGjQiFxHIUZOU+X1RPdZ43zUitsLT 3wBJSgnztdAINxE6md5jQJJAd6czrGTvENAX2K10asdIlncetpBBUYMerpy2WxE00zBttCzn fhoDQEa7HVy/SShsXOv7CjEtJD0ASyDr2Csvkp0CloxBi+IeckWs/BUyPdX8Rd3wbHN/AAAA AAAA --------------ms050407060809080104090407-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 02 22:30:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF0za-0003YS-Nh for ipfix-archive@lists.ietf.org; Thu, 02 Mar 2006 22:30:10 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF0za-0007xk-Lk for ipfix-archive@lists.ietf.org; Thu, 02 Mar 2006 22:30:10 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FF0zZ-0007gF-2K for ipfix-archive@lists.ietf.org; Thu, 02 Mar 2006 22:30:10 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FF0eI-0000pi-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 Mar 2006 21:08:10 -0600 Received: from franclinus.red.cert.org ([192.88.209.16]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FF0eH-0000pZ-00 for ipfix@net.doit.wisc.edu; Thu, 02 Mar 2006 21:08:09 -0600 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.18) with ESMTP id k23387l0020481 for ; Thu, 2 Mar 2006 22:08:08 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k2336eb4020432 for ; Thu, 2 Mar 2006 22:06:40 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k2336dZ3020430; Thu, 02 Mar 2006 22:06:40 -0500 (EST) Received: from [10.11.57.191] (vpn-10-25-4-14.remote.cert.org [10.25.4.14]) by villemus.indigo.cert.org (8.12.11/8.12.11/2.55) with ESMTP id k2336c2o007519; Thu, 2 Mar 2006 22:06:39 -0500 In-Reply-To: <4406B8A9.4060101@informatik.uni-tuebingen.de> References: <4406B8A9.4060101@informatik.uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--160759468" Message-Id: <2D72A377-3A64-4C57-9C8D-731268939C18@cert.org> Cc: ipfix@net.doit.wisc.edu Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix] Message Source ID and template scoping Date: Fri, 3 Mar 2006 04:06:37 +0100 To: Gerhard Muenz X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000004 X-Scanned-By: MIMEDefang 2.54 on 192.88.209.16 Precedence: bulk Sender: majordomo listserver X-Spam-Score: -2.6 (--) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Status: O This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1--160759468 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Mar 2, 2006, at 10:19 AM, Gerhard Muenz wrote: > Btw, I do not understand the following sentence in the definition of > Source ID: > "The Exporting Process uses the Source ID to uniquely identify to the > Collecting Process that metered the Flows." > Does a Collecting Process meter flows? Nope - that was a typo. "the Collecting Process the Observation Domain that metered the flows" is in the original definition, and I deleted the wrong three words. The passage should read "The Exporting Process uses the Source ID to uniquely identify to the Observation Domain that metered the Flows." Thanks, Brian --Apple-Mail-1--160759468 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) iD8DBQFEB7LB4/8LCZ4pwvYRAhFrAJ9LqLC3eJHQJphcdz6iS7waYsGzWACePKHB u4cAJz5Um6iVmWlV9P0aExc= =rSia -----END PGP SIGNATURE----- --Apple-Mail-1--160759468-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 03 06:52:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF8pG-0001Y4-W2 for ipfix-archive@lists.ietf.org; Fri, 03 Mar 2006 06:52:02 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF8pF-000151-Oe for ipfix-archive@lists.ietf.org; Fri, 03 Mar 2006 06:52:02 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FF8bg-0006Pr-00 for ipfix-list@mil.doit.wisc.edu; Fri, 03 Mar 2006 05:38:00 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FF8be-0006Ox-00 for ipfix-info@net.doit.wisc.edu; Fri, 03 Mar 2006 05:37:59 -0600 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-info] IPFIX and PSMAP information model: applicability field Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 03 08:18:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFABD-00045O-IJ for ipfix-archive@lists.ietf.org; Fri, 03 Mar 2006 08:18:47 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFABC-0004qJ-9x for ipfix-archive@lists.ietf.org; Fri, 03 Mar 2006 08:18:47 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FF9vE-0000xC-00 for ipfix-list@mil.doit.wisc.edu; Fri, 03 Mar 2006 07:02:16 -0600 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FF9vD-0000x1-00 for ipfix-info@net.doit.wisc.edu; Fri, 03 Mar 2006 07:02:15 -0600 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: [ipfix-info] 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 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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: -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 03 08:20:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFADK-0008EP-Db for ipfix-archive@lists.ietf.org; Fri, 03 Mar 2006 08:20:58 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFADK-0004uP-4S for ipfix-archive@lists.ietf.org; Fri, 03 Mar 2006 08:20:58 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FF9yj-000159-00 for ipfix-list@mil.doit.wisc.edu; Fri, 03 Mar 2006 07:05:53 -0600 Received: from faui70.informatik.uni-erlangen.de ([131.188.37.37]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FF9yi-000154-00 for ipfix-info@net.doit.wisc.edu; Fri, 03 Mar 2006 07:05:52 -0600 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: [ipfix-info] 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 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 03 10:12:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBwt-0007dN-Gy for ipfix-archive@lists.ietf.org; Fri, 03 Mar 2006 10:12:07 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFBwt-0000JN-7T for ipfix-archive@lists.ietf.org; Fri, 03 Mar 2006 10:12:07 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FFBnJ-0005u8-00 for ipfix-list@mil.doit.wisc.edu; Fri, 03 Mar 2006 09:02:13 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FFBnI-0005tw-00 for ipfix-info@net.doit.wisc.edu; Fri, 03 Mar 2006 09:02:12 -0600 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: [ipfix-info] 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" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From wigginsochyna@gauloises.com Fri Mar 03 19:21:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFKWE-0004zV-NL for ipfix-archive@lists.ietf.org; Fri, 03 Mar 2006 19:21:10 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFKWD-00084D-Eg for ipfix-archive@lists.ietf.org; Fri, 03 Mar 2006 19:21:10 -0500 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FFK4Y-0005eh-00 for ipfix-list@mil.doit.wisc.edu; Fri, 03 Mar 2006 17:52:34 -0600 Received: from gauloises.com (81-202-51-78.user.ono.com [81.202.51.78]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k23NqVGR030745 for ; Fri, 3 Mar 2006 17:52:32 -0600 Message-ID: <000001c63f1d$7cc562f0$2db2a8c0@vvp74> Reply-To: "Chyna Wiggins" From: "Chyna Wiggins" To: ipfix-list@mil.doit.wisc.edu Subject: car etaker news Date: Fri, 3 Mar 2006 18:52:10 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C63EF3.93EF5AF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Status: O This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C63EF3.93EF5AF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 vSeauvwee eobvleurr g5t0z%i xwwiztch http://www.arentany.com =20 dVtltAxGzRyA rCwllAaLzIcS fVwAaLiIeUzM ------=_NextPart_000_0001_01C63EF3.93EF5AF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
eauvwee bvleurr t0z%i xwztch
 
tltAxGzRwllAaLzIwAaLiIeU Collecting Process that metered the Flows." > Does a Collecting Process meter flows? > > Regards, > Gerhard > > > Brian Trammell wrote: >> Greetings, >> >> In reviewing IPFIX-PROTO 19 during the interoperability event in >> Salzburg, I noticed what I believe to be an inconsistency in the >> definition of the Source ID message header field and the sourceId >> information element, and how these interact with template management. >> The relevant language: >> >> (from 3.1, p. 13) >> 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. >> >> (from 3.4.1, p. 18) >> Template ID >> Each of the newly generated Template Records is given a unique >> Template ID. This uniqueness is local to the Observation >> Domain that generated the Template ID. Template IDs 0-255 are >> reserved for Template Sets, Options Template Sets, and other >> reserved Sets yet to be created. Template IDs of Data Sets >> are numbered from 256 to 65535. There are no constraints >> regarding the order of the Template ID allocation. >> >> First, there's a typographical error (that may already be corrected in >> the working draft; I'm not sure) in the Source ID definition; on line 4: >> "the Collecting Process the Observation Domain" - should be "the >> Observation Domain". >> >> These two paragraphs would seem to imply that the preferred way for >> Collecting Processes to manage templates is by (Source ID, Template ID) >> tuple (since Source ID is the observation domain identifier). However, >> this will lead to issues during aggregation, during which a single IPFIX >> Message may contain multiple Flow Records with different Source IDs (via >> Options Records or via the sourceId IE on each Flow Record). In this >> case, every _record_ is still scoped to a Source ID, but the templates >> no longer are. An exporter then has no way to ensure Template IDs >> associated with records from multiple upstream Observation Domains will >> not collide, and a collector accepting Source ID = 0 messages from >> multiple exporters may also run into Template ID collision problems. One >> way around this on the _collector_ side would be to manage templates by >> (Source ID, exporter(IPv(4,6)Address,ProcessId), Template ID) tuples, >> but this places further burdens on the collector to determine when two >> different Template IDs really are the same. >> >> I would suggest instead that the Source ID of 0 be reserved* (using >> SHOULD NOT language); that _every_ IPFIX Message should have a valid >> (non-zero) Source ID; and that the source ID of a record is defined at >> the most specific of the enclosing message's Source ID, any Source ID >> attached to the record by an Options Record, then any Source ID attached >> directly to the record (via the sourceId IE). >> >> The suggested new language is as follows: >> >> 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 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 NOT 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 SHOULD >> identify the default Observation Domain for the Exporting >> Process, >> or a virtual Observation Domain containing only the Exporting >> Process. >> The Source ID of each record MUST be taken to be the most >> specific >> Source ID applicable to the record. >> >> >> * This is really something of an implementation convenience; it allows >> implementations which use IPFIX templates internally for record encoding >> and decoding to scope internal templates - those which will never leave >> the Process - by the (0, Template ID) source/template tuple. >> >> Thoughts? >> >> - Brian >> > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From kostasdr@server25.hostpoint.ch Sun Mar 05 01:56:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFnAM-0002qs-PQ for ipfix-archive@lists.ietf.org; Sun, 05 Mar 2006 01:56:30 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFnAD-0006JK-FT for ipfix-archive@lists.ietf.org; Sun, 05 Mar 2006 01:56:25 -0500 Received: from server25.hostpoint.ch ([217.26.52.35]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FFmrN-0002mJ-00 for ipfix-list@mil.doit.wisc.edu; Sun, 05 Mar 2006 00:36:53 -0600 Received: from kostasdr by server25.hostpoint.ch with local (Exim 4.54 (FreeBSD)) id 1FFmrQ-000BkF-LR for ipfix-list@mil.doit.wisc.edu; Sun, 05 Mar 2006 07:36:56 +0100 To: ipfix-list@mil.doit.wisc.edu Subject: 6wa1sxkyGood money From: supas2p5h3qport@allianzcorp.biz X-Mailer: PHPMail Tool Mime-Version: 1.0 Content-Type:multipart/mixed;boundary="----------1141540616440A87089709E" Message-Id: Date: Sun, 05 Mar 2006 07:36:56 +0100 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server25.hostpoint.ch X-AntiAbuse: Original Domain - mil.doit.wisc.edu X-AntiAbuse: Originator/Caller UID/GID - [12535 12535] / [26 6] X-AntiAbuse: Sender Address Domain - server25.hostpoint.ch X-Spam-Score: 4.9 (++++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Status: O ------------1141540616440A87089709E Content-Type:text/html;charset="windows-1251" Content-Transfer-Encoding: 8bit No title

Good day dear user. Do not be afraid this letter is not a spam. We found

your e-mail on employment web-site: www.jobzone.co.nz

We (Allianz Finance LLC) would like to offer you a position of financial

manager at home. We need reliable and honest people with basic accounting

and Microsoft Office skills for this positions. This is part-time home-based

work which doesn't require any professional skills  or previous work

experience. If you want to apply of have any questions about position

offered please do not hesitate to visit our web-site which is

http://www.allianzcorp.biz or send your CV to manager@allianzcorp.biz and we

will send you invitation pack and job description. You are able to make up

to 800 dollars a week being busy only 1 hour in the morning. Can we make

it? Yes we can. Thank you for your time.

 

Alex Suttelman,

Project manager,

New Zealand/Australia division,

Allianz Finance LLC,

manager@allianzcorp.biz

http://www.allianzcorp.biz

TEL/FAX: +44-87-0912-7525

------------1141540616440A87089709E Content-Type: image/jpeg;name="wpcxxppptest.txt" Content-Transfer-Encoding:base64 Content-ID: From majordomo@mil.doit.wisc.edu Sun Mar 05 04:11:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFpHG-0006Hd-Ru for ipfix-archive@lists.ietf.org; Sun, 05 Mar 2006 04:11:46 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFpHF-0001v5-Hf for ipfix-archive@lists.ietf.org; Sun, 05 Mar 2006 04:11:46 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FFpCe-0002is-00 for ipfix-list@mil.doit.wisc.edu; Sun, 05 Mar 2006 03:07:00 -0600 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FFpCc-0002ig-00 for ipfix@net.doit.wisc.edu; Sun, 05 Mar 2006 03:06:58 -0600 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3384011C for ; Sun, 5 Mar 2006 10:06:57 +0100 (NFT) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12736-04 for ; Sun, 5 Mar 2006 10:06:54 +0100 (NFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 9F4DF115 for ; Sun, 5 Mar 2006 10:06:53 +0100 (NFT) Message-ID: <440AAA18.4070202@informatik.uni-tuebingen.de> Date: Sun, 05 Mar 2006 10:06:32 +0100 From: Gerhard Muenz User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Message Source ID and template scoping References: <4406B8A9.4060101@informatik.uni-tuebingen.de> <4408E2DB.7040807@cisco.com> In-Reply-To: <4408E2DB.7040807@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070406080900070703010907" X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Status: O This is a cryptographically signed message in MIME format. --------------ms070406080900070703010907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Andrew, Andrew Johnson wrote: > Gerhard Muenz wrote: >> In my opinion, the Source ID should identify the Exporting Process and >> every IPFIX messages sent by this Exporting Process has to contain its >> Source ID. This is important for the collector in order to associate t= he >> right Template(s). Thus, the collector can manage the Templates based = on >> the Source IDs only. >=20 > While that would be convenient, it would only work if all Exporting > Processes communicating with a single Collecting Process had different > Source IDs. Since, in the majority of cases, different Exporting Proce= ss > will reside in different parts of the network and not communicate with > each other, this can never be guaranteed, which is why the use of the > source adress is essential. Thanks for the clarification. I reread the current definition of observation domains in IPFIX and it actually requires the (exporterIP, sourceID)-tuple to identify an Exporting Process. However, as you stated, the other option (unique sourceIDs for each Exporting Process) would be convenient with respect to the implementation of the collector. Moreover, it offers the advantage that the same Exporting Process may use more than one interfaces (or IP addresses) to export its monitoring data. According to the current specification, no collector receiving data from two different interface/IP addresses of the same Exporting Process would ever be able to conclude that it receives duplicate records. I assume that in practice, Exporting and Collection Processes would be managed and configured by the same administrator, so it would not be a problem to assign unique sourceIDs to the Exporting Processes. But of course, there may have also been good resons to specify it as it is today. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz 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 --------------ms070406080900070703010907 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 HAYJKoZIhvcNAQkFMQ8XDTA2MDMwNTA5MDYzMlowIwYJKoZIhvcNAQkEMRYEFLglnxuhoDZ+ /fT63D5jkzQFn6T6MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ Wed3TO1yHz8UpnINThpgzzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQWed3TO1yHz8UpnINThpgzzANBgkqhkiG 9w0BAQEFAASCAQA7vK1rDPcce88ELctn9SmDhch+Tjer7Bw3GDEvMyxdHaKhlZAx6S/OCuj/ 1V/IpGZzDgxzKqJSeDnX7YV9GgS9XnweOrt4BqM+Svg5zx+uyzTpSWz+QWVZz0OyyVoUAdRX 3eUKMESb6MpOJ2R0Mp8GbFHPcn3unulugaif7Y0qByz77BDUQj0WHbuQZfmgs1KXqTj1r58U c+a63cIrq+3s8WL1gua9GvBd4m3deuPBoLJz2Sal50LLkOWc56Fxs9bb3wA891NjHb+EDy/l JII831ffyCo6ljwT5i13rRwLggqyQGAvWpOa0meiIcsz+4kXX4lo5rGjjZZ+rbSCjCryAAAA AAAA --------------ms070406080900070703010907-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sun Mar 05 05:32:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFqXe-0000W7-L8 for ipfix-archive@lists.ietf.org; Sun, 05 Mar 2006 05:32:46 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFqXd-0001Ct-AG for ipfix-archive@lists.ietf.org; Sun, 05 Mar 2006 05:32:46 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FFqMb-0004UW-00 for ipfix-list@mil.doit.wisc.edu; Sun, 05 Mar 2006 04:21:21 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FFqMa-0004TR-00 for ipfix@net.doit.wisc.edu; Sun, 05 Mar 2006 04:21:20 -0600 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 05 Mar 2006 11:20:41 +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 k25AKe36005936; Sun, 5 Mar 2006 11:20:40 +0100 (MET) Received: from [10.61.80.250] (ams-clip-vpn-dhcp4347.cisco.com [10.61.80.250]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA08845; Sun, 5 Mar 2006 10:20:39 GMT Message-ID: <440ABB76.6000300@cisco.com> Date: Sun, 05 Mar 2006 10:20: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: Gerhard Muenz CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Message Source ID and template scoping References: <4406B8A9.4060101@informatik.uni-tuebingen.de> <4408E2DB.7040807@cisco.com> <440AAA18.4070202@informatik.uni-tuebingen.de> In-Reply-To: <440AAA18.4070202@informatik.uni-tuebingen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Status: O Gerhard, >Thanks for the clarification. I reread the current definition of >observation domains in IPFIX and it actually requires the (exporterIP, >sourceID)-tuple to identify an Exporting Process. > > 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. >However, as you stated, the other option (unique sourceIDs for each >Exporting Process) would be convenient with respect to the >implementation of the collector. > But impossible to impliment, since all the exporters connected to the same collector would have to communicate with one another to agree unique IDs. Or they'd have to receive a unique ID from the collector before they can send any information. However, if you think of "exporterIPv4Address : sourceID" as a 64bit value, you can consider it as a unique source ID for this exporter. >Moreover, it offers the advantage that >the same Exporting Process may use more than one interfaces (or IP >addresses) to export its monitoring data. > There's nothing to prevent that today. >According to the current >specification, no collector receiving data from two different >interface/IP addresses of the same Exporting Process would ever be able >to conclude that it receives duplicate records. > > Why not? Think of the exporting process as being at a level just above the interfaces, rather than being tied to one particular interface. The specification doesn't say to use the address of the interface, but to use the exporterIPv4Address / exporterIPv6Address, which is the IPv4/IPv6 address used by the Exporting Process. It's usually one of the interface addresses, but it could equally be another address that's unique to the box. Cheers. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From dexe@fulton.k12.ky.us Mon Mar 06 08:29:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFma-000824-LC for ipfix-archive@lists.ietf.org; Mon, 06 Mar 2006 08:29:52 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGFmX-0001of-CQ for ipfix-archive@lists.ietf.org; Mon, 06 Mar 2006 08:29:52 -0500 Received: from mek33-2-82-225-221-93.fbx.proxad.net ([82.225.221.93] helo=fulton.k12.ky.us) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FGFVI-0003xg-00 for ipfix-list@mil.doit.wisc.edu; Mon, 06 Mar 2006 07:12:00 -0600 Message-ID: <000001c6411f$8b01cb20$2103a8c0@dicotyledon> Reply-To: "Dexter Durante" From: "Dexter Durante" To: ipfix-list@mil.doit.wisc.edu Subject: Re: news intona tion Date: Mon, 6 Mar 2006 08:11:55 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C640F5.A22BC320" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?82.225.221.93 X-Spam-Score: 2.7 (++) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Status: O This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C640F5.A22BC320 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://juq35.tisandi.com C V V I I A A A L L G I I R U S A M =20 =20 =20 $ $ $ 1 3 3 , , , 2 3 7 1 3 5 ------=_NextPart_000_0001_01C640F5.A22BC320 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
C
V
V
= I
I
A
A
= A
L
L
G
= I
I
R
U
 =
S
A
M
 
=
 
 
$
= $
$
1
3
= 3
,
,
,
 =
2
3
7
1
= 3
5
------=_NextPart_000_0001_01C640F5.A22BC320-- From ald@archventure.com Tue Mar 07 05:22:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZL2-0000Y8-FW for ipfix-archive@lists.ietf.org; Tue, 07 Mar 2006 05:22:44 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGZL1-0005MN-7q for ipfix-archive@lists.ietf.org; Tue, 07 Mar 2006 05:22:44 -0500 Received: from 168.red-83-35-168.dynamicip.rima-tde.net ([83.35.168.168] helo=archventure.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FGZ3P-0007CA-00 for ipfix-list@mil.doit.wisc.edu; Tue, 07 Mar 2006 04:04:33 -0600 Message-ID: <000001c641ce$77d78800$1f4ba8c0@grazer> Reply-To: "Micaela Alden" From: "Micaela Alden" To: ipfix-list@mil.doit.wisc.edu Subject: Re: news amoe bae Date: Tue, 7 Mar 2006 05:04:05 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C641A4.8F018000" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?83.35.168.168 X-Spam-Score: 2.5 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C641A4.8F018000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable V C V A I I L A A I L G U I R M S A http://faz61.netersons.com ------=_NextPart_000_0001_01C641A4.8F018000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
V
C
V
= A
I
I
L
= A
A
I
L
= G
U
I
R
 =
M
S
A
<= /BODY> ------=_NextPart_000_0001_01C641A4.8F018000-- From majordomo@mil.doit.wisc.edu Wed Mar 08 11:18:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH1Mk-0004xM-8X for ipfix-archive@lists.ietf.org; Wed, 08 Mar 2006 11:18:22 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH1Mj-00071s-0q for ipfix-archive@lists.ietf.org; Wed, 08 Mar 2006 11:18:22 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FH15N-0005QA-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 Mar 2006 10:00:25 -0600 Received: from beniaminus.red.cert.org ([192.88.209.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FH15M-0005Q3-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 08 Mar 2006 10:00:24 -0600 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.18) with ESMTP id k28G0Mqx021372 for ; Wed, 8 Mar 2006 11:00:22 -0500 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 k28G0Mrl021681 for ; Wed, 8 Mar 2006 11:00:22 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <952ED4BD-645C-4FBA-89F2-A135C4B5B27C@cert.org> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3-317660998" To: ipfix-protocol@net.doit.wisc.edu From: Brian Trammell Subject: [ipfix-protocol] nit: IPFIX over TLS over SCTP Date: Wed, 8 Mar 2006 11:00:17 -0500 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 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-3-317660998 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed All, Section 11 (page 47) of proto-19 makes a reference to using TLS over SCTP as a transport for IPFIX. However, there is no further information (as in TCP, sections 10.4.1.2, 10.4.2) on the interaction between TLS and SCTP, and no normative reference to RFC 3436, which defines the usage of TLS over SCTP. Reference to TLS should be made in sections 10.2.4.1 (noting the requirement to use reliable bidirectional streams when using TLS as in 3436 section 7; and the requirement for the Metering Process to establish a TLS session across each stream as shown in 3436 section 8.1), 10.2.4.2 (noting TLS session teardown on stream shutdown), and 10.2.4.3 (again, noting unreliable and partially reliable streams are not available for TLS). Additional references may be necessary as well; I've just taken a first pass here for sake of feedback. Additionally, RFC 3436 "Transport Layer Security over Stream Control Transmission Protocol" should be added to the protocol document's normative references. Thoughts? - Brian --Apple-Mail-3-317660998 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) iD8DBQFEDv+V4/8LCZ4pwvYRAsALAJsEHYxH/eKfTO6gbeaiH4BUJrA5LwCgnLDJ XzsZm7nmAoHgCqtZFUwtTRQ= =LbOb -----END PGP SIGNATURE----- --Apple-Mail-3-317660998-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Mar 08 15:08:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH4x6-00023S-Nv for ipfix-archive@lists.ietf.org; Wed, 08 Mar 2006 15:08:08 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH4x4-0006mM-DA for ipfix-archive@lists.ietf.org; Wed, 08 Mar 2006 15:08:08 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FH4m0-0002aY-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 Mar 2006 13:56:40 -0600 Received: from beniaminus.red.cert.org ([192.88.209.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FH4ly-0002Zn-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 08 Mar 2006 13:56:38 -0600 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 k28JuZ7S005313 for ; Wed, 8 Mar 2006 14:56:37 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k28Jt1wB005191 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: [ipfix-protocol] 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-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000004 X-Scanned-By: MIMEDefang 2.54 on 192.88.209.10 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 09 04:37:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHHac-0000Gj-U8 for ipfix-archive@lists.ietf.org; Thu, 09 Mar 2006 04:37:46 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHHab-0002pG-KA for ipfix-archive@lists.ietf.org; Thu, 09 Mar 2006 04:37:46 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FHHJ8-0001uP-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Mar 2006 03:19:42 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FHHJ7-0001uG-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 09 Mar 2006 03:19:41 -0600 Received: from [10.147.65.153] (luz@kaitos [10.147.65.153]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id k299Jev11026 for ; Thu, 9 Mar 2006 10:19:40 +0100 (MET) Message-ID: <440FF32C.2060705@fokus.fraunhofer.de> Date: Thu, 09 Mar 2006 10:19:40 +0100 From: Lutz Mark User-Agent: Mail/News 1.5 (X11/20060130) MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] semantics of multiple identical Information Elements in a template References: <43971E77.1010806@cisco.com> <43984458.8070008@cisco.com> <691529BB-4B0B-4780-8EF5-753808541389@cert.org> In-Reply-To: <691529BB-4B0B-4780-8EF5-753808541389@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Hi Brian, find my comments inline. > 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. I disagree about this. I prefer to keep Benoit's proposal. The IPFIX protocol draft just defines the protocol and does not care about the semantics. For instance one can use IPFIX protocol with vendor specific information elements and with multiple IEs of the same type. The protocol shouldn't restrict this. > 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? IPFIX just defines the semantics of IEs (information model draft). There are no predefined templates. For this reason there is no predefined semantic for an IPFIX template and corresponding flow records. Best regards, Lutz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 09 12:05:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHOa8-0005GD-PG for ipfix-archive@lists.ietf.org; Thu, 09 Mar 2006 12:05:44 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHOa8-0000Cp-FF for ipfix-archive@lists.ietf.org; Thu, 09 Mar 2006 12:05:44 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FHOPx-0000el-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Mar 2006 10:55:13 -0600 Received: from beniaminus.red.cert.org ([192.88.209.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FHOPv-0000cU-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 09 Mar 2006 10:55:11 -0600 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 k29GsukU027491 for ; Thu, 9 Mar 2006 11:54:57 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k29GsBcR027457 for ; Thu, 9 Mar 2006 11:54:11 -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 k29GsBkh027455; Thu, 09 Mar 2006 11:54:11 -0500 (EST) Received: from [128.237.237.77] (vpn-10-25-4-18.remote.cert.org [10.25.4.18]) by villemus.indigo.cert.org (8.12.11/8.12.11/2.55) with ESMTP id k29GsAJf016592; Thu, 9 Mar 2006 11:54:11 -0500 In-Reply-To: <440FF32C.2060705@fokus.fraunhofer.de> References: <43971E77.1010806@cisco.com> <43984458.8070008@cisco.com> <691529BB-4B0B-4780-8EF5-753808541389@cert.org> <440FF32C.2060705@fokus.fraunhofer.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-407290037" Message-Id: <9DAB6BB5-DDD8-4B28-A3E2-040EED6EEBE3@cert.org> Cc: ipfix-protocol@net.doit.wisc.edu Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix-protocol] semantics of multiple identical Information Elements in a template Date: Thu, 9 Mar 2006 11:54:07 -0500 To: Lutz Mark X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000004 X-Scanned-By: MIMEDefang 2.54 on 192.88.209.10 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2-407290037 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Lutz, Comments, as usual, inline... On Mar 9, 2006, at 4:19 AM, Lutz Mark wrote: >> 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. > > I disagree about this. I prefer to keep Benoit's proposal. > The IPFIX protocol draft just defines the protocol and does not > care about the semantics. For instance one can use IPFIX protocol > with vendor specific information elements and with multiple IEs > of the same type. The protocol shouldn't restrict this. Defining IPFIX to be a semantics-free representation makes absolute sense when each IE appears only once. Note that even this case is not _really_ semantics-free -- "this IE value applies to this Flow Record" is an assertion carrying some meaning, however thin. It's simple to handle private enterprise IEs in this framework - you may not have any idea what a given IE means, but you can unambiguously However, once you allow multiple IE instances per Flow Record, as we have here, it does not appear possible not to make the following choices and still have a universally understandable data format: 1. Do multiple IEs in a record represent a set? 2. Are multiple IE's ordered? These first two points are necessary for proper functioning of generic collectors, especially those which might re-export. Benoit's proposal as I read it covers both, and defines multiple IEs as ordered arrays. There are other questions I'm not sure have yet been explicitly answered: 3. How does the interpretation of each subsequent IE change with its position in the collection? From Benoit's proposal I assume that subsequent IEs in a single record apply to subsequent treatment or sensing at a metering process. Is any other interpretation supported? 4. Does this intepretation of each subsequent IE change with the count of identical IEs in a given template? An example may clarify this question. Presume a biflow collector that uses the second IE of each type to serve as the "reverse" counter. It's a generic biflow collector - it knows how to handle all the various ways flows may be placed in time; it handles both delta and total counters; it can even handle non-key header fields, so, for example, it can recognize forward and reverse TCP initial sequence numbers via duplicate tcpSequenceNumber fields. What should this hypothetical biflow collector do when it receives a record with three octetTotalCount fields? And how is this approach compatible with the hash example in 3. - if a biflow record has six payload hashes, do the first three apply to the forward direction flow, or are the directions interleaved? >> 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? > > IPFIX just defines the semantics of IEs (information model draft). > There are no predefined templates. For this reason there is no > predefined semantic for an IPFIX template and corresponding flow > records. Understood. My objection (or rather, confusion) does not apply to templates as a whole, but to the semantics of _each individual field_ within a flow record. Regards, Brian --Apple-Mail-2-407290037 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) iD8DBQFEEF2y4/8LCZ4pwvYRAhtyAJ9Fy25QvLbOnM3SMiKu3hJdlGYHdwCcDacP vWPmVzjwxliukzfoEDOa/3M= =ECnf -----END PGP SIGNATURE----- --Apple-Mail-2-407290037-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 09 14:00:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHQMs-0006ak-H9 for ipfix-archive@lists.ietf.org; Thu, 09 Mar 2006 14:00:10 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHQMo-0003tx-7v for ipfix-archive@lists.ietf.org; Thu, 09 Mar 2006 14:00:10 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FHQ8Q-0007Jy-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Mar 2006 12:45:14 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FHQ8P-0007Jp-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 09 Mar 2006 12:45:13 -0600 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Mar 2006 19:45:12 +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 k29IjB36016052; Thu, 9 Mar 2006 19:45:11 +0100 (MET) Received: from [10.61.80.3] (ams-clip-vpn-dhcp4100.cisco.com [10.61.80.3]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA22216; Thu, 9 Mar 2006 18:45:10 GMT Message-ID: <441077B6.90303@cisco.com> Date: Thu, 09 Mar 2006 18:45:10 +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: Brian Trammell CC: Lutz Mark , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] semantics of multiple identical Information Elements in a template References: <43971E77.1010806@cisco.com> <43984458.8070008@cisco.com> <691529BB-4B0B-4780-8EF5-753808541389@cert.org> <440FF32C.2060705@fokus.fraunhofer.de> <9DAB6BB5-DDD8-4B28-A3E2-040EED6EEBE3@cert.org> In-Reply-To: <9DAB6BB5-DDD8-4B28-A3E2-040EED6EEBE3@cert.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Brian, > if a biflow record has six payload hashes, do the first three apply > to the forward direction flow, or are the directions interleaved? If it's not 100% clear and unambiguous, then the biflow design is clearly incomplete. For my 2€: Presumably the device meansures the same information in both directions - perhaps it doesn't even care which direction is which. So divide and conquer: let the device export one template and two records. The template contains a direction element and three hash elements. Define their order as you will (eg, time or location). Then one record shows "I observed these three hashes in direction A", while the other says the same about the other three hashes in direction B. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 09 14:09:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHQVh-0007M2-Tf for ipfix-archive@lists.ietf.org; Thu, 09 Mar 2006 14:09:17 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHQVg-0004DX-Mg for ipfix-archive@lists.ietf.org; Thu, 09 Mar 2006 14:09:17 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FHQHj-0007ca-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Mar 2006 12:54:51 -0600 Received: from franclinus.red.cert.org ([192.88.209.16]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FHQHi-0007cV-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 09 Mar 2006 12:54:50 -0600 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.18) with ESMTP id k29IsmSt004884 for ; Thu, 9 Mar 2006 13:54:48 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k29Irc3Y004823 for ; Thu, 9 Mar 2006 13:53:38 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k29IrccS004821; Thu, 09 Mar 2006 13:53:38 -0500 (EST) Received: from [128.237.237.77] (vpn-10-25-4-18.remote.cert.org [10.25.4.18]) by villemus.indigo.cert.org (8.12.11/8.12.11/2.55) with ESMTP id k29Irc6e027234; Thu, 9 Mar 2006 13:53:38 -0500 In-Reply-To: <441077B6.90303@cisco.com> References: <43971E77.1010806@cisco.com> <43984458.8070008@cisco.com> <691529BB-4B0B-4780-8EF5-753808541389@cert.org> <440FF32C.2060705@fokus.fraunhofer.de> <9DAB6BB5-DDD8-4B28-A3E2-040EED6EEBE3@cert.org> <441077B6.90303@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-3-414457157" Message-Id: <3D7381C3-EA57-4375-9946-1BA22528FC26@cert.org> Cc: Lutz Mark , ipfix-protocol@net.doit.wisc.edu Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix-protocol] semantics of multiple identical Information Elements in a template Date: Thu, 9 Mar 2006 13:53:34 -0500 To: Paul Aitken X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000004 X-Scanned-By: MIMEDefang 2.54 on 192.88.209.16 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-3-414457157 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Paul, On Mar 9, 2006, at 1:45 PM, Paul Aitken wrote: > Brian, > >> if a biflow record has six payload hashes, do the first three apply >> to the forward direction flow, or are the directions interleaved? > > If it's not 100% clear and unambiguous, then the biflow design is > clearly incomplete. My point exactly. As currently specified, multiple identical IEs do not appear sufficient for the biflow use case. (The single-record biflow export presently advanced in the biflow draft does not make use of multiple IEs, for precisely this reason. Direction is explicitly specified in the definition of the information elements.) Regards, Brian --Apple-Mail-3-414457157 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) iD8DBQFEEHmx4/8LCZ4pwvYRAvmzAJ4wXF4yly51bLOqFH90XwH9V5NQoACg0tfw RFRdYUaHQnmr0rOiOH1D6SY= =R11F -----END PGP SIGNATURE----- --Apple-Mail-3-414457157-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 09 14:41:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHR0P-0005tQ-1T for ipfix-archive@lists.ietf.org; Thu, 09 Mar 2006 14:41:01 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHR0N-0005CH-Qt for ipfix-archive@lists.ietf.org; Thu, 09 Mar 2006 14:41:01 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FHQwX-0005u8-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Mar 2006 13:37:01 -0600 Received: from beniaminus.red.cert.org ([192.88.209.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FHQwV-0005ti-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 09 Mar 2006 13:36:59 -0600 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 k29JavUh006201 for ; Thu, 9 Mar 2006 14:36:58 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k29Jaa0R006192 for ; Thu, 9 Mar 2006 14:36:36 -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 k29JaZ21006190; Thu, 09 Mar 2006 14:36:36 -0500 (EST) Received: from [128.237.237.77] (vpn-10-25-4-18.remote.cert.org [10.25.4.18]) by villemus.indigo.cert.org (8.12.11/8.12.11/2.55) with ESMTP id k29JaZtu031173; Thu, 9 Mar 2006 14:36:35 -0500 In-Reply-To: <9DAB6BB5-DDD8-4B28-A3E2-040EED6EEBE3@cert.org> References: <43971E77.1010806@cisco.com> <43984458.8070008@cisco.com> <691529BB-4B0B-4780-8EF5-753808541389@cert.org> <440FF32C.2060705@fokus.fraunhofer.de> <9DAB6BB5-DDD8-4B28-A3E2-040EED6EEBE3@cert.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4-417034342" Message-Id: <7890E0CD-CFE4-4839-B69A-E6285C895DE5@cert.org> Cc: Lutz Mark , ipfix-protocol@net.doit.wisc.edu Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix-protocol] semantics of multiple identical Information Elements in a template Date: Thu, 9 Mar 2006 14:36:31 -0500 To: Brian Trammell X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000004 X-Scanned-By: MIMEDefang 2.54 on 192.88.209.10 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-4-417034342 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Lutz, Oops. Interrupted myself in mid thought on this one. To finish... On Mar 9, 2006, at 11:54 AM, Brian Trammell wrote: > Defining IPFIX to be a semantics-free representation makes absolute > sense when each IE appears only once. Note that even this case is > not _really_ semantics-free -- "this IE value applies to this Flow > Record" is an assertion carrying some meaning, however thin. It's > simple to handle private enterprise IEs in this framework - you may > not have any idea what a given IE means, but you can unambiguously ...state that the value applies to the record. Regards, Brian --Apple-Mail-4-417034342 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) iD8DBQFEEIPC4/8LCZ4pwvYRArs2AJ45+2QCxWwxmyVy1kwbcRzU19nJVQCcCGf8 fDffGBu/NK4uRhcPLZ3AO80= =K7gj -----END PGP SIGNATURE----- --Apple-Mail-4-417034342-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 10 05:39:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHf1n-0001pK-7s for ipfix-archive@lists.ietf.org; Fri, 10 Mar 2006 05:39:23 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHf1l-0001xx-QW for ipfix-archive@lists.ietf.org; Fri, 10 Mar 2006 05:39:23 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FHeZe-0002ZP-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Mar 2006 04:10:18 -0600 Received: from smtp.ee.ethz.ch ([129.132.2.219]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FHeZc-0002Yd-00 for ipfix@net.doit.wisc.edu; Fri, 10 Mar 2006 04:10:16 -0600 Received: from localhost (tranquillity.ee.ethz.ch [129.132.2.222]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 674E0D936C; Fri, 10 Mar 2006 11:10:15 +0100 (MET) Received: from smtp.ee.ethz.ch ([129.132.2.217]) by localhost (tranquillity [129.132.2.222]) (amavisd-new, port 10024) with LMTP id 14454-03-3; Fri, 10 Mar 2006 11:10:15 +0100 (MET) Received: from [82.130.102.210] (nb-4995.ethz.ch [82.130.102.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0201CD9352; Fri, 10 Mar 2006 11:10:14 +0100 (MET) Message-ID: <441151A5.6040102@fokus.fraunhofer.de> Date: Fri, 10 Mar 2006 11:15:01 +0100 From: Elisa Boschi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Cc: Lutz Mark , Juergen Quittek , Paul Aitken , Martin Stiemerling , Elisa Boschi Subject: [ipfix] [Fwd: I-D ACTION:draft-boschi-ipfix-implementation-guidelines-01.txt] Content-Type: multipart/mixed; boundary="------------050101010302030309050700" X-Virus-Scanned: by amavisd-new at ee.ethz.ch Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 This is a multi-part message in MIME format. --------------050101010302030309050700 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all, we have submitted a new version of the IPFIX implementation guidelines. Comments are welcome... Regards, Elisa -------- Original Message -------- Subject: I-D ACTION:draft-boschi-ipfix-implementation-guidelines-01.txt Date: Thu, 09 Mar 2006 15:50:01 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPFIX Implementation Guidelines Author(s) : E. Boschi, et al. Filename : draft-boschi-ipfix-implementation-guidelines-01.txt Pages : 29 Date : 2006-3-9 The IP Flow Information eXport (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes or other devices. This document provides guidelines for the implementation and use of the IPFIX protocol. A set of these guidelines refers to the implementation on middleboxes, such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boschi-ipfix-implementation-guidelines-01.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-boschi-ipfix-implementation-guidelines-01.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-boschi-ipfix-implementation-guidelines-01.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. --------------050101010302030309050700 Content-Type: Message/External-body; name="draft-boschi-ipfix-implementation-guidelines-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-boschi-ipfix-implementation-guidelines-01.txt" Content-Type: text/plain Content-ID: <2006-3-9105300.I-D@ietf.org> --------------050101010302030309050700 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/EBO/LOCALS%7E1/TEMP/nsmail-1.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/EBO/LOCALS%7E1/TEMP/nsmail-1.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------050101010302030309050700-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 10 05:43:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHf5Y-0003B4-Ii for ipfix-archive@lists.ietf.org; Fri, 10 Mar 2006 05:43:16 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHf5Y-000215-7D for ipfix-archive@lists.ietf.org; Fri, 10 Mar 2006 05:43:16 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FHejR-00036H-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Mar 2006 04:20:25 -0600 Received: from smtp.ee.ethz.ch ([129.132.2.219]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FHejP-00035k-00 for ipfix@net.doit.wisc.edu; Fri, 10 Mar 2006 04:20:23 -0600 Received: from localhost (tranquillity.ee.ethz.ch [129.132.2.222]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 996E2D9361; Fri, 10 Mar 2006 11:20:22 +0100 (MET) Received: from smtp.ee.ethz.ch ([129.132.2.217]) by localhost (tranquillity [129.132.2.222]) (amavisd-new, port 10024) with LMTP id 15788-01-2; Fri, 10 Mar 2006 11:20:22 +0100 (MET) Received: from [82.130.102.210] (nb-4995.ethz.ch [82.130.102.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1A3CDD935C; Fri, 10 Mar 2006 11:20:22 +0100 (MET) Message-ID: <44115404.7070504@fokus.fraunhofer.de> Date: Fri, 10 Mar 2006 11:25:08 +0100 From: Elisa Boschi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Cc: Lutz Mark , Elisa Boschi Subject: [ipfix] [Fwd: I-D ACTION:draft-boschi-ipfix-reducing-redundancy-01.txt] Content-Type: multipart/mixed; boundary="------------020601000403040805000606" X-Virus-Scanned: by amavisd-new at ee.ethz.ch Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c This is a multi-part message in MIME format. --------------020601000403040805000606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all, as agreed in Vancouver, we have generalised the idea described in the draft "Export of per packet information with IPFIX" and have submitted this new Internet-Draft: "Reducing redundancy in IPFIX and PSAMP reports" Please have a look at it Thanks and regards, Elisa -------- Original Message -------- Subject: I-D ACTION:draft-boschi-ipfix-reducing-redundancy-01.txt Date: Wed, 08 Mar 2006 18:50:01 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Reducing redundancy in IPFIX and PSAMP reports Author(s) : E. Boschi, L. Mark Filename : draft-boschi-ipfix-reducing-redundancy-01.txt Pages : 16 Date : 2006-3-8 This document describes a bandwidth saving methodology for exporting flow or packet information using the IP Flow Information Export (IPFIX) protocol. Being the PSAMP protocol based on IPFIX, these considerations are valid for PSAMP exports as well. The main idea is to separate the export of information common to several flows (or packets) and the specific flow (or packet) information, using two different records. The association between the records is kept using unique Identifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boschi-ipfix-reducing-redundancy-01.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-boschi-ipfix-reducing-redundancy-01.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-boschi-ipfix-reducing-redundancy-01.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. ************************************************************************************************** E-mail Confidentiality Notice and Disclaimer. This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. Email messages are not necessarily secure. Hitachi Europe does not accept responsibility for any changes made to this message after it was sent. Please note that Hitachi Europe checks outgoing email messages for the presence of computer viruses. --------------020601000403040805000606 Content-Type: Message/External-body; name="draft-boschi-ipfix-reducing-redundancy-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-boschi-ipfix-reducing-redundancy-01.txt" Content-Type: text/plain Content-ID: <2006-3-8153521.I-D@ietf.org> --------------020601000403040805000606 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/EBO/LOCALS%7E1/TEMP/nsmail-2.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/EBO/LOCALS%7E1/TEMP/nsmail-2.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------020601000403040805000606-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From eva@aerobics.com Fri Mar 10 13:59:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHmpz-0000Ri-4w for ipfix-archive@lists.ietf.org; Fri, 10 Mar 2006 13:59:43 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHmpx-0000cU-Rf for ipfix-archive@lists.ietf.org; Fri, 10 Mar 2006 13:59:43 -0500 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FHmfX-0000Gk-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Mar 2006 12:48:55 -0600 Received: from aerobics.com (65.Red-83-51-47.dynamicIP.rima-tde.net [83.51.47.65]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k2AImqat012891 for ; Fri, 10 Mar 2006 12:48:53 -0600 Message-ID: <000001c64473$3e6d8310$5162a8c0@yal36> Reply-To: "Evander Lichtman" From: "Evander Lichtman" To: ipfix-list@mil.doit.wisc.edu Subject: Re: Pak8ramcy news Date: Fri, 10 Mar 2006 13:48:38 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C64449.55977B10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.5 (++) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C64449.55977B10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable p C o i m a b I l i u s $9 c 9 ( t0 10 l p b i l l d l l s s ) s V a a g I z i x u e m $1 i 05 (30 uz s p t i d l f l h s r ) e V f i w a p g x r z a $ b 69 (10 M4 g p l i x l w l v s m ) =20 And ma JI ny other. =20 Sa sY ve o RN ver 5 1a 0% wi Wi th ou SC r onl V5 ine st ic ore http://beae81.drivetiget.com ------=_NextPart_000_0001_01C64449.55977B10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
p C o i m a b I l i u s $9 c 9 ( t0 10  l p b i l l d l l s s )
s V a a g I z i x u e m $1 i 05 (30 uz   s p t i d l f l h s r )
e V f i w a p g x r z a $ b 69 (10 M4   g p l i x l w l v s m )
 
And ma JI ny other.
 
Sa sY ve o RN ver 5 1a 0% wi Wi th ou SC r onl V5 ine st ic ore http://beae81.drivetiget.com
------=_NextPart_000_0001_01C64449.55977B10-- From josephay@aidcoint.com Fri Mar 10 23:19:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHvZz-0000eh-Ij for ipfix-archive@lists.ietf.org; Fri, 10 Mar 2006 23:19:47 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHvZx-0005eY-84 for ipfix-archive@lists.ietf.org; Fri, 10 Mar 2006 23:19:47 -0500 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FHv7S-0001Dw-00 for ipfix-list@mil.doit.wisc.edu; Fri, 10 Mar 2006 21:50:18 -0600 Received: from aidcoint.com (dslb-084-057-251-172.pools.arcor-ip.net [84.57.251.172]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k2B3oGBQ023222 for ; Fri, 10 Mar 2006 21:50:17 -0600 Message-ID: <000001c644be$e2bf7130$4caaa8c0@iys12> Reply-To: "Josepha Ladner" From: "Josepha Ladner" To: ipfix-list@mil.doit.wisc.edu Subject: Re: ParatAmcy news Date: Fri, 10 Mar 2006 22:50:06 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C64494.F9E96930" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C64494.F9E96930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable l C k i b a g I q i c s $9 h 9 (10 fH c p x i k l p l a s c ) l V y a t I w i w u m m $10 j 5 (30 CX w p f i r l i l d s a ) n V r i b a t g g r l a $6 r 9 (10 4N n p m i u l k l p s w ) =20 And many l4 other. =20 Sav lP e ove ar r 50 WM % wit Hw h ou oW r onlin Di e stor io e http://yyko0.leasspile.com ------=_NextPart_000_0001_01C64494.F9E96930 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
l C k i b a g I q i c s $9 h 9 (10 fH   c p x i k l p l a s c )
l V y a t I w i w u m m $10 j 5 (30 CX   w p f i r l i l d s a )
n V r i b a t g g r l a $6 r 9 (10 4N   n p m i u l k l p s w )
 
And many l4 other.
 
Sav lP e ove ar r 50 WM % wit Hw h ou oW r onlin Di e stor io e http://yyko0.leasspile.com=
------=_NextPart_000_0001_01C64494.F9E96930-- From musto@utext.com Sun Mar 12 09:59:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIS2t-0000VA-J8 for ipfix-archive@lists.ietf.org; Sun, 12 Mar 2006 09:59:47 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIS2s-00075S-AE for ipfix-archive@lists.ietf.org; Sun, 12 Mar 2006 09:59:47 -0500 Received: from gb.jb.173.236.revip.asianet.co.th ([61.91.173.236] helo=utext.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FIRyw-0002GH-00 for ipfix-list@mil.doit.wisc.edu; Sun, 12 Mar 2006 08:55:42 -0600 Message-ID: <000001c645e5$0318ebb0$01caa8c0@sdg32> Reply-To: "Zakhar Musto" From: "Zakhar Musto" To: ipfix-list@mil.doit.wisc.edu Subject: Re: PaDramcy news Date: Sun, 12 Mar 2006 09:55:32 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C645BB.1A42E3B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.7 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C645BB.1A42E3B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable t C f i g a z I c i e s $ e 99 (10 Nm u p f i b l h l x s h ) v V b a v I y i n u s m $ s 105 (3 fJ 0 k p p i b l k l t s y ) i V x i i a l g z r h a $6 g 9 ( Mu 10 g p z i y l j l c s g ) =20 An oO d many other. =20 Sav Ql e o tj ver 5 Qk 0% w ME ith o XM ur on jn line sto Nc re http://uufe21.haneveben.com ------=_NextPart_000_0001_01C645BB.1A42E3B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
t C f i g a z I c i e s $ e 99 (10 Nm   u p f i b l h l x s h )
v V b a v I y i n u s m $ s 105 (3 fJ 0  k p p i b l k l t s y )
i V x i i a l g z r h a $6 g 9 ( Mu 10  g p z i y l j l c s g )
 
An oO d many other.
 
Sav Ql e o tj ver 5 Qk 0% w ME ith o XM ur on jn line sto Nc re http://uufe21.haneveben.com
------=_NextPart_000_0001_01C645BB.1A42E3B0-- From majordomo@mil.doit.wisc.edu Sun Mar 12 17:22:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIYxC-0004S2-53 for ipfix-archive@lists.ietf.org; Sun, 12 Mar 2006 17:22:22 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIYxA-0004Qt-Sp for ipfix-archive@lists.ietf.org; Sun, 12 Mar 2006 17:22:22 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FIYqj-0002pT-00 for ipfix-list@mil.doit.wisc.edu; Sun, 12 Mar 2006 16:15:41 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FIYqh-0002pH-00 for ipfix-protocol@net.doit.wisc.edu; Sun, 12 Mar 2006 16:15:39 -0600 Received: from [10.147.68.14] (vpn1d014 [10.147.68.14]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id k2CMFWv25159; Sun, 12 Mar 2006 23:15:32 +0100 (MET) Message-ID: <44149D97.8090505@fokus.fraunhofer.de> Date: Sun, 12 Mar 2006 23:15:51 +0100 From: Lutz Mark User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Brian Trammell CC: Paul Aitken , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] semantics of multiple identical Information Elements in a template References: <43971E77.1010806@cisco.com> <43984458.8070008@cisco.com> <691529BB-4B0B-4780-8EF5-753808541389@cert.org> <440FF32C.2060705@fokus.fraunhofer.de> <9DAB6BB5-DDD8-4B28-A3E2-040EED6EEBE3@cert.org> <441077B6.90303@cisco.com> <3D7381C3-EA57-4375-9946-1BA22528FC26@cert.org> In-Reply-To: <3D7381C3-EA57-4375-9946-1BA22528FC26@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Brian, >>> if a biflow record has six payload hashes, do the first three apply >>> to the forward direction flow, or are the directions interleaved? >> >> If it's not 100% clear and unambiguous, then the biflow design is >> clearly incomplete. > > My point exactly... So let's make a well-defined design. There are definitely multiple methods to export biflow data via IPFIX protocol. In most cases the method Paul described would be sufficient. The usage of special Information Elements for the reverse direction fields is another method. And since IPFIX allows the use of multiple IEs of the same type within one flow record, there might be a smart method to exploit this for the export of biflow records. I can think of further methods to export biflow data. Let's collect the alternatives in the biflow draft and discuss their pros and cons and which method fits best for different use cases. Maybe we should also pick this issue and give a recommendation in the implementation guidelines. Best regards, Lutz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From edgar@folkogdans.no Sun Mar 12 17:27:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIZ1w-000292-7h for ipfix-archive@lists.ietf.org; Sun, 12 Mar 2006 17:27:16 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIZ1u-0004Y0-Uz for ipfix-archive@lists.ietf.org; Sun, 12 Mar 2006 17:27:16 -0500 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FIYxB-00033D-00 for ipfix-list@mil.doit.wisc.edu; Sun, 12 Mar 2006 16:22:21 -0600 Received: from folkogdans.no (200-161-166-176.dsl.telesp.net.br [200.161.166.176]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k2CMMEfg001489 for ; Sun, 12 Mar 2006 16:22:19 -0600 Message-ID: <000001c64623$63440680$2acba8c0@xqs16> Reply-To: "Edgar Summerford" From: "Edgar Summerford" To: ipfix-list@mil.doit.wisc.edu Subject: Re: PharamaHBcy news Date: Sun, 12 Mar 2006 17:22:02 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C645F9.7A6DFE80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.3 (+) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C645F9.7A6DFE80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Do you want to p O x V r E f R y P z A g Y for your n M e e y d z i u a d c c t b i n o a n j s? =20 Nothing like you need it, k S i a w v z e over m 5 q 0 f % with http://jebu33.wereefees.com ------=_NextPart_000_0001_01C645F9.7A6DFE80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Do you want to p O x V r E f R y P z A g Y for your n M e e y d z i u a d c c t b i n o a n j s?
 
Nothing like you need it, k S i a w v z e over m 5 q 0 f % with http://jebu33.wereefees.com
------=_NextPart_000_0001_01C645F9.7A6DFE80-- From browacaryl@xantheon.com Mon Mar 13 02:38:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIhdJ-0007Lw-SJ for ipfix-archive@lists.ietf.org; Mon, 13 Mar 2006 02:38:25 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIhdC-0004E8-Ij for ipfix-archive@lists.ietf.org; Mon, 13 Mar 2006 02:38:25 -0500 Received: from 218-172-215-53.dynamic.hinet.net ([218.172.215.53] helo=xantheon.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FIhEj-0002cp-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Mar 2006 01:13:01 -0600 Message-ID: <000001c6466d$7d64dea0$c766a8c0@vzy77> Reply-To: "Caryl Browder" From: "Caryl Browder" To: ipfix-list@mil.doit.wisc.edu Subject: Re: PharGLamacy news Date: Mon, 13 Mar 2006 02:12:29 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C64643.948ED6A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.4 (+++) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C64643.948ED6A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Do you want to j O q V v E h R y P m A m Y for your e M i e k d l i x a q c b t g i c o f n q s? =20 Nothing like you need it, d S o a e v a e over a 5 h 0 t % with http://aafe18.diviternati.com ------=_NextPart_000_0001_01C64643.948ED6A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Do you want to j O q V v E h R y P m A m Y for your e M i e k d l i x a q c b t g i c o f n q s?
 
Nothing like you need it, d S o a e v a e over a 5 h 0 t % with http://aafe18.diviternati.com<= /FONT>
------=_NextPart_000_0001_01C64643.948ED6A0-- From majordomo@mil.doit.wisc.edu Mon Mar 13 06:55:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIldy-0005y2-Iw for ipfix-archive@lists.ietf.org; Mon, 13 Mar 2006 06:55:22 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIldx-0003RK-9S for ipfix-archive@lists.ietf.org; Mon, 13 Mar 2006 06:55:22 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FIl6Q-0003BT-00 for ipfix-list@mil.doit.wisc.edu; Mon, 13 Mar 2006 05:20:42 -0600 Received: from ihemail1.lucent.com ([192.11.222.161]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FIl6P-0003BC-00 for ipfix@net.doit.wisc.edu; Mon, 13 Mar 2006 05:20:41 -0600 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 k2DBKTD9028335; Mon, 13 Mar 2006 05:20:30 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 13 Mar 2006 12:20:27 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098496D2@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Ipfix Wg' (E-mail) (E-mail)" Cc: "Dan Romascanu (E-mail)" , "David Kessens (E-mail)" Subject: [ipfix] AD review for: draft-ietf-ipfix-architecture-09.txt Date: Mon, 13 Mar 2006 12:20:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Appologies that it took so long. As far as I am concerned, you could ask for IETF last Call now and consider the below as initial IETF Last Call comments. At the other hand, if you can quickly spin a new rev (during IETF week?), then it might be better to try and address the below first, before asking your AD to request IETF LC. - sect 2, under bullet observation domain it speaks a bout a "unique ID". Is that administratively unique? or globally unique? - sect 5.4 last line s/Source ID/Domain ID/ ?? Or should the section title be somthing about "Soutrce" ?? I am getting a bit confused about DOmain and Source ID I guess? Protocol doc does indeed speak about SOurce ID. - sect 6.4 2nd para. How can a IPfix device count the p[ackets losts in all the possible problem scenarios? Maybe the solution is to say that it should try to count them and if it can, then it should report. Of it cannot count them, then maybe give a indication of the time period that packets could not be handled/seen? - sect 8.1 last para I think it would be good to add a few more words on how operators can avoid congestion. Just keeping it in their own domain helps to not impact other networks, but if it is a live network with normal user data, then it is still problemantic. Maybe you mean that they should use a dedicated network for it? Anyway, best to elaborate somewhat I think. - I suspect that the Security Considerations section will be considered weak by the security ADs. You may want to check with them for early review/comment. Early meaning right before or in parallel with IETF LC. For example, I am not sure that just MD5 is sufficient anymore. - It seems to me that sect 11 is also Security COnsideratons, no? So should they be subsections of Sect 10? - Sect 12.1 I think you rather want Standards Action for approval of a new IPfix version or template, no? - page 30: INtellectual Property the last para can be removed. We normally do not add such a statement because such claims can be filed any time, even after RFC publication. admin/nites/spelling - refernces/citation issues: !! Missing Reference for citation: [IPFIX-INFO] P008 L037: The IPFIX information model [IPFIX-INFO] defines the base set of - In the abstract you should not use a citation - sect 1.2 last para I would assume that config is done by network ops staff, regardless if it can be done remote or local or whatever the tools are. - sect 2, middle of page 5 s/vvery/very/ - page 6, 1st line: s/field/fields/ 3rd line add closing parethesis one but last line: remove 1 open parenthesis - page 8: s/sender Exporter/sending Exporter/ ?? - page 9 In exmaples you should use IP addresses 192.0.2.x/24 as per RFC3330 - last sentence on page 10. I do not see the difference between "<-->" and "<-->" I know my eyes are getting worse, but this time I suspect it is not caused by my eyes ;-) - sect 5.1.2 last sentence s/Metering Process/Exporting Process/ ?? - sect 5.3.1. 2nd line s/is/are/ - sect 5.5 Pls use RFC3330 IP addresses in example IP addresses - Sect 6.3 speaks about "ID". Is that the "Domain ID" ?? - sect 10: s/IPSEC/IPsec/ Bert -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From ecclesgrant@luxor.com Tue Mar 14 07:33:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ8iO-000199-9p for ipfix-archive@lists.ietf.org; Tue, 14 Mar 2006 07:33:28 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ8iN-0007ld-1B for ipfix-archive@lists.ietf.org; Tue, 14 Mar 2006 07:33:28 -0500 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FJ8Hp-0005wS-00 for ipfix-list@mil.doit.wisc.edu; Tue, 14 Mar 2006 06:06:01 -0600 Received: from luxor.com (sto95-1-82-233-35-186.fbx.proxad.net [82.233.35.186]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k2EC5x59006775 for ; Tue, 14 Mar 2006 06:06:00 -0600 Message-ID: <000001c6475f$a349b620$7a07a8c0@ndf88> Reply-To: "Grant Eccles" From: "Grant Eccles" To: ipfix-list@mil.doit.wisc.edu Subject: Re: PhZUaramacy news Date: Tue, 14 Mar 2006 07:05:51 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C64735.BA73AE20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.5 (++) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C64735.BA73AE20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Do you want to b O d V t E a R k P r A a Y for your i M g e n d l i z a u c b t q i d o b n f s? =20 Nothing like you need it, h S f a p v p e over n 5 h 0 h % with http://roey5.heteroth.com ------=_NextPart_000_0001_01C64735.BA73AE20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Do you want to b O d V t E a R k P r A a Y for your i M g e n d l i z a u c b t q i d o b n f s?
 
Nothing like you need it, h S f a p v p e over n 5 h 0 h % with http://roey5.heteroth.com ------=_NextPart_000_0001_01C64735.BA73AE20-- From majordomo@mil.doit.wisc.edu Tue Mar 14 20:19:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJKfr-0001Me-G9 for ipfix-archive@lists.ietf.org; Tue, 14 Mar 2006 20:19:39 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJKfp-0004tS-3v for ipfix-archive@lists.ietf.org; Tue, 14 Mar 2006 20:19:39 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FJJlm-0006Pg-00 for ipfix-list@mil.doit.wisc.edu; Tue, 14 Mar 2006 18:21:42 -0600 Received: from ihemail1.lucent.com ([192.11.222.161]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FJJlk-0006O4-00 for ipfix@net.doit.wisc.edu; Tue, 14 Mar 2006 18:21:40 -0600 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 k2F0Lbfr009512; Tue, 14 Mar 2006 18:21:37 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 15 Mar 2006 01:21:36 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098E14A6@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Ipfix Wg' (E-mail) (E-mail)" Cc: "David Kessens (E-mail)" , "Dan Romascanu (E-mail)" Subject: [ipfix] AD review for: draft-ietf-ipfix-protocol-19.txt Date: Wed, 15 Mar 2006 01:21:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Sorry for the long delay. WG chairs/editors, pls let me (us ADs) know if you want to respin a new rev first before we do IETF Last Call. - Sect 3. States that Template Sets MUST be sent periodically when UDP is used. What if TCP or or SCTP are used? Might want to state what expected behaviour is in those cases as well. - sect 3.1 under SOurce ID I do not understand the last sentence. WHat does it mean? pls clarify in text. - Page 16 under padding s/zero (0) octets/zero (0) valued octets/ or "octets with a value of zero (o)" ?? Last sentence under "padding" may need a period or semicolon in the middle of the sentence? - Sect 5/6 speak about ...DeltaUSeconds, but I cannot find that term in INFO spec. It talks about ...DeltaMicroSeconds. Is that what you mean? - sect 6.1.3 I'd like to see a reference to the IEEE spec for floats. - sect 6.1.5 I am not sure that by saying "it is expected that strings will be coded in UTF-8 format" will guanrantee interoiperability? Maybe better use MUST (RFC2119) language. Last sentence of 6.1.5 talks about "NUL" characters. That again seems to be ASCII language. Maybe better state "zero valued octets" . - sect 6.1.6 YOu might want to add a sentence how long this can serve us. I believ it is something like 146 years, - sect 6.2 speaks about signed64/unsigned64 and also for 32 and 16. Where are those types defined?? - one but last para on page 33 "sufficient time" should be defined/explained somewhat don't you think so? - Page 35. Should the "All Data Templates" be changed into "All Templates" ?? - I wonder if the one but last para of section 9 is a nice opening for DoS attacks? - Sect 10.1 and 10.2 seem inconsistent in the use of SCTP-PR and PR-SCTP - sect 10.2.6 Where/how is the treshold specified? Same for sect 10.4.1.1 - sect 10.3.7 It is unclear to me how/where the template lifetimes are specified, defined or configured. - sect 11.4 last para I guess that just depends of who/where the attacker is, no? WHat if it is an internal ISP employee? - sect 12.1 I do not think the IPfix version number is an IANA controlled thing. I also think you want that to be changebale only by an IETF standards action (as opposed to just IETF consensus). Afetr all you want this protocol to be stds track. - sect 12.2 seems to be IPFIX-INFO material and not protocol material?? - sect 12 You have already gotten ports for UDP, SCTP and TCP. Sect 10.2.4.1 however does not list the port number. You may want to list the port there, and maybe in the IANA considerations you want to say/state that Nevil has already got port numbers for TCP, UDP and SCTP assigned via IANA. - sect 12. Sect 11.1.1 talsk about IANA assigning Selectors. I guess this needs to be documented under IANA Considerations too. - Sect 12.1 The "IPFIX Set ID" starts (I think) a new registry. So you MUST describe under IANA considerations how to set it up and what the rules are for new assignements. You have that text (more or less) in sect 3.3.2, but you must spell it out here for IANA as well. Then you have a set of Set IDs that get assigned by this document and you should list them clearly for IANA so they can do the initial population of the registry. - It seems to me that sect 13 is more an APPENDIX and so non-normative? Might be good to then list it as appendix and state that it is non-normative. - Refrences. - is 1889 really normative? admin/nits/spelling - references/citation issues: !! Contains embedded space: P051 L048: by IANA, on a First Come First Served basis [RFC 2434], subject to !! Contains embedded space: P052 L005: Expert Review [RFC 2434], i.e. review by one of a group of experts !! Missing Reference for citation: [RFC768] P041 L036: [RFC768] !! Missing citation for Informative reference: P060 L046: [RFC3955] Leinen, S., "Evaluation of Candidate Protocols for IP Flow - add citation to RFC2119 first time you mention 2119. - sect 3.1 remove one of the two words "format" You migth also want to add a sentence to explain why the version field is 0x000a for this version. - sect 3.1 under SOurce ID remove one of the two "the combination" - sect 6.2 s/smaller type/smaller size/ ?? - sect 7 s/MUST/MUST be/ - page 33 s/Disused/Unused/ ?? - the last par of the "Interllectual Property Statement" on page 63 is normally not included in the RFC. So I would remove it. Bert -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From solt@idcmotion.com Wed Mar 15 05:52:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJTcd-000079-62 for ipfix-archive@lists.ietf.org; Wed, 15 Mar 2006 05:52:55 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJTca-0004fn-TD for ipfix-archive@lists.ietf.org; Wed, 15 Mar 2006 05:52:55 -0500 Received: from 151.red-80-59-63.staticip.rima-tde.net ([80.59.63.151] helo=idcmotion.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FJTHJ-0006ow-00 for ipfix-list@mil.doit.wisc.edu; Wed, 15 Mar 2006 04:30:54 -0600 Message-ID: <000001c6481b$803a5060$3749a8c0@tsv97> Reply-To: "Esaias Soltero" From: "Esaias Soltero" To: ipfix-list@mil.doit.wisc.edu Subject: Re: Phymaramacy news Date: Wed, 15 Mar 2006 05:30:37 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C647F1.97644860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?80.59.63.151 X-Spam-Score: 2.7 (++) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C647F1.97644860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 i C o i y a x I u i m s $9 i 9 (10 Jw s p e i a l p l w s q ) m V u a g I n i k u p m $1 h 05 ( PV 30 n p c i l l b l g s v ) y V y i e a w g p r g a $ e 69 ( pX 10 b p c i x l w l t s y ) =20 Man bH y other, Visi yX t our s Jm ite and Sav FY e ove Hp r 5 Uw 0% ------=_NextPart_000_0001_01C647F1.97644860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
i C o i y a x I u i m s $9 i 9 (10 Jw   s p e i a l p l w s q )
m V u a g I n i k u p m $1 h 05 ( PV 30  n p c i l l b l g s v )
y V y i e a w g p r g a $ e 69 ( pX 10  b p c i x l w l t s y )
 
Man bH y other, Visi yX t our s Jm ite and Sav FY e ove Hp r 5 Uw 0%
------=_NextPart_000_0001_01C647F1.97644860-- From majordomo@mil.doit.wisc.edu Thu Mar 16 13:06:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJws5-0002eM-0r for ipfix-archive@lists.ietf.org; Thu, 16 Mar 2006 13:06:49 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJws3-0002i7-N6 for ipfix-archive@lists.ietf.org; Thu, 16 Mar 2006 13:06:49 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FJwTQ-0003uG-00 for ipfix-list@mil.doit.wisc.edu; Thu, 16 Mar 2006 11:41:20 -0600 Received: from groucho.itss.auckland.ac.nz ([130.216.190.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FJwTN-0003t8-00 for ipfix@net.doit.wisc.edu; Thu, 16 Mar 2006 11:41:17 -0600 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 44EAE35DD4 for ; Fri, 17 Mar 2006 06:41:16 +1300 (NZDT) Received: from groucho.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18418-10 for ; Fri, 17 Mar 2006 06:41:16 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 150E434A40 for ; Fri, 17 Mar 2006 06:41:16 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (localhost.localdomain [127.0.0.1]) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11) with ESMTP id k2GHfFQ1014649 for ; Fri, 17 Mar 2006 06:41:15 +1300 Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11/Submit) id k2GHfFNu014647 for ipfix@net.doit.wisc.edu; Fri, 17 Mar 2006 06:41:15 +1300 X-Authentication-Warning: motoko.itss.auckland.ac.nz: apache set sender to nevil@auckland.ac.nz using -f Received: from cpe-66-75-246-10.san.res.rr.com (cpe-66-75-246-10.san.res.rr.com [66.75.246.10]) by webmail.auckland.ac.nz (Horde MIME library) with HTTP; Fri, 17 Mar 2006 06:41:15 +1300 Message-ID: <20060317064115.fglgdc2r81wgksg8@webmail.auckland.ac.nz> Date: Fri, 17 Mar 2006 06:41:15 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] Agenda for IPFIX meeting in Dallas MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Hi all: The Agenda for next week's IPFIX meeting is appended below. Would presenters - especially draft authors - please email copies of their slides to me (preferable as .pdf files) so that we can get them onto the IETF agenda site before the meeting. Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand IPFIX Agenda for IETF 65, Dallas -------------------------------- The IPFIX meeting is scheduled on Wednesday 22 March, 1300-1500, in the Monet Ballroom. Agenda: 5 min 1) Agenda review 10 min 2) Drafts currently with IESG (Nevil Brownlee) * AD Reviews of - draft-ietf-ipfix-protocol-19.txt - draft-ietf-ipfix-info-11.txt * Any comments on - draft-ietf-ipfix-as-06.txt - draft-ietf-ipfix-architecture-09.txt We need to make the changes suggested in the AD Review, along with other editorial changes discussed on the list. The revised drafts can then go to IETF Last Call. 3) IPFIX charter review 5 min Overview (Juergen Quittek) We want to select a few of these to become IPFIX WG items. The items selected should be those that are most important for IPFIX, particularly in helping users to deploy it. And of course, we want to select items that can be completed within a short time frame, i.e. less than one year! Individual Drafts - 5 minute presentations by Draft Authors 50 min - boschi-ipfix-implementation-guidelines-01.txt - draft-schmoll-ipfix-testing-00.txt - dressler-ipfix-aggregation-02.txt - draft-boschi-ipfix-reducing-redundancy-01.txt (was perpktinfo) - draft-trammell-ipfix-file-00.txt - boschi-ipfix-biflow-01.txt - draft-bclaise-ipfix-reliability-00.txt - stephan-isp-templates-01.txt - draft-kobayashi-ipfix-concentrator-mib-00.txt - draft-kobayashi-ipfix-concentrator-model-00.txt 35 min Select of WG items, establish new WG 'Milestones' list 10 min 4) Discussion: the PSAMP MIB / IPFIX MIB (Juergen Quittek) If you have other items you'd like to see discussed, please advise the WG chairs by email to ipfix-chairs@net.doit.wisc.edu -------------------------------------------------------------------------- ----------------------------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 16 14:46:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJyQq-0005p0-Jp for ipfix-archive@lists.ietf.org; Thu, 16 Mar 2006 14:46:48 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJyQp-00065c-Ad for ipfix-archive@lists.ietf.org; Thu, 16 Mar 2006 14:46:48 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FJyMS-00019j-00 for ipfix-list@mil.doit.wisc.edu; Thu, 16 Mar 2006 13:42:16 -0600 Received: from harpo.itss.auckland.ac.nz ([130.216.190.13]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FJyMQ-000163-00 for ipfix@net.doit.wisc.edu; Thu, 16 Mar 2006 13:42:15 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 23DC834DF9 for ; Fri, 17 Mar 2006 08:42:11 +1300 (NZDT) Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18751-07 for ; Fri, 17 Mar 2006 08:42:11 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 07C6E34A70 for ; Fri, 17 Mar 2006 08:42:11 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (localhost.localdomain [127.0.0.1]) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11) with ESMTP id k2GJgAf8026988 for ; Fri, 17 Mar 2006 08:42:10 +1300 Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11/Submit) id k2GJgAKD026985 for ipfix@net.doit.wisc.edu; Fri, 17 Mar 2006 08:42:10 +1300 X-Authentication-Warning: motoko.itss.auckland.ac.nz: apache set sender to nevil@auckland.ac.nz using -f Received: from client64-213.sdsc.edu (client64-213.sdsc.edu [132.249.64.213]) by webmail.auckland.ac.nz (Horde MIME library) with HTTP; Fri, 17 Mar 2006 08:42:10 +1300 Message-ID: <20060317084210.y985pp675pko04g4@webmail.auckland.ac.nz> Date: Fri, 17 Mar 2006 08:42:10 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] Changes to IPFIX Dallas agenda .. MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi all: The 'official,' i.e. the most current, version of our meeting agenda is on our IETF ageanda page, at http://www3.ietf.org/proceedings/06mar/agenda/ipfix.txt (or you can find it via the meeting | Session Agendas and Presentations pages). Do please send me any corrections or requests for changes, I'll update the 'official' version. Cheers, Nevil PS: As authors/presenters send me their slides, I'll post them on our 'Session Agendas and Presentations' page. ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ----------------------------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From stanle@xaverian.org Thu Mar 16 21:37:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK4pw-0001XU-OG for ipfix-archive@lists.ietf.org; Thu, 16 Mar 2006 21:37:08 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK4pv-0004TP-C0 for ipfix-archive@lists.ietf.org; Thu, 16 Mar 2006 21:37:08 -0500 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FK4hS-0006m1-00 for ipfix-list@mil.doit.wisc.edu; Thu, 16 Mar 2006 20:28:22 -0600 Received: from xaverian.org (cm-tvcidade-rec-C8B14B28.dynamic.brdterra.com.br [200.177.75.40]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k2H2SJia003635 for ; Thu, 16 Mar 2006 20:28:20 -0600 Message-ID: <000001c6496a$6f93b530$a2a3a8c0@yix46> Reply-To: "Domen Stanley" From: "Domen Stanley" To: ipfix-list@mil.doit.wisc.edu Subject: Re: PharNWamacy news Date: Thu, 16 Mar 2006 21:28:11 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C64940.86BDAD30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.2 (++++) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C64940.86BDAD30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 p C c i f a f I g i s s $9 o 9 ( kS 10 n p x i r l k l j s g ) l V z a s I v i i u y m $ q 105 (3 F8 0 v p z i v l v l k s j ) b V o i x a e g t r l a $ r 69 (1 IG 0 e p f i b l j l q s z ) =20 M rn any other, Vis 39 it our sit sT e and S Yc ave o iB ver 5 WV 0% ------=_NextPart_000_0001_01C64940.86BDAD30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
p C c i f a f I g i s s $9 o 9 ( kS 10  n p x i r l k l j s g )
l V z a s I v i i u y m $ q 105 (3 F8 0  v p z i v l v l k s j )
b V o i x a e g t r l a $ r 69 (1 IG 0  e p f i b l j l q s z )
 
M rn any other, Vis 39 it our sit sT e and S Yc ave o iB ver 5 WV 0%
------=_NextPart_000_0001_01C64940.86BDAD30-- From majordomo@mil.doit.wisc.edu Fri Mar 17 12:04:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKINP-0002NI-RM for ipfix-archive@lists.ietf.org; Fri, 17 Mar 2006 12:04:35 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKINO-0005rk-DT for ipfix-archive@lists.ietf.org; Fri, 17 Mar 2006 12:04:35 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FKI20-0006Io-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 Mar 2006 10:42:28 -0600 Received: from ihemail1.lucent.com ([192.11.222.161]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FKI1x-0006GJ-00 for ipfix@net.doit.wisc.edu; Fri, 17 Mar 2006 10:42:25 -0600 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 k2HGgKEp010501; Fri, 17 Mar 2006 10:42:21 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 17 Mar 2006 17:42:18 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098E1F55@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Ipfix Wg' (E-mail) (E-mail)" Cc: "Dan Romascanu (E-mail)" , "David Kessens (E-mail)" Subject: [ipfix] AD review for: draft-ietf-ipfix-info-11.txt Date: Fri, 17 Mar 2006 17:42:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Sorry that it took so long (if I say it 4 times, i.e. for each doc I have reviewed, will you please forgive me). Seems that a new rev might be in order ?? Bert - bottom of page 8. enterpriseId - it speaks about "Information Element Identifier described above" I do not see where "above" it is described. In fact, I think the Identifier is described in sect 4, no? - In the 3 paragraphs of sect 3 and 3.1, I would insert the word "abstract" in from of each occurence of "data type(s)". Also the title of sect 3.1 probably reads better as "Abstract Data Types". - sect 3.1.9 "it is expected that strings will be encoded in UTF-8" That does not make it interoperable, does it? Would it not be better to say "strings MUST be encoded..." And I woudl add a citation and reference to RFC3629. - sect 3.2 s/future protocol extensions/future information model extensions/ ?? - page 16 What are ID 211 and 212 ?? blank ?? reserved?? something else? I see the explanation on page 17. I'd suggest to make them RESERVED or OBSOLLETE or DEPRECATEd or give them some name with the note that they are not part of the standard. - section 5 1st sentence s/Flow attributes/Information Elements/ ?? - sections 5.1.3, 5.1.4., 5.1.5 and 5.1.6 I worry about referential integrety when the ifIndex gets stored in offline/archive storage. On a reboot, many devices renumber the ifIndex for various interfaces. Is this not a problem? I'd think it is at least something to mention/discuss/warn for. - sect 5.2.3 Is the message that contains this Information Element included in the count?? May want to make that clear for better interoperability. Same for some of the other exportXXXCounters - sect 5.2.5 Text says: number of flow records But in Units it says: flows So what is it? Same for sect 5.2.9 - sect 5.2.8 Does the count include header octets? - sect 5.2.12 It is not clear/sopecific as to which bit is bit zero, bit one etc. - Sect 5.2.3 and 5.2.5 Is it best to speak about Mask? Or would speaking of (and naming it) PrefixLength be better? - Sect 5.6.3 I worry about the fact that there is discussion already about AS numbers of 32-bit length. So are we future proof here? In the MIB/SMI world we have made it a 32bit unsigned, see InetAutonomousSystemNumber in RFC4001. - sect 5.6.9 How are new values of Labeltypes be added in the future? last line in this section, remove "and IP addresses" ?? - sect 5.8 Just for my understanding, why do you need all 4 levels of granularity here (i.e. sec, milisec, microsec and nanosec)?? - sect 5.5.x Would it be usefull to add a line of text to explain how long (how many minutes, months, years) each granularity allows based on the underlying datatype? - sect 5.9.11 to 5.9.14 I wondered if it makes sense to say some thing more about "packet treatment". Like what sort of treatment? Any reference to an RFC? - sect 5.10.2 speaks about flowInactiveTimeout while sect 5.10.3 speaks about idle timeout. Should you have flowIdleTimeout instead of flowInactievTimeout for consistency? - sect 5.10.11 Make it clear that the value is hex 00 (0 could be read as decimal zero) - sect 6, page 69 I think I would make it MUST instead of SHOULD in 2nd and 3rd para. - sect 7 first para, pls add a ptr to the list of Information Element Identifiers that need to be recorded as the initially assigned values for this registry. I guess you need to point them to sect 4. I doubt it is clear to IANA though what exactly to record from that section. You can check directly with iana to ask if things are clear or not and if not to work out text with them that they understand. I wonder if it would not be much better to have new Information Elements require a Standards Track action. I think that ensure much better review and evaluation and certainly ensure well-documented registrations. In any event, if you do do FCFS with expert review, then I would - require proper documentation to be publicly available - maybe setup some sort of template that MUST be filled out and approved to request registration. You speak about an Appendix B as having a schema/example on how to extend. It is howeer (I think) the Schema for the currently assigned values. - Sect 8. I am pretty sure that the Security ADs will want to see more detail here. They probably want to understand which Information Elements contain sensitive data (and why it is sensitive) or privacy sensitive data (and why so). Probably similar to why they want to see that a MIB document lists the objects that are sensitive and why so and what the risks are if the data gets intercepted. - Appendix A and B I am a bit confused when I read as title "Formal Specification..." and then in the first para I read that it is informational and not normative. If it is a "fomral machine readable spec.." is it then not intended as input to tools, code-generators, data-structure generators and such? In that case I would be very worried if no tthis schema but the text earlier in the document is normative and authoritative. Anyway, I asked an APPS AD if he could check the "formal" machine readable schema, but he does not recognize it as a schema that can be checked by any of his tools. So what is it? How can we (or anyone) check it for correctness? administrative/bureaucracy/nits/spelling: - sect 5.10.4 "bewtween in time" in first sentence ?? same in sect 5.10.5 - 3rd para in sect 1. I suspect that the ptrs to the various sections do not completely match with the actual content claimed to be in those sections. Specifically, the ptrs to 4 and 5 should probably be 5 and 6 ?? - I see that you use MUST (i.e. rfc2119 type) language and so there MUST be a normative citation/reference to RFC2119. - problems with references/citations. Note that my tool may give false warnings, so just check them. !! Missing citation for Informative reference: P071 L006: [IEEE.802-11.1999] !! Missing citation for Informative reference: P071 L015: [IEEE.802-3.2002] !! Missing citation for Informative reference: P071 L023: [IEEE.P802-1Q.2003] !! Missing citation for Informative reference: P072 L026: [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 !! Missing citation for Informative reference: P072 L029: [RFC2463] Conta, A. and S. Deering, "Internet Control Message !! Missing citation for Informative reference: P072 L033: [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, !! Missing citation for Informative reference: P072 L036: [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, !! Missing citation for Informative reference: P072 L039: [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group !! Missing citation for Informative reference: P072 L042: [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., !! Missing citation for Informative reference: P072 L047: [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol !! Missing citation for Informative reference: P072 L050: [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., !! Missing citation for Informative reference: P073 L006: [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and !! Missing citation for Informative reference: P073 L012: [RFC3260] Grossman, D., "New Terminology and Clarifications for !! Missing citation for Informative reference: P073 L015: [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, !! Missing citation for Informative reference: P073 L018: [RFC3668] Bradner, S., "Intellectual Property Rights in IETF !! Missing citation for Informative reference: P073 L021: [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 17 12:41:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKIxE-0006Gs-ON for ipfix-archive@lists.ietf.org; Fri, 17 Mar 2006 12:41:36 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKIxD-00072N-Fl for ipfix-archive@lists.ietf.org; Fri, 17 Mar 2006 12:41:36 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FKIpn-0005hM-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 Mar 2006 11:33:55 -0600 Received: from ihemail1.lucent.com ([192.11.222.161]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FKIpm-0005hH-00 for ipfix@net.doit.wisc.edu; Fri, 17 Mar 2006 11:33:54 -0600 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 k2HHXoD8023968; Fri, 17 Mar 2006 11:33:50 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 17 Mar 2006 18:33:47 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098E1F74@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Ipfix Wg' (E-mail) (E-mail)" Cc: "Dan Romascanu (E-mail)" , "David Kessens (E-mail)" Subject: [ipfix] AD review for: draft-ietf-ipfix-as-06.txt Date: Fri, 17 Mar 2006 18:33:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Sorry for the long delay. Overall question: Is this a document to describe realistic applicability of IPFIX, or Is it more of a marketing or promitional document to try and push itinto all sorts of existing systems? This is the first time I read this document, and I did find myself wondering several times if I was reading promotional material to convince me of all sorts of places where I could go use this. In many scenarios it would mean extending the Information Model, so it is not as if it would be a no-effort activity. As an AD I woner if the other groups have all looked at the scenarios that would touch or interact on their turf so to speak. Like has WGs like IPPM, AAA, IDMEF, RMONMIB, RTP etc looked at this? It seems there might be quite a set of questions from there. And then there is the question if operators really want IPFIX to be interacting/integrating with all these other areas. Maybe they do. Have you (WG) proof of that or expressions of support from operators? So I am not yet how to move ahead with this one. It is targeted for Informational, so we have some leverage. But I'd like to have some answers on the above first. Meanwhile, below are some nits to look at: - IPv4 sample addresses should be from the range 192.0.2.0/24 as per RFC3330. So you better update the addresses on page 6. - the last sentence on page 7 spaking about PSAMP seems a bit out of place in the middle of a discussion of using IPFIX for IDS. - citation/reference issues those with a - in the middle might be OK, my tool does not (yet) recognize linebreak at such points. !! Missing citation for Informative reference: P021 L046: [DuGr00] Nick Duffield, Matthias Grossglauser, "Trajectory !! Missing citation for Informative reference: P021 L051: [GrDM98] Ian D. Graham, Stephen F. Donnelly, Stele Martin, !! Missing Reference for citation: [PSAMP-FM] P018 L012: requirements in [PSAMP-FM] that directly affect the export !! Missing Reference for citation: [PSAMP-PROTOCOL] P018 L013: protocol. In [PSAMP-PROTOCOL] the requirements have been !! Missing citation for Informative reference: P022 L012: [PSAMP-FW] Nick Duffield (Ed.), "A Framework for Packet !! Missing citation for Informative reference: P022 L051: [RFC3577] S. Waldbusser, R. Cole, C. Kalbfleisch, Bert -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From nobody@mla.host2server.net Sat Mar 18 09:23:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKcKx-0000nz-0z for ipfix-archive@lists.ietf.org; Sat, 18 Mar 2006 09:23:23 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKcKt-0003bm-KD for ipfix-archive@lists.ietf.org; Sat, 18 Mar 2006 09:23:23 -0500 Received: from ns2.host2server.net ([69.72.210.219] helo=mla.host2server.net) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FKbx2-0007iL-00 for ipfix-list@mil.doit.wisc.edu; Sat, 18 Mar 2006 07:58:40 -0600 Received: from nobody by mla.host2server.net with local (Exim 4.52) id 1FKbx0-0002hN-NN for ipfix-list@mil.doit.wisc.edu; Sat, 18 Mar 2006 21:58:38 +0800 To: ipfix-list@mil.doit.wisc.edu Subject: Update the e-mail address in your online profile. [code0001] From: © 2006 JPMorgan Chase & Co. Reply-To: no.reply@chase.com MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit Message-Id: Date: Sat, 18 Mar 2006 21:58:38 +0800 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mla.host2server.net X-AntiAbuse: Original Domain - mil.doit.wisc.edu X-AntiAbuse: Originator/Caller UID/GID - [99 500] / [47 12] X-AntiAbuse: Sender Address Domain - mla.host2server.net X-Source: X-Source-Args: /usr/local/apache/bin/httpd -DSSL X-Source-Dir: americancorrespondence.com:/public_html/suckmydick X-Spam-Score: 1.3 (+) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Chase OnlineSM - Logon Form Prospect
Chase Logo Skip to main content Accessibility Information

Chase.com   |   Privacy Policy  
Chase Online
Dear Chase account holder,

Dear Chase account holder,

We recently reviewed your account, and suspect that your Chase Internet Banking account may have been accessed by an unauthorized third party. Protecting the security of your account and of the Chase Bank network is our primary concern. Therefore, as a preventative measure, we have temporarily limited access to sensitive account features.

To restore your account access, please take the following steps to ensure that your account has not been compromised:

1. Login to your Chase Internet Banking account. In case you are not enrolled for Internet Banking, you will have to use your Social Security Number as both your Personal ID and Password.

2. Review your recent account history for any unauthorized withdrawals or deposits, and check your account profile to make sure not changes have been made. If any unauthorized activity has taken place on your account, report this to Chase staff immediately.

Click here to activate your account

 

We apologize for any inconvenience this may cause, and appreciate your assistance in helping us maintain the integrity of the entire Chase system. Thank you for your prompt attention to this matter.

Sincerely,

The Chase Bank Team

Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your Chase Bank account and choose the "Help" link in the header of any page.

© 2006 JPMorgan Chase & Co.security manager

Becky Draftel

 

 
 

Security  |  Terms of Use
© 2005 JPMorgan Chase & Co.
From majordomo@mil.doit.wisc.edu Sun Mar 19 01:08:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKr5W-0003IE-JK for ipfix-archive@lists.ietf.org; Sun, 19 Mar 2006 01:08:26 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKr5T-0008Ei-87 for ipfix-archive@lists.ietf.org; Sun, 19 Mar 2006 01:08:26 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FKqhv-0001H5-00 for ipfix-list@mil.doit.wisc.edu; Sat, 18 Mar 2006 23:44:03 -0600 Received: from ihemail1.lucent.com ([192.11.222.161]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FKqht-0001Fj-00 for ipfix@net.doit.wisc.edu; Sat, 18 Mar 2006 23:44:01 -0600 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 k2J5hvcW017409; Sat, 18 Mar 2006 23:43:57 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 19 Mar 2006 06:43:55 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098E2116@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Ipfix Wg' (E-mail) (E-mail)" Cc: "Scott Hollenbeck (E-mail)" , "Dan Romascanu (E-mail)" , "David Kessens (E-mail)" Subject: [ipfix] Additional AD review for: draft-ietf-ipfix-info-11 XML Schema Rev iew Date: Sun, 19 Mar 2006 06:43:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Pls include the below comment as AD review comments for this document. Thanks for the review to Scott! Bert -----Original Message----- From: Scott Hollenbeck [mailto:sah@428cobrajet.net] Sent: Friday, March 17, 2006 19:32 To: 'Wijnen, Bert (Bert)'; 'David Kessens'; dromasca@avaya.com Subject: draft-ietf-ipfix-info-11 XML Schema Review Review at Bert's request. Appendix A: The best that can be done with this is to confirm that it's well-formed XML. It's NOT a specification in the formal sense of the word. Appendix B: This is an XML Schema specification. As currently written it's not valid. The issues: The legitimate element is commented out. It shouldn't be. There are also some other structures in the Schema that are commented out without explanation. They should be either removed, or something should be added to explain why they're commented out. The URI used to identify the Schema doesn't follow the conventions for IETF Schemas described in RFC 3688, but that's probably OK if this is just for informational purposes. The XPath described at the end of the Schema is invalid. Here's the error returned from IBM's XML Schema Quality Checker: MESSAGE No node in element http://www.ietf.org/ipfix:fieldDefinitions corresponds to defined in . Invalid XPath starting from http://www.ietf.org/ipfix:fieldDefinitions:field. It appears to be invalid because there's nothing defined as infoElementId in the Schema. to be done ... Note the "to be done". -Scott- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sun Mar 19 12:57:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL29x-0003Ov-P9 for ipfix-archive@lists.ietf.org; Sun, 19 Mar 2006 12:57:45 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL29w-0003G7-Ed for ipfix-archive@lists.ietf.org; Sun, 19 Mar 2006 12:57:45 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FL1mT-0000GK-00 for ipfix-list@mil.doit.wisc.edu; Sun, 19 Mar 2006 11:33:29 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FL1mR-0000FL-00 for ipfix@net.doit.wisc.edu; Sun, 19 Mar 2006 11:33:28 -0600 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 k2JHX6u11814; Sun, 19 Mar 2006 18:33:08 +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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipfix] AD review for: draft-ietf-ipfix-as-06.txt Date: Sun, 19 Mar 2006 18:33:17 +0100 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA10C82BC@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ipfix] AD review for: draft-ietf-ipfix-as-06.txt Thread-Index: AcZJ6UxDfUiOHknjR9mDmsQmEHBuowBkW6XA From: "Tanja Zseby" To: "Wijnen, Bert \(Bert\)" , "'Ipfix Wg' \(E-mail\) \(E-mail\)" Cc: "Dan Romascanu \(E-mail\)" , "David Kessens \(E-mail\)" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Hi Bert, actually I am a bit surprised about your first comment. In the applicability statement we want to show how IPFIX can be used for the target applications mentioned in the requirement document and what are the relations to other frameworks. Isnt this the role of an applicability statement? We have critical statements in the draft and at nearly each IPFIX meeting I asked for further input for the section on IPFIX limitations (I think at least some RMON and IPPM people attended IPFIX meetings).=20 Personally I think IPFIX offers a lot of opportunites. But comming from a research institute I strongly dissociate myself from promoting any product or solution without critical technical assessment. I would be happy to discuss further opportunities and limitations of IPFIX and to include these in the AS document. So comments from the other groups are highly welcome. Kind Regards, Tanja=20 > -----Original Message----- > From: majordomo listserver=20 > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Wijnen, Bert (Bert) > Sent: Friday, March 17, 2006 6:34 PM > To: 'Ipfix Wg' (E-mail) (E-mail) > Cc: Dan Romascanu (E-mail); David Kessens (E-mail) > Subject: [ipfix] AD review for: draft-ietf-ipfix-as-06.txt >=20 > Sorry for the long delay. >=20 > Overall question: >=20 > Is this a document to describe realistic applicability of IPFIX, >=20 > or >=20 > Is it more of a marketing or promitional document to try and > push itinto all sorts of existing systems? >=20 > This is the first time I read this document, and I did find=20 > myself wondering several times if I was reading promotional=20 > material to convince me of all sorts of places where I could=20 > go use this. > In many scenarios it would mean extending the Information=20 > Model, so it is not as if it would be a no-effort activity. >=20 > As an AD I woner if the other groups have all looked at the=20 > scenarios that would touch or interact on their turf so to speak. > Like has WGs like IPPM, AAA, IDMEF, RMONMIB, RTP etc looked at this? > It seems there might be quite a set of questions from there. >=20 > And then there is the question if operators really want IPFIX=20 > to be interacting/integrating with all these other areas.=20 > Maybe they do. Have you (WG) proof of that or expressions of=20 > support from operators? >=20 > So I am not yet how to move ahead with this one. > It is targeted for Informational, so we have some leverage. > But I'd like to have some answers on the above first. >=20 > Meanwhile, below are some nits to look at: >=20 > - IPv4 sample addresses should be from the range 192.0.2.0/24 as > per RFC3330. So you better update the addresses on page 6. >=20 > - the last sentence on page 7 spaking about PSAMP seems > a bit out of place in the middle of a discussion of > using IPFIX for IDS. >=20 > - citation/reference issues > those with a - in the middle might be OK, my tool does not (yet) > recognize linebreak at such points. >=20 > !! Missing citation for Informative reference: > P021 L046: [DuGr00] Nick Duffield, Matthias=20 > Grossglauser, "Trajectory >=20 > !! Missing citation for Informative reference: > P021 L051: [GrDM98] Ian D. Graham, Stephen F.=20 > Donnelly, Stele Martin, >=20 > !! Missing Reference for citation: [PSAMP-FM] > P018 L012: requirements in [PSAMP-FM] that directly=20 > affect the export >=20 > !! Missing Reference for citation: [PSAMP-PROTOCOL] > P018 L013: protocol. In [PSAMP-PROTOCOL] the=20 > requirements have been >=20 > !! Missing citation for Informative reference: > P022 L012: [PSAMP-FW] Nick Duffield (Ed.), "A=20 > Framework for Packet >=20 > !! Missing citation for Informative reference: > P022 L051: [RFC3577] S. Waldbusser, R. Cole, C. Kalbfleisch, >=20 >=20 > Bert >=20 > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help"=20 > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say=20 > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ >=20 >=20 -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sun Mar 19 14:07:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL3Ey-00009D-Mn for ipfix-archive@lists.ietf.org; Sun, 19 Mar 2006 14:07:00 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL3Ex-0005eg-Ar for ipfix-archive@lists.ietf.org; Sun, 19 Mar 2006 14:07:00 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FL39S-0001L6-00 for ipfix-list@mil.doit.wisc.edu; Sun, 19 Mar 2006 13:01:18 -0600 Received: from ihemail2.lucent.com ([192.11.222.163]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FL39R-0001Kx-00 for ipfix@net.doit.wisc.edu; Sun, 19 Mar 2006 13:01:17 -0600 Received: from ihemail1.lucent.com (h192-11-222-161.lucent.com [192.11.222.161]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2JJ195t000153; Sun, 19 Mar 2006 13:01:09 -0600 (CST) 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 k2JJ17PX015487; Sun, 19 Mar 2006 13:01:08 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 19 Mar 2006 20:01:07 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098E22E7@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Tanja Zseby , "'Ipfix Wg' (E-mail) (E-mail)" Cc: "Dan Romascanu (E-mail)" , "David Kessens (E-mail)" Subject: RE: [ipfix] AD review for: draft-ietf-ipfix-as-06.txt Date: Sun, 19 Mar 2006 20:01:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Tanja, I may have to go back to read RFC2026 as to what an AS is meant to do. It starts in sect 3.2 in 2026. I guess you could take your viewpoint. I may have overreacted, I tend to look for a statement that explains how to pragmatically use it in current environment, not describing things like "if you change aaa in protocol bbb, then ipfix can also play an important rile in environment zzz". Such a story in my view would ne more of a "overview of possible uses of IPfix" as opposed to an AS for IPfix. Hope this helps to explain how I was looking at it. Bert > -----Original Message----- > From: Tanja Zseby [mailto:Tanja.Zseby@fokus.fraunhofer.de] > Sent: Sunday, March 19, 2006 11:33 > To: Wijnen, Bert (Bert); 'Ipfix Wg' (E-mail) (E-mail) > Cc: Dan Romascanu (E-mail); David Kessens (E-mail) > Subject: RE: [ipfix] AD review for: draft-ietf-ipfix-as-06.txt > > > Hi Bert, > > actually I am a bit surprised about your first comment. In the > applicability statement we want to show how IPFIX can be used for the > target applications mentioned in the requirement document and what are > the relations to other frameworks. Isnt this the role of an > applicability statement? We have critical statements in the > draft and at > nearly each IPFIX meeting I asked for further input for the section on > IPFIX limitations (I think at least some RMON and IPPM people attended > IPFIX meetings). > Personally I think IPFIX offers a lot of opportunites. But > comming from > a research institute I strongly dissociate myself from promoting any > product or solution without critical technical assessment. I would be > happy to discuss further opportunities and limitations of IPFIX and to > include these in the AS document. So comments from the other > groups are > highly welcome. > > Kind Regards, > Tanja > > > -----Original Message----- > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Wijnen, > Bert (Bert) > > Sent: Friday, March 17, 2006 6:34 PM > > To: 'Ipfix Wg' (E-mail) (E-mail) > > Cc: Dan Romascanu (E-mail); David Kessens (E-mail) > > Subject: [ipfix] AD review for: draft-ietf-ipfix-as-06.txt > > > > Sorry for the long delay. > > > > Overall question: > > > > Is this a document to describe realistic applicability of IPFIX, > > > > or > > > > Is it more of a marketing or promitional document to try and > > push itinto all sorts of existing systems? > > > > This is the first time I read this document, and I did find > > myself wondering several times if I was reading promotional > > material to convince me of all sorts of places where I could > > go use this. > > In many scenarios it would mean extending the Information > > Model, so it is not as if it would be a no-effort activity. > > > > As an AD I woner if the other groups have all looked at the > > scenarios that would touch or interact on their turf so to speak. > > Like has WGs like IPPM, AAA, IDMEF, RMONMIB, RTP etc looked at this? > > It seems there might be quite a set of questions from there. > > > > And then there is the question if operators really want IPFIX > > to be interacting/integrating with all these other areas. > > Maybe they do. Have you (WG) proof of that or expressions of > > support from operators? > > > > So I am not yet how to move ahead with this one. > > It is targeted for Informational, so we have some leverage. > > But I'd like to have some answers on the above first. > > > > Meanwhile, below are some nits to look at: > > > > - IPv4 sample addresses should be from the range 192.0.2.0/24 as > > per RFC3330. So you better update the addresses on page 6. > > > > - the last sentence on page 7 spaking about PSAMP seems > > a bit out of place in the middle of a discussion of > > using IPFIX for IDS. > > > > - citation/reference issues > > those with a - in the middle might be OK, my tool does not (yet) > > recognize linebreak at such points. > > > > !! Missing citation for Informative reference: > > P021 L046: [DuGr00] Nick Duffield, Matthias > > Grossglauser, "Trajectory > > > > !! Missing citation for Informative reference: > > P021 L051: [GrDM98] Ian D. Graham, Stephen F. > > Donnelly, Stele Martin, > > > > !! Missing Reference for citation: [PSAMP-FM] > > P018 L012: requirements in [PSAMP-FM] that directly > > affect the export > > > > !! Missing Reference for citation: [PSAMP-PROTOCOL] > > P018 L013: protocol. In [PSAMP-PROTOCOL] the > > requirements have been > > > > !! Missing citation for Informative reference: > > P022 L012: [PSAMP-FW] Nick Duffield (Ed.), "A > > Framework for Packet > > > > !! Missing citation for Informative reference: > > P022 L051: [RFC3577] S. Waldbusser, R. Cole, C. > Kalbfleisch, > > > > > > Bert > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" > > in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From toibabur@ucs.ubc.ca Sun Mar 19 22:09:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLAls-0006Dc-0L for ipfix-archive@lists.ietf.org; Sun, 19 Mar 2006 22:09:28 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLAlq-0006E2-OV for ipfix-archive@lists.ietf.org; Sun, 19 Mar 2006 22:09:27 -0500 Received: from host81-158-73-149.range81-158.btcentralplus.com ([81.158.73.149] helo=ucs.ubc.ca) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FLAPF-0000pd-00 for ipfix-list@mil.doit.wisc.edu; Sun, 19 Mar 2006 20:46:05 -0600 Message-ID: <000001c64bc8$6beca0d0$b961a8c0@epi82> Reply-To: "Toiba Burgamy" From: "Toiba Burgamy" To: ipfix-list@mil.doit.wisc.edu Subject: Re: news Date: Sun, 19 Mar 2006 21:46:00 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C64B9E.831698D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?81.158.73.149 X-Spam-Score: 2.5 (++) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C64B9E.831698D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Do you want to w O s V v E m R v P s A s Y for your i M m e m d j i c a r c u t p i e o n n l s? =20 Nothing like you need it, m S g a k v b e over l 5 u 0 i % with http://mymo56.headdressmanto.com ------=_NextPart_000_0001_01C64B9E.831698D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Do you want to w O s V v E m R v P s A s Y for your i M m e m d j i c a r c u t p i e o n n l s?
 
Nothing like you need it, m S g a k v b e over l 5 u 0 i % with http://mymo56.headdressmanto.co= m
------=_NextPart_000_0001_01C64B9E.831698D0-- From majordomo@mil.doit.wisc.edu Mon Mar 20 13:06:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLOm6-0005mO-95 for ipfix-archive@lists.ietf.org; Mon, 20 Mar 2006 13:06:38 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLOm4-0004PR-S1 for ipfix-archive@lists.ietf.org; Mon, 20 Mar 2006 13:06:38 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FLORq-0007e2-00 for ipfix-list@mil.doit.wisc.edu; Mon, 20 Mar 2006 11:45:42 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FLORo-0007dp-00 for ipfix@net.doit.wisc.edu; Mon, 20 Mar 2006 11:45:40 -0600 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 k2KHjUu23543; Mon, 20 Mar 2006 18:45:30 +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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipfix] AD review for: draft-ietf-ipfix-as-06.txt Date: Mon, 20 Mar 2006 18:45:28 +0100 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA10C8306@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ipfix] AD review for: draft-ietf-ipfix-as-06.txt Thread-Index: AcZLh50gWbQw7I6gTKyw4dP0S/LqbQAvj9dw From: "Tanja Zseby" To: "Wijnen, Bert \(Bert\)" , "'Ipfix Wg' \(E-mail\) \(E-mail\)" Cc: "Dan Romascanu \(E-mail\)" , "David Kessens \(E-mail\)" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Hi Bert, o.k. I see. As far as I understand RFC2026 an AS should also look at how different technical specifictaions may be combined. But you are probably right that the draft contains more "exotic" examples than usual. I will discuss this with Nevil and the group. Trying to get some feedback from chairs of the mentioned groups is a good idea anyway. Kind Regards, Tanja > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 > Sent: Sunday, March 19, 2006 8:01 PM > To: Tanja Zseby; 'Ipfix Wg' (E-mail) (E-mail) > Cc: Dan Romascanu (E-mail); David Kessens (E-mail) > Subject: RE: [ipfix] AD review for: draft-ietf-ipfix-as-06.txt >=20 > Tanja, >=20 > I may have to go back to read RFC2026 as to what an AS is meant to do. > It starts in sect 3.2 in 2026. >=20 > I guess you could take your viewpoint. >=20 > I may have overreacted, I tend to look for a statement that=20 > explains how to pragmatically use it in current environment,=20 > not describing things like "if you change aaa in protocol=20 > bbb, then ipfix can also play an important rile in environment zzz". > Such a story in my view would ne more of a "overview of=20 > possible uses of IPfix" > as opposed to an AS for IPfix. >=20 > Hope this helps to explain how I was looking at it. >=20 > Bert >=20 > > -----Original Message----- > > From: Tanja Zseby [mailto:Tanja.Zseby@fokus.fraunhofer.de] > > Sent: Sunday, March 19, 2006 11:33 > > To: Wijnen, Bert (Bert); 'Ipfix Wg' (E-mail) (E-mail) > > Cc: Dan Romascanu (E-mail); David Kessens (E-mail) > > Subject: RE: [ipfix] AD review for: draft-ietf-ipfix-as-06.txt > >=20 > >=20 > > Hi Bert, > >=20 > > actually I am a bit surprised about your first comment. In the=20 > > applicability statement we want to show how IPFIX can be=20 > used for the=20 > > target applications mentioned in the requirement document=20 > and what are=20 > > the relations to other frameworks. Isnt this the role of an=20 > > applicability statement? We have critical statements in the=20 > draft and=20 > > at nearly each IPFIX meeting I asked for further input for=20 > the section=20 > > on IPFIX limitations (I think at least some RMON and IPPM people=20 > > attended IPFIX meetings). > > Personally I think IPFIX offers a lot of opportunites. But comming=20 > > from a research institute I strongly dissociate myself from=20 > promoting=20 > > any product or solution without critical technical=20 > assessment. I would=20 > > be happy to discuss further opportunities and limitations=20 > of IPFIX and=20 > > to include these in the AS document. So comments from the=20 > other groups=20 > > are highly welcome. > >=20 > > Kind Regards, > > Tanja > >=20 > > > -----Original Message----- > > > From: majordomo listserver > > > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Wijnen, > > Bert (Bert) > > > Sent: Friday, March 17, 2006 6:34 PM > > > To: 'Ipfix Wg' (E-mail) (E-mail) > > > Cc: Dan Romascanu (E-mail); David Kessens (E-mail) > > > Subject: [ipfix] AD review for: draft-ietf-ipfix-as-06.txt > > >=20 > > > Sorry for the long delay. > > >=20 > > > Overall question: > > >=20 > > > Is this a document to describe realistic applicability of IPFIX, > > >=20 > > > or > > >=20 > > > Is it more of a marketing or promitional document to try and > > > push itinto all sorts of existing systems? > > >=20 > > > This is the first time I read this document, and I did=20 > find myself=20 > > > wondering several times if I was reading promotional material to=20 > > > convince me of all sorts of places where I could go use this. > > > In many scenarios it would mean extending the Information=20 > Model, so=20 > > > it is not as if it would be a no-effort activity. > > >=20 > > > As an AD I woner if the other groups have all looked at the=20 > > > scenarios that would touch or interact on their turf so to speak. > > > Like has WGs like IPPM, AAA, IDMEF, RMONMIB, RTP etc=20 > looked at this? > > > It seems there might be quite a set of questions from there. > > >=20 > > > And then there is the question if operators really want=20 > IPFIX to be=20 > > > interacting/integrating with all these other areas. > > > Maybe they do. Have you (WG) proof of that or expressions=20 > of support=20 > > > from operators? > > >=20 > > > So I am not yet how to move ahead with this one. > > > It is targeted for Informational, so we have some leverage. > > > But I'd like to have some answers on the above first. > > >=20 > > > Meanwhile, below are some nits to look at: > > >=20 > > > - IPv4 sample addresses should be from the range 192.0.2.0/24 as > > > per RFC3330. So you better update the addresses on page 6. > > >=20 > > > - the last sentence on page 7 spaking about PSAMP seems > > > a bit out of place in the middle of a discussion of > > > using IPFIX for IDS. > > >=20 > > > - citation/reference issues > > > those with a - in the middle might be OK, my tool does not (yet) > > > recognize linebreak at such points. > > >=20 > > > !! Missing citation for Informative reference: > > > P021 L046: [DuGr00] Nick Duffield, Matthias=20 > > > Grossglauser, "Trajectory > > >=20 > > > !! Missing citation for Informative reference: > > > P021 L051: [GrDM98] Ian D. Graham, Stephen F.=20 > > > Donnelly, Stele Martin, > > >=20 > > > !! Missing Reference for citation: [PSAMP-FM] > > > P018 L012: requirements in [PSAMP-FM] that directly=20 > > > affect the export > > >=20 > > > !! Missing Reference for citation: [PSAMP-PROTOCOL] > > > P018 L013: protocol. In [PSAMP-PROTOCOL] the=20 > > > requirements have been > > >=20 > > > !! Missing citation for Informative reference: > > > P022 L012: [PSAMP-FW] Nick Duffield (Ed.), "A=20 > > > Framework for Packet > > >=20 > > > !! Missing citation for Informative reference: > > > P022 L051: [RFC3577] S. Waldbusser, R. Cole, C.=20 > > Kalbfleisch, > > >=20 > > >=20 > > > Bert > > >=20 > > > -- > > > Help mailto:majordomo@net.doit.wisc.edu and say "help"=20 > > > in message body > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say=20 > "unsubscribe=20 > > > ipfix" in message body > > > Archive http://ipfix.doit.wisc.edu/archive/ > > >=20 > > >=20 > >=20 >=20 >=20 -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Mar 20 16:39:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLS6P-0000yD-Vv for ipfix-archive@lists.ietf.org; Mon, 20 Mar 2006 16:39:49 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLS6N-00058g-Nf for ipfix-archive@lists.ietf.org; Mon, 20 Mar 2006 16:39:49 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FLS1f-0007Pj-00 for ipfix-list@mil.doit.wisc.edu; Mon, 20 Mar 2006 15:34:55 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FLS1c-0007O0-00 for ipfix@net.doit.wisc.edu; Mon, 20 Mar 2006 15:34:52 -0600 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 k2KLYps10665 for ; Mon, 20 Mar 2006 22:34:51 +0100 (CET) Received: from [10.21.97.68] (sjc-vpn1-324.cisco.com [10.21.97.68]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k2KLYlC25267; Mon, 20 Mar 2006 22:34:47 +0100 (CET) Message-ID: <441F1FF6.2050702@cisco.com> Date: Mon, 20 Mar 2006 15:34:46 -0600 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ipfix CC: "Randall Stewart (cisco)" , Paul Aitken , Peter P Lei Subject: [ipfix] New draft: draft-bclaise-ipfix-reliability-01.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Dear all, We posted a new version of draft-bclaise-ipfix-reliability before the deadline. However, trying to be a perfectionist, I made a mistake: I tried to correct the file name from draft-bclaise-ipfix-reliability to draft-claise-ipfix-reliability. That confused the internet draft administrators, as no matching file name was found. Sorry for this "mistake" conclusion: the internet draft, even if posted before the deadline, is not available. You can now find a copy at http://www.employees.org/~bclaise/public_files/draft-bclaise-ipfix-reliability-01.txt The major improvement is that RSERPOOL has been added. Regards, Benoit. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From cowdea@mail.dircon.net Tue Mar 21 16:04:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLo1J-0004pf-DD for ipfix-archive@lists.ietf.org; Tue, 21 Mar 2006 16:04:01 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLo1I-0002Oi-37 for ipfix-archive@lists.ietf.org; Tue, 21 Mar 2006 16:04:01 -0500 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FLnfp-0005c2-00 for ipfix-list@mil.doit.wisc.edu; Tue, 21 Mar 2006 14:41:49 -0600 Received: from mail.dircon.net (116.Red-213-97-170.staticIP.rima-tde.net [213.97.170.116]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k2LKfl1J008993 for ; Tue, 21 Mar 2006 14:41:48 -0600 Message-ID: <000001c64d27$db639e40$e4dea8c0@obq12> Reply-To: "Iole Cowden" From: "Iole Cowden" To: ipfix-list@mil.doit.wisc.edu Subject: Re: 9y2y522 news Date: Tue, 21 Mar 2006 15:41:40 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C64CFD.F28D9640" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.9 (+) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C64CFD.F28D9640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Do you want to j O w V w E j R b P a A o Y for your m M i e l d b i e a n c l t i i m o c n u s ? =20 Nothing like you need it, e S q a a v m e over s 5 b 0 d % with http://geocities.com/KazuerLinnGrey/ =20 i V x a r I l i y u j m $ t 105 30 ZN m p s i h l q l t s g C n i g a j I b i u s $ g 99 10 DQ n p b i u l c l f s k V r i o a g g e r k a $6 t 9 10 Oy d p w i r l q l h s ------=_NextPart_000_0001_01C64CFD.F28D9640 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Do you want to j O w V w E j R b P a A o Y for your m M i e l d b i e a n c l t i i m o c n u s ?
 
Nothing like you need it, e S q a a v m e over s 5 b 0 d % with http://geocities.com/Kazuer= LinnGrey/
 
i V x a r I l i y u j m $ t 105 30 ZN   m p s i h l q l t s
g C n i g a j I b i u s $ g 99 10 DQ   n p b i u l c l f s
k V r i o a g g e r k a $6 t 9 10 Oy   d p w i r l q l h s
------=_NextPart_000_0001_01C64CFD.F28D9640-- From ardan@mexxxico.com Wed Mar 22 02:53:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLy9j-0001AS-2T for ipfix-archive@lists.ietf.org; Wed, 22 Mar 2006 02:53:23 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLy9h-00033o-Pn for ipfix-archive@lists.ietf.org; Wed, 22 Mar 2006 02:53:23 -0500 Received: from zaqdadcd105.zaq.ne.jp ([218.220.209.5] helo=-1212106560) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FLxmR-0003fV-00 for ipfix-list@mil.doit.wisc.edu; Wed, 22 Mar 2006 01:29:20 -0600 Received: from mexxxico.com (-1208903840 [-1208903800]) by zaqdadcd105.zaq.ne.jp (Qmailv1) with ESMTP id 746625A90C for ; Tue, 21 Mar 2006 23:31:37 -0800 Date: Tue, 21 Mar 2006 23:31:37 -0800 From: moneysup X-Mailer: The Bat! (v2.00.7) Personal X-Priority: 3 Message-ID: <6561298699.20060321233137@mexxxico.com> To: Ipfix Subject: Part Time JOB $2000 a week! MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter at zaqdadcd105.zaq.ne.jp X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?218.220.209.5 X-Spam-Score: 2.5 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de you can now make extra money working part time $2000 a week please visit http://www.moneysup.com for more details From majordomo@mil.doit.wisc.edu Wed Mar 22 12:39:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7J5-0006dS-L5 for ipfix-archive@lists.ietf.org; Wed, 22 Mar 2006 12:39:39 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM7J1-00011e-BS for ipfix-archive@lists.ietf.org; Wed, 22 Mar 2006 12:39:37 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FM6vU-00016C-00 for ipfix-list@mil.doit.wisc.edu; Wed, 22 Mar 2006 11:15:16 -0600 Received: from zeppo.itss.auckland.ac.nz ([130.216.190.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FM6vS-000165-00 for ipfix@net.doit.wisc.edu; Wed, 22 Mar 2006 11:15:15 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 61CA2358CB for ; Thu, 23 Mar 2006 05:15:13 +1200 (NZST) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28743-06 for ; Thu, 23 Mar 2006 05:15:13 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 46DBF35767 for ; Thu, 23 Mar 2006 05:15:13 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (localhost.localdomain [127.0.0.1]) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11) with ESMTP id k2MHFDev023887 for ; Thu, 23 Mar 2006 05:15:13 +1200 Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11/Submit) id k2MHFDFP023885 for ipfix@net.doit.wisc.edu; Thu, 23 Mar 2006 05:15:13 +1200 X-Authentication-Warning: motoko.itss.auckland.ac.nz: apache set sender to nevil@auckland.ac.nz using -f Received: from DHCP-Wired-65-241.ietf65.org (DHCP-Wired-65-241.ietf65.org [130.129.65.241]) by webmail.auckland.ac.nz (Horde MIME library) with HTTP; Thu, 23 Mar 2006 05:15:12 +1200 Message-ID: <20060323051512.xkc51gfmp6688okg@webmail.auckland.ac.nz> Date: Thu, 23 Mar 2006 05:15:12 +1200 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] Todays meeting ... MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 The IPFIX meeting is scheduled today, Wednesday 22 March, 1300-1500, in the Monet Ballroom. If you're using jabber, the room is ipfix@rooms.jabber.ietf.org Presentation slides (sent to me so far) are at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 (search for IPFIX in the Operations and Management Area) See you there ... Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland, New Zealand ----------------------------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 23 12:09:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTJs-0007n0-0t for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 12:09:56 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMTJq-00048Q-PW for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 12:09:55 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMT0A-0002DO-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Mar 2006 10:49:34 -0600 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMT09-0002DH-00 for ipfix@net.doit.wisc.edu; Thu, 23 Mar 2006 10:49:33 -0600 Date: Thu, 23 Mar 2006 10:49:33 -0600 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: [ipfix] DRAFT IPFIX meeting minutes, 65th IETF, Dallas Message-ID: <20060323164933.GA8437@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Organization: University of Wisconsin-Madison, DoIT Network Services X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL) X-URL: http://net.doit.wisc.edu/~plonka/ X-VMS-Error: %SYSTEM-F-NOTSQDEV, not a sequential device X-Shakespearean-Insult: Thou beslubbering hedge-born barnacle Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.6 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 IPFIXers, Please review the attached DRAFT minutes of the IPFIX meeting yesterday afternoon. You are welcome to send any follow-up comments/suggestions/ corrections to the list. The minutes can also be found here: http://ipfix.doit.wisc.edu/IETF65/minutes.txt Thanks to all those that participated, and to to Tanja and Ralf for their notes. Dave -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 23 12:11:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTLn-0001cG-EA for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 12:11:55 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMTLn-0004EV-1n for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 12:11:55 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMT41-0002KS-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Mar 2006 10:53:33 -0600 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMT40-0002KJ-00 for ipfix@net.doit.wisc.edu; Thu, 23 Mar 2006 10:53:32 -0600 Date: Thu, 23 Mar 2006 10:53:32 -0600 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 65th IETF, Dallas Message-ID: <20060323165332.GA8850@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu References: <20060323164933.GA8437@doit.wisc.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: <20060323164933.GA8437@doit.wisc.edu> User-Agent: Mutt/1.4.2.1i X-Organization: University of Wisconsin-Madison, DoIT Network Services X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL) X-URL: http://net.doit.wisc.edu/~plonka/ X-VMS-Error: %SYSTEM-F-ALTER, alter stack frames X-Shakespearean-Insult: Thou droning guts-griping bum-bailey Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.6 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This one actually has the attachment that I forgot to attach. ;^) On Thu, Mar 23, 2006 at 10:49:33AM -0600, Dave Plonka wrote: > IPFIXers, > > Please review the attached DRAFT minutes of the IPFIX meeting yesterday > afternoon. You are welcome to send any follow-up comments/suggestions/ > corrections to the list. -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="minutes.txt" DRAFT Minutes of the IP Flow Information eXport (IPFIX) WG 65th IETF, Dallas, Wednesday March 12, 2006 46 people in attendance submitted by Nevil Brownlee and Dave Plonka (co-chairs) based on notes from Ralf Wolter and Tanja Zseby. The text messaging log is available here: http://www.ietf.org/meetings/ietf-logs/ipfix@rooms.jabber.ietf.org/2006-03-22.html The meeting agenda and slides are available here: http://ipfix.doit.wisc.edu/IETF65/ [please see the agenda slides there for the sequence of topics: http://ipfix.doit.wisc.edu/IETF65/0-ietf65-ipfix-agenda.pdf ] ---- IPFIX Drafts Status (Nevil Brownlee) The chair reported that our Area Directors have reviewed all four drafts and had no serious concerns. He proposed one more editing iteration to fix the primarily editorial changes. Also, security considerations sections should be improved before last call. Regarding draft-ietf-ipfix-info-11, it was suggested that the draft include a template to be used to request new information elements. Also, the XML needs fixing. Regarding draft-ietf-ipfix-as-06, there were some concerns whether it properly documented situations in which IPFIX is most applicable and that some examples were "exotic" situations. The authors agreed to gather more feedback. The authors/editors present agreed to submit a new revision of their respective draft(s) by April 7, 2006, with the intent of these being submitted for IETF last call. ---- Interop Report (Elisa Boschi) Elisa reported on the second IPFIX Interop event March 1-2 in Salzburg. New issues were put into the Implementations Guidelines draft. [see slides for details: http://ipfix.doit.wisc.edu/IETF65/02-ietf65-ipfix-interop2.pdf ] ---- IPFIX Charter Discussion (Juergen Quittek) Juergen proposed that IPFIX recharter with a set of short term goals. Nevil suggested that they should be completed in less than one year and that the selections should encourage use of IPFIX as currently defined. To this end (below), we could select these goals from the existing set of IPFIX-related drafts. The chairs will propose a selection of these for discussion on the mailing list to determine consensus. Accordingly, a new charter incorporating those items will be proposed on the mailing list. [see slides for details: http://ipfix.doit.wisc.edu/IETF65/03-ietf65-ipfix-charter.ppt ] ---- The following candidate drafts were presented for consideration: daft-dressler-ipfix-aggregation-02 (Juergen Quittek) draft-boschi-ipfix-implementation-guidelines-01 (Elisa Boschi) draft-boschi-ipfix-reducing-redundancy-01 (Elisa Boschi) draft-bclaise-ipfix-reliability-01 (Benoit Claise) draft-trammel-ipfix-biflow-00 (Brian Trammel) draft-trammel-ipfix-file-00 (Brian Trammel) draft-kobayashi-ipfix-concentrator-model-01 (Atsushi Kobayashi) draft-kobayashi-ipfix-concentrator-mib-01 (Atsushi Kobayashi) draft-schmoll-ipfix-testing-00 (Paul Aitken) draft-stephan-isp-templates-01 (Emile Stephan) [see slides for details: http://ipfix.doit.wisc.edu/IETF65/ ] ---- PSAMP MIB / IPFIX MIB (Juergen Quittek) Juergen pointed out that there are two existing MIB drafts, PSAMP and the IPFIX concentrator MIB, which are nearly complete and could be combined and extended to form a single IPFIX MIB. [see slides for details: http://ipfix.doit.wisc.edu/IETF65/13-ietf65-ipfix-mib.ppt ] ---- Select Working Group Items, Establish new Milestones The chairs introduced discussion of the individual drafts (presented above), inviting suggestions as to which should be chosen as working group items. Dan Romascanu said that working groups can consider API-like work such as file formats, in IPFIX' case. Also he suggested that we mention only the high priority items in a new charter, rather than listing also potential future work. It was suggested that, in rechartering, we consider whether the group is defining probes' functionality or just a transport protocol. Under the existing charter it may have been a combination of both. In response, Dan mentioned that security and reliability concerns sometimes require that both be considered. There was general support in the room for the implementation guidelines and testing drafts as new working group items. On behalf of the security community, support was expressed for the biflow and file drafts. Also efficiency improvements, i.e. the reducing redundancy draft. A number of participants showed support for an IPFIX MIB. It was mentioned that some 20% of flow users use flow export for accounting and billing, so may benefit significantly from the reliability draft being selected. It was discussed whether or not some of the drafts' efforts would benefit from dramatic change in the protocol, such as a structured, multi-level information model, and therefore be deferred. In response it was pointed out that that could be many years away, and therefore a near-term solution must use only existing IPFIX features. The question was raised about how to select amongst the drafts. It was suggested that the drafts' number of authors/editors and dedicated reviewers could help to decide amongst too many "acceptable" drafts. Discussion regarding the choice amongst these candidate drafts will proceed to the mailing list. Nevil will propose a list to begin discussion there. -- $Id: minutes.txt,v 1.2 2006/03/23 16:30:27 dplonka Exp $ --liOOAslEiF7prFVr-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 23 14:33:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVZF-0006ZA-4j for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 14:33:57 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMVZD-0001OC-Px for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 14:33:57 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMVVR-0001TJ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Mar 2006 13:30:01 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMVVP-0001So-00 for ipfix@net.doit.wisc.edu; Thu, 23 Mar 2006 13:30:00 -0600 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 23 Mar 2006 20:29:59 +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 k2NJTw36013583; Thu, 23 Mar 2006 20:29:58 +0100 (MET) Received: from [10.89.16.75] (rcdn-vpn-cluster-1-75.cisco.com [10.89.16.75]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA12780; Thu, 23 Mar 2006 19:29:48 GMT Message-ID: <4422F726.2040103@cisco.com> Date: Thu, 23 Mar 2006 19:29:42 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu CC: plonka@doit.wisc.edu Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 65th IETF, Dallas References: <20060323164933.GA8437@doit.wisc.edu> <20060323165332.GA8850@doit.wisc.edu> In-Reply-To: <20060323165332.GA8850@doit.wisc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Dave Plonka wrote: > This one actually has the attachment that I forgot to attach. ;^) Thanks Dave. I have some comments inline to help kick off the next round of discussions. People should bear in mind that these are just my opinions and a lively discussion is welcomed. > IPFIX Drafts Status (Nevil Brownlee) > > The chair reported that our Area Directors have reviewed all four > drafts and had no serious concerns. He proposed one more editing > iteration to fix the primarily editorial changes. Also, security > considerations sections should be improved before last call. I attended the Security Tutorial on Sunday. It's primary focus was on what should be written in the security considerations of an RFC. A summary of what is being looked for is to produce a set of security problems which should be addressed, and detail how they are addressed. For example, in the IPFIX protocol, the problems include: Integrity Knowing the received records are from authorised exporters (i.e. not spoofed). Privacy Protecting the messages from eavesdropping. Knowing you are exporting to authorised receiver. These problems may well be covered by the authentication and encryption functionality of IPSEC, but it needs to be demonstrated that these issues have been thought about and addressed. > IPFIX Charter Discussion (Juergen Quittek) > > Juergen proposed that IPFIX recharter with a set of short term goals. > Nevil suggested that they should be completed in less than one year and > that the selections should encourage use of IPFIX as currently > defined. I agree with Nevil's statement from yesterday, and to a large extent Carter's feelings. I feel the next goal of the working group should be to encourage the use of the IPFIX protocol in commercial products for a wide range of real-world applications. We should focus on the drafts which aid implementation: draft-boschi-ipfix-implementation-guidelines-01 (Elisa Boschi) draft-schmoll-ipfix-testing-00 (Paul Aitken) and those which extend the protocol in ways which will encourage adoption: draft-boschi-ipfix-reducing-redundancy-01 (Elisa Boschi) draft-bclaise-ipfix-reliability-01 (Benoit Claise) draft-trammel-ipfix-biflow-00 (Brian Trammel) As mentioned, the choice of WG items should also take into consideration the maturity, WG support and WG agreement on approach. I feel that drafts like the aggregation and concentrator are a premature. They're focus is the manipulation of IPFIX data and, at the moment, there is a lack of devices which generate this data. From the opening introduction of the aggregation draft: "Flow measurement in high-speed large-scale networks easily produces huge amount of data that can not be handled by a single IPFIX collector or analyzer." The solution will hopefully be as simple as re-configuring your IPFIX devices to use the flow keys your really want. If the implantations are found to have a fixed set of flow keys and you can't configure a subset, then perhaps some form of aggregation will become necessary, but we shouldn't be solving hypothetical issues. regards Andrew -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 23 15:04:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMW2w-00086r-Tl for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 15:04:38 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMW2v-0003BW-Fj for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 15:04:38 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMVyw-0002PZ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Mar 2006 14:00:30 -0600 Received: from mailhub.lawrence.edu ([143.44.0.14] helo=lawrence.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMVyv-0002PS-00 for ipfix@net.doit.wisc.edu; Thu, 23 Mar 2006 14:00:29 -0600 Received: from [143.44.160.16] (account lower [143.44.160.16] verified) by lawrence.edu (CommuniGate Pro SMTP 5.0.6) with ESMTPA id 15518803; Thu, 23 Mar 2006 14:00:26 -0600 Message-ID: <4422FE58.7090809@lawrence.edu> Date: Thu, 23 Mar 2006 14:00:24 -0600 From: Robert Lowe Organization: Lawrence University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: plonka@doit.wisc.edu CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 65th IETF, Dallas References: <20060323164933.GA8437@doit.wisc.edu> <20060323165332.GA8850@doit.wisc.edu> In-Reply-To: <20060323165332.GA8850@doit.wisc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 From the meeting minutes... > It was suggested that, in rechartering, we consider whether the group > is defining probes' functionality or just a transport protocol. Under > the existing charter it may have been a combination of both. In > response, Dan mentioned that security and reliability concerns > sometimes require that both be considered. I'm not sure I understand what is being questioned or proposed. Anyone care to elaborate? They seem unrelated to me. > A number of participants showed support for an IPFIX MIB. For the purpose of exposing what part of IPFIX? Configuration items? -Robert -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 23 15:06:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMW4L-0000z5-9D for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 15:06:05 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMW4H-0003H1-Ti for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 15:06:05 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMW0k-0002Vw-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Mar 2006 14:02:22 -0600 Received: from zeppo.itss.auckland.ac.nz ([130.216.190.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMW0i-0002Vr-00 for ipfix@net.doit.wisc.edu; Thu, 23 Mar 2006 14:02:21 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 6DAAB34AD5 for ; Fri, 24 Mar 2006 08:02:19 +1200 (NZST) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17407-30 for ; Fri, 24 Mar 2006 08:02:19 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 3EED734AE2 for ; Fri, 24 Mar 2006 08:02:19 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (localhost.localdomain [127.0.0.1]) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11) with ESMTP id k2NK2J0l005066 for ; Fri, 24 Mar 2006 08:02:19 +1200 Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11/Submit) id k2NK2IeT005064 for ipfix@net.doit.wisc.edu; Fri, 24 Mar 2006 08:02:18 +1200 X-Authentication-Warning: motoko.itss.auckland.ac.nz: apache set sender to nevil@auckland.ac.nz using -f Received: from DHCP-Wireless-128-236.ietf65.org (DHCP-Wireless-128-236.ietf65.org [130.129.128.236]) by webmail.auckland.ac.nz (Horde MIME library) with HTTP; Fri, 24 Mar 2006 08:02:18 +1200 Message-ID: <20060324080218.f09rbbgcuv34kwww@webmail.auckland.ac.nz> Date: Fri, 24 Mar 2006 08:02:18 +1200 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] PROPOSED list of WG items for new charter MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Hi all: At our IPFIX meeting yesterday we discussed the following individual drafts: draft-dressler-ipfix-aggregation-02 (Juergen Quittek) draft-boschi-ipfix-implementation-guidelines-01 (Elisa Boschi) draft-boschi-ipfix-reducing-redundancy-01 (Elisa Boschi) draft-bclaise-ipfix-reliability-01 (Benoit Claise) draft-trammel-ipfix-biflow-00 (Brian Trammel) draft-trammel-ipfix-file-00 (Brian Trammel) draft-kobayashi-ipfix-concentrator-model-01 (Atsushi Kobayashi) draft-kobayashi-ipfix-concentrator-mib-01 (Atsushi Kobayashi) draft-schmoll-ipfix-testing-00 (Paul Aitken) draft-stephan-isp-templates-01 (Emile Stephan) In my opinion .. * draft-boschi-ipfix-implementation-guidelines-01 (Elisa Boschi) * draft-schmoll-ipfix-testing-00 (Paul Aitken) There was clear consensus that these two are nearly complete, and should become WG items. * draft-boschi-ipfix-reducing-redundancy-01 (Elisa Boschi) comes from an earlier PSAMP draft (per-packet info), and is also nearly complete. It requires one new Information Elelement, CommonPropertiesID, but no changes to the IPFIX protocol. * draft-kobayashi-ipfix-concentrator-mib-01 (Atsushi Kobayashi) At the meeting, Juergen Quittek pointed out that quite a lot of MIB development work has been done in PSAMP, and that this draft adds some IPFIX objects to that. Meeting consensus was that an IPFIX MIB (to provide monitoring capability for IPFIX and PSAMP processes) can be completed within a year. 3 people at the meeting stated that they'd work on a MIB, and another teo volunteered to review the drafts. * draft-trammel-ipfix-biflow-00 (Brian Trammel) There is [FlowCon, Sep 05] a clear need for users to create IE's with more structure. That would require extensions to the IPFIX Info Model, allowing it to be more 'multi-dimensinal;' that's clearly future work. However, it would be useful to have a well-understood, simple, way to handle biflows now, using the exisiting Info Model - that's what this draft addresses. The remaining drafts all cover ongoing work by various individuals and groups, but I think they're all in 'early stages,' i.e. they need quite a bit more discussion and development within the IPFIX community. - draft-dressler-ipfix-aggregation-02 (Juergen Quittek) - draft-kobayashi-ipfix-concentrator-model-01 (Atsushi Kobayashi) - draft-bclaise-ipfix-reliability-01 (Benoit Claise) - draft-stephan-isp-templates-01 (Emile Stephan) - draft-trammel-ipfix-file-00 (Brian Trammel) In our new charter, I propose that we take on the following as WG items (estimated delivery times in parenthises): 1. IPFIX Implementation Guidelines draft, to be an Informational RFC (6 months) 2. IPFIX Testing draft, to be an Informational RFC (6 months) 3. IPFIX MIB, to be an Informational RFC (12 months) 4 IPFIX Biflow draft, to be an Informational RFC (6 months) Please consider this, and send your comments to the IPFIX list. Remember, we need you feedback - if you agree with this proposal, send a note to say so. I'd like to reach consensus on this by 7 April 06. Once we have that consensus, we'll develop the new charter and discuss that on the list. (Meanwhile, we'll be working hard to revise our current drafts, and get them into IETF Last Call!) Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland, New Zealand ----------------------------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 23 15:21:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWJX-0003he-Fk for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 15:21:47 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMWJW-00043K-74 for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 15:21:47 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMWG0-0003ek-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Mar 2006 14:18:08 -0600 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMWFz-0003eb-00 for ipfix@net.doit.wisc.edu; Thu, 23 Mar 2006 14:18:07 -0600 Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by nj300815-ier2.net.avaya.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2NKGuQY014943 for ; Thu, 23 Mar 2006 15:16:56 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id k2NKEvhj025933 for ; Thu, 23 Mar 2006 15:14:58 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 65th IETF, Dallas Date: Thu, 23 Mar 2006 22:18:05 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ipfix] DRAFT IPFIX meeting minutes, 65th IETF, Dallas Thread-Index: AcZOm8xIXqp8r3ZaRT6UG0vP7MCK8AAGtSUw From: "Romascanu, Dan \(Dan\)" To: , X-Scanner: InterScan AntiVirus for Sendmail Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Wrt.=20 > Dan Romascanu said that working groups can consider API-like work such > as file formats, in IPFIX' case.=20 My comment was related to a bullet in the slideware about 'the IETF does not accept work on APIs' - I do not remember the exact wording. I pointed to the fact that lately this restriction seems to have been relaxed, and API documents could become candidates of IETF work on the informational track.=20 Dan =20 =20 > -----Original Message----- > From: majordomo listserver=20 > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Dave Plonka > Sent: Thursday, March 23, 2006 6:50 PM > To: ipfix@net.doit.wisc.edu > Subject: [ipfix] DRAFT IPFIX meeting minutes, 65th IETF, Dallas >=20 > IPFIXers, >=20 > Please review the attached DRAFT minutes of the IPFIX meeting=20 > yesterday afternoon. You are welcome to send any follow-up=20 > comments/suggestions/ corrections to the list. >=20 > The minutes can also be found here: >=20 > http://ipfix.doit.wisc.edu/IETF65/minutes.txt >=20 > Thanks to all those that participated, and to to Tanja and=20 > Ralf for their notes. >=20 > Dave >=20 > -- > plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka =20 > ARS:N9HZF Madison, WI >=20 > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help"=20 > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say=20 > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ >=20 -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 23 15:32:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWTd-0002Zi-UK for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 15:32:13 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMWTc-0004SE-Li for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 15:32:13 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMWDo-0003aK-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Mar 2006 14:15:52 -0600 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMWDn-0003aB-00 for ipfix@net.doit.wisc.edu; Thu, 23 Mar 2006 14:15:51 -0600 Received: from tierw.net.avaya.com (h198-152-13-100.avaya.com [198.152.13.100]) by co300216-ier2.net.avaya.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2NKEwVw002702 for ; Thu, 23 Mar 2006 15:14:58 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id k2NJxjYj010886 for ; Thu, 23 Mar 2006 14:59:46 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 65th IETF, Dallas Date: Thu, 23 Mar 2006 22:15:48 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ipfix] DRAFT IPFIX meeting minutes, 65th IETF, Dallas Thread-Index: AcZOtMKFjjK444hNShuvomPYSgM6pQAAQivA From: "Romascanu, Dan \(Dan\)" To: "Robert Lowe" , Cc: X-Scanner: InterScan AntiVirus for Sendmail Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 =20 =20 > -----Original Message----- > From: majordomo listserver=20 > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Robert Lowe > Sent: Thursday, March 23, 2006 10:00 PM > To: plonka@doit.wisc.edu > Cc: ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 65th IETF, Dallas >=20 > From the meeting minutes... >=20 > > It was suggested that, in rechartering, we consider whether=20 > the group=20 > > is defining probes' functionality or just a transport=20 > protocol. Under=20 > > the existing charter it may have been a combination of both. In=20 > > response, Dan mentioned that security and reliability concerns=20 > > sometimes require that both be considered. >=20 > I'm not sure I understand what is being questioned or proposed. > Anyone care to elaborate? They seem unrelated to me. >=20 My comment addressed specifically a proposal related to ipfix deployment in ISP environment. I believe that there are increased security concerns in these environments related to the authentication of probes with collectors, and I recommended that the authors do not miss to address these issues. As there is work for defining a similar model in rmon, I suggested that the authors have a look at that work (more exactly the updated raqmon-pdu draft, that will be published in a few days).=20 Dan -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 23 17:43:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMYX4-00071c-QZ for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 17:43:54 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMYX0-0002Y7-HR for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 17:43:54 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMYRk-00028P-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Mar 2006 16:38:24 -0600 Received: from chico.itss.auckland.ac.nz ([130.216.190.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMYRj-00028E-00 for ipfix@net.doit.wisc.edu; Thu, 23 Mar 2006 16:38:23 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id B3FEC3561A for ; Fri, 24 Mar 2006 10:37:00 +1200 (NZST) Received: from chico.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06500-07 for ; Fri, 24 Mar 2006 10:37:00 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 982E9355FC for ; Fri, 24 Mar 2006 10:37:00 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (localhost.localdomain [127.0.0.1]) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11) with ESMTP id k2NMb069004406 for ; Fri, 24 Mar 2006 10:37:00 +1200 Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11/Submit) id k2NMb0ui004404 for ipfix@net.doit.wisc.edu; Fri, 24 Mar 2006 10:37:00 +1200 X-Authentication-Warning: motoko.itss.auckland.ac.nz: apache set sender to nevil@auckland.ac.nz using -f Received: from DHCP-Wired-65-241.ietf65.org (DHCP-Wired-65-241.ietf65.org [130.129.65.241]) by webmail.auckland.ac.nz (Horde MIME library) with HTTP; Fri, 24 Mar 2006 10:37:00 +1200 Message-ID: <20060324103700.ec8qt11imylcgwsg@webmail.auckland.ac.nz> Date: Fri, 24 Mar 2006 10:37:00 +1200 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: Oops: [ipfix] PROPOSED list of WG items References: <20060324080218.f09rbbgcuv34kwww@webmail.auckland.ac.nz> In-Reply-To: <20060324080218.f09rbbgcuv34kwww@webmail.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Hi again: Several people have emailed to point out that I left 'reducing redundancy' off my proposed list. What I meant to say was .. > In our new charter, I propose that we take on the following as > WG items (estimated delivery times in parenthises): 1. IPFIX Implementation Guidelines draft, to be an Informational RFC (6 months) 2. IPFIX Testing draft, to be an Informational RFC (6 months) 3. IPFIX Reducung Reduncy, to be an Informational RFC (6 months) 4. IPFIX MIB, to be an Informational RFC (12 months) 5. IPFIX Biflow draft, to be an Informational RFC (6 months) > Please consider this, and send your comments to the IPFIX list. > Remember, we need you feedback - if you agree with this proposal, > send a note to say so. Just a little too quick with my 'send email' button, sorry. Cheers again, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland, New Zealand ----------------------------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 23 17:59:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMYmQ-0003mG-6J for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 17:59:46 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMYmO-0002wt-Pd for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 17:59:46 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMYi0-00036v-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Mar 2006 16:55:12 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMYhz-00036d-00 for ipfix@net.doit.wisc.edu; Thu, 23 Mar 2006 16:55:11 -0600 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 k2NMtAo16721; Thu, 23 Mar 2006 23:55: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 k2NMt7C12020; Thu, 23 Mar 2006 23:55:08 +0100 (CET) Message-ID: <4423274B.3060201@cisco.com> Date: Thu, 23 Mar 2006 16:55:07 -0600 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Nevil Brownlee CC: ipfix@net.doit.wisc.edu Subject: Re: Oops: [ipfix] PROPOSED list of WG items References: <20060324080218.f09rbbgcuv34kwww@webmail.auckland.ac.nz> <20060324103700.ec8qt11imylcgwsg@webmail.auckland.ac.nz> In-Reply-To: <20060324103700.ec8qt11imylcgwsg@webmail.auckland.ac.nz> Content-Type: multipart/alternative; boundary="------------040205020907080109040909" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.1 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 This is a multi-part message in MIME format. --------------040205020907080109040909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nevil Brownlee wrote: > > Hi again: > > Several people have emailed to point out that I left 'reducing > redundancy' off my proposed list. What I meant to say was .. > >> In our new charter, I propose that we take on the following as >> WG items (estimated delivery times in parenthises): > > 1. IPFIX Implementation Guidelines draft, to be an Informational RFC > (6 months) > 2. IPFIX Testing draft, to be an Informational RFC (6 months) > > 3. IPFIX Reducung Reduncy, to be an Informational RFC (6 months) > > 4. IPFIX MIB, to be an Informational RFC (12 months) > 5. IPFIX Biflow draft, to be an Informational RFC (6 months) I support: 1. IPFIX Implementation Guidelines 2. IPFIX Testing draft 3. IPFIX Reducing Redundancy 4. IPFIX MIB. By the way, shouldn't be standard track. I was trying to find whether the PSAMP MIB would be standard track or not, but couldn't I have some concerns about the biflow, which proposed several solutions, without precisely telling which one to choose: 1. record adjacency -> the collector can assume the exporter will always to do this. 2. reverse counters -> yet an extra dimension in the information model 3. multiple I.Es. -> potentially some ambiguities Note that I don't have the perfect solution without IPFIX version 2, as I explained on the list So I'm not sure we have a consensus on the approach to adopt, which was a requirement for the new work charter, as far as I understood. I would consider the biflow exactly as the reliability draft: some extra work is required. Regards, Benoit. > >> Please consider this, and send your comments to the IPFIX list. >> Remember, we need you feedback - if you agree with this proposal, >> send a note to say so. > > Just a little too quick with my 'send email' button, sorry. > > Cheers again, Nevil > > ----------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITSS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland, New Zealand > > ----------------------------------------------------------------------- > This mail sent through University of Auckland http://www.auckland.ac.nz > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ --------------040205020907080109040909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nevil Brownlee wrote:

Hi again:

Several people have emailed to point out that I left 'reducing
redundancy' off my proposed list.  What I meant to say was ..

In our new charter, I propose that we take on the following as
WG items (estimated delivery times in parenthises):

1. IPFIX Implementation Guidelines draft, to be an Informational RFC
      (6 months)
2. IPFIX Testing draft, to be an Informational RFC  (6 months)

3. IPFIX Reducung Reduncy, to be an Informational RFC  (6 months)

4. IPFIX MIB, to be an Informational RFC (12 months)
5. IPFIX Biflow draft, to be an Informational RFC (6 months)
I support:
    1. IPFIX Implementation Guidelines
    2. IPFIX Testing draft
    3. IPFIX Reducing Redundancy
    4. IPFIX MIB. By the way, shouldn't be standard track.
        I was trying to find whether the PSAMP MIB would be standard track or not, but couldn't

I have some concerns about the biflow, which proposed several solutions, without precisely telling which one to choose:
  1. record adjacency -> the collector  can assume the  exporter will always to do this.
  2. reverse counters -> yet an extra dimension in the information model
  3. multiple I.Es. -> potentially some ambiguities
Note that I don't have the perfect solution without IPFIX version 2, as I explained on the list

So I'm not sure we have a consensus on the approach to adopt, which was a requirement for the new work charter, as far as I understood.
I would consider the biflow exactly as the reliability draft: some extra work is required.

Regards, Benoit.

Please consider this, and send your comments to the IPFIX list.
Remember, we need you feedback - if you agree with this proposal,
send a note to say so.

Just a little too quick with my 'send email' button, sorry.

Cheers again, Nevil

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

-----------------------------------------------------------------------
This mail sent through University of Auckland http://www.auckland.ac.nz


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

--------------040205020907080109040909-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 23 19:02:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMZl9-0005rp-Pj for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 19:02:31 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMZl8-0008KG-Gp for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 19:02:31 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMZgb-0005oE-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Mar 2006 17:57:49 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMZga-0005o5-00 for ipfix@net.doit.wisc.edu; Thu, 23 Mar 2006 17:57:48 -0600 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 24 Mar 2006 00:57: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 k2NNvj36017994; Fri, 24 Mar 2006 00:57:45 +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 XAA08081; Thu, 23 Mar 2006 23:57:43 GMT Message-ID: <442335F6.4000503@cisco.com> Date: Thu, 23 Mar 2006 23:57:42 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Benoit Claise CC: Nevil Brownlee , ipfix@net.doit.wisc.edu Subject: Re: Oops: [ipfix] PROPOSED list of WG items References: <20060324080218.f09rbbgcuv34kwww@webmail.auckland.ac.nz> <20060324103700.ec8qt11imylcgwsg@webmail.auckland.ac.nz> <4423274B.3060201@cisco.com> In-Reply-To: <4423274B.3060201@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Benoit Claise wrote: > Nevil Brownlee wrote: >> >> Hi again: >> >> Several people have emailed to point out that I left 'reducing >> redundancy' off my proposed list. What I meant to say was .. >> >>> In our new charter, I propose that we take on the following as >>> WG items (estimated delivery times in parenthises): >> >> 1. IPFIX Implementation Guidelines draft, to be an Informational RFC >> (6 months) >> 2. IPFIX Testing draft, to be an Informational RFC (6 months) >> >> 3. IPFIX Reducung Reduncy, to be an Informational RFC (6 months) >> >> 4. IPFIX MIB, to be an Informational RFC (12 months) >> 5. IPFIX Biflow draft, to be an Informational RFC (6 months) > I support: > 1. IPFIX Implementation Guidelines > 2. IPFIX Testing draft > 3. IPFIX Reducing Redundancy > 4. IPFIX MIB. By the way, shouldn't be standard track. I think you mean "shouldn't it be standard track?" I would think it would have to be standards track if we expect to mandate anything. > I was trying to find whether the PSAMP MIB would be standard > track or not, but couldn't > > I have some concerns about the biflow, which proposed several solutions, > without precisely telling which one to choose: > > 1. record adjacency -> the collector can assume the exporter will > always to do this. > 2. reverse counters -> yet an extra dimension in the information model > 3. multiple I.Es. -> potentially some ambiguities > > Note that I don't have the perfect solution without IPFIX version 2, as > I explained on the list > > So I'm not sure we have a consensus on the approach to adopt, which was > a requirement for the new work charter, as far as I understood. > I would consider the biflow exactly as the reliability draft: some extra > work is required. I thought we have a set of criteria for a draft to meet before being considered for working group adoption: * consensus of approach * maturity * support from the WG I agree that the biflow draft doesn't meet the first criteria yet. When it does, and that could be quite soon, we can consider it for WG adoption. regards Andrew -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 23 19:31:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMaDB-0004Oi-3f for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 19:31:29 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMaD9-00028v-SZ for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 19:31:29 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMa9m-0007FE-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Mar 2006 18:27:58 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMa9l-0007F5-00 for ipfix@net.doit.wisc.edu; Thu, 23 Mar 2006 18:27:57 -0600 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: [ipfix] Source ID -> Observation Domain Id? Content-Type: multipart/alternative; boundary="------------020101030407050604040503" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 23 20:06:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMalU-00042Y-6t for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 20:06:56 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMalQ-0003ki-UW for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 20:06:56 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMaiD-00013z-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Mar 2006 19:03:33 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMaiC-00013u-00 for ipfix@net.doit.wisc.edu; Thu, 23 Mar 2006 19:03:33 -0600 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 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 23 20:54:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMbVM-0003nr-O4 for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 20:54:20 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMbVK-0005kw-Ea for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 20:54:20 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMbP7-0003Jg-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Mar 2006 19:47:53 -0600 Received: from zeppo.itss.auckland.ac.nz ([130.216.190.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMbP6-0003JT-00 for ipfix@net.doit.wisc.edu; Thu, 23 Mar 2006 19:47:52 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 136FC3470D; Fri, 24 Mar 2006 13:47:51 +1200 (NZST) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15885-07; Fri, 24 Mar 2006 13:47:50 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id E98963451C; Fri, 24 Mar 2006 13:47:50 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (localhost.localdomain [127.0.0.1]) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11) with ESMTP id k2O1loOh010508; Fri, 24 Mar 2006 13:47:50 +1200 Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11/Submit) id k2O1loeU010505; Fri, 24 Mar 2006 13:47:50 +1200 X-Authentication-Warning: motoko.itss.auckland.ac.nz: apache set sender to nevil@auckland.ac.nz using -f Received: from DHCP-Wired-65-241.ietf65.org (DHCP-Wired-65-241.ietf65.org [130.129.65.241]) by webmail.auckland.ac.nz (Horde MIME library) with HTTP; Fri, 24 Mar 2006 13:47:50 +1200 Message-ID: <20060324134750.hlruoqum7hs88wc4@webmail.auckland.ac.nz> Date: Fri, 24 Mar 2006 13:47:50 +1200 From: Nevil Brownlee To: Benoit Claise Cc: ipfix@net.doit.wisc.edu Subject: Another Oops: [ipfix] PROPOSED list of WG items References: <20060324080218.f09rbbgcuv34kwww@webmail.auckland.ac.nz> <20060324103700.ec8qt11imylcgwsg@webmail.auckland.ac.nz> <4423274B.3060201@cisco.com> In-Reply-To: <4423274B.3060201@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Quoting Benoit Claise : >> 4. IPFIX MIB, to be an Informational RFC (12 months) > 4. IPFIX MIB. By the way, shouldn't be standard track. Oh dear, another bungle. MIBs have to run on lots of different devinces, and must interoperate. THat means they have to be Standards-track RFCs. Also .. > I have some concerns about the biflow, which proposed several > solutions, without precisely telling which one to choose: > ... In thinking about that, I assumed that the authors/editors would go on working on it so as to arrive at a single, elegant solution. I'd like to see something which was a viable short-term way to do biflows without needing significant changes to the current IPFIX protocol. As a by-product, this work could/should provide more input into longer-term development of the IPFIX Info Model. Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland, New Zealand ----------------------------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 23 20:56:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMbX3-0007NG-Qu for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 20:56:05 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMbX3-0005oF-IP for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 20:56:05 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMbSI-0003P7-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Mar 2006 19:51:10 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMbSH-0003P0-00 for ipfix@net.doit.wisc.edu; Thu, 23 Mar 2006 19:51:09 -0600 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 24 Mar 2006 02:51:09 +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 k2O1p836003936 for ; Fri, 24 Mar 2006 02:51:08 +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 BAA17953 for ; Fri, 24 Mar 2006 01:51:06 GMT Message-ID: <44235088.3000005@cisco.com> Date: Fri, 24 Mar 2006 01:51:04 +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: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] PROPOSED list of WG items for new charter References: <20060324080218.f09rbbgcuv34kwww@webmail.auckland.ac.nz> In-Reply-To: <20060324080218.f09rbbgcuv34kwww@webmail.auckland.ac.nz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Nevil, In my mind, and without prejudice to any of the authors or all their hard work so far, the IPFIX drafts fall into three groups: 1. Mature drafts, which can be completed soon and should be targetted for immediate completion: draft-boschi-ipfix-implementation-guidelines-01 draft-boschi-ipfix-reducing-redundancy-01 draft-schmoll-ipfix-testing-00 draft-kobayashi-ipfix-concentrator-mib-01 - this should be worked under the IPFIX MIB 2. Drafts which still require some work and should be targetted for phase 2: draft-dressler-ipfix-aggregation-02 draft-bclaise-ipfix-reliability-01 draft-trammel-ipfix-biflow-00 draft-kobayashi-ipfix-concentrator-model-01 3. Drafts whose value I'm unconvinced of: draft-trammel-ipfix-file-00 draft-stephan-isp-templates-01 > In our new charter, I propose that we take on the following as > WG items (estimated delivery times in parenthises): > > 1. IPFIX Implementation Guidelines draft, to be an Informational RFC > (6 months) > 2. IPFIX Testing draft, to be an Informational RFC (6 months) > 3. IPFIX MIB, to be an Informational RFC (12 months) And later you added: > IPFIX Reducung Reduncy, to be an Informational RFC (6 months) I'm happy with these. > 4 IPFIX Biflow draft, to be an Informational RFC (6 months) In my opinion, biflow isn't sufficiently mature to be completed in 6 months, even if it's possible to do biflow on a single box at all. I would prefer to see it in a second phase. One final point: many of these drafts call for new Information Elements. Do you feel that the processes for requesting, reviewing and approving new IE's have been clearly communicated to the WG? Cheers. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 23 22:27:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMcxV-0001uc-3D for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 22:27:29 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMcxR-0000he-R6 for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 22:27:29 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMcd9-0006dg-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Mar 2006 21:06:27 -0600 Received: from diotima.switch.ch ([130.59.4.87]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMcd8-0006dZ-00 for ipfix@net.doit.wisc.edu; Thu, 23 Mar 2006 21:06:26 -0600 Received: (from leinen@localhost) by diotima.switch.ch (8.13.5+Sun/8.13.5) id k2O3615E006391; Fri, 24 Mar 2006 04:06:01 +0100 (CET) To: Robert Lowe Cc: plonka@doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: IPFIX MIB [Re: [ipfix] DRAFT IPFIX meeting minutes, 65th IETF, Dallas] X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: <4422FE58.7090809@lawrence.edu> (Robert Lowe's message of "Thu, 23 Mar 2006 14:00:24 -0600") References: <20060323164933.GA8437@doit.wisc.edu> <20060323165332.GA8850@doit.wisc.edu> <4422FE58.7090809@lawrence.edu> Date: Fri, 24 Mar 2006 04:06:00 +0100 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Robert Lowe writes: >> A number of participants showed support for an IPFIX MIB. > For the purpose of exposing what part of IPFIX? Configuration > items? The focus is more on monitoring I think. Personally I use SNMP today for monitoring the performance of my (Net)flow exporters and collectors, using vendor-specific and home-grown MIBs, respectively. Standard MIB modules for common functions of IPFIX devices would be very useful. About configuration, Benoit mentioned that he doesn't really believe in the utility of SNMP "set"s for this, and I would agree. It might be more useful to specify IPFIX device configuration schemata for NETCONF, with the caveat that we don't (yet) have a standard data modeling language for NETCONF. But that hasn't prevented people to already work on such models even for IPFIX (well Netflow v9) meter/exporters, e.g. http://www.liberouter.org/netflow/flowmon-rng.php -- Simon. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 23 22:57:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMdQS-0003Iu-RM for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 22:57:24 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMdQP-0001sk-HU for ipfix-archive@lists.ietf.org; Thu, 23 Mar 2006 22:57:24 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMd8R-0000M7-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 Mar 2006 21:38:47 -0600 Received: from zeppo.itss.auckland.ac.nz ([130.216.190.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMd8Q-0000Ly-00 for ipfix@net.doit.wisc.edu; Thu, 23 Mar 2006 21:38:46 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 9F0D135AF9; Fri, 24 Mar 2006 15:38:44 +1200 (NZST) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14341-24; Fri, 24 Mar 2006 15:38:44 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 34D1735AFA; Fri, 24 Mar 2006 15:38:44 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (localhost.localdomain [127.0.0.1]) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11) with ESMTP id k2O3chHK030367; Fri, 24 Mar 2006 15:38:43 +1200 Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11/Submit) id k2O3chtX030365; Fri, 24 Mar 2006 15:38:43 +1200 X-Authentication-Warning: motoko.itss.auckland.ac.nz: apache set sender to nevil@auckland.ac.nz using -f Received: from DHCP-Wired-65-241.ietf65.org (DHCP-Wired-65-241.ietf65.org [130.129.65.241]) by webmail.auckland.ac.nz (Horde MIME library) with HTTP; Fri, 24 Mar 2006 15:38:43 +1200 Message-ID: <20060324153843.3fwnpab6stc08gsc@webmail.auckland.ac.nz> Date: Fri, 24 Mar 2006 15:38:43 +1200 From: Nevil Brownlee To: Paul Aitken Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] PROPOSED list of WG items for new charter References: <20060324080218.f09rbbgcuv34kwww@webmail.auckland.ac.nz> <44235088.3000005@cisco.com> In-Reply-To: <44235088.3000005@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hi again Paul: > One final point: many of these drafts call for new Information Elements. > > Do you feel that the processes for requesting, reviewing and > approving new IE's have been clearly communicated to the WG? Good point. I suspect not. Maybe you could put together a few paragraphs of text about that and post it to the IPFIX list? Thanks, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland, New Zealand ----------------------------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 24 02:54:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMh7V-000682-TP for ipfix-archive@lists.ietf.org; Fri, 24 Mar 2006 02:54:05 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMh7R-0002Ok-Le for ipfix-archive@lists.ietf.org; Fri, 24 Mar 2006 02:54:05 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMh1w-00040j-00 for ipfix-list@mil.doit.wisc.edu; Fri, 24 Mar 2006 01:48:20 -0600 Received: from beniaminus.red.cert.org ([192.88.209.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMh1v-00040e-00 for ipfix@net.doit.wisc.edu; Fri, 24 Mar 2006 01:48:19 -0600 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 k2O7mGMX012469 for ; Fri, 24 Mar 2006 02:48:17 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k2O7kjlO012418 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) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000005 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 24 02:56:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMh9S-0006tW-Dm for ipfix-archive@lists.ietf.org; Fri, 24 Mar 2006 02:56:06 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMh9R-0002Xv-61 for ipfix-archive@lists.ietf.org; Fri, 24 Mar 2006 02:56:06 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMh6W-0004O3-00 for ipfix-list@mil.doit.wisc.edu; Fri, 24 Mar 2006 01:53:04 -0600 Received: from franclinus.red.cert.org ([192.88.209.16]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMh6V-0004Ny-00 for ipfix@net.doit.wisc.edu; Fri, 24 Mar 2006 01:53:03 -0600 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.19) with ESMTP id k2O7qxv2020541 for ; Fri, 24 Mar 2006 02:53:01 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k2O7qc3K020516 for ; Fri, 24 Mar 2006 02:52:38 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k2O7qbH6020512; Fri, 24 Mar 2006 02:52:38 -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 k2O7qagH003189; Fri, 24 Mar 2006 02:52:36 -0500 In-Reply-To: <4423274B.3060201@cisco.com> References: <20060324080218.f09rbbgcuv34kwww@webmail.auckland.ac.nz> <20060324103700.ec8qt11imylcgwsg@webmail.auckland.ac.nz> <4423274B.3060201@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-2--476687937" Message-Id: <6264796C-2D54-4C92-886B-1F46D4B0E766@cert.org> Cc: Nevil Brownlee , ipfix@net.doit.wisc.edu Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: Oops: [ipfix] PROPOSED list of WG items Date: Fri, 24 Mar 2006 01:52:32 -0600 To: Benoit Claise X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000005 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2--476687937 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Benoit, On Mar 23, 2006, at 4:55 PM, Benoit Claise wrote: > I have some concerns about the biflow, which proposed several > solutions, without precisely telling which one to choose: > record adjacency -> the collector can assume the exporter will > always to do this. > reverse counters -> yet an extra dimension in the information model > multiple I.Es. -> potentially some ambiguities > Note that I don't have the perfect solution without IPFIX version > 2, as I explained on the list I believe the forthcoming -01 revision of this draft (which we are hoping to have out by 31 March; one week in advance of the proposed date of drafting the charter) will address these concerns. 1. Record Adjacency is meant _only_ as an example of why the current obvious approach is inadequate (efficiency, lack of explicit flow association). The language will be changed to clarify this point. 2. The multiple IE approach came up during review of -00; after further review it has been roundly rejected, and will not appear in the -01 revision. It was tempting to consider, but is too ambiguous to move forward with. 3. The reverse counter approach is the recommended one. The language will reflect this. We are discussing the assignment of a Private Enterprise Number with IANA for reverse-direction fields in order to mitigate the info model dimension explosion. This point (PEN vs. non- private IEs in the info model for reverse counters) will require some discussion on the list; if consensus can be reached by mid-June, we'll be prepared to bring a -02 draft with no major points of contention to Montreal. Regards, Brian --Apple-Mail-2--476687937 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) iD8DBQFEI6VE4/8LCZ4pwvYRAiSNAJ40q9urqlADfdSDyt6joM4tmfjXGgCaAjLv rpFa40IVFRjL/+sYx9H/Y54= =GKXI -----END PGP SIGNATURE----- --Apple-Mail-2--476687937-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 24 03:44:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMhuD-0004Hb-HZ for ipfix-archive@lists.ietf.org; Fri, 24 Mar 2006 03:44:25 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMhuC-00041u-AS for ipfix-archive@lists.ietf.org; Fri, 24 Mar 2006 03:44:25 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMhpp-0006er-00 for ipfix-list@mil.doit.wisc.edu; Fri, 24 Mar 2006 02:39:53 -0600 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMhpo-0006eg-00 for ipfix@net.doit.wisc.edu; Fri, 24 Mar 2006 02:39:52 -0600 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: [ipfix] 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> Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 --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-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 24 05:18:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMjNT-0007oQ-6E for ipfix-archive@lists.ietf.org; Fri, 24 Mar 2006 05:18:43 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMjNQ-0007sE-SY for ipfix-archive@lists.ietf.org; Fri, 24 Mar 2006 05:18:43 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMjHx-00038z-00 for ipfix-list@mil.doit.wisc.edu; Fri, 24 Mar 2006 04:13:01 -0600 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMjHv-00038o-00 for ipfix@net.doit.wisc.edu; Fri, 24 Mar 2006 04:13:00 -0600 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 75A2511C for ; Fri, 24 Mar 2006 11:12:58 +0100 (MET) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12892-02 for ; Fri, 24 Mar 2006 11:12:56 +0100 (NFT) Received: from [127.0.0.1] (c64.informatik.uni-tuebingen.de [134.2.168.129]) by mx5.informatik.uni-tuebingen.de (Postfix) with SMTP id 9E435115 for ; Fri, 24 Mar 2006 11:12:55 +0100 (MET) Message-ID: <4423C60B.10004@informatik.uni-tuebingen.de> Date: Fri, 24 Mar 2006 11:12:27 +0100 From: Gerhard Muenz User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Subject: Re: IPFIX MIB [Re: [ipfix] DRAFT IPFIX meeting minutes, 65th IETF, Dallas] References: <20060323164933.GA8437@doit.wisc.edu> <20060323165332.GA8850@doit.wisc.edu> <4422FE58.7090809@lawrence.edu> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de Content-Transfer-Encoding: quoted-printable Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Simon, All, Thanks for the interesting link. We are also using NetConf for configuring our IPFIX/PSAMP probes/concentrators. Interested readers can find information in the deliverables of the DIADEM Firewall Project: http://www.diadem-firewall.org/ http://www.diadem-firewall.org/documents/Diadem%20Firewall%20-%20D6%20-%2= 0Revised%20Interfaces%20Specification.pdf http://www.diadem-firewall.org/documents/Diadem%20Firewall%20-%20D9%20-%2= 0Initial%20Violation%20Detection%20Prototype.pdf Moremore, a poster on this subject will be presented at NOMS 2006. Regards, Gerhard Simon Leinen wrote: > Robert Lowe writes: >>> A number of participants showed support for an IPFIX MIB. >=20 >> For the purpose of exposing what part of IPFIX? Configuration >> items? >=20 > The focus is more on monitoring I think. Personally I use SNMP today > for monitoring the performance of my (Net)flow exporters and > collectors, using vendor-specific and home-grown MIBs, respectively. > Standard MIB modules for common functions of IPFIX devices would be > very useful. >=20 > About configuration, Benoit mentioned that he doesn't really believe > in the utility of SNMP "set"s for this, and I would agree. It might > be more useful to specify IPFIX device configuration schemata for > NETCONF, with the caveat that we don't (yet) have a standard data > modeling language for NETCONF. But that hasn't prevented people to > already work on such models even for IPFIX (well Netflow v9) > meter/exporters, e.g. http://www.liberouter.org/netflow/flowmon-rng.php --=20 Dipl.-Ing. Gerhard M=FCnz 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 -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 24 13:22:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMqvy-0006c6-U8 for ipfix-archive@lists.ietf.org; Fri, 24 Mar 2006 13:22:50 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMqvw-0004zN-Ih for ipfix-archive@lists.ietf.org; Fri, 24 Mar 2006 13:22:50 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMqs5-0003JO-00 for ipfix-list@mil.doit.wisc.edu; Fri, 24 Mar 2006 12:18:49 -0600 Received: from mailhub.lawrence.edu ([143.44.0.14] helo=lawrence.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMqs4-0003JJ-00 for ipfix@net.doit.wisc.edu; Fri, 24 Mar 2006 12:18:48 -0600 Received: from [143.44.160.16] (account lower [143.44.160.16] verified) by lawrence.edu (CommuniGate Pro SMTP 5.0.6) with ESMTPA id 15536382; Fri, 24 Mar 2006 12:18:44 -0600 Message-ID: <44243803.7020608@lawrence.edu> Date: Fri, 24 Mar 2006 12:18:43 -0600 From: Robert Lowe Organization: Lawrence University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Leinen CC: plonka@doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: IPFIX MIB [Re: [ipfix] DRAFT IPFIX meeting minutes, 65th IETF, Dallas] References: <20060323164933.GA8437@doit.wisc.edu> <20060323165332.GA8850@doit.wisc.edu> <4422FE58.7090809@lawrence.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Simon Leinen wrote: > Robert Lowe writes: > >>>A number of participants showed support for an IPFIX MIB. > > >>For the purpose of exposing what part of IPFIX? Configuration >>items? > > > The focus is more on monitoring I think. Personally I use SNMP today > for monitoring the performance of my (Net)flow exporters and > collectors, using vendor-specific and home-grown MIBs, respectively. > Standard MIB modules for common functions of IPFIX devices would be > very useful. Are there any performance issues to worry about, especially a conflict of interest between exporting/collecting data and recording performance metrics? It seems as though a MIB could be useful though. > About configuration, Benoit mentioned that he doesn't really believe > in the utility of SNMP "set"s for this, and I would agree. I would agree as well. And, IIRC, we went down that path a while ago, and I was hoping we weren't going to revisit it. -Robert > It might > be more useful to specify IPFIX device configuration schemata for > NETCONF, with the caveat that we don't (yet) have a standard data > modeling language for NETCONF. But that hasn't prevented people to > already work on such models even for IPFIX (well Netflow v9) > meter/exporters, e.g. http://www.liberouter.org/netflow/flowmon-rng.php -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 24 18:53:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMw6E-00048Q-Go for ipfix-archive@lists.ietf.org; Fri, 24 Mar 2006 18:53:46 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMw6D-00012L-1f for ipfix-archive@lists.ietf.org; Fri, 24 Mar 2006 18:53:46 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FMvvD-00047g-00 for ipfix-list@mil.doit.wisc.edu; Fri, 24 Mar 2006 17:42:23 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FMvvC-00047Z-00 for ipfix@net.doit.wisc.edu; Fri, 24 Mar 2006 17:42:22 -0600 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 25 Mar 2006 00:42:22 +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 k2ONgL36020422; Sat, 25 Mar 2006 00:42:21 +0100 (MET) Received: from [10.89.16.126] (rcdn-vpn-cluster-1-126.cisco.com [10.89.16.126]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA12610; Fri, 24 Mar 2006 23:42:19 GMT Message-ID: <442483DB.2040809@cisco.com> Date: Fri, 24 Mar 2006 23:42:19 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu CC: "emile.stephan" Subject: Re: [WARNING: VIRUS REMOVED] [ipfix] Fw: References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi all If this virus made it past your software filters and into your Inbox, and past your common sense filters and onto your Windows System, then here's more info: http://www.symantec.com/avcenter/venc/data/w32.blackmal.e@mm.html And here's the removal tool (This means you, Emile!): http://securityresponse.symantec.com/avcenter/venc/data/w32.blackmal@mm.removal.tool.html Andrew emile.stephan wrote: > > photo > photo2 photo3 > > > ------------------------------------------------------------------------ > > This attachment contained a virus and was stripped. > Filename: Video_part.mim > Content-Type: application/x-msdownload > Virus(es): W32/Nyxem-D -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From fayzhan@legadelcane.org Sat Mar 25 04:08:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN4ky-0002gs-0F for ipfix-archive@lists.ietf.org; Sat, 25 Mar 2006 04:08:24 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FN4kw-0005VO-Nf for ipfix-archive@lists.ietf.org; Sat, 25 Mar 2006 04:08:23 -0500 Received: from 19.red-83-43-150.dynamicip.rima-tde.net ([83.43.150.19] helo=legadelcane.org) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FN4Q0-0000wO-00 for ipfix-list@mil.doit.wisc.edu; Sat, 25 Mar 2006 02:46:45 -0600 Message-ID: <000001c64fe8$9f269270$fa67a8c0@qst67> Reply-To: "Fayza Hannum" From: "Fayza Hannum" To: ipfix-list@mil.doit.wisc.edu Subject: Re: 8i2i355 news Date: Sat, 25 Mar 2006 03:46:34 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C64FBE.B6508A70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?83.43.150.19 X-Spam-Score: 2.7 (++) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C64FBE.B6508A70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 Do you want to OVER P A Y for your MEDs ? =20 Nothing like you need it, S A V E yourself 50 % with http://www.ouseifan.com =20 C=20 \/=20 \/=20 l=20 A=20 I=20 A=20 L=20 A=20 L=20 l=20 G=20 I=20 U=20 R=20 S=20 M=20 A=20 =20 =20 =20 $=20 $=20 $=20 6=20 8=20 6=20 7=20 5=20 9=20 ,=20 ,=20 ,=20 5=20 4=20 9=20 0=20 5=20 5=20 ------=_NextPart_000_0001_01C64FBE.B6508A70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
Do you want to OVER P A Y for your MEDs ?
 
Nothing like you need it, S A V E=20 yourself 50 % with http://www.ouseifan.com
=
 
C
\/
\/
l
A
I =
A
L
A =
L
l
G =
I
U
R =
S
M
A
 
  =
 
$
$
$ =
6
8
6 =
7
5
9
,
,
, =
5
4
9 =
0
5
5 =
------=_NextPart_000_0001_01C64FBE.B6508A70-- From ronaldomoronta@dreefs.de Wed Mar 29 08:31:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOamC-0004Hg-OZ for ipfix-archive@lists.ietf.org; Wed, 29 Mar 2006 08:31:56 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOamC-0004ca-FZ for ipfix-archive@lists.ietf.org; Wed, 29 Mar 2006 08:31:56 -0500 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FOaOo-00061x-00 for ipfix-list@mil.doit.wisc.edu; Wed, 29 Mar 2006 07:07:46 -0600 Received: from dreefs.de ([85.139.113.104]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k2TD7iXJ028081 for ; Wed, 29 Mar 2006 07:07:45 -0600 Message-ID: <000001c65331$bc112160$a852a8c0@yfr81> Reply-To: "Ronaldo Moronta" From: "Ronaldo Moronta" To: ipfix-list@mil.doit.wisc.edu Subject: Re: news good Date: Wed, 29 Mar 2006 08:07:30 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C65307.D33B1960" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C65307.D33B1960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dea P r Home O b wner ,=20 =20 Your cr Z edit doesn't matter to us ! If you OW z N real e f st g at R e and want IMM h EDIAT A E c d ash to s f pend ANY way you like, or simply wish=20 to LO z WER your monthly p C ayments by a third or more, here are the deal S s=20 we have T t OD 9 AY :=20 =20 $4 D 88,000.00 at a 3.6 m 7% f t ixed-ra k te=20 $37 g 2,000.00 at a 3.9 M 0% varia a ble-ra X te=20 $49 0 2,000.00 at a 3.2 b 1% i Y nteres q t-only=20 $24 V 8,000.00 at a 3. P 36% fix w ed-ra y te=20 $1 Z 98,000.00 at a 3.5 U 5% variab s le-ra W te=20 =20 Hurr s y, when these deaI q s are gone, they are gone ! =20 Don't worry about app 7 roval, your c I redit will not disqu E alify you !=20 =20 Vis W it our s 3 ite =20 =20 Sincerely, Ronaldo Moronta =20 Ap Z proval Manager ------=_NextPart_000_0001_01C65307.D33B1960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dea P r Home O b wner ,
 
Your cr Z edit doesn't matter to us ! If you OW z N real e f st g at R e
and want IMM h EDIAT A E c d ash to s f pend ANY way you like, or simply wish
to LO z WER your monthly p C ayments by a third or more, here are the deal S s
we have T t OD 9 AY :
 
$4 D 88,000.00 at a 3.6 m 7% f t ixed-ra k te
$37 g 2,000.00 at a 3.9 M 0% varia a ble-ra X te
$49 0 2,000.00 at a 3.2 b 1% i Y nteres q t-only
$24 V 8,000.00 at a 3. P 36% fix w ed-ra y te
$1 Z 98,000.00 at a 3.5 U 5% variab s le-ra W te
 
Hurr s y, when these deaI q s are gone, they are gone !
 
Don't worry about app 7 roval, your c I redit will not disqu E alify you !
 
Vis W it our s 3 ite
 
Sincerely, Ronaldo Moronta
 
Ap Z proval Manager
------=_NextPart_000_0001_01C65307.D33B1960-- From yehielu@asianfn.com Wed Mar 29 12:18:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOeJo-00013c-8N for ipfix-archive@lists.ietf.org; Wed, 29 Mar 2006 12:18:52 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOeJl-00078W-Va for ipfix-archive@lists.ietf.org; Wed, 29 Mar 2006 12:18:52 -0500 Received: from [124.28.72.106] (helo=asianfn.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FOeEX-0002eI-00 for ipfix-list@mil.doit.wisc.edu; Wed, 29 Mar 2006 11:13:25 -0600 Message-ID: <000001c65354$0f4a6590$1407a8c0@ktj24> Reply-To: "Yehiel Tibbals" From: "Yehiel Tibbals" To: ipfix-list@mil.doit.wisc.edu Subject: Re: news ok Date: Wed, 29 Mar 2006 12:13:12 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6532A.26745D90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?124.28.72.106 X-Spam-Score: 4.0 (++++) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6532A.26745D90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, http://www.arrivuets.com =20 VzAqLclrUzMy a$k1e,n2h1g VdIpAfGlRlAa k$x3x,o7z5x ClIrAhLrIdSb y$c3j,y3j3l ------=_NextPart_000_0001_01C6532A.26745D90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
VzAqLclrUzMy a$k1e,n2h1g
VdIpAfGlRlAa k$x3x,o7z5x
ClIrAhLrIdSb y$c3j,y3j3l
------=_NextPart_000_0001_01C6532A.26745D90-- From bissepamelia@ian.com Wed Mar 29 13:18:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOfFx-0005Kd-0w for ipfix-archive@lists.ietf.org; Wed, 29 Mar 2006 13:18:57 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOfFv-0001v1-Ny for ipfix-archive@lists.ietf.org; Wed, 29 Mar 2006 13:18:57 -0500 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FOf7s-0007kl-00 for ipfix-list@mil.doit.wisc.edu; Wed, 29 Mar 2006 12:10:36 -0600 Received: from ian.com ([133.82.209.241]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k2TIAYXA003520 for ; Wed, 29 Mar 2006 12:10:35 -0600 Message-ID: <000001c6535c$0e6e63d0$d028a8c0@gyx38> Reply-To: "Pamelia Bissette" From: "Pamelia Bissette" To: ipfix-list@mil.doit.wisc.edu Subject: Re: news good Date: Wed, 29 Mar 2006 13:10:27 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C65332.259AA5C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.9 (++) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C65332.259AA5C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable De e ar Home Ow f ner ,=20 =20 Your credi F t doesn't matter to us ! If you O 0 WN real e V st V at o e and want IMMED m IA z TE ca q sh to spen J d ANY way you like, or simply wish=20 to L l OWER your monthly p q ayments by a third or more, here are the d 5 eals=20 we have T D OD S AY :=20 =20 $4 k 88,000.00 at a 3 P .67% fi u xed-rat t e=20 $37 t 2,000.00 at a 3 V .90% varia D ble-ra W te=20 $49 D 2,000.00 at a 3.2 f 1% int u ere o st-only=20 $24 v 8,000.00 at a 3 D .36% f m ixed-rat a e=20 $1 C 98,000.00 at a 3 V .55% variabl b e-ra 3 te=20 =20 H v urry, when these dea V Is are gone, they are gone ! =20 Don't worry about appro n val, your cr U edit will not dis C qualify you !=20 =20 Vis X it our si Q te =20 =20 Sincerely, Pamelia Bissette =20 App 3 roval Manager ------=_NextPart_000_0001_01C65332.259AA5C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
De e ar Home Ow f ner ,
 
Your credi F t doesn't matter to us ! If you O 0 WN real e V st V at o e
and want IMMED m IA z TE ca q sh to spen J d ANY way you like, or simply wish
to L l OWER your monthly p q ayments by a third or more, here are the d 5 eals
we have T D OD S AY :
 
$4 k 88,000.00 at a 3 P .67% fi u xed-rat t e
$37 t 2,000.00 at a 3 V .90% varia D ble-ra W te
$49 D 2,000.00 at a 3.2 f 1% int u ere o st-only
$24 v 8,000.00 at a 3 D .36% f m ixed-rat a e
$1 C 98,000.00 at a 3 V .55% variabl b e-ra 3 te
 
H v urry, when these dea V Is are gone, they are gone !
 
Don't worry about appro n val, your cr U edit will not dis C qualify you !
 
Vis X it our si Q te
 
Sincerely, Pamelia Bissette
 
App 3 roval Manager
------=_NextPart_000_0001_01C65332.259AA5C0-- From esk@lopezclub.com Wed Mar 29 23:46:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOp37-000762-7y for ipfix-archive@lists.ietf.org; Wed, 29 Mar 2006 23:46:21 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOp35-00059p-06 for ipfix-archive@lists.ietf.org; Wed, 29 Mar 2006 23:46:21 -0500 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FOojA-0004UW-00 for ipfix-list@mil.doit.wisc.edu; Wed, 29 Mar 2006 22:25:44 -0600 Received: from -1209022912 ([221.217.82.175]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k2U4PCP3002678 for ; Wed, 29 Mar 2006 22:25:37 -0600 Received: from lopezclub.com (-1208591808 [-1208589040]) by mexxxico.com (Qmailv1) with ESMTP id 4D2A6FDCF2 for ; Thu, 30 Mar 2006 12:23:26 -0500 Date: Thu, 30 Mar 2006 12:23:26 -0500 From: majorincome X-Mailer: The Bat! (v2.00.8) Personal X-Priority: 3 Message-ID: <2146402216.20060330122326@lopezclub.com> To: Ipfix Subject: High Income JOB $2000 per week! Now! MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 3.0 (+++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 you can now make extra money working part time $2000 a week please visit http://www.majorincome.net for more details From majordomo@mil.doit.wisc.edu Thu Mar 30 10:22:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOyyN-0005Lo-MM for ipfix-archive@lists.ietf.org; Thu, 30 Mar 2006 10:22:07 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOyyN-0001EJ-7E for ipfix-archive@lists.ietf.org; Thu, 30 Mar 2006 10:22:07 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FOya2-0003j1-00 for ipfix-list@mil.doit.wisc.edu; Thu, 30 Mar 2006 08:56:58 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FOya1-0003hx-00 for ipfix@net.doit.wisc.edu; Thu, 30 Mar 2006 08:56:57 -0600 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 k2UEutf05221; Thu, 30 Mar 2006 16:56:55 +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 k2UEurC26654; Thu, 30 Mar 2006 16:56:53 +0200 (CEST) Message-ID: <442BF1B5.3020507@cisco.com> Date: Thu, 30 Mar 2006 16:56:53 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Thomas Dietz CC: ipfix , psamp Subject: [ipfix] Re: Source ID -> Observation Domain Id? -> New Definition proposals References: <44233D08.5080108@cisco.com> <200603240939.16597.Thomas.Dietz@netlab.nec.de> In-Reply-To: <200603240939.16597.Thomas.Dietz@netlab.nec.de> Content-Type: multipart/alternative; boundary="------------030102060004040405010606" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.5 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 This is a multi-part message in MIME format. --------------030102060004040405010606 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 k2UEutf05221 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=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 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=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 Observatio= n Domain ID field to separate different export streams originati= ng=20 from the same Exporting Process. The Observation Domain ID SH= OULD be 0=20 when no specific Observation Domain ID is relevant for the ent= ire 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, 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 se= ntence was not too clear, as the readers don't know the notion of scope a= t 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, 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: > =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 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. >> =20 --------------030102060004040405010606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
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.

--------------030102060004040405010606-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 30 15:55:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4BE-0007nJ-Nc for ipfix-archive@lists.ietf.org; Thu, 30 Mar 2006 15:55:44 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP4BE-0007b1-7t for ipfix-archive@lists.ietf.org; Thu, 30 Mar 2006 15:55:44 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FP46I-0003gH-00 for ipfix-list@mil.doit.wisc.edu; Thu, 30 Mar 2006 14:50:38 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FP46H-0003gA-00 for ipfix@net.doit.wisc.edu; Thu, 30 Mar 2006 14:50:37 -0600 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 CC: Thomas Dietz , ipfix , psamp@ietf.org Subject: Re: [ipfix] Re: Source ID -> Observation Domain Id? -> New Definition proposals References: <44233D08.5080108@cisco.com> <200603240939.16597.Thomas.Dietz@netlab.nec.de> <442BF1B5.3020507@cisco.com> In-Reply-To: <442BF1B5.3020507@cisco.com> Content-Type: multipart/alternative; boundary="------------010900090802060008010502" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.5 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 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-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 30 17:35:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5js-0007Pe-G3 for ipfix-archive@lists.ietf.org; Thu, 30 Mar 2006 17:35:36 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP5jq-0003sD-H3 for ipfix-archive@lists.ietf.org; Thu, 30 Mar 2006 17:35:36 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FP5em-00053U-00 for ipfix-list@mil.doit.wisc.edu; Thu, 30 Mar 2006 16:30:20 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FP5ek-00053J-00 for ipfix@net.doit.wisc.edu; Thu, 30 Mar 2006 16:30:19 -0600 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 k2UMUEN02848; Fri, 31 Mar 2006 00:30:15 +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 k2UMUAC14196; Fri, 31 Mar 2006 00:30:11 +0200 (CEST) Message-ID: <442C5BF2.1050908@cisco.com> Date: Fri, 31 Mar 2006 00:30:10 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: "'Ipfix Wg' (E-mail) (E-mail)" , "David Kessens (E-mail)" , "Dan Romascanu (E-mail)" Subject: Re: [ipfix] AD review for: draft-ietf-ipfix-protocol-19.txt References: <7D5D48D2CAA3D84C813F5B154F43B155098E14A6@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155098E14A6@nl0006exch001u.nl.lucent.com> Content-Type: multipart/alternative; boundary="------------060909090108090300030602" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.1 (/) X-Scan-Signature: afbb91703506ab43c817903f0dd6f23d This is a multi-part message in MIME format. --------------060909090108090300030602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bert, all, Thanks for your comments. See inline. For clarity purposes, I removed the obvious editorial improvements, which have been inserted already. Note that I made the following changes: - I modified all occurrences of Source ID to Observation Domain ID. - As proposed by Brian Trammell, I clarified: Add to the end of 10.2.4.1 Association Establishment: "Each SCTP stream over which TLS [TLS] will be used MUST be established as a fully reliable bidirectional stream as required by RFC 3436." Insert a new third paragraph to 10.2.4.2 Association Teardown: "If TLS [TLS] is used, the Process initiating association teardown SHOULD send a close_notify alert over each TLS stream before closing the SCTP association." Append to the second paragraph to 10.2.4.3 Stream: "Only fully reliable bidirectional streams are available if TLS [TLS] as used, as required by RFC 3436." [RFC3436] added as a normative reference > - Sect 3. > States that Template Sets MUST be sent periodically when UDP is used. > What if TCP or or SCTP are used? Might want to state what expected > behaviour is in those cases as well. > I agree this is confusing, as we don't know yet at this stage that UDP is a MAY. Since these are examples, since the first two examples don't discuss any transport protocol issues and since the transport protocol is explained at length in the section 10, I have removed the sentences. > - sect 3.1 under SOurce ID > I do not understand the last sentence. WHat does it mean? > pls clarify in text. > As proposed in http://ipfix.doit.wisc.edu/archive/3145.html, I moved it into the section "3.4.2.1 Scope... where it naturally belongs > - Page 16 under padding > s/zero (0) octets/zero (0) valued octets/ > or "octets with a value of zero (o)" ?? > Done. "the padding octet(s) MUST be composed of zero (0) valued octets. " > Last sentence under "padding" may need a period or semicolon in > the middle of the sentence? > Done. > - Sect 5/6 speak about ...DeltaUSeconds, but I cannot find that term in > INFO spec. It talks about ...DeltaMicroSeconds. Is that what you mean? > Corrected already. Someone mentioned it on the mailing > - sect 6.1.3 > I'd like to see a reference to the IEEE spec for floats. > Corrected already. This was discussed on the mailing list. 6.1.3 float32 The float32 data type is encoded as an IEEE single-precision 32-bit floating point-type, as specified in [IEEE.754.1985]. 6.1.4 float64 The float64 data type is encoded as an IEEE double-precision 64-bit floating point-type, as specified in [IEEE.754.1985]. > - sect 6.1.5 > I am not sure that by saying "it is expected that strings will be coded > in UTF-8 format" will guanrantee interoiperability? > Maybe better use MUST (RFC2119) language. I have right now: The data type string represents a finite length string of valid characters of the Unicode character encoding set. The string data type MUST be encoded in UTF-8 format. The string is sent as an array of octets using an information element of fixed or variable length. The length of the information element specifies the length of the octetarray. Since this is required for interoperability, I think the "MUST" is more appropriate. So I changed all definitions in 6.1.X: from "is encoded" to "MUST be encoded" Note: we have the same sentence in [IPFIX-INFO]: It is expected that strings will be encoded in UTF-8 format, which is identical in encoding for ASCII characters, but also accommodates other Unicode multi-byte characters. I think this should be removed, as the information model should not tell how to encode the data. > Last sentence of 6.1.5 talks about "NUL" characters. That again seems > to be ASCII language. Maybe better state "zero valued octets" . > Following some discussions, the sentence "In case of fixed length Information Element, if padding is required, padding MUST be composed of NUL character(s)." has been removed. All padding related info is now in the padding section. > - sect 6.1.6 > YOu might want to add a sentence how long this can serve us. > I believ it is something like 146 years, > 136 years. Added. The data type dateTimeSeconds represents a time value in units of seconds normalised to the GMT timezone. It MUST be encoded in a 32-bit integer containing the number of seconds since 0000 UTC Jan 1st 1970. The 32-bit integer allows the time encoding up to 136 years. > - sect 6.2 speaks about signed64/unsigned64 and also for 32 and 16. > Where are those types defined?? > Previous text: 6.1.1 Integral Data Types Integral data types - octet, unsigned16, unsigned32 and unsigned64 - are encoded using the default canonical format in network byte order. New text: 6.1.1 Integral Data Types Integral data types - octet, signed octet, unsigned16, signed16, unsigned32 signed32, signed64 and unsigned64 - are encoded using the default canonical format in network byte order. Signed Integral data types are represented in two's complement notation. > - one but last para on page 33 > "sufficient time" should be defined/explained somewhat don't > you think so? > I added the last sentence. "The Template Withdraw Message MUST not be sent until sufficient time has elapsed to allow the Collecting Process to receive and process the last Data Record using this Template information. This time MUST be configurable. A suitable default value is 5 seconds after the last Data Record has been sent. > - I wonder if the one but last para of section 9 is a nice opening > for DoS attacks? > The sentence is: "If the Collecting Process receives a Template Withdraw message for a Template Record it has not received before, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error as it does for malformed IPFIX Messages." The point is that we need that statement because it means that the collector is confused about its own status. And the only solution is to shutdown the SCTP association, so that the exporter will resend all the templates with a new SCTP association. > - sect 10.2.6 > Where/how is the treshold specified? > Same for sect 10.4.1.1 > I'm not sure how to answer the questions: Where? on the exporter How? based on the user appreciation. This is exactly why we have a MAY statement. We could say "exceeds a locally configured threshold. By default this time is foo secs." However, I have no clue what the value of foo should be. If the statements are too vague without the default value, I simply propose to remove them. > - sect 10.3.7 > It is unclear to me how/where the template lifetimes are specified, > defined or configured. > We wrote the following sentence: The Template lifetime at the Collecting Process MUST be at least 3 times higher that the Template refresh timeout configured on the Exporting Process. Isn't it enough? > - sect 11.4 last para > I guess that just depends of who/where the attacker is, no? > WHat if it is an internal ISP employee? > Old text: The use of a dedicated network prevents IPFIX Messages from being inspected by an attacker. New text: The use of a dedicated network prevents IPFIX Messages from being inspected by an external attacker. > - sect 12.1 > I do not think the IPfix version number is an IANA controlled thing. > I also think you want that to be changebale only by an IETF standards > action (as opposed to just IETF consensus). Afetr all you want this > protocol to be stds track. > It was actually the intend behind the sentence: "Changes in either IPFIX Version Number or IPFIX Set ID assignments require an IETF Consensus, i.e. they are to be made via RFCs approved by the IESG." Should we simply erase the section 12.1? Or make clearer? "Changes in either IPFIX Version Number or IPFIX Set ID assignments are not controlled by IANA, but by an RFC approved by the IESG." > - sect 12.2 seems to be IPFIX-INFO material and not protocol material?? > Section 12.2 erased. > - Sect 12.1 > The "IPFIX Set ID" starts (I think) a new registry. So you MUST > describe under IANA considerations how to set it up and what the > rules are for new assignements. You have that text (more or less) in > sect 3.3.2, but you must spell it out here for IANA as well. > New section "12.x Set ID" Set ID value identifies the IPFIX Set. Set ID values of 0 and 1 are not used for historical reasons [RFC3954]. A value of 2 is reserved for the Template Set. A value of 3 is reserved for the Option Template Set. All other values from 4 to 255 are reserved for future use. Values above 255 are used for Data Sets. The new Set ID values are defined as "Specification Required" [RFC 2434] prior to the assignment by IANA. > Then you have a set of Set IDs that get assigned by this document > and you should list them clearly for IANA so they can do the initial > population of the registry. > > - It seems to me that sect 13 is more an APPENDIX and so non-normative? > Might be good to then list it as appendix and state that it is > non-normative. > I moved the appendix just before the reference section. ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt doesn't mention that we should mention something about non-normative ... unless I missed something? > - Refrences. > - is 1889 really normative? > Moved to informative > !! Missing citation for Informative reference: > P060 L046: [RFC3955] Leinen, S., "Evaluation of Candidate Protocols for IP Flow > Removed this reference. > - sect 3.1 remove one of the two words "format" > > You migth also want to add a sentence to explain why the version > field is 0x000a for this version. > I inserted this proposal Version Version of Flow Record format exported in this message. The value of this field is 0x000a for the current version, incrementing by one the version used in the NetFlow services export version 9 [RFC3954]. > - page 33 > s/Disused/Unused/ ?? Let me copy the entire paragraph: Disused Templates SHOULD be deleted. Before reusing a Template ID the disused Template MUST be deleted. In order to delete an allocated Template, the Template is withdrawn through the use of a Template Withdraw Message. The term "unused" is already applied in this section with a different meaning. For example "an unused Template ID MUST be used". This means: allocate a new Template ID. However, in the sentence you pointed out: we want to say: the templates that are not used anymore. I propose: "The Templates that are not used anymore SHOULD be deleted. Before reusing a Template ID, the Template MUST be deleted" Thanks again for your comments. Regards, Benoit. --------------060909090108090300030602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bert, all,

Thanks for your comments. See inline.
For clarity purposes, I removed the obvious editorial improvements, which have been inserted already.

Note that I made the following changes:
- I modified all occurrences of Source ID to Observation Domain ID.
- As proposed by Brian Trammell, I clarified:
Add to the end of 10.2.4.1 Association Establishment:
"Each SCTP stream over which TLS [TLS] will be used MUST be established as a fully reliable bidirectional stream as required by RFC 3436."

Insert a new third paragraph to 10.2.4.2 Association Teardown:
"If TLS [TLS] is used, the Process initiating association teardown SHOULD send a close_notify alert over each TLS stream before closing the SCTP association."

Append to the second paragraph to 10.2.4.3 Stream:
"Only fully reliable bidirectional streams are available if TLS [TLS] as used, as required by RFC 3436."
          [RFC3436] added as a normative reference
- Sect 3.
  States that Template Sets MUST be sent periodically when UDP is used.
  What if TCP or or SCTP are used? Might want to state what expected
  behaviour is in those cases as well.
I agree this is confusing, as we don't know yet at this stage that UDP is a MAY.
Since these are examples, since the first two examples don't discuss any transport protocol issues and since the transport protocol is explained at length in the section 10, I have removed the sentences. 

- sect 3.1 under SOurce ID
  I do not understand the last sentence. WHat does it mean?
  pls clarify in text.
As proposed in http://ipfix.doit.wisc.edu/archive/3145.html, I moved it into the section "3.4.2.1 Scope... where it naturally belongs 


- Page 16 under padding
  s/zero (0) octets/zero (0) valued octets/
  or "octets with a value of zero (o)" ??
Done. "the padding octet(s) MUST be composed of zero (0) valued octets. " 
  Last sentence under "padding" may need a period or semicolon in
  the middle of the sentence?
Done.
 
- Sect 5/6 speak about ...DeltaUSeconds, but I cannot find that term in
  INFO spec. It talks about ...DeltaMicroSeconds. Is that what you mean?
Corrected already. Someone mentioned it on the mailing
- sect 6.1.3
  I'd like to see a reference to the IEEE spec for floats.
Corrected already. This was discussed on the mailing list.

 6.1.3   float32
   
   The float32 data type is encoded as an IEEE single-precision 32-bit
   floating point-type, as specified in [IEEE.754.1985].  

 6.1.4   float64
   
   The float64 data type is encoded as an IEEE double-precision 64-bit
   floating point-type, as specified in [IEEE.754.1985]. 
- sect 6.1.5 
  I am not sure that by saying "it is expected that strings will be coded
  in UTF-8 format" will guanrantee interoiperability?
  Maybe better use MUST (RFC2119) language.
I have right now:
The data type string represents a finite length string of valid characters of the Unicode character encoding set.  The string data type MUST be encoded in UTF-8 format.  The string is sent as an array of octets using an information element of fixed or variable length. The length of the information element specifies the length of the octetarray.
Since this is required for interoperability, I think the "MUST" is more appropriate. So I changed all definitions in 6.1.X: from "is encoded" to "MUST be encoded"


Note: we have the same sentence in [IPFIX-INFO]:
 
   It is expected that strings
   will be encoded in UTF-8 format, which is identical in encoding for
   ASCII characters, but also accommodates other Unicode multi-byte
   characters.

I think this should be removed, as the information model should not tell how to encode the data.




  Last sentence of 6.1.5 talks about "NUL" characters. That again seems
  to be ASCII language. Maybe better state "zero valued octets" .
Following some discussions, the sentence "In case of fixed length Information Element, if padding is required, padding MUST be composed of NUL character(s)." has been removed. All padding related info is now in the padding section.
- sect 6.1.6
  YOu might want to add a sentence how long this can serve us.
  I believ it is something like 146 years,
136 years. Added.

The data type dateTimeSeconds represents a time value in units of seconds normalised to the GMT timezone.  It MUST be encoded in a 32-bit integer containing the number of seconds since 0000 UTC Jan 1st 1970. The 32-bit integer allows the time encoding up to 136 years. 


- sect 6.2 speaks about signed64/unsigned64 and also for 32 and 16.
  Where are those types defined??
Previous text:
 6.1.1   Integral Data Types 
    
   Integral data types - octet, unsigned16, unsigned32 and unsigned64 - 
   are encoded using the default canonical format in network byte 
   order. 

New text:

 6.1.1   Integral Data Types 
    
   Integral data types - octet, signed octet, unsigned16, signed16, unsigned32
   signed32, signed64 and unsigned64 - are encoded using the default canonical 
   format in network byte order.  Signed Integral data types are represented in
   two's complement notation.


- one but last para on page 33
  "sufficient time" should be defined/explained somewhat don't
  you think so?
I added the last sentence.
"The Template Withdraw Message MUST not be sent until sufficient time has elapsed to allow the Collecting Process to receive and process the last Data Record using this Template information. This time MUST be configurable.  A suitable default value is 5 seconds after the last Data Record has been sent.


 
- I wonder if the one but last para of section 9 is a nice opening
  for DoS attacks?
The sentence is: "If the Collecting Process receives a Template Withdraw message for a Template Record it has not received before, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error as it does for malformed IPFIX Messages."

The point is that we need that statement because it means that the collector is confused about its own status. And the only solution is to shutdown the SCTP association, so that the exporter will resend all the templates with a new SCTP association.
- sect 10.2.6
  Where/how is the treshold specified?
  Same for sect 10.4.1.1
I'm not sure how to answer the questions:
    Where? on the exporter
    How? based on the user appreciation. This is exactly why we have a MAY statement.
We could say "exceeds a locally configured threshold. By default this time is foo secs." However, I have no clue what the value of foo should be.
If the statements are too vague without the default value, I simply propose to remove them.
 
- sect 10.3.7
  It is unclear to me how/where the template lifetimes are specified,
  defined or configured.
  
We wrote the following sentence:
   The Template lifetime at 
   the Collecting Process MUST be at least 3 times higher that the 
   Template refresh timeout configured on the Exporting Process.  
Isn't it enough?


- sect 11.4 last para
  I guess that just depends of who/where the attacker is, no?
  WHat if it is an internal ISP employee?
Old text:
   The use of a dedicated network prevents IPFIX Messages from being 
   inspected by an attacker. 

New text:
   The use of a dedicated network prevents IPFIX Messages from being 
   inspected by an external attacker. 

- sect 12.1
  I do not think the IPfix version number is an IANA controlled thing.
  I also think you want that to be changebale only by an IETF standards
  action (as opposed to just IETF consensus). Afetr all you want this
  protocol to be stds track.
It was actually the intend behind the sentence:
   "Changes in either IPFIX Version Number or IPFIX Set ID assignments 
   require an IETF Consensus, i.e. they are to be made via RFCs 
   approved by the IESG."

Should we simply erase the section 12.1?
Or make clearer?
   "Changes in either IPFIX Version Number or IPFIX Set ID assignments 
   are not controlled by IANA, but by an RFC approved by the IESG." 

- sect 12.2 seems to be IPFIX-INFO material and not protocol material??
Section 12.2 erased.

- Sect 12.1
  The "IPFIX Set ID" starts (I think) a new registry. So you MUST
  describe under IANA considerations how to set it up and what the
  rules are for new assignements. You have that text (more or less) in
  sect 3.3.2, but you must spell it out here for IANA as well.
New section "12.x Set ID"

Set ID value identifies the IPFIX Set. Set ID values of 0 and 1 are not used for historical reasons [RFC3954]. A value of 2 is reserved for the Template Set. A value of 3 is reserved for the Option Template Set. All other values from 4 to 255 are reserved for future use. Values above 255 are used for Data Sets.
The new Set ID values are defined as "Specification Required" [RFC 2434] prior to the assignment by IANA.

  Then you have a set of Set IDs that get assigned by this document
  and you should list them clearly for IANA so they can do the initial
  population of the registry.

- It seems to me that sect 13 is more an APPENDIX and so non-normative?
  Might be good to then list it as appendix and state that it is 
  non-normative.
I moved the appendix just before the reference section.
ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt doesn't mention that we should mention something about non-normative ... unless I missed something?

- Refrences.
  - is 1889 really normative?
Moved to informative
  !! Missing citation for Informative reference:
  P060 L046:    [RFC3955] Leinen, S., "Evaluation of Candidate Protocols for IP Flow
Removed this reference.
- sect 3.1 remove one of the two words "format" 
  
  You migth also want to add a sentence to explain why the version
  field is 0x000a for this version.
I inserted this proposal

Version

Version of Flow Record format exported in this message.  The value of this field is 0x000a for the current version, incrementing by one the version used in the NetFlow services export version 9 [RFC3954].


- page 33
  s/Disused/Unused/ ??

Let me copy the entire paragraph:
   Disused Templates SHOULD be deleted. Before reusing a Template ID 
   the disused Template MUST be deleted.  In order to delete an 
   allocated Template, the Template is withdrawn through the use of a 
   Template Withdraw Message.  

The term "unused" is already applied in this section with a different meaning.
For example "an unused Template ID MUST be used". This means: allocate a new Template ID.
However, in the sentence you pointed out: we want to say: the templates that are not used anymore.
I propose:
	"The Templates that are not used anymore SHOULD be deleted. Before reusing a Template ID, the Template MUST be deleted"

Thanks again for your comments. 

Regards, Benoit.


--------------060909090108090300030602-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From phili@norweb.net Thu Mar 30 22:17:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPA8C-0002hH-IH for ipfix-archive@lists.ietf.org; Thu, 30 Mar 2006 22:17:00 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPA8C-0008OT-8I for ipfix-archive@lists.ietf.org; Thu, 30 Mar 2006 22:17:00 -0500 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FP9lM-00065z-00 for ipfix-list@mil.doit.wisc.edu; Thu, 30 Mar 2006 20:53:24 -0600 Received: from norweb.net (lns-bzn-50f-81-56-194-198.adsl.proxad.net [81.56.194.198]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k2V2rMfT007018 for ; Thu, 30 Mar 2006 20:53:23 -0600 Message-ID: <000001c65417$ec8fdcf0$86b1a8c0@czu66> Reply-To: "Philadelphia Oakes" From: "Philadelphia Oakes" To: ipfix-list@mil.doit.wisc.edu Subject: news day Date: Thu, 30 Mar 2006 11:35:15 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C653EE.03B9D4F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.1 (++) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C653EE.03B9D4F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D 6 ear Home O 1 wner ,=20 =20 Your cr 3 edi E t doesn't matter to us !=20 =20 Your c D redi Z t doesn't matter to us ! If you OW y N real e U st D at 2 e=20 and want IMMED O IAT 1 E ca N sh to s L pend ANY way you like, or simply wish=20 to L 8 OWER your monthly p 8 aym g ents by a third or more, here are the d h eaI B s=20 we have T G ODA k Y :=20 =20 $ 4 b 88,000 at a 3,6 z 7% fi 6 xed - rat u e=20 $ 37 H 2,000 at a 3, g 90% v 6 ariable - ra i te=20 $ 4 Y 92,000 at a 3, v 21% int 0 ere R st - onl E y=20 $ 24 B 8,000 at a 3, Z 36% f L ixed - rat D e=20 $ 19 Q 8,000 at a 3,5 M 5% var s iable - rat L e=20 =20 H 1 urry, when these d N eaI Q s are gone, they are gone ! =20 Don't worry about a d pproval, your cred q it will not di p squ 0 alify you !=20 =20 V 7 is T it our s F ite =20 =20 Sincerely, Philadelphia Oakes =20 Ap 9 prova A l Manager ------=_NextPart_000_0001_01C653EE.03B9D4F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D 6 ear Home O 1 wner ,
 
Your cr 3 edi E t doesn't matter to us !
 
Your c D redi Z t doesn't matter to us ! If you OW y N real e U st D at 2 e
and want IMMED O IAT 1 E ca N sh to s L pend ANY way you like, or simply wish
to L 8 OWER your monthly p 8 aym g ents by a third or more, here are the d h eaI B s
we have T G ODA k Y :
 
$ 4 b 88,000 at a 3,6 z 7% fi 6 xed - rat u e
$ 37 H 2,000 at a 3, g 90% v 6 ariable - ra i te
$ 4 Y 92,000 at a 3, v 21% int 0 ere R st - onl E y
$ 24 B 8,000 at a 3, Z 36% f L ixed - rat D e
$ 19 Q 8,000 at a 3,5 M 5% var s iable - rat L e
 
H 1 urry, when these d N eaI Q s are gone, they are gone !
 
Don't worry about a d pproval, your cred q it will not di p squ 0 alify you !
 
V 7 is T it our s F ite
 
Sincerely, Philadelphia Oakes
 
Ap 9 prova A l Manager
------=_NextPart_000_0001_01C653EE.03B9D4F0-- From majordomo@mil.doit.wisc.edu Fri Mar 31 02:48:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPEMz-0006s8-0d for ipfix-archive@lists.ietf.org; Fri, 31 Mar 2006 02:48:33 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPEMx-0002fc-Ka for ipfix-archive@lists.ietf.org; Fri, 31 Mar 2006 02:48:32 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FPEIN-0001Ex-00 for ipfix-list@mil.doit.wisc.edu; Fri, 31 Mar 2006 01:43:47 -0600 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FPEIL-0001Ep-00 for ipfix@net.doit.wisc.edu; Fri, 31 Mar 2006 01:43:45 -0600 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 Subject: [ipfix] Re: Source ID -> Observation Domain Id? -> New Definition proposals Date: Fri, 31 Mar 2006 09:43:36 +0200 User-Agent: KMail/1.9.1 Cc: ipfix , psamp 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> Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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 -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 31 03:06:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPEc5-0004je-AJ for ipfix-archive@lists.ietf.org; Fri, 31 Mar 2006 03:04:09 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPEQN-0002lk-1L for ipfix-archive@lists.ietf.org; Fri, 31 Mar 2006 02:52:04 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FPENB-0001sx-00 for ipfix-list@mil.doit.wisc.edu; Fri, 31 Mar 2006 01:48:45 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FPENA-0001s0-00 for ipfix@net.doit.wisc.edu; Fri, 31 Mar 2006 01:48:44 -0600 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 CC: ipfix , psamp Subject: [ipfix] Re: Source ID -> Observation Domain Id? -> New Definition proposals 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> Content-Type: multipart/alternative; boundary="------------020308020205050106000803" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.5 (/) X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119 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-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 31 03:31:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPF2k-0007Cy-Hc for ipfix-archive@lists.ietf.org; Fri, 31 Mar 2006 03:31:42 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPF2j-0004pk-9j for ipfix-archive@lists.ietf.org; Fri, 31 Mar 2006 03:31:42 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FPEzI-0005Zg-00 for ipfix-list@mil.doit.wisc.edu; Fri, 31 Mar 2006 02:28:08 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FPEzG-0005ZZ-00 for ipfix@net.doit.wisc.edu; Fri, 31 Mar 2006 02:28:06 -0600 Received: from [10.147.65.153] (luz@kaitos [10.147.65.153]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id k2V8S2n05645; Fri, 31 Mar 2006 10:28:02 +0200 (MEST) Message-ID: <442CE812.6020905@fokus.fraunhofer.de> Date: Fri, 31 Mar 2006 10:28:02 +0200 From: Lutz Mark User-Agent: Mail/News 1.5 (X11/20060130) MIME-Version: 1.0 To: Thomas Dietz , Benoit Claise CC: ipfix Subject: Re: [ipfix] Re: Source ID -> Observation Domain Id? -> New Definition proposals 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> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 >> 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 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. ok for me. This implies that you need one exporter per observation domain. >> 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 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. If there are multiple exporters on a node (using the same ip address), then the collector cannot get out which exporter is the source of the message. Is there a motivation to recommend the use of sourceid 0? If not, I suggest to remove the last two sentences. Best regards, Lutz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 31 04:17:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPFkr-0000JK-6o for ipfix-archive@lists.ietf.org; Fri, 31 Mar 2006 04:17:17 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPFkp-0006of-Vq for ipfix-archive@lists.ietf.org; Fri, 31 Mar 2006 04:17:17 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FPFhO-00014C-00 for ipfix-list@mil.doit.wisc.edu; Fri, 31 Mar 2006 03:13:42 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FPFhN-000143-00 for ipfix@net.doit.wisc.edu; Fri, 31 Mar 2006 03:13:41 -0600 Received: from [10.147.65.153] (luz@kaitos [10.147.65.153]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id k2V9Ddn12957 for ; Fri, 31 Mar 2006 11:13:39 +0200 (MEST) Message-ID: <442CF2C3.4000504@fokus.fraunhofer.de> Date: Fri, 31 Mar 2006 11:13:39 +0200 From: Lutz Mark User-Agent: Mail/News 1.5 (X11/20060130) MIME-Version: 1.0 To: ipfix Subject: Re: [ipfix] Re: Source ID -> Observation Domain Id? -> New Definition proposals References: <44233D08.5080108@cisco.com> <200603240939.16597.Thomas.Dietz@netlab.nec.de> <442BF1B5.3020507@cisco.com> <200603310943.37129.Thomas.Dietz@netlab.nec.de> <442CE812.6020905@fokus.fraunhofer.de> In-Reply-To: <442CE812.6020905@fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 >>> 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 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. > > ok for me. This implies that you need > one exporter per observation domain. sorry, it does not. Lutz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 31 07:31:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPImj-00027m-VW for ipfix-archive@lists.ietf.org; Fri, 31 Mar 2006 07:31:25 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPImi-0007dA-NY for ipfix-archive@lists.ietf.org; Fri, 31 Mar 2006 07:31:25 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FPIPR-0001SP-00 for ipfix-list@mil.doit.wisc.edu; Fri, 31 Mar 2006 06:07:21 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FPIPQ-0001SK-00 for ipfix@net.doit.wisc.edu; Fri, 31 Mar 2006 06:07:20 -0600 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 31 Mar 2006 14:07:20 +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 k2VC7I36010342; Fri, 31 Mar 2006 14:07:19 +0200 (MEST) Received: from [10.61.81.40] (ams-clip-vpn-dhcp4393.cisco.com [10.61.81.40]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA10372; Fri, 31 Mar 2006 13:07:17 +0100 (BST) Message-ID: <442D1B74.9090809@cisco.com> Date: Fri, 31 Mar 2006 13:07:16 +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: Lutz Mark CC: Thomas Dietz , Benoit Claise , ipfix Subject: Re: [ipfix] Re: Source ID -> Observation Domain Id? -> New Definition proposals References: <44233D08.5080108@cisco.com> <200603240939.16597.Thomas.Dietz@netlab.nec.de> <442BF1B5.3020507@cisco.com> <200603310943.37129.Thomas.Dietz@netlab.nec.de> <442CE812.6020905@fokus.fraunhofer.de> In-Reply-To: <442CE812.6020905@fokus.fraunhofer.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Lutz, > If there are multiple exporters on a node (using the same > ip address), then the collector cannot get out which exporter > is the source of the message. They can use different exportingProcessId values. However, having multiple exporters appear the same might be an advantage, eg for redundancy or load balancing. > Is there a motivation to recommend the use of sourceid 0? > If not, I suggest to remove the last two sentences. If an exporter is reporting some non Observation Domain specific information, what value should it use? -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 31 07:44:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPIze-0007OH-S4 for ipfix-archive@lists.ietf.org; Fri, 31 Mar 2006 07:44:46 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPIze-0008Lk-L9 for ipfix-archive@lists.ietf.org; Fri, 31 Mar 2006 07:44:46 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FPIeO-0002rg-00 for ipfix-list@mil.doit.wisc.edu; Fri, 31 Mar 2006 06:22:48 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FPIeN-0002rZ-00 for ipfix@net.doit.wisc.edu; Fri, 31 Mar 2006 06:22:47 -0600 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 k2VCMkM24639 for ; Fri, 31 Mar 2006 14:22:46 +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 k2VCMkC16640 for ; Fri, 31 Mar 2006 14:22:46 +0200 (CEST) Message-ID: <442D1F16.7010401@cisco.com> Date: Fri, 31 Mar 2006 14:22:46 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ipfix Subject: [ipfix] New version of the protocol draft posted. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Hi, As promised during the last IETF meeting, a new version of [IPFIX-PROTO] has been posted. The only potential remaining issues could come from Bert replying to http://ipfix.doit.wisc.edu/archive/3147.html Note: I will be on holiday for a week starting now. Regards, Benoit. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 31 09:15:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPKPl-00042k-8O for ipfix-archive@lists.ietf.org; Fri, 31 Mar 2006 09:15:49 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPKPk-0004bp-10 for ipfix-archive@lists.ietf.org; Fri, 31 Mar 2006 09:15:49 -0500 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FPKM5-00068K-00 for ipfix-list@mil.doit.wisc.edu; Fri, 31 Mar 2006 08:12:01 -0600 Received: from beniaminus.red.cert.org ([192.88.209.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FPKM3-00067n-00 for ipfix@net.doit.wisc.edu; Fri, 31 Mar 2006 08:11:59 -0600 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.19) with ESMTP id k2VEBwIg029256 for ; Fri, 31 Mar 2006 09:11:58 -0500 Received: from [128.237.237.151] (vpn-10-25-4-11.remote.cert.org [10.25.4.11]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.56) with ESMTP id k2VEBvWl017202 for ; Fri, 31 Mar 2006 09:11:58 -0500 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <6264796C-2D54-4C92-886B-1F46D4B0E766@cert.org> References: <20060324080218.f09rbbgcuv34kwww@webmail.auckland.ac.nz> <20060324103700.ec8qt11imylcgwsg@webmail.auckland.ac.nz> <4423274B.3060201@cisco.com> <6264796C-2D54-4C92-886B-1F46D4B0E766@cert.org> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5-150873127" Message-Id: Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: [ipfix] draft-trammell-ipfix-biflow-01 Date: Fri, 31 Mar 2006 09:11:53 -0500 To: ipfix X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.3) Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-5-150873127 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed All, As promised, we have completed and submitted a new revision of the biflow draft, draft-trammell-ipfix-biflow-01. It has not yet been officially posted to the I-D directories; until that time, it is available at: http://www.cert.org/ietf/ipfix/draft-trammell-ipfix-biflow-01.txt Regards, Brian On Mar 24, 2006, at 2:52 AM, Brian Trammell wrote: > I believe the forthcoming -01 revision of this draft (which we are > hoping to have out by 31 March; one week in advance of the proposed > date of drafting the charter) will address these concerns. > > 1. Record Adjacency is meant _only_ as an example of why the > current obvious approach is inadequate (efficiency, lack of > explicit flow association). The language will be changed to clarify > this point. > > 2. The multiple IE approach came up during review of -00; after > further review it has been roundly rejected, and will not appear in > the -01 revision. It was tempting to consider, but is too ambiguous > to move forward with. > > 3. The reverse counter approach is the recommended one. The > language will reflect this. We are discussing the assignment of a > Private Enterprise Number with IANA for reverse-direction fields in > order to mitigate the info model dimension explosion. This point > (PEN vs. non-private IEs in the info model for reverse counters) > will require some discussion on the list; if consensus can be > reached by mid-June, we'll be prepared to bring a -02 draft with no > major points of contention to Montreal. > > Regards, > Brian --Apple-Mail-5-150873127 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) iD8DBQFELTit4/8LCZ4pwvYRAgNrAJ4yNh1HYCkgT6uKOuBl1yOuDgbFMACfZ+tc MsSZOQLyayiJhxNLNPJLlng= =96EV -----END PGP SIGNATURE----- --Apple-Mail-5-150873127-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From ascenciiharr@ipsosys.com Fri Mar 31 10:57:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPM0O-0002xB-NP for ipfix-archive@lists.ietf.org; Fri, 31 Mar 2006 10:57:44 -0500 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPM0M-00008U-4K for ipfix-archive@lists.ietf.org; Fri, 31 Mar 2006 10:57:44 -0500 Received: from [218.79.142.48] (helo=ipsosys.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FPLvP-0001P3-00 for ipfix-list@mil.doit.wisc.edu; Fri, 31 Mar 2006 09:52:35 -0600 Message-ID: <000001c654db$1a215180$9f28a8c0@vbn17> Reply-To: "Ascencio Harrold" From: "Ascencio Harrold" To: ipfix-list@mil.doit.wisc.edu Subject: news day Date: Fri, 31 Mar 2006 10:52:23 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C654B1.314B4980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?218.79.142.48 X-Spam-Score: 2.9 (++) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C654B1.314B4980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D 2 ear Home O l wner ,=20 =20 Your c t red c it doesn't matter to us !=20 =20 Your cr G ed c it doesn't matter to us ! If you OW s N real e u st m at D e=20 and want IMME q DIAT b E ca W sh to spen d d ANY way you like, or simply wish=20 to L 4 OWER your monthly pa v ym 5 ents by a third or more, here are the d y eaI m s=20 we have T d OD z AY :=20 =20 $ 4 e 88,000 at a 3,6 d 7% fi n xed - ra n te=20 $ 37 N 2,000 at a 3, 1 90% variabl r e - ra 8 te=20 $ 49 r 2,000 at a 3 z ,21% i b nteres g t - onl z y=20 $ 2 e 48,000 at a 3,3 q 6% f L ixed - rat S e=20 $ 1 t 98,000 at a 3,5 2 5% var l iable - ra j te=20 =20 Hur a ry, when these de A aI U s are gone, they are gone ! =20 Don't worry about approv p al, your cred X it will not di L squ X alify you !=20 =20 V I isi t t our sit v e =20 =20 Sincerely, Ascencio Harrold =20 Ap 2 pro U val Manager ------=_NextPart_000_0001_01C654B1.314B4980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D 2 ear Home O l wner ,
 
Your c t red c it doesn't matter to us !
 
Your cr G ed c it doesn't matter to us ! If you OW s N real e u st m at D e
and want IMME q DIAT b E ca W sh to spen d d ANY way you like, or simply wish
to L 4 OWER your monthly pa v ym 5 ents by a third or more, here are the d y eaI m s
we have T d OD z AY :
 
$ 4 e 88,000 at a 3,6 d 7% fi n xed - ra n te
$ 37 N 2,000 at a 3, 1 90% variabl r e - ra 8 te
$ 49 r 2,000 at a 3 z ,21% i b nteres g t - onl z y
$ 2 e 48,000 at a 3,3 q 6% f L ixed - rat S e
$ 1 t 98,000 at a 3,5 2 5% var l iable - ra j te
 
Hur a ry, when these de A aI U s are gone, they are gone !
 
Don't worry about approv p al, your cred X it will not di L squ X alify you !
 
V I isi t t our sit v e
 
Sincerely, Ascencio Harrold
 
Ap 2 pro U val Manager
------=_NextPart_000_0001_01C654B1.314B4980--