From muenz@net.in.tum.de Sun Jan 2 11:59:44 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69FB3A69C1; Sun, 2 Jan 2011 11:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znvs79hlYJbz; Sun, 2 Jan 2011 11:59:43 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id E1AF33A69C0; Sun, 2 Jan 2011 11:59:42 -0800 (PST) Received: from [192.168.2.152] (ppp-88-217-14-92.dynamic.mnet-online.de [88.217.14.92]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 7F2FF2083FCB; Sun, 2 Jan 2011 21:01:47 +0100 (CET) Message-ID: <4D20D9B1.3060700@net.in.tum.de> Date: Sun, 02 Jan 2011 21:01:53 +0100 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ladislav Lhotka References: <1292254737.8763.57.camel@behold> <4D0DE31F.1080308@net.in.tum.de> <1292854302.15113.23.camel@behold> In-Reply-To: <1292854302.15113.23.camel@behold> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060501020102000209020009" Cc: YANG Doctors , ipfix@ietf.org Subject: Re: [IPFIX] review of YANG module ietf-ipfix-psamp@2010-10-25 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 19:59:44 -0000 This is a cryptographically signed message in MIME format. --------------ms060501020102000209020009 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lada, >>> My main concern is the size of the module. I believe that splitting t= he >>> data model into smaller coherent modules makes it more understandable= >>> and manageable - also in terms of the standardisation process. It >>> seems that the present module could relatively easily be divided into= >>> two modules, one describing the collector subsystem and the other >>> dealing with the remaining functionality. As a matter of fact, flow >>> collectors are in most cases implemented in a separate device, so >>> their configuration won't be mixed with configurations of the other >>> parts. This change would also remove one level of containment in the >>> schema, at a very reasonable price of adding one more namespace. >> >> With the upcoming IPFIX mediators, we will have devices implementing=20 >> Collecting Processes, Intermediate Processes, and Exporting Processes.= >> Therefore, I think that keeping the configuration data of all IPFIX=20 >> processes in one module makes sense. >=20 > All functions could be combined anyway, even if they are defined in > different modules, by advertising all modules that apply in the hello > message rather than having just one module and using various > combinations of features. By way of analogy, entire router configuratio= n > could also be specified in one module and various routing protocols > selected by means of features - I just don't think this is the right > approach. There are groupings which are used in Exporter and Collector configurations (e.g. TransportSession, TransportLayerSecurity). Furthermore, the output of a Collecting Processes can be directed to an Exporting Processes, using leafrefs. As far as I understand, leafref cannot point to another module which is not imported. Ersue and Bernd argued that the list of Selectors is very long. Hence, instead of splitting the entire module, I would rather create a submodule for the different Selectors. What do you think about this? Gerhard --------------ms060501020102000209020009 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO5jCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBUowggQyoAMCAQICEF0kYdlVNx5E1qcmxun5IrswDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0xMDAxMDIwMDAwMDBaFw0xMTAxMDIyMzU5NTlaMIIBEzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRYw FAYDVQQDFA1HZXJoYXJkIE11ZW56MSIwIAYJKoZIhvcNAQkBFhNtdWVuekBuZXQuaW4udHVt LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl/YDW9cnAXJjesGhwtGwj9JN IHWXQ7QA18s+wGZNsQY0k4eKBeLTk/RAiC1hP+uQAXLoGQHQF/ljjQCQeRmnsN6w04iAzKVo Ru+NP7Y6ipn8uztx+z0Y3w43CO+LWUudp3PIF3+Fm2zwsAFXj/IYy/8Kq6m9+nQgYO/D4HoN DDR3//GepXghK0x93gR0GCkm8pgKINHNBD47/IZbDe/cIpAC9HaoxCeLiB1QaCDIYPIrJ0Vx kk0crAA0tPaMDjdSQTmNRAn2P+7Wg7K+DLvauBHfxLs8PrsolI+XdwiBu6henK9nPxvtoHmm mfxcdslKLbS9Xz2rHxi6PVVgv1ubWwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0w OzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBPU7OeWNo2LRzsdu/RuuAk L5cj/RzeZ0xv9q4K/eosy9dRu45XACpPvb0fjc3u/dsY4m3jDqzUsB02IrrnF9jpEo10BJPw b/RZ7NaU7jC/gEknL3bSXiD2PVwL4ZI5ChH5+TJUboWhVh+FpOwOfP/yKk7wQM/46iXXzRIz enk0rcJp71k4aQgQTML3/8MDeD6TUipuQwQMY9n6T6DsNd/6JpGa+x9ZX4HIEG6+EWwQ85G5 vGfDBaq3dFrksHE75u7b7pf75wm9HIFU2SDHP2tymTHJt/XM9sqP1URIC57s+uZV0/d5KRc1 uPcJ0FAnAiC9o7ybPIh27shiq0FvOEwfMIIFSjCCBDKgAwIBAgIQXSRh2VU3HkTWpybG6fki uzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMB4XDTEwMDEwMjAwMDAwMFoXDTExMDEwMjIzNTk1 OVowggETMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNl cnZpY2UxFjAUBgNVBAMUDUdlcmhhcmQgTXVlbnoxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCX9gNb1ycBcmN6 waHC0bCP0k0gdZdDtADXyz7AZk2xBjSTh4oF4tOT9ECILWE/65ABcugZAdAX+WONAJB5Gaew 3rDTiIDMpWhG740/tjqKmfy7O3H7PRjfDjcI74tZS52nc8gXf4WbbPCwAVeP8hjL/wqrqb36 dCBg78Pgeg0MNHf/8Z6leCErTH3eBHQYKSbymAog0c0EPjv8hlsN79wikAL0dqjEJ4uIHVBo IMhg8isnRXGSTRysADS09owON1JBOY1ECfY/7taDsr4Mu9q4Ed/Euzw+uyiUj5d3CIG7qF6c r2c/G+2geaaZ/Fx2yUottL1fPasfGLo9VWC/W5tbAgMBAAGjgcwwgckwCQYDVR0TBAIwADBE BgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAE9Ts55Y2jYt HOx279G64CQvlyP9HN5nTG/2rgr96izL11G7jlcAKk+9vR+Nze792xjibeMOrNSwHTYiuucX 2OkSjXQEk/Bv9Fns1pTuML+ASScvdtJeIPY9XAvhkjkKEfn5MlRuhaFWH4Wk7A58//IqTvBA z/jqJdfNEjN6eTStwmnvWThpCBBMwvf/wwN4PpNSKm5DBAxj2fpPoOw13/omkZr7H1lfgcgQ br4RbBDzkbm8Z8MFqrd0WuSwcTvm7tvul/vnCb0cgVTZIMc/a3KZMcm39cz2yo/VREgLnuz6 5lXT93kpFzW49wnQUCcCIL2jvJs8iHbuyGKrQW84TB8xggTsMIIE6AIBATCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcy AhBdJGHZVTceRNanJsbp+SK7MAkGBSsOAwIaBQCgggLOMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEwMjIwMDE1M1owIwYJKoZIhvcNAQkEMRYEFAMX hk+jGoIhQVlG4iY4S/r28YOZMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQBl9QP8jf2otdn/k27UbEUHZWI3aFzgT9VKYv1KicKUuHa6fMqdtqRX rtYdvDzXjaFvuRFvhivv1KQm5KMp6bYnnYYOC4p2yCX5JtMoGtQb/skkMuEbhgGSHgeRFoYl EuTcQ6N588RtaN2FpBoNngA2q+OwLIzpx32Uc4eg3lbDCNNvtkIm/QU+aq8C6ktKWNGRMr9P tLxrety05Ucq7Hc3JfyaWd1UUF+LtTwQd/E7jc1RsJWKdcUJKDs6BY6YbpwPs2UPhrdeFK9v 0ZR1lUMIwujuHXT1IGsfkzIZePLdPN1JvLNPhlw3/1EdOu1sUFTFegY3JDhOOAIWgqc67HZX AAAAAAAA --------------ms060501020102000209020009-- From trammell@tik.ee.ethz.ch Wed Jan 5 00:39:43 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EFDE3A6B5F for ; Wed, 5 Jan 2011 00:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlE8i2Mt9DhU for ; Wed, 5 Jan 2011 00:39:42 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id D9F503A6C28 for ; Wed, 5 Jan 2011 00:39:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 06585D9367; Wed, 5 Jan 2011 09:41:48 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YoWGR+QlEi9H; Wed, 5 Jan 2011 09:41:47 +0100 (MET) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 726DAD9353; Wed, 5 Jan 2011 09:41:47 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Jan 2011 09:41:47 +0100 Message-Id: <7B1C5859-0781-44E8-A8EA-E932C38665CE@tik.ee.ethz.ch> To: ipfix@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: joelja@bogus.com Subject: [IPFIX] recordings of Beijing IPFIX meeting X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 08:39:43 -0000 Greetings, all, Does anyone have audio from the IETF79 IPFIX meeting? The files seem to = be missing from the archives at http://79archive.dyndns.org/ietf79/ -- = IPFIX was channel 4 on Wednesday morning, but Channel 4 doesn't seem to = be available on Wednesday at all. Best regards, Brian= From bclaise@cisco.com Thu Jan 6 05:14:14 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D107D3A6DDC; Thu, 6 Jan 2011 05:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAwHA0CmOk00; Thu, 6 Jan 2011 05:14:13 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 8A6623A6CAA; Thu, 6 Jan 2011 05:14:13 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p06DCYbI010864; Thu, 6 Jan 2011 14:12:34 +0100 (CET) Received: from [10.55.43.54] (ams-bclaise-8715.cisco.com [10.55.43.54]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p06DCX2T012559; Thu, 6 Jan 2011 14:12:33 +0100 (CET) Message-ID: <4D25BFC1.9080907@cisco.com> Date: Thu, 06 Jan 2011 14:12:33 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ladislav Lhotka References: <1292254737.8763.57.camel@behold> <4D0DE31F.1080308@net.in.tum.de> <1292854302.15113.23.camel@behold> In-Reply-To: <1292854302.15113.23.camel@behold> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: YANG Doctors , ipfix@ietf.org Subject: Re: [IPFIX] review of YANG module ietf-ipfix-psamp@2010-10-25 - ieEnterpriseNumber X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 13:14:14 -0000 Dear all, OLD: "If omitted or zero, the Information Element is registered in the IANA registry of IPFIX Information Elements." NEW: "If omitted, the Information Element is registered in the IANA registry of IPFIX Information Elements." What is the problem with the simple solution? Regards, Benoit. >>> - The description of "ieEnterpriseNumber" leafs says: "If omitted or >>> zero, the Information Element is registered in the IANA registry of >>> IPFIX Information Elements." Why not define a default value of "0" >>> here (perhaps in a special typedef)? >> I'm not sure whether 0 is a valid enterprise number. >> >> >> In http://www.iana.org/assignments/enterprise-numbers , we have: >> >> Decimal >> | Organization >> | | Contact >> | | | Email >> | | | | >> 0 >> Reserved >> Internet Assigned Numbers Authority >> iana&iana.org >> >> Does this mean that 0 can be used to refer to IANA? >> If yes, we could use 0 as a default value. Otherwise, I would rather >> remove "or zero" and create a type that does not allow zero values. > I don't know but the text as it is now sounds exactly like zero is the > default value for this leaf. > > Lada > From trammell@tik.ee.ethz.ch Thu Jan 6 05:25:30 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C693A6F0E; Thu, 6 Jan 2011 05:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k-K1wU+mLgp; Thu, 6 Jan 2011 05:25:29 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 778113A6E28; Thu, 6 Jan 2011 05:25:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C70D4D932E; Thu, 6 Jan 2011 14:27:35 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kcgxCPKOaUzO; Thu, 6 Jan 2011 14:27:35 +0100 (MET) Received: from mac-10243.ethz.ch (mac-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 67DB0D931D; Thu, 6 Jan 2011 14:27:35 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4D25BFC1.9080907@cisco.com> Date: Thu, 6 Jan 2011 14:27:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2675B60B-ED88-4D49-BD5C-3CEB6B789178@tik.ee.ethz.ch> References: <1292254737.8763.57.camel@behold> <4D0DE31F.1080308@net.in.tum.de> <1292854302.15113.23.camel@behold> <4D25BFC1.9080907@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1082) Cc: YANG Doctors , Ladislav Lhotka , ipfix@ietf.org Subject: Re: [IPFIX] review of YANG module ietf-ipfix-psamp@2010-10-25 - ieEnterpriseNumber X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 13:25:30 -0000 Hi, Benoit, all, PEN zero is taken to be a default value meaning "in the IANA registry" = in RFC 5610, section 3.8, and in the definition of IE 346 = privateEnterpriseNumber at = http://www.iana.org/assignments/ipfix/ipfix.xhtml. "Or 0" should be = retained to remained consistent. Best regards, Brian On Jan 6, 2011, at 2:12 PM, Benoit Claise wrote: > Dear all, >=20 > OLD: > "If omitted or zero, the Information Element is registered in the IANA = registry of > IPFIX Information Elements." >=20 > NEW: > "If omitted, the Information Element is registered in the IANA = registry of > IPFIX Information Elements." >=20 > What is the problem with the simple solution? >=20 > Regards, Benoit. >>>> - The description of "ieEnterpriseNumber" leafs says: "If omitted = or >>>> zero, the Information Element is registered in the IANA registry = of >>>> IPFIX Information Elements." Why not define a default value of = "0" >>>> here (perhaps in a special typedef)? >>> I'm not sure whether 0 is a valid enterprise number. >>>=20 >>>=20 >>> In http://www.iana.org/assignments/enterprise-numbers , we have: >>>=20 >>> Decimal >>> | Organization >>> | | Contact >>> | | | Email >>> | | | | >>> 0 >>> Reserved >>> Internet Assigned Numbers Authority >>> iana&iana.org >>>=20 >>> Does this mean that 0 can be used to refer to IANA? >>> If yes, we could use 0 as a default value. Otherwise, I would rather >>> remove "or zero" and create a type that does not allow zero values. >> I don't know but the text as it is now sounds exactly like zero is = the >> default value for this leaf. >>=20 >> Lada >>=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Thu Jan 6 05:51:14 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8AF3A6F0F; Thu, 6 Jan 2011 05:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id el9DGLUzPjyb; Thu, 6 Jan 2011 05:51:13 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 319D03A6E28; Thu, 6 Jan 2011 05:51:13 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p06Djn6i013700; Thu, 6 Jan 2011 14:45:49 +0100 (CET) Received: from [10.55.43.54] (ams-bclaise-8715.cisco.com [10.55.43.54]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p06Djm0W023568; Thu, 6 Jan 2011 14:45:49 +0100 (CET) Message-ID: <4D25C78C.70402@cisco.com> Date: Thu, 06 Jan 2011 14:45:48 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian Trammell References: <1292254737.8763.57.camel@behold> <4D0DE31F.1080308@net.in.tum.de> <1292854302.15113.23.camel@behold> <4D25BFC1.9080907@cisco.com> <2675B60B-ED88-4D49-BD5C-3CEB6B789178@tik.ee.ethz.ch> In-Reply-To: <2675B60B-ED88-4D49-BD5C-3CEB6B789178@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: YANG Doctors , Ladislav Lhotka , ipfix@ietf.org Subject: Re: [IPFIX] review of YANG module ietf-ipfix-psamp@2010-10-25 - ieEnterpriseNumber X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 13:51:14 -0000 Hi Brian, Thanks for the clarification. So as Lada mentioned, 0 should be the default value. Regards, Benoit. > Hi, Benoit, all, > > PEN zero is taken to be a default value meaning "in the IANA registry" in RFC 5610, section 3.8, and in the definition of IE 346 privateEnterpriseNumber at http://www.iana.org/assignments/ipfix/ipfix.xhtml. "Or 0" should be retained to remained consistent. > > Best regards, > > Brian > > > On Jan 6, 2011, at 2:12 PM, Benoit Claise wrote: > >> Dear all, >> >> OLD: >> "If omitted or zero, the Information Element is registered in the IANA registry of >> IPFIX Information Elements." >> >> NEW: >> "If omitted, the Information Element is registered in the IANA registry of >> IPFIX Information Elements." >> >> What is the problem with the simple solution? >> >> Regards, Benoit. >>>>> - The description of "ieEnterpriseNumber" leafs says: "If omitted or >>>>> zero, the Information Element is registered in the IANA registry of >>>>> IPFIX Information Elements." Why not define a default value of "0" >>>>> here (perhaps in a special typedef)? >>>> I'm not sure whether 0 is a valid enterprise number. >>>> >>>> >>>> In http://www.iana.org/assignments/enterprise-numbers , we have: >>>> >>>> Decimal >>>> | Organization >>>> | | Contact >>>> | | | Email >>>> | | | | >>>> 0 >>>> Reserved >>>> Internet Assigned Numbers Authority >>>> iana&iana.org >>>> >>>> Does this mean that 0 can be used to refer to IANA? >>>> If yes, we could use 0 as a default value. Otherwise, I would rather >>>> remove "or zero" and create a type that does not allow zero values. >>> I don't know but the text as it is now sounds exactly like zero is the >>> default value for this leaf. >>> >>> Lada >>> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Thu Jan 6 08:23:11 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC8BE3A6D79; Thu, 6 Jan 2011 08:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.054 X-Spam-Level: X-Spam-Status: No, score=-10.054 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfm+ibEqq4MO; Thu, 6 Jan 2011 08:23:10 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 910D53A6C4F; Thu, 6 Jan 2011 08:23:10 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 06 Jan 2011 16:25:17 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p06GPGbS000913; Thu, 6 Jan 2011 16:25:16 GMT Received: from [10.55.91.72] (dhcp-10-55-91-72.cisco.com [10.55.91.72]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p06GPD829695; Thu, 6 Jan 2011 16:25:14 GMT Message-ID: <4D25ECE9.6010102@cisco.com> Date: Thu, 06 Jan 2011 16:25:13 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Benoit Claise References: <1292254737.8763.57.camel@behold> <4D0DE31F.1080308@net.in.tum.de> <1292854302.15113.23.camel@behold> <4D25BFC1.9080907@cisco.com> In-Reply-To: <4D25BFC1.9080907@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: YANG Doctors , Ladislav Lhotka , ipfix@ietf.org Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: review of YANG module ietf-ipfix-psamp@2010-10-25 - ieEnterpriseNumber X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:23:11 -0000 Benoit, I agree with Brian: the value zero should be retained. For two reasons: 1. This isn't actually an IANA EnterpriseNumber. It's actually an IPFIX ieEnterpriseNumber which builds on the IANA EnterpriseNumber by adding the extra definition for 0. 2. There should be a way to export "in the IANA registry" without requiring a new template - which would be necessary if the ieEnterpriseNumber must be omitted. Cheers, P. > Dear all, > > OLD: > "If omitted or zero, the Information Element is registered in the IANA > registry of > IPFIX Information Elements." > > NEW: > "If omitted, the Information Element is registered in the IANA registry of > IPFIX Information Elements." > > What is the problem with the simple solution? > > Regards, Benoit. >>>> - The description of "ieEnterpriseNumber" leafs says: "If omitted or >>>> zero, the Information Element is registered in the IANA registry of >>>> IPFIX Information Elements." Why not define a default value of "0" >>>> here (perhaps in a special typedef)? >>> I'm not sure whether 0 is a valid enterprise number. >>> >>> >>> In http://www.iana.org/assignments/enterprise-numbers , we have: >>> >>> Decimal >>> | Organization >>> | | Contact >>> | | | Email >>> | | | | >>> 0 >>> Reserved >>> Internet Assigned Numbers Authority >>> iana&iana.org >>> >>> Does this mean that 0 can be used to refer to IANA? >>> If yes, we could use 0 as a default value. Otherwise, I would rather >>> remove "or zero" and create a type that does not allow zero values. >> I don't know but the text as it is now sounds exactly like zero is the >> default value for this leaf. >> >> Lada >> > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Thu Jan 6 08:25:48 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C3213A6E39; Thu, 6 Jan 2011 08:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN+wgwBhvFO5; Thu, 6 Jan 2011 08:25:47 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id BC4533A6E35; Thu, 6 Jan 2011 08:25:46 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p06GRq3G026192; Thu, 6 Jan 2011 17:27:52 +0100 (CET) Received: from [10.55.43.54] (ams-bclaise-8715.cisco.com [10.55.43.54]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p06GRm1G014585; Thu, 6 Jan 2011 17:27:48 +0100 (CET) Message-ID: <4D25ED84.3020000@cisco.com> Date: Thu, 06 Jan 2011 17:27:48 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Paul Aitken References: <1292254737.8763.57.camel@behold> <4D0DE31F.1080308@net.in.tum.de> <1292854302.15113.23.camel@behold> <4D25BFC1.9080907@cisco.com> <4D25ECE9.6010102@cisco.com> In-Reply-To: <4D25ECE9.6010102@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: YANG Doctors , Ladislav Lhotka , ipfix@ietf.org Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: review of YANG module ietf-ipfix-psamp@2010-10-25 - ieEnterpriseNumber X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:25:48 -0000 Paul, > Benoit, > > I agree with Brian: the value zero should be retained. > > For two reasons: > > 1. This isn't actually an IANA EnterpriseNumber. It's actually an > IPFIX ieEnterpriseNumber which builds on the IANA EnterpriseNumber by > adding the extra definition for 0. > > 2. There should be a way to export "in the IANA registry" without > requiring a new template - which would be necessary if the > ieEnterpriseNumber must be omitted. I'm convinced now Regards, Benoit > > Cheers, > P. > > > >> Dear all, >> >> OLD: >> "If omitted or zero, the Information Element is registered in the IANA >> registry of >> IPFIX Information Elements." >> >> NEW: >> "If omitted, the Information Element is registered in the IANA >> registry of >> IPFIX Information Elements." >> >> What is the problem with the simple solution? >> >> Regards, Benoit. >>>>> - The description of "ieEnterpriseNumber" leafs says: "If omitted or >>>>> zero, the Information Element is registered in the IANA registry of >>>>> IPFIX Information Elements." Why not define a default value of "0" >>>>> here (perhaps in a special typedef)? >>>> I'm not sure whether 0 is a valid enterprise number. >>>> >>>> >>>> In http://www.iana.org/assignments/enterprise-numbers , we have: >>>> >>>> Decimal >>>> | Organization >>>> | | Contact >>>> | | | Email >>>> | | | | >>>> 0 >>>> Reserved >>>> Internet Assigned Numbers Authority >>>> iana&iana.org >>>> >>>> Does this mean that 0 can be used to refer to IANA? >>>> If yes, we could use 0 as a default value. Otherwise, I would rather >>>> remove "or zero" and create a type that does not allow zero values. >>> I don't know but the text as it is now sounds exactly like zero is the >>> default value for this leaf. >>> >>> Lada >>> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From n.brownlee@auckland.ac.nz Thu Jan 6 13:30:16 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B9B53A6F2D for ; Thu, 6 Jan 2011 13:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.343 X-Spam-Level: X-Spam-Status: No, score=-106.343 tagged_above=-999 required=5 tests=[AWL=2.256, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0QVNsZfX1oy for ; Thu, 6 Jan 2011 13:30:12 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 41D843A6F19 for ; Thu, 6 Jan 2011 13:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1294349532; x=1325885532; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4D2634CC.6050607@auckland.ac.nz>|Date:=20 Fri,=2007=20Jan=202011=2010:31:56=20+1300|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20lorenzo.peluso@unina.it|CC:=20"draft-ietf-ip fix-flow-selection-tech@tools.ietf.org"=20,=0D=0A=20IPFIX=20W orking=20Group=20|Subject:=20Re:=20[IPFIX ]=20Shepherd=20review=20of=20=20draft-ietf-ipfix-flow-sel ection-tech|References:=20<4D06B0C7.4070901@auckland.ac.n z>|In-Reply-To:=20<4D06B0C7.4070901@auckland.ac.nz> |Content-Transfer-Encoding:=207bit; bh=n/ya7xDAfN9IKtnOH47GIn0KLgG9PlY9kl+aCjdXEwQ=; b=F7+K6zcVRnEoOW78JRQ5Lix9xZq1z3gJ8VSTDVLB6w23pRMjgMpquAHw 8m5QEQtYmUCbNMXzasJBuQNPcDQ/U4bTKBP8I2mIGuU/D8Ghe6IbZH+I5 wAz5A1dYTT+XXKPm9kY0PpUYMdlSTaQ5MhkaE1CDWgWrjWMx15aHD7+n/ 0=; X-IronPort-AV: E=Sophos;i="4.60,285,1291546800"; d="scan'208";a="41467088" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 07 Jan 2011 10:32:01 +1300 Message-ID: <4D2634CC.6050607@auckland.ac.nz> Date: Fri, 07 Jan 2011 10:31:56 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: lorenzo.peluso@unina.it References: <4D06B0C7.4070901@auckland.ac.nz> In-Reply-To: <4D06B0C7.4070901@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group , "draft-ietf-ipfix-flow-selection-tech@tools.ietf.org" Subject: Re: [IPFIX] Shepherd review of draft-ietf-ipfix-flow-selection-tech X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 21:30:16 -0000 Hi Lorenzo: I haven't seen any response to my earlier emails (copied below). Did you receive them? Can you please make the changes I've detailed and publish a new revision sometime soon? I'd like to get the shepherd document completed so that I can submit this draft to IESG well before the Prague IETF meeting! Cheers, Nevil On 14/12/10 12:48 PM, Nevil Brownlee wrote: > > Hi Lorenzo et al: > > As part of writing a shepherd document I have to read your draft > carefully, and check it for ID-nits. I've done that, and I find > quite a few things that need to be fixed, as follows: > > s7, p15: List of new IEs > 5102 clearly says that IE names start with a lower-case letter. > Also, none of the existing IEs use an underscore character. > How about using fsMeterUnmeasPacketCount, as per 5102? > > s7, p14 > You say "Some elements have > been associated with a pair of timestamps, which are referred to as > Tfirst and Tlast (instead of element_nameTfirst, element_nameTlast). > Does that mean that you both the TFirst and Tlast timestamps are > also needed as IEs? Or are they something that will only be used > inside a meter or mediator? You need to explain this here! > > s7.1.1, p15 > Refers to TsFirst and TsLast - you should change Tfirst and Tlast > above (I think TsFirst is easier to read). > > s7.2.2 Why is ..PacketInDropped.. defined in terms of its two timestamps, > but ..ByteInDropped.. is not? > Similarly for other IEs in 7.2.x sections. > > s9, p22: remove [RFC 2051] (as above) > > s9.1, p22: In the table, don't use ID, that suggests its an ID for an > Informations Element. I think you mean Value. > > Running ID-nits, using the [Nits] button at the top of > http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-03 > > You should run this, and fix the little things it finds. > > In particular, I see that there's no Security Considerations section. > Every RFC has to have such a section! You need to add one, pointing > out what possible security weaknesses could be introduced by using > flow selection (or explaining that there aren't any obvious ones). > > Most of these are quite trivial, so they won't take much fixing. > The ones that do need some real work are to explain how TsFirst/ > TsFirst are intended to be used in the FlowSelect Info Model, and > to add a Security Considerations section. > > I look forward to seeing your next version. > > Cheers, Nevil > Lorenzo et al: > > One more thing, when your next revision is ready, I need to be able > to list two or three people as reviewers for it - perhaps you could > ask them directly and ask them to post their reviews on the IPFIX > list? > > Cheers again, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From lorenzo.peluso@unina.it Fri Jan 7 06:18:48 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5EE3A68D4 for ; Fri, 7 Jan 2011 06:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.323 X-Spam-Level: X-Spam-Status: No, score=-1.323 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoiPYg95PbM6 for ; Fri, 7 Jan 2011 06:18:47 -0800 (PST) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 209FB3A68BE for ; Fri, 7 Jan 2011 06:18:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id p07EKfvw008671; Fri, 7 Jan 2011 15:20:41 +0100 Received: from 94.160.88.150 ([94.160.88.150]) by webmail.unina.it (Horde MIME library) with HTTP; Fri, 07 Jan 2011 15:20:41 +0100 Message-ID: <20110107152041.6v5uzbhga8o84kcc@webmail.unina.it> Date: Fri, 07 Jan 2011 15:20:41 +0100 From: lorenzo.peluso@unina.it To: Nevil Brownlee References: <4D06B0C7.4070901@auckland.ac.nz> <4D2634CC.6050607@auckland.ac.nz> In-Reply-To: <4D2634CC.6050607@auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) Cc: IPFIX Working Group , "draft-ietf-ipfix-flow-selection-tech@tools.ietf.org" Subject: Re: [IPFIX] Shepherd review of draft-ietf-ipfix-flow-selection-tech X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 14:18:48 -0000 Hi Nevil, sorry for the very late answer. We are actively working on a new =20 revision of the draft. We are going to publish the new revision =20 tomorrow. Cheers, Lorenzo. Quoting Nevil Brownlee : > > Hi Lorenzo: > > I haven't seen any response to my earlier emails (copied below). > Did you receive them? Can you please make the changes I've detailed > and publish a new revision sometime soon? I'd like to get the > shepherd document completed so that I can submit this draft to > IESG well before the Prague IETF meeting! > > Cheers, Nevil > > > On 14/12/10 12:48 PM, Nevil Brownlee wrote: >> >> Hi Lorenzo et al: >> >> As part of writing a shepherd document I have to read your draft >> carefully, and check it for ID-nits. I've done that, and I find >> quite a few things that need to be fixed, as follows: >> >> s7, p15: List of new IEs >> 5102 clearly says that IE names start with a lower-case letter. >> Also, none of the existing IEs use an underscore character. >> How about using fsMeterUnmeasPacketCount, as per 5102? >> >> s7, p14 >> You say "Some elements have >> been associated with a pair of timestamps, which are referred to as >> Tfirst and Tlast (instead of element_nameTfirst, element_nameTlast)= . >> Does that mean that you both the TFirst and Tlast timestamps are >> also needed as IEs? Or are they something that will only be used >> inside a meter or mediator? You need to explain this here! >> >> s7.1.1, p15 >> Refers to TsFirst and TsLast - you should change Tfirst and Tlast >> above (I think TsFirst is easier to read). >> >> s7.2.2 Why is ..PacketInDropped.. defined in terms of its two timestamps= , >> but ..ByteInDropped.. is not? >> Similarly for other IEs in 7.2.x sections. >> >> s9, p22: remove [RFC 2051] (as above) >> >> s9.1, p22: In the table, don't use ID, that suggests its an ID for an >> Informations Element. I think you mean Value. >> >> Running ID-nits, using the [Nits] button at the top of >> http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-03 >> >> You should run this, and fix the little things it finds. >> >> In particular, I see that there's no Security Considerations section. >> Every RFC has to have such a section! You need to add one, pointing >> out what possible security weaknesses could be introduced by using >> flow selection (or explaining that there aren't any obvious ones). >> >> Most of these are quite trivial, so they won't take much fixing. >> The ones that do need some real work are to explain how TsFirst/ >> TsFirst are intended to be used in the FlowSelect Info Model, and >> to add a Security Considerations section. >> >> I look forward to seeing your next version. >> >> Cheers, Nevil > >> Lorenzo et al: >> >> One more thing, when your next revision is ready, I need to be able >> to list two or three people as reviewers for it - perhaps you could >> ask them directly and ask them to post their reviews on the IPFIX >> list? >> >> Cheers again, Nevil > > --=20 > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From tianhc08@mails.tsinghua.edu.cn Fri Jan 7 10:57:52 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C316E3A6921 for ; Fri, 7 Jan 2011 10:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.396 X-Spam-Level: **** X-Spam-Status: No, score=4.396 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, DEAR_SOMETHING=1.605, FR_IMPORT_CSS=1.889, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MgS8ZxToh5O for ; Fri, 7 Jan 2011 10:57:51 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 667043A67A1 for ; Fri, 7 Jan 2011 10:57:51 -0800 (PST) Received: from tu132218.ip.tsinghua.edu.cn ([166.111.132.218] helo=thc-66) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1PbHXS-0004f1-5V for ipfix@ietf.org; Sat, 08 Jan 2011 02:59:50 +0800 Date: Sat, 8 Jan 2011 02:59:55 +0800 From: "=?gb2312?B?zO+67LPJ?=" To: "ipfix" Message-ID: <201101080259555627835@mails.tsinghua.edu.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon528627411525_=====" Subject: [IPFIX] one problem on IPFIX X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 18:57:52 -0000 This is a multi-part message in MIME format. --=====003_Dragon528627411525_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Dear Sir/Madam, I am a Ph.D. student of Professor Jun Bi from Tsinghua University, Beijing, China. I am very glad to read RFCs on IPFIX , from which I have learned much. Thank for your great contribution. I would like to ask one question about IPFIX. (1)As we all know, sampling does not provide a 100% accurate result. If the flow is defined as five tuples (source address, destination address, protocol number, source port, destination port), I don't know whether there exists theoretical analysis or experiment results on the relation between packet sampling probability and the percentage that flows are sampled. I am looking forward to hearing from you. Thank you very much! best ragards ------ Hongcheng Tian Network Architecture Lab, Network Center,Tsinghua University Mobile: +86 13370195827 Add: Room 1227B, Zijing Building 15, Tsinghua University, 100084 Beijing, China Email: tianhc08@mails.tsinghua.edu.cn --=====003_Dragon528627411525_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 7bit
Dear Sir/Madam,
I am a Ph.D. student of Professor Jun Bi from Tsinghua University, Beijing, China. I am very glad to read RFCs on IPFIX , from which I have learned much. Thank for your great contribution.
I would like to ask one question about IPFIX.
 
(1)As we all know, sampling does not provide a 100% accurate result. If the flow is defined as five tuples (source address, destination address, protocol number, source port, destination port), I don't know whether there exists theoretical analysis or experiment results  on the relation between packet sampling probability and the percentage that flows are sampled.
 
I am looking forward to hearing from you. Thank you very much!
 
 
best ragards
 ------
Hongcheng Tian
Network Architecture Lab, Network Center,Tsinghua University
Mobile:   +86 13370195827
Add:       Room 1227B, Zijing Building 15, Tsinghua University, 100084 Beijing, China
Email:    tianhc08@mails.tsinghua.edu.cn
--=====003_Dragon528627411525_=====-- From yaroslav@arbor.net Fri Jan 7 13:08:21 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A0EB3A6979 for ; Fri, 7 Jan 2011 13:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[AWL=-3.999, BAYES_00=-2.599, DEAR_SOMETHING=1.605, FR_IMPORT_CSS=1.889, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orEOWaGRjEjU for ; Fri, 7 Jan 2011 13:08:20 -0800 (PST) Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by core3.amsl.com (Postfix) with ESMTP id 771DE3A6946 for ; Fri, 7 Jan 2011 13:08:19 -0800 (PST) Received: from gateout02.mbox.net (gwo2-lo [127.0.0.1]) by gateout02.mbox.net (Postfix) with ESMTP id 534C84BF697; Fri, 7 Jan 2011 21:10:24 +0000 (GMT) X-USANET-Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.71F) with ESMTP id 643PagVkV7424Mo2; Fri, 07 Jan 2011 21:10:21 -0000 Received: from s1hub2.EXCHPROD.USA.NET [165.212.120.254] by gateout02.mbox.net via smtad (C8.MAIN.3.68M) with ESMTPS id XID339PagVkV1335Xo2; Fri, 07 Jan 2011 21:10:21 -0000 X-USANET-Source: 165.212.120.254 IN yaroslav@arbor.net s1hub2.EXCHPROD.USA.NET X-USANET-MsgId: XID339PagVkV1335Xo2 Received: from MBX14.EXCHPROD.USA.NET ([10.120.221.141]) by s1hub2.EXCHPROD.USA.NET ([10.120.220.32]) with mapi; Fri, 7 Jan 2011 21:10:11 +0000 From: "Rosomakho, Yaroslav" To: =?gb2312?B?zO+67LPJ?= Date: Fri, 7 Jan 2011 21:10:08 +0000 Thread-Topic: [IPFIX] one problem on IPFIX Thread-Index: Acuur0TqGiEt0OrpR0624CqENQsl9g== Message-ID: In-Reply-To: <201101080259555627835@mails.tsinghua.edu.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C94D5AD54C09yaroslavarbornet_" MIME-Version: 1.0 Cc: ipfix Subject: Re: [IPFIX] one problem on IPFIX X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:08:21 -0000 --_000_C94D5AD54C09yaroslavarbornet_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8sIFRpYW4hDQoNCldoaWxlIHNhbXBsaW5nIGFjY3VyYWN5IGRlcGVuZHMgb24gdHJhZmZp YyBwYXR0ZXJuIGFuZCBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzLCB5b3UgY291bGQgbG9vayBpbnRv IG1hdGVyaWFscyBwcm92aWRlZCBhdCBodHRwOi8vc2Zsb3cub3JnL2Fib3V0L3NhbXBsaW5nX3Ro ZW9yeS5waHAgYXMgYSBzdGFydGluZyBwb2ludCBmb3IgeW91ciBzdHVkeS4NCg0KDQpCZXN0IFJl Z2FyZHMsDQpZYXJvc2xhdg0KDQoNCg0KRnJvbTogzO+67LPJIDx0aWFuaGMwOEBtYWlscy50c2lu Z2h1YS5lZHUuY248bWFpbHRvOnRpYW5oYzA4QG1haWxzLnRzaW5naHVhLmVkdS5jbj4+DQpEYXRl OiBGcmksIDcgSmFuIDIwMTEgMTg6NTk6NTUgKzAwMDANClRvOiBpcGZpeCA8aXBmaXhAaWV0Zi5v cmc8bWFpbHRvOmlwZml4QGlldGYub3JnPj4NClN1YmplY3Q6IFtJUEZJWF0gb25lIHByb2JsZW0g b24gSVBGSVgNCg0KRGVhciBTaXIvTWFkYW0sDQpJIGFtIGEgUGguRC4gc3R1ZGVudCBvZiBQcm9m ZXNzb3IgSnVuIEJpIGZyb20gVHNpbmdodWEgVW5pdmVyc2l0eSwgQmVpamluZywgQ2hpbmEuIEkg YW0gdmVyeSBnbGFkIHRvIHJlYWQgUkZDcyBvbiBJUEZJWCAsIGZyb20gd2hpY2ggSSBoYXZlIGxl YXJuZWQgbXVjaC4gVGhhbmsgZm9yIHlvdXIgZ3JlYXQgY29udHJpYnV0aW9uLg0KSSB3b3VsZCBs aWtlIHRvIGFzayBvbmUgcXVlc3Rpb24gYWJvdXQgSVBGSVguDQoNCigxKUFzIHdlIGFsbCBrbm93 LCBzYW1wbGluZyBkb2VzIG5vdCBwcm92aWRlIGEgMTAwJSBhY2N1cmF0ZSByZXN1bHQuIElmIHRo ZSBmbG93IGlzIGRlZmluZWQgYXMgZml2ZSB0dXBsZXMgKHNvdXJjZSBhZGRyZXNzLCBkZXN0aW5h dGlvbiBhZGRyZXNzLCBwcm90b2NvbCBudW1iZXIsIHNvdXJjZSBwb3J0LCBkZXN0aW5hdGlvbiBw b3J0KSwgSSBkb24ndCBrbm93IHdoZXRoZXIgdGhlcmUgZXhpc3RzIHRoZW9yZXRpY2FsIGFuYWx5 c2lzIG9yIGV4cGVyaW1lbnQgcmVzdWx0cyAgb24gdGhlIHJlbGF0aW9uIGJldHdlZW4gcGFja2V0 IHNhbXBsaW5nIHByb2JhYmlsaXR5IGFuZCB0aGUgcGVyY2VudGFnZSB0aGF0IGZsb3dzIGFyZSBz YW1wbGVkLg0KDQpJIGFtIGxvb2tpbmcgZm9yd2FyZCB0byBoZWFyaW5nIGZyb20geW91LiBUaGFu ayB5b3UgdmVyeSBtdWNoIQ0KDQoNCmJlc3QgcmFnYXJkcw0KIC0tLS0tLQ0KSG9uZ2NoZW5nIFRp YW4NCk5ldHdvcmsgQXJjaGl0ZWN0dXJlIExhYiwgTmV0d29yayBDZW50ZXIsVHNpbmdodWEgVW5p dmVyc2l0eQ0KTW9iaWxlOiAgICs4NiAxMzM3MDE5NTgyNw0KQWRkOiAgICAgICBSb29tIDEyMjdC LCBaaWppbmcgQnVpbGRpbmcgMTUsIFRzaW5naHVhIFVuaXZlcnNpdHksIDEwMDA4NCBCZWlqaW5n LCBDaGluYQ0KRW1haWw6ICAgIHRpYW5oYzA4QG1haWxzLnRzaW5naHVhLmVkdS5jbjxtYWlsdG86 dGlhbmhjMDhAbWFpbHMudHNpbmdodWEuZWR1LmNuPg0K --_000_C94D5AD54C09yaroslavarbornet_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hello, Tian!
<= br>
While sampling accuracy depends on traffic pattern and implem= entation details, you could look into materials provided at http://sflow.org/about/samplin= g_theory.php as a starting point for your study.


Best Regards,
Yaroslav



From: = =CC=EF=BA=EC=B3=C9 <tianhc08@mails.tsinghua.edu.cn>
Date: Fri, 7 Jan 2011 18:59:55 +0000
To: ipfix <ipfix@i= etf.org>
Subject: [IPFIX= ] one problem on IPFIX

Dear Sir/Madam,
I am a P= h.D. student of Professor Jun Bi from Tsinghua=20 University, Beijing, China. I am very glad to read RFCs on IPFIX = ,=20 from which I have learned much. Thank for your great contribution.
I wou= ld=20 like to ask one question about IPFIX.
 
(1)As we all know, sampling=20 does not provide a 100% accurate result. If the fl= ow is=20 defined as five tuples (source address, destination address, protocol numbe= r,=20 source port, destination port), I don't know whether there=20 exists theoretical analysis or experiment results  on the relatio= n=20 between packet sampling probability and the percentage that flows = ;are=20 sampled.
 
<= font face=3D"Verdana">
I am looking forward to hearing from you. Thank you very=20 much!
 
 
best ragards
 ------
Hongcheng=20 Tian
Network Architecture Lab, Network Center,Tsinghua University
Mob= ile:=20   +86 13370195827
Add:       Room 1227B, Zijing Buil= ding=20 15, Tsinghua University, 100084 Beijing, China
Email:    tianhc08@mails.tsinghua.edu.cn=
=
--_000_C94D5AD54C09yaroslavarbornet_-- From dromasca@avaya.com Sun Jan 9 03:24:43 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458703A696E for ; Sun, 9 Jan 2011 03:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y47liD3JpbUz for ; Sun, 9 Jan 2011 03:24:29 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 1A6CA3A6969 for ; Sun, 9 Jan 2011 03:24:28 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ8pKU3GmAcF/2dsb2JhbACkRnOldAKUcYVMBI5E X-IronPort-AV: E=Sophos;i="4.60,295,1291611600"; d="scan'208";a="53504061" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 09 Jan 2011 06:26:39 -0500 X-IronPort-AV: E=Sophos;i="4.60,295,1291611600"; d="scan'208";a="568215961" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Jan 2011 06:26:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 9 Jan 2011 12:26:36 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipfix-anon-05 Thread-Index: Acuv8BN/docu2bbuTLuaWtjcwqnynw== From: "Romascanu, Dan (Dan)" To: , "Brian Trammell" Cc: IPFIX Working Group Subject: [IPFIX] draft-ietf-ipfix-anon-05 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 11:24:43 -0000 draft-ietf-ipfix-anon-05 was discussed in the IESG telechat on 1/6. The IESG resolution was that a new revision of the I-D is needed to solve the issues raised by the DISCUSSes of Stewart Bryant and Sean Turner. As document editors, please work with the Area Directors to address their issues and submit a new I-D when you reach agreements on the necessary changes.=20 Thanks and Regards, Dan From lhotka@cesnet.cz Mon Jan 10 02:56:06 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9FA728C143; Mon, 10 Jan 2011 02:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQ2zbuHZvzyO; Mon, 10 Jan 2011 02:56:06 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id A6C0628C137; Mon, 10 Jan 2011 02:56:05 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e] (unknown [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e]) by office2.cesnet.cz (Postfix) with ESMTPSA id 9C73F2CDE057; Mon, 10 Jan 2011 11:58:16 +0100 (CET) From: Ladislav Lhotka To: Gerhard Muenz In-Reply-To: <4D20D9B1.3060700@net.in.tum.de> References: <1292254737.8763.57.camel@behold> <4D0DE31F.1080308@net.in.tum.de> <1292854302.15113.23.camel@behold> <4D20D9B1.3060700@net.in.tum.de> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 10 Jan 2011 11:58:15 +0100 Message-ID: <1294657095.2033.32.camel@behold> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 10 Jan 2011 03:22:59 -0800 Cc: YANG Doctors , ipfix@ietf.org Subject: Re: [IPFIX] review of YANG module ietf-ipfix-psamp@2010-10-25 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 10:56:07 -0000 Hi Gerhard, On Ne, 2011-01-02 at 21:01 +0100, Gerhard Muenz wrote: > There are groupings which are used in Exporter and Collector > configurations (e.g. TransportSession, TransportLayerSecurity). Such groupings could be put to a separate module and imported where necessary, right? > > Furthermore, the output of a Collecting Processes can be directed to > an > Exporting Processes, using leafrefs. As far as I understand, leafref > cannot point to another module which is not imported. This is a good point which is actually somewhat unclear in RFC 6020. Sec. 9.9.1 defines the accessible tree for leafrefs in config data in terms of configuration datastores, e.g. the last bullet: o Otherwise, the tree is all state data on the device, and the datastore. The XPath root node has all top-level data nodes in all modules as children. This seems to imply that the parts of the configuration datastore coming from another module are also accessible, even if the latter module is not imported by the module containing the leafref. On the other hand, if you don't import the other module, you don't have the prefix of the other module that you need for the 'path' statement. > > Ersue and Bernd argued that the list of Selectors is very long. Hence, > instead of splitting the entire module, I would rather create a > submodule for the different Selectors. This is an option, just keep in mind that any new revision of the submodule implies a change in the main module, so the modularity is not as good as for (main) modules: http://tools.ietf.org/html/draft-ietf-netmod-yang-usage-11#section-3.5.2 Lada > > What do you think about this? > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From Internet-Drafts@ietf.org Mon Jan 10 12:45:02 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1D963A6405; Mon, 10 Jan 2011 12:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjZQNw2S4+fj; Mon, 10 Jan 2011 12:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD8763A63CB; Mon, 10 Jan 2011 12:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110110204501.5529.86880.idtracker@localhost> Date: Mon, 10 Jan 2011 12:45:01 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-flow-selection-tech-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 20:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Flow Selection Techniques Author(s) : L. Peluso, S. D'Antonio, C. Henke, T. Zseby Filename : draft-ietf-ipfix-flow-selection-tech-04.txt Pages : 33 Date : 2011-1-10 Flow selection is the process of selecting a subset of flows from all flows observed at an observation point. The objective of flow selection is to reduce the effort of post-processing flow data and transferring flow records. The flow selection process can be enabled at different stages of the measurement process. It can be applied either directly after classification or at recording/exporting time by limiting the number of flows to be stored and/or exported to the collecting process. This document describes motivations for flow selection and presents flow selection techniques. It furthermore provides an information model for configuring flow selection techniques and discusses what information about a flow selection process is worth exporting through a suitable information model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-flow-selection-tech-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-1-10123323.I-D@ietf.org> --NextPart-- From bclaise@cisco.com Wed Jan 12 08:16:45 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 248983A6B38 for ; Wed, 12 Jan 2011 08:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.453 X-Spam-Level: X-Spam-Status: No, score=-1.453 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, HTML_MESSAGE=0.001, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia1qwYEXvfEJ for ; Wed, 12 Jan 2011 08:16:44 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id D7ED73A6A4B for ; Wed, 12 Jan 2011 08:16:43 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0CGFIZ5002128 for ; Wed, 12 Jan 2011 17:15:18 +0100 (CET) Received: from [10.55.43.55] (ams-bclaise-8716.cisco.com [10.55.43.55]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0CGFHDC028170 for ; Wed, 12 Jan 2011 17:15:18 +0100 (CET) Message-ID: <4D2DD395.3060108@cisco.com> Date: Wed, 12 Jan 2011 17:15:17 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/alternative; boundary="------------090801000901090006000501" Subject: [IPFIX] RFC 7101, 7102, 7103? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 16:16:45 -0000 This is a multi-part message in MIME format. --------------090801000901090006000501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Based on the previous meeting minutes: Juergen led a discussion on "should we move the IPFIX base standards (RFCs 5101, 5102 and 5103) to Draft Standard. There was consensus that this would be worthwhile if it corrected all the bugs discovered to date in the documents, and added explanatory text to make them easier to understand. We also need to remove 'IP' from the IPFIX Flow definition, since that is proving to be a blocking factor or the ITU-T NGN to reference IPFIX. Do you think it's a good idea to reserve the following RFC 7101, 7102, 7103 numbers? Looking at http://www.ietf.org/download/rfc-index.txt, it's apparently too late for the 61xx series. Regards, Benoit. --------------090801000901090006000501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Based on the previous meeting minutes:
Juergen led a discussion on "should we move the IPFIX base standards
(RFCs 5101, 5102 and 5103) to Draft Standard.  There was consensus
that this would be worthwhile if it corrected all the bugs discovered
to date in the documents, and added explanatory text to make them
easier to understand.  We also need to remove 'IP' from the IPFIX Flow
definition, since that is proving to be a blocking factor or the ITU-T
NGN to reference IPFIX.
Do you think it's a good idea to reserve the following RFC 7101, 7102, 7103 numbers?
Looking at http://www.ietf.org/download/rfc-index.txt, it's apparently too late for the 61xx series.

Regards, Benoit.
--------------090801000901090006000501-- From n.brownlee@auckland.ac.nz Wed Jan 12 14:30:47 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467DD3A6846 for ; Wed, 12 Jan 2011 14:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.807 X-Spam-Level: X-Spam-Status: No, score=-105.807 tagged_above=-999 required=5 tests=[AWL=0.792, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZBkX0myzDnV for ; Wed, 12 Jan 2011 14:30:46 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id F25E03A6822 for ; Wed, 12 Jan 2011 14:30:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1294871587; x=1326407587; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4D2E2C1E.8010003@auckland.ac.nz>|Date:=20 Thu,=2013=20Jan=202011=2011:33:02=20+1300|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20Benoit=20Claise=20|CC:=20 "ipfix@ietf.org"=20|Subject:=20Re:=20[IPF IX]=20RFC=207101,=207102,=207103?|References:=20<4D2DD395 .3060108@cisco.com>|In-Reply-To:=20<4D2DD395.3060108@cisc o.com>|Content-Transfer-Encoding:=207bit; bh=7Rz0ATbyLiQyw6t796X7nnhF9DJyNEPI6Jcf+QCcZBE=; b=NHwAULZEFHa8uL3ldV9Ai93nLZKUWTegnzbp83sWDJzk31gpCngBmIZE a6U2dqzLYx/TcwfgWkrvbIT7xi14plFRxjH5i5HYpm31QDpj8N36rqonm EhBMt/v3nKoG23BebwxiozhSnvhsO3QKac4mkJKKb6WFp7teo/LrIeOVp Q=; X-IronPort-AV: E=Sophos;i="4.60,314,1291546800"; d="scan'208";a="42099170" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 13 Jan 2011 11:33:03 +1300 Message-ID: <4D2E2C1E.8010003@auckland.ac.nz> Date: Thu, 13 Jan 2011 11:33:02 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Benoit Claise References: <4D2DD395.3060108@cisco.com> In-Reply-To: <4D2DD395.3060108@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] RFC 7101, 7102, 7103? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 22:30:47 -0000 Hi Benoit: RFC Editor policy is that RFC numbers don't get allocated until a draft reaches AUTH48 state. However, for new RFCs that replace old ones, we can send an informal request to RFC Editor letting them know what we're doing so that they consider such a request when they're allocating numbers close to the ones we'd like. Note that there's no guarantee that we'd actually get them! Shall I send them an informal request like this? Cheers, Nevil On 13/01/11 5:15 AM, Benoit Claise wrote: > Dear all, > > Based on the previous meeting minutes: > Juergen led a discussion on "should we move the IPFIX base standards > (RFCs 5101, 5102 and 5103) to Draft Standard. There was consensus > that this would be worthwhile if it corrected all the bugs discovered > to date in the documents, and added explanatory text to make them > easier to understand. We also need to remove 'IP' from the IPFIX Flow > definition, since that is proving to be a blocking factor or the ITU-T > NGN to reference IPFIX. > Do you think it's a good idea to reserve the following RFC 7101, 7102, 7103 numbers? > Looking at http://www.ietf.org/download/rfc-index.txt, it's apparently too late for the 61xx series. > > Regards, Benoit. -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From dromasca@avaya.com Thu Jan 13 02:35:52 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2CD3A6B58 for ; Thu, 13 Jan 2011 02:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.507 X-Spam-Level: X-Spam-Status: No, score=-101.507 tagged_above=-999 required=5 tests=[AWL=-0.985, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6wuQeLqlN0h for ; Thu, 13 Jan 2011 02:35:51 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id B1C563A6A17 for ; Thu, 13 Jan 2011 02:35:50 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIIABNlLk3GmAcF/2dsb2JhbACkRmQPpgwClkMChUoEjkyHdw X-IronPort-AV: E=Sophos;i="4.60,317,1291611600"; d="scan'208";a="227321538" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Jan 2011 05:38:06 -0500 X-IronPort-AV: E=Sophos;i="4.60,317,1291611600"; d="scan'208";a="569808631" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Jan 2011 05:38:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jan 2011 11:37:47 +0100 Message-ID: In-Reply-To: <4D2E2C1E.8010003@auckland.ac.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] RFC 7101, 7102, 7103? Thread-Index: AcuyqLOaziVkgHSxR7+Bjxo2zr/fQQAZNsGQ References: <4D2DD395.3060108@cisco.com> <4D2E2C1E.8010003@auckland.ac.nz> From: "Romascanu, Dan (Dan)" To: "Nevil Brownlee" , "Benoit Claise" Cc: ipfix@ietf.org Subject: Re: [IPFIX] RFC 7101, 7102, 7103? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 10:35:52 -0000 Actually according to the RFC index 6101, 6102, 6103 were not published yet. They may have been reserved however, as the last one published is 6106. If they were reserved I would suggest that we do not wait until 7101, 7102, 7103 - this means a few years and I expect the Draft Standards to show up much sooner (please do not tell me I am wrong!).=20 Dan =20 > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org]=20 > On Behalf Of Nevil Brownlee > Sent: Thursday, January 13, 2011 12:33 AM > To: Benoit Claise > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] RFC 7101, 7102, 7103? >=20 >=20 > Hi Benoit: >=20 > RFC Editor policy is that RFC numbers don't get allocated=20 > until a draft reaches AUTH48 state. >=20 > However, for new RFCs that replace old ones, we can send an=20 > informal request to RFC Editor letting them know what we're=20 > doing so that they consider such a request when they're=20 > allocating numbers close to the ones we'd like. Note that=20 > there's no guarantee that we'd actually get them! >=20 > Shall I send them an informal request like this? >=20 > Cheers, Nevil >=20 >=20 > On 13/01/11 5:15 AM, Benoit Claise wrote: > > Dear all, > > > > Based on the previous meeting minutes: > > Juergen led a discussion on "should we move the IPFIX base=20 > standards=20 > > (RFCs 5101, 5102 and 5103) to Draft Standard. There was consensus=20 > > that this would be worthwhile if it corrected all the bugs=20 > discovered=20 > > to date in the documents, and added explanatory text to make them=20 > > easier to understand. We also need to remove 'IP' from the=20 > IPFIX Flow=20 > > definition, since that is proving to be a blocking factor=20 > or the ITU-T=20 > > NGN to reference IPFIX. > > Do you think it's a good idea to reserve the following RFC=20 > 7101, 7102, 7103 numbers? > > Looking at http://www.ietf.org/download/rfc-index.txt, it's=20 > apparently too late for the 61xx series. > > > > Regards, Benoit. >=20 > -- > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix >=20 From trammell@tik.ee.ethz.ch Thu Jan 13 02:38:16 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC95B3A6A17 for ; Thu, 13 Jan 2011 02:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZPJbCmB9kbp for ; Thu, 13 Jan 2011 02:38:15 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 888433A6B60 for ; Thu, 13 Jan 2011 02:38:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 25A0BD9362; Thu, 13 Jan 2011 11:40:37 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id a7OIeurGCiXk; Thu, 13 Jan 2011 11:40:36 +0100 (MET) Received: from mac-10243.ethz.ch (mac-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 8F9B4D9328; Thu, 13 Jan 2011 11:40:36 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: Date: Thu, 13 Jan 2011 11:40:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D2DD395.3060108@cisco.com> <4D2E2C1E.8010003@auckland.ac.nz> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1082) Cc: Nevil Brownlee , ipfix@ietf.org Subject: Re: [IPFIX] RFC 7101, 7102, 7103? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 10:38:16 -0000 hi, Dan, all, I say we look for the next xx01, xx02, xx03 available when we are ready = to publish -- these could be 660x, for example, just as well as 710x. (+1 to the idea in general) Cheers, Brian On Jan 13, 2011, at 11:37 AM, Romascanu, Dan (Dan) wrote: > Actually according to the RFC index 6101, 6102, 6103 were not = published > yet. They may have been reserved however, as the last one published is > 6106. If they were reserved I would suggest that we do not wait until > 7101, 7102, 7103 - this means a few years and I expect the Draft > Standards to show up much sooner (please do not tell me I am wrong!).=20= >=20 > Dan >=20 >=20 >> -----Original Message----- >> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org]=20 >> On Behalf Of Nevil Brownlee >> Sent: Thursday, January 13, 2011 12:33 AM >> To: Benoit Claise >> Cc: ipfix@ietf.org >> Subject: Re: [IPFIX] RFC 7101, 7102, 7103? >>=20 >>=20 >> Hi Benoit: >>=20 >> RFC Editor policy is that RFC numbers don't get allocated=20 >> until a draft reaches AUTH48 state. >>=20 >> However, for new RFCs that replace old ones, we can send an=20 >> informal request to RFC Editor letting them know what we're=20 >> doing so that they consider such a request when they're=20 >> allocating numbers close to the ones we'd like. Note that=20 >> there's no guarantee that we'd actually get them! >>=20 >> Shall I send them an informal request like this? >>=20 >> Cheers, Nevil >>=20 >>=20 >> On 13/01/11 5:15 AM, Benoit Claise wrote: >>> Dear all, >>>=20 >>> Based on the previous meeting minutes: >>> Juergen led a discussion on "should we move the IPFIX base=20 >> standards=20 >>> (RFCs 5101, 5102 and 5103) to Draft Standard. There was consensus=20= >>> that this would be worthwhile if it corrected all the bugs=20 >> discovered=20 >>> to date in the documents, and added explanatory text to make them=20 >>> easier to understand. We also need to remove 'IP' from the=20 >> IPFIX Flow=20 >>> definition, since that is proving to be a blocking factor=20 >> or the ITU-T=20 >>> NGN to reference IPFIX. >>> Do you think it's a good idea to reserve the following RFC=20 >> 7101, 7102, 7103 numbers? >>> Looking at http://www.ietf.org/download/rfc-index.txt, it's=20 >> apparently too late for the 61xx series. >>>=20 >>> Regards, Benoit. >>=20 >> -- >> --------------------------------------------------------------------- >> Nevil Brownlee Computer Science Department | ITS >> Phone: +64 9 373 7599 x88941 The University of Auckland >> FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >>=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From dromasca@avaya.com Thu Jan 13 02:40:27 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C70353A6B62 for ; Thu, 13 Jan 2011 02:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.502 X-Spam-Level: X-Spam-Status: No, score=-101.502 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UHjnLjRPgAi for ; Thu, 13 Jan 2011 02:40:27 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id F07D03A6B60 for ; Thu, 13 Jan 2011 02:40:26 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIIAD5mLk3GmAcF/2dsb2JhbACkRmQPphYClkEChUoEjkw X-IronPort-AV: E=Sophos;i="4.60,317,1291611600"; d="scan'208";a="259393743" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 Jan 2011 05:42:45 -0500 X-IronPort-AV: E=Sophos;i="4.60,317,1291611600"; d="scan'208";a="569809740" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Jan 2011 05:42:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jan 2011 11:42:24 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] RFC 7101, 7102, 7103? Thread-Index: AcuzDlLzzWPgQF1EScerMl+6j9aXmgAADGmw References: <4D2DD395.3060108@cisco.com> <4D2E2C1E.8010003@auckland.ac.nz> From: "Romascanu, Dan (Dan)" To: "Brian Trammell" Cc: Nevil Brownlee , ipfix@ietf.org Subject: Re: [IPFIX] RFC 7101, 7102, 7103? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 10:40:27 -0000 Good compromise.=20 Dan =20 > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]=20 > Sent: Thursday, January 13, 2011 12:41 PM > To: Romascanu, Dan (Dan) > Cc: Nevil Brownlee; Benoit Claise; ipfix@ietf.org > Subject: Re: [IPFIX] RFC 7101, 7102, 7103? >=20 > hi, Dan, all, >=20 > I say we look for the next xx01, xx02, xx03 available when we=20 > are ready to publish -- these could be 660x, for example,=20 > just as well as 710x. >=20 > (+1 to the idea in general) >=20 > Cheers, >=20 > Brian >=20 > On Jan 13, 2011, at 11:37 AM, Romascanu, Dan (Dan) wrote: >=20 > > Actually according to the RFC index 6101, 6102, 6103 were not=20 > > published yet. They may have been reserved however, as the last one=20 > > published is 6106. If they were reserved I would suggest that we do=20 > > not wait until 7101, 7102, 7103 - this means a few years=20 > and I expect=20 > > the Draft Standards to show up much sooner (please do not=20 > tell me I am wrong!). > >=20 > > Dan > >=20 > >=20 > >> -----Original Message----- > >> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On=20 > >> Behalf Of Nevil Brownlee > >> Sent: Thursday, January 13, 2011 12:33 AM > >> To: Benoit Claise > >> Cc: ipfix@ietf.org > >> Subject: Re: [IPFIX] RFC 7101, 7102, 7103? > >>=20 > >>=20 > >> Hi Benoit: > >>=20 > >> RFC Editor policy is that RFC numbers don't get allocated until a=20 > >> draft reaches AUTH48 state. > >>=20 > >> However, for new RFCs that replace old ones, we can send=20 > an informal=20 > >> request to RFC Editor letting them know what we're doing=20 > so that they=20 > >> consider such a request when they're allocating numbers=20 > close to the=20 > >> ones we'd like. Note that there's no guarantee that we'd actually=20 > >> get them! > >>=20 > >> Shall I send them an informal request like this? > >>=20 > >> Cheers, Nevil > >>=20 > >>=20 > >> On 13/01/11 5:15 AM, Benoit Claise wrote: > >>> Dear all, > >>>=20 > >>> Based on the previous meeting minutes: > >>> Juergen led a discussion on "should we move the IPFIX base > >> standards > >>> (RFCs 5101, 5102 and 5103) to Draft Standard. There was=20 > consensus=20 > >>> that this would be worthwhile if it corrected all the bugs > >> discovered > >>> to date in the documents, and added explanatory text to make them=20 > >>> easier to understand. We also need to remove 'IP' from the > >> IPFIX Flow > >>> definition, since that is proving to be a blocking factor > >> or the ITU-T > >>> NGN to reference IPFIX. > >>> Do you think it's a good idea to reserve the following RFC > >> 7101, 7102, 7103 numbers? > >>> Looking at http://www.ietf.org/download/rfc-index.txt, it's > >> apparently too late for the 61xx series. > >>>=20 > >>> Regards, Benoit. > >>=20 > >> -- > >>=20 > --------------------------------------------------------------------- > >> Nevil Brownlee Computer Science=20 > Department | ITS > >> Phone: +64 9 373 7599 x88941 The University=20 > of Auckland > >> FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142,=20 > New Zealand > >> _______________________________________________ > >> IPFIX mailing list > >> IPFIX@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipfix > >>=20 > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix >=20 >=20 From bclaise@cisco.com Thu Jan 13 09:41:26 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56E5F28C133 for ; Thu, 13 Jan 2011 09:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xy+IeSPjeXR for ; Thu, 13 Jan 2011 09:41:25 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 15FD428C130 for ; Thu, 13 Jan 2011 09:41:24 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0DHDhCO024990; Thu, 13 Jan 2011 18:13:43 +0100 (CET) Received: from [10.55.43.55] (ams-bclaise-8716.cisco.com [10.55.43.55]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0DHDgqI015402; Thu, 13 Jan 2011 18:13:42 +0100 (CET) Message-ID: <4D2F32C6.1080705@cisco.com> Date: Thu, 13 Jan 2011 18:13:42 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4D2DD395.3060108@cisco.com> <4D2E2C1E.8010003@auckland.ac.nz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nevil Brownlee , ipfix@ietf.org Subject: Re: [IPFIX] RFC 7101, 7102, 7103? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 17:41:26 -0000 Dan, I did some more investigations. Some RFCs are in AUTH48. For example, http://www.rfc-editor.org/auth48/rfc6074 However, I don't see any entries for http://www.rfc-editor.org/auth48/rfc6101 http://www.rfc-editor.org/auth48/rfc6102 http://www.rfc-editor.org/auth48/rfc6103 So unless there were reserved, they might still be free. Worth asking RFC-editor now? > Actually according to the RFC index 6101, 6102, 6103 were not published > yet. They may have been reserved however, as the last one published is > 6106. If they were reserved I would suggest that we do not wait until > 7101, 7102, 7103 - this means a few years and I expect the Draft > Standards to show up much sooner (please do not tell me I am wrong!). No, you're not wrong. ;-) Regards, Benoit. > Dan > > >> -----Original Message----- >> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] >> On Behalf Of Nevil Brownlee >> Sent: Thursday, January 13, 2011 12:33 AM >> To: Benoit Claise >> Cc: ipfix@ietf.org >> Subject: Re: [IPFIX] RFC 7101, 7102, 7103? >> >> >> Hi Benoit: >> >> RFC Editor policy is that RFC numbers don't get allocated >> until a draft reaches AUTH48 state. >> >> However, for new RFCs that replace old ones, we can send an >> informal request to RFC Editor letting them know what we're >> doing so that they consider such a request when they're >> allocating numbers close to the ones we'd like. Note that >> there's no guarantee that we'd actually get them! >> >> Shall I send them an informal request like this? >> >> Cheers, Nevil >> >> >> On 13/01/11 5:15 AM, Benoit Claise wrote: >>> Dear all, >>> >>> Based on the previous meeting minutes: >>> Juergen led a discussion on "should we move the IPFIX base >> standards >>> (RFCs 5101, 5102 and 5103) to Draft Standard. There was consensus >>> that this would be worthwhile if it corrected all the bugs >> discovered >>> to date in the documents, and added explanatory text to make them >>> easier to understand. We also need to remove 'IP' from the >> IPFIX Flow >>> definition, since that is proving to be a blocking factor >> or the ITU-T >>> NGN to reference IPFIX. >>> Do you think it's a good idea to reserve the following RFC >> 7101, 7102, 7103 numbers? >>> Looking at http://www.ietf.org/download/rfc-index.txt, it's >> apparently too late for the 61xx series. >>> Regards, Benoit. >> -- >> --------------------------------------------------------------------- >> Nevil Brownlee Computer Science Department | ITS >> Phone: +64 9 373 7599 x88941 The University of Auckland >> FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> From dromasca@avaya.com Thu Jan 13 09:42:48 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30DFE28C139 for ; Thu, 13 Jan 2011 09:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.498 X-Spam-Level: X-Spam-Status: No, score=-101.498 tagged_above=-999 required=5 tests=[AWL=-0.976, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66Mrr3tYPRtG for ; Thu, 13 Jan 2011 09:42:47 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 111BE28C12E for ; Thu, 13 Jan 2011 09:42:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIIAOrILk2HCzI1/2dsb2JhbACkSGQPpwUClioChUoEjkw X-IronPort-AV: E=Sophos;i="4.60,318,1291611600"; d="scan'208";a="227400972" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Jan 2011 12:45:08 -0500 X-IronPort-AV: E=Sophos;i="4.60,318,1291611600"; d="scan'208";a="581971260" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Jan 2011 12:45:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jan 2011 18:44:55 +0100 Message-ID: In-Reply-To: <4D2F32C6.1080705@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] RFC 7101, 7102, 7103? Thread-Index: AcuzSXA3x2KYBqDATxWanUUMRVMW5AAABV1A References: <4D2DD395.3060108@cisco.com> <4D2E2C1E.8010003@auckland.ac.nz> <4D2F32C6.1080705@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" Cc: Nevil Brownlee , ipfix@ietf.org Subject: Re: [IPFIX] RFC 7101, 7102, 7103? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 17:42:48 -0000 Indeed!=20 > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com]=20 > Sent: Thursday, January 13, 2011 7:14 PM > To: Romascanu, Dan (Dan) > Cc: Nevil Brownlee; ipfix@ietf.org > Subject: Re: [IPFIX] RFC 7101, 7102, 7103? >=20 > Dan, >=20 > I did some more investigations. > Some RFCs are in AUTH48. For example, > http://www.rfc-editor.org/auth48/rfc6074 > However, I don't see any entries for > http://www.rfc-editor.org/auth48/rfc6101 > http://www.rfc-editor.org/auth48/rfc6102 > http://www.rfc-editor.org/auth48/rfc6103 >=20 > So unless there were reserved, they might still be free. > Worth asking RFC-editor now? > > Actually according to the RFC index 6101, 6102, 6103 were not=20 > > published yet. They may have been reserved however, as the last one=20 > > published is 6106. If they were reserved I would suggest that we do=20 > > not wait until 7101, 7102, 7103 - this means a few years=20 > and I expect=20 > > the Draft Standards to show up much sooner (please do not=20 > tell me I am wrong!). > No, you're not wrong. ;-) >=20 > Regards, Benoit. > > Dan > > > > > >> -----Original Message----- > >> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On=20 > >> Behalf Of Nevil Brownlee > >> Sent: Thursday, January 13, 2011 12:33 AM > >> To: Benoit Claise > >> Cc: ipfix@ietf.org > >> Subject: Re: [IPFIX] RFC 7101, 7102, 7103? > >> > >> > >> Hi Benoit: > >> > >> RFC Editor policy is that RFC numbers don't get allocated until a=20 > >> draft reaches AUTH48 state. > >> > >> However, for new RFCs that replace old ones, we can send=20 > an informal=20 > >> request to RFC Editor letting them know what we're doing=20 > so that they=20 > >> consider such a request when they're allocating numbers=20 > close to the=20 > >> ones we'd like. Note that there's no guarantee that we'd actually=20 > >> get them! > >> > >> Shall I send them an informal request like this? > >> > >> Cheers, Nevil > >> > >> > >> On 13/01/11 5:15 AM, Benoit Claise wrote: > >>> Dear all, > >>> > >>> Based on the previous meeting minutes: > >>> Juergen led a discussion on "should we move the IPFIX base > >> standards > >>> (RFCs 5101, 5102 and 5103) to Draft Standard. There was=20 > consensus=20 > >>> that this would be worthwhile if it corrected all the bugs > >> discovered > >>> to date in the documents, and added explanatory text to make them=20 > >>> easier to understand. We also need to remove 'IP' from the > >> IPFIX Flow > >>> definition, since that is proving to be a blocking factor > >> or the ITU-T > >>> NGN to reference IPFIX. > >>> Do you think it's a good idea to reserve the following RFC > >> 7101, 7102, 7103 numbers? > >>> Looking at http://www.ietf.org/download/rfc-index.txt, it's > >> apparently too late for the 61xx series. > >>> Regards, Benoit. > >> -- > >>=20 > --------------------------------------------------------------------- > >> Nevil Brownlee Computer Science=20 > Department | ITS > >> Phone: +64 9 373 7599 x88941 The University=20 > of Auckland > >> FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142,=20 > New Zealand > >> _______________________________________________ > >> IPFIX mailing list > >> IPFIX@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipfix > >> >=20 >=20 From Internet-Drafts@ietf.org Thu Jan 20 02:30:03 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39F933A7101; Thu, 20 Jan 2011 02:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ima4wBZR9bFJ; Thu, 20 Jan 2011 02:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC18B3A6F75; Thu, 20 Jan 2011 02:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110120103001.18772.82316.idtracker@localhost> Date: Thu, 20 Jan 2011 02:30:01 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-anon-06.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 10:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IP Flow Anonymization Support Author(s) : E. Boschi, B. Trammell Filename : draft-ietf-ipfix-anon-06.txt Pages : 43 Date : 2011-01-20 This document describes anonymization techniques for IP flow data and the export of anonymized data using the IPFIX protocol. It categorizes common anonymization schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options-based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-anon-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-anon-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-20022303.I-D@ietf.org> --NextPart-- From trammell@tik.ee.ethz.ch Mon Jan 24 00:11:24 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 968753A6A08 for ; Mon, 24 Jan 2011 00:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKWrH0aj-YbO for ; Mon, 24 Jan 2011 00:11:23 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 0E7443A63CA for ; Mon, 24 Jan 2011 00:11:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id CE154D9394 for ; Mon, 24 Jan 2011 09:14:15 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sQs994llILw7 for ; Mon, 24 Jan 2011 09:14:15 +0100 (MET) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 92095D9391 for ; Mon, 24 Jan 2011 09:14:15 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Jan 2011 09:14:15 +0100 Message-Id: To: ipfix@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [IPFIX] IPFIX Interoperability Event, Prague, March 24-25, 2011 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 08:11:24 -0000 Greetings, all, The FP7 DEMONS (http://www.fp7-demons.org) project is organizing an = IPFIX Interoperability Event the Thursday and Friday before IETF 80 in = Prague, on March 24-25, in cooperation with CESNET (http://www.ces.net). = The aim of the event is to test interoperability among developers and = vendors of IPFIX Devices, focusing on the core protocol. The results of = this event will be used to advance IPFIX down the IETF Standards Track. The event will take place at the offices of CESNET, Zikova 4, 160 00 = Prague 6, Czech Republic.=20 Details are available at http://fp7-demons.org/?p=3D164 ... please feel = free to forward this link to anyone who may be interested. Best regards, Brian Trammell (Organizer) -- trammell@tik.ee.ethz.ch From n.brownlee@auckland.ac.nz Mon Jan 24 23:43:32 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6477C3A6A69 for ; Mon, 24 Jan 2011 23:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.32 X-Spam-Level: X-Spam-Status: No, score=-104.32 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GnXderuvIoL for ; Mon, 24 Jan 2011 23:43:31 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id A9A053A6A60 for ; Mon, 24 Jan 2011 23:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1295941588; x=1327477588; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; z=Message-ID:=20<4D3E7FD0.1000100@auckland.ac.nz>|Date:=20 Mon,=2024=20Jan=202011=2023:46:24=20-0800|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20RFC=20Editor=20 |CC:=20IPFIX=20list=20|Subject:=20Informa l=20request=20for=20RFC=20numbers |Content-Transfer-Encoding:=207bit; bh=PLJqzRfelrhoRRFgsODK5y12qNR974Ocw/h/vydxNU8=; b=kaqc3+Fe6YJivqymHiYqSS34QzbgYnTHpQZemcEuAmwMnnnOcCS1dLS4 m3rZF4RXd9ZCi6aoupXbeCzn2iDNDOnjV+rBl777nuEA7BQJljkWFVyPn 8VFc5TflWwva2gKVZpGo8+Y4BIMpfAZTHwUFl6q5ZNPKbg30mVXfoHLUo I=; X-IronPort-AV: E=Sophos;i="4.60,373,1291546800"; d="scan'208";a="43598890" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 121.73.130.252 - Outgoing - Outgoing-SSL Received: from 121-73-130-252.cable.telstraclear.net (HELO [192.168.0.106]) ([121.73.130.252]) by mx2-int.auckland.ac.nz with ESMTP; 25 Jan 2011 20:46:25 +1300 Message-ID: <4D3E7FD0.1000100@auckland.ac.nz> Date: Mon, 24 Jan 2011 23:46:24 -0800 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: RFC Editor Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX list Subject: [IPFIX] Informal request for RFC numbers X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 07:43:32 -0000 Hi RFC Editor: The IPFIX Working Group has three Proposed Standard RFCs, 5101, 5102 and 5103. We will soon start work on revising them, with the goal of replacing them with new Draft Standards. If it's possible, we would like the Draft Standards to have similar numbers, such as 6101, 2 and 3. Alternatively, rather than waiting until the RFC numbers reach 7101, having a set of numbers ending in 1, 2 and 3 could be a good alternative. Would you please note this request; I will keep you informed of the IPFIX WG's progress with this work. Cheers, Nevil (IPFIX Co-chair) -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From Glenn@RiverOnce.com Tue Jan 25 07:27:14 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 791F33A67F0 for ; Tue, 25 Jan 2011 07:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE9w88Torjk2 for ; Tue, 25 Jan 2011 07:27:13 -0800 (PST) Received: from sbh11.songbird.com (sbh11.songbird.com [72.52.113.11]) by core3.amsl.com (Postfix) with ESMTP id 8C49D3A67E7 for ; Tue, 25 Jan 2011 07:27:13 -0800 (PST) Received: from [10.0.1.3] (c-68-51-252-202.hsd1.fl.comcast.net [68.51.252.202]) (authenticated bits=0) by sbh11.songbird.com (8.13.8/8.13.8) with ESMTP id p0PFU3Fd002487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Jan 2011 07:30:05 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Glenn Kowack In-Reply-To: <4D3E7FD0.1000100@auckland.ac.nz> Date: Tue, 25 Jan 2011 10:30:00 -0500 Content-Transfer-Encoding: 7bit Message-Id: <7B2AAA41-9B69-4E17-934B-D0CEDF89F305@RiverOnce.com> References: <4D3E7FD0.1000100@auckland.ac.nz> To: Nevil Brownlee X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh11.songbird.com [72.52.113.11]); Tue, 25 Jan 2011 07:30:05 -0800 (PST) X-Mailman-Approved-At: Tue, 25 Jan 2011 20:51:44 -0800 Cc: IPFIX list , RFC Editor Subject: Re: [IPFIX] Informal request for RFC numbers X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 15:27:14 -0000 Nevil, Just to be sure - you're have taken off your Independent Submission Editor hat while making this request, yes? thanks, Glenn ___ On Jan 25, 2011, at 2:46 AM, Nevil Brownlee wrote: > > Hi RFC Editor: > > The IPFIX Working Group has three Proposed Standard RFCs, 5101, 5102 > and 5103. We will soon start work on revising them, with the goal of > replacing them with new Draft Standards. If it's possible, we would > like the Draft Standards to have similar numbers, such as 6101, 2 and 3. > > Alternatively, rather than waiting until the RFC numbers reach 7101, > having a set of numbers ending in 1, 2 and 3 could be a good alternative. > > Would you please note this request; I will keep you informed of the > IPFIX WG's progress with this work. > > Cheers, Nevil (IPFIX Co-chair) > > -- > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From bclaise@cisco.com Fri Jan 28 04:22:24 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BE4C3A683B for ; Fri, 28 Jan 2011 04:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RH3wB+eFkLLT for ; Fri, 28 Jan 2011 04:22:23 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id B84CA3A6833 for ; Fri, 28 Jan 2011 04:22:22 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0SBmKpC022858; Fri, 28 Jan 2011 12:48:20 +0100 (CET) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0SBmJ8Y015330; Fri, 28 Jan 2011 12:48:20 +0100 (CET) Message-ID: <4D42AD03.4040707@cisco.com> Date: Fri, 28 Jan 2011 12:48:19 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "ipfix@ietf.org" , ipfix-chairs@tools.ietf.org References: <4D0FD3EF.6040803@cisco.com> In-Reply-To: <4D0FD3EF.6040803@cisco.com> Content-Type: multipart/alternative; boundary="------------080007010607090403080204" Subject: Re: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-structured-data-04 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 12:22:24 -0000 This is a multi-part message in MIME format. --------------080007010607090403080204 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Nevil, Juergen, Now that the WGLC is finished, can we please progress this document. Thanks, Benoit > Dear all, > > This version should take care of all the WGLC comments. > > Regards, Benoit. > -------- Original Message -------- > Subject: New Version Notification for > draft-ietf-ipfix-structured-data-04 > Date: Mon, 20 Dec 2010 14:04:35 -0800 (PST) > From: IETF I-D Submission Tool > To: bclaise@cisco.com > CC: gowri@cisco.com, syates@cisco.com, paitken@cisco.com > > > > A new version of I-D, draft-ietf-ipfix-structured-data-04.txt has been successfully submitted by Benoit Claise and posted to the IETF repository. > > Filename: draft-ietf-ipfix-structured-data > Revision: 04 > Title: Export of Structured Data in IPFIX > Creation_date: 2010-12-20 > WG ID: ipfix > Number_of_pages: 74 > > Abstract: > This document specifies an extension to the IP Flow Information > > eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX > > information model specified in [RFC5102] to support hierarchical > > structured data and lists (sequences) of Information Elements in > > data records. This extension allows definition of complex data > > structures such as variable-length lists and specification of > > hierarchical containment relationships between Templates. > > Finally, the semantics are provided in order to express the > > relationship among multiple list elements in a structured data > > record. > > > > The IETF Secretariat. > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------080007010607090403080204 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Nevil, Juergen,

Now that the WGLC is finished, can we please progress this document.

Thanks, Benoit
Dear all,

This version should take care of all the WGLC comments.

Regards, Benoit.
-------- Original Message --------
Subject: New Version Notification for draft-ietf-ipfix-structured-data-04
Date: Mon, 20 Dec 2010 14:04:35 -0800 (PST)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: bclaise@cisco.com
CC: gowri@cisco.com, syates@cisco.com, paitken@cisco.com 


A new version of I-D, draft-ietf-ipfix-structured-data-04.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-ietf-ipfix-structured-data
Revision:	 04
Title:		 Export of Structured Data in IPFIX
Creation_date:	 2010-12-20
WG ID:		 ipfix
Number_of_pages: 74

Abstract:
This document specifies an extension to the IP Flow Information 

  eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX 

  information model specified in [RFC5102] to support hierarchical 

  structured data and lists (sequences) of Information Elements in 

  data records.  This extension allows definition of complex data 

  structures such as variable-length lists and specification of 

  hierarchical containment relationships between Templates. 

  Finally, the semantics are provided in order to express the 

  relationship among multiple list elements in a structured data 

  record.
                                                                                  


The IETF Secretariat.



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

--------------080007010607090403080204--