From owner-psamp@ops.ietf.org Wed Feb 01 04:02:01 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4DsA-0007qu-Q2 for psamp-archive@megatron.ietf.org; Wed, 01 Feb 2006 04:02:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23664 for ; Wed, 1 Feb 2006 04:00:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4DlF-0005ym-JN for psamp-data@psg.com; Wed, 01 Feb 2006 08:54:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [134.2.12.32] (helo=mx5.informatik.uni-tuebingen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4DlD-0005yT-Ii for psamp@ops.ietf.org; Wed, 01 Feb 2006 08:54:44 +0000 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 03CD5112 for ; Wed, 1 Feb 2006 09:54:37 +0100 (MET) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 28444-02 for ; Wed, 1 Feb 2006 09:54:34 +0100 (NFT) Received: from [127.0.0.1] (c64.informatik.uni-tuebingen.de [134.2.168.129]) by mx3.informatik.uni-tuebingen.de (Postfix) with SMTP id 68234145 for ; Wed, 1 Feb 2006 09:54:34 +0100 (MET) Message-ID: <43E07741.8080500@informatik.uni-tuebingen.de> Date: Wed, 01 Feb 2006 09:54:25 +0100 From: Gerhard Muenz User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: psamp@ops.ietf.org Subject: psamp-info: transport/udp/tcpPayloadPacketSection X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000505050902010908010005" X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms000505050902010908010005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear all, In the psamp-info draft, there is an IE for IP payload, L2 payload and MPLS payload. Are there any reasons for not having a similar IE for transport layer payload, e.g. udp|tcpPayloadPacketSection or a generic transportPayloadPacketSection? Regards, Gerhard -- Dipl.-Ing. Gerhard Münz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science, University of Tuebingen Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 EMail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms000505050902010908010005 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJWzCC AwgwggJxoAMCAQICAw4BrjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwMjEwMTMyMjAzWhcNMDYwMjEwMTMyMjAz WjBsMQ4wDAYDVQQEEwVNdWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFy ZCBNdWVuejEwMC4GCSqGSIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2Vu LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu+Ddf3/ZMbVsYVJH/KMciCFj JzwlpTcHLnkD1LOBW08ENmWK/8RzDeFGXFiz8uRSNa+vPIrh35GvLpn/kPdvOyizW+iNs1F+ UMUVc4GOEBxMpqkRPfVKPWytwGjM3FHLakjcxWDcclyDCI9bwrL/0wGiBIafOTC39YRLzOlK LKQ/4i6AJ4uiKdmr8f/MFJ7zBcP4dkeKRQmmakrpC1uDFI7k2xLwSAdKT4uTP+KEDYMR1TAK Kvu747IQNZlyxRWqcH8gB6Msp6yN6tjV/hSiQnGbJVNNT/J8/MjlQcEAgW/zMmdWd83ortQN vuYFDMGyvVoNl6y0mQ0KcyXqUV4toQIDAQABoz4wPDAsBgNVHREEJTAjgSFtdWVuekBpbmZv cm1hdGlrLnVuaS10dWViaW5nZW4uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQBxYP9Bynfu+K/n2QN3AIh1WVD3wOKw5vj2vSsRnhXR4akLKJrRoaU+WXLc5p9qa7j/3zBm OckyashMUgx0zC59a1huaSM4t/qzB+wwZpgXOasAO3y0YeXUHDc8Zv6DPQJlGuOtYOcLl1tB 9Gm/V4Y3PYj6Uihwe/T6lZIPGampaDCCAwgwggJxoAMCAQICAw4BrjANBgkqhkiG9w0BAQQF ADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUw MjEwMTMyMjAzWhcNMDYwMjEwMTMyMjAzWjBsMQ4wDAYDVQQEEwVNdWVuejEQMA4GA1UEKhMH R2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqGSIb3DQEJARYhbXVlbnpA aW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAu+Ddf3/ZMbVsYVJH/KMciCFjJzwlpTcHLnkD1LOBW08ENmWK/8RzDeFGXFiz8uRS Na+vPIrh35GvLpn/kPdvOyizW+iNs1F+UMUVc4GOEBxMpqkRPfVKPWytwGjM3FHLakjcxWDc clyDCI9bwrL/0wGiBIafOTC39YRLzOlKLKQ/4i6AJ4uiKdmr8f/MFJ7zBcP4dkeKRQmmakrp C1uDFI7k2xLwSAdKT4uTP+KEDYMR1TAKKvu747IQNZlyxRWqcH8gB6Msp6yN6tjV/hSiQnGb JVNNT/J8/MjlQcEAgW/zMmdWd83ortQNvuYFDMGyvVoNl6y0mQ0KcyXqUV4toQIDAQABoz4w PDAsBgNVHREEJTAjgSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUwDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBxYP9Bynfu+K/n2QN3AIh1WVD3wOKw5vj2vSsR nhXR4akLKJrRoaU+WXLc5p9qa7j/3zBmOckyashMUgx0zC59a1huaSM4t/qzB+wwZpgXOasA O3y0YeXUHDc8Zv6DPQJlGuOtYOcLl1tB9Gm/V4Y3PYj6Uihwe/T6lZIPGampaDCCAz8wggKo oAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwt ZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNV HRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNv bS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzR UIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6E sZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh eILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDgGuMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDIwMTA4NTQyNVowIwYJKoZIhvcN AQkEMRYEFE501xj3WiydjIxk4X7Tq4zL8aBbMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAgMOAa4wegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDgGuMA0GCSqGSIb3DQEBAQUABIIBAFv0 owN9lGtYPy/fMe13xwpQor0Gk3tDuRN14ATtkeTHu1YLDj/4/1IruchCyZ5w1ji7vO8xRDH3 CGDQRdSZFeD1ety2FycchrKcX3Jdj4klb5h5mRYzV3B/oa7JGkasUrf6bmRUojARh/iFRSrF Kdq6S0UZzX2YIr67LpaFg173WkR1kGLupO6JweZM8yzYVb0oZKnFhShmDwMh3tQr7K7rvtiN by/+d/t5xoOk2uSTj8Uli5RMtx3cXljnwC3L+4KwHCvn0PFi5GMWdEryGbsIEx9Gw2aYYzMq IosBLGraeopdjrQOgbG4QktSxwZOSjfCCn35ckSBofMKSDmMWYYAAAAAAAA= --------------ms000505050902010908010005-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Wed Feb 01 08:52:20 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4IPE-0001T6-JF for psamp-archive@megatron.ietf.org; Wed, 01 Feb 2006 08:52:20 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29581 for ; Wed, 1 Feb 2006 08:50:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4IIk-000N5u-Dw for psamp-data@psg.com; Wed, 01 Feb 2006 13:45:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4IIj-000N5E-4g for psamp@ops.ietf.org; Wed, 01 Feb 2006 13:45:37 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 01 Feb 2006 14:45:36 +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 k11DjX5i006260; Wed, 1 Feb 2006 14:45:34 +0100 (MET) Received: from [10.61.64.13] (ams-clip-vpn-dhcp13.cisco.com [10.61.64.13]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA03036; Wed, 1 Feb 2006 13:45:30 GMT Message-ID: <43E0BB7A.3030007@cisco.com> Date: Wed, 01 Feb 2006 13:45:30 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Gerhard Muenz CC: psamp@ops.ietf.org Subject: Re: psamp-info: transport/udp/tcpPayloadPacketSection References: <43E07741.8080500@informatik.uni-tuebingen.de> In-Reply-To: <43E07741.8080500@informatik.uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Gerhard Muenz wrote: > > Dear all, > > In the psamp-info draft, there is an IE for IP payload, L2 payload and > MPLS payload. > Are there any reasons for not having a similar IE for transport layer > payload, e.g. udp|tcpPayloadPacketSection or a generic > transportPayloadPacketSection? A generic transport payload IE is not feasible because to implement properly an implementation would have to understand and parse all transport protocols, including ones which are yet to be defined. At this time, it is expected that the IP payload type will be sufficient because correct interpretation of the transport payload will most likely require much of the information from the transport header, and the IP payload IE will provide both. If you, or anyone, has an application that would require that PSAMP be extended in some way then please mail the list details of the application and we can discuss the best way to address the requirements, possibly requesting new IEs as needed. Don't forget, however, that new IEs can be requested at any time in the future, so we don't have to cover all cases right now. regards Andrew -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Feb 02 03:30:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Zr3-00006h-Pa for psamp-archive@megatron.ietf.org; Thu, 02 Feb 2006 03:30:14 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10462 for ; Thu, 2 Feb 2006 03:28:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4Zk9-0006GU-Nz for psamp-data@psg.com; Thu, 02 Feb 2006 08:23:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [134.2.12.32] (helo=mx5.informatik.uni-tuebingen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4Zk5-0006G1-1g for psamp@ops.ietf.org; Thu, 02 Feb 2006 08:23:02 +0000 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 652E4115 for ; Thu, 2 Feb 2006 09:22:59 +0100 (MET) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 28524-02 for ; Thu, 2 Feb 2006 09:22:57 +0100 (NFT) Received: from [127.0.0.1] (c64.informatik.uni-tuebingen.de [134.2.168.129]) by mx3.informatik.uni-tuebingen.de (Postfix) with SMTP id C434E144 for ; Thu, 2 Feb 2006 09:22:56 +0100 (MET) Message-ID: <43E1C157.4090009@informatik.uni-tuebingen.de> Date: Thu, 02 Feb 2006 09:22:47 +0100 From: Gerhard Muenz User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: psamp@ops.ietf.org Subject: Re: psamp-info: transport/udp/tcpPayloadPacketSection References: <43E07741.8080500@informatik.uni-tuebingen.de> <43E0BB7A.3030007@cisco.com> In-Reply-To: <43E0BB7A.3030007@cisco.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040600000004050205010207" X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms040600000004050205010207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear Andrew, all, Comments inline: Andrew Johnson wrote: > Gerhard Muenz wrote: >> In the psamp-info draft, there is an IE for IP payload, L2 payload and >> MPLS payload. >> Are there any reasons for not having a similar IE for transport layer >> payload, e.g. udp|tcpPayloadPacketSection or a generic >> transportPayloadPacketSection? > > A generic transport payload IE is not feasible because to implement > properly an implementation would have to understand and parse all > transport protocols, including ones which are yet to be defined. I thought of a generic transportPayloadPacketSection similar to the sourceTransportPort that exists besides udp|tcpTransportPort. In any case, a monitor would only export the information it is able to retrieve from a packet. Apart from the generic type, is there any argument against IEs for udp|tcpPacketPayloadSection? Since IEs for almost all UDP/TCP header fields exist, the payload type would cover the remaining unparsed packet data. > At this time, it is expected that the IP payload type will be sufficient > because correct interpretation of the transport payload will most likely > require much of the information from the transport header, and the IP > payload IE will provide both. The IP payload type is sufficient but inefficient if you are not interested in the whole transport header but only in some specific fields (such as port numbers). In this case you would export much more data than you need. > If you, or anyone, has an application that would require that PSAMP be > extended in some way then please mail the list details of the application > and we can discuss the best way to address the requirements, possibly > requesting new IEs as needed. Don't forget, however, that new IEs can > be requested at any time in the future, so we don't have to cover all > cases right now. An application I'm working on is signature detection on sampled packets. Regards, Gerhard -- Dipl.-Ing. Gerhard Münz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science, University of Tuebingen Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 EMail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms040600000004050205010207 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJWzCC AwgwggJxoAMCAQICAw4BrjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwMjEwMTMyMjAzWhcNMDYwMjEwMTMyMjAz WjBsMQ4wDAYDVQQEEwVNdWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFy ZCBNdWVuejEwMC4GCSqGSIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2Vu LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu+Ddf3/ZMbVsYVJH/KMciCFj JzwlpTcHLnkD1LOBW08ENmWK/8RzDeFGXFiz8uRSNa+vPIrh35GvLpn/kPdvOyizW+iNs1F+ UMUVc4GOEBxMpqkRPfVKPWytwGjM3FHLakjcxWDcclyDCI9bwrL/0wGiBIafOTC39YRLzOlK LKQ/4i6AJ4uiKdmr8f/MFJ7zBcP4dkeKRQmmakrpC1uDFI7k2xLwSAdKT4uTP+KEDYMR1TAK Kvu747IQNZlyxRWqcH8gB6Msp6yN6tjV/hSiQnGbJVNNT/J8/MjlQcEAgW/zMmdWd83ortQN vuYFDMGyvVoNl6y0mQ0KcyXqUV4toQIDAQABoz4wPDAsBgNVHREEJTAjgSFtdWVuekBpbmZv cm1hdGlrLnVuaS10dWViaW5nZW4uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQBxYP9Bynfu+K/n2QN3AIh1WVD3wOKw5vj2vSsRnhXR4akLKJrRoaU+WXLc5p9qa7j/3zBm OckyashMUgx0zC59a1huaSM4t/qzB+wwZpgXOasAO3y0YeXUHDc8Zv6DPQJlGuOtYOcLl1tB 9Gm/V4Y3PYj6Uihwe/T6lZIPGampaDCCAwgwggJxoAMCAQICAw4BrjANBgkqhkiG9w0BAQQF ADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUw MjEwMTMyMjAzWhcNMDYwMjEwMTMyMjAzWjBsMQ4wDAYDVQQEEwVNdWVuejEQMA4GA1UEKhMH R2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqGSIb3DQEJARYhbXVlbnpA aW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAu+Ddf3/ZMbVsYVJH/KMciCFjJzwlpTcHLnkD1LOBW08ENmWK/8RzDeFGXFiz8uRS Na+vPIrh35GvLpn/kPdvOyizW+iNs1F+UMUVc4GOEBxMpqkRPfVKPWytwGjM3FHLakjcxWDc clyDCI9bwrL/0wGiBIafOTC39YRLzOlKLKQ/4i6AJ4uiKdmr8f/MFJ7zBcP4dkeKRQmmakrp C1uDFI7k2xLwSAdKT4uTP+KEDYMR1TAKKvu747IQNZlyxRWqcH8gB6Msp6yN6tjV/hSiQnGb JVNNT/J8/MjlQcEAgW/zMmdWd83ortQNvuYFDMGyvVoNl6y0mQ0KcyXqUV4toQIDAQABoz4w PDAsBgNVHREEJTAjgSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUwDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBxYP9Bynfu+K/n2QN3AIh1WVD3wOKw5vj2vSsR nhXR4akLKJrRoaU+WXLc5p9qa7j/3zBmOckyashMUgx0zC59a1huaSM4t/qzB+wwZpgXOasA O3y0YeXUHDc8Zv6DPQJlGuOtYOcLl1tB9Gm/V4Y3PYj6Uihwe/T6lZIPGampaDCCAz8wggKo oAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwt ZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNV HRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNv bS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzR UIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6E sZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh eILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDgGuMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDIwMjA4MjI0N1owIwYJKoZIhvcN AQkEMRYEFG2vbUxho1k/0i+s+kExpUeJfjMuMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAgMOAa4wegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDgGuMA0GCSqGSIb3DQEBAQUABIIBAI4l iznQrw1fc0wrzufL2sN35musSVYxam+BZZZsJDGd2E6KiqvH/RXJs2zDxyuEkR/Li1yge7PD hl7ruJnzxL8P/oig6bxUUNEjmHPtyEPdzzOHyuHtpudIPOvFIunZMg3ufVWi6qx2FdiBDPDY f85881KD7ALnU9BcLvLceUmnumEnFg91O5K6ikVNuf/P5yXej9/P3lEJ0+2zEI1fbW7ILLTl 5K1z3j/g8JIzyzTYfpHyMcccreYRxId6/UYvzIY9NAoQ4GeQlKMiF5sy/d+ahPCRE6sQtPay Oi1oeQ52aFYjjOGk1YpC/waThGJoJmK+u3+yqo6AtNCRjlK+46EAAAAAAAA= --------------ms040600000004050205010207-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Feb 02 12:36:46 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4iNo-0008WQ-J2 for psamp-archive@megatron.ietf.org; Thu, 02 Feb 2006 12:36:46 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22978 for ; Thu, 2 Feb 2006 12:34:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4iIq-000HXG-2J for psamp-data@psg.com; Thu, 02 Feb 2006 17:31:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4iIm-000HWx-9L for psamp@ops.ietf.org; Thu, 02 Feb 2006 17:31:24 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 02 Feb 2006 18:31:23 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k12HVI5i010159; Thu, 2 Feb 2006 18:31:19 +0100 (MET) Received: from [144.254.153.40] (dhcp-144-254-153-40.cisco.com [144.254.153.40]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA25343; Thu, 2 Feb 2006 17:31:14 GMT Message-ID: <43E241E2.9000805@cisco.com> Date: Thu, 02 Feb 2006 17:31:14 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Gerhard Muenz CC: psamp@ops.ietf.org Subject: Re: psamp-info: transport/udp/tcpPayloadPacketSection References: <43E07741.8080500@informatik.uni-tuebingen.de> <43E0BB7A.3030007@cisco.com> <43E1C157.4090009@informatik.uni-tuebingen.de> In-Reply-To: <43E1C157.4090009@informatik.uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Gerhard If I recall correctly, the packet section fields were defined to meet the PSAMP requirements and provide a minimum requirement for the basic packet reports. The extended packet reports can contain any information you like as long as you have an IE for it, so I hope you don't feel that the current PSAMP drafts will restrict what you want to do. Some more inline: Gerhard Muenz wrote: >> A generic transport payload IE is not feasible because to implement >> properly an implementation would have to understand and parse all >> transport protocols, including ones which are yet to be defined. > > I thought of a generic transportPayloadPacketSection similar to the > sourceTransportPort that exists besides udp|tcpTransportPort. In any > case, a monitor would only export the information it is able to retrieve > from a packet. Sure, but the sourceTransportPort is restricted to specifically TCP, UDP and SCTP. Where is gets a bit woolly, and the part I don't like, is the option to use it for future protocols, which could lead to different implementations of the protocol doing different things for the same traffic. I think that all our IEs should have very solid definitions. > Apart from the generic type, is there any argument against IEs for > udp|tcpPacketPayloadSection? Since IEs for almost all UDP/TCP header > fields exist, the payload type would cover the remaining unparsed packet > data. If a new IE was created to cover UDP, TCP and SCTP payloads then I suppose that would be fine. The option to use it with future types is debatable but I wouldn't object if it was consistent with the transportSourcePort field. [SNIP] >> If you, or anyone, has an application that would require that PSAMP be >> extended in some way then please mail the list details of the application >> and we can discuss the best way to address the requirements, possibly >> requesting new IEs as needed. Don't forget, however, that new IEs can >> be requested at any time in the future, so we don't have to cover all >> cases right now. > > An application I'm working on is signature detection on sampled packets. OK, to summarise then. Would I be right in saying that current PSAMP drafts meet your requirements with the basic packet reports, and could be met more efficiently with certain extended packet reports? To be more efficient still you want a new IE for just the TCP or UDP (and maybe SCTP) payload? In which case I would say that this new IE doesn't specifically belong in the PSAMP drafts, it is merely one of the many IEs that can be used in an extended packet report. That said, the IE may be relevant and generally useful enough to be included in the PSAMP drafts as a good candidate for extended packet reports. The alternative is for you to request the IE yourself on the IPFIX mailing list. Cheers Andrew -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Feb 02 13:30:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4jEP-0004fg-UO for psamp-archive@megatron.ietf.org; Thu, 02 Feb 2006 13:30:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27026 for ; Thu, 2 Feb 2006 13:29:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4jAI-000LDG-53 for psamp-data@psg.com; Thu, 02 Feb 2006 18:26:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [134.2.12.32] (helo=mx5.informatik.uni-tuebingen.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F4jAD-000LCt-3j for psamp@ops.ietf.org; Thu, 02 Feb 2006 18:26:37 +0000 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 0E0D711C for ; Thu, 2 Feb 2006 19:26:36 +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 28578-03 for ; Thu, 2 Feb 2006 19:26:33 +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 4CABA115 for ; Thu, 2 Feb 2006 19:26:33 +0100 (MET) Message-ID: <43E24ED0.3050401@informatik.uni-tuebingen.de> Date: Thu, 02 Feb 2006 19:26:24 +0100 From: Gerhard Muenz User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: psamp@ops.ietf.org Subject: Re: psamp-info: transport/udp/tcpPayloadPacketSection References: <43E07741.8080500@informatik.uni-tuebingen.de> <43E0BB7A.3030007@cisco.com> <43E1C157.4090009@informatik.uni-tuebingen.de> <43E241E2.9000805@cisco.com> In-Reply-To: <43E241E2.9000805@cisco.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070502020208050308070704" X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms070502020208050308070704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Andrew, Of course, the psamp-info draft does not restrict me since I can always define my own IEs. It's just that having such an IE in the standard would have looked natural to me. Cheers, Gerhard Andrew Johnson wrote: > Hi Gerhard > > If I recall correctly, the packet section fields were defined to > meet the PSAMP requirements and provide a minimum requirement for > the basic packet reports. The extended packet reports can contain > any information you like as long as you have an IE for it, so I hope > you don't feel that the current PSAMP drafts will restrict what you > want to do. > > Some more inline: > > > Gerhard Muenz wrote: > >>> A generic transport payload IE is not feasible because to implement >>> properly an implementation would have to understand and parse all >>> transport protocols, including ones which are yet to be defined. >> >> >> I thought of a generic transportPayloadPacketSection similar to the >> sourceTransportPort that exists besides udp|tcpTransportPort. In any >> case, a monitor would only export the information it is able to >> retrieve from a packet. > > > Sure, but the sourceTransportPort is restricted to specifically TCP, > UDP and SCTP. Where is gets a bit woolly, and the part I don't like, is > the option to use it for future protocols, which could lead to different > implementations of the protocol doing different things for the same > traffic. I think that all our IEs should have very solid definitions. > > >> Apart from the generic type, is there any argument against IEs for >> udp|tcpPacketPayloadSection? Since IEs for almost all UDP/TCP header >> fields exist, the payload type would cover the remaining unparsed >> packet data. > > > If a new IE was created to cover UDP, TCP and SCTP payloads then I suppose > that would be fine. The option to use it with future types is debatable > but I wouldn't object if it was consistent with the transportSourcePort > field. > > > [SNIP] > >>> If you, or anyone, has an application that would require that PSAMP be >>> extended in some way then please mail the list details of the >>> application >>> and we can discuss the best way to address the requirements, possibly >>> requesting new IEs as needed. Don't forget, however, that new IEs can >>> be requested at any time in the future, so we don't have to cover all >>> cases right now. >> >> >> An application I'm working on is signature detection on sampled packets. > > > OK, to summarise then. Would I be right in saying that current PSAMP > drafts > meet your requirements with the basic packet reports, and could be met more > efficiently with certain extended packet reports? To be more efficient > still you want a new IE for just the TCP or UDP (and maybe SCTP) payload? > > In which case I would say that this new IE doesn't specifically belong in > the PSAMP drafts, it is merely one of the many IEs that can be used in an > extended packet report. That said, the IE may be relevant and generally > useful enough to be included in the PSAMP drafts as a good candidate for > extended packet reports. The alternative is for you to request the IE > yourself on the IPFIX mailing list. > > > Cheers > > Andrew > -- Dipl.-Ing. Gerhard Münz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science, University of Tuebingen Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 EMail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms070502020208050308070704 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJWzCC AwgwggJxoAMCAQICAw4BrjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwMjEwMTMyMjAzWhcNMDYwMjEwMTMyMjAz WjBsMQ4wDAYDVQQEEwVNdWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFy ZCBNdWVuejEwMC4GCSqGSIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2Vu LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu+Ddf3/ZMbVsYVJH/KMciCFj JzwlpTcHLnkD1LOBW08ENmWK/8RzDeFGXFiz8uRSNa+vPIrh35GvLpn/kPdvOyizW+iNs1F+ UMUVc4GOEBxMpqkRPfVKPWytwGjM3FHLakjcxWDcclyDCI9bwrL/0wGiBIafOTC39YRLzOlK LKQ/4i6AJ4uiKdmr8f/MFJ7zBcP4dkeKRQmmakrpC1uDFI7k2xLwSAdKT4uTP+KEDYMR1TAK Kvu747IQNZlyxRWqcH8gB6Msp6yN6tjV/hSiQnGbJVNNT/J8/MjlQcEAgW/zMmdWd83ortQN vuYFDMGyvVoNl6y0mQ0KcyXqUV4toQIDAQABoz4wPDAsBgNVHREEJTAjgSFtdWVuekBpbmZv cm1hdGlrLnVuaS10dWViaW5nZW4uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQBxYP9Bynfu+K/n2QN3AIh1WVD3wOKw5vj2vSsRnhXR4akLKJrRoaU+WXLc5p9qa7j/3zBm OckyashMUgx0zC59a1huaSM4t/qzB+wwZpgXOasAO3y0YeXUHDc8Zv6DPQJlGuOtYOcLl1tB 9Gm/V4Y3PYj6Uihwe/T6lZIPGampaDCCAwgwggJxoAMCAQICAw4BrjANBgkqhkiG9w0BAQQF ADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUw MjEwMTMyMjAzWhcNMDYwMjEwMTMyMjAzWjBsMQ4wDAYDVQQEEwVNdWVuejEQMA4GA1UEKhMH R2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqGSIb3DQEJARYhbXVlbnpA aW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAu+Ddf3/ZMbVsYVJH/KMciCFjJzwlpTcHLnkD1LOBW08ENmWK/8RzDeFGXFiz8uRS Na+vPIrh35GvLpn/kPdvOyizW+iNs1F+UMUVc4GOEBxMpqkRPfVKPWytwGjM3FHLakjcxWDc clyDCI9bwrL/0wGiBIafOTC39YRLzOlKLKQ/4i6AJ4uiKdmr8f/MFJ7zBcP4dkeKRQmmakrp C1uDFI7k2xLwSAdKT4uTP+KEDYMR1TAKKvu747IQNZlyxRWqcH8gB6Msp6yN6tjV/hSiQnGb JVNNT/J8/MjlQcEAgW/zMmdWd83ortQNvuYFDMGyvVoNl6y0mQ0KcyXqUV4toQIDAQABoz4w PDAsBgNVHREEJTAjgSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUwDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBxYP9Bynfu+K/n2QN3AIh1WVD3wOKw5vj2vSsR nhXR4akLKJrRoaU+WXLc5p9qa7j/3zBmOckyashMUgx0zC59a1huaSM4t/qzB+wwZpgXOasA O3y0YeXUHDc8Zv6DPQJlGuOtYOcLl1tB9Gm/V4Y3PYj6Uihwe/T6lZIPGampaDCCAz8wggKo oAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwt ZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNV HRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNv bS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzR UIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6E sZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh eILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDgGuMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDIwMjE4MjYyNFowIwYJKoZIhvcN AQkEMRYEFH5/+ubDww3C3FyXXa1AiB+a6OToMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAgMOAa4wegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDgGuMA0GCSqGSIb3DQEBAQUABIIBAH3s xiMsjmSZqnXTmPIVyxFXSrGkEwJCrgGIjr966luTKwG49Beiwpy3+6h2lf4SRo4xM0VqBuSG b0+ogaHZzSKn22XgaHdkQQhXVgixHcYN0kTkCkNZfjK6V+oBs1G/SBHngdpQoRreD11FdDTP pbuaSEt+6oZxIgLE0p40lSxG0/cdhRBfvl0hJntgqVKe1HdTUXo+WvOSs3brBsvc99wXM6PD K/KYwry9mSrEpGSR7JiBwnFiqdaGpV1x/Oi8qKPdNigRtl6YdwMboroKdeiiBuHtChnzxhMl vviccG/BFunsuEiYI86Cc+6M4hAHbTSE+5Gps36cwCbEKKAyTRQAAAAAAAA= --------------ms070502020208050308070704-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Feb 23 11:31:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCJNU-0002oh-Q5 for psamp-archive@lists.ietf.org; Thu, 23 Feb 2006 11:31:40 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCJNT-0004I6-HO for psamp-archive@lists.ietf.org; Thu, 23 Feb 2006 11:31:40 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCJGg-000HGd-DI for psamp-data@psg.com; Thu, 23 Feb 2006 16:24:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FCJGf-000HGL-9b for psamp@ops.ietf.org; Thu, 23 Feb 2006 16:24:37 +0000 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 9E0911BAC4D for ; Thu, 23 Feb 2006 17:26:09 +0100 (CET) Date: Thu, 23 Feb 2006 17:24:32 +0100 From: Juergen Quittek To: psamp@ops.ietf.org Subject: PSAMP session in Dallas Message-ID: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Dear all, We will have a PSAMP session in Dallas. Since all drafts are approaching maturity, this will probably be the last PSAMP session. According to the current draft of the meeting agenda our session is scheduled on WEDNESDAY, March 22 2006 in Afternoon Session II at 1510-1610 h immediately after the IPFIX session (and hopefully in the same room). I will soon post a suggestion for the agenda. If you have suggestions, please send them. Thanks, Juergen -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Feb 27 06:51:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDgu6-0001Uv-AY for psamp-archive@lists.ietf.org; Mon, 27 Feb 2006 06:51:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDgu6-0007Eu-1C for psamp-archive@lists.ietf.org; Mon, 27 Feb 2006 06:51:02 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDgnS-00093M-VC for psamp-data@psg.com; Mon, 27 Feb 2006 11:44:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDgnS-00092o-0X for psamp@ops.ietf.org; Mon, 27 Feb 2006 11:44:10 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k1RBi8n23457; Mon, 27 Feb 2006 12:44:08 +0100 (CET) Received: from [10.61.65.251] (ams-clip-vpn-dhcp507.cisco.com [10.61.65.251]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k1RBi7C09074; Mon, 27 Feb 2006 12:44:07 +0100 (CET) Message-ID: <4402E607.2040004@cisco.com> Date: Mon, 27 Feb 2006 12:44:07 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Tanja Zseby CC: Benoit Claise , psamp Subject: Re: Open Issue 6: Associations ID -> Selection Path References: <43A816BC.2030604@cisco.com> <43AA9667.2070909@fokus.fraunhofer.de> <43AB3234.9050709@cisco.com> In-Reply-To: <43AB3234.9050709@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Tanja, Will you modify the Associations ID into Selection Path in the next [PSAMP-TECH] version? Or should I add a short sentence in [PSAMP-PROTO]: "the Selection Path is referred to as the Associations ID in [PSAMP-TECH]" My personal choice, in order to avoid any confusion, would go for the [PSAMP-TECH] modification. Regards, Benoit. > Ok, I made the modifications for the new draft that I will be posting > soon. > > Regards, Benoit. >> Hi Benoit, >> >> I also prefer Selection Path. >> >> Kind regards, >> Tanja >> >> Benoit Claise wrote: >> >>> Dear all, >>> >>> The PSAMP open issue 6 is the following: >>> >>> Even if the notion of Associations ID is mentioned in [PSAMP-TECH], >>> maybe a term such as SelectionPath or PathID would be more >>> appropriate. >>> >>> The background of this issue is the following. >>> [PSAMP-TECH] specifies the Associations ID like this: >>> >>> ASSOCIATIONS Values: >> ID, IPFIX Exporting process ID, IDs of other associated >>> processes> With STREAM ID: Observation point ID AND List of >>> SELECTOR_IDs >>> However, we concluded during the last IETF meeting that we don't >>> need the IPFIX Metering and Exporting Process ID. >>> So we're left with: >>> >>> Values: >>> >>> Since we don't associate anymore the observation point with >>> processes, it was proposed to change the name: >>> from "Associations ID" to "Selection Path" or "Path ID". >>> >>> Personally, I prefer the Selection Path term, along with the >>> selectionPath I.E. >>> For the simple reason that we speak of selection methods all over in >>> the PSAMP drafts. >>> >>> Feedback? >>> >>> Regards, Benoit. >>> >>> >>> >> > > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Feb 27 09:39:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjWu-0003N7-1I for psamp-archive@lists.ietf.org; Mon, 27 Feb 2006 09:39:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDjWs-0004JK-HQ for psamp-archive@lists.ietf.org; Mon, 27 Feb 2006 09:39:16 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDjSJ-000I7d-LL for psamp-data@psg.com; Mon, 27 Feb 2006 14:34:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [193.174.154.14] (helo=mailhub.fokus.fraunhofer.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDh1t-0009xx-E0 for psamp@ops.ietf.org; Mon, 27 Feb 2006 11:59:05 +0000 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id k1RBx2v27248; Mon, 27 Feb 2006 12:59:02 +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: Open Issue 6: Associations ID -> Selection Path Date: Mon, 27 Feb 2006 12:59:03 +0100 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA1058FC9@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open Issue 6: Associations ID -> Selection Path Thread-Index: AcY7ky45trdHYCTLSX6jpzKvSqhq2wAAejUQ From: "Tanja Zseby" To: "Benoit Claise" Cc: "psamp" Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Hi Benoit, I will modify it in the PSAMP-TECH draft.=20 Regards, Tanja -----Original Message----- From: Benoit Claise [mailto:bclaise@cisco.com]=20 Sent: Monday, February 27, 2006 12:44 PM To: Tanja Zseby Cc: Benoit Claise; psamp Subject: Re: Open Issue 6: Associations ID -> Selection Path Tanja, Will you modify the Associations ID into Selection Path in the next [PSAMP-TECH] version? Or should I add a short sentence in [PSAMP-PROTO]: "the Selection Path is referred to as the Associations ID in [PSAMP-TECH]" My personal choice, in order to avoid any confusion, would go for the [PSAMP-TECH] modification. Regards, Benoit. > Ok, I made the modifications for the new draft that I will be posting=20 > soon. > > Regards, Benoit. >> Hi Benoit, >> >> I also prefer Selection Path. >> >> Kind regards, >> Tanja >> >> Benoit Claise wrote: >> >>> Dear all, >>> >>> The PSAMP open issue 6 is the following: >>> >>> Even if the notion of Associations ID is mentioned in [PSAMP-TECH], >>> maybe a term such as SelectionPath or PathID would be more=20 >>> appropriate. >>> >>> The background of this issue is the following. >>> [PSAMP-TECH] specifies the Associations ID like this: >>> >>> ASSOCIATIONS Values: >> ID, IPFIX Exporting process ID, IDs of other associated=20 >>> processes> With STREAM ID: Observation point ID AND List of >>> SELECTOR_IDs >>> However, we concluded during the last IETF meeting that we don't=20 >>> need the IPFIX Metering and Exporting Process ID. >>> So we're left with: >>> >>> Values: >>> >>> Since we don't associate anymore the observation point with=20 >>> processes, it was proposed to change the name: >>> from "Associations ID" to "Selection Path" or "Path ID". >>> >>> Personally, I prefer the Selection Path term, along with the=20 >>> selectionPath I.E. >>> For the simple reason that we speak of selection methods all over in >>> the PSAMP drafts. >>> >>> Feedback? >>> >>> Regards, Benoit. >>> >>> >>> >> > > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with the=20 > word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Feb 27 10:45:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDkYn-0003xL-NQ for psamp-archive@lists.ietf.org; Mon, 27 Feb 2006 10:45:17 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDkYm-0007B9-AS for psamp-archive@lists.ietf.org; Mon, 27 Feb 2006 10:45:17 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDkUo-000NGw-5x for psamp-data@psg.com; Mon, 27 Feb 2006 15:41:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDkUn-000NGh-Cg for psamp@ops.ietf.org; Mon, 27 Feb 2006 15:41:09 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k1RFf7F09635; Mon, 27 Feb 2006 16:41:07 +0100 (CET) Received: from [10.61.80.197] (ams-clip-vpn-dhcp4294.cisco.com [10.61.80.197]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k1RFf7C19686; Mon, 27 Feb 2006 16:41:07 +0100 (CET) Message-ID: <44031D93.8010404@cisco.com> Date: Mon, 27 Feb 2006 16:41:07 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Juergen Quittek CC: psamp Subject: Re: PSAMP IANA considerations section References: <43A92B20.3020600@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Juergen, This open issue should find a solution for the next version of the draft, to be published by Monday. See inline. > --On 21.12.2005 11:14 Uhr +0100 Benoit Claise wrote: > >> Dear all, >> >> Here is a proposal for the IANA considerations section. >> >> >> 1. 9. IANA Considerations >> >> The PSAMP Protocol, as set out in this document, has two sets of >> assigned numbers. Considerations for assigning them are discussed in >> this section, using the example policies as set out in the >> "Guidelines for IANA Considerations" document IANA-RFC >> [RFC2434]. >> >> 9.1 IPFIX Related Considerations >> >> As the PSAMP protocol uses the IPFIX protocol, refer to the IANA >> considerations section in [IPFIX-PROTO] for the assignments of >> numbers used in the protocol and for the numbers used in the >> information model. >> >> 9.2 PSAMP Related Considerations >> >> Each new selection method MUST be assigned a unique value for the >> selectorAlgorithm Information Element. Its configuration >> parameter(s), along with the way to report it/them with an Options >> Template, MUST be clearly specified. >> >> Each new selection method MUST be assigned a unique value for the >> selectorAlgorithm Information Element. New assignments for the PSAMP >> selection method will be administered by IANA, on a First Come First >> Served basis [RFC 2434], subject to Expert >> Review [RFC 2434], i.e. review by one of a group of experts >> designated by an IETF Operations and Management Area Director. The >> group of experts must double check the Information Elements >> definitions with already defined Information Elements for >> completeness, accuracy and redundancy. Those experts will initially >> be drawn from the Working Group Chairs and document editors of the >> IPFIX and PSAMP Working Groups. >> >> Now, two questions: >> 1. I'm not too sure whether we should mandate a new IETF RFC for the >> new selection method description? > > This would be a tough requirement. However, it would make sure that the > new methods is well documented. So the text proposal is fine with you, right? > >> 2. I'm not too sure whether we should mandate new IANA-registered >> information elements for the new selection method? > > Since we do not have vendor IDs in here, this is the only way of > achieving > interoperability. I had in mind that the selectorAlgorithm could be specified with the Entreprise Number, for proprietary purposes 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Information Element ident. | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure G: Field Specifier format > >> In other words, can we have proprietary selection method in the >> selectorAlgorithm Information Element? > > Can't we assign an interval, say [1024 - ...] and declare selection > methods > with identifiers in that interval as 'experimental' or even > 'implementation specific'? Do we need this if we use a I.E. proprietary definition with the Entreprise Number? Don't forget that the selectorAlgorithm is specified as an octet. Regards, Benoit. > >> Regards, Benoit. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Tue Feb 28 10:45:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE72L-0006Zp-FT for psamp-archive@lists.ietf.org; Tue, 28 Feb 2006 10:45:17 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE72J-00086y-20 for psamp-archive@lists.ietf.org; Tue, 28 Feb 2006 10:45:17 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE6uK-0007tW-Lo for psamp-data@psg.com; Tue, 28 Feb 2006 15:37:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FE6uJ-0007tL-NM for psamp@ops.ietf.org; Tue, 28 Feb 2006 15:37:00 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k1SFawt09715 for ; Tue, 28 Feb 2006 16:36:58 +0100 (CET) Received: from [10.61.64.86] (ams-clip-vpn-dhcp86.cisco.com [10.61.64.86]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k1SFavC11948; Tue, 28 Feb 2006 16:36:57 +0100 (CET) Message-ID: <44046E19.9060100@cisco.com> Date: Tue, 28 Feb 2006 16:36:57 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Johnson CC: psamp Subject: Re: PSAMP open issue 18: export rate limit? References: <43A9F344.8010308@cisco.com> <43AC191B.6080803@cisco.com> In-Reply-To: <43AC191B.6080803@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Dear all, After speaking with Andrew and Paul, here is a proposal: There MUST be a IPFIX Message export rate limit, configurable per Exporting Process. The Exporting Process MAY rate-limit the export rate on a per Collecting Process basis. Feedback? Regards, Benoit. > Hello Benoit and all. > > Benoit Claise wrote: >> Dear all, >> >> In [PSAMP-FMWK], the following statement is still un-addressed in >> [PSAMP-PROTO] >> PROTO-18 “The exporting process must have an export rate limit, >> configurable per Exporting Process”. >> See section 8.3 for the details >> http://www.ietf.org/internet-drafts/draft-ietf-psamp-framework-10.txt >> >> >> First of all, I have a question regarding the requirement itself. >> Isn't it supposed to mean: “The exporting process must have an export >> rate limit, configurable per Collecting Process”? Otherwise, I don't >> understand the exact requirement when we have a PSAMP device >> exporting to multiple collectors! > > I would say that each Exporting Process exports to only one collector, > but can be fed by multiple Metering Processes. Also, each Metering > Process may feed Multiple Exporting Processes. With this concept we > can rate limit the Exporting Process and it will only affect one > collector. > > >> Then, how to address the requirement? >> Shall we simply update [PSAMP-PROTO] with a sentence such as: "The >> exporting process MUST have an export rate limit, configurable per >> Collecting Process"? >> And that's it? > > If we agree that one Exporting Process deals with only one collector > then this simplifies matters. > > >> Do we keep the export rate limit as a generic term? Or do we define >> precisely what it mean? Example: number of IPFIX Messages, number of >> bytes/s, number of records/s? > > I think we should pick a MUST, such as we MUST be able to rate limit > based on the number of data and option records per second, but you MAY > rate limit on other criteria also, such as bandwidth. This will allow > some common ground between implementations, useful for people who buy > from multiple vendors. > > Regards > > Andrew -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Tue Feb 28 17:48:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEDdj-0007k7-J8 for psamp-archive@lists.ietf.org; Tue, 28 Feb 2006 17:48:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEDdj-0003fj-1I for psamp-archive@lists.ietf.org; Tue, 28 Feb 2006 17:48:19 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEDWt-0009OB-Nj for psamp-data@psg.com; Tue, 28 Feb 2006 22:41:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEDWs-0009Nz-Eu for psamp@ops.ietf.org; Tue, 28 Feb 2006 22:41:14 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k1SMfDL06035 for ; Tue, 28 Feb 2006 23:41:13 +0100 (CET) Received: from [10.61.64.86] (ams-clip-vpn-dhcp86.cisco.com [10.61.64.86]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k1SMfCC23856 for ; Tue, 28 Feb 2006 23:41:12 +0100 (CET) Message-ID: <4404D188.40506@cisco.com> Date: Tue, 28 Feb 2006 23:41:12 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: psamp Subject: PROTO-12: The observation point report interpretation Content-Type: multipart/alternative; boundary="------------010201010001010606000307" Sender: owner-psamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 This is a multi-part message in MIME format. --------------010201010001010606000307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, During the last IETF meeting, we discussed the PSAMP issue 12. PROTO-12 Discuss how to implement the observation point report interpretation (if we need one) The "Associations Report Interpretation" in http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-03.txt, which BTW has been renamed to "Select Path Report Interpretation", currently contains the observationPointId information element, amongst others: Scope: selectionPath Non-Scope: observationPointId selectorId (one or more) Note that the section also specifies: The observationPointID SHOULD be first Information Element and the optional processes SHOULD be last ones so that the path of the selected Packet is provided in the logical order. [PSAMP-INFO] currently specifies: 6.2.19 observationPointId Description: ID of the observation process. Unique in the observation domain. Abstract Data Type: octet ElementId: 320 The issue is that a mapping between the observationPointId and the existing information element(s) such as interfaceId, lineCardId, or routerId is required, adding some complexity in PSAMP, as yet another option template is required. The proposal is that: 1. we don't define the observationPointId in [PSAMP-INFO], but we use the any information element (such as interfaceId, lineCardId, or routerId) to define the observation point 2. as the "Select Path Report Interpretation" is composed only of one observation point and selector Id(s), we simply assume that the non-selector ID(s) is the observation point. This way, we avoid the sentence "The observationPointID SHOULD be first Information Element and the optional processes SHOULD be last ones ." that impose a new rule in IPFIX: the meaning of a specific I.E. depends on the order of the I.E. in the record 3. If a more complex observation point is required such as an unique ID representing a list of interfaces, a new Information Element is defined and can be used right away. Note: an alternate solution would be to have 2 scopes in the "Select Path Report Interpretation": the selectionPath, and the observation point. However, this was not considered as a clean solution. _ Here is the text proposal_ Selection Path Report Interpretation Each Packet Report contains a selectionPath Information Element that identifies the particular combination of Observation Point and Selector(s) used for its selection. For every selectionPath Information Element in use, the PSAMP Device MUST export a Selection Path Report Interpretation using an Options Template with the following Information Element: Scope: selectionPath Non-Scope: one Information Element representing the Observation Point selectorId (one or more) The Information Element representing the Observation Point would typically be taken from the ingressInterface, egressInterface, lineCardId, exporterIPv4Address, exporterIPv6Address (specified in [IPFIX-INFO]), but not limited to those: any Information Element specified in [IFPIX-INFO] or [PSAMP-INFO] can potentially be used. In case of more complex Observation Points (such as a list of interfaces, a bus, etc..), a new Information Element describing the new type of Observation Point must be specified, along with an option template record describing it in more details (if necessary). If the packets are selected by a Composite Selector, the Selection Path is composed of several Primitive Selectors. In such a case, the Selection Path Report Interpretation MUST contain the list of all the Primitive Selector IDs in the Selection Path. If multiple Selectors are contained in the Selection Path Report Interpretation, the Selectors ID MUST be identified in the order they are used. Any feedback? Regards, Benoit. --------------010201010001010606000307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

During the last IETF meeting, we discussed the PSAMP issue 12.
   PROTO-12 Discuss how to implement the observation point report 
   interpretation (if we need one)
The "Associations Report Interpretation" in http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-03.txt, which BTW has been renamed to "Select Path Report Interpretation", currently contains the observationPointId information element, amongst others:
    Scope:     selectionPath 
    Non-Scope: observationPointId 
               selectorId (one or more) 

Note that the section also specifies: 

   The observationPointID SHOULD be first Information Element and the 
   optional processes SHOULD be last ones so that the path of the 
   selected Packet is provided in the logical order. 

[PSAMP-INFO] currently specifies:
6.2.19 observationPointId

Description:
ID of the observation process. Unique in the observation domain.
Abstract Data Type: octet
ElementId: 320
The issue is that a mapping between the observationPointId and the existing information element(s) such as interfaceId, lineCardId, or routerId is required, adding some complexity in PSAMP, as yet another option template is required.
The proposal is that:
1. we don't define the observationPointId in [PSAMP-INFO], but we use the any information element (such as interfaceId, lineCardId, or routerId) to define the observation point
2. as the "Select Path Report Interpretation" is composed only of one observation point and selector Id(s), we simply assume that the non-selector ID(s) is the observation point. This way, we avoid the sentence "The observationPointID SHOULD be first Information Element and the optional processes SHOULD be last ones ." that impose a new rule in IPFIX: the meaning of a specific I.E. depends on the order of the I.E. in the record
3. If a more complex observation point is required such as an unique ID representing a list of interfaces, a new Information Element is defined and can be used right away.

Note: an alternate solution would be to have 2 scopes in the "Select Path Report Interpretation": the selectionPath, and the observation point. However, this was not considered as a clean solution.

Here is the text proposal
Selection Path Report Interpretation

Each Packet Report contains a selectionPath Information Element that identifies the particular combination of Observation Point and Selector(s) used for its selection.  For every selectionPath Information Element in use, the PSAMP Device MUST export a Selection Path Report Interpretation using an Options Template with the following Information Element:

 Scope:          selectionPath
 Non-Scope: one Information Element representing the Observation Point
                     selectorId (one or more)

The Information Element representing the Observation Point would typically be taken from the ingressInterface, egressInterface, lineCardId, exporterIPv4Address, exporterIPv6Address (specified in [IPFIX-INFO]), but not limited to those: any Information Element specified in [IFPIX-INFO] or [PSAMP-INFO] can potentially be used. In case of more complex Observation Points (such as a list of interfaces, a bus, etc..), a new Information Element describing the new type of Observation Point must be specified, along with an option template record describing it in more details (if necessary).

If the packets are selected by a Composite Selector, the Selection Path is composed of several Primitive Selectors.  In such a case, the Selection Path Report Interpretation MUST contain the list of all the Primitive Selector IDs in the Selection Path.  If multiple Selectors are contained in the Selection Path Report Interpretation, the Selectors ID MUST be identified in the order they are used.

Any feedback?


Regards, Benoit.
--------------010201010001010606000307-- -- 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: