From muenz@net.in.tum.de Thu Jul 1 01:10:19 2010 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 F39003A685B for ; Thu, 1 Jul 2010 01:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.042 X-Spam-Level: X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[AWL=1.207, 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 eCtwFW0Kh0k3 for ; Thu, 1 Jul 2010 01:10:17 -0700 (PDT) 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 E68C73A6855 for ; Thu, 1 Jul 2010 01:10:16 -0700 (PDT) Received: from [131.159.20.248] (vpn-4.net.in.tum.de [131.159.20.248]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 1C4522096A57; Thu, 1 Jul 2010 10:10:26 +0200 (CEST) Message-ID: <4C2C4D7A.7070604@net.in.tum.de> Date: Thu, 01 Jul 2010 10:10:34 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4B9AC2F8.1090504@cisco.com> <4B9B87BD.7020201@net.in.tum.de> <4BA5584E.3060508@auckland.ac.nz> <4BA5611F.90309@cisco.com><4BA6A547.7050503@cisco.com> <4C2B118B.4050601@net.in.tum.de> <4C2C2C7F.8090202@auckland.ac.nz> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090704030900020105020406" X-Virus-Scanned: ClamAV using ClamSMTP Cc: Nevil Brownlee , ipfix@ietf.org Subject: Re: [IPFIX] IPFIX errata 2052 to 2059 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, 01 Jul 2010 08:10:19 -0000 This is a cryptographically signed message in MIME format. --------------ms090704030900020105020406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Nevil, As a further consequence, the status of errata 2053, 2054, 2055, 2056, 2057, 2058, and 2059 (related to RFC 5476) should be "rejected" instead of "verified". In the examples, we see selectorId with length =3D 4 (=3D32bit), so there= is no reduced size encoding. Thanks, Gerhard Romascanu, Dan (Dan) wrote: > Nevil, >=20 > The way to do it is to 'unverify' errata 2052 - and I think that this > can be done by the RFC Editor. Do you know anybody there? :-) Then I ca= n > reenter the proper resolution. Can you suggest the text that the WG > reached consensus about?=20 >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org]=20 >> On Behalf Of Nevil Brownlee >> Sent: Thursday, July 01, 2010 8:50 AM >> To: Gerhard Muenz >> Cc: ipfix@ietf.org >> Subject: Re: [IPFIX] IPFIX errata 2052 to 2059 >> >> >> Hi Gerhard: >> >> Oh, Oh, .. looking back I see that when I asked Dan to verify=20 >> these errata, I gave him a confusing message, so it's been=20 >> verified incorrectly - consensus was (as you say below) for=20 >> unsigned32. >> >> I'll work out the best way to get errata 2052 corrected. >> >> Cheers, Nevil >> >> >> Gerhard Muenz wrote: >>> Dear all, >>> >>> I see unsigned64 as being verified in the errata, not unsigned32: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D5477 >>> >>> So, what's true now? >>> >>> Regards, >>> Gerhard >>> >>> Benoit Claise wrote: >>>> Nevil, >>>>> Nevil, >>>>> >>>>>> I'm looking through our 'unverified' errata - do we have=20 >> consensus=20 >>>>>> for Paul's Errata 2052, i.e. change SelectorId to unsigned64? >>>>> The consensus seems to be a change to unsigned32. >>>> It's true that unsigned64 would have been better, and Thomas=20 >>>> highlighted a limitation with the MIB. >>>> So let's go for unsigned32 then. >>>> >>>> Regards, Benoit. >>>>> Thanks, >>>>> P. >>>>> >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >> >> -- >> --------------------------------------------------------------------- >> 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 Dr.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms090704030900020105020406 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDcwMTA4MTAzNFowIwYJKoZIhvcNAQkEMRYEFHd7 mIy1Uyo3MSiyKhFo54V8oVPgMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQAiEfiI+Erz9zC0+M+/0wwp0/0DSRwh4pa8brUOLHqBeA4OzpnMlGdN YQyg4UcmnnOc9OTup2AKctFZ6hux7vO6kwqZwFTMyzYBW/CIF5Mq+pLuQ14BSEg/rZ3AqHo0 Wubk2ThMK4L0AjtUiQwJbejUwV9A7uZSFHGjL1AUJvideZAh8HWbOej47/SV7NwIET9jbZVG /R9YcvDAyCwRjMGpEVwLPKwFX/54I/U46LWMWvtkWDwN9ktG5vgCRbVdtP6g0T02ynjSuvNh GW+Ljx0JuaWfnx7kEvSHcaELwDGWS4QU0vYfxPzeFY8aZRrOAoNdusvkd9q6eDxNe6Nfs+7l AAAAAAAA --------------ms090704030900020105020406-- From n.brownlee@auckland.ac.nz Sun Jul 4 16:04:41 2010 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 373323A67E3 for ; Sun, 4 Jul 2010 16:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 fHm0XHhrQWgK for ; Sun, 4 Jul 2010 16:04:40 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 00BC43A6781 for ; Sun, 4 Jul 2010 16:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1278284681; x=1309820681; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4C311369.8030409@auckland.ac.nz>|Date:=20 Sun,=2004=20Jul=202010=2016:04:09=20-0700|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20list=20|Subject:=20W G=20LC=20for=20two=20drafts|Content-Transfer-Encoding:=20 7bit; bh=WyiKLWt9WSyTkrE3FqV3fbvCHUuCynRERFduPwlwf50=; b=rN442VmaQfB7W5MpL3+ODU+YrT/o41X3Ze5+AREAUijTqemnKnPcK9xc hj/n4YSlZydxBng7EFlzxqJ5le04S50BnchJ3tUKBZyZkpb33qY20uoXm ivA/pXLIqu/blZbZpPYGvny3ipwktkV/2q9ij86XCFm8VM9OB6fOnlXOG E=; X-IronPort-AV: E=Sophos;i="4.53,537,1272801600"; d="scan'208";a="13804874" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 121.98.151.149 - Outgoing - Outgoing-SSL Received: from 121-98-151-149.bitstream.orcon.net.nz (HELO [192.168.0.6]) ([121.98.151.149]) by mx2-int.auckland.ac.nz with ESMTP; 05 Jul 2010 11:04:10 +1200 Message-ID: <4C311369.8030409@auckland.ac.nz> Date: Sun, 04 Jul 2010 16:04:09 -0700 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] WG LC for two drafts 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, 04 Jul 2010 23:04:41 -0000 Hi all: The two drafts - Export of Structured Data in IPFIX draft-ietf-ipfix-structured-data-01.txt - Flow Selection Techniques draft-ietf-ipfix-flow-selection-tech-02.txt appear to represent our current consensus. This email starts their WG Last Call, it will end just before the IPFIX meeting at the Maastricht IETF meeting. Cheers, 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 n.brownlee@auckland.ac.nz Sun Jul 4 16:28:28 2010 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 183D13A6403 for ; Sun, 4 Jul 2010 16:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11] 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 zKKWrLSLn0k1 for ; Sun, 4 Jul 2010 16:28:26 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 4DAF93A63CB for ; Sun, 4 Jul 2010 16:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1278286107; x=1309822107; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4C3118F0.7060700@auckland.ac.nz>|Date:=20 Sun,=2004=20Jul=202010=2016:27:44=20-0700|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20list=20|Subject:=20* **DRAFT***=20Agenda=20for=20Maastricht=20Meeting |Content-Transfer-Encoding:=207bit; bh=6dKqjxKciBWtTD6jbl7/R4MdGKMkIwogr83aMIsORcs=; b=iTKEhfbaLW9JNoWiuUKlZRoZv0sGJpBn3RyL0VBd3t6CCPEZw7qTZq1R 0UEhfD9steqiBVDQ4yClm5tTFRn1S3hd+Qsa5e7NjeTQ0UOFHKsTgBgOC RXoX2xQ10gbTuWsBcF0vUavyafWFgQYRE3O85sfWnQHXUvBuCRFsr8MJU g=; X-IronPort-AV: E=Sophos;i="4.53,537,1272801600"; d="scan'208";a="13809723" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 121.98.151.149 - Outgoing - Outgoing-SSL Received: from 121-98-151-149.bitstream.orcon.net.nz (HELO [192.168.0.6]) ([121.98.151.149]) by mx2-int.auckland.ac.nz with ESMTP; 05 Jul 2010 11:27:45 +1200 Message-ID: <4C3118F0.7060700@auckland.ac.nz> Date: Sun, 04 Jul 2010 16:27:44 -0700 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] ***DRAFT*** Agenda for Maastricht 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: Sun, 04 Jul 2010 23:28:28 -0000 Hi all: Here's my first draft agenda; if you have material, e.g. new drafts, you want discussed, please email me to request that. As another thing to think about, the IPFIX Standards are mostly Proposed Standards. 5101, 5102 and 5103 were published in 2008, should we be asking for them to become Ingternet Standards? To do that we need to demonstrate that there are inter-operating implementations. To help me assess that, would everyone who has an implementation please email me (either on or off-list) with some brief details of it, particularly the date it was first used, and an estimate of how many sites are using it? Cheers, 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 ====================================================== Ip Flow Information Export WG (ipfix) IETF #78, Maastricht Thursday, 29 July, 1300-1500, Berlin room ====================================================== Chairs: Juergen Quittek Nevil Brownlee AGENDA: 1. Agenda review WG Status = 5 min 2. Update from last meeting = 5 min Errata 2052 et al Mediators Problem Statement - in RFC Editor queue 3. Current WG drafts = 65 min a) Config Data Model draft-ietf-ipfix-configuration-model-05, 8 Mar 10 b) SCTP per-stream draft (Benoit Claise) draft-ietf-ipfix-export-per-sctp-stream-06, 19 Nov 09 Currently with IESG d) Mediators Framework (Atsushi Kobayashi) draft-ietf-ipfix-mediators-framework-06, 20 Apr 10 Ready for IETF LC e) IP Flow Anonymisation Support (Elisa Boschi) draft-ietf-ipfix-anon-02, 15 Feb 10 Ready for IETF LC f) Flow Selection Techniques (Tanja Zseby) draft-ietf-ipfix-flow-selection-tech-02, 1 Jun 10 (Peluso, Zseby. D'Antonio & Molina) WG LC started g) Export of Structured Data in IPFIX (Benoit Claise) draft-ietf-ipfix-structured-data-01, 8 Mar 10 (Claise, Dhandapani, Yates & Aitken) WG LC started h) PSAMP MIB (Benoit Claise) [earlier draft from PSAMP WG] draft-ietf-ipfix-psamp-mib-00.txt, 2 Mar 10 4. Other drafts = 40 min ?? 5. Any Other Business = 5 min - Milestones Review Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=78 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org ------------------ From bclaise@cisco.com Mon Jul 5 10:30:25 2010 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 7CDB53A67D7 for ; Mon, 5 Jul 2010 10:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 ZY9fC8VkIPcZ for ; Mon, 5 Jul 2010 10:30:24 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 706523A67A4 for ; Mon, 5 Jul 2010 10:30:24 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o65H2Nuv022029; Mon, 5 Jul 2010 19:02:23 +0200 (CEST) Received: from [10.21.85.163] (sjc-vpn4-1444.cisco.com [10.21.85.163]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o65H2GgV022006; Mon, 5 Jul 2010 19:02:18 +0200 (CEST) Message-ID: <4C321018.1030501@cisco.com> Date: Mon, 05 Jul 2010 10:02:16 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Nevil Brownlee References: <4C311369.8030409@auckland.ac.nz> In-Reply-To: <4C311369.8030409@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX list Subject: Re: [IPFIX] WG LC for two drafts 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, 05 Jul 2010 17:30:25 -0000 Dear Nevil, Regarding draft-ietf-ipfix-structured-data-01.txt, we decided at the last IETF meeting that we wanted to add the semantic field. We are busy integrating it, and we will have a new version before the deadline. So could it be possible to postpone the WG Last Call by a week, when the version 02 will be there? Regards, Benoit > Hi all: > > The two drafts > - Export of Structured Data in IPFIX > draft-ietf-ipfix-structured-data-01.txt > - Flow Selection Techniques > draft-ietf-ipfix-flow-selection-tech-02.txt > appear to represent our current consensus. > > This email starts their WG Last Call, it will end just before > the IPFIX meeting at the Maastricht IETF meeting. > > Cheers, Nevil > From n.brownlee@auckland.ac.nz Wed Jul 7 00:15:50 2010 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 499943A6868 for ; Wed, 7 Jul 2010 00:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[AWL=-0.603, BAYES_50=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 rMCbo6yVmE8H for ; Wed, 7 Jul 2010 00:15:46 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 3C0843A6862 for ; Wed, 7 Jul 2010 00:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1278486949; x=1310022949; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4C342985.8010600@auckland.ac.nz>|Date:=20 Wed,=2007=20Jul=202010=2000:15:17=20-0700|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20list=20|CC:=20Benoit =20Claise=20|Subject:=20Re:=20[IPFIX] =20WG=20LC=20for=20two=20drafts|References:=20<4C311369.8 030409@auckland.ac.nz>=20<4C321018.1030501@cisco.com> |In-Reply-To:=20<4C321018.1030501@cisco.com> |Content-Transfer-Encoding:=207bit; bh=0/k9kjanA+DbKx5Nfs8MDBUJSAd8T8oXcpYDuwh7DKA=; b=pT+fRofRw5KkHRWtPKhMlyIpaH5FVlOpDbGrHMWsRdpG9Afzg6Y+0ksU DgGWXL8SKijhTiXo3n1wa6EBByOIo3vM5QaUWJojEAtP91Pcw07eTCMWy Nz/Ua5W73zSK1pXjkZSUbGDraaNwxx/za+taAH8wdYvYBc4Nxz4D+jnZ2 Y=; X-IronPort-AV: E=Sophos;i="4.53,551,1272801600"; d="scan'208";a="14231628" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 80.237.254.228 - Outgoing - Outgoing-SSL Received: from n80-237-254-228.cnet.hosteurope.de (HELO [192.168.44.58]) ([80.237.254.228]) by mx2-int.auckland.ac.nz with ESMTP; 07 Jul 2010 19:15:19 +1200 Message-ID: <4C342985.8010600@auckland.ac.nz> Date: Wed, 07 Jul 2010 00:15:17 -0700 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IPFIX list References: <4C311369.8030409@auckland.ac.nz> <4C321018.1030501@cisco.com> In-Reply-To: <4C321018.1030501@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] WG LC for two drafts 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, 07 Jul 2010 07:15:51 -0000 Hi all: Sorry, I called the WG LC for raft-ietf-ipfix-structured-data a little bit too soon (see note from Benoit below). WG LC for this now starts as soon as the -02 version is published. Cheers, Nevil Benoit Claise wrote: > Dear Nevil, > > Regarding draft-ietf-ipfix-structured-data-01.txt, we decided at the > last IETF meeting that we wanted to add the semantic field. > We are busy integrating it, and we will have a new version before the > deadline. > So could it be possible to postpone the WG Last Call by a week, when the > version 02 will be there? > > 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 nishida.haruhiko@lab.ntt.co.jp Wed Jul 7 00:27:46 2010 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 93B543A67CC for ; Wed, 7 Jul 2010 00:27:46 -0700 (PDT) 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=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 TjggpPTQFNRz for ; Wed, 7 Jul 2010 00:27:45 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id 5EBA73A6767 for ; Wed, 7 Jul 2010 00:27:45 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.4/8.14.4) with ESMTP id o677Regn014708; Wed, 7 Jul 2010 16:27:40 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id AEFAB65FD; Wed, 7 Jul 2010 16:27:40 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 8B68965F3; Wed, 7 Jul 2010 16:27:40 +0900 (JST) Received: from [129.60.149.196] ([129.60.149.196]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id o677ReJF014477; Wed, 7 Jul 2010 16:27:40 +0900 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nishida Haruhiko In-Reply-To: <4C3118F0.7060700@auckland.ac.nz> Date: Wed, 7 Jul 2010 16:27:40 +0900 Content-Transfer-Encoding: 7bit Message-Id: <611B0106-F474-406F-A3D0-410F1971630D@lab.ntt.co.jp> References: <4C3118F0.7060700@auckland.ac.nz> To: Nevil Brownlee X-Mailer: Apple Mail (2.1081) Cc: IPFIX list Subject: Re: [IPFIX] ***DRAFT*** Agenda for Maastricht 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, 07 Jul 2010 07:27:46 -0000 Nevil, On draft-ietf-ipfix-mediators-framework. Atsushi cannot attend the meeting but I and Kashima-san will. Atsushi will edit the draft (for comments during WG Last Call), and I will talk with Benoit who should have a presentation in Maastricht. Please keep the current time slot for the draft. -- Haruhiko Nishida, NTT On 2010/07/05, at 8:27, Nevil Brownlee wrote: > > Hi all: > > Here's my first draft agenda; if you have material, e.g. new drafts, > you want discussed, please email me to request that. > > As another thing to think about, the IPFIX Standards are mostly > Proposed Standards. 5101, 5102 and 5103 were published in 2008, > should we be asking for them to become Ingternet Standards? > > To do that we need to demonstrate that there are inter-operating > implementations. To help me assess that, would everyone who has > an implementation please email me (either on or off-list) with > some brief details of it, particularly the date it was first used, > and an estimate of how many sites are using it? > > Cheers, 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 > > > ====================================================== > Ip Flow Information Export WG (ipfix) > IETF #78, Maastricht > Thursday, 29 July, 1300-1500, Berlin room > ====================================================== > > Chairs: > Juergen Quittek > Nevil Brownlee > > AGENDA: > > 1. Agenda review WG Status = 5 min > > 2. Update from last meeting = 5 min > Errata 2052 et al > Mediators Problem Statement - in RFC Editor queue > > 3. Current WG drafts = 65 min > a) Config Data Model > draft-ietf-ipfix-configuration-model-05, 8 Mar 10 > > b) SCTP per-stream draft (Benoit Claise) > draft-ietf-ipfix-export-per-sctp-stream-06, 19 Nov 09 > Currently with IESG > > d) Mediators Framework (Atsushi Kobayashi) > draft-ietf-ipfix-mediators-framework-06, 20 Apr 10 > Ready for IETF LC > > e) IP Flow Anonymisation Support (Elisa Boschi) > draft-ietf-ipfix-anon-02, 15 Feb 10 > Ready for IETF LC > > f) Flow Selection Techniques (Tanja Zseby) > draft-ietf-ipfix-flow-selection-tech-02, 1 Jun 10 > (Peluso, Zseby. D'Antonio & Molina) > WG LC started > > g) Export of Structured Data in IPFIX (Benoit Claise) > draft-ietf-ipfix-structured-data-01, 8 Mar 10 > (Claise, Dhandapani, Yates & Aitken) > WG LC started > > h) PSAMP MIB (Benoit Claise) [earlier draft from PSAMP WG] > draft-ietf-ipfix-psamp-mib-00.txt, 2 Mar 10 > > > 4. Other drafts = 40 min > ?? > > > 5. Any Other Business = 5 min > - Milestones Review > > Presentation slides will be available at > https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=78 > (search for IPFIX in the Operations and Management Area) > > Participation via jabber is offered at ipfix@jabber.ietf.org > > ------------------ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From root@core3.amsl.com Fri Jul 9 07:00:03 2010 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 007E13A69FC; Fri, 9 Jul 2010 07:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100709140003.007E13A69FC@core3.amsl.com> Date: Fri, 9 Jul 2010 07:00:02 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-configuration-model-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: Fri, 09 Jul 2010 14:00: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 : Configuration Data Model for IPFIX and PSAMP Author(s) : G. Muenz, et al. Filename : draft-ietf-ipfix-configuration-model-06.txt Pages : 112 Date : 2010-07-09 This document specifies a data model for the configuration of Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX and PSAMP compliant Monitoring Devices using UML (Unified Modeling Language) class diagrams. The configuration data is encoded in Extensible Markup Language (XML). The structure of the data model is specified in a YANG module to ensure compatibility with the NETCONF protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-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-configuration-model-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-09064555.I-D@ietf.org> --NextPart-- From bclaise@cisco.com Fri Jul 9 13:14:52 2010 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 C3D673A68AE for ; Fri, 9 Jul 2010 13:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 fSuZQNReBoox for ; Fri, 9 Jul 2010 13:14:52 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 96FCF3A6802 for ; Fri, 9 Jul 2010 13:14:51 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o69KB5pi007721; Fri, 9 Jul 2010 22:11:05 +0200 (CEST) Received: from [10.21.145.253] (sjc-vpn7-509.cisco.com [10.21.145.253]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o69KB1Q6007494; Fri, 9 Jul 2010 22:11:02 +0200 (CEST) Message-ID: <4C378255.4050607@cisco.com> Date: Fri, 09 Jul 2010 13:11:01 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Nevil Brownlee References: <4C311369.8030409@auckland.ac.nz> <4C321018.1030501@cisco.com> In-Reply-To: <4C321018.1030501@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX list Subject: Re: [IPFIX] WG LC for two drafts 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, 09 Jul 2010 20:14:52 -0000 Dear Nevil, The next version of the IPFIX structured data draft has been posted. Currently in staging state. So while waiting for the draft version 2 to appear at http://tools.ietf.org/html/draft-ietf-ipfix-structured-data-01 (2 business days), you can access it at http://www.ietf.org/staging/draft-ietf-ipfix-structured-data-02.txt So, according to your last message on the topic, the WG Last -call can start now. Regards, Benoit. > Dear Nevil, > > Regarding draft-ietf-ipfix-structured-data-01.txt, we decided at the > last IETF meeting that we wanted to add the semantic field. > We are busy integrating it, and we will have a new version before the > deadline. > So could it be possible to postpone the WG Last Call by a week, when > the version 02 will be there? > > Regards, Benoit >> Hi all: >> >> The two drafts >> - Export of Structured Data in IPFIX >> draft-ietf-ipfix-structured-data-01.txt >> - Flow Selection Techniques >> draft-ietf-ipfix-flow-selection-tech-02.txt >> appear to represent our current consensus. >> >> This email starts their WG Last Call, it will end just before >> the IPFIX meeting at the Maastricht IETF meeting. >> >> Cheers, Nevil >> > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From root@core3.amsl.com Sat Jul 10 21:30:17 2010 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 006513A6816; Sat, 10 Jul 2010 21:30:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100711043013.006513A6816@core3.amsl.com> Date: Sat, 10 Jul 2010 21:30:03 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-framework-07.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: Sun, 11 Jul 2010 04:30:18 -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 : IPFIX Mediation: Framework Author(s) : A. Kobayashi, et al. Filename : draft-ietf-ipfix-mediators-framework-07.txt Pages : 34 Date : 2010-07-10 This document describes a framework for IPFIX Mediation. This framework extends the IPFIX reference model by defining the IPFIX Mediator components. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-framework-07.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-mediators-framework-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-10211559.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 12 10:00:01 2010 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B2D7C3A69C2; Mon, 12 Jul 2010 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712170001.B2D7C3A69C2@core3.amsl.com> Date: Mon, 12 Jul 2010 10:00:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-structured-data-02.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, 12 Jul 2010 17:00:01 -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 : Export of Structured Data in IPFIX Author(s) : B. Claise, G. Dhandapani, S. Yates, P. Aitken Filename : draft-ietf-ipfix-structured-data-02.txt Pages : 72 Date : 2010-7-10 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-structured-data-02.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-structured-data-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-7-12095614.I-D@ietf.org> --NextPart-- From n.brownlee@auckland.ac.nz Wed Jul 14 02:02:11 2010 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 30FAD3A69EB for ; Wed, 14 Jul 2010 02:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.416 X-Spam-Level: X-Spam-Status: No, score=-0.416 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_50=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 PKZmgflIU7wx for ; Wed, 14 Jul 2010 02:02:08 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 2B5783A69FB for ; Wed, 14 Jul 2010 02:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1279098137; x=1310634137; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4C3D7D11.5080607@auckland.ac.nz>|Date:=20 Wed,=2014=20Jul=202010=2002:02:09=20-0700|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20list=20|Subject:=20[ Fwd:=20[IEEE=20CNOM]=20Call=20for=20Participation:=203rd =20NMRG=20Workshop=20on=20Netflow/IPFIX=0D=0A=20Usage=20i n=20Network=20Management]|Content-Transfer-Encoding:=207b it; bh=ani8xGrmq3fRXqLkQs7x+N4ZsDWMrRoFcy1hJtu77Z4=; b=HIbWBQBz8gB94ptQoxX8cTAf1vvSU/t98nGiUwnrxqRSkPyfBWk/w4OP 61Orsi8e0tUb0j0Ba0X3hNqotwrfjZxEl4T/+NdRi+iTiMaE+uJzodRJv Sx50E2LsCh/3kilODBAD/+YoWcIujxXcazzcBsBxYOUrdqIXhbyT8TibL U=; X-IronPort-AV: E=Sophos;i="4.55,201,1278244800"; d="scan'208";a="15509139" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 84.86.11.124 - Outgoing - Outgoing-SSL Received: from ip54560b7c.speed.planet.nl (HELO [192.168.2.5]) ([84.86.11.124]) by mx2-int.auckland.ac.nz with ESMTP; 14 Jul 2010 21:02:14 +1200 Message-ID: <4C3D7D11.5080607@auckland.ac.nz> Date: Wed, 14 Jul 2010 02:02:09 -0700 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] [Fwd: [IEEE CNOM] Call for Participation: 3rd NMRG Workshop on Netflow/IPFIX Usage in Network Management] 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, 14 Jul 2010 09:02:11 -0000 Hi all: I'm forwarding this notice, just in case you weren't aware of this meeting on the Friday of IETF week ... Cheers, Nevil -------- Original Message -------- Subject: [IEEE CNOM] Call for Participation: 3rd NMRG Workshop on Netflow/IPFIX Usage in Network Management Date: Mon, 12 Jul 2010 23:36:23 +1200 From: Ramin Sadre Reply-To: IEEE COMSOC Committee on Network Operation and Management To: cnom@inf.ufsc.br Call for Participation 3rd NMRG Workshop on Netflow/IPFIX Usage in Network Management July 30, 2010, Maastricht, The Netherlands (Friday, last day of the 78th IETF meeting in Maastricht) Flow-based approaches are used in various areas of network management today, such as link monitoring, accounting, and security. As in the previous years, the goal of this workshop is to be a place where researchers, operators and manufacturers can exchange and discuss their experiences and ideas on the usage of Netflow/IPFIX in network management. Venue: This IRTF-NMRG workshop is part of the 78th IETF meeting in the MECC conference center in Maastricht (NL). Detailed information on the meeting agenda and the venue can be found here: http://www.ietf78.nl/home.html https://datatracker.ietf.org/meeting/78/agenda.html More specifically, the workshop will take place in room "0.8 Rome". Registration: Participants have to register to the IETF meeting: http://www.ietf.org/meeting/register.html Please note the early-bird deadline on July 16 and the special fees for one-day participants and students. In addition, if not already done so, participants should send a notification mail to: Ramin Sadre, sadrer@ewi.utwente.nl Draft workshop agenda: 09:00 Opening 09:10 Using of time characteristic in Netflow data for improvement of protocol detection Jiri Novotny, Masaryk University/INVEA-TECH Flow signatures of popular applications Nikolay Melnikov, Jacobs University Bremen IPTV Traffic Monitoring System with IPFIX/PSAMP Shingo Kashima, NTT 10:25 Short break 10:40 Presentation title tba Benoit Claise, Cisco A Labeled Data Set For Flow-based Intrusion Detection Anna Sperotto, University of Twente 11:30 Lunch break 13:00 Malware Detection From The Network Perspective Using NetFlow Data Pavel Celeda, Masaryk University Characterization of accuracy problems in NetFlow data and approaches to handle them Jochen Koegel, University of Stuttgart 14:00 Coffee break 14:15 ripfix: Rapid Prototyping and Debugging of IPFIX Applications in Ruby Brian Trammell, ETH Zurich The Tranalyzer and Traviz tools Stefan Burschka, Swisscom/CSIT The trace2netFlow tool Lucjan Janowski, AGH Poland 15:15 End On behalf of the workshop chairs Ramin Sadre (University of Twente) Aiko Pras (University of Twente) _______________________________________________ cnom mailing list cnom@inf.ufsc.br http://listas.inf.ufsc.br/mailman/listinfo/cnom -- --------------------------------------------------------------------- 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 n.brownlee@auckland.ac.nz Wed Jul 14 02:16:18 2010 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 275393A69FB; Wed, 14 Jul 2010 02:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.657 X-Spam-Level: X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[AWL=0.942, 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 TGiv-m8mjBQO; Wed, 14 Jul 2010 02:16:16 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 7DCBF3A68B6; Wed, 14 Jul 2010 02:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1279098986; x=1310634986; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4C3D8065.5070402@auckland.ac.nz>|Date:=20 Wed,=2014=20Jul=202010=2002:16:21=20-0700|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20list=20,=20=0D=0A=20 "ipfix-chairs@ietf.org"=20 |Subject:=20Maastricht=20Agenda,=20-01 |Content-Transfer-Encoding:=207bit; bh=x/bhxciqs9QO0oMpLxEvCg0CsyL3zH6VW3WLeIPbFW0=; b=Cfyip9cTwmiskJ3WGPUXypBvxYX/WgD6/ksDEQK7pFs1vGIUCDtqZH9P nOOJpeKK+w+bqJXdQLUU0FywNK8BJngbYJmDNZYHp1Zc1jRYc7OxPic6n KAhQJejrbc06yCFJV9gQrgleeFW1koiUjc8X97n0l1kCwUUeBXxPZljJm 8=; X-IronPort-AV: E=Sophos;i="4.55,201,1278244800"; d="scan'208";a="15509747" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 84.86.11.124 - Outgoing - Outgoing-SSL Received: from ip54560b7c.speed.planet.nl (HELO [192.168.2.5]) ([84.86.11.124]) by mx2-int.auckland.ac.nz with ESMTP; 14 Jul 2010 21:16:24 +1200 Message-ID: <4C3D8065.5070402@auckland.ac.nz> Date: Wed, 14 Jul 2010 02:16:21 -0700 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IPFIX list , "ipfix-chairs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Maastricht Agenda, -01 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, 14 Jul 2010 09:16:18 -0000 Hi all: Thanks for all the update requests, here's the next draft of the agenda. If you're presenting, please don't forget to email your slides to ipfix-chairs@tools.ietf.org so that we can get them onto the Meeting Materials page before the meeting! Cheers, 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 ====================================================== Ip Flow Information Export WG (ipfix) IETF #78, Maastricht Thursday, 29 July, 1300-1500, Berlin room ====================================================== Chairs: Juergen Quittek Nevil Brownlee AGENDA: 1. Agenda review WG Status = 5 min 2. Update from last meeting = 10 min Errata 2052 et al Mediators Problem Statement - in RFC Editor queue 3. Current WG drafts = 50 min a) Config Data Model draft-ietf-ipfix-configuration-model-06, 8 Jul 10 b) SCTP per-stream draft (Benoit Claise) draft-ietf-ipfix-export-per-sctp-stream-08, 31 May 09 Currently with IESG d) Mediators Framework (Haruhiko Nishida) draft-ietf-ipfix-mediators-framework-07, 11 Jul 10 Ready for IETF LC e) IP Flow Anonymisation Support (Elisa Boschi) draft-ietf-ipfix-anon-03, 22 Apr 10 Ready for IETF LC f) Flow Selection Techniques (Tanja Zseby) draft-ietf-ipfix-flow-selection-tech-02, 1 Jun 10 (Peluso, Zseby. D'Antonio & Molina) WG LC started 4 Jul 10 g) Export of Structured Data in IPFIX (Benoit Claise) draft-ietf-ipfix-structured-data-02, (Claise, Dhandapani, Yates & Aitken) WG LC started 9 Jul 10 h) PSAMP MIB (Benoit Claise) [earlier draft from PSAMP WG] draft-ietf-ipfix-psamp-mib-00.txt, 1 Mar 10 4. Other drafts = 40 min a) Exporting Aggregated Flow Data using the IPFIX Protocol (Brian Trammell) draft-trammell-ipfix-a8n-00.txt, 5 Jul 10 b) A Lightweight Textual Format for IPFIX Information Models and Templates (Brian Trammell) draft-trammell-ipfix-text-iespec-00.txt, 16 Apr 10 c) Information Elements for Data Link Layer Traffic Measurement (Shingo Kashima) draft-kashima-ipfix-data-link-layer-monitoring-03, 12 Jul 10 5. Any Other Business = 15 min - Milestones Review Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=78 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org ------------------ From wwwrun@core3.amsl.com Thu Jul 15 07:24:35 2010 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id C05543A6A3C; Thu, 15 Jul 2010 07:24:35 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100715142435.C05543A6A3C@core3.amsl.com> Date: Thu, 15 Jul 2010 07:24:35 -0700 (PDT) Cc: Internet Architecture Board , ipfix chair , ipfix mailing list , RFC Editor Subject: [IPFIX] Protocol Action: 'IPFIX Export per SCTP Stream' to Proposed Standard 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, 15 Jul 2010 14:24:36 -0000 The IESG has approved the following document: - 'IPFIX Export per SCTP Stream ' as a Proposed Standard This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-export-per-sctp-stream-08.txt Technical Summary This document specifies an improvement to the PR-SCTP export specified in the IPFIX specifications in RFC5101. This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process. Working Group Summary This work was motivated by experiences made with early IPFIX implementations. It was accepted with consensus as WG work item and progressed within the WG. WG last call was conducted in August 2008. Modifications based on received comments were applied until November 2008. No more issues were brought up since then and at the IETF meeting in March 2009 the WG confirmed at the session that the document is ready for requesting publication. Document Quality IPFIX is implemented and deployed and this work is based on deployment experience. The document underwent several reviews and a WG last call in the IPFIX WG. This way, a high document quality has been achieved already. Personnel Juergen Quittek is shepherding this document. Dan Romascanu is the responsible Area Director. From bclaise@cisco.com Fri Jul 16 00:49:54 2010 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 CF6E33A6922; Fri, 16 Jul 2010 00:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, SARE_SUB_6CONS_WORD=0.356] 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 M6cM1D8aKXVU; Fri, 16 Jul 2010 00:49:51 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id A34153A68AF; Fri, 16 Jul 2010 00:49:50 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o6G7g1M2019898; Fri, 16 Jul 2010 09:42:01 +0200 (CEST) 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 o6G7g09p019804; Fri, 16 Jul 2010 09:42:00 +0200 (CEST) Message-ID: <4C400D48.9080900@cisco.com> Date: Fri, 16 Jul 2010 09:42:00 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Peter Lei (peterlei)" , Michael Tuexen , rstewart@huawei.com, tsvwg@ietf.org, James Polk , gorry@erg.abdn.ac.uk Content-Type: multipart/alternative; boundary="------------020504090805090108040803" Cc: "ipfix@ietf.org" Subject: [IPFIX] Status of draft-ietf-tsvwg-sctp-strrst-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: Fri, 16 Jul 2010 07:49:54 -0000 This is a multi-part message in MIME format. --------------020504090805090108040803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I'm not following closely this mailing list, so excuse my ignorance. What is the status of draft-ietf-tsvwg-sctp-strrst-04.txt? We have an IPFIX draft in the RFC-editor queue wait for its publication... Regards, Benoit. -------- Original Message -------- Subject: [RFC State] has changed state Date: Thu, 15 Jul 2010 14:53:08 -0700 (PDT) From: rfc-editor@rfc-editor.org To: bclaise@cisco.com, paitken@cisco.com, andrjohn@cisco.com, muenz@net.in.tum.de CC: ipfix-ads@tools.ietf.org, ipfix-chairs@tools.ietf.org, rfc-editor@rfc-editor.org The document draft-ietf-ipfix-export-per-sctp-stream-08 has changed from MISSREF*A*R state to MISSREF*R state. We thought you'd like to know. You can check on your document's status at . See below for more information on the names of queue states. Best regards, The RFC Editor Team Queue State Names ----------------- AUTH = Awaiting Author Action AUTH48 = Awaiting final author approval EDIT = Approved by IESG, awaiting processing and publishing, no "APPR" note means that it was approved on date received IANA = RFC-Editor/IANA Registration Coordination IESG = Holding for IESG Action ISR = Independent Submission Review by the RFC Editor ISR-AUTH = Independent Submission awaiting author update, or in discussion between author and RFC Editor REF = Holding for normative reference RFC-EDITOR = Awaiting final rfc-editor review before AUTH48 TO = Time-out period during which the IESG reviews document for conflict/concurrence with other IETF working group work MISSREF = Awaiting missing normative reference. Note: *A = IANA Actions required *R = Potential REF hold --------------020504090805090108040803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

I'm not following closely this mailing list, so excuse my ignorance.
What is the status of draft-ietf-tsvwg-sctp-strrst-04.txt?
We have an IPFIX draft in the RFC-editor queue wait for its publication...

Regards, Benoit.
-------- Original Message --------
Subject: [RFC State] has changed state
Date: Thu, 15 Jul 2010 14:53:08 -0700 (PDT)
From: rfc-editor@rfc-editor.org
To: bclaise@cisco.com, paitken@cisco.com, andrjohn@cisco.com, muenz@net.in.tum.de
CC: ipfix-ads@tools.ietf.org, ipfix-chairs@tools.ietf.org, rfc-editor@rfc-editor.org 


The document draft-ietf-ipfix-export-per-sctp-stream-08 has 
changed from MISSREF*A*R state to MISSREF*R state. We thought you'd like to know. 
You can check on your document's status at
<http://www.rfc-editor.org/queue2.html#draft-ietf-ipfix-export-per-sctp-stream>.
See below for more information on the names of queue states.

Best regards,
The RFC Editor Team


Queue State Names
-----------------

AUTH = Awaiting Author Action
AUTH48 = Awaiting final author approval
EDIT = Approved by IESG, awaiting processing and publishing,
       no "APPR" note means that it was approved on date received
IANA = RFC-Editor/IANA Registration Coordination
IESG = Holding for IESG Action
ISR = Independent Submission Review by the RFC Editor
ISR-AUTH = Independent Submission awaiting author update,
           or in discussion between author and RFC Editor
REF = Holding for normative reference
RFC-EDITOR = Awaiting final rfc-editor review before AUTH48
TO = Time-out period during which the IESG reviews document for
     conflict/concurrence with other IETF working group work
MISSREF = Awaiting missing normative reference.

Note: *A = IANA Actions required
      *R = Potential REF hold
--------------020504090805090108040803-- From tuexen@fh-muenster.de Fri Jul 16 03:08:37 2010 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 877F23A6874; Fri, 16 Jul 2010 03:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_71=0.6, RDNS_NONE=0.1, SARE_SUB_6CONS_WORD=0.356] 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 rfHRfGmvETTU; Fri, 16 Jul 2010 03:08:36 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 6506A3A6816; Fri, 16 Jul 2010 03:08:31 -0700 (PDT) Received: from [10.0.1.103] (unknown [212.201.121.94]) by mail-n.franken.de (Postfix) with ESMTP id 953C91C0C0BD4; Fri, 16 Jul 2010 12:08:41 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <4C400D48.9080900@cisco.com> Date: Fri, 16 Jul 2010 12:10:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C400D48.9080900@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1081) Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, "ipfix@ietf.org" , "Peter Lei \(peterlei\)" , James Polk , rstewart@huawei.com Subject: Re: [IPFIX] Status of draft-ietf-tsvwg-sctp-strrst-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: Fri, 16 Jul 2010 10:08:37 -0000 On Jul 16, 2010, at 9:42 AM, Benoit Claise wrote: > Dear all, >=20 > I'm not following closely this mailing list, so excuse my ignorance. > What is the status of draft-ietf-tsvwg-sctp-strrst-04.txt?=20 > We have an IPFIX draft in the RFC-editor queue wait for its = publication... Hi Benoit, it is ready for WG LC from our side, however, the WGLC has not happened = yet... Gorry? Best regards Michael >=20 > Regards, Benoit. > -------- Original Message -------- > Subject: [RFC State] has changed state > Date: Thu, 15 Jul 2010 14:53:08 -0700 (PDT) > From: rfc-editor@rfc-editor.org > To: bclaise@cisco.com, paitken@cisco.com, andrjohn@cisco.com, = muenz@net.in.tum.de > CC: ipfix-ads@tools.ietf.org, ipfix-chairs@tools.ietf.org, = rfc-editor@rfc-editor.org >=20 > The document draft-ietf-ipfix-export-per-sctp-stream-08 has=20 > changed from MISSREF*A*R state to MISSREF*R state. We thought you'd = like to know.=20 > You can check on your document's status at >=20 > = > . > See below for more information on the names of queue states. >=20 > Best regards, > The RFC Editor Team >=20 >=20 > Queue State Names > ----------------- >=20 > AUTH =3D Awaiting Author Action > AUTH48 =3D Awaiting final author approval > EDIT =3D Approved by IESG, awaiting processing and publishing, > no "APPR" note means that it was approved on date received > IANA =3D RFC-Editor/IANA Registration Coordination > IESG =3D Holding for IESG Action > ISR =3D Independent Submission Review by the RFC Editor > ISR-AUTH =3D Independent Submission awaiting author update, > or in discussion between author and RFC Editor > REF =3D Holding for normative reference > RFC-EDITOR =3D Awaiting final rfc-editor review before AUTH48 > TO =3D Time-out period during which the IESG reviews document for > conflict/concurrence with other IETF working group work > MISSREF =3D Awaiting missing normative reference. >=20 > Note: *A =3D IANA Actions required > *R =3D Potential REF hold >=20 From randall@lakerest.net Fri Jul 16 06:41:46 2010 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 E3ACC3A6A0B for ; Fri, 16 Jul 2010 06:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_71=0.6, SARE_SUB_6CONS_WORD=0.356] 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 4OagEhhqwWoQ for ; Fri, 16 Jul 2010 06:41:45 -0700 (PDT) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by core3.amsl.com (Postfix) with ESMTP id B05883A6A21 for ; Fri, 16 Jul 2010 06:41:44 -0700 (PDT) Received: from mobile-166-129-165-211.mycingular.net (mobile-166-129-165-211.mycingular.net [166.129.165.211] (may be forged)) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o6GDfet3043899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 16 Jul 2010 09:41:47 -0400 (EDT) (envelope-from randall@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1279287713; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=jPkQ+GSix+bvY6PtXbrIWccm0Q3NY2LiOqF9FZjjnnW8T/+owTlcFMo lZjk2z7gYLBB7Y8sOyEFaUKGJpLl0/A== Message-Id: <482C3176-90A0-4A70-8FEA-BC8684B41B25@lakerest.net> From: Randy Stewart To: Benoit Claise In-Reply-To: <4C400D48.9080900@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Jul 2010 06:41:33 -0700 References: <4C400D48.9080900@cisco.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Fri, 16 Jul 2010 06:59:32 -0700 Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, "ipfix@ietf.org" , Michael Tuexen , "Peter Lei \(peterlei\)" , James Polk , rstewart@huawei.com Subject: Re: [IPFIX] Status of draft-ietf-tsvwg-sctp-strrst-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: Fri, 16 Jul 2010 13:41:47 -0000 Michael and I have said as far as we are concerned it is finished... ready for last call... but I have heard nothing else since we made that statement.. R On Jul 16, 2010, at 12:42 AM, Benoit Claise wrote: > Dear all, > > I'm not following closely this mailing list, so excuse my ignorance. > What is the status of draft-ietf-tsvwg-sctp-strrst-04.txt? > We have an IPFIX draft in the RFC-editor queue wait for its > publication... > > Regards, Benoit. > -------- Original Message -------- > Subject: > [RFC State] has changed state > Date: > Thu, 15 Jul 2010 14:53:08 -0700 (PDT) > From: > rfc-editor@rfc-editor.org > To: > bclaise@cisco.com, paitken@cisco.com, andrjohn@cisco.com, muenz@net.in.tum.de > CC: > ipfix-ads@tools.ietf.org, ipfix-chairs@tools.ietf.org, rfc-editor@rfc-editor.org > > > The document draft-ietf-ipfix-export-per-sctp-stream-08 has > changed from MISSREF*A*R state to MISSREF*R state. We thought you'd > like to know. > You can check on your document's status at > >. > See below for more information on the names of queue states. > > Best regards, > The RFC Editor Team > > > Queue State Names > ----------------- > > AUTH = Awaiting Author Action > AUTH48 = Awaiting final author approval > EDIT = Approved by IESG, awaiting processing and publishing, > no "APPR" note means that it was approved on date received > IANA = RFC-Editor/IANA Registration Coordination > IESG = Holding for IESG Action > ISR = Independent Submission Review by the RFC Editor > ISR-AUTH = Independent Submission awaiting author update, > or in discussion between author and RFC Editor > REF = Holding for normative reference > RFC-EDITOR = Awaiting final rfc-editor review before AUTH48 > TO = Time-out period during which the IESG reviews document for > conflict/concurrence with other IETF working group work > MISSREF = Awaiting missing normative reference. > > Note: *A = IANA Actions required > *R = Potential REF hold ----- Randall Stewart randall@lakerest.net From salvatore.dantonio@uniparthenope.it Sun Jul 18 14:27:05 2010 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 5DEFC3A6848 for ; Sun, 18 Jul 2010 14:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.881 X-Spam-Level: * X-Spam-Status: No, score=1.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 RpNV0s03XE07 for ; Sun, 18 Jul 2010 14:27:04 -0700 (PDT) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by core3.amsl.com (Postfix) with ESMTP id 783503A67D9 for ; Sun, 18 Jul 2010 14:27:04 -0700 (PDT) Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id B6D57E1C4 for ; Sun, 18 Jul 2010 21:27:06 +0000 (UTC) Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 5792_3720705c_92b3_11df_9c95_001372515a5c; Sun, 18 Jul 2010 23:27:06 +0200 Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id 6381CC4321 for ; Sun, 18 Jul 2010 23:27:06 +0200 (CEST) Received: by spamk.uniparthenope.it (Postfix, from userid 500) id 5F662C432C; Sun, 18 Jul 2010 23:27:06 +0200 (CEST) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by spamk.uniparthenope.it (Postfix) with ESMTP id 30139C4321 for ; Sun, 18 Jul 2010 23:27:05 +0200 (CEST) Received: from webmail.uniparthenope.it (webmail.uniparthenope.it [192.167.9.147]) by mail.uniparthenope.it (Postfix) with ESMTP id 47804E1C4 for ; Sun, 18 Jul 2010 23:27:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by webmail.uniparthenope.it (Postfix) with ESMTP id 6C4AA1AC047 for ; Sun, 18 Jul 2010 23:28:40 +0200 (CEST) Received: from 109.115.43.208 ([109.115.43.208]) by webmail.uniparthenope.it (Horde Framework) with HTTP; Sun, 18 Jul 2010 23:28:40 +0200 Date: Sun, 18 Jul 2010 23:28:40 +0200 From: salvatore.dantonio@uniparthenope.it To: ipfix@ietf.org MIME-Version: 1.0 User-Agent: Internet Messaging Program (IMP) H3 (4.2) Message-ID: <20100718232840.16472txxi60c6vpk@webmail.uniparthenope.it> Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20100718 #4231423, check: 20100718 clean Subject: [IPFIX] Internet Draft on flow selection techniques 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, 18 Jul 2010 21:27:05 -0000 Dear IPFIXers, we have not received any feedback yet on the latest version of the draft on flow selection techniques. We would greatly appreciate if you could provide us with your comments so that we may discuss them during the Maastricht meeting. Thanks in advance. Best regards, Salvatore, Lorenzo and Tanja ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From akoba@nttv6.net Mon Jul 19 14:32:04 2010 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 064CA3A6A00 for ; Mon, 19 Jul 2010 14:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 lP8dDs2MmVwy for ; Mon, 19 Jul 2010 14:32:00 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 67B6D3A696F for ; Mon, 19 Jul 2010 14:31:59 -0700 (PDT) Received: from [192.168.1.4] (mail.nttv6.net [IPv6:2001:fa8::25]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id o6JLWC1i013472 for ; Tue, 20 Jul 2010 06:32:12 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 20 Jul 2010 06:32:14 +0900 From: Kobayashi Atsushi To: ipfix@ietf.org In-Reply-To: <20100711043013.006513A6816@core3.amsl.com> References: <20100711043013.006513A6816@core3.amsl.com> Message-Id: <20100720063214.5C9C.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.53 [ja] (Evaluation) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Tue, 20 Jul 2010 06:32:12 +0900 (JST) Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-framework-07.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, 19 Jul 2010 21:32:04 -0000 Dear all, In IPFIX Mediation Framework draft, WG LC was lasted from May 17 to June 1. Before last call, Brian proposed entire security consideration section according to discussion in last IETF. It was improved entirely. I already included his proposal in latest version. Thank you, Brian. During WG LC, Christoph listed his comments in ML. I improved relevant section in latest version. If you have any feedback, let me know. Regards, Atsushi On Sat, 10 Jul 2010 21:30:03 -0700 (PDT) Internet-Drafts@ietf.org wrote: > 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 : IPFIX Mediation: Framework > Author(s) : A. Kobayashi, et al. > Filename : draft-ietf-ipfix-mediators-framework-07.txt > Pages : 34 > Date : 2010-07-10 > > This document describes a framework for IPFIX Mediation. This > framework extends the IPFIX reference model by defining the IPFIX > Mediator components. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-framework-07.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. --- Atsushi KOBAYASHI From rahulp@cisco.com Thu Jul 22 08:33:56 2010 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 031723A6BE3 for ; Thu, 22 Jul 2010 08:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 vlBYr0DN4g7H for ; Thu, 22 Jul 2010 08:33:51 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2F5A53A6BF1 for ; Thu, 22 Jul 2010 08:33:48 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAIwBSEytJV2c/2dsb2JhbACBRJ4ucaZJmyOFNgSEAIcS Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2010 15:34:05 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o6MFY4qI009344 for ; Thu, 22 Jul 2010 15:34:04 GMT Received: from xmb-rcd-213.cisco.com ([72.163.62.220]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 10:34:04 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB29B3.50FED928" Date: Thu, 22 Jul 2010 10:34:00 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG LC for IPFIX structured data Thread-Index: AcsnWfCGvZR1/ZGFRZyTDMAeJHjZvgCWVHmA From: "Rahul Patel (rahulp)" To: X-OriginalArrivalTime: 22 Jul 2010 15:34:04.0897 (UTC) FILETIME=[513C1D10:01CB29B3] Subject: [IPFIX] WG LC for IPFIX structured data 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, 22 Jul 2010 15:33:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB29B3.50FED928 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Resending it. =20 -Rahul =20 From: Rahul Patel (rahulp)=20 Sent: Monday, July 19, 2010 11:49 AM To: 'ipfix@ietf.org' Subject: WG LC for IPFIX structured data =20 Few comments on Rev2 =20 comment #1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Page 45-46: " Selection Sequence 7 (Filter->Sampling): =20 observation point: subTemplateMultiList. =20 Router 1, (interface 1) =20 Router 2, (line card A) =20 Router 3, (line card B)=20 Router 4, (line card C, interface 2) =20 selectorId: 5 (Filter, match IPV4SourceAddress 192.0.2.1) =20 selectorId: 10 (Sampler, Random 1 out-of ten)=20 =20 The following Templates are defined to represent the PSAMP SSRI:=20 Template for representing PSAMP SSRI: 262=20 Template for representing interface: 263=20 " =20 Rahul# Wouldn't it be better to include RouterID in addition to=20 Interface and/or linecard in the example. Without router id interface has no meaning unless interfaces are unique across routers which is=20 unlikely. =20 =20 comment #2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Page 46 " Note that the Data Record above contains multiple instances of=20 Template 264 to represent Observation Point 2 (line card A) and=20 Observation Point 3 (line card B). Instead, if a single=20 Observation Point had both line card A and line card B, a=20 basicList would be used to represent the list of line cards.=20 " =20 Rahul# There is an implicit assumption that each record belongs to a different router. That is why you would have to use basicList if line card A and line card B were to be on OB Point 2. =20 =20 Comment #3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Page 46 =20 =20 Rahul# In the same example (above), instead of 'allof" if "ordered" is used then does it imply that there is order in template 264 (line card A, line card B) even though it is just a regular template? =20 Comment #4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Page 16 " Another example is a router that monitors some specific BGP AS- PATHs and reports if a Flow belongs to any of them. If the router=20 wants to export that a Flow does not belong to any of the=20 monitored BGP AS-PATHs, the router reports a Data Record with a=20 basicList composed of (BGP AS-PATH 1, BGP AS-PATH 2, BGP AS-PATH=20 3) and the respective Structured Data type semantic of "noneOf". " =20 Rahul# If there are many flows which are exported with "noneOf" then that would not be efficient because each flow is carring path1, path2 and path3. Can you do following? How? =20 List of flows that didn't match monitored AS paths -> AS_PATH { path1, path2, path3} -> Flows - Flow1 - Flow2 - Flow3 - Flow4 =20 -Rahul ------_=_NextPart_001_01CB29B3.50FED928 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Resending it.

 

-Rahul

 

From:= = Rahul Patel (rahulp)
Sent: Monday, July 19, 2010 11:49 = AM
To: 'ipfix@ietf.org'
Subject: WG LC for IPFIX = structured data

 

Few comments on = Rev2

 

comment = #1:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Page 45-46:

"       Selection Sequence 7 = (Filter->Sampling): 

         observation = point: subTemplateMultiList. 

           &= nbsp;           &n= bsp;      Router 1, (interface 1)  =

           &= nbsp;           &n= bsp;      Router 2, (line card A)  =

           &= nbsp;           &n= bsp;      Router 3, (line card B) =

           &= nbsp;           &n= bsp;      Router 4, (line card C, = interface 2) 

         selectorId: = 5 (Filter, match IPV4SourceAddress 192.0.2.1)  =

         selectorId: = 10 (Sampler, Random 1 out-of ten)

       

      The following Templates are = defined to represent the PSAMP SSRI:

      Template for representing = PSAMP SSRI: 262

      Template for representing = interface: 263

"

 

Rahul# Wouldn't it be better to = include RouterID in addition to

Interface = and/or linecard in the example. Without router id = interface

has no meaning unless interfaces are = unique across routers which is

unlikely.

 

 

comment #2

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Page 46

"      Note that the Data Record = above contains multiple instances of

      Template 264 to represent = Observation Point 2 (line card A) and

      Observation Point 3 (line card = B).  Instead, if a single

      Observation Point had both = line card A and line card B, a

      basicList would be used to = represent the list of line cards.

"

 

Rahul# There = is an implicit assumption that each record belongs to = a

different router. That is why you = would have to use basicList if line

card A and = line card B were to be on OB Point 2.

 

 

Comment = #3

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Page = 46

 

 

Rahul# In the same example (above), = instead of 'allof" if "ordered" = is

used then does it imply that there = is order in template 264 (line card A,

line card B) = even though it is just a regular template?

 

Comment #4

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Page = 16

“     = Another example is a router that monitors some specific BGP = AS-

     PATHs and = reports if a Flow belongs to any of them.  If the router =

     wants = to export that a Flow does not belong to any of the =

     monitored BGP AS-PATHs, the router = reports a Data Record with a

     basicList composed of (BGP AS-PATH = 1, BGP AS-PATH 2, BGP AS-PATH

     3) and the respective Structured = Data type semantic of "noneOf".

“

 

Rahul# If = there are many flows which are exported with “noneOf” then = that

would not be efficient because each = flow is carring path1, path2 and path3.

Can you do = following? How?

 

List of = flows that didn’t

match monitored AS paths -> = AS_PATH { path1, path2, path3}

           &= nbsp;            = -> Flows

           &= nbsp;           &n= bsp;       - Flow1

           &= nbsp;           &n= bsp;       - Flow2

           &= nbsp;           &n= bsp;       - Flow3

           &= nbsp;           &n= bsp;       - Flow4

 

-Rahul

------_=_NextPart_001_01CB29B3.50FED928-- From christoph.sommer@informatik.uni-erlangen.de Thu Jul 22 23:03:29 2010 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 E302F3A68A5 for ; Thu, 22 Jul 2010 23:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 QyFdjyVoE7VZ for ; Thu, 22 Jul 2010 23:03:15 -0700 (PDT) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id 688A13A6862 for ; Thu, 22 Jul 2010 23:03:08 -0700 (PDT) Received: from faui7as (faui7as.informatik.uni-erlangen.de [131.188.37.230]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id 96A4146E8 for ; Fri, 23 Jul 2010 08:03:22 +0200 (MEST) Received: from [192.168.1.98] (nrbg-d9320b09.pool.mediaWays.net [217.50.11.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui7as (Postfix) with ESMTPSA id 072728000F for ; Fri, 23 Jul 2010 08:03:21 +0200 (CEST) Message-ID: <4C4930A9.7090707@informatik.uni-erlangen.de> Date: Fri, 23 Jul 2010 08:03:21 +0200 From: Christoph Sommer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070504 Thunderbird/2.0.0.0 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: ipfix@ietf.org References: <20100712170001.B2D7C3A69C2@core3.amsl.com> In-Reply-To: <20100712170001.B2D7C3A69C2@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] I-D ACTION:draft-ietf-ipfix-structured-data-02.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: Fri, 23 Jul 2010 06:03:48 -0000 Benoit, all, as promised, here are some comments on draft-ietf-ipfix-structured-data-02: Section 4.5: > when representing variable-length data, hierarchical data, and > repeated data with variable element counts, we RECOMMEND these are > encoded as a Variable-Length Information Element The draft doesn't make very clear why this is recommended. It almost feels like the benefits of this are implementation specific... Section 5.6: > The Exporter SHOULD NOT check all semantically meaningless > combinations before exporting the Data Record. I didn't understand what is meant by this 'checking of combinations'. Is there a way to spell it out more clearly? Section 5.6: > in case of a single element in a Structured Data > Information Element, the default "undefined" semantic SHOULD be > used. Is this to promote a consistent encoding? I don't see any harm in using one of the other semantics - in fact, using the same semantic for the same field regardless of the number of encoded values should save both the exporter and data visualization tools some time. Also, there's an off chance that this recommendation might be misunderstood to imply that encoding one value with "noneOf" semantic should be done using "undefined", too :) Section 7: > If the Structured Data contains the "undefined" Structured Data > type semantic, the Collecting Process MAY attempt to draw its own > conclusion in terms of the semantic contained in the Data Record, > exactly as it would have done before the introduction of this > specification. Collectors that are unaware of this specification would never be able to make any sense of structured data BLOBs, would they? Section 8.4: > As explained in Section 4.4.3., a subTemplateMultiList is used that's section 4.1.3, no? Section 8.4: > Template for classification attributes: 259 > Template for sampling attributes: 260 > Template for Flow Record: 261 Here, like in other parts of the draft, the indentation is a bit off. It might be taken to imply that templates 260 and 261 and dependant on 259. In fact, it's 261 that's dependant on 259 and 260. Section 9.2: > - this test should be expanded to include Data Records > containing variable length basicList, > subTemplateList, and subTemplateMultiList Information > Elements. Maybe an explicit recommendation to test not only for variable length structured data, but also for fixed length structured data field containing variable-length IEs might be warranted. Cheers, Christoph -- Christoph Sommer Computer Networks and Communication Systems University of Erlangen-Nuremberg, Germany Phone: +49 9131 85-27993 / Fax: +49 9131 85-27409 http://www7.informatik.uni-erlangen.de/~sommer/ From trammell@tik.ee.ethz.ch Mon Jul 26 07:32:39 2010 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 5DD9A3A68A0 for ; Mon, 26 Jul 2010 07:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vk6eo1MQd2xm for ; Mon, 26 Jul 2010 07:32:37 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 0DD553A6A41 for ; Mon, 26 Jul 2010 07:32:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1A146D930B for ; Mon, 26 Jul 2010 16:32:51 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id U0hI+NTbR8YF for ; Mon, 26 Jul 2010 16:32:50 +0200 (MEST) Received: from dhcp-62f2.meeting.ietf.org (dhcp-62f2.meeting.ietf.org [130.129.98.242]) (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 7BDB9D9307 for ; Mon, 26 Jul 2010 16:32:50 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Jul 2010 16:32:49 +0200 References: <20100726141425.6475B3A6A04@core3.amsl.com> To: IETF IPFIX Working Group Message-Id: <6BED7FFC-E696-4A50-AD74-4A84E5EE583C@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-set9hack-00 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, 26 Jul 2010 14:32:39 -0000 Greetings, all, See the abstract for details; there's a little (but not much) more in = the three-page draft itself. Assume you have a file containing NetFlow V9 PDUs. Assume you'd like to = split it into packets by seeking. Well, you can't do this, really, = without completely parsing and counting records, because while Sets have = lengths, the count header in the Packet header counts records. This = implies a rather slow implementation for any V9 file reader, by forcing = any process reading V9 files to do all parsing in a single pass. There's a hack around this: since Set ID 9 is not valid in V9, you can = just assume Set ID 9 to be the Version of the next V9 Packet header. = When you see Set ID 9, that's a new Packet. Otherwise, it's a set = header, and the next set runs for the number of bytes in the set header = length. All is well, but Set ID 9 might be allocated in the future, which would = cause this hack to break in a version-mixed file. (If we don't want to = support version mixing in files, why bother with a version header?). So = if we allocate Set ID 9 to reserved, we ensure this hack can keep = working. (While we're at it, let's allocate Set ID 10, so we can = recognize IPFIX as well.) Okay. Yes. This is a hack. Why write it up in a draft? The Set ID = registry is modifiable only by Standards Action, so this would appear to = be the only way to make the change. Thoughts? Cheers, Brian Begin forwarded message: > From: IETF I-D Submission Tool > Date: July 26, 2010 4:14:25 PM GMT+02:00 > To: trammell@tik.ee.ethz.ch > Subject: New Version Notification for draft-trammell-ipfix-set9hack-00=20= >=20 >=20 > A new version of I-D, draft-trammell-ipfix-set9hack-00.txt has been = successfully submitted by Brian Trammell and posted to the IETF = repository. >=20 > Filename: draft-trammell-ipfix-set9hack > Revision: 00 > Title: Reserved Set IDs to Enable Boundary Finding in = Mixed IPFIX Files > Creation_date: 2010-07-26 > WG ID: Independent Submission > Number_of_pages: 3 >=20 > Abstract: > This document reserves the IPFIX Set IDs 9 and 10 to prevent them > from being allocated in the future. The reason behind this is to > ensure that heuristic methods for determining PDU boundaries in files > containing NetFlow V9 PDUs and IPFIX Messages work in a standards- > compliant way. >=20 >=20 >=20 > The IETF Secretariat. >=20 From carsten.schmoll9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Mon Jul 26 08:57:34 2010 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 DF27E3A6880 for ; Mon, 26 Jul 2010 08:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 D32VaOrWlTOw for ; Mon, 26 Jul 2010 08:57:27 -0700 (PDT) Received: from relay02-haj2.antispameurope.com (relay02-haj2.antispameurope.com [83.246.65.52]) by core3.amsl.com (Postfix) with ESMTP id 88EBB3A681A for ; Mon, 26 Jul 2010 08:57:26 -0700 (PDT) Received: by relay02-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 5D4CB19400A; Mon, 26 Jul 2010 17:57:45 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay02-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 5967D194002; Mon, 26 Jul 2010 17:57:44 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o6QFvhoc028738; Mon, 26 Jul 2010 17:57:43 +0200 (MEST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2CDB.483EF1D5" Date: Mon, 26 Jul 2010 17:57:43 +0200 Message-ID: <70524A4436C03E43A293958B505008B602A8725C@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipfix-structured-data-02 feedback Thread-Index: Acss20oy5F36302hShOGSuG0clIsbw== From: "Schmoll, Carsten" To: , , , Cc: "Zseby, Tanja" , ipfix@ietf.org Subject: [IPFIX] draft-ietf-ipfix-structured-data-02 feedback 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, 26 Jul 2010 15:57:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2CDB.483EF1D5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Dear authors, =20 I had a look at draft-ietf-ipfix-structured-data-02 recently and I find it in very good shape already. =20 Here my questions and comments in hope they are helpful. =20 =20 1.) =20 You wrote with respect to packet observation: =20 "Ideally, the measurement at the second Observation Point should start a little bit later than at the first Observation Point, allowing the packets to arrive at the destination." =20 I believe this is a too stringent look at packet observation. I would expect that each packet tracking solution must be able to cope with incomplete, and non-matching records. Consider just the case that traffic runs both ways and already then there is no way to start the measurements so that both observation points see exactly the same packets. I would therefore remove that paragraph or replace it with one that states that packet matchers must be quite flexible and cope with non-ideal situations (however I believe that such text is not needed in this draft) =20 2.) =20 "4.3.1. basicList =20 A basicList specifies a generic Information Element with a basicList abstract data type as defined in Section 4.1.1. and list semantics as defined in Section 4.2.1. For example, a list of port numbers, a list of interface indexes, etc. " =20 When I then read 4.3.1 the first time and then 4.2.1 and 4.2.1 I got the impression then 4.2.1 sort of extends 4.1.1 and that basicList may also represent a list of elements conforming to an IPFIX template, i.e. already cover the abstract type subTemplateList. I don't know how I would rewrite it, but would want to make sure that it cannot be misinterpreted this way. (or is it just me?) =20 3.) =20 "A Collection Process decodes list elements from the BasicList Content until no further data remains. A field count is not included but can be derived when the Information Element is decoded." =20 Question: Is there any case at all where a field count does exist in the data records? I think not. The end of a (sub-)list of data will always be detected by end of the (subelement-) byte stream as specified by the length field(s) in the data records in bytes. Correct? =20 4.) =20 "An Exporting Process MUST take care when encoding such data to not exceed the maximum allowed length of an IPFIX Message, 65535 bytes, respecting the IPFIX specifications [RFC5101] that imposes: "The IPFIX Message Header 16-bit Length field limits the length of an IPFIX Message to 65535 octets, including the header". " =20 Completely agree. Good you added this text. Maybe write one more sentence to make clear that the 64k limit pertains to the "outermost" size of each list and/or complex data structure. Hmm, what *if* my complex data structures are bigger than that? Can the joint use together with commonPropertiesID be of help? If so, then I would add one or two sentences on that. =20 5. On a sidenote: Does anyone see the general need for an IPFIX draft on "exporting big blobs of data with IPFIX" ? =20 Then maybe, finally, I could send all my vacation photos via IPFIX to the photo printing service - simply using netcat , if I had them stored as IPFIX file, that is ;-) =20 =20 Best regards Carsten =20 =20 =20 =20 =20 =20 =20 --=20 "With great power comes great responsibility!" What power, you ask? UNIX root privileges. =20 Carsten Schmoll Dipl.-Ing. Project Manager Network Research +49 (0) 30 3463-7136 =20 Fraunhofer FOKUS www.fokus.fraunhofer.de =20 ------_=_NextPart_001_01CB2CDB.483EF1D5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Dear authors,

 

I had a look at = draft-ietf-ipfix-structured-data-02 recently and I find it in very good shape already.

 

Here my questions and comments = in hope they are helpful.

 

 

1.)

 

You wrote with respect to packet = observation:

 

“Ideally, the measurement = at the second Observation Point should

start a little bit later than at = the first Observation Point,

allowing the packets to arrive = at the destination.”

 

I believe this is a too = stringent look at packet observation.  I would expect that each packet tracking = solution must be able to cope with incomplete, and non-matching records. Consider just = the case that traffic runs both ways and already then there is no way to start = the measurements so that both observation points see exactly the same = packets. I would therefore remove that paragraph or replace it with one that states = that packet matchers must be quite flexible and cope with non-ideal = situations (however I believe that such text is not needed in this = draft)

 

2.)

 

“4.3.=
1. basicList
 =

  =
;    A basicList specifies a generic Information =
Element with a
  =
;    basicList abstract data type as defined in Section =
4.1.1. and list
  =
;    semantics as defined in Section =
4.2.1.  For example, a list =
of
  =
;    port numbers, a list of interface indexes, =
etc.

“

 

When I then read 4.3.1 the first = time and then 4.2.1 and 4.2.1  I got the impression then 4.2.1 sort of = extends 4.1.1 and that basicList may also represent a list of elements conforming to an = IPFIX template, i.e. already cover the abstract type subTemplateList.  I = don’t know how I would rewrite it, but would want to make sure that it cannot be misinterpreted this way. (or is it just me?)

 

3.)

 

“A Collection Process = decodes list elements from the BasicList

          = Content until no further data remains.  A field count is not

          = included but can be derived when the Information Element is

          = decoded.”

 

Question:

          =      Is there any case at all where a field count does exist in the data records? I think = not.

          =     The end of a (sub-)list of data will always be detected by end of the (subelement-) byte stream as specified by the length field(s) in the data records in = bytes.

          =      Correct?

 

4.)

 

“An Exporting Process MUST = take care when encoding such data to not

      = exceed the maximum allowed length of an IPFIX Message, 65535

      = bytes, respecting the IPFIX specifications [RFC5101] that imposes:

      = "The IPFIX Message Header 16-bit Length field limits the length of

      = an IPFIX Message to 65535 octets, including the header".

“

 

Completely agree. Good you added = this text. Maybe write one more sentence to make clear that the 64k limit pertains = to the “outermost” size of each list and/or complex data structure. Hmm, what *if* = my complex data structures are bigger than that?  Can the joint use = together with commonPropertiesID be of help? If so, then I would add one or two = sentences on that.

 

5.

On a = sidenote:

Does anyone see the general need = for an IPFIX draft on “exporting big blobs of data with IPFIX” = ?

 

Then maybe, finally, I could = send all my vacation photos via IPFIX to the photo printing service  -  = simply using netcat , if I had them stored as IPFIX file, that is =  ;-)

 

 

Best = regards

Carsten

 

 

 

 

 

 

 

-- =

"With great power comes great responsibility!”  What power, you = ask?  UNIX root privileges.

 

Carsten = Schmoll

Dipl.-Ing.

Project = Manager

Network Research

+49 (0) 30 = 3463-7136

 

Fraunhofer = FOKUS

www.fokus.fraunhofer.de

 

------_=_NextPart_001_01CB2CDB.483EF1D5-- From root@core3.amsl.com Tue Jul 27 01:15:06 2010 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3FBCC3A6AE5; Tue, 27 Jul 2010 01:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100727081503.3FBCC3A6AE5@core3.amsl.com> Date: Tue, 27 Jul 2010 01:15:02 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-psamp-mib-01.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: Tue, 27 Jul 2010 08:15:06 -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 : Definitions of Managed Objects for Packet Sampling Author(s) : T. Dietz, et al. Filename : draft-ietf-ipfix-psamp-mib-01.txt Pages : 28 Date : 2010-07-27 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the IPFIX MIB module [RFC5815]. For IPFIX implementations that use packet sampling (PSAMP) techniques as described in [RFC5475], this memo defines the PSAMP MIB module containing managed objects for providing information on applied packet selection functions and their parameters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-psamp-mib-01.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-psamp-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-27010113.I-D@ietf.org> --NextPart-- From muenz@net.in.tum.de Tue Jul 27 01:31:10 2010 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 183173A6AB9 for ; Tue, 27 Jul 2010 01:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.251 X-Spam-Level: * X-Spam-Status: No, score=1.251 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_LETTER=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_39=0.6, MANGLED_PENIS=2.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 73Y704Sk8kPc for ; Tue, 27 Jul 2010 01:30:59 -0700 (PDT) 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 6DB653A6A8A for ; Tue, 27 Jul 2010 01:30:58 -0700 (PDT) Received: from [130.129.113.123] (dhcp-717b.meeting.ietf.org [130.129.113.123]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 98B75208AFC3 for ; Tue, 27 Jul 2010 10:31:16 +0200 (CEST) Message-ID: <4C4E996E.2000300@net.in.tum.de> Date: Tue, 27 Jul 2010 10:31:42 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080408050207040100060704" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [IPFIX] Review: draft-ietf-ipfix-structured-data-02.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: Tue, 27 Jul 2010 08:31:10 -0000 This is a cryptographically signed message in MIME format. --------------ms080408050207040100060704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Benoit, all, Here is my review of draft-ietf-ipfix-structured-data-02. It mainly consists of suggestions and comments regarding the comprehensibility and language. There is one suggestion about the specification itself. I think that it would be easier to understand if the meaning of the semantic of subTemplateList and subTemplateMultiList would be the same, namely that it specifies the semantic among the Data Records. At the moment, the draft specifies (although not very clearly) that the semantic refers to goups of Data Records associated to different Templates in the case of the subTemplateMultiList. I do not see a use-case for this. Also, no useful example is provided. On the contrary, it is always said that the semantic of subTemplateMultiList is not sufficient. Regards, Gerhard > 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. Maybe add some words about semantics? > 1. Overview > > 1.1. IPFIX Documents Overview > > The IPFIX Protocol [RFC5101] provides network administrators with > access to IP Flow information. > > The architecture for the export of measured IP Flow information > out of an IPFIX Exporting Process to a Collecting Process is > defined in the IPFIX Architecture [RFC5470], per the requirements > defined in RFC 3917 [RFC3917]. > > The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records > and Templates are carried via a congestion-aware transport > protocol from IPFIX Exporting Processes to IPFIX Collecting > Processes. > > IPFIX has a formal description of IPFIX Information Elements, > their name, type and additional semantic information, as specified > in the IPFIX information model [RFC5102]. > > In order to gain a level of confidence in the IPFIX > implementation, probe the conformity and robustness, and allow > interoperability, the Guidelines for IPFIX Testing [RFC5471] > presents a list of tests for implementers of compliant Exporting > Processes and Collecting Processes. > > The Bidirectional Flow Export [RFC5103] specifies a method for > exporting bidirectional flow (biflow) information using the IP > Flow Information Export (IPFIX) protocol, representing each Biflow > using a single Flow Record. > > The "Reducing Redundancy in IP Flow Information Export (IPFIX) and > Packet Sampling (PSAMP) Reports" [RFC5473] specifies a bandwidth > saving method for exporting Flow or packet information, by > separating information common to several Flow Records from > information specific to an individual Flow Record: common Flow > information is exported only once. > > > 1.2. Relationship between IPFIX and PSAMP > > The specification in this document applies to the IPFIX protocol > specifications [RFC5101]. All specifications from [RFC5101] apply > unless specified otherwise in this document. > > The Packet Sampling (PSAMP) protocol [RFC5476] specifies the > export of packet information from a PSAMP Exporting Process to a > PSAMP Collecting Process. Like IPFIX, PSAMP has a formal > description of its information elements, their name, type and > additional semantic information. The PSAMP information model is > defined in [RFC5477]. > > As the PSAMP protocol specifications [RFC5476] are based on the > IPFIX protocol specifications, the specifications in this document > are also valid for the PSAMP protocol. > > Indeed, the major difference between IPFIX and PSAMP is that the > IPFIX protocol exports Flow Records while the PSAMP protocol > exports Packet Reports. From a pure export point of view, IPFIX > will not distinguish a Flow Record composed of several packets > aggregated together, from a Flow Record composed of a single > packet. So the PSAMP export can be seen as a special IPFIX Flow > Record containing information about a single packet. > > > 2. Terminology > > IPFIX-specific terminology used in this document is defined in > Section 2 of the IPFIX protocol specification [RFC5101] and > Section 3 of PSAMP protocol specification [RFC5476]. As in > [RFC5101], these IPFIX-specific terms have the first letter of a > word capitalized when used in this document. > > > 2.1. New Terminology > > Structured Data Information Element > > One of the Information Elements supporting structured data, > i.e., the basicList, subTemplateList, or subTemplateMultiList > Information Elements specified in section 4.3. > > > 3. Introduction > > While collecting the interface counters every five minutes has > proven to be useful in the past, more and more granular > information is required from network elements for a series of > applications: performance assurance, capacity planning, security, > billing, or simply monitoring. However, the amount of information > has become so important that, when dealing with highly granular > information such as Flow information, a push mechanism (as opposed > to a pull mechanism, such as SNMP) is the only solution for > routers whose primary function is to route packets. Indeed, > polling short-live Flows via SNMP is not an option: high end > routers can support hundreds of thousands of Flows simultaneously. > Furthermore, in order to reduce the export bandwidth requirements, > the network elements have to integrate mediation functions to > aggregate the collected information, both in space and time. > > Typically, it would be beneficial if access routers could export > Flow Records, composed of the counters before and after the WAN > optimization mechanism, instead of exporting two Flow Records with > identical tuple information. It is not clear what "the WAN optimization mechanism" is. > In terms of aggregation in time, let us imagine that, for > performance assurance, the network management application must > receive the performance metrics associated with a specific flow, > every millisecond. Since the performance metrics will be > constantly changing, there is a new dimension to the Flow > definition: we are not dealing anymore with a single Flow lasting > a few seconds or a few minutes, but with a multitude of one > millisecond sub flows for which the performance metrics are > reported. > > Which current protocol is suitable for these requirements: push > mechanism, highly granular information, and huge number of similar > records? IPFIX, as specified in RFC5101 would give part of the > solution. > > > 3.1. The IPFIX Track > > The IPFIX working group has specified a protocol to export IP Flow > information [RFC5101]. This protocol is designed to export > information about IP traffic Flows and related measurement data, > where a Flow is defined by a set of key attributes (e.g. source > and destination IP address, source and destination port, etc.). > > The IPFIX protocol specification [RFC5101] specifies that IP > traffic measurements for Flows are exported using a TLV (type, > length, value) format. The information is exported using a > Template Record that is sent once to export the {type, length} > pairs that define the data format for the Information Elements in > a Flow. The Data Records specify values for each Flow. > > Based on the Requirements for IP Flow Information Export (IPFIX) > [RFC3917], the IPFIX protocol has been optimized to export Flow > related information. However, thanks to its Template mechanism, > the IPFIX protocol can export any type of information, as long as > the relevant Information Element is specified in the IPFIX > information model [RFC5102], registered with IANA [IANA-IPFIX], or > specified as an enterprise-specific Information Element. For each > Information Element, the IPFIX information model [RFC5102] defines > a numeric identifier, an abstract data type, an encoding mechanism > for the data type, and any semantic constraints. Only basic, > single-valued data types, e.g., numbers, strings, and network > addresses are currently supported. > > > 3.2. The IPFIX Limitations > > The IPFIX protocol specification [RFC5101] does not support the > encoding of hierarchical structured data and arbitrary-length > lists (sequences) of Information Elements as fields within a > Template Record. As it is currently specified, a Data Record is a > "flat" list of single-valued attributes. However, it is a common > data modeling requirement to compose complex hierarchies of data > types, with multiple occurrences, e.g., 0..* cardinality allowed > for instances of each Information Element in the hierarchy. > > A typical example is the MPLS label stack entries model. An early > NetFlow implementation used two Information Elements to represent > the MPLS label stack entry: a "label stack entry position" > followed by a "label stack value". However, several drawbacks > were discovered. Firstly, the Information Elements in the > Template Record had to be imposed so that the position would > always precede the value. However, some encoding optimizations > are based on the permutation of Information Element order. > Secondly, a new semantic intelligence, not described in the > information model, had to be hardcoded in the Collecting Process: > the label value at the position "X" in the stack is contained in > the "label stack value" Information Element following by a "label > stack entry position" Information Element containing the value > "X". Therefore, this model was abandoned. > > The selected solution in the IPFIX information model [RFC5102] is > a long series of Information Elements: mplsTopLabelStackSection, > mplsLabelStackSection2, mplsLabelStackSection3, > mplsLabelStackSection4, mplsLabelStackSection5, > mplsLabelStackSection6, mplsLabelStackSection7, > mplsLabelStackSection8, mplsLabelStackSection9, > mplsLabelStackSection10. While this model removes any ambiguity, > it overloads the IPFIX information model with repetitive > information. Furthermore, if mplsLabelStackSection11 is required, > IANA [IANA-IPFIX] will not be able to assign the new Information > Element next to the other ones in the registry, which might cause > some confusion. > > Clearly a real structured data type composed of ("label stack > entry position", "label stack value") pairs, potentially repeated > multiple times in Flow Records would be more efficient from an > information model point of view. > > Some more examples enter the same category: how to encode the list > of output interfaces in a multicast Flow, how to encode the list > of BGP Autonomous Systems (AS) in a BGP Flow, how to encode the > BGP communities in a BGP Flow, etc? > > The one-way delay passive measurement, which is described in the > IPFIX Applicability [RFC5472], is yet another example that would > benefit from a structured data encoding. Assuming synchronized > clocks, the Collector can deduce the one-way delay from the > following two Information Elements, collected from two different > Observation Points: > - Packet arrival time: observationTimeMicroseconds [RFC5477] > - Packet ID: digestHashValue [RFC5477] > Ideally, the measurement at the second Observation Point should > start a little bit later than at the first Observation Point, > allowing the packets to arrive at the destination. I do not understand this sentence. How does the measurement affect packet forwarding? How can the measurement allow packets to arrive somewhere? > In practice, > this implies that many pairs of (observationTimeMicroseconds, > digestHashValue) must be exported for each Observation Point, even > if some optimization based on Hash-Based Filtering [RFC5475] is > used. What can be "optimized" by HBF? Maybe: "...even if Hash-Based Filtering is used." > Instead of exporting repetitive information as part of > every single Flow Record (for example, the 5 tuple), an optimized I suggest to remove all occurrences of "optimize", "optimization" etc. unless there is a metric based on which you optimize and unless you can tell whether you reach a global optimum or a local optimum. > flow record composed of a structured data type such as the > following would save a lot of bandwidth: > > 5 tuple It would be good to explain what "5 tuple" means. > { observationTimeMicroseconds 1, digestHashValue 1 } > { observationTimeMicroseconds 2, digestHashValue 2 } > { observationTimeMicroseconds 3, digestHashValue 3 } > { ... , ... } The example has remaind unclear to me until I understood what you describe here. In particular, it is not obvious to me that OWD measurements are exported in Flow Records together with the 5 tuple. If you perform OWD measurements, isn't it sufficient to just export digestHashValue and observationTimeMicroseconds? Also, if you talk about Flow Records here, you actually mean PSAMP Packet Report (i.e. one packet Flow), right? This is not explained. > As a last example, here is a more complex case of hierarchical > structured data encoding. Consider the example scenario of an IPS > (Intrusion Prevention System) alert data structure containing > multiple participants, where each participant contains multiple > attackers and multiple targets, with each target potentially > composed of multiple applications, as depicted below: > > alert > signatureId > protocolIdentifier > riskRating > participant 1 > attacker 1 > sourceIPv4Address > applicationId > ... > attacker N > sourceIPv4Address > applicationId > target 1 > destinationIPv4Address > applicationId 1 > ... > applicationId n > ... > target N > destinationIPv4Address > applicationId 1 > ... > applicationId n > participant 2 > ... > > To export this information in IPFIX, the data would need to be > flattened (thus losing the hierarchical relationships) and a new > IPFIX Template created for each alert, according to the number of > applicationID elements in each target, the number of targets and > attackers in each participant, and the number of participants in > each alert. Clearly each Template will be unique to each alert, > and a large amount of CPU, memory and export bandwidth will be > wasted creating, exporting, maintaining, and withdrawing the > Templates. See Appendix C for a specific example related to this > case study. > > > 3.3. The Proposal > > This document specifies an IPFIX extension to support hierarchical > structured data and variable-length lists by defining three new > Information Elements and three corresponding new abstract data > types called basicList, subTemplateList, and subTemplateMultiList. > > These are defined in Section 4.1. The three list Information > Elements carry some semantic information so that the Collecting > Process can understand the relationship between the different list > elements. > > It is important to note that whereas the Information Elements and > abstract data types defined in the IPFIX information model > [RFC5102] represent single values, these new abstract data types > are structural in nature and primarily contain references to other > Information Elements and to Templates. By referencing other > Information Elements and Templates from an Information Element's > data content, it is possible to define complex data structures > such as variable-length lists and to specify hierarchical > containment relationships between Templates. Therefore, this > document prefers the more generic "Data Record" term to the "Flow > Record" term. > > This document specifies three new abstract data types, which are > basic blocks to represent structured data. However, this document > does not comment on all possible combinations of basicList, > subTemplateList, and subTemplateMultiList. Neither, does it limit > the possible combinations. > > 4. Linkage with the Information Model > > As in the IPFIX Protocol specification [RFC5101], the new > Information Elements specified in Section 4.3. below MUST be sent > in canonical format in network-byte order (also known as the big- > endian byte ordering). > > > 4.1. New Abstract Data Types > > This document specifies three new abstract data types, as > described below. > > > 4.1.1. basicList > > The type "basicList" represents a list of zero or more instances > of any single Information Element, primarily used for single- > valued data types. For example, a list of port numbers, a list of > interface indexes, a list of AS in a BGP AS-PATH, etc. > > > 4.1.2. subTemplateList > > The type "subTemplateList" represents a list of zero or more > instances of a structured data type, where the data type of each > list element is the same and corresponds with a single Template > Record. For example, a structured data type composed of multiple > pairs of ("MPLS label stack entry position", "MPLS label stack > value"), a structured data type composed of performance metrics, a > structured data type composed of multiple pairs of IP address, > etc. > > > 4.1.3. subTemplateMultiList > > The type "subTemplateMultiList" represents a list of zero or more > instances of a structured data type, where the data type of each > list element can be different and corresponds with different > template definitions. For example, a structured data type > composed of multiple access-list entries, where entries can be > composed of different criteria types. > > > 4.2. New Data Type Semantic > > This document specifies a new data type semantic, as described > below. > > > 4.2.1. List > > A list represents an arbitrary-length sequence of zero or more > structured data elements, either composed of regular Information > Elements or composed of data conforming to a Template Record. > > 4.3. New Information Elements > > This document specifies three new Information Elements, as > described below. > > > 4.3.1. basicList > > A basicList specifies a generic Information Element with a > basicList abstract data type as defined in Section 4.1.1. and list > semantics as defined in Section 4.2.1. For example, a list of > port numbers, a list of interface indexes, etc. > > EDITOR'S NOTE: while waiting for IANA [IANA-IPFIX] to assign this > new Information Element identifier, the value XXX is used in all > the examples and in the XML in Appendix A. > > 4.3.2. subTemplateList > > A subTemplateList specifies a generic Information Element with a > subTemplateList abstract data type as defined in Section 4.1.2. > and list semantics as defined in Section 4.2.1. > > EDITOR'S NOTE: while waiting for IANA [IANA-IPFIX] to assign this > new Information Element identifier, the value YYY is used in all > the examples. > > > 4.3.3. subTemplateMultiList > > A subTemplateMultiList specifies a generic Information Element > with a subTemplateMultiList abstract data type as defined in > Section 4.1.3. and list semantics as defined in Section 4.2.1. > > EDITOR'S NOTE: while waiting for IANA [IANA-IPFIX] to assign this > new Information Element identifier, the value ZZZ is used in all > the examples. > > 4.4. New Structured Data Type Semantics > > Structured Data type semantics are provided in order to express Structured _d_ata type > the relationship among multiple list elements in a Structured Data > Information Element. These Structured Data type semantics require _s_tructured _d_ata (is not a term!) Please check all further occurrences below! The usage of capital letters is inconsistent. > a new IPFIX subregistry, as specified in the "IANA Considerations" > section. The semantics are specified in the next following > sections. > > 4.4.1. undefined > > The "undefined" Structured Data type semantic specifies that the > semantic of list elements is not specified, and that, if a > semantic exists, then it is up to the Collecting Process to draw > its own conclusions. The "undefined" structured data type > semantic is the default Structured Data type semantic. > > 4.4.2. noneOf > > The "noneOf" Structured Data type semantic specifies that none of > the elements are actual properties of the Data Record. > > For example, a mediator might want to report to a Collector that a > specific Flow is suspicious, but that it checked already that this > Flow does not belong to the attack type 1, attack type 2, and > attack type 3. So this Flow might need some further inspection. > In such a case, the mediator would report the Flow Record with a > basicList composed of (attack type 1, attack type 2, attack type > 3) and the respective Structured Data type semantic of "noneOf". > > Another example is a router that monitors some specific BGP AS- > PATHs and reports if a Flow belongs to any of them. If the router > wants to export that a Flow does not belong to any of the > monitored BGP AS-PATHs, the router reports a Data Record with a > basicList composed of (BGP AS-PATH 1, BGP AS-PATH 2, BGP AS-PATH > 3) and the respective Structured Data type semantic of "noneOf". > > > 4.4.3. exactlyOneOf > > The "exactlyOneOf" Structured Data type semantic specifies that > only a single element from the Structured Data is an actual > property of the Data Record. This is equivalent to a logical XOR > operation. > > For example, if a Flow record contains a basicList of outgoing > interfaces with the "exactlyOneOf" semantic, then it implies that > the reported Flow only egressed from a single interface, although > the Flow Record lists all of the possible outgoing interfaces. > This is a typical example of a per destination load-balanced Flow > IPFIX encoding. What does the last sentence mean? How can structured data be typical if it has not even been standardized? > > For example, a mediator must report an aggregated observation "Another example is a mediator which must..." You should explain what an "aggregate observation point" is. > point, composed of multiple Template Records: Unclear. The information about OPs is exported in Data Records, not in Template Records. > > Template Record 1: exporterIPaddress > This reports a specific exporter > > Template Record 2: exporterIPaddress, basicList of interfaces > This reports a series of interfaces from an exporter > > Template Record 3: exporterIPaddress, line card > This reports a specific line card from an exporter > > If these three Template Records are exported with a > subTemplateMultiList with the semantic "exactlyOneOf", then it You only export Data Records in a subTemplateMultiList, not Template Records! > implies that the Flow Observation Point is reported with the "Flow's Observation Point"? > values of either Template Record 1, Template Record 2, or Template > Record 3 but not more than one Template Record. I would rewrite it in two sentences, e.g.: "The Flow Record exported by the mediator contains a subTemplateMultiList field with semantic "exactlyOneOf" containing one Data Record for each of the Template Records described above. This implies that the Flow was observed at exactly one of the Observation Points reported." > 4.4.4. oneOrMoreOf > > The "oneOrMoreOf" Structured Data type semantic specifies that one > or more element(s) from the list in the Structured Data is/are I do not like (s) and "/" alternatives. "elements .... are" > actual propertie(s) of the Data Record. This is equivalent to a "properties" > logical OR operation. > > For example, a mediator must report an aggregated Flow (for > example aggregated from IP addresses to IP prefixes), with an "(for ...)" => "(e.g. aggregating IP addresses with common IP prefixes)" > aggregated observation point, composed of multiple Template > Records: > > > Template Record 1: exporterIPaddress > This reports a specific exporter > > Template Record 2: exporterIPaddress, basicList of interfaces > This reports a series of interfaces from an exporter > > Template Record 3: exporterIPaddress, line card > This reports a specific line card from an exporter > > If these three Template Records are exported with a > subTemplateMultiList with the semantic "oneOrMoreOf", then the Same comments as in section 4.4.3. > aggregated Flow has been observed on at least one of the > individual Observation Points reported with the values of a > specific Template Record, and potentially on multiple Observation > Points. > > > 4.4.5. allOf > > The "allOf" structured data type semantic specifies that all of > the list elements from the Structured Data are actual properties > of the Data Record. > > For example, if a Record contains a basicList of outgoing > interfaces with the "allOf" semantic, then the observed Flow is > typically a multicast Flow where each packet in the Flow has been > replicated to each outgoing interface in the basicList. > > > 4.4.6. ordered > > The "ordered" Structured Data type semantic specifies that > elements from the list in the Structured Data are ordered. > > For example, an Exporter might want to export the AS10 AS20 AS30 > AS40 BGP AS-PATH. In such a case, the Exporter would report a > basicList composed of (AS10, AS20, AS30, AS40) and the respective > Structured Data type semantic of "ordered". > > > 4.5. Encoding of IPFIX Data Types > > The following sections define the encoding of the data types abstract data types ? > defined in Section 4.1. above. > > When the encoding of a Structured Data Information Element has a > fixed length (because, for example, it contains the same number of > fixed-length elements, or if the permutations of elements in the > list always produces the same total length), the element length > can be encoded in the corresponding Template Record. However, > when representing variable-length data, hierarchical data, and > repeated data with variable element counts, we RECOMMEND these are "...RECOMMEND that these..." > encoded as a Variable-Length Information Element as described in _v_ariable-_l_ength > Section 7 of [RFC5101], with the length carried in one or three > octets before the Structured Data Information Element encoding. > > > 4.5.1. basicList > > The basicList Information Element defined in Section 4.3.1. > represents a list of zero or more instances of an Information > Element and is encoded as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Semantic |0| Field ID | Element... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ...Length | BasicList Content ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure A: basicList Information Element Encoding > > > Semantic > > The Semantic indicates the semantic of the list elements, remove "The" at the beginning of the sentence or write "The Semantic field..."? > i.e., the relationship among the different Information Element > values within this Structured Data. _s_tructured _d_ata > > > Field ID > > The Field ID is the Information Element identifier of the remove "The" at the beginning of the sentence or add "field"? > Information Element(s) contained in the list. > > > Element Length > > The Element Length indicates the length of each list element remove "The" at the beginning of the sentence or add "field"? > specified by the Field ID, or contains the value 0xFFFF if the > length is encoded as a variable-length Information Element at > the start of the BasicList Content. > > The Element Length field is effectively part of a header, so > even in the case of a zero-element list with no Enterprise > Number, it MUST NOT be omitted. why "with no Enterprise Number"? I would remove the last paragraph. "header" is confusing. And you repeat this requirement below. > > > BasicList Content > > A Collection Process decodes list elements from the BasicList > Content until no further data remains. A field count is not > included but can be derived when the Information Element is > decoded. > > Note that in the diagram above, the Field ID is shown with the maybe "..., Field ID...," or "..., the Field ID field ..." ? > Enterprise bit (most significant bit) set to 0. If instead the > Enterprise bit is set to 1, a four-byte Enterprise Number MUST be > encoded immediately after the Element Length as shown below. See > the "Field Specifier Format" section in the IPFIX Protocol > [RFC5101] for additional information. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Semantic |1| Field ID | Element... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ...Length | Enterprise Number ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | BasicList Content ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure B: basicList Encoding with Enterprise Number > > > Also note that, if a basicList has zero elements, the encoded data > contains the Semantic, Field ID, the Element Length and the four- > byte Enterprise Number (if present), while the BasicList Content > is empty. > > If the basicList is encoded as a Variable-Length Information variable-length (also appears multiple times below) > Element in less than 255 octets, it is encoded with the Length per "Length" => "Length field" (multiple times below) > Section 7 of [RFC5101] as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length (< 255)| basicList Content | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... continuing as needed | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure C: Variable-Length basicList Information Element Encoding > (Length < 255 octets) > > > If the basicList is encoded as a Variable-Length Information > Element in 255 or more octets, it is encoded with the Length per > Section 7 of [RFC5101] as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 255 | Length (0 to 65535) | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | basicList Content | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure D: Variable-Length basicList Information Element Encoding > (Length 0 to 65535 octets) > > > 4.5.2. subTemplateList > > The subTemplateList Information Element represents a list of zero > or more instances of Template data. Because the Template Record what do you mean by "instances of Template data" ? This would be clearer: "Data Records associated to one specific (Options) Template" Or do you think that the term "Data Record" should not be used here? Yet, you also use it below in this context... > referenced by a subTemplateList Information Element can itself > contain other subTemplateList Information Elements, and because > these Template Record references are part of the Information > Elements content in the Data Record, it is possible to represent > complex hierarchical data structures. The following diagram shows > how a subTemplateList Information Element is encoded within a Data > Record: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Semantic | Template ID | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SubTemplateList Content ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure E: subTemplateList Encoding > > > Semantic > > The Semantic indicates the semantic of the list elements, i.e. remove "The" at the beginning of the sentence? Or "The Semantic field"? > the relationship among the different Data Records within this > Structured Data. > > Template ID > > The Template ID is the ID of the template used to encode and This sentence is confusing because Template ID is an IPFIX term! So, it sound like a redefinition. Better: "The Template ID field contains the ID of the ...." > decode the SubTemplateList Content. > > SubTemplateList Content > > The SubTemplateList Content consists of zero or more instances > of Data Records corresponding to the Template ID. A "...Template ID specified in the Template ID field." ? Well, it's pedantic and I would not insist on this change :) > Collecting Process decodes the Data Records until no further > data remains. A record count is not included but can be > derived when the subTemplateList is decoded. Encoding and > decoding are performed recursively if the specified Template > itself contains Structured Data Information Elements as > described here. > > > Note that, if a subTemplateList has zero elements, the encoded > data contains only the Semantic and the Template ID, while the > SubTemplateList Content is empty. > > If the subTemplateList is encoded as a Variable-Length Information variable-length (same below) > Element in less than 255 octets, it is encoded with the Length per Length field (same below) > Section 7 of [RFC5101] as follows: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length (< 255)| subTemplateList Content | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... continuing as needed | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure F: Variable-Length subTemplateList Information Element > Encoding (Length < 255 octets) > > > If the subTemplateList is encoded as a Variable-Length Information > Element in 255 or more octets, it is encoded with the Length per > Section 7 of [RFC5101] as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 255 | Length (0 to 65535) | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... SubTemplateList Content | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure G: Variable-Length subTemplateList Information Element > Encoding (Length 0 to 65535 octets) > > > 4.5.3. subTemplateMultiList > > Whereas each top-level element in a subTemplateList Information what is meant by "top-level"? It means that there are levels below. Remove? > Element corresponds with a single Template ID and therefore has "corresponds to" > the same data type, sometimes it is useful for a list to contain Why "same data type"? Each element is a Data Record associated to the same (Options) Template. ", sometimes it..." => "..., it is sometimes useful..." > elements of more than one data type. To support this case, each Why "data type"? You talk about Templates. > top-level element in a subTemplateMultiList Information Element > carries a Template ID, Length and zero or more Data Records > corresponding to the Template ID. The following diagram shows how > a subTemplateMultiList Information Element is encoded within a > Data Record. Note that the subTemplateMultiList encoding is > consistent with Set Header specified in [RFC5101], once the "with Set Header" => "with the Set Header" ? > Semantic field has been decoded. well, not only after decoding Semantic, also after encoding it :) Better: "Note that the encoding following the Semantic field is consistent with the Set Header specified in [RFC5101]." > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Semantic | Template ID X |Data Records...| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... Length X | Data Record X.1 Content ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | Data Record X.2 Content ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | Data Record X.L Content ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | Template ID Y |Data Records...| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... Length Y | Data Record Y.1 Content ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | Data Record Y.2 Content ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | Data Record Y.M Content ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | Template ID Z |Data Records...| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... Length Z | Data Record Z.1 Content ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | Data Record Z.2 Content ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | Data Record Z.N Content ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+ > > Figure H: subTemplateMultiList Encoding > > Semantic > > The Semantic indicates the top level semantic among Template Remove "The" or "Semantic field"? remove "top level" "among the Data Records"? Comment added later: Now as I have read section 5.4, I understand that you want to restrict to the semantic among sequences of Data Records belonging to different Templates. This does not become clear. Wouldn't it be simpler to say that Semantic defines the semantic among all Data Records, regardless of the Template? > Records, i.e. the relationship among the series of Data > Records from the different Template Records within this "from" => "associated with" > Structured Data. _s_tructured _d_ata > > Note: if a semantic is required to describe the relationship > among the different Data Records corresponding to a single > Template ID within the subTemplateMultiList, then an encoding > based on a basicList of subTemplateLists should be used. Refer I would remove "basicList" because it does not support Templates. So, it is not a general alternative. > to Section 5.6 for more information. > > Template ID > > Unlike the subTemplateList Information Element, each list > element contains a Template ID which specifies the encoding of "each element of subTemplateMultiList contains..." > the following Data Records. > > Data Records Length > > The total length of the Data Records encoding for the Template > ID previously specified, including the 2 bytes for the > Template ID and the 2 bytes for the Data Records Length field > itself. > > Data Record X.M > > The Data Record X.M consists of the Mth Data Record of the > Template Record X. A Collecting Process decodes the Data > Records until no further data remains, according to the Data > Records Length. A record count is not included but can be > derived when the Element Content is decoded. Encoding and > decoding are performed recursively if the specified Template > itself contains Structured Data Information Elements as > described here. > > In the exceptional case of zero instances in the > subTemplateMultiList, no data is encoded and the Data Record > Length is set to zero. > > If the subTemplateMultiList is encoded as a Variable-Length variable-length > Information Element in less than 255 octets, it is encoded with > the Length per Section 7 of [RFC5101] as follows: Length field > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length (< 255)| subTemplateMultiList Information Element | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... continuing as needed | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure I: Variable-Length subTemplateMultiList Information Element > Encoding (Length < 255 octets) > > > If the subTemplateMultiList is encoded as a Variable-Length > Information Element in 255 or more octets, it is encoded with the > Length per Section 7 of [RFC5101] as follows: same comments as above > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 255 | Length (0 to 65535) | IE | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... continuing as needed | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure J: Variable-Length subTemplateMultiList Information > Element Encoding (Length 0 to 65535 octets) > > > 5. Structured Data Format > > > 5.1. Length Encoding Considerations > > The new Structured Data Information Elements represent a list that > potentially carries complex hierarchical and repeated data. In > the normal case where the number and length of elements can vary > from record to record, these Information Elements are encoded as > variable-length Information Elements as described in Section 7 of > [RFC5101]. > > Because of the complex and repeated nature of the data, it is > potentially difficult for the Exporting Process to efficiently > know in advance the exact encoding size. I would replace the following > As a result, data may be > recursively encoded starting at a fixed offset, with the final > length only known and filled in afterwards. > > Therefore, the three-byte length encoding is RECOMMENDED for > variable-length information elements in all Template Records > containing a Structured Data Information Element, even if the > encoded length can be less than 255 bytes, because the starting > offset of the data is known in advance. by: "In this case, the Exporting Process may encode the available data and fill in the final length afterwards. Therefore, it may be convenient to always use the three-byte long encoding of the Length field of the variable-length Structured Data Information Element (even if the final length is less than 255 bytes) to allow the data encoding to start at a fixed offset." > > An Exporting Process MUST take care when encoding such data to not > exceed the maximum allowed length of an IPFIX Message, 65535 > bytes, respecting the IPFIX specifications [RFC5101] that imposes: > "The IPFIX Message Header 16-bit Length field limits the length of > an IPFIX Message to 65535 octets, including the header". I do not think that a quotation is necessary. "When encoding such data, an Exporting Process MUST take care to not exceed the maximum allowed IPFIX Message length of 65535 bytes which is specified in [RFC5101]." > > > 5.2. Recursive Structured Data > > It is possible to define recursive relationships between IPFIX > structured data instances, for example when representing a tree > structure. The simplest case of this might be a basicList where > each element is itself a basicList, or a subTemplateList where one > of the fields of the referenced template is itself a > subTemplateList referencing the same Template. When such a > recursive relationship exists, variable-length encoding as > described in Section 7 of [RFC5101] MUST be used. Also, the > Exporting Process MUST take care when encoding recursively-defined > structured data, not to exceed the maximum allowed length of an > IPFIX Message (as noted in Length Encoding Considerations). > > > 5.3. Structured Data Information Elements Applicability in Options > Template Sets > > Structured Data Information Elements MAY be used in Options > Template Sets. > > As an example, consider a mediation function that must aggregate > Data Records from multiple Observation Point types: > > Router 1, (interface 1) > Router 2, (line card A) > Router 3, (line card B) > Router 4, (line card C, interface 2) > > In order to encode the PSAMP Selection Sequence Report > Interpretation [RFC5476], the mediation function must express this > combination of Observation Points as a single new Observation > Point. Recall from [RFC5476] that the PSAMP Selection Sequence > Report Interpretation consists of the following fields: > > Scope: selectionSequenceId > Non-Scope: one Information Element mapping the Observation Point > selectorId (one or more) > > Without structured data, there is clearly no way to express the > complex aggregated Observation Point as "one Information Element > mapping the Observation Point". However, the desired result may > be easily achieved using the structured data types. Refer to > Section 8.5. for an encoding example related to this case study. > > Regarding the scope in the Options Template Record, the IPFIX > specification [RFC5101] mentions that "The IPFIX protocol doesn't > prevent the use of any Information Elements for scope". > Therefore, a Structured Data Information Element MAY be used as > scope in an Options Template Set. > > Extending the previous example, the mediation function could > export a given name for this complex aggregated Observation Point: > > Scope: Aggregated Observation Point (Structured Data) > Non-Scope: a new Information Element containing the name > > > 5.4. Usage Guidelines for Equivalent Data Representations > > Because basicList, subTemplateList, and subTemplateMultiList are > all lists, in several cases there is more than one way to > represent what is effectively the same data structure. However, > in some cases, one approach has an advantage over the other e.g. > more compact, uses fewer resources, etc., and is therefore > preferred over an alternate representation. > > A subTemplateList can represent the same simple list of single- > value Information Elements as a basicList, if the Template > referenced by the subTemplateList contains only one single-valued > Information Element. Although the encoding is more compact than a > basicList by two bytes, using a subTemplateList in this case > requires a new Template per Information Element. The basicList > requires no additional Template and is therefore RECOMMENDED in > this case. > > Although a subTemplateMultiList with one Element can represent the > contents of a subTemplateList, the subTemplateMultiList carries > two additional bytes (Element Length). It is also potentially > useful to a Collecting Process to know in advance that a > subTemplateList directly indicates that list element types are > consistent. The subTemplateList Information Element is therefore > RECOMMENDED in this case. > > The Semantic in a subTemplateMultiList indicates the top level Semantic field > semantic among Template Records, i.e. the relationship among the Template Records => Data Records ? See comment above in section 4.5.3. > series of Data Records from the different Template Records, within > this Structured Data. If a semantic is required to describe the > relationship among the different Data Records corresponding to a > single Template ID within the subTemplateMultiList, then an > encoding based on a basicList of subTemplateLists should be used. > > Note that the referenced Information Element(s) in the Structured > Data Information Elements can be taken from the IPFIX information > model [RFC5102], the PSAMP information model [RFC5477], or any of > the Information Elements defined in the IANA IPFIX registry [IANA- > IPFIX]. Hm, what about enterprise-specific IEs? > > > 5.5. Padding > > The Exporting Process MAY insert some padding octets in structured > data field values in a Data Record by including the > 'paddingOctets' Information Element as described in [RFC5101] > Section 3.3.1. The paddingOctets Information Element can be > included in a Template Record referenced by Structured Data > Information Element for this purpose. Do we need this section? If you keep it, provide an example where padding might be useful in the context of structured data. > > > 5.6. Semantic > > Semantic interpretations of received Data Records at or beyond the > Collecting Process remain explicitly undefined, unless that data > is transmitted using this extension with explicit Structured Data > type semantic information. Do we need this sentence? It seems to define an unnecessary restriction. Maybe we specify further mechanisms for IPFIX semantics in another RFC which could conflict with this sentence. > > The Exporter SHOULD NOT check all semantically meaningless > combinations before exporting the Data Record. I do not understand. SHOULD NOT => SHOULD or SHOULD NOT => "does not have to" > > Most forms of Structured Data type semantics are possible, without > necessarily specifying new semantic values. Is there a proof for this statement? Otherwise: "More complex semantics can be expressed as a combination of the Semantic Data Information Elements specified in this document." > > For example, the export of the AS10 AS20 AS30 AS40 {AS50,AS60} BGP > AS-PATH would be reported as a basicList of two elements, each > element being a basicList of BGP AS, with the top level Structured > Data type semantic of "ordered". The first element would contain > a basicList composed of (AS10,AS20,AS30,AS40) and the respective > Structured Data type semantic of "ordered", while the second > element would contain a basicList composed of (AS50, AS60) and the > respective Structured Data type semantic of "exactlyOneOf". A > high level Data Record diagram would be represented as: > > (basicList, ordered, > > (basicList, ordered, AS10,AS20,AS30,AS40), > > (basicList, exactlyOneOf, AS50, AS60) > > ) > > Note that the subTemplateMultiList Structured Data type semantic > provides the top level semantic among Template Records, i.e. the > relationship among the series of Data Records from the different > Template Records within this Structured Data, and not the > relationships of the different Data Records corresponding to a > single Template ID within the subTemplateMultiList. If this is > required, semantic information needs to be exported for every > Template ID, in other words a basicList of subTemplateLists should > be used. Remove this paragraph as it is repeated from section 5.4. > > The following case studies show the advantage of a basicList of > subTemplateLists over a subTemplateMultiList. > > Case study 1: > > In this example, an Exporter monitoring security attacks must > export a list of attackers and targets. For the sake of the > example, consider attackers A1 or A2 may attack targets T1 and T2. "consider" => "imagine that" > > The first case uses a subTemplateMultiList composed of two > Template Records, one representing the attacker and one > representing the target, each of them containing an IP address and > a port. > > Attacker Template Record = (src IP address, src port) > Target Template Record = (dst IP address, dst port) > > A high level Data Record diagram would be represented as: > > (subTemplateMultiList, allOf, > > (Attacker Template Record, A1, A2), > > (Target Template Record, T1, T2) > > ) > > The Collecting Process can only conclude that all of the attackers > A1, A2 and the targets T1, T2 are present, without knowing the > relationship amongst attackers and targets. The Exporting Process > would have to explicitly call out the relationship amongst > attackers and targets and the top level semantic offered by the second "and" => "as" ? > subTemplateMultiList isn't sufficient. > > The only proper encoding for the previous semantic (i.e. attacker > A1 or A2 may attack target T1 and T2) uses a basicList of > subTemplateLists and is represented as follows: > > Attacker Template Record = (src IP address, src port) > > Target Template Record = (dst IP address, dst port) > > (basicList, allof, > > (subTemplateList, exactlyOneOf, attacker A1, A2) > > (subTemplateList, allOf, target T1, T2) > > ) > > > > Case study 2: > > In this example, an Exporter monitoring security attacks must > export a list of attackers and targets. For the sake of the > example, attackers A1 or A2 may attack targets T1, attacker A3 is "targets" => "target" > attacking targets T2 and T3. The first case uses a > subTemplateMultiList composed of two Template Records, one "Data Records associated to two different Templates" > representing the attacker and one representing the target, each of > them containing an IP address and a port. > > Attacker Template Record = (src IP address, src port) > > Target Template Record = (dst IP address, dst port) > > A high level Data Record diagram would be represented as: > > (subTemplateMultiList, allOf, > > (Attacker Template Record, A1, A2, A3), > > (Target Template Record, T1, T2, T3) > > ) > > The Collecting Process can only conclude that all of the attackers > A1, A2, A3 and the targets T1, T2, T3 are present, without knowing > the relationship amongst attackers and targets. > > The second case could use a Data Record definition composed of the > following: > > (subTemplateMultiList, allOf, > > (Attacker Template Record, A1, A2), > > (Target Template Record, T1), > > (Attacker Template Record, A3), > > (Target Template Record, T2, T3) > > ) > > With the above representation, the Collecting Process can possibly > deduce that some relationship exists among (A1, A2, T1) and (A3, > T2, T3) but cannot understand what it is exactly. So, there is a > need for the Exporting Process to explicitly define the > relationship between the attackers and targets and the top level > semantic of the subTemplateMultiList is not sufficient. > > The only proper encoding for the previous semantic (i.e. attacker > A1 or A2 attack target T1, attacker A3 attacks targets T2 and T3) > uses a basicList of subTemplateLists and is represented as > follows: > > Attacker Template Record = (src IP address, src port) > > Target Template Record = (dst IP address, dst port) I would not repeat these Template Records here because you do not show the Participant and Alarm Templates either. > > Participant P1: > > (basicList, allOf, > > (subTemplateList, exactlyOneOf, attacker A1, A2) > > (subTemplateList, undefined, target T1) > > ) > > Participant P2: > > (basicList, allOf, > > (subTemplateList, undefined, attacker A3, > > (subTemplateList, allOf, targets T2, T3) > > ) > > The security alert is represented as a subTemplateList of > participants. > > Alert > > (subTemplateList, allOf, Participant P1, Participant P2) > > Note that, in the particular case of a single element in a > Structured Data Information Element, the semantic field is > actually not very useful since it specifies the relationship among > multiple elements. Any choice of allOf, exactlyOneOr, or > OneOrMoreOf would provide the same result semantically. > Therefore, in case of a single element in a Structured Data > Information Element, the default "undefined" semantic SHOULD be > used. > > > 6. Template Management > > This section introduces some more specific Template Management and _m_anagement > Template Withdrawal Message-related specifications compared to the > IPFIX protocol specification [RFC5101]. > > First of all, the Template ID uniqueness is unchanged compared to > [RFC5101]; the uniqueness is local to the Transport Session and > Observation Domain that generated the Template ID. In other > words, the Set ID used to export the Template Record does not > influence the Template ID uniqueness. > > While [RFC5101] mentions that: "If an Information Element is > required more than once in a Template, the different occurrences > of this Information Element SHOULD follow the logical order of > their treatments by the Metering Process.", this rule MAY not be > followed for the Structured Data Information Elements. > > As specified in [RFC5101], Templates that are not used anymore > SHOULD be deleted. Before reusing a Template ID, the Template > MUST be deleted. In order to delete an allocated Template, the > Template is withdrawn through the use of a Template Withdrawal > Message. You might clarify that deleting a Template implies that it may not be used within subTemplateList and subTemplateMultiList any more. > > > 7. The Collecting Process's Side > > This section introduces some more specific specifications to the > Collection Process compared to Section 9 in the IPFIX Protocol > [RFC5101]. > > As described in [RFC5101], a Collecting Process MUST note the > Information Element identifier of any Information Element that it > does not understand and MAY discard that Information Element from > the Flow Record. Therefore a Collection Process that does not > support the extension specified in this document can ignore the > Structured Data Information Elements in a Data Record, or it can > ignore Data Records containing these new Structured Data > Information Elements while continuing to process other Data > Records. > > If the Structured Data contains the "undefined" Structured Data > type semantic, the Collecting Process MAY attempt to draw its own > conclusion in terms of the semantic contained in the Data Record, > exactly as it would have done before the introduction of this > specification. Maybe remove "exactly as..." because without this specification, you cannot nest Data Records anyway, so the CP never has the problem to interpret nested Data Records. > > > 8. Structured Data Encoding Examples > > The following examples are created solely for the purpose of > illustrating how the extensions proposed in this document are > encoded. > > > 8.1. Encoding a Multicast Data Record with BasicList > > Consider encoding a multicast Data Record containing the following > data: > > --------------------------------------------------------------- > Ingress If | Source IP | Destination IP | Egress Interfaces > --------------------------------------------------------------- > 9 192.0.2.201 233.252.0.1 1, 4, 8 > --------------------------------------------------------------- > > Template Record for the multicast Flows, with the Template ID 256: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 24 octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 256 | Field Count = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| ingressInterface = 10 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceIPv4Address = 8 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| DestinationIPv4Address = 12 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| basicList = XXX | Field Length = 0xFFFF | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure K: Encoding basicList, Template Record > > > The list of outgoing interfaces is represented as a basicList with > semantic allOf, and the Length of the list is chosen to be encoded > in three bytes even though it may be less than 255 octets. > > The Data Set is represented as follows: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 256 | Length = 36 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ingressInterface = 9 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sourceIPv4Address = 192.0.2.201 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | DestinationIPv4Address = 233.252.0.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 255 | List Length = 17 | semantic=allOf| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | egressInterface FieldId = 14 |egressInterface Field Length=4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | egressInterface value 1 = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | egressInterface value 2 = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | egressInterface value 3 = 8 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure L: Encoding basicList, Data Record, Semantic allOf > > In the example above, the BasicList contains fixed-length > elements. To illustrate how variable-length elements would be > encoded, the same example is shown below with variable-length > interface names in the BasicList instead: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 256 | Length = 44 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ingressInterface = 9 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sourceIPv4Address = 192.0.2.201 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | DestinationIPv4Address = 233.252.0.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 255 | List Length = 25 | semantic=allOf| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| InterfaceName FieldId = 82 | InterfaceName Field Len=0xFFFF| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length = 5 | 'F' | 'E' | '0' | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | '/' | '0' | Length = 7 | 'F' | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 'E' | '1' | '0' | '/' | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | '1' | '0' | Length = 5 | 'F' | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 'E' | '2' | '/' | '2' | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure M: Encoding basicList, Data Record with Variable-Length > Elements, Semantic allOf > > > 8.2. Encoding a Load-balanced Data Record with a BasicList > > Consider encoding a load-balanced Data Record containing the > following data: > > --------------------------------------------------------------- > Ingress If | Source IP | Destination IP | Egress Interfaces > --------------------------------------------------------------- > 9 192.0.2.201 233.252.0.1 1, 4, 8 > --------------------------------------------------------------- > > > So the Data Record egressed from either interface 1, 4, or 8. The > Data Set is represented as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 256 | Length = 36 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ingressInterface = 9 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sourceIPv4Address = 192.0.2.201 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | DestinationIPv4Address = 233.252.0.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 255 | List Length = 17 |sem=exactlyOne | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | egressInterface FieldId = 14 |egressInterface Field Length=4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | egressInterface value 1 = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | egressInterface value 2 = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | egressInterface value 3 = 8 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure N: Encoding basicList, Data Record, Semantic ExactlyOneOf > > > 8.3. Encoding subTemplateList > > As explained in Section 3.2. , multiple pairs of > (observationTimeMicroseconds, digestHashValue) must be collected > from two different Observation Points to passively compute the > one-way delay across the network. This data can be exported with > an optimized Data Record that consists of the following > attributes: > > 5 tuple > { observationTimeMicroseconds 1, digestHashValue 1 } > { observationTimeMicroseconds 2, digestHashValue 2 } > { observationTimeMicroseconds 3, digestHashValue 3 } > { ... , ... } > > > A subTemplateList is best suited for exporting the list of > (observationTimeMicroseconds, digestHashValue). For illustration > purposes, the number of elements in the list is 5; in practice, it > could be more. > > ------------------------------------------------------------------ > srcIP | dstIP | src | dst |proto| one-way delay > | | Port | Port | | metrics > ------------------------------------------------------------------ > 192.0.2.1 192.0.2.105 1025 80 6 Time1, 0x0x91230613 > Time2, 0x0x91230650 > Time3, 0x0x91230725 > Time4, 0x0x91230844 > Time5, 0x0x91230978 > ------------------------------------------------------------------ > > The following Template is defined for exporting the one-way delay > metrics: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 16 octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 257 | Field Count = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| observationTimeMicroSec=324 | Field Length = 8 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| digestHashValue = 326 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure O: Encoding subTemplateList, Template for One-Way Delay > Metrics > > > The Template Record for the Optimized Data Record is as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 32 octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 258 | Field Count = 6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceIPv4Address = 8 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| destinationIPv4Address = 12 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceTransportPort = 7 | Field Length = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| destinationTransportPort= 11| Field Length = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| protocolIdentifier = 4 | Field Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| subTemplateList = YYY | Field Length = 0xFFFF | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure P: Encoding subTemplateList, Template Record > > The list of (observationTimeMicroseconds, digestHashValue) is > exported as a subTemplateList with semantic allOf. The Length of > the subTemplatelist is chosen to be encoded in three bytes even > though it may be less than 255 octets. > > The Data Record is represented as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 258 | Length = 83 octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sourceIPv4Address = 192.0.2.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | destinationIPV4Address = 192.0.2.105 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sourceTransportPort = 1025 | destinationTransportPort = 80 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Protocol = 6 | 255 | one-way metrics list len = 63 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | semantic=allOf| TemplateID = 257 | TimeValue1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... octets 2-5 of TimeValue1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... octets 6-8 of TimeValue1 |digestHashVal1=| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... 0x0x91230613 | TimeValue2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... octets 2-5 of TimeValue2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... octets 6-8 of TimeValue2 |digestHashVal2=| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... 0x0x91230650 | TimeValue3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... octets 2-5 of TimeValue3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... octets 6-8 of TimeValue3 |digestHashVal3=| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... 0x0x91230725 | TimeValue4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... octets 2-5 of TimeValue4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... octets 6-8 of TimeValue4 |digestHashVal4=| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... 0x0x91230844 | TimeValue5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... octets 2-5 of TimeValue5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... octets 6-8 of TimeValue5 |digestHashVal5=| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... 0x0x91230978 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure Q: Encoding subTemplateList, Data Set > > > 8.4. Encoding subTemplateMultiList > > As explained in Section 4.4.3., a subTemplateMultiList is used to > export a list of mixed-type content where each top level element > corresponds to a different Template Record. > > To illustrate this, consider the Data Record with the following > attributes: > > > 5 tuple (Flow Keys), octetCount, packetCount > attributes for classification > selectorId, > selectorAlgorithm > attributes for sampling > selectorId, > selectorAlgorithm, > samplingPacketInterval, > samplingPacketSpace > > This example demonstrates that the Selector Report Interpretation > [RFC5476] can be encoded with the subTemplateMultiList. More > specifically, the example describes Property Match Filtering > Selector Report Interpretation [RFC5476] used for classification IMO, "classification" can be misunderstood. Why do not use the word "filtering"? Or "selection"? > purposes, and the Systemic Count-Based Sampling as described in > Section 6.5.2.1 of [RFC5476]. Some traffic will be filtered > according to match properties configured, some will be sampled, > some will be filtered and sampled, and some will not be filtered or > be sampled. > > A subTemplateMultiList is best suited for exporting this variable > data. A Template is defined for classification attributes and Again, I would say: filtering attributes. > another Template is defined for sampling attributes. A Data Record > can contain data corresponding to either of the Templates, both of > them, or neither of them. > > > Consider the example below where the following Data Record contains > both classification and sampling attributes. > > Key attributes of the Data Record: > > ------------------------------------------------------------------ > srcIP | dstIP | src | dst | proto | octetCount | packet > | | Port | Port | | | Count > ------------------------------------------------------------------ > 192.0.2.1 192.0.2.105 1025 80 6 108000 120 > ------------------------------------------------------------------ > > > Classification attributes: > > ------------------------------------------- > selectorId | selectorAlgorithm > ------------------------------------------- > 100 5 (Property Match Filtering) > ------------------------------------------- > > > Sampling attributes: > > For Systemic Count-Based Sampling as defined in Section 6.5.2.1 of > [RFC5476] the required algorithm-specific Information Elements are: > > samplingPacketInterval: number of packets selected in a row > samplingPacketSpace: number of packets between selections > > Example of a simple 1 out-of 100 systematic count-based Selector > definition, where the samplingPacketInterval is 1 and the > samplingPacketSpace is 99. > > -------------------------------------------------------------- > selectorId | selectorAlgorithm | sampling | sampling > | | Packet | Packet > | | Interval | Space > -------------------------------------------------------------- > 15 1 (Count-Based Sampling) 1 99 > -------------------------------------------------------------- > > > To represent the Data Record, the following Template Records are > defined: > > Template for classification attributes: 259 > Template for sampling attributes: 260 > Template for Flow Record: 261 > > Flow record (261) > | (sourceIPv4Address) > | (destinationIPv4Address) > | (sourceTransportPort) > | (destinationTransportPort) > | (protocolIdentifier) > | (octetTotalCount) > | (packetTotalCount) > | > +------ classification attributes (259) > | (selectorId) > | (selectorAlgorithm) > | > +------ sampling attributes (260) > | (selectorId) > | (selectorAlgorithm) > | (samplingPacketInterval) > | (samplingPacketSpace) > > > The following Template Record is defined for classification > attributes: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 16 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 259 | Field Count = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| selectorId = 302 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| selectorAlgorithm = 304 | Field Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure R: Encoding subTemplateMultiList, Template for > Classification Attributes > > The Template for sampling attributes is defined as follows: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 24 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 260 | Field Count = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| selectorId = 302 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| selectorAlgorithm = 304 | Field Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| samplingPacketInteval = 305 | Field Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| samplingPacketSpace = 306 | Field Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure S: Encoding subTemplateMultiList, Template for Sampling > Attributes > > > Note that while selectorId is defined as unsigned64, it is Actually, selectorId is unsigned32 (at least according to WG consensus) > compressed down to 4 octet here as allowed by Reduced Size > Encoding in Section 6.2 of the IPFIX protocol specifications > [RFC5101]. > > Note that while selectorAlgorithm is defined as unsigned16, and > samplingPacketInterval and samplingPacketSpace are defined as > unsigned32, they are compressed down to 1 octet here as allowed > by Reduced Size Encoding in Section 6.2 of the IPFIX protocol > specifications [RFC5101]. > > > Template for the Flow Record is defined as shown below: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 40 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 261 | Field Count = 8 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceIPv4Address = 8 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| destinationIPv4Address = 12 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceTransportPort = 7 | Field Length = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| destinationTransportPort=11 | Field Length = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| protocolIdentifier = 4 | Field Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| octetTotalCount = 85 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| packetTotalCount = 86 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| subTemplateMultiList = ZZZ | Field Length = 0XFFFF | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure T: Encoding subTemplateMultiList, Template for Flow Record > > > A subTemplateMultiList with semantic allOf is used to export the > classification and sampling attributes. The Length of the > subTemplateMultilist is chosen to be encoded in three bytes even > though it may be less than 255 octets. > > The Data Record is encoded as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 261 | Length = 49 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sourceIPv4Address = 192.0.2.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | destinationIPv4Address = 192.0.2.105 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sourceTransportPort = 1025 | destinationTransportPort = 80 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | protocol = 6 | octetTotalCount = 108000 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | packetTotalCount = 120 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | 255 | Attributes List Length = 21 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |semantic=allOf | Classif. Template ID = 259 | Classif. Attr | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ...Length = 9 | selectorId = ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... 100 |selectorAlg = 5| Sampling Template ID = 260 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sampling Attributes Length=11 | selectorId = ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... 15 |selectorAlg = 1| Interval = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Space = 99 | > +-+-+-+-+-+-+-+-+ > > Figure U: Encoding subTemplateMultiList, Data Set > > > 8.5. Encoding an Options Template Set using Structured Data > > As described in Section 5.3. , consider a mediation function that > must aggregate Data Records from multiple different Observation > Points. > > Say Observation Point 1 consists of one or more interfaces, > Observation Points 2 and 3 consist of one or more line cards, and > Observation Point 4 consists of one or more interfaces and one or > more line cards. Without structured data, a template would have > to be defined for every possible combination to interpret the data > corresponding to each of the Observation Points. However, with > structured data, a basicList can be used to encode the list of > interfaces and another basicList can be used to encode the list of > line cards. > > For the sake of simplicity, each Observation Point shown below has > an or or . This > can very well be extended to include a list of interfaces and a > list of linecards using basicLists as explained above. > > Observation Point 1: Router 1, (interface 1) > Observation Point 2: Router 2, (line card A) > Observation Point 3: Router 3, (line card B) > Observation Point 4: Router 4, (line card C, interface 2) > > > The mediation function wishes to express this as a single > Observation Point, in order to encode the PSAMP Selection Sequence > Report Interpretation (SSRI). Recall from [RFC5476] that the > PSAMP Selection Sequence Report Interpretation consists of the > following fields: > > Scope: selectionSequenceId > Non-Scope: one Information Element mapping the Observation Point > selectorId (one or more) > > For example, the Observation Point detailed above may be encoded > in a PSAMP Selection Sequence Report Interpretation as shown > below: > > Selection Sequence 7 (Filter->Sampling): > observation point: subTemplateMultiList. > Router 1, (interface 1) > Router 2, (line card A) > Router 3, (line card B) > Router 4, (line card C, interface 2) > selectorId: 5 (Filter, match IPV4SourceAddress 192.0.2.1) > selectorId: 10 (Sampler, Random 1 out-of ten) > > The following Templates are defined to represent the PSAMP SSRI: > Template for representing PSAMP SSRI: 262 > Template for representing interface: 263 > Template for representing linecard: 264 > Template for representing linecard and interface: 265 > > > PSAMP SSRI (262) > | (SelectionSequenceId) > | > +--- Observation Point 1 (263) > | (Interface Id) > | > +--- Observation Point 2 and 3 (264) > | (line card) > | > +--- Observation Point 4 (265) > | (line card) > | (Interface Id) > | > | (selectorId 1) > | (selectorId 2) > > > Figure V: PSAMP SSRI to be encoded > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 3 | Length = 26 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 262 | Field Count = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope Field Count = 1 |0| selectionSequenceId = 301 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope 1 Length = 4 |0| subTemplateMultiList = ZZZ | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 0xFFFF |0| selectorId = 302 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| selectorId = 302 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure W: Options Template Record for PSAMP SSRI using > subTemplateMultiList > > A subTemplateMultiList with semantic allOf is used to encode the > list of Observation Points. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 12 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 263 | Field Count = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| ingressInterface = 10 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure X: PSAMP SSRI, Template Record for interface > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 12 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 264 | Field Count = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| lineCardId = 141 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure Y: PSAMP SSRI, Template Record for linecard > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 16 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 265 | Field Count = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| lineCardId = 141 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| ingressInterface = 10 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure Z: PSAMP SSRI, Template Record for linecard and interface > > > The PSAMP SSRI Data Set is represented as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 262 | Length = 52 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | selectionSequenceId = 7 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 255 | Observation Point List Len=33 |semantic=allOf | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OP1 Template ID = 263 | OP1 Length = 8 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OP1 ingressInterface = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OP2&3 Template ID = 264 | OP2&3 Length = 12 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OP2 lineCardId = A | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OP3 lineCardId = B | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OP4 Template ID = 265 | OP4 Length = 12 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OP4 lineCardId = C | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OP4 ingressInterface = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | selectorId = 5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | selectorId = 10 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure ZA: Example of a PSAMP SSRI Data Record, Encoded using a > subTemplateMultiList > > Note that the Data Record above contains multiple instances of > Template 264 to represent Observation Point 2 (line card A) and > Observation Point 3 (line card B). Instead, if a single > Observation Point had both line card A and line card B, a > basicList would be used to represent the list of line cards. > > > > 9. Relationship with the Other IFPIX Documents > > 9.1. Relationship with Reducing Redundancy > > "Reducing Redundancy in IP Flow Information Export (IPFIX) and > Packet Sampling (PSAMP) Reports" [RFC5473] describes a bandwidth > saving method for exporting Flow or packet information using the > IP Flow Information eXport (IPFIX) protocol. > > It defines the commonPropertiesID Information Element for > exporting Common Properties. > > > > 9.1.1. Encoding Structured Data Element using Common Properties. > > When Structured Data Information Elements contain repeated > elements, these elements may be replaced with a > commonPropertiesID Information Element as specified in > [RFC5473]. The replaced elements may include the basicList, > subTemplateList and subTemplateMultiList Information Elements. > > This technique might help reducing the bandwidth requirements > for the export. However, a detailed analysis of the gain has > not been done; refer to Section 8.3 of [RFC5473] for further > considerations. > > > > 9.1.2. Encoding Common Properties elements With Structured Data > Element. > > Structured Data Information Element MAY be used to define a list > of commonPropertiesID, as a replacement for the specifications > in [RFC5473]. > > Indeed, the example in figures 1 and 2 of [RFC5473] can be > encoded with the specifications in this document. > > > +----------------+-------------+---------------------------+ > | sourceAddressA | sourcePortA | | > +----------------+-------------+---------------------------+ > | sourceAddressA | sourcePortA | | > +----------------+-------------+---------------------------+ > | sourceAddressA | sourcePortA | | > +----------------+-------------+---------------------------+ > | sourceAddressA | sourcePortA | | > +----------------+-------------+---------------------------+ > | ... | ... | ... | > +----------------+-------------+---------------------------+ > > Figure ZB: Common and Specific Properties Exported Together > [RFC5473] > > +------------------------+-----------------+-------------+ > | index for properties A | sourceAddressA | sourcePortA | > +------------------------+-----------------+-------------+ > | ... | ... | ... | > +------------------------+-----------------+-------------+ > > > +------------------------+---------------------------+ > | index for properties A | | > +------------------------+---------------------------+ > | index for properties A | | > +------------------------+---------------------------+ > | index for properties A | | > +------------------------+---------------------------+ > | index for properties A | | > +------------------------+---------------------------+ > > Figure ZC: Common and Specific Properties Exported Separately > according to [RFC5473] > > +----------------+-------------+---------------------------+ > | sourceAddressA | sourcePortA | | > +----------------+-------------+---------------------------+ > | | > +---------------------------+ > | | > +---------------------------+ > | | > +---------------------------+ > | ... | > +---------------------------+ > > Figure ZD: Common and Specific Properties Exported with > Structured Data Information Element > > > The example in figure ZC could be encoded with a basicList if Isn't it in figure ZD? > the represents a single Information Element, > with a subTemplateList if the represents a > Template Record, or with a subTemplateMultiList if the information> is composed of different Template Records. > > Using Structured Data Information Elements as a replacement for > the techniques specified in "Reducing Redundancy in IP Flow > Information Export (IPFIX) and Packet Sampling (PSAMP) Reports" > [RFC5473] offers the advantage that a single Template Record is > defined. Hence the Collectors job is simplified in terms of > Template management and combining Template/Options Template > Records. > > However, it must be noted that using Structured Data Information > Elements as a replacement for the techniques specified in > "Reducing Redundancy in IP Flow Information Export (IPFIX) and > Packet Sampling (PSAMP) Reports" only applies to simplified > cases. For example, the "Multiple Data Reduction" (Section 7.1 > [RFC5473]) might be too complex to encode with Structured Data > Information Elements. > > > > 9.2. Relationship with Guidelines for IPFIX Testing > > [RFC5471] presents a list of tests for implementers of IP Flow > Information eXport (IPFIX) compliant Exporting Processes and > Collecting Processes. > > Although [RFC5471] doesn't define any structured data element > specific tests, the Structured Data Information Elements can be > used in many of the [RFC5471] tests. > > The [RFC5471] series of test could be useful because the > document specifies that every Information Element type should be > tested. However, not all cases from this document are tested in > [RFC5471]. > > The following sections are especially noteworthy: > > . 3.2.1. Transmission of Template with fixed size > Information Elements > > - each data type should be used in at least one test. > The new data types specified in Section 4.1. should > be included in this test. > > . 3.2.2. Transmission of Template with variable length > Information Elements > > - this test should be expanded to include Data Records > containing variable length basicList, > subTemplateList, and subTemplateMultiList Information > Elements. > > . 3.3.1. Enterprise-specific Information Elements > - this test should include the export of basicList, > subTemplateList, and subTemplateMultiList Information > Elements containing Enterprise-specific Information > Elements. e.g., see the example in figure B. > > . 3.3.3. Multiple instances of the same Information Element > in one Template > > - this test should verify that multiple instances of the > basicList, subTemplateList and subTemplateMultiList > Information Elements are accepted. > > . 3.5 Stress/Load tests > > - since the structured data types defined here allow > modeling of complex data structures, they may be > useful for stress testing both Exporting Processes > and Collecting Processes. > > > > 9.3. Relationship with Bidirectional Flow Export > > [RFC5103] describes a method for exporting bidirectional flow > information, and defines the biflowDirection Information Element > for this purpose. > > [RFC5103] Biflows may be encoded in a subTemplateList or > subTemplateMultiList. The basicList requires recurrence of a > single element, so is not suitable for Biflows. > > Encoding Biflows with subTemplateList or subTemplateMultiList > provides a more logical division of the information in both > directions, although this encoding incurs a small additional > bandwidth penalty. > > An example of Biflow encoding using Structure Data Information > Elements and comparison with the [RFC5103] Biflow encoding is > shown in Appendix B. > > > 9.4. Relationship with IPFIX Mediation Function > > The Structured Data Information Elements would be beneficial for > the export of aggregated Data Records in mediation function, as > was demonstrated with the example of the aggregated Observation > Point in Section 5.3. > > > 10. IANA Considerations > > This document specifies several new IPFIX abstract data types, a > new IPFIX Data Type Semantic, and several new Information > Elements. > > These require the creation of two new IPFIX registries and > updating the existing IPFIX Information Element registry as > detailed below. > > > 10.1. New Abstract Data Types > > Section 4.1. of this document specifies several new IPFIX abstract > data types. Per Section 6 of the IPFIX information model > [RFC5102], new abstract data types can be added to the IPFIX > information model. This requires creation of a new IPFIX > "abstract data types" registry at > http://www.iana.org/assignments/ipfix. This registry should > include all the abstract data types from Section 3.1 of [RFC5102]. > > Abstract data types to be added to the IPFIX "abstract data types" > registry are listed below. > > > 10.1.1. basicList > > The type "basicList" represents a list of any Information Element > used for single-valued data types. > > > 10.1.2. subTemplateList > > The type "subTemplateList" represents a list of a structured data > type, where the data type of each list element is the same and > corresponds with a single Template Record. > > > 10.1.3. subTemplateMultiList > > The type "subTemplateMultiList" represents a list of structured > data types, where the data types of the list elements can be > different and correspond with different template definitions. > > > 10.2. New Data Type Semantics > > Section 4.2. of this document specifies a new IPFIX Data Type > Semantic. Per Section 3.2 of the IPFIX information model > [RFC5102], new data type semantics can be added to the IPFIX > information model. Therefore, the IANA IPFIX > informationElementSemantics registry [IANA-IPFIX], which contains > all the data type semantics from Section 3.2 of [RFC5102], must be > augmented with the "list" value below. > > > 10.2.1. list > > A list is a structured data type, being composed of a sequence of > elements e.g. Information Element, Template Record, etc. > > > 10.3. New Information Elements > > Section 4.3. of this document specifies several new Information > Elements which are to be created in the IPFIX Information Element > registry [IANA-IPFIX]. > > New Information Elements to be added to the IPFIX Information > Element registry are listed below. > > EDITOR'S NOTE: the XML specification in Appendix A must be updated > with the elementID values allocated below. > > 10.3.1. basicList > > Name: basicList > Description: > Specifies a generic Information Element with a basicList abstract > data type. For example, a list of port numbers, a list of > interface indexes, etc. > Abstract Data Type: basicList > Data Type Semantics: list > ElementId: XXX (to be specified by IANA) > Status: current > > 10.3.2. subTemplateList > > Name: subTemplateList > Description: > Specifies a generic Information Element with a subTemplateList > abstract data type. > Abstract Data Type: subTemplateList > Data Type Semantics: list > ElementId: YYY (to be specified by IANA) > Status: current > > 10.3.3. subTemplateMultiList > > Name: subTemplateMultiList > Description: > Specifies a generic Information Element with a > subTemplateMultiList abstract data type. > Abstract Data Type: subTemplateMultiList > Data Type Semantics: list > ElementId: ZZZ (to be specified by IANA) > Status: current > > 10.4. New Structured Data Semantics > > Section 4.4. of this document specifies a series of new IPFIX > structured data type semantics, which is expressed as an 8-bit > value. This requires the creation of a new IPFIX "structured data > types semantics" IPFIX subregistry [IANA-IPFIX]. > > Entries may be added to this subregistry subject to a Standards > Action [RFC5226]. Initially, this registry should include all the > structured data type semantics listed below. > > > 10.4.1. undefined > > A list is a structured data type, being composed of a sequence of > elements e.g. Information Element, Template Record, etc. > Value: 0xFF > Description: undefined > Reference: > > > 10.4.2. noneOf > > A list is a structured data type, being composed of a sequence of > elements e.g. Information Element, Template Record, etc. > Value: 0x00 > Description: noneOf > Reference: > > > 10.4.3. exactlyOneOf > > A list is a structured data type, being composed of a sequence of > elements e.g. Information Element, Template Record, etc. > Value: 0x01 > Description: exactlyOneOf > Reference: > > > 10.4.4. oneOrMoreOf > > A list is a structured data type, being composed of a sequence of > elements e.g. Information Element, Template Record, etc. > Value: 0x02 > Description: oneOrMoreOf > Reference: > > 10.4.5. allOf > > A list is a structured data type, being composed of a sequence of > elements e.g. Information Element, Template Record, etc. > Value: 0x03 > Description: allOf > Reference: > > > 10.4.6. ordered > > A list is a structured data type, being composed of a sequence of > elements e.g. Information Element, Template Record, etc. > Value: 0x04 > Description: ordered > Reference: > > > 11. Security Considerations > > The same security considerations as for the IPFIX Protocol > [RFC5101] apply. > > > 12. References > > 12.1. Normative References > > [RFC2119] S. Bradner, Key words for use in RFCs to Indicate > Requirement Levels, BCP 14, RFC 2119, March 1997. > > [RFC5101] Claise, B., Ed., "Specification of the IP Flow > Information Export (IPFIX) Protocol for the Exchange of > IP Traffic Flow Information", RFC 5101, January 2008. > > [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and > J. Meyer, "Information Model for IP Flow Information > Export", RFC 5102, January 2008. > > [RFC5226] T. Narten, T., Alverstrand, H. , "Guidelines for > Writing an IANA Considerations Section in RFCs", > RFC5226, May 2008. > > > 12.2. Informative References > > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > Requirements for IP Flow Information Export, RFC 3917, > October 2004. > > [RFC5103] Trammell, B., and E. Boschi, "Bidirectional Flow > Export Using IP Flow Information Export (IPFIX)", RFC > 5103, January 2008. > > [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. > Quittek, "Architecture for IP Flow Information Export", > RFC 5470, March 2009. > > [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines > for IP Flow Information Export (IPFIX) Testing", RFC > 5471, March 2009. > > [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, > "IP Flow Information Export (IPFIX) Applicability", RFC > 5472, March 2009. > > [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing > Redundancy in IP Flow Information Export (IPFIX) and > Packet Sampling (PSAMP) Reports", RFC 5473, March 2009. > > [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., > and F. Raspall, "Sampling and Filtering Techniques for > IP Packet Selection", RFC 5475, March 2009. > > [RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol > Specifications", RFC 5476, March 2009. > > [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and > G. Carle, "Information Model for Packet Sampling > Exports", RFC 5477, March 2009. > > [IANA-IPFIX] http://www.iana.org/assignments/ipfix/ipfix.xhtml > > > 13. Acknowledgement > > The authors would like to thank Zhipu Jin, Nagaraj Varadharajan, > Brian Trammel, and Atsushi Kobayashi for their feedback. > > > 14. Authors' Addresses > > > Benoit Claise > Cisco Systems Inc. > De Kleetlaan 6a b1 > Diegem 1813 > Belgium > > Phone: +32 2 704 5622 > EMail: bclaise@cisco.com > > > Gowri Dhandapani > Cisco Systems Inc. > 13615 Dulles Technology Drive > Herndon, Virigina 20171 > United States > > Phone: +1 408 853 0480 > EMail: gowri@cisco.com > > > Stan Yates > Cisco Systems Inc. > 7100-8 Kit Creek Road > PO Box 14987 > Research Triangle Park > North Carolina, 27709-4987 > United States > > Phone: +1 919 392 8044 > EMail: syates@cisco.com > > > > Paul Aitken > Cisco Systems (Scotland) Ltd. > 96 Commercial Quay > Commercial Street > Edinburgh, EH6 6LX, United Kingdom > > Phone: +44 131 561 3616 > EMail: paitken@cisco.com > > > > Appendix A. Additions to XML Specification of IPFIX Information > Elements and Abstract Data Types > > This appendix contains additions to the machine-readable > description of the IPFIX information model coded in XML in > Appendix A and Appendix B in [RFC5102]. Note that this appendix > is of informational nature, while the text in section 4. > (generated from this appendix) is normative. > > The following field definitions are appended to the IPFIX > information model in Appendix A of [RFC5102]. > > dataType="basicList" > group="structured-data" > dataTypeSemantics="List" > elementId="XXX" applicability="all" status="current"> > > > Represents a list of zero or more instances of > any single Information Element, primarily used for > single-valued data types. For example, a list of port > numbers, list of interface indexes, list of AS in a > BGP AS-PATH, etc. > > > > > dataType="subTemplateList" > group="structured-data" > dataTypeSemantics="List" > elementId="XXX" applicability="all" status="current"> > > > Represents a list of zero or more instances of a > structured data type, where the data type of each list > element is the same and corresponds with a single > Template Record. For example, a structured data type > composed of multiple pairs of ("MPLS label stack entry > position", "MPLS label stack value"), a structured data > type composed of performance metrics, a structured data > type composed of multiple pairs of IP address, etc. > > > > > dataType="subTemplateMultiList" > group="structured-data" > dataTypeSemantics="List" > elementId="XXX" applicability="all" status="current"> > > > Represents a list of zero or more instances of > structured data types, where the data type of each list > element can be different and corresponds with > different template definitions. For example, a > structured data type composed of multiple access-list > entries, where entries can be composed of different > criteria types. > > > > > > The following structured data type semantic definitions are > appended to the the IPFIX information model in Appendix A of > [RFC5102]. > > > > > > > Specifies that the semantic of list elements is not > specified, and that, if a semantic exists, then it is up > to > the Collecting Process to draw its own conclusions. The > "undefined" structured data type semantic is the default > Structured Data type semantic. > > > > > > > > Specifies that none of the elements are actual > properties > of the Data Record. > > > > > > > > Specifies that only a single element from the > Structured Data is an actual property of the Data > Record. This is equivalent to a logical XOR operation. > > > > > > > > Specifies that one or more element(s) from the list in > the Structured Data is/are actual propertie(s) of the > Data Record. This is equivalent to a logical OR > operation. > > > > > > > > Specifies that all of the list elements from the > Structured Data are actual properties of the Data > Record. > > > > > > > > Specifies that elements from the list in the > Structured Data are ordered. > > > > > > > The following schema definitions are appended to the abstract data > types defined in Appendix B of [RFC5102]. > > > > > > > > Represents a list of zero or more instances of > any single Information Element, primarily used for > single-valued data types. For example, a list of port > numbers, list of interface indexes, list of AS in a > BGP AS-PATH, etc. > > > > > > > Represents a list of zero or more instances of a > structured data type, where the data type of each list > element is the same and corresponds with a single > Template Record. For example, a structured data type > composed of multiple pairs of ("MPLS label stack entry > position", "MPLS label stack value"), a structured > data type composed of performance metrics, a > structured data type composed of multiple pairs of IP > address, etc. > > > > > > > Represents a list of zero or more instances of > structured data types, where the data type of each > list element can be different and corresponds with > different template definitions. For example, a > structured data type composed of multiple > access-list entries, where entries can be > composed of different criteria types. > > > > > > > > > > > > Represents an arbitrary-length sequence of structured > data elements, either composed of regular Information > Elements or composed of data conforming to a Template > Record. > > > > > > > > > minOccurs="1" maxOccurs="unbounded"> > > > > > > use="required"/> > > > > > > type="structuredDataTypeSemantics"> > > > Structured Data type semantics express the relationship > among multiple list elements in a Structured Data > Information Element. > > > > > > > Appendix B. Example of Biflow Encoding using Structured Data > Information Elements > > Referring to [RFC5103] figure 1, a Biflow consists of two parts: > some "key" fields such as src/dst information (IP addresses, > ports), followed by a set of forward/reverse pairs. > > Then looking at [RFC5103] figure 7, we see that the Reverse PEN > is repeated many times to indicate fields which were observed in > the reverse direction. Clearly that repetition is wasteful. You mean that it is wasteful if such a Template is used in a Structured Data Information Element? Or in general? In this case, I do not think that the PEN is a problem. The Template is exported only once. > > Looking back at [RFC5103] figure 1, it's clear that the encoding > can use a Template Record consisting of the Flow Keys followed > by a subTemplateList consisting of two elements: one for the > forward direction, the other for the reverse direction. > > The subTemplateList uses a single Template Record to describe > the fields in both lists since they are a set of forward/reverse > pairs. > > > Uniflow Uniflow > +-------+-------+-----------------+ +-------+-------+-----------------+ > | src A | dst B | counters/values | | src B | dst A | counters/values | > +-------+-------+-----------------+ +-------+-------+-----------------+ > | | | | > V V V V > +-------+-------+---------------------+---------------------+ > | src A | dst B | fwd counters/values | rev counters/values | > +-------+-------+---------------------+---------------------+ > | | | > V V V > key fields fwd element rev element > > Figure B0: Using a subTemplateList to represent a Biflow. You should show where the subTemplateList is. > > The following example shows the example from Appendix A of > [RFC5103] encoded using a subTemplateList: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 24 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 266 | Field Count = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| flowDirection 61 | Field Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| flowStartSeconds 150 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| octetTotalCount 85 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| packetTotalCount 86 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure B1: Template for the Biflow Fields > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 32 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 267 | Field Count = 6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceIPv4Address 8 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| destinationIPv4Address 12 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceTransportPort 7 | Field Length = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| destinationTransportPort 11 | Field Length = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| protocolIdentifier 4 | Field Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| subTemplateList = YYY | Field Length = 29 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure B2: Template for the Key Fields > > The Template Record includes a subTemplateList with semantic allOf > for encoding the BiFlow fields for the forward and reverse > direction. Note that the subTemplateList is encoded using Fixed > Length, as shown in the above template definition. _f_ixed _l_ength, _T_emplate > > > Also, note that the overall template size is 24 + 32 = 56 octets, > compared with 64 octets in the [RFC5103] example - so a small > saving is achieved. Is the Template length actually relevant? The Template is exported only once. > > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 267 | Length = 46 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sourceIPv4Address = 192.0.2.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | destinationIPv4Address = 192.0.2.3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sourceTransportPort = 32770 | destinationTransportPort = 80 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | protocol = 6 |semantic=allOf | Template ID = 266 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | dir = forward | flowStartSeconds = 2006-02-01 17:00:00 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | octetTotalCount = 18000 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | packetTotalCount = 65 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | dir = reverse | flowStartSeconds = ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... 2006-02-01 17:00:01 | octetTotalCount = 128000 ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | packetTotalCount = 110 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure B3: Biflow Data Set Encoded using Structured Data > > > Note that the Data Set length is 46, compared with 41 in RFC5103. > The five additional octets are due to the inclusion of the 8-bit > semantic, 16-bit Template ID and two, 8-bit direction indicators. > > Clearly structured data offers an alternative way to encode > Biflows. Although this may not be best suited if the number of > elements is small as in this example, it does offer a more robust > and scalable solution if multiple elements need to be encoded. I do not understand. The Data Record will always be larger than in the RFC5103 case. So, where is a scalability advantage? And where is a robustness advantage? In both cases, the flow information is included in one Data Record. > > Appendix C. Encoding IPS Alert using Structured Data Information > Elements > > In this section, an IPS alert example is used to demonstrate how > complex data and multiple levels of hierarchy can be encoded using > Structured Data Information Elements. Also, this example > demonstrates how a basicList of subTemplateLists can be used to > represent semantics at multiple levels in the hierarchy. > > An IPS alert consists of the following mandatory attributes: > signatureId, protocolIdentifier and riskRating. It can also > contain zero or more participants, each participant can contain > zero or more attackers and zero or more targets. An attacker > contains the attributes sourceIPv4Address and applicationId, and > a target contains the attributes destinationIPv4Address and > applicationId. > > Note that the signatureId and riskRating Information Element > fields are created for these examples only; the Field IDs are > shown as N/A. The signatureId helps to uniquely identify the IPS > signature that triggered the alert. The riskRating identifies the > potential risk, on a scale of 0-100 (100 being most serious), of > the traffic that triggered the alert. > > Consider the example described in case study 2 of Section 5.6. The > IPS alert contains participants encoded as a subTemplateList with > semantic allOf. Each participant uses a basicList of > subTemplateLists to represent attackers and targets. For the sake > of simplicity, the alert has two participants P1 and P2. In > participant P1, attacker A1 or A2 attack target T1. In > participant P2, attacker A3 attacks targets T2 and T3. > > Participant P1: > > (basicList, allof, > > (subTemplateList, exactlyOneOf, attacker A1, A2) > > (subTemplateList, undefined, target T1) > > ) > > Participant P2: > > (basicList, allOf, > > (subTemplateList, undefined, attacker A3, > (subTemplateList, allOf, targets T2, T3) > > ) > > Alert : > > (subTemplateList, allOf, Participant P1, Participant P2) > > > ------------------------------------------------------------------ > | | | participant > sigId |protocol| risk | attacker | target > | Id | Rating | IP | appId | IP | appId > ------------------------------------------------------------------ > 1003 17 10 192.0.2.3 103 192.0.2.103 3001 > 192.0.2.4 104 > > 192.0.2.5 105 192.0.2.104 4001 > 192.0.2.105 5001 > ------------------------------------------------------------------ > > Participant P1 contains: > Attacker A1: (IP, appID)=(192.0.2.3, 103) > Attacker A2: (IP, appID)=(192.0.2.4, 104) > Target T1: (IP, appID)= (192.0.2.103, 3001) > > Participant P2 contains: > Attacker A3: (IP, appID) = (192.0.2.5, 105) > Target T2: (IP, appID)= (192.0.2.104, 4001) > Target T3: (IP, appID)= (192.0.2.105, 5001) > > > To represent an alert, the following Templates are defined: > Template for target (268) > Template for attacker (269) > Template for participant (270) > Template for alert (271) > > alert (271) > | (signatureId) > | (protocolIdentifier) > | (riskRating) > | > +------- participant (270) > | > +------- attacker (269) > | (sourceIPv4Address) > | (applicationId) > | > +------- target (268) > | (destinationIPv4Address) > | (applicationId) > > Note that the attackers are always composed of a single > applicationId, while the targets typically have multiple > applicationId, for the sake of simplicity this example shows only > one applicationId in the target. > > Template Record for target, with the Template ID 268: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 16 octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 268 | Field Count = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| destinationIPv4Address = 12 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| applicationId = 95 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure C0: Encoding IPS Alert, Template for Target > > > Template Record for attacker, with the Template ID 269: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 16 octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 269 | Field Count = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceIPv4Address = 8 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| applicationId = 95 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure C1: Encoding IPS Alert, Template for Attacker > > > Template Record for participant, with the Template ID 270: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 12 octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 270 | Field Count = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| basicList = XXX | Field Length = 0xFFFF | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure C2: Encoding IPS Alert, Template for Participant > > > The Template Record for the participant has one basicList > Information Element, which is a list of subTemplateLists of > attackers and targets. > > Template Record for IPS alert, with the Template ID 271: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 24 octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 271 | Field Count = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| signatureId = N/A | Field Length = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| protocolIdentifier = 4 | Field Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| riskRating = N/A | Field Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| subTemplateList = YYY | Field Length = 0xFFFF | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure C3: Encoding IPS Alert, Template for IPS Alert > > The subTemplateList in the alert Template Record contains a list > of participants. > > The Length of basicList and subTemplateList are encoded in three > bytes even though they may be less than 255 octets. > > > The Data Set is represented as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 271 | Length = 102 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | signatureId = 1003 | protocolId=17 | riskRating=10 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 255 |participant List Length = 91 |semantic=allOf | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | participant Template ID = 270 | 255 | P1 List Len = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 41 | semantic=allOf| P1 List Field ID = YYY | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | P1 List Field ID Len = 0xFFFF | 255 |P1 attacker ...| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | List Len = 19 |sem=exactlyOne | P1 attacker Template ID = 269 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | P1 attacker A1 sourceIPv4Address = 192.0.2.3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | P1 attacker A1 applicationId = 103 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | P1 attacker A2 sourceIPv4Address = 192.0.2.4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | P1 attacker A2 applicationId = 104 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 255 | P1 target List Len = 11 | sem=undefined | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | P1 target Template ID = 268 | P1 target T1 destinationIPv4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... Address = 192.0.2.103 |P1 target T1 applicationId =...| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... 3001 | 255 | P2 List Len = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... 41 | semantic=allOf| P2 List Field ID = YYY | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | P2 List Field ID Len = 0xFFFF | 255 |P2 attacker ...| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | List Len = 11 | sem=undefined | P2 attacker Template ID = 269 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | P2 attacker A3 sourceIPv4Address = 192.0.2.5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | P2 attacker A3 applicationId = 105 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 255 | P2 target List Len = 19 |semantic=allOf | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | P2 target Template ID = 268 | P2 target T2 destinationIPv4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... Address = 192.0.2.104 |P2 target T2 applicationId =...| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... 4001 | P2 target T3 destinationIPv4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... Address = 192.0.2.105 |P2 target T3 applicationId =...| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... 5001 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure C4: Encoding IPS Alert, Data Set > --------------ms080408050207040100060704 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDcyNzA4MzE0MlowIwYJKoZIhvcNAQkEMRYEFKO/ t+57PN4ZTyqeR7Stn1Lp+vexMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQAIfCjtdgXwKIhhzLRQUHQYehujxqjJmiwrR3rSe960WM3AYwOGzfK7 l1nsP3HDAOJfUNz+6a2j670M3+qav28ExAKSwZTlF7uWCdpE5N7MUQWiygH5bjpZMkZ1Hz/G MvT0qWW3h8LjuhMnRcJm1we5W6PDUTzPfPFoxOgv4507ZsZ3CBK8dTD5jK+rv6tcB4AGdTMp 3lsbydoAFNkriXZl17oV3adJFtkMbC/vALdECA7r67ZMyMpxh7DMorH9EMV3wG9nn+6YbyQw //aBxqoc9ol9Pcufz8mTXnG8DHEz2PXmkHYktj0cYTGeWv2FtPomYgaGe4qtrW5RXQYNvfoX AAAAAAAA --------------ms080408050207040100060704-- From n.brownlee@auckland.ac.nz Tue Jul 27 01:43:09 2010 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 EDE233A6B87 for ; Tue, 27 Jul 2010 01:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 JEJs3a9HHIZU for ; Tue, 27 Jul 2010 01:43:04 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id B54103A6A69 for ; Tue, 27 Jul 2010 01:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1280220206; x=1311756206; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4C4E9C1F.70909@auckland.ac.nz>|Date:=20Tu e,=2027=20Jul=202010=2001:43:11=20-0700|From:=20Nevil=20B rownlee=20|MIME-Version:=201.0 |To:=20IPFIX=20list=20|Subject:=20Slide =20for=20Thursday's=20meeting,=20=20NMRG=20on=20Friday |Content-Transfer-Encoding:=207bit; bh=7cOo82ge3gHpC+wa82YKlGiwqXEeOSTCrCR2Ph5ceO4=; b=oVz97K1wgmR1qRAL0yZWh+p9YfvsUhb/MbGgV4pR9UwZVuVvmXbkQwlP 6zNoudjbivdHOklWdQq2vQ5a1KKMXfwH2Id6tdfLHfhfXOpOd3raiHgCw wa29wRUffM607eDUh4x7zQia1TIAi/cD36Hs5eBEMgbtMozjQ7POHjU+6 o=; X-IronPort-AV: E=Sophos;i="4.55,267,1278244800"; d="scan'208";a="17736763" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.133.236 - Outgoing - Outgoing-SSL Received: from dhcp-85ec.meeting.ietf.org (HELO [130.129.133.236]) ([130.129.133.236]) by mx2-int.auckland.ac.nz with ESMTP; 27 Jul 2010 20:43:17 +1200 Message-ID: <4C4E9C1F.70909@auckland.ac.nz> Date: Tue, 27 Jul 2010 01:43:11 -0700 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Slide for Thursday's meeting, NMRG on Friday 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, 27 Jul 2010 08:43:09 -0000 Hi all: 1. If you're presenting at the IPFIX meeting in Maastricht on Thursday, please email your slide to me real soon now, so that I can put them on the Meeting Materials page. 2. If you're at IETF 78, reminder: the NMRG sessions on Friday are a Workshop on Netflow/IPFIX Usage in Network Management Cheers, 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 muenz@net.in.tum.de Tue Jul 27 01:59:35 2010 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 1DB7C3A6A98 for ; Tue, 27 Jul 2010 01:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=1.750, 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 Q8auYCUbVqth for ; Tue, 27 Jul 2010 01:59:33 -0700 (PDT) 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 1ABD13A686B for ; Tue, 27 Jul 2010 01:59:33 -0700 (PDT) Received: from [130.129.113.123] (dhcp-717b.meeting.ietf.org [130.129.113.123]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 56607208AFDF; Tue, 27 Jul 2010 10:59:54 +0200 (CEST) Message-ID: <4C4EA02D.2080905@net.in.tum.de> Date: Tue, 27 Jul 2010 11:00:29 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brian Trammell References: <20100726141425.6475B3A6A04@core3.amsl.com> <6BED7FFC-E696-4A50-AD74-4A84E5EE583C@tik.ee.ethz.ch> In-Reply-To: <6BED7FFC-E696-4A50-AD74-4A84E5EE583C@tik.ee.ethz.ch> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000008050606040806020401" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-set9hack-00 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, 27 Jul 2010 08:59:35 -0000 This is a cryptographically signed message in MIME format. --------------ms000008050606040806020401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brian, Assume that the parser starts reading at a message header. Then, the first field is the version number A. The parser then may proceed as follows: if A =3D=3D 10 then parse IPFIX Message, skip Sets as necessary, expect next message header at ipfix_hdr->length offset else if A =3D=3D 9 then parse Netflow.v9 Message, skip Sets as necessary (using length), stop parsing if next "Set ID" is in the range 2..255 (because then, it is not a new Set but a new message header) end So, there does not seem to be a problem as long as no new Set IDs in Netflow.v9 are introduced (or at least no new Set IDs > 8). So, if you want to specify a restriction, why not specify it for Netflow.v9 instead of IPFIX? Regards, Gerhard Brian Trammell wrote: > Greetings, all, >=20 > See the abstract for details; there's a little (but not much) more in > the three-page draft itself. >=20 > Assume you have a file containing NetFlow V9 PDUs. Assume you'd like > to split it into packets by seeking. Well, you can't do this, really, > without completely parsing and counting records, because while Sets > have lengths, the count header in the Packet header counts records. > This implies a rather slow implementation for any V9 file reader, by > forcing any process reading V9 files to do all parsing in a single > pass. >=20 > There's a hack around this: since Set ID 9 is not valid in V9, you > can just assume Set ID 9 to be the Version of the next V9 Packet > header. When you see Set ID 9, that's a new Packet. Otherwise, it's a > set header, and the next set runs for the number of bytes in the set > header length. >=20 > All is well, but Set ID 9 might be allocated in the future, which > would cause this hack to break in a version-mixed file. (If we don't > want to support version mixing in files, why bother with a version > header?). So if we allocate Set ID 9 to reserved, we ensure this hack > can keep working. (While we're at it, let's allocate Set ID 10, so we > can recognize IPFIX as well.) >=20 > Okay. Yes. This is a hack. Why write it up in a draft? The Set ID > registry is modifiable only by Standards Action, so this would appear > to be the only way to make the change. >=20 > Thoughts? >=20 > Cheers, >=20 > Brian >=20 > Begin forwarded message: >=20 >> From: IETF I-D Submission Tool Date: July >> 26, 2010 4:14:25 PM GMT+02:00 To: trammell@tik.ee.ethz.ch Subject: >> New Version Notification for draft-trammell-ipfix-set9hack-00 >>=20 >>=20 >> A new version of I-D, draft-trammell-ipfix-set9hack-00.txt has been >> successfully submitted by Brian Trammell and posted to the IETF >> repository. >>=20 >> Filename: draft-trammell-ipfix-set9hack Revision: 00 Title: >> Reserved Set IDs to Enable Boundary Finding in Mixed IPFIX Files=20 >> Creation_date: 2010-07-26 WG ID: Independent Submission=20 >> Number_of_pages: 3 >>=20 >> Abstract: This document reserves the IPFIX Set IDs 9 and 10 to >> prevent them from being allocated in the future. The reason behind >> this is to ensure that heuristic methods for determining PDU >> boundaries in files containing NetFlow V9 PDUs and IPFIX Messages >> work in a standards- compliant way. >>=20 >>=20 >>=20 >> The IETF Secretariat. >>=20 >=20 > _______________________________________________ IPFIX mailing list=20 > IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --=20 Dr.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms000008050606040806020401 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDcyNzA5MDAyOVowIwYJKoZIhvcNAQkEMRYEFKvK 954HbB5xb3u+U35sPhQNzqVpMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQAdJot941n4/8nfsUN5amMDAnUTN6Fh59SoBBiDeGd2jWn2gZCi5dKb tC25KRk44BRO7VZiIWcH6OFR/ZsqojBkrQDP3tsLKYVolkLdn1tkQja4j08mJF9Z9pKuCTxs 8UvszSKeNYMWFXdSj/9yiDYdoyLHUk1slZj8Mf34SdJ0Aoz3jBkznr1GHA0E92BKhe+39WMD EQN/0yVt/b4LWUFcTcIDC+gyGWPGDmCdVh8INLbdaf9TJ21zeFloj2KGGl8zcrJD8cQd72sh ysi2usMhuFCwkqwywyw/bwzrl5Pn12Xb5NOOeVwn+xxf4VP4/1FScprSDqC+uxQqPlI2O5FW AAAAAAAA --------------ms000008050606040806020401-- From muenz@net.in.tum.de Tue Jul 27 02:17:24 2010 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 42F793A6BA2 for ; Tue, 27 Jul 2010 02:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=0.875, 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 mD5tr4+QW6cL for ; Tue, 27 Jul 2010 02:17:22 -0700 (PDT) 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 13F893A6AA9 for ; Tue, 27 Jul 2010 02:17:19 -0700 (PDT) Received: from [130.129.113.123] (dhcp-717b.meeting.ietf.org [130.129.113.123]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 4ACC0208AFD0 for ; Tue, 27 Jul 2010 11:17:40 +0200 (CEST) Message-ID: <4C4EA456.10509@net.in.tum.de> Date: Tue, 27 Jul 2010 11:18:14 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ipfix@ietf.org References: <4B9AC2F8.1090504@cisco.com> <4B9B87BD.7020201@net.in.tum.de> <4BA5584E.3060508@auckland.ac.nz> <4BA5611F.90309@cisco.com><4BA6A547.7050503@cisco.com> <4C2B118B.4050601@net.in.tum.de> <4C2C2C7F.8090202@auckland.ac.nz> <4C2C4D7A.7070604@net.in.tum.de> In-Reply-To: <4C2C4D7A.7070604@net.in.tum.de> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060907030101000201070505" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [IPFIX] IPFIX errata 2052 to 2059 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, 27 Jul 2010 09:17:24 -0000 This is a cryptographically signed message in MIME format. --------------ms060907030101000201070505 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Steps to do: - go to RFC editors - unverify errata 2052 to 2059, reject them instead - open and verify new errata on RFC5476: --- Section 8.1.2 says: Abstract Data Type: unsigned16 It should say: Abstract Data Type: unsigned32 Notes: Change selectorID from 16 bits to 32 bits per discussion on the IPFIX mailing list: http://www.ietf.org/mail-archive/web/ipfix/current/msg05509.html --- Who is going to do this? Gerhard Gerhard Muenz wrote: > Dear Nevil, > > As a further consequence, the status of errata 2053, 2054, 2055, 2056, > 2057, 2058, and 2059 (related to RFC 5476) should be "rejected" instead > of "verified". > > In the examples, we see selectorId with length = 4 (=32bit), so there is > no reduced size encoding. > > Thanks, > Gerhard > > > > Romascanu, Dan (Dan) wrote: >> Nevil, >> >> The way to do it is to 'unverify' errata 2052 - and I think that this >> can be done by the RFC Editor. Do you know anybody there? :-) Then I can >> reenter the proper resolution. Can you suggest the text that the WG >> reached consensus about? >> >> Thanks and Regards, >> >> Dan >> >> >> >> >>> -----Original Message----- >>> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] >>> On Behalf Of Nevil Brownlee >>> Sent: Thursday, July 01, 2010 8:50 AM >>> To: Gerhard Muenz >>> Cc: ipfix@ietf.org >>> Subject: Re: [IPFIX] IPFIX errata 2052 to 2059 >>> >>> >>> Hi Gerhard: >>> >>> Oh, Oh, .. looking back I see that when I asked Dan to verify >>> these errata, I gave him a confusing message, so it's been >>> verified incorrectly - consensus was (as you say below) for >>> unsigned32. >>> >>> I'll work out the best way to get errata 2052 corrected. >>> >>> Cheers, Nevil >>> >>> >>> Gerhard Muenz wrote: >>>> Dear all, >>>> >>>> I see unsigned64 as being verified in the errata, not unsigned32: >>>> http://www.rfc-editor.org/errata_search.php?rfc=5477 >>>> >>>> So, what's true now? >>>> >>>> Regards, >>>> Gerhard >>>> >>>> Benoit Claise wrote: >>>>> Nevil, >>>>>> Nevil, >>>>>> >>>>>>> I'm looking through our 'unverified' errata - do we have >>> consensus >>>>>>> for Paul's Errata 2052, i.e. change SelectorId to unsigned64? >>>>>> The consensus seems to be a change to unsigned32. >>>>> It's true that unsigned64 would have been better, and Thomas >>>>> highlighted a limitation with the MIB. >>>>> So let's go for unsigned32 then. >>>>> >>>>> Regards, Benoit. >>>>>> Thanks, >>>>>> P. --------------ms060907030101000201070505 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDcyNzA5MTgxNFowIwYJKoZIhvcNAQkEMRYEFLHt GBTtfZAg2X4FBXUmoiBSXWweMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQBtP3GNqosjCXZ1/75MQTDtjDEkPm/7l3lmBmFJQ+xeLhHwOioQ9nRT plbWPZtnJTM35akKPr7ArtnkJDwTRlcauH+MPsBhV4LqkGhaJzDifatW4uQDXZyYMW1a594j pLhi4UZG5/Fw4Nz/Kkc4jPHbevGxCYMGd3tGFRL1VwWi2C0FACyYanZ4L19IcdQ32/I4F36w PHftbm8wext4nSkgF9AlVP9MShC3dhYfPvi820mCriIiQbzqomsVzx90EVyNbtu3EZV0S69y vSLtO23R3SARyGux2CgN03KNjbIFPmSz6rJrpKSXlh0BdFvqGtzuiYG3LVPD47aVVgsvPFRZ AAAAAAAA --------------ms060907030101000201070505-- From trammell@tik.ee.ethz.ch Tue Jul 27 02:32:29 2010 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 DE3EB3A6A55 for ; Tue, 27 Jul 2010 02:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1709zjVym4Rc for ; Tue, 27 Jul 2010 02:32:27 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id BB2723A6AF6 for ; Tue, 27 Jul 2010 02:32:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 87E81D9388; Tue, 27 Jul 2010 11:32:47 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id grB5GA9G0LXo; Tue, 27 Jul 2010 11:32:47 +0200 (MEST) Received: from dhcp-62f2.meeting.ietf.org (dhcp-62f2.meeting.ietf.org [130.129.98.242]) (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 343F9D9385; Tue, 27 Jul 2010 11:32:47 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <4C4EA02D.2080905@net.in.tum.de> Date: Tue, 27 Jul 2010 11:32:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2764FDED-07CF-4C3A-A5B7-82800C47E829@tik.ee.ethz.ch> References: <20100726141425.6475B3A6A04@core3.amsl.com> <6BED7FFC-E696-4A50-AD74-4A84E5EE583C@tik.ee.ethz.ch> <4C4EA02D.2080905@net.in.tum.de> To: Gerhard Muenz X-Mailer: Apple Mail (2.1081) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-set9hack-00 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, 27 Jul 2010 09:32:29 -0000 Hi, Gerhard, Because I have no control over Netflow V9. :) However, if we are to = assume that the definition/primary implementation of NetFlow V9 will not = define any Set IDs lower than 256 other than 0 or 1, then you're right. = In the absence of other information, I think we can assume this. :) (My issue here is that I have been forced to implement this particular = hack, and since there's no other good way to deal with V9 files using = other than a one-pass, unified parser design, it would be nice to have = some confidence that the hack will continue working in the future) Per our conversation yesterday, I also agree that mixed files = themselves, containing V5/9/IPFIX records, would violate at least a = SHOULD in RFC5655 - V5 and V9 PDUs can by definition not share a = Transport Session with IPFIX Messages (the template scope etc. are = exclusive), and therefore should not share a (5655) File. Cheers, B On Jul 27, 2010, at 11:00 AM, Gerhard Muenz wrote: >=20 > Brian, >=20 > Assume that the parser starts reading at a message header. > Then, the first field is the version number A. The parser then may > proceed as follows: >=20 > if A =3D=3D 10 then > parse IPFIX Message, skip Sets as necessary, > expect next message header at ipfix_hdr->length offset > else if A =3D=3D 9 then > parse Netflow.v9 Message, skip Sets as necessary (using length), > stop parsing if next "Set ID" is in the range 2..255 (because then, = it > is not a new Set but a new message header) > end >=20 > So, there does not seem to be a problem as long as no new Set IDs in > Netflow.v9 are introduced (or at least no new Set IDs > 8). >=20 > So, if you want to specify a restriction, why not specify it for > Netflow.v9 instead of IPFIX? >=20 > Regards, > Gerhard >=20 > Brian Trammell wrote: >> Greetings, all, >>=20 >> See the abstract for details; there's a little (but not much) more in >> the three-page draft itself. >>=20 >> Assume you have a file containing NetFlow V9 PDUs. Assume you'd like >> to split it into packets by seeking. Well, you can't do this, really, >> without completely parsing and counting records, because while Sets >> have lengths, the count header in the Packet header counts records. >> This implies a rather slow implementation for any V9 file reader, by >> forcing any process reading V9 files to do all parsing in a single >> pass. >>=20 >> There's a hack around this: since Set ID 9 is not valid in V9, you >> can just assume Set ID 9 to be the Version of the next V9 Packet >> header. When you see Set ID 9, that's a new Packet. Otherwise, it's a >> set header, and the next set runs for the number of bytes in the set >> header length. >>=20 >> All is well, but Set ID 9 might be allocated in the future, which >> would cause this hack to break in a version-mixed file. (If we don't >> want to support version mixing in files, why bother with a version >> header?). So if we allocate Set ID 9 to reserved, we ensure this hack >> can keep working. (While we're at it, let's allocate Set ID 10, so we >> can recognize IPFIX as well.) >>=20 >> Okay. Yes. This is a hack. Why write it up in a draft? The Set ID >> registry is modifiable only by Standards Action, so this would appear >> to be the only way to make the change. >>=20 >> Thoughts? >>=20 >> Cheers, >>=20 >> Brian >>=20 >> Begin forwarded message: >>=20 >>> From: IETF I-D Submission Tool Date: July >>> 26, 2010 4:14:25 PM GMT+02:00 To: trammell@tik.ee.ethz.ch Subject: >>> New Version Notification for draft-trammell-ipfix-set9hack-00 >>>=20 >>>=20 >>> A new version of I-D, draft-trammell-ipfix-set9hack-00.txt has been >>> successfully submitted by Brian Trammell and posted to the IETF >>> repository. >>>=20 >>> Filename: draft-trammell-ipfix-set9hack Revision: 00 = Title: >>> Reserved Set IDs to Enable Boundary Finding in Mixed IPFIX Files=20 >>> Creation_date: 2010-07-26 WG ID: Independent = Submission=20 >>> Number_of_pages: 3 >>>=20 >>> Abstract: This document reserves the IPFIX Set IDs 9 and 10 to >>> prevent them from being allocated in the future. The reason behind >>> this is to ensure that heuristic methods for determining PDU >>> boundaries in files containing NetFlow V9 PDUs and IPFIX Messages >>> work in a standards- compliant way. >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat. >>>=20 >>=20 >> _______________________________________________ IPFIX mailing list=20 >> IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix >=20 > --=20 > Dr.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Technische Universit=E4t M=FCnchen - Department of Informatics > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz >=20 >=20 From dromasca@avaya.com Tue Jul 27 05:12:26 2010 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 1E2DA3A6A51 for ; Tue, 27 Jul 2010 05:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 pGmV0VQ1XDt6 for ; Tue, 27 Jul 2010 05:12:24 -0700 (PDT) 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 662C53A6B8B for ; Tue, 27 Jul 2010 05:12:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,267,1278302400"; d="scan'208";a="229822079" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Jul 2010 08:12:35 -0400 X-IronPort-AV: E=Sophos;i="4.55,267,1278302400"; d="scan'208";a="486160802" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 27 Jul 2010 08:12:34 -0400 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: Tue, 27 Jul 2010 14:12:23 +0200 Message-ID: In-Reply-To: <4C4EA456.10509@net.in.tum.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] IPFIX errata 2052 to 2059 Thread-Index: AcstbJvErz2ZBb1TSLONORx7L7hQWQAGD6HA References: <4B9AC2F8.1090504@cisco.com> <4B9B87BD.7020201@net.in.tum.de> <4BA5584E.3060508@auckland.ac.nz> <4BA5611F.90309@cisco.com><4BA6A547.7050503@cisco.com> <4C2B118B.4050601@net.in.tum.de><4C2C2C7F.8090202@auckland.ac.nz> <4C2C4D7A.7070604@net.in.tum.de> <4C4EA456.10509@net.in.tum.de> From: "Romascanu, Dan (Dan)" To: "Gerhard Muenz" , Subject: Re: [IPFIX] IPFIX errata 2052 to 2059 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, 27 Jul 2010 12:12:26 -0000 Please do it if you can (by message or by going to their booth in Maastricht), refer them to me for approval if they need.=20 Thanks and Regards, Dan =20 > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org]=20 > On Behalf Of Gerhard Muenz > Sent: Tuesday, July 27, 2010 12:18 PM > To: ipfix@ietf.org > Subject: Re: [IPFIX] IPFIX errata 2052 to 2059 >=20 >=20 > Hi, >=20 > Steps to do: >=20 > - go to RFC editors > - unverify errata 2052 to 2059, reject them instead > - open and verify new errata on RFC5476: >=20 > --- >=20 > Section 8.1.2 says: >=20 > Abstract Data Type: unsigned16 >=20 > It should say: >=20 > Abstract Data Type: unsigned32 >=20 > Notes: >=20 > Change selectorID from 16 bits to 32 bits per discussion on=20 > the IPFIX mailing list: >=20 > http://www.ietf.org/mail-archive/web/ipfix/current/msg05509.html >=20 > --- >=20 > Who is going to do this? >=20 > Gerhard >=20 >=20 > Gerhard Muenz wrote: > > Dear Nevil, > >=20 > > As a further consequence, the status of errata 2053, 2054,=20 > 2055, 2056,=20 > > 2057, 2058, and 2059 (related to RFC 5476) should be "rejected"=20 > > instead of "verified". > >=20 > > In the examples, we see selectorId with length =3D 4=20 > (=3D32bit), so there=20 > > is no reduced size encoding. > >=20 > > Thanks, > > Gerhard > >=20 > >=20 > >=20 > > Romascanu, Dan (Dan) wrote: > >> Nevil, > >> > >> The way to do it is to 'unverify' errata 2052 - and I=20 > think that this=20 > >> can be done by the RFC Editor. Do you know anybody there?=20 > :-) Then I=20 > >> can reenter the proper resolution. Can you suggest the=20 > text that the=20 > >> WG reached consensus about? > >> > >> Thanks and Regards, > >> > >> Dan > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On=20 > >>> Behalf Of Nevil Brownlee > >>> Sent: Thursday, July 01, 2010 8:50 AM > >>> To: Gerhard Muenz > >>> Cc: ipfix@ietf.org > >>> Subject: Re: [IPFIX] IPFIX errata 2052 to 2059 > >>> > >>> > >>> Hi Gerhard: > >>> > >>> Oh, Oh, .. looking back I see that when I asked Dan to=20 > verify these=20 > >>> errata, I gave him a confusing message, so it's been verified=20 > >>> incorrectly - consensus was (as you say below) for unsigned32. > >>> > >>> I'll work out the best way to get errata 2052 corrected. > >>> > >>> Cheers, Nevil > >>> > >>> > >>> Gerhard Muenz wrote: > >>>> Dear all, > >>>> > >>>> I see unsigned64 as being verified in the errata, not unsigned32: > >>>> http://www.rfc-editor.org/errata_search.php?rfc=3D5477 > >>>> > >>>> So, what's true now? > >>>> > >>>> Regards, > >>>> Gerhard > >>>> > >>>> Benoit Claise wrote: > >>>>> Nevil, > >>>>>> Nevil, > >>>>>> > >>>>>>> I'm looking through our 'unverified' errata - do we have > >>> consensus > >>>>>>> for Paul's Errata 2052, i.e. change SelectorId to unsigned64? > >>>>>> The consensus seems to be a change to unsigned32. > >>>>> It's true that unsigned64 would have been better, and Thomas=20 > >>>>> highlighted a limitation with the MIB. > >>>>> So let's go for unsigned32 then. > >>>>> > >>>>> Regards, Benoit. > >>>>>> Thanks, > >>>>>> P. >=20 From n.brownlee@auckland.ac.nz Wed Jul 28 02:31:36 2010 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 83D6328C15B for ; Wed, 28 Jul 2010 02:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 GcGkDsoznji9 for ; Wed, 28 Jul 2010 02:31:34 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 2579128C15C for ; Wed, 28 Jul 2010 02:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1280309504; x=1311845504; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; z=Message-ID:=20<4C4FF8EC.1060607@auckland.ac.nz>|Date:=20 Wed,=2028=20Jul=202010=2002:31:24=20-0700|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20list=20|Subject:=20R eminder:=20Slides=20for=20Thursday's=20meeting, |References:=20<4C4E9C1F.70909@auckland.ac.nz> |In-Reply-To:=20<4C4E9C1F.70909@auckland.ac.nz> |Content-Transfer-Encoding:=207bit; bh=aASV7xvmBKjSOxYE9KNRRqYDfHGTvEiGuNx61UeCuPw=; b=XQP8H1THdPWUo3MXVN3gTwFK5VwY5Nb/C39ZMVJExX6ZUwsq1R9Kti5n IZDw75+wQf+j2jSr8hgMS7YvV8jrJxxQ9kk4etzZb2r/ZDyNwdKHR9n2w ZfkyLZTmAQwwrmcqxN6c4WwSf2QOdzQn8zuCFqbqEUXMhuK60uErH3GiG U=; X-IronPort-AV: E=Sophos;i="4.55,273,1278244800"; d="scan'208";a="17946885" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.133.236 - Outgoing - Outgoing-SSL Received: from dhcp-85ec.meeting.ietf.org (HELO [130.129.133.236]) ([130.129.133.236]) by mx2-int.auckland.ac.nz with ESMTP; 28 Jul 2010 21:31:26 +1200 Message-ID: <4C4FF8EC.1060607@auckland.ac.nz> Date: Wed, 28 Jul 2010 02:31:24 -0700 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IPFIX list References: <4C4E9C1F.70909@auckland.ac.nz> In-Reply-To: <4C4E9C1F.70909@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Reminder: Slides for Thursday's 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, 28 Jul 2010 09:31:36 -0000 Hi all: We have four presentations on the Meeting Materials page so far, thanks to those who've sent them to me. Please can I have any further slides sets soon ... Cheers, 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 bclaise@cisco.com Wed Jul 28 13:35:41 2010 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 D303B3A6849 for ; Wed, 28 Jul 2010 13:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.144, 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 bH4PanKKX7E0 for ; Wed, 28 Jul 2010 13:35:35 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 9D01D3A67F8 for ; Wed, 28 Jul 2010 13:35:34 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o6SKZvlT028175 for ; Wed, 28 Jul 2010 22:35:57 +0200 (CEST) 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 o6SKZuSY028165; Wed, 28 Jul 2010 22:35:56 +0200 (CEST) Message-ID: <4C5094AC.2020803@cisco.com> Date: Wed, 28 Jul 2010 22:35:56 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Rahul Patel (rahulp)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070801020405010706010505" Cc: ipfix@ietf.org Subject: Re: [IPFIX] WG LC for IPFIX structured data 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, 28 Jul 2010 20:35:41 -0000 This is a multi-part message in MIME format. --------------070801020405010706010505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Rahul, Thank you very much for your review. See my replies in line. > > Resending it. > > -Rahul > > *From:* Rahul Patel (rahulp) > *Sent:* Monday, July 19, 2010 11:49 AM > *To:* 'ipfix@ietf.org' > *Subject:* WG LC for IPFIX structured data > > Few comments on Rev2 > > comment #1: > > =========== > > Page 45-46: > > " Selection Sequence 7 (Filter->Sampling): > > observation point: subTemplateMultiList. > > Router 1, (interface 1) > > Router 2, (line card A) > > Router 3, (line card B) > > Router 4, (line card C, interface 2) > > selectorId: 5 (Filter, match IPV4SourceAddress 192.0.2.1) > > selectorId: 10 (Sampler, Random 1 out-of ten) > > The following Templates are defined to represent the PSAMP SSRI: > > Template for representing PSAMP SSRI: 262 > > Template for representing interface: 263 > > " > > Rahul# Wouldn't it be better to include RouterID in addition to > > Interface and/or linecard in the example. Without router id interface > > has no meaning unless interfaces are unique across routers which is > > unlikely. > OLD: PSAMP SSRI (262) | (SelectionSequenceId) | +--- Observation Point 1 (263) | (Interface Id) | +--- Observation Point 2 and 3 (264) | (line card) | +--- Observation Point 4 (265) | (line card) | (Interface Id) | | (selectorId 1) | (selectorId 2) NEW: PSAMP SSRI (262) | (SelectionSequenceId) | +--- Observation Point 1 (263) | (exporterIPv4Address) | (Interface Id) | +--- Observation Point 2 and 3 (264) | (exporterIPv4Address) | (line card) | +--- Observation Point 4 (265) | (exporterIPv4Address) | (line card) | (Interface Id) | | (selectorId 1) | (selectorId 2) This would good enough? Or you want the full example, with (subTemplateMultiList, exactlyOneOf, exporterIPv4Address, exporterIPv6Address)? This would be: PSAMP SSRI (262) | (SelectionSequenceId) | +--- Exporter IPv4 address (262) | (exporterIPv4Address) | +--- Exporter IPv6 address (263) | (exporterIPv6Address) | +--- Observation Point 1 (264) | (Interface Id) | +--- Observation Point 2 and 3 (265) | (line card) | +--- Observation Point 4 (266) | (line card) | (Interface Id) | | (selectorId 1) | (selectorId 2) > comment #2 > > ========== > > Page 46 > > " Note that the Data Record above contains multiple instances of > > Template 264 to represent Observation Point 2 (line card A) and > > Observation Point 3 (line card B). Instead, if a single > > Observation Point had both line card A and line card B, a > > basicList would be used to represent the list of line cards. > > " > > Rahul# There is an implicit assumption that each record belongs to a > > different router. > You're right, the example shows so. > > That is why you would have to use basicList if line > > card A and line card B were to be on OB Point 2. > Right. Alternatively, the proposals above would solve this by repeating the exporterIPv4Address > > Comment #3 > > ========== > > Page 46 > > Rahul# In the same example (above), instead of 'allof" if "ordered" is > > used then does it imply that there is order in template 264 (line card A, > > line card B) even though it is just a regular template? > Yes. > > Comment #4 > > =========== > > Page 16 > > " Another example is a router that monitors some specific BGP AS- > > PATHs and reports if a Flow belongs to any of them. If the router > > wants to export that a Flow does not belong to any of the > > monitored BGP AS-PATHs, the router reports a Data Record with a > > basicList composed of (BGP AS-PATH 1, BGP AS-PATH 2, BGP AS-PATH > > 3) and the respective Structured Data type semantic of "noneOf". > > " > > Rahul# If there are many flows which are exported with "noneOf" then that > > would not be efficient because each flow is carring path1, path2 and > path3. > > Can you do following? How? > > List of flows that didn't > > match monitored AS paths -> AS_PATH { path1, path2, path3} > > -> Flows > > - Flow1 > > - Flow2 > > - Flow3 > > - Flow4 > How would you express this semantically? (allOf, Flows) allOf (noOff, BGP AS) (allOf, Flows) none (allOf, BGP AS) From there, we could map it with a basicList of subTemplateMultiList. Regards, Benoit. > > -Rahul > --------------070801020405010706010505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Rahul,

Thank you very much for your review.
See my replies in line.

Resending it.

 

-Rahul

 

From: Rahul Patel (rahulp)
Sent: Monday, July 19, 2010 11:49 AM
To: 'ipfix@ietf.org'
Subject: WG LC for IPFIX structured data

 

Few comments on Rev2

 

comment #1:

===========

 

Page 45-46:

"       Selection Sequence 7 (Filter->Sampling): 

         observation point: subTemplateMultiList. 

                              Router 1, (interface 1) 

                              Router 2, (line card A) 

                              Router 3, (line card B)

                              Router 4, (line card C, interface 2) 

         selectorId: 5 (Filter, match IPV4SourceAddress 192.0.2.1) 

         selectorId: 10 (Sampler, Random 1 out-of ten)

       

      The following Templates are defined to represent the PSAMP SSRI:

      Template for representing PSAMP SSRI: 262

      Template for representing interface: 263

"

 

Rahul# Wouldn't it be better to include RouterID in addition to

Interface and/or linecard in the example. Without router id interface

has no meaning unless interfaces are unique across routers which is

unlikely.


OLD:
 
           PSAMP SSRI (262)
              | (SelectionSequenceId)
              |
              +--- Observation Point 1 (263)
              |      (Interface Id)
              |
              +--- Observation Point 2 and 3 (264)
              |      (line card)
              |
              +--- Observation Point 4 (265)
              |      (line card)
              |      (Interface Id)
              |
              | (selectorId 1)
              | (selectorId 2)

NEW:
 
           PSAMP SSRI (262)
              | (SelectionSequenceId)
              |
              +--- Observation Point 1 (263)
              |      (exporterIPv4Address)
              |      (Interface Id)
              |
              +--- Observation Point 2 and 3 (264)
              |      (exporterIPv4Address)
              |      (line card)
              |
              +--- Observation Point 4 (265)
              |      (exporterIPv4Address)
              |      (line card)
              |      (Interface Id)
              |
              | (selectorId 1)
              | (selectorId 2)

This would good enough?
Or you want the full example,  with (subTemplateMultiList, exactlyOneOf, exporterIPv4Address, exporterIPv6Address)?
This would be:
           PSAMP SSRI (262)
              | (SelectionSequenceId)
              |
              +--- Exporter IPv4 address (262)
              |      (exporterIPv4Address)
              |
              +--- Exporter IPv6 address (263)
              |      (exporterIPv6Address)
              |
              +--- Observation Point 1 (264)
              |      (Interface Id)
              |
              +--- Observation Point 2 and 3 (265)
              |      (line card)
              |
              +--- Observation Point 4 (266)
              |      (line card)
              |      (Interface Id)
              |
              | (selectorId 1)
              | (selectorId 2)


 

 

comment #2

==========

 

Page 46

"      Note that the Data Record above contains multiple instances of

      Template 264 to represent Observation Point 2 (line card A) and

      Observation Point 3 (line card B).  Instead, if a single

      Observation Point had both line card A and line card B, a

      basicList would be used to represent the list of line cards.

"

 

Rahul# There is an implicit assumption that each record belongs to a

different router.

You're right, the example shows so.

That is why you would have to use basicList if line

card A and line card B were to be on OB Point 2.

Right.
Alternatively, the proposals above would solve this by repeating the exporterIPv4Address

 

 

Comment #3

==========

Page 46

 

 

Rahul# In the same example (above), instead of 'allof" if "ordered" is

used then does it imply that there is order in template 264 (line card A,

line card B) even though it is just a regular template?

Yes.

 

Comment #4

===========

Page 16

“     Another example is a router that monitors some specific BGP AS-

     PATHs and reports if a Flow belongs to any of them.  If the router

     wants to export that a Flow does not belong to any of the

     monitored BGP AS-PATHs, the router reports a Data Record with a

     basicList composed of (BGP AS-PATH 1, BGP AS-PATH 2, BGP AS-PATH

     3) and the respective Structured Data type semantic of "noneOf".

“

 

Rahul# If there are many flows which are exported with “noneOf” then that

would not be efficient because each flow is carring path1, path2 and path3.

Can you do following? How?

 

List of flows that didn’t

match monitored AS paths -> AS_PATH { path1, path2, path3}

                        -> Flows

                               - Flow1

                               - Flow2

                               - Flow3

                               - Flow4

How would you express this semantically?
    (allOf, Flows) allOf (noOff, BGP AS)
    (allOf, Flows) none (allOf, BGP AS)
>From there, we could map it with a basicList of subTemplateMultiList.

Regards, Benoit.

 

-Rahul


--------------070801020405010706010505-- From bclaise@cisco.com Wed Jul 28 14:08:09 2010 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 5CA313A684A for ; Wed, 28 Jul 2010 14:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-zdrSCHgYZl for ; Wed, 28 Jul 2010 14:08:09 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 753173A6844 for ; Wed, 28 Jul 2010 14:08:07 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o6SL8Tkj001303; Wed, 28 Jul 2010 23:08:29 +0200 (CEST) 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 o6SL8L21001063; Wed, 28 Jul 2010 23:08:21 +0200 (CEST) Message-ID: <4C509C44.5010905@cisco.com> Date: Wed, 28 Jul 2010 23:08:20 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Gerhard Muenz References: <4C4E996E.2000300@net.in.tum.de> In-Reply-To: <4C4E996E.2000300@net.in.tum.de> Content-Type: multipart/alternative; boundary="------------040200090604060200060109" Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Review: draft-ietf-ipfix-structured-data-02.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: Wed, 28 Jul 2010 21:08:09 -0000 This is a multi-part message in MIME format. --------------040200090604060200060109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, I'm impressed by your review. I can see that you spent quite some time. Let me address the biggest issue in this email thread. > Dear Benoit, all, > > Here is my review of draft-ietf-ipfix-structured-data-02. It mainly > consists of suggestions and comments regarding the comprehensibility and > language. > > There is one suggestion about the specification itself. I think that it > would be easier to understand if the meaning of the semantic of > subTemplateList and subTemplateMultiList would be the same, namely that > it specifies the semantic among the Data Records. At the moment, the > draft specifies (although not very clearly) that the semantic refers to > goups of Data Records associated to different Templates in the case of > the subTemplateMultiList. I do not see a use-case for this. Also, no > useful example is provided. On the contrary, it is always said that the > semantic of subTemplateMultiList is not sufficient. > That's an important one, to be discussed at the meeting tomorrow. A use case could be a middle box function on a router, for which we want to export the series of flow records before the function, and the new series of flow records (*) after the function. (*) a WAN optimization function could produce a completely different set of flow records, potentially because you encapsulate everything into a new transport. Note that we give a workaround if we need two levels of semantics. Semantic The Semantic indicates the top level semantic among Template Records, i.e. the relationship among the series of Data Records from the different Template Records within this Structured Data. Note: if a semantic is required to describe the relationship among the different Data Records corresponding to a single Template ID within the subTemplateMultiList, then an encoding based on a basicList of subTemplateLists should be used. Refer toSection 5.6 for more information. I'll have some slides tomorrow to explain this issue. Regards, Benoit. > Regards, > Gerhard > > > >> 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. >> > Maybe add some words about semantics? > > >> 1. Overview >> >> 1.1. IPFIX Documents Overview >> >> The IPFIX Protocol [RFC5101] provides network administrators with >> access to IP Flow information. >> >> The architecture for the export of measured IP Flow information >> out of an IPFIX Exporting Process to a Collecting Process is >> defined in the IPFIX Architecture [RFC5470], per the requirements >> defined in RFC 3917 [RFC3917]. >> >> The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records >> and Templates are carried via a congestion-aware transport >> protocol from IPFIX Exporting Processes to IPFIX Collecting >> Processes. >> >> IPFIX has a formal description of IPFIX Information Elements, >> their name, type and additional semantic information, as specified >> in the IPFIX information model [RFC5102]. >> >> In order to gain a level of confidence in the IPFIX >> implementation, probe the conformity and robustness, and allow >> interoperability, the Guidelines for IPFIX Testing [RFC5471] >> presents a list of tests for implementers of compliant Exporting >> Processes and Collecting Processes. >> >> The Bidirectional Flow Export [RFC5103] specifies a method for >> exporting bidirectional flow (biflow) information using the IP >> Flow Information Export (IPFIX) protocol, representing each Biflow >> using a single Flow Record. >> >> The "Reducing Redundancy in IP Flow Information Export (IPFIX) and >> Packet Sampling (PSAMP) Reports" [RFC5473] specifies a bandwidth >> saving method for exporting Flow or packet information, by >> separating information common to several Flow Records from >> information specific to an individual Flow Record: common Flow >> information is exported only once. >> >> >> 1.2. Relationship between IPFIX and PSAMP >> >> The specification in this document applies to the IPFIX protocol >> specifications [RFC5101]. All specifications from [RFC5101] apply >> unless specified otherwise in this document. >> >> The Packet Sampling (PSAMP) protocol [RFC5476] specifies the >> export of packet information from a PSAMP Exporting Process to a >> PSAMP Collecting Process. Like IPFIX, PSAMP has a formal >> description of its information elements, their name, type and >> additional semantic information. The PSAMP information model is >> defined in [RFC5477]. >> >> As the PSAMP protocol specifications [RFC5476] are based on the >> IPFIX protocol specifications, the specifications in this document >> are also valid for the PSAMP protocol. >> >> Indeed, the major difference between IPFIX and PSAMP is that the >> IPFIX protocol exports Flow Records while the PSAMP protocol >> exports Packet Reports. From a pure export point of view, IPFIX >> will not distinguish a Flow Record composed of several packets >> aggregated together, from a Flow Record composed of a single >> packet. So the PSAMP export can be seen as a special IPFIX Flow >> Record containing information about a single packet. >> >> >> 2. Terminology >> >> IPFIX-specific terminology used in this document is defined in >> Section 2 of the IPFIX protocol specification [RFC5101] and >> Section 3 of PSAMP protocol specification [RFC5476]. As in >> [RFC5101], these IPFIX-specific terms have the first letter of a >> word capitalized when used in this document. >> >> >> 2.1. New Terminology >> >> Structured Data Information Element >> >> One of the Information Elements supporting structured data, >> i.e., the basicList, subTemplateList, or subTemplateMultiList >> Information Elements specified in section 4.3. >> >> >> 3. Introduction >> >> While collecting the interface counters every five minutes has >> proven to be useful in the past, more and more granular >> information is required from network elements for a series of >> applications: performance assurance, capacity planning, security, >> billing, or simply monitoring. However, the amount of information >> has become so important that, when dealing with highly granular >> information such as Flow information, a push mechanism (as opposed >> to a pull mechanism, such as SNMP) is the only solution for >> routers whose primary function is to route packets. Indeed, >> polling short-live Flows via SNMP is not an option: high end >> routers can support hundreds of thousands of Flows simultaneously. >> Furthermore, in order to reduce the export bandwidth requirements, >> the network elements have to integrate mediation functions to >> aggregate the collected information, both in space and time. >> >> Typically, it would be beneficial if access routers could export >> Flow Records, composed of the counters before and after the WAN >> optimization mechanism, instead of exporting two Flow Records with >> identical tuple information. >> > It is not clear what "the WAN optimization mechanism" is. > > >> In terms of aggregation in time, let us imagine that, for >> performance assurance, the network management application must >> receive the performance metrics associated with a specific flow, >> every millisecond. Since the performance metrics will be >> constantly changing, there is a new dimension to the Flow >> definition: we are not dealing anymore with a single Flow lasting >> a few seconds or a few minutes, but with a multitude of one >> millisecond sub flows for which the performance metrics are >> reported. >> >> Which current protocol is suitable for these requirements: push >> mechanism, highly granular information, and huge number of similar >> records? IPFIX, as specified in RFC5101 would give part of the >> solution. >> >> >> 3.1. The IPFIX Track >> >> The IPFIX working group has specified a protocol to export IP Flow >> information [RFC5101]. This protocol is designed to export >> information about IP traffic Flows and related measurement data, >> where a Flow is defined by a set of key attributes (e.g. source >> and destination IP address, source and destination port, etc.). >> >> The IPFIX protocol specification [RFC5101] specifies that IP >> traffic measurements for Flows are exported using a TLV (type, >> length, value) format. The information is exported using a >> Template Record that is sent once to export the {type, length} >> pairs that define the data format for the Information Elements in >> a Flow. The Data Records specify values for each Flow. >> >> Based on the Requirements for IP Flow Information Export (IPFIX) >> [RFC3917], the IPFIX protocol has been optimized to export Flow >> related information. However, thanks to its Template mechanism, >> the IPFIX protocol can export any type of information, as long as >> the relevant Information Element is specified in the IPFIX >> information model [RFC5102], registered with IANA [IANA-IPFIX], or >> specified as an enterprise-specific Information Element. For each >> Information Element, the IPFIX information model [RFC5102] defines >> a numeric identifier, an abstract data type, an encoding mechanism >> for the data type, and any semantic constraints. Only basic, >> single-valued data types, e.g., numbers, strings, and network >> addresses are currently supported. >> >> >> 3.2. The IPFIX Limitations >> >> The IPFIX protocol specification [RFC5101] does not support the >> encoding of hierarchical structured data and arbitrary-length >> lists (sequences) of Information Elements as fields within a >> Template Record. As it is currently specified, a Data Record is a >> "flat" list of single-valued attributes. However, it is a common >> data modeling requirement to compose complex hierarchies of data >> types, with multiple occurrences, e.g., 0..* cardinality allowed >> for instances of each Information Element in the hierarchy. >> >> A typical example is the MPLS label stack entries model. An early >> NetFlow implementation used two Information Elements to represent >> the MPLS label stack entry: a "label stack entry position" >> followed by a "label stack value". However, several drawbacks >> were discovered. Firstly, the Information Elements in the >> Template Record had to be imposed so that the position would >> always precede the value. However, some encoding optimizations >> are based on the permutation of Information Element order. >> Secondly, a new semantic intelligence, not described in the >> information model, had to be hardcoded in the Collecting Process: >> the label value at the position "X" in the stack is contained in >> the "label stack value" Information Element following by a "label >> stack entry position" Information Element containing the value >> "X". Therefore, this model was abandoned. >> >> The selected solution in the IPFIX information model [RFC5102] is >> a long series of Information Elements: mplsTopLabelStackSection, >> mplsLabelStackSection2, mplsLabelStackSection3, >> mplsLabelStackSection4, mplsLabelStackSection5, >> mplsLabelStackSection6, mplsLabelStackSection7, >> mplsLabelStackSection8, mplsLabelStackSection9, >> mplsLabelStackSection10. While this model removes any ambiguity, >> it overloads the IPFIX information model with repetitive >> information. Furthermore, if mplsLabelStackSection11 is required, >> IANA [IANA-IPFIX] will not be able to assign the new Information >> Element next to the other ones in the registry, which might cause >> some confusion. >> >> Clearly a real structured data type composed of ("label stack >> entry position", "label stack value") pairs, potentially repeated >> multiple times in Flow Records would be more efficient from an >> information model point of view. >> >> Some more examples enter the same category: how to encode the list >> of output interfaces in a multicast Flow, how to encode the list >> of BGP Autonomous Systems (AS) in a BGP Flow, how to encode the >> BGP communities in a BGP Flow, etc? >> >> The one-way delay passive measurement, which is described in the >> IPFIX Applicability [RFC5472], is yet another example that would >> benefit from a structured data encoding. Assuming synchronized >> clocks, the Collector can deduce the one-way delay from the >> following two Information Elements, collected from two different >> Observation Points: >> - Packet arrival time: observationTimeMicroseconds [RFC5477] >> - Packet ID: digestHashValue [RFC5477] >> Ideally, the measurement at the second Observation Point should >> start a little bit later than at the first Observation Point, >> allowing the packets to arrive at the destination. >> > I do not understand this sentence. How does the measurement affect > packet forwarding? How can the measurement allow packets to arrive > somewhere? > > >> In practice, >> this implies that many pairs of (observationTimeMicroseconds, >> digestHashValue) must be exported for each Observation Point, even >> if some optimization based on Hash-Based Filtering [RFC5475] is >> used. >> > What can be "optimized" by HBF? > > Maybe: "...even if Hash-Based Filtering is used." > > >> Instead of exporting repetitive information as part of >> every single Flow Record (for example, the 5 tuple), an optimized >> > I suggest to remove all occurrences of "optimize", "optimization" etc. > unless there is a metric based on which you optimize and unless you can > tell whether you reach a global optimum or a local optimum. > > >> flow record composed of a structured data type such as the >> following would save a lot of bandwidth: >> >> 5 tuple >> > It would be good to explain what "5 tuple" means. > > >> { observationTimeMicroseconds 1, digestHashValue 1 } >> { observationTimeMicroseconds 2, digestHashValue 2 } >> { observationTimeMicroseconds 3, digestHashValue 3 } >> { ... , ... } >> > The example has remaind unclear to me until I understood what you > describe here. In particular, it is not obvious to me that OWD > measurements are exported in Flow Records together with the 5 tuple. > > If you perform OWD measurements, isn't it sufficient to just export > digestHashValue and observationTimeMicroseconds? > > Also, if you talk about Flow Records here, you actually mean PSAMP > Packet Report (i.e. one packet Flow), right? This is not explained. > > >> As a last example, here is a more complex case of hierarchical >> structured data encoding. Consider the example scenario of an IPS >> (Intrusion Prevention System) alert data structure containing >> multiple participants, where each participant contains multiple >> attackers and multiple targets, with each target potentially >> composed of multiple applications, as depicted below: >> >> alert >> signatureId >> protocolIdentifier >> riskRating >> participant 1 >> attacker 1 >> sourceIPv4Address >> applicationId >> ... >> attacker N >> sourceIPv4Address >> applicationId >> target 1 >> destinationIPv4Address >> applicationId 1 >> ... >> applicationId n >> ... >> target N >> destinationIPv4Address >> applicationId 1 >> ... >> applicationId n >> participant 2 >> ... >> >> To export this information in IPFIX, the data would need to be >> flattened (thus losing the hierarchical relationships) and a new >> IPFIX Template created for each alert, according to the number of >> applicationID elements in each target, the number of targets and >> attackers in each participant, and the number of participants in >> each alert. Clearly each Template will be unique to each alert, >> and a large amount of CPU, memory and export bandwidth will be >> wasted creating, exporting, maintaining, and withdrawing the >> Templates. See Appendix C for a specific example related to this >> case study. >> >> >> 3.3. The Proposal >> >> This document specifies an IPFIX extension to support hierarchical >> structured data and variable-length lists by defining three new >> Information Elements and three corresponding new abstract data >> types called basicList, subTemplateList, and subTemplateMultiList. >> >> These are defined in Section 4.1. The three list Information >> Elements carry some semantic information so that the Collecting >> Process can understand the relationship between the different list >> elements. >> >> It is important to note that whereas the Information Elements and >> abstract data types defined in the IPFIX information model >> [RFC5102] represent single values, these new abstract data types >> are structural in nature and primarily contain references to other >> Information Elements and to Templates. By referencing other >> Information Elements and Templates from an Information Element's >> data content, it is possible to define complex data structures >> such as variable-length lists and to specify hierarchical >> containment relationships between Templates. Therefore, this >> document prefers the more generic "Data Record" term to the "Flow >> Record" term. >> >> This document specifies three new abstract data types, which are >> basic blocks to represent structured data. However, this document >> does not comment on all possible combinations of basicList, >> subTemplateList, and subTemplateMultiList. Neither, does it limit >> the possible combinations. >> >> 4. Linkage with the Information Model >> >> As in the IPFIX Protocol specification [RFC5101], the new >> Information Elements specified in Section 4.3. below MUST be sent >> in canonical format in network-byte order (also known as the big- >> endian byte ordering). >> >> >> 4.1. New Abstract Data Types >> >> This document specifies three new abstract data types, as >> described below. >> >> >> 4.1.1. basicList >> >> The type "basicList" represents a list of zero or more instances >> of any single Information Element, primarily used for single- >> valued data types. For example, a list of port numbers, a list of >> interface indexes, a list of AS in a BGP AS-PATH, etc. >> >> >> 4.1.2. subTemplateList >> >> The type "subTemplateList" represents a list of zero or more >> instances of a structured data type, where the data type of each >> list element is the same and corresponds with a single Template >> Record. For example, a structured data type composed of multiple >> pairs of ("MPLS label stack entry position", "MPLS label stack >> value"), a structured data type composed of performance metrics, a >> structured data type composed of multiple pairs of IP address, >> etc. >> >> >> 4.1.3. subTemplateMultiList >> >> The type "subTemplateMultiList" represents a list of zero or more >> instances of a structured data type, where the data type of each >> list element can be different and corresponds with different >> template definitions. For example, a structured data type >> composed of multiple access-list entries, where entries can be >> composed of different criteria types. >> >> >> 4.2. New Data Type Semantic >> >> This document specifies a new data type semantic, as described >> below. >> >> >> 4.2.1. List >> >> A list represents an arbitrary-length sequence of zero or more >> structured data elements, either composed of regular Information >> Elements or composed of data conforming to a Template Record. >> >> 4.3. New Information Elements >> >> This document specifies three new Information Elements, as >> described below. >> >> >> 4.3.1. basicList >> >> A basicList specifies a generic Information Element with a >> basicList abstract data type as defined in Section 4.1.1. and list >> semantics as defined in Section 4.2.1. For example, a list of >> port numbers, a list of interface indexes, etc. >> >> EDITOR'S NOTE: while waiting for IANA [IANA-IPFIX] to assign this >> new Information Element identifier, the value XXX is used in all >> the examples and in the XML in Appendix A. >> >> 4.3.2. subTemplateList >> >> A subTemplateList specifies a generic Information Element with a >> subTemplateList abstract data type as defined in Section 4.1.2. >> and list semantics as defined in Section 4.2.1. >> >> EDITOR'S NOTE: while waiting for IANA [IANA-IPFIX] to assign this >> new Information Element identifier, the value YYY is used in all >> the examples. >> >> >> 4.3.3. subTemplateMultiList >> >> A subTemplateMultiList specifies a generic Information Element >> with a subTemplateMultiList abstract data type as defined in >> Section 4.1.3. and list semantics as defined in Section 4.2.1. >> >> EDITOR'S NOTE: while waiting for IANA [IANA-IPFIX] to assign this >> new Information Element identifier, the value ZZZ is used in all >> the examples. >> >> 4.4. New Structured Data Type Semantics >> >> Structured Data type semantics are provided in order to express >> > Structured _d_ata type > > >> the relationship among multiple list elements in a Structured Data >> Information Element. These Structured Data type semantics require >> > _s_tructured _d_ata (is not a term!) > > Please check all further occurrences below! The usage of capital letters > is inconsistent. > > >> a new IPFIX subregistry, as specified in the "IANA Considerations" >> section. The semantics are specified in the next following >> sections. >> >> 4.4.1. undefined >> >> The "undefined" Structured Data type semantic specifies that the >> semantic of list elements is not specified, and that, if a >> semantic exists, then it is up to the Collecting Process to draw >> its own conclusions. The "undefined" structured data type >> semantic is the default Structured Data type semantic. >> >> 4.4.2. noneOf >> >> The "noneOf" Structured Data type semantic specifies that none of >> the elements are actual properties of the Data Record. >> >> For example, a mediator might want to report to a Collector that a >> specific Flow is suspicious, but that it checked already that this >> Flow does not belong to the attack type 1, attack type 2, and >> attack type 3. So this Flow might need some further inspection. >> In such a case, the mediator would report the Flow Record with a >> basicList composed of (attack type 1, attack type 2, attack type >> 3) and the respective Structured Data type semantic of "noneOf". >> >> Another example is a router that monitors some specific BGP AS- >> PATHs and reports if a Flow belongs to any of them. If the router >> wants to export that a Flow does not belong to any of the >> monitored BGP AS-PATHs, the router reports a Data Record with a >> basicList composed of (BGP AS-PATH 1, BGP AS-PATH 2, BGP AS-PATH >> 3) and the respective Structured Data type semantic of "noneOf". >> >> >> 4.4.3. exactlyOneOf >> >> The "exactlyOneOf" Structured Data type semantic specifies that >> only a single element from the Structured Data is an actual >> property of the Data Record. This is equivalent to a logical XOR >> operation. >> >> For example, if a Flow record contains a basicList of outgoing >> interfaces with the "exactlyOneOf" semantic, then it implies that >> the reported Flow only egressed from a single interface, although >> the Flow Record lists all of the possible outgoing interfaces. >> This is a typical example of a per destination load-balanced Flow >> IPFIX encoding. >> > What does the last sentence mean? How can structured data be typical if > it has not even been standardized? > > >> For example, a mediator must report an aggregated observation >> > "Another example is a mediator which must..." > > You should explain what an "aggregate observation point" is. > > >> point, composed of multiple Template Records: >> > Unclear. The information about OPs is exported in Data Records, not in > Template Records. > > >> >> Template Record 1: exporterIPaddress >> This reports a specific exporter >> >> Template Record 2: exporterIPaddress, basicList of interfaces >> This reports a series of interfaces from an exporter >> >> Template Record 3: exporterIPaddress, line card >> This reports a specific line card from an exporter >> >> If these three Template Records are exported with a >> subTemplateMultiList with the semantic "exactlyOneOf", then it >> > You only export Data Records in a subTemplateMultiList, not Template > Records! > > >> implies that the Flow Observation Point is reported with the >> > "Flow's Observation Point"? > > >> values of either Template Record 1, Template Record 2, or Template >> Record 3 but not more than one Template Record. >> > I would rewrite it in two sentences, e.g.: > > "The Flow Record exported by the mediator contains a > subTemplateMultiList field with semantic "exactlyOneOf" containing one > Data Record for each of the Template Records described above. This > implies that the Flow was observed at exactly one of the Observation > Points reported." > > >> 4.4.4. oneOrMoreOf >> >> The "oneOrMoreOf" Structured Data type semantic specifies that one >> or more element(s) from the list in the Structured Data is/are >> > I do not like (s) and "/" alternatives. > > "elements .... are" > > >> actual propertie(s) of the Data Record. This is equivalent to a >> > "properties" > > >> logical OR operation. >> >> For example, a mediator must report an aggregated Flow (for >> example aggregated from IP addresses to IP prefixes), with an >> > "(for ...)" => "(e.g. aggregating IP addresses with common IP prefixes)" > > >> aggregated observation point, composed of multiple Template >> Records: >> >> >> Template Record 1: exporterIPaddress >> This reports a specific exporter >> >> Template Record 2: exporterIPaddress, basicList of interfaces >> This reports a series of interfaces from an exporter >> >> Template Record 3: exporterIPaddress, line card >> This reports a specific line card from an exporter >> >> If these three Template Records are exported with a >> subTemplateMultiList with the semantic "oneOrMoreOf", then the >> > Same comments as in section 4.4.3. > > >> aggregated Flow has been observed on at least one of the >> individual Observation Points reported with the values of a >> specific Template Record, and potentially on multiple Observation >> Points. >> >> >> 4.4.5. allOf >> >> The "allOf" structured data type semantic specifies that all of >> the list elements from the Structured Data are actual properties >> of the Data Record. >> >> For example, if a Record contains a basicList of outgoing >> interfaces with the "allOf" semantic, then the observed Flow is >> typically a multicast Flow where each packet in the Flow has been >> replicated to each outgoing interface in the basicList. >> >> >> 4.4.6. ordered >> >> The "ordered" Structured Data type semantic specifies that >> elements from the list in the Structured Data are ordered. >> >> For example, an Exporter might want to export the AS10 AS20 AS30 >> AS40 BGP AS-PATH. In such a case, the Exporter would report a >> basicList composed of (AS10, AS20, AS30, AS40) and the respective >> Structured Data type semantic of "ordered". >> >> >> 4.5. Encoding of IPFIX Data Types >> >> The following sections define the encoding of the data types >> > abstract data types ? > > >> defined in Section 4.1. above. >> >> When the encoding of a Structured Data Information Element has a >> fixed length (because, for example, it contains the same number of >> fixed-length elements, or if the permutations of elements in the >> list always produces the same total length), the element length >> can be encoded in the corresponding Template Record. However, >> when representing variable-length data, hierarchical data, and >> repeated data with variable element counts, we RECOMMEND these are >> > "...RECOMMEND that these..." > > >> encoded as a Variable-Length Information Element as described in >> > _v_ariable-_l_ength > > >> Section 7 of [RFC5101], with the length carried in one or three >> octets before the Structured Data Information Element encoding. >> >> >> 4.5.1. basicList >> >> The basicList Information Element defined in Section 4.3.1. >> represents a list of zero or more instances of an Information >> Element and is encoded as follows: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Semantic |0| Field ID | Element... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ...Length | BasicList Content ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure A: basicList Information Element Encoding >> >> >> Semantic >> >> The Semantic indicates the semantic of the list elements, >> > remove "The" at the beginning of the sentence or write "The Semantic > field..."? > > >> i.e., the relationship among the different Information Element >> values within this Structured Data. >> > _s_tructured _d_ata > > >> >> >> Field ID >> >> The Field ID is the Information Element identifier of the >> > remove "The" at the beginning of the sentence or add "field"? > > >> Information Element(s) contained in the list. >> >> >> Element Length >> >> The Element Length indicates the length of each list element >> > remove "The" at the beginning of the sentence or add "field"? > > >> specified by the Field ID, or contains the value 0xFFFF if the >> length is encoded as a variable-length Information Element at >> the start of the BasicList Content. >> >> The Element Length field is effectively part of a header, so >> even in the case of a zero-element list with no Enterprise >> Number, it MUST NOT be omitted. >> > why "with no Enterprise Number"? > > I would remove the last paragraph. "header" is confusing. And you repeat > this requirement below. > > >> >> >> BasicList Content >> >> A Collection Process decodes list elements from the BasicList >> Content until no further data remains. A field count is not >> included but can be derived when the Information Element is >> decoded. >> >> Note that in the diagram above, the Field ID is shown with the >> > maybe "..., Field ID...," or "..., the Field ID field ..." ? > > >> Enterprise bit (most significant bit) set to 0. If instead the >> Enterprise bit is set to 1, a four-byte Enterprise Number MUST be >> encoded immediately after the Element Length as shown below. See >> the "Field Specifier Format" section in the IPFIX Protocol >> [RFC5101] for additional information. >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Semantic |1| Field ID | Element... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ...Length | Enterprise Number ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | BasicList Content ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Figure B: basicList Encoding with Enterprise Number >> >> >> Also note that, if a basicList has zero elements, the encoded data >> contains the Semantic, Field ID, the Element Length and the four- >> byte Enterprise Number (if present), while the BasicList Content >> is empty. >> >> If the basicList is encoded as a Variable-Length Information >> > variable-length (also appears multiple times below) > > >> Element in less than 255 octets, it is encoded with the Length per >> > "Length" => "Length field" (multiple times below) > > >> Section 7 of [RFC5101] as follows: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Length (< 255)| basicList Content | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... continuing as needed | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure C: Variable-Length basicList Information Element Encoding >> (Length< 255 octets) >> >> >> If the basicList is encoded as a Variable-Length Information >> Element in 255 or more octets, it is encoded with the Length per >> Section 7 of [RFC5101] as follows: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 255 | Length (0 to 65535) | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | basicList Content | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure D: Variable-Length basicList Information Element Encoding >> (Length 0 to 65535 octets) >> >> >> 4.5.2. subTemplateList >> >> The subTemplateList Information Element represents a list of zero >> or more instances of Template data. Because the Template Record >> > what do you mean by "instances of Template data" ? > > This would be clearer: "Data Records associated to one specific > (Options) Template" > > Or do you think that the term "Data Record" should not be used here? > Yet, you also use it below in this context... > > >> referenced by a subTemplateList Information Element can itself >> contain other subTemplateList Information Elements, and because >> these Template Record references are part of the Information >> Elements content in the Data Record, it is possible to represent >> complex hierarchical data structures. The following diagram shows >> how a subTemplateList Information Element is encoded within a Data >> Record: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Semantic | Template ID | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | SubTemplateList Content ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure E: subTemplateList Encoding >> >> >> Semantic >> >> The Semantic indicates the semantic of the list elements, i.e. >> > remove "The" at the beginning of the sentence? Or "The Semantic field"? > > >> the relationship among the different Data Records within this >> Structured Data. >> >> Template ID >> >> The Template ID is the ID of the template used to encode and >> > This sentence is confusing because Template ID is an IPFIX term! So, it > sound like a redefinition. > > Better: "The Template ID field contains the ID of the ...." > > >> decode the SubTemplateList Content. >> >> SubTemplateList Content >> >> The SubTemplateList Content consists of zero or more instances >> of Data Records corresponding to the Template ID. A >> > "...Template ID specified in the Template ID field." ? > > Well, it's pedantic and I would not insist on this change :) > > >> Collecting Process decodes the Data Records until no further >> data remains. A record count is not included but can be >> derived when the subTemplateList is decoded. Encoding and >> decoding are performed recursively if the specified Template >> itself contains Structured Data Information Elements as >> described here. >> >> >> Note that, if a subTemplateList has zero elements, the encoded >> data contains only the Semantic and the Template ID, while the >> SubTemplateList Content is empty. >> >> If the subTemplateList is encoded as a Variable-Length Information >> > variable-length (same below) > > >> Element in less than 255 octets, it is encoded with the Length per >> > Length field (same below) > > >> Section 7 of [RFC5101] as follows: >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Length (< 255)| subTemplateList Content | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... continuing as needed | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure F: Variable-Length subTemplateList Information Element >> Encoding (Length< 255 octets) >> >> >> If the subTemplateList is encoded as a Variable-Length Information >> Element in 255 or more octets, it is encoded with the Length per >> Section 7 of [RFC5101] as follows: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 255 | Length (0 to 65535) | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... SubTemplateList Content | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure G: Variable-Length subTemplateList Information Element >> Encoding (Length 0 to 65535 octets) >> >> >> 4.5.3. subTemplateMultiList >> >> Whereas each top-level element in a subTemplateList Information >> > what is meant by "top-level"? It means that there are levels below. Remove? > > >> Element corresponds with a single Template ID and therefore has >> > "corresponds to" > > >> the same data type, sometimes it is useful for a list to contain >> > Why "same data type"? Each element is a Data Record associated to the > same (Options) Template. > > ", sometimes it..." => "..., it is sometimes useful..." > > >> elements of more than one data type. To support this case, each >> > Why "data type"? You talk about Templates. > > >> top-level element in a subTemplateMultiList Information Element >> carries a Template ID, Length and zero or more Data Records >> corresponding to the Template ID. The following diagram shows how >> a subTemplateMultiList Information Element is encoded within a >> Data Record. Note that the subTemplateMultiList encoding is >> consistent with Set Header specified in [RFC5101], once the >> > "with Set Header" => "with the Set Header" ? > > >> Semantic field has been decoded. >> > well, not only after decoding Semantic, also after encoding it :) > > Better: > "Note that the encoding following the Semantic field is consistent with > the Set Header specified in [RFC5101]." > > >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Semantic | Template ID X |Data Records...| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... Length X | Data Record X.1 Content ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | Data Record X.2 Content ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | Data Record X.L Content ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | Template ID Y |Data Records...| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... Length Y | Data Record Y.1 Content ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | Data Record Y.2 Content ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | Data Record Y.M Content ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | Template ID Z |Data Records...| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... Length Z | Data Record Z.1 Content ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | Data Record Z.2 Content ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | Data Record Z.N Content ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | >> +-+-+-+-+-+-+-+-+ >> >> Figure H: subTemplateMultiList Encoding >> >> Semantic >> >> The Semantic indicates the top level semantic among Template >> > Remove "The" or "Semantic field"? > > remove "top level" > > "among the Data Records"? > > Comment added later: Now as I have read section 5.4, I understand that > you want to restrict to the semantic among sequences of Data Records > belonging to different Templates. This does not become clear. Wouldn't > it be simpler to say that Semantic defines the semantic among all Data > Records, regardless of the Template? > > >> Records, i.e. the relationship among the series of Data >> Records from the different Template Records within this >> > "from" => "associated with" > > >> Structured Data. >> > _s_tructured _d_ata > > >> >> Note: if a semantic is required to describe the relationship >> among the different Data Records corresponding to a single >> Template ID within the subTemplateMultiList, then an encoding >> based on a basicList of subTemplateLists should be used. Refer >> > I would remove "basicList" because it does not support Templates. So, it > is not a general alternative. > > >> to Section 5.6 for more information. >> >> Template ID >> >> Unlike the subTemplateList Information Element, each list >> element contains a Template ID which specifies the encoding of >> > "each element of subTemplateMultiList contains..." > > >> the following Data Records. >> >> Data Records Length >> >> The total length of the Data Records encoding for the Template >> ID previously specified, including the 2 bytes for the >> Template ID and the 2 bytes for the Data Records Length field >> itself. >> >> Data Record X.M >> >> The Data Record X.M consists of the Mth Data Record of the >> Template Record X. A Collecting Process decodes the Data >> Records until no further data remains, according to the Data >> Records Length. A record count is not included but can be >> derived when the Element Content is decoded. Encoding and >> decoding are performed recursively if the specified Template >> itself contains Structured Data Information Elements as >> described here. >> >> In the exceptional case of zero instances in the >> subTemplateMultiList, no data is encoded and the Data Record >> Length is set to zero. >> >> If the subTemplateMultiList is encoded as a Variable-Length >> > variable-length > > >> Information Element in less than 255 octets, it is encoded with >> the Length per Section 7 of [RFC5101] as follows: >> > Length field > > >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Length (< 255)| subTemplateMultiList Information Element | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... continuing as needed | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure I: Variable-Length subTemplateMultiList Information Element >> Encoding (Length< 255 octets) >> >> >> If the subTemplateMultiList is encoded as a Variable-Length >> Information Element in 255 or more octets, it is encoded with the >> Length per Section 7 of [RFC5101] as follows: >> > same comments as above > > >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 255 | Length (0 to 65535) | IE | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... continuing as needed | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure J: Variable-Length subTemplateMultiList Information >> Element Encoding (Length 0 to 65535 octets) >> >> >> 5. Structured Data Format >> >> >> 5.1. Length Encoding Considerations >> >> The new Structured Data Information Elements represent a list that >> potentially carries complex hierarchical and repeated data. In >> the normal case where the number and length of elements can vary >> from record to record, these Information Elements are encoded as >> variable-length Information Elements as described in Section 7 of >> [RFC5101]. >> >> Because of the complex and repeated nature of the data, it is >> potentially difficult for the Exporting Process to efficiently >> know in advance the exact encoding size. >> > I would replace the following > > >> As a result, data may be >> recursively encoded starting at a fixed offset, with the final >> length only known and filled in afterwards. >> >> Therefore, the three-byte length encoding is RECOMMENDED for >> variable-length information elements in all Template Records >> containing a Structured Data Information Element, even if the >> encoded length can be less than 255 bytes, because the starting >> offset of the data is known in advance. >> > by: > "In this case, the Exporting Process may encode the available data and > fill in the final length afterwards. Therefore, it may be convenient to > always use the three-byte long encoding of the Length field of the > variable-length Structured Data Information Element (even if the final > length is less than 255 bytes) to allow the data encoding to start at a > fixed offset." > > >> >> An Exporting Process MUST take care when encoding such data to not >> exceed the maximum allowed length of an IPFIX Message, 65535 >> bytes, respecting the IPFIX specifications [RFC5101] that imposes: >> "The IPFIX Message Header 16-bit Length field limits the length of >> an IPFIX Message to 65535 octets, including the header". >> > I do not think that a quotation is necessary. > > "When encoding such data, an Exporting Process MUST take care to not > exceed the maximum allowed IPFIX Message length of 65535 bytes which is > specified in [RFC5101]." > > >> >> >> 5.2. Recursive Structured Data >> >> It is possible to define recursive relationships between IPFIX >> structured data instances, for example when representing a tree >> structure. The simplest case of this might be a basicList where >> each element is itself a basicList, or a subTemplateList where one >> of the fields of the referenced template is itself a >> subTemplateList referencing the same Template. When such a >> recursive relationship exists, variable-length encoding as >> described in Section 7 of [RFC5101] MUST be used. Also, the >> Exporting Process MUST take care when encoding recursively-defined >> structured data, not to exceed the maximum allowed length of an >> IPFIX Message (as noted in Length Encoding Considerations). >> >> >> 5.3. Structured Data Information Elements Applicability in Options >> Template Sets >> >> Structured Data Information Elements MAY be used in Options >> Template Sets. >> >> As an example, consider a mediation function that must aggregate >> Data Records from multiple Observation Point types: >> >> Router 1, (interface 1) >> Router 2, (line card A) >> Router 3, (line card B) >> Router 4, (line card C, interface 2) >> >> In order to encode the PSAMP Selection Sequence Report >> Interpretation [RFC5476], the mediation function must express this >> combination of Observation Points as a single new Observation >> Point. Recall from [RFC5476] that the PSAMP Selection Sequence >> Report Interpretation consists of the following fields: >> >> Scope: selectionSequenceId >> Non-Scope: one Information Element mapping the Observation Point >> selectorId (one or more) >> >> Without structured data, there is clearly no way to express the >> complex aggregated Observation Point as "one Information Element >> mapping the Observation Point". However, the desired result may >> be easily achieved using the structured data types. Refer to >> Section 8.5. for an encoding example related to this case study. >> >> Regarding the scope in the Options Template Record, the IPFIX >> specification [RFC5101] mentions that "The IPFIX protocol doesn't >> prevent the use of any Information Elements for scope". >> Therefore, a Structured Data Information Element MAY be used as >> scope in an Options Template Set. >> >> Extending the previous example, the mediation function could >> export a given name for this complex aggregated Observation Point: >> >> Scope: Aggregated Observation Point (Structured Data) >> Non-Scope: a new Information Element containing the name >> >> >> 5.4. Usage Guidelines for Equivalent Data Representations >> >> Because basicList, subTemplateList, and subTemplateMultiList are >> all lists, in several cases there is more than one way to >> represent what is effectively the same data structure. However, >> in some cases, one approach has an advantage over the other e.g. >> more compact, uses fewer resources, etc., and is therefore >> preferred over an alternate representation. >> >> A subTemplateList can represent the same simple list of single- >> value Information Elements as a basicList, if the Template >> referenced by the subTemplateList contains only one single-valued >> Information Element. Although the encoding is more compact than a >> basicList by two bytes, using a subTemplateList in this case >> requires a new Template per Information Element. The basicList >> requires no additional Template and is therefore RECOMMENDED in >> this case. >> >> Although a subTemplateMultiList with one Element can represent the >> contents of a subTemplateList, the subTemplateMultiList carries >> two additional bytes (Element Length). It is also potentially >> useful to a Collecting Process to know in advance that a >> subTemplateList directly indicates that list element types are >> consistent. The subTemplateList Information Element is therefore >> RECOMMENDED in this case. >> >> The Semantic in a subTemplateMultiList indicates the top level >> > Semantic field > > >> semantic among Template Records, i.e. the relationship among the >> > Template Records => Data Records ? > > See comment above in section 4.5.3. > > >> series of Data Records from the different Template Records, within >> this Structured Data. If a semantic is required to describe the >> relationship among the different Data Records corresponding to a >> single Template ID within the subTemplateMultiList, then an >> encoding based on a basicList of subTemplateLists should be used. >> >> Note that the referenced Information Element(s) in the Structured >> Data Information Elements can be taken from the IPFIX information >> model [RFC5102], the PSAMP information model [RFC5477], or any of >> the Information Elements defined in the IANA IPFIX registry [IANA- >> IPFIX]. >> > Hm, what about enterprise-specific IEs? > > >> >> >> 5.5. Padding >> >> The Exporting Process MAY insert some padding octets in structured >> data field values in a Data Record by including the >> 'paddingOctets' Information Element as described in [RFC5101] >> Section 3.3.1. The paddingOctets Information Element can be >> included in a Template Record referenced by Structured Data >> Information Element for this purpose. >> > Do we need this section? If you keep it, provide an example where > padding might be useful in the context of structured data. > > >> >> >> 5.6. Semantic >> >> Semantic interpretations of received Data Records at or beyond the >> Collecting Process remain explicitly undefined, unless that data >> is transmitted using this extension with explicit Structured Data >> type semantic information. >> > Do we need this sentence? It seems to define an unnecessary restriction. > Maybe we specify further mechanisms for IPFIX semantics in another RFC > which could conflict with this sentence. > > >> The Exporter SHOULD NOT check all semantically meaningless >> combinations before exporting the Data Record. >> > I do not understand. > SHOULD NOT => SHOULD > or > SHOULD NOT => "does not have to" > > >> Most forms of Structured Data type semantics are possible, without >> necessarily specifying new semantic values. >> > Is there a proof for this statement? > > Otherwise: > "More complex semantics can be expressed as a combination of the > Semantic Data Information Elements specified in this document." > > >> For example, the export of the AS10 AS20 AS30 AS40 {AS50,AS60} BGP >> AS-PATH would be reported as a basicList of two elements, each >> element being a basicList of BGP AS, with the top level Structured >> Data type semantic of "ordered". The first element would contain >> a basicList composed of (AS10,AS20,AS30,AS40) and the respective >> Structured Data type semantic of "ordered", while the second >> element would contain a basicList composed of (AS50, AS60) and the >> respective Structured Data type semantic of "exactlyOneOf". A >> high level Data Record diagram would be represented as: >> >> (basicList, ordered, >> >> (basicList, ordered, AS10,AS20,AS30,AS40), >> >> (basicList, exactlyOneOf, AS50, AS60) >> >> ) >> >> Note that the subTemplateMultiList Structured Data type semantic >> provides the top level semantic among Template Records, i.e. the >> relationship among the series of Data Records from the different >> Template Records within this Structured Data, and not the >> relationships of the different Data Records corresponding to a >> single Template ID within the subTemplateMultiList. If this is >> required, semantic information needs to be exported for every >> Template ID, in other words a basicList of subTemplateLists should >> be used. >> > Remove this paragraph as it is repeated from section 5.4. > > >> The following case studies show the advantage of a basicList of >> subTemplateLists over a subTemplateMultiList. >> >> Case study 1: >> >> In this example, an Exporter monitoring security attacks must >> export a list of attackers and targets. For the sake of the >> example, consider attackers A1 or A2 may attack targets T1 and T2. >> > "consider" => "imagine that" > > >> The first case uses a subTemplateMultiList composed of two >> Template Records, one representing the attacker and one >> representing the target, each of them containing an IP address and >> a port. >> >> Attacker Template Record = (src IP address, src port) >> Target Template Record = (dst IP address, dst port) >> >> A high level Data Record diagram would be represented as: >> >> (subTemplateMultiList, allOf, >> >> (Attacker Template Record, A1, A2), >> >> (Target Template Record, T1, T2) >> >> ) >> >> The Collecting Process can only conclude that all of the attackers >> A1, A2 and the targets T1, T2 are present, without knowing the >> relationship amongst attackers and targets. The Exporting Process >> would have to explicitly call out the relationship amongst >> attackers and targets and the top level semantic offered by the >> > second "and" => "as" ? > > >> subTemplateMultiList isn't sufficient. >> >> The only proper encoding for the previous semantic (i.e. attacker >> A1 or A2 may attack target T1 and T2) uses a basicList of >> subTemplateLists and is represented as follows: >> >> Attacker Template Record = (src IP address, src port) >> >> Target Template Record = (dst IP address, dst port) >> >> (basicList, allof, >> >> (subTemplateList, exactlyOneOf, attacker A1, A2) >> >> (subTemplateList, allOf, target T1, T2) >> >> ) >> >> >> >> Case study 2: >> >> In this example, an Exporter monitoring security attacks must >> export a list of attackers and targets. For the sake of the >> example, attackers A1 or A2 may attack targets T1, attacker A3 is >> > "targets" => "target" > > >> attacking targets T2 and T3. The first case uses a >> subTemplateMultiList composed of two Template Records, one >> > "Data Records associated to two different Templates" > > >> representing the attacker and one representing the target, each of >> them containing an IP address and a port. >> >> Attacker Template Record = (src IP address, src port) >> >> Target Template Record = (dst IP address, dst port) >> >> A high level Data Record diagram would be represented as: >> >> (subTemplateMultiList, allOf, >> >> (Attacker Template Record, A1, A2, A3), >> >> (Target Template Record, T1, T2, T3) >> >> ) >> >> The Collecting Process can only conclude that all of the attackers >> A1, A2, A3 and the targets T1, T2, T3 are present, without knowing >> the relationship amongst attackers and targets. >> >> The second case could use a Data Record definition composed of the >> following: >> >> (subTemplateMultiList, allOf, >> >> (Attacker Template Record, A1, A2), >> >> (Target Template Record, T1), >> >> (Attacker Template Record, A3), >> >> (Target Template Record, T2, T3) >> >> ) >> >> With the above representation, the Collecting Process can possibly >> deduce that some relationship exists among (A1, A2, T1) and (A3, >> T2, T3) but cannot understand what it is exactly. So, there is a >> need for the Exporting Process to explicitly define the >> relationship between the attackers and targets and the top level >> semantic of the subTemplateMultiList is not sufficient. >> >> The only proper encoding for the previous semantic (i.e. attacker >> A1 or A2 attack target T1, attacker A3 attacks targets T2 and T3) >> uses a basicList of subTemplateLists and is represented as >> follows: >> >> Attacker Template Record = (src IP address, src port) >> >> Target Template Record = (dst IP address, dst port) >> > I would not repeat these Template Records here because you do not show > the Participant and Alarm Templates either. > > >> Participant P1: >> >> (basicList, allOf, >> >> (subTemplateList, exactlyOneOf, attacker A1, A2) >> >> (subTemplateList, undefined, target T1) >> >> ) >> >> Participant P2: >> >> (basicList, allOf, >> >> (subTemplateList, undefined, attacker A3, >> >> (subTemplateList, allOf, targets T2, T3) >> >> ) >> >> The security alert is represented as a subTemplateList of >> participants. >> >> Alert >> >> (subTemplateList, allOf, Participant P1, Participant P2) >> >> Note that, in the particular case of a single element in a >> Structured Data Information Element, the semantic field is >> actually not very useful since it specifies the relationship among >> multiple elements. Any choice of allOf, exactlyOneOr, or >> OneOrMoreOf would provide the same result semantically. >> Therefore, in case of a single element in a Structured Data >> Information Element, the default "undefined" semantic SHOULD be >> used. >> >> >> 6. Template Management >> >> This section introduces some more specific Template Management and >> > _m_anagement > > >> Template Withdrawal Message-related specifications compared to the >> IPFIX protocol specification [RFC5101]. >> >> First of all, the Template ID uniqueness is unchanged compared to >> [RFC5101]; the uniqueness is local to the Transport Session and >> Observation Domain that generated the Template ID. In other >> words, the Set ID used to export the Template Record does not >> influence the Template ID uniqueness. >> >> While [RFC5101] mentions that: "If an Information Element is >> required more than once in a Template, the different occurrences >> of this Information Element SHOULD follow the logical order of >> their treatments by the Metering Process.", this rule MAY not be >> followed for the Structured Data Information Elements. >> >> As specified in [RFC5101], Templates that are not used anymore >> SHOULD be deleted. Before reusing a Template ID, the Template >> MUST be deleted. In order to delete an allocated Template, the >> Template is withdrawn through the use of a Template Withdrawal >> Message. >> > You might clarify that deleting a Template implies that it may not be > used within subTemplateList and subTemplateMultiList any more. > > >> >> >> 7. The Collecting Process's Side >> >> This section introduces some more specific specifications to the >> Collection Process compared to Section 9 in the IPFIX Protocol >> [RFC5101]. >> >> As described in [RFC5101], a Collecting Process MUST note the >> Information Element identifier of any Information Element that it >> does not understand and MAY discard that Information Element from >> the Flow Record. Therefore a Collection Process that does not >> support the extension specified in this document can ignore the >> Structured Data Information Elements in a Data Record, or it can >> ignore Data Records containing these new Structured Data >> Information Elements while continuing to process other Data >> Records. >> >> If the Structured Data contains the "undefined" Structured Data >> type semantic, the Collecting Process MAY attempt to draw its own >> conclusion in terms of the semantic contained in the Data Record, >> exactly as it would have done before the introduction of this >> specification. >> > Maybe remove "exactly as..." because without this specification, you > cannot nest Data Records anyway, so the CP never has the problem to > interpret nested Data Records. > > >> >> 8. Structured Data Encoding Examples >> >> The following examples are created solely for the purpose of >> illustrating how the extensions proposed in this document are >> encoded. >> >> >> 8.1. Encoding a Multicast Data Record with BasicList >> >> Consider encoding a multicast Data Record containing the following >> data: >> >> --------------------------------------------------------------- >> Ingress If | Source IP | Destination IP | Egress Interfaces >> --------------------------------------------------------------- >> 9 192.0.2.201 233.252.0.1 1, 4, 8 >> --------------------------------------------------------------- >> >> Template Record for the multicast Flows, with the Template ID 256: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 | Length = 24 octets | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 256 | Field Count = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| ingressInterface = 10 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| sourceIPv4Address = 8 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| DestinationIPv4Address = 12 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| basicList = XXX | Field Length = 0xFFFF | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure K: Encoding basicList, Template Record >> >> >> The list of outgoing interfaces is represented as a basicList with >> semantic allOf, and the Length of the list is chosen to be encoded >> in three bytes even though it may be less than 255 octets. >> >> The Data Set is represented as follows: >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 256 | Length = 36 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ingressInterface = 9 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | sourceIPv4Address = 192.0.2.201 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | DestinationIPv4Address = 233.252.0.1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 255 | List Length = 17 | semantic=allOf| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | egressInterface FieldId = 14 |egressInterface Field Length=4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | egressInterface value 1 = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | egressInterface value 2 = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | egressInterface value 3 = 8 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure L: Encoding basicList, Data Record, Semantic allOf >> >> In the example above, the BasicList contains fixed-length >> elements. To illustrate how variable-length elements would be >> encoded, the same example is shown below with variable-length >> interface names in the BasicList instead: >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 256 | Length = 44 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ingressInterface = 9 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | sourceIPv4Address = 192.0.2.201 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | DestinationIPv4Address = 233.252.0.1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 255 | List Length = 25 | semantic=allOf| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| InterfaceName FieldId = 82 | InterfaceName Field Len=0xFFFF| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Length = 5 | 'F' | 'E' | '0' | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | '/' | '0' | Length = 7 | 'F' | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 'E' | '1' | '0' | '/' | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | '1' | '0' | Length = 5 | 'F' | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 'E' | '2' | '/' | '2' | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure M: Encoding basicList, Data Record with Variable-Length >> Elements, Semantic allOf >> >> >> 8.2. Encoding a Load-balanced Data Record with a BasicList >> >> Consider encoding a load-balanced Data Record containing the >> following data: >> >> --------------------------------------------------------------- >> Ingress If | Source IP | Destination IP | Egress Interfaces >> --------------------------------------------------------------- >> 9 192.0.2.201 233.252.0.1 1, 4, 8 >> --------------------------------------------------------------- >> >> >> So the Data Record egressed from either interface 1, 4, or 8. The >> Data Set is represented as follows: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 256 | Length = 36 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ingressInterface = 9 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | sourceIPv4Address = 192.0.2.201 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | DestinationIPv4Address = 233.252.0.1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 255 | List Length = 17 |sem=exactlyOne | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | egressInterface FieldId = 14 |egressInterface Field Length=4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | egressInterface value 1 = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | egressInterface value 2 = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | egressInterface value 3 = 8 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure N: Encoding basicList, Data Record, Semantic ExactlyOneOf >> >> >> 8.3. Encoding subTemplateList >> >> As explained in Section 3.2. , multiple pairs of >> (observationTimeMicroseconds, digestHashValue) must be collected >> from two different Observation Points to passively compute the >> one-way delay across the network. This data can be exported with >> an optimized Data Record that consists of the following >> attributes: >> >> 5 tuple >> { observationTimeMicroseconds 1, digestHashValue 1 } >> { observationTimeMicroseconds 2, digestHashValue 2 } >> { observationTimeMicroseconds 3, digestHashValue 3 } >> { ... , ... } >> >> >> A subTemplateList is best suited for exporting the list of >> (observationTimeMicroseconds, digestHashValue). For illustration >> purposes, the number of elements in the list is 5; in practice, it >> could be more. >> >> ------------------------------------------------------------------ >> srcIP | dstIP | src | dst |proto| one-way delay >> | | Port | Port | | metrics >> ------------------------------------------------------------------ >> 192.0.2.1 192.0.2.105 1025 80 6 Time1, 0x0x91230613 >> Time2, 0x0x91230650 >> Time3, 0x0x91230725 >> Time4, 0x0x91230844 >> Time5, 0x0x91230978 >> ------------------------------------------------------------------ >> >> The following Template is defined for exporting the one-way delay >> metrics: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 | Length = 16 octets | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 257 | Field Count = 2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| observationTimeMicroSec=324 | Field Length = 8 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| digestHashValue = 326 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure O: Encoding subTemplateList, Template for One-Way Delay >> Metrics >> >> >> The Template Record for the Optimized Data Record is as follows: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 | Length = 32 octets | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 258 | Field Count = 6 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| sourceIPv4Address = 8 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| destinationIPv4Address = 12 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| sourceTransportPort = 7 | Field Length = 2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| destinationTransportPort= 11| Field Length = 2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| protocolIdentifier = 4 | Field Length = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| subTemplateList = YYY | Field Length = 0xFFFF | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure P: Encoding subTemplateList, Template Record >> >> The list of (observationTimeMicroseconds, digestHashValue) is >> exported as a subTemplateList with semantic allOf. The Length of >> the subTemplatelist is chosen to be encoded in three bytes even >> though it may be less than 255 octets. >> >> The Data Record is represented as follows: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 258 | Length = 83 octets | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | sourceIPv4Address = 192.0.2.1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | destinationIPV4Address = 192.0.2.105 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | sourceTransportPort = 1025 | destinationTransportPort = 80 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Protocol = 6 | 255 | one-way metrics list len = 63 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | semantic=allOf| TemplateID = 257 | TimeValue1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... octets 2-5 of TimeValue1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... octets 6-8 of TimeValue1 |digestHashVal1=| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... 0x0x91230613 | TimeValue2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... octets 2-5 of TimeValue2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... octets 6-8 of TimeValue2 |digestHashVal2=| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... 0x0x91230650 | TimeValue3 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... octets 2-5 of TimeValue3 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... octets 6-8 of TimeValue3 |digestHashVal3=| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... 0x0x91230725 | TimeValue4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... octets 2-5 of TimeValue4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... octets 6-8 of TimeValue4 |digestHashVal4=| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... 0x0x91230844 | TimeValue5 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... octets 2-5 of TimeValue5 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... octets 6-8 of TimeValue5 |digestHashVal5=| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... 0x0x91230978 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Figure Q: Encoding subTemplateList, Data Set >> >> >> 8.4. Encoding subTemplateMultiList >> >> As explained in Section 4.4.3., a subTemplateMultiList is used to >> export a list of mixed-type content where each top level element >> corresponds to a different Template Record. >> >> To illustrate this, consider the Data Record with the following >> attributes: >> >> >> 5 tuple (Flow Keys), octetCount, packetCount >> attributes for classification >> selectorId, >> selectorAlgorithm >> attributes for sampling >> selectorId, >> selectorAlgorithm, >> samplingPacketInterval, >> samplingPacketSpace >> >> This example demonstrates that the Selector Report Interpretation >> [RFC5476] can be encoded with the subTemplateMultiList. More >> specifically, the example describes Property Match Filtering >> Selector Report Interpretation [RFC5476] used for classification >> > IMO, "classification" can be misunderstood. > Why do not use the word "filtering"? Or "selection"? > > >> purposes, and the Systemic Count-Based Sampling as described in >> Section 6.5.2.1 of [RFC5476]. Some traffic will be filtered >> according to match properties configured, some will be sampled, >> some will be filtered and sampled, and some will not be filtered or >> be sampled. >> >> A subTemplateMultiList is best suited for exporting this variable >> data. A Template is defined for classification attributes and >> > Again, I would say: filtering attributes. > > >> another Template is defined for sampling attributes. A Data Record >> can contain data corresponding to either of the Templates, both of >> them, or neither of them. >> >> >> Consider the example below where the following Data Record contains >> both classification and sampling attributes. >> >> Key attributes of the Data Record: >> >> ------------------------------------------------------------------ >> srcIP | dstIP | src | dst | proto | octetCount | packet >> | | Port | Port | | | Count >> ------------------------------------------------------------------ >> 192.0.2.1 192.0.2.105 1025 80 6 108000 120 >> ------------------------------------------------------------------ >> >> >> Classification attributes: >> >> ------------------------------------------- >> selectorId | selectorAlgorithm >> ------------------------------------------- >> 100 5 (Property Match Filtering) >> ------------------------------------------- >> >> >> Sampling attributes: >> >> For Systemic Count-Based Sampling as defined in Section 6.5.2.1 of >> [RFC5476] the required algorithm-specific Information Elements are: >> >> samplingPacketInterval: number of packets selected in a row >> samplingPacketSpace: number of packets between selections >> >> Example of a simple 1 out-of 100 systematic count-based Selector >> definition, where the samplingPacketInterval is 1 and the >> samplingPacketSpace is 99. >> >> -------------------------------------------------------------- >> selectorId | selectorAlgorithm | sampling | sampling >> | | Packet | Packet >> | | Interval | Space >> -------------------------------------------------------------- >> 15 1 (Count-Based Sampling) 1 99 >> -------------------------------------------------------------- >> >> >> To represent the Data Record, the following Template Records are >> defined: >> >> Template for classification attributes: 259 >> Template for sampling attributes: 260 >> Template for Flow Record: 261 >> >> Flow record (261) >> | (sourceIPv4Address) >> | (destinationIPv4Address) >> | (sourceTransportPort) >> | (destinationTransportPort) >> | (protocolIdentifier) >> | (octetTotalCount) >> | (packetTotalCount) >> | >> +------ classification attributes (259) >> | (selectorId) >> | (selectorAlgorithm) >> | >> +------ sampling attributes (260) >> | (selectorId) >> | (selectorAlgorithm) >> | (samplingPacketInterval) >> | (samplingPacketSpace) >> >> >> The following Template Record is defined for classification >> attributes: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 | Length = 16 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 259 | Field Count = 2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| selectorId = 302 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| selectorAlgorithm = 304 | Field Length = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure R: Encoding subTemplateMultiList, Template for >> Classification Attributes >> >> The Template for sampling attributes is defined as follows: >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 | Length = 24 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 260 | Field Count = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| selectorId = 302 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| selectorAlgorithm = 304 | Field Length = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| samplingPacketInteval = 305 | Field Length = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| samplingPacketSpace = 306 | Field Length = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure S: Encoding subTemplateMultiList, Template for Sampling >> Attributes >> >> >> Note that while selectorId is defined as unsigned64, it is >> > Actually, selectorId is unsigned32 (at least according to WG consensus) > > >> compressed down to 4 octet here as allowed by Reduced Size >> Encoding in Section 6.2 of the IPFIX protocol specifications >> [RFC5101]. >> >> Note that while selectorAlgorithm is defined as unsigned16, and >> samplingPacketInterval and samplingPacketSpace are defined as >> unsigned32, they are compressed down to 1 octet here as allowed >> by Reduced Size Encoding in Section 6.2 of the IPFIX protocol >> specifications [RFC5101]. >> >> >> Template for the Flow Record is defined as shown below: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 | Length = 40 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 261 | Field Count = 8 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| sourceIPv4Address = 8 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| destinationIPv4Address = 12 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| sourceTransportPort = 7 | Field Length = 2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| destinationTransportPort=11 | Field Length = 2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| protocolIdentifier = 4 | Field Length = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| octetTotalCount = 85 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| packetTotalCount = 86 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| subTemplateMultiList = ZZZ | Field Length = 0XFFFF | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure T: Encoding subTemplateMultiList, Template for Flow Record >> >> >> A subTemplateMultiList with semantic allOf is used to export the >> classification and sampling attributes. The Length of the >> subTemplateMultilist is chosen to be encoded in three bytes even >> though it may be less than 255 octets. >> >> The Data Record is encoded as follows: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 261 | Length = 49 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | sourceIPv4Address = 192.0.2.1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | destinationIPv4Address = 192.0.2.105 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | sourceTransportPort = 1025 | destinationTransportPort = 80 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | protocol = 6 | octetTotalCount = 108000 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | packetTotalCount = 120 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | 255 | Attributes List Length = 21 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |semantic=allOf | Classif. Template ID = 259 | Classif. Attr | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ...Length = 9 | selectorId = ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... 100 |selectorAlg = 5| Sampling Template ID = 260 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sampling Attributes Length=11 | selectorId = ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... 15 |selectorAlg = 1| Interval = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Space = 99 | >> +-+-+-+-+-+-+-+-+ >> >> Figure U: Encoding subTemplateMultiList, Data Set >> >> >> 8.5. Encoding an Options Template Set using Structured Data >> >> As described in Section 5.3. , consider a mediation function that >> must aggregate Data Records from multiple different Observation >> Points. >> >> Say Observation Point 1 consists of one or more interfaces, >> Observation Points 2 and 3 consist of one or more line cards, and >> Observation Point 4 consists of one or more interfaces and one or >> more line cards. Without structured data, a template would have >> to be defined for every possible combination to interpret the data >> corresponding to each of the Observation Points. However, with >> structured data, a basicList can be used to encode the list of >> interfaces and another basicList can be used to encode the list of >> line cards. >> >> For the sake of simplicity, each Observation Point shown below has >> an or or. This >> can very well be extended to include a list of interfaces and a >> list of linecards using basicLists as explained above. >> >> Observation Point 1: Router 1, (interface 1) >> Observation Point 2: Router 2, (line card A) >> Observation Point 3: Router 3, (line card B) >> Observation Point 4: Router 4, (line card C, interface 2) >> >> >> The mediation function wishes to express this as a single >> Observation Point, in order to encode the PSAMP Selection Sequence >> Report Interpretation (SSRI). Recall from [RFC5476] that the >> PSAMP Selection Sequence Report Interpretation consists of the >> following fields: >> >> Scope: selectionSequenceId >> Non-Scope: one Information Element mapping the Observation Point >> selectorId (one or more) >> >> For example, the Observation Point detailed above may be encoded >> in a PSAMP Selection Sequence Report Interpretation as shown >> below: >> >> Selection Sequence 7 (Filter->Sampling): >> observation point: subTemplateMultiList. >> Router 1, (interface 1) >> Router 2, (line card A) >> Router 3, (line card B) >> Router 4, (line card C, interface 2) >> selectorId: 5 (Filter, match IPV4SourceAddress 192.0.2.1) >> selectorId: 10 (Sampler, Random 1 out-of ten) >> >> The following Templates are defined to represent the PSAMP SSRI: >> Template for representing PSAMP SSRI: 262 >> Template for representing interface: 263 >> Template for representing linecard: 264 >> Template for representing linecard and interface: 265 >> >> >> PSAMP SSRI (262) >> | (SelectionSequenceId) >> | >> +--- Observation Point 1 (263) >> | (Interface Id) >> | >> +--- Observation Point 2 and 3 (264) >> | (line card) >> | >> +--- Observation Point 4 (265) >> | (line card) >> | (Interface Id) >> | >> | (selectorId 1) >> | (selectorId 2) >> >> >> Figure V: PSAMP SSRI to be encoded >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 3 | Length = 26 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 262 | Field Count = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Scope Field Count = 1 |0| selectionSequenceId = 301 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Scope 1 Length = 4 |0| subTemplateMultiList = ZZZ | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Length = 0xFFFF |0| selectorId = 302 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Length = 4 |0| selectorId = 302 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure W: Options Template Record for PSAMP SSRI using >> subTemplateMultiList >> >> A subTemplateMultiList with semantic allOf is used to encode the >> list of Observation Points. >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 | Length = 12 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 263 | Field Count = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| ingressInterface = 10 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure X: PSAMP SSRI, Template Record for interface >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 | Length = 12 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 264 | Field Count = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| lineCardId = 141 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure Y: PSAMP SSRI, Template Record for linecard >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 | Length = 16 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 265 | Field Count = 2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| lineCardId = 141 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| ingressInterface = 10 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure Z: PSAMP SSRI, Template Record for linecard and interface >> >> >> The PSAMP SSRI Data Set is represented as follows: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 262 | Length = 52 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | selectionSequenceId = 7 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 255 | Observation Point List Len=33 |semantic=allOf | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | OP1 Template ID = 263 | OP1 Length = 8 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | OP1 ingressInterface = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | OP2&3 Template ID = 264 | OP2&3 Length = 12 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | OP2 lineCardId = A | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | OP3 lineCardId = B | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | OP4 Template ID = 265 | OP4 Length = 12 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | OP4 lineCardId = C | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | OP4 ingressInterface = 2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | selectorId = 5 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | selectorId = 10 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure ZA: Example of a PSAMP SSRI Data Record, Encoded using a >> subTemplateMultiList >> >> Note that the Data Record above contains multiple instances of >> Template 264 to represent Observation Point 2 (line card A) and >> Observation Point 3 (line card B). Instead, if a single >> Observation Point had both line card A and line card B, a >> basicList would be used to represent the list of line cards. >> >> >> >> 9. Relationship with the Other IFPIX Documents >> >> 9.1. Relationship with Reducing Redundancy >> >> "Reducing Redundancy in IP Flow Information Export (IPFIX) and >> Packet Sampling (PSAMP) Reports" [RFC5473] describes a bandwidth >> saving method for exporting Flow or packet information using the >> IP Flow Information eXport (IPFIX) protocol. >> >> It defines the commonPropertiesID Information Element for >> exporting Common Properties. >> >> >> >> 9.1.1. Encoding Structured Data Element using Common Properties. >> >> When Structured Data Information Elements contain repeated >> elements, these elements may be replaced with a >> commonPropertiesID Information Element as specified in >> [RFC5473]. The replaced elements may include the basicList, >> subTemplateList and subTemplateMultiList Information Elements. >> >> This technique might help reducing the bandwidth requirements >> for the export. However, a detailed analysis of the gain has >> not been done; refer to Section 8.3 of [RFC5473] for further >> considerations. >> >> >> >> 9.1.2. Encoding Common Properties elements With Structured Data >> Element. >> >> Structured Data Information Element MAY be used to define a list >> of commonPropertiesID, as a replacement for the specifications >> in [RFC5473]. >> >> Indeed, the example in figures 1 and 2 of [RFC5473] can be >> encoded with the specifications in this document. >> >> >> +----------------+-------------+---------------------------+ >> | sourceAddressA | sourcePortA | | >> +----------------+-------------+---------------------------+ >> | sourceAddressA | sourcePortA | | >> +----------------+-------------+---------------------------+ >> | sourceAddressA | sourcePortA | | >> +----------------+-------------+---------------------------+ >> | sourceAddressA | sourcePortA | | >> +----------------+-------------+---------------------------+ >> | ... | ... | ... | >> +----------------+-------------+---------------------------+ >> >> Figure ZB: Common and Specific Properties Exported Together >> [RFC5473] >> >> +------------------------+-----------------+-------------+ >> | index for properties A | sourceAddressA | sourcePortA | >> +------------------------+-----------------+-------------+ >> | ... | ... | ... | >> +------------------------+-----------------+-------------+ >> >> >> +------------------------+---------------------------+ >> | index for properties A | | >> +------------------------+---------------------------+ >> | index for properties A | | >> +------------------------+---------------------------+ >> | index for properties A | | >> +------------------------+---------------------------+ >> | index for properties A | | >> +------------------------+---------------------------+ >> >> Figure ZC: Common and Specific Properties Exported Separately >> according to [RFC5473] >> >> +----------------+-------------+---------------------------+ >> | sourceAddressA | sourcePortA | | >> +----------------+-------------+---------------------------+ >> | | >> +---------------------------+ >> | | >> +---------------------------+ >> | | >> +---------------------------+ >> | ... | >> +---------------------------+ >> >> Figure ZD: Common and Specific Properties Exported with >> Structured Data Information Element >> >> >> The example in figure ZC could be encoded with a basicList if >> > Isn't it in figure ZD? > > >> the represents a single Information Element, >> with a subTemplateList if the represents a >> Template Record, or with a subTemplateMultiList if the> information> is composed of different Template Records. >> >> Using Structured Data Information Elements as a replacement for >> the techniques specified in "Reducing Redundancy in IP Flow >> Information Export (IPFIX) and Packet Sampling (PSAMP) Reports" >> [RFC5473] offers the advantage that a single Template Record is >> defined. Hence the Collectors job is simplified in terms of >> Template management and combining Template/Options Template >> Records. >> >> However, it must be noted that using Structured Data Information >> Elements as a replacement for the techniques specified in >> "Reducing Redundancy in IP Flow Information Export (IPFIX) and >> Packet Sampling (PSAMP) Reports" only applies to simplified >> cases. For example, the "Multiple Data Reduction" (Section 7.1 >> [RFC5473]) might be too complex to encode with Structured Data >> Information Elements. >> >> >> >> 9.2. Relationship with Guidelines for IPFIX Testing >> >> [RFC5471] presents a list of tests for implementers of IP Flow >> Information eXport (IPFIX) compliant Exporting Processes and >> Collecting Processes. >> >> Although [RFC5471] doesn't define any structured data element >> specific tests, the Structured Data Information Elements can be >> used in many of the [RFC5471] tests. >> >> The [RFC5471] series of test could be useful because the >> document specifies that every Information Element type should be >> tested. However, not all cases from this document are tested in >> [RFC5471]. >> >> The following sections are especially noteworthy: >> >> . 3.2.1. Transmission of Template with fixed size >> Information Elements >> >> - each data type should be used in at least one test. >> The new data types specified in Section 4.1. should >> be included in this test. >> >> . 3.2.2. Transmission of Template with variable length >> Information Elements >> >> - this test should be expanded to include Data Records >> containing variable length basicList, >> subTemplateList, and subTemplateMultiList Information >> Elements. >> >> . 3.3.1. Enterprise-specific Information Elements >> - this test should include the export of basicList, >> subTemplateList, and subTemplateMultiList Information >> Elements containing Enterprise-specific Information >> Elements. e.g., see the example in figure B. >> >> . 3.3.3. Multiple instances of the same Information Element >> in one Template >> >> - this test should verify that multiple instances of the >> basicList, subTemplateList and subTemplateMultiList >> Information Elements are accepted. >> >> . 3.5 Stress/Load tests >> >> - since the structured data types defined here allow >> modeling of complex data structures, they may be >> useful for stress testing both Exporting Processes >> and Collecting Processes. >> >> >> >> 9.3. Relationship with Bidirectional Flow Export >> >> [RFC5103] describes a method for exporting bidirectional flow >> information, and defines the biflowDirection Information Element >> for this purpose. >> >> [RFC5103] Biflows may be encoded in a subTemplateList or >> subTemplateMultiList. The basicList requires recurrence of a >> single element, so is not suitable for Biflows. >> >> Encoding Biflows with subTemplateList or subTemplateMultiList >> provides a more logical division of the information in both >> directions, although this encoding incurs a small additional >> bandwidth penalty. >> >> An example of Biflow encoding using Structure Data Information >> Elements and comparison with the [RFC5103] Biflow encoding is >> shown in Appendix B. >> >> >> 9.4. Relationship with IPFIX Mediation Function >> >> The Structured Data Information Elements would be beneficial for >> the export of aggregated Data Records in mediation function, as >> was demonstrated with the example of the aggregated Observation >> Point in Section 5.3. >> >> >> 10. IANA Considerations >> >> This document specifies several new IPFIX abstract data types, a >> new IPFIX Data Type Semantic, and several new Information >> Elements. >> >> These require the creation of two new IPFIX registries and >> updating the existing IPFIX Information Element registry as >> detailed below. >> >> >> 10.1. New Abstract Data Types >> >> Section 4.1. of this document specifies several new IPFIX abstract >> data types. Per Section 6 of the IPFIX information model >> [RFC5102], new abstract data types can be added to the IPFIX >> information model. This requires creation of a new IPFIX >> "abstract data types" registry at >> http://www.iana.org/assignments/ipfix. This registry should >> include all the abstract data types from Section 3.1 of [RFC5102]. >> >> Abstract data types to be added to the IPFIX "abstract data types" >> registry are listed below. >> >> >> 10.1.1. basicList >> >> The type "basicList" represents a list of any Information Element >> used for single-valued data types. >> >> >> 10.1.2. subTemplateList >> >> The type "subTemplateList" represents a list of a structured data >> type, where the data type of each list element is the same and >> corresponds with a single Template Record. >> >> >> 10.1.3. subTemplateMultiList >> >> The type "subTemplateMultiList" represents a list of structured >> data types, where the data types of the list elements can be >> different and correspond with different template definitions. >> >> >> 10.2. New Data Type Semantics >> >> Section 4.2. of this document specifies a new IPFIX Data Type >> Semantic. Per Section 3.2 of the IPFIX information model >> [RFC5102], new data type semantics can be added to the IPFIX >> information model. Therefore, the IANA IPFIX >> informationElementSemantics registry [IANA-IPFIX], which contains >> all the data type semantics from Section 3.2 of [RFC5102], must be >> augmented with the "list" value below. >> >> >> 10.2.1. list >> >> A list is a structured data type, being composed of a sequence of >> elements e.g. Information Element, Template Record, etc. >> >> >> 10.3. New Information Elements >> >> Section 4.3. of this document specifies several new Information >> Elements which are to be created in the IPFIX Information Element >> registry [IANA-IPFIX]. >> >> New Information Elements to be added to the IPFIX Information >> Element registry are listed below. >> >> EDITOR'S NOTE: the XML specification in Appendix A must be updated >> with the elementID values allocated below. >> >> 10.3.1. basicList >> >> Name: basicList >> Description: >> Specifies a generic Information Element with a basicList abstract >> data type. For example, a list of port numbers, a list of >> interface indexes, etc. >> Abstract Data Type: basicList >> Data Type Semantics: list >> ElementId: XXX (to be specified by IANA) >> Status: current >> >> 10.3.2. subTemplateList >> >> Name: subTemplateList >> Description: >> Specifies a generic Information Element with a subTemplateList >> abstract data type. >> Abstract Data Type: subTemplateList >> Data Type Semantics: list >> ElementId: YYY (to be specified by IANA) >> Status: current >> >> 10.3.3. subTemplateMultiList >> >> Name: subTemplateMultiList >> Description: >> Specifies a generic Information Element with a >> subTemplateMultiList abstract data type. >> Abstract Data Type: subTemplateMultiList >> Data Type Semantics: list >> ElementId: ZZZ (to be specified by IANA) >> Status: current >> >> 10.4. New Structured Data Semantics >> >> Section 4.4. of this document specifies a series of new IPFIX >> structured data type semantics, which is expressed as an 8-bit >> value. This requires the creation of a new IPFIX "structured data >> types semantics" IPFIX subregistry [IANA-IPFIX]. >> >> Entries may be added to this subregistry subject to a Standards >> Action [RFC5226]. Initially, this registry should include all the >> structured data type semantics listed below. >> >> >> 10.4.1. undefined >> >> A list is a structured data type, being composed of a sequence of >> elements e.g. Information Element, Template Record, etc. >> Value: 0xFF >> Description: undefined >> Reference: >> >> >> 10.4.2. noneOf >> >> A list is a structured data type, being composed of a sequence of >> elements e.g. Information Element, Template Record, etc. >> Value: 0x00 >> Description: noneOf >> Reference: >> >> >> 10.4.3. exactlyOneOf >> >> A list is a structured data type, being composed of a sequence of >> elements e.g. Information Element, Template Record, etc. >> Value: 0x01 >> Description: exactlyOneOf >> Reference: >> >> >> 10.4.4. oneOrMoreOf >> >> A list is a structured data type, being composed of a sequence of >> elements e.g. Information Element, Template Record, etc. >> Value: 0x02 >> Description: oneOrMoreOf >> Reference: >> >> 10.4.5. allOf >> >> A list is a structured data type, being composed of a sequence of >> elements e.g. Information Element, Template Record, etc. >> Value: 0x03 >> Description: allOf >> Reference: >> >> >> 10.4.6. ordered >> >> A list is a structured data type, being composed of a sequence of >> elements e.g. Information Element, Template Record, etc. >> Value: 0x04 >> Description: ordered >> Reference: >> >> >> 11. Security Considerations >> >> The same security considerations as for the IPFIX Protocol >> [RFC5101] apply. >> >> >> 12. References >> >> 12.1. Normative References >> >> [RFC2119] S. Bradner, Key words for use in RFCs to Indicate >> Requirement Levels, BCP 14, RFC 2119, March 1997. >> >> [RFC5101] Claise, B., Ed., "Specification of the IP Flow >> Information Export (IPFIX) Protocol for the Exchange of >> IP Traffic Flow Information", RFC 5101, January 2008. >> >> [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and >> J. Meyer, "Information Model for IP Flow Information >> Export", RFC 5102, January 2008. >> >> [RFC5226] T. Narten, T., Alverstrand, H. , "Guidelines for >> Writing an IANA Considerations Section in RFCs", >> RFC5226, May 2008. >> >> >> 12.2. Informative References >> >> >> [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, >> Requirements for IP Flow Information Export, RFC 3917, >> October 2004. >> >> [RFC5103] Trammell, B., and E. Boschi, "Bidirectional Flow >> Export Using IP Flow Information Export (IPFIX)", RFC >> 5103, January 2008. >> >> [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. >> Quittek, "Architecture for IP Flow Information Export", >> RFC 5470, March 2009. >> >> [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines >> for IP Flow Information Export (IPFIX) Testing", RFC >> 5471, March 2009. >> >> [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, >> "IP Flow Information Export (IPFIX) Applicability", RFC >> 5472, March 2009. >> >> [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing >> Redundancy in IP Flow Information Export (IPFIX) and >> Packet Sampling (PSAMP) Reports", RFC 5473, March 2009. >> >> [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., >> and F. Raspall, "Sampling and Filtering Techniques for >> IP Packet Selection", RFC 5475, March 2009. >> >> [RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol >> Specifications", RFC 5476, March 2009. >> >> [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and >> G. Carle, "Information Model for Packet Sampling >> Exports", RFC 5477, March 2009. >> >> [IANA-IPFIX] http://www.iana.org/assignments/ipfix/ipfix.xhtml >> >> >> 13. Acknowledgement >> >> The authors would like to thank Zhipu Jin, Nagaraj Varadharajan, >> Brian Trammel, and Atsushi Kobayashi for their feedback. >> >> >> 14. Authors' Addresses >> >> >> Benoit Claise >> Cisco Systems Inc. >> De Kleetlaan 6a b1 >> Diegem 1813 >> Belgium >> >> Phone: +32 2 704 5622 >> EMail: bclaise@cisco.com >> >> >> Gowri Dhandapani >> Cisco Systems Inc. >> 13615 Dulles Technology Drive >> Herndon, Virigina 20171 >> United States >> >> Phone: +1 408 853 0480 >> EMail: gowri@cisco.com >> >> >> Stan Yates >> Cisco Systems Inc. >> 7100-8 Kit Creek Road >> PO Box 14987 >> Research Triangle Park >> North Carolina, 27709-4987 >> United States >> >> Phone: +1 919 392 8044 >> EMail: syates@cisco.com >> >> >> >> Paul Aitken >> Cisco Systems (Scotland) Ltd. >> 96 Commercial Quay >> Commercial Street >> Edinburgh, EH6 6LX, United Kingdom >> >> Phone: +44 131 561 3616 >> EMail: paitken@cisco.com >> >> >> >> Appendix A. Additions to XML Specification of IPFIX Information >> Elements and Abstract Data Types >> >> This appendix contains additions to the machine-readable >> description of the IPFIX information model coded in XML in >> Appendix A and Appendix B in [RFC5102]. Note that this appendix >> is of informational nature, while the text in section 4. >> (generated from this appendix) is normative. >> >> The following field definitions are appended to the IPFIX >> information model in Appendix A of [RFC5102]. >> >> > dataType="basicList" >> group="structured-data" >> dataTypeSemantics="List" >> elementId="XXX" applicability="all" status="current"> >> >> >> Represents a list of zero or more instances of >> any single Information Element, primarily used for >> single-valued data types. For example, a list of port >> numbers, list of interface indexes, list of AS in a >> BGP AS-PATH, etc. >> >> >> >> >> > dataType="subTemplateList" >> group="structured-data" >> dataTypeSemantics="List" >> elementId="XXX" applicability="all" status="current"> >> >> >> Represents a list of zero or more instances of a >> structured data type, where the data type of each list >> element is the same and corresponds with a single >> Template Record. For example, a structured data type >> composed of multiple pairs of ("MPLS label stack entry >> position", "MPLS label stack value"), a structured data >> type composed of performance metrics, a structured data >> type composed of multiple pairs of IP address, etc. >> >> >> >> >> > dataType="subTemplateMultiList" >> group="structured-data" >> dataTypeSemantics="List" >> elementId="XXX" applicability="all" status="current"> >> >> >> Represents a list of zero or more instances of >> structured data types, where the data type of each list >> element can be different and corresponds with >> different template definitions. For example, a >> structured data type composed of multiple access-list >> entries, where entries can be composed of different >> criteria types. >> >> >> >> >> >> The following structured data type semantic definitions are >> appended to the the IPFIX information model in Appendix A of >> [RFC5102]. >> >> >> >> >> >> >> Specifies that the semantic of list elements is not >> specified, and that, if a semantic exists, then it is up >> to >> the Collecting Process to draw its own conclusions. The >> "undefined" structured data type semantic is the default >> Structured Data type semantic. >> >> >> >> >> >> >> >> Specifies that none of the elements are actual >> properties >> of the Data Record. >> >> >> >> >> >> >> >> Specifies that only a single element from the >> Structured Data is an actual property of the Data >> Record. This is equivalent to a logical XOR operation. >> >> >> >> >> >> >> >> Specifies that one or more element(s) from the list in >> the Structured Data is/are actual propertie(s) of the >> Data Record. This is equivalent to a logical OR >> operation. >> >> >> >> >> >> >> >> Specifies that all of the list elements from the >> Structured Data are actual properties of the Data >> Record. >> >> >> >> >> >> >> >> Specifies that elements from the list in the >> Structured Data are ordered. >> >> >> >> >> >> >> The following schema definitions are appended to the abstract data >> types defined in Appendix B of [RFC5102]. >> >> >> >> >> >> >> >> Represents a list of zero or more instances of >> any single Information Element, primarily used for >> single-valued data types. For example, a list of port >> numbers, list of interface indexes, list of AS in a >> BGP AS-PATH, etc. >> >> >> >> >> >> >> Represents a list of zero or more instances of a >> structured data type, where the data type of each list >> element is the same and corresponds with a single >> Template Record. For example, a structured data type >> composed of multiple pairs of ("MPLS label stack entry >> position", "MPLS label stack value"), a structured >> data type composed of performance metrics, a >> structured data type composed of multiple pairs of IP >> address, etc. >> >> >> >> >> >> >> Represents a list of zero or more instances of >> structured data types, where the data type of each >> list element can be different and corresponds with >> different template definitions. For example, a >> structured data type composed of multiple >> access-list entries, where entries can be >> composed of different criteria types. >> >> >> >> >> >> >> >> >> >> >> >> Represents an arbitrary-length sequence of structured >> data elements, either composed of regular Information >> Elements or composed of data conforming to a Template >> Record. >> >> >> >> >> >> >> >> >> > minOccurs="1" maxOccurs="unbounded"> >> >> >> >> >> >> > use="required"/> >> >> >> >> >> >> > type="structuredDataTypeSemantics"> >> >> >> Structured Data type semantics express the relationship >> among multiple list elements in a Structured Data >> Information Element. >> >> >> >> >> >> >> Appendix B. Example of Biflow Encoding using Structured Data >> Information Elements >> >> Referring to [RFC5103] figure 1, a Biflow consists of two parts: >> some "key" fields such as src/dst information (IP addresses, >> ports), followed by a set of forward/reverse pairs. >> >> Then looking at [RFC5103] figure 7, we see that the Reverse PEN >> is repeated many times to indicate fields which were observed in >> the reverse direction. Clearly that repetition is wasteful. >> > You mean that it is wasteful if such a Template is used in a Structured > Data Information Element? > Or in general? In this case, I do not think that the PEN is a problem. > The Template is exported only once. > > >> >> Looking back at [RFC5103] figure 1, it's clear that the encoding >> can use a Template Record consisting of the Flow Keys followed >> by a subTemplateList consisting of two elements: one for the >> forward direction, the other for the reverse direction. >> >> The subTemplateList uses a single Template Record to describe >> the fields in both lists since they are a set of forward/reverse >> pairs. >> >> >> Uniflow Uniflow >> +-------+-------+-----------------+ +-------+-------+-----------------+ >> | src A | dst B | counters/values | | src B | dst A | counters/values | >> +-------+-------+-----------------+ +-------+-------+-----------------+ >> | | | | >> V V V V >> +-------+-------+---------------------+---------------------+ >> | src A | dst B | fwd counters/values | rev counters/values | >> +-------+-------+---------------------+---------------------+ >> | | | >> V V V >> key fields fwd element rev element >> >> Figure B0: Using a subTemplateList to represent a Biflow. >> > You should show where the subTemplateList is. > > >> >> The following example shows the example from Appendix A of >> [RFC5103] encoded using a subTemplateList: >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 | Length = 24 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 266 | Field Count = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| flowDirection 61 | Field Length = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| flowStartSeconds 150 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| octetTotalCount 85 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| packetTotalCount 86 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure B1: Template for the Biflow Fields >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 | Length = 32 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 267 | Field Count = 6 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| sourceIPv4Address 8 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| destinationIPv4Address 12 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| sourceTransportPort 7 | Field Length = 2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| destinationTransportPort 11 | Field Length = 2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| protocolIdentifier 4 | Field Length = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| subTemplateList = YYY | Field Length = 29 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure B2: Template for the Key Fields >> >> The Template Record includes a subTemplateList with semantic allOf >> for encoding the BiFlow fields for the forward and reverse >> direction. Note that the subTemplateList is encoded using Fixed >> Length, as shown in the above template definition. >> > _f_ixed _l_ength, _T_emplate > > >> >> >> Also, note that the overall template size is 24 + 32 = 56 octets, >> compared with 64 octets in the [RFC5103] example - so a small >> saving is achieved. >> > Is the Template length actually relevant? The Template is exported only > once. > > >> >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 267 | Length = 46 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | sourceIPv4Address = 192.0.2.2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | destinationIPv4Address = 192.0.2.3 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | sourceTransportPort = 32770 | destinationTransportPort = 80 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | protocol = 6 |semantic=allOf | Template ID = 266 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | dir = forward | flowStartSeconds = 2006-02-01 17:00:00 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | octetTotalCount = 18000 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | packetTotalCount = 65 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | dir = reverse | flowStartSeconds = ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... 2006-02-01 17:00:01 | octetTotalCount = 128000 ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | packetTotalCount = 110 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure B3: Biflow Data Set Encoded using Structured Data >> >> >> Note that the Data Set length is 46, compared with 41 in RFC5103. >> The five additional octets are due to the inclusion of the 8-bit >> semantic, 16-bit Template ID and two, 8-bit direction indicators. >> >> Clearly structured data offers an alternative way to encode >> Biflows. Although this may not be best suited if the number of >> elements is small as in this example, it does offer a more robust >> and scalable solution if multiple elements need to be encoded. >> > I do not understand. The Data Record will always be larger than in the > RFC5103 case. So, where is a scalability advantage? And where is a > robustness advantage? In both cases, the flow information is included in > one Data Record. > > >> Appendix C. Encoding IPS Alert using Structured Data Information >> Elements >> >> In this section, an IPS alert example is used to demonstrate how >> complex data and multiple levels of hierarchy can be encoded using >> Structured Data Information Elements. Also, this example >> demonstrates how a basicList of subTemplateLists can be used to >> represent semantics at multiple levels in the hierarchy. >> >> An IPS alert consists of the following mandatory attributes: >> signatureId, protocolIdentifier and riskRating. It can also >> contain zero or more participants, each participant can contain >> zero or more attackers and zero or more targets. An attacker >> contains the attributes sourceIPv4Address and applicationId, and >> a target contains the attributes destinationIPv4Address and >> applicationId. >> >> Note that the signatureId and riskRating Information Element >> fields are created for these examples only; the Field IDs are >> shown as N/A. The signatureId helps to uniquely identify the IPS >> signature that triggered the alert. The riskRating identifies the >> potential risk, on a scale of 0-100 (100 being most serious), of >> the traffic that triggered the alert. >> >> Consider the example described in case study 2 of Section 5.6. The >> IPS alert contains participants encoded as a subTemplateList with >> semantic allOf. Each participant uses a basicList of >> subTemplateLists to represent attackers and targets. For the sake >> of simplicity, the alert has two participants P1 and P2. In >> participant P1, attacker A1 or A2 attack target T1. In >> participant P2, attacker A3 attacks targets T2 and T3. >> >> Participant P1: >> >> (basicList, allof, >> >> (subTemplateList, exactlyOneOf, attacker A1, A2) >> >> (subTemplateList, undefined, target T1) >> >> ) >> >> Participant P2: >> >> (basicList, allOf, >> >> (subTemplateList, undefined, attacker A3, >> (subTemplateList, allOf, targets T2, T3) >> >> ) >> >> Alert : >> >> (subTemplateList, allOf, Participant P1, Participant P2) >> >> >> ------------------------------------------------------------------ >> | | | participant >> sigId |protocol| risk | attacker | target >> | Id | Rating | IP | appId | IP | appId >> ------------------------------------------------------------------ >> 1003 17 10 192.0.2.3 103 192.0.2.103 3001 >> 192.0.2.4 104 >> >> 192.0.2.5 105 192.0.2.104 4001 >> 192.0.2.105 5001 >> ------------------------------------------------------------------ >> >> Participant P1 contains: >> Attacker A1: (IP, appID)=(192.0.2.3, 103) >> Attacker A2: (IP, appID)=(192.0.2.4, 104) >> Target T1: (IP, appID)= (192.0.2.103, 3001) >> >> Participant P2 contains: >> Attacker A3: (IP, appID) = (192.0.2.5, 105) >> Target T2: (IP, appID)= (192.0.2.104, 4001) >> Target T3: (IP, appID)= (192.0.2.105, 5001) >> >> >> To represent an alert, the following Templates are defined: >> Template for target (268) >> Template for attacker (269) >> Template for participant (270) >> Template for alert (271) >> >> alert (271) >> | (signatureId) >> | (protocolIdentifier) >> | (riskRating) >> | >> +------- participant (270) >> | >> +------- attacker (269) >> | (sourceIPv4Address) >> | (applicationId) >> | >> +------- target (268) >> | (destinationIPv4Address) >> | (applicationId) >> >> Note that the attackers are always composed of a single >> applicationId, while the targets typically have multiple >> applicationId, for the sake of simplicity this example shows only >> one applicationId in the target. >> >> Template Record for target, with the Template ID 268: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 | Length = 16 octets | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 268 | Field Count = 2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| destinationIPv4Address = 12 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| applicationId = 95 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure C0: Encoding IPS Alert, Template for Target >> >> >> Template Record for attacker, with the Template ID 269: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 | Length = 16 octets | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 269 | Field Count = 2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| sourceIPv4Address = 8 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| applicationId = 95 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure C1: Encoding IPS Alert, Template for Attacker >> >> >> Template Record for participant, with the Template ID 270: >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 | Length = 12 octets | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 270 | Field Count = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| basicList = XXX | Field Length = 0xFFFF | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure C2: Encoding IPS Alert, Template for Participant >> >> >> The Template Record for the participant has one basicList >> Information Element, which is a list of subTemplateLists of >> attackers and targets. >> >> Template Record for IPS alert, with the Template ID 271: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 | Length = 24 octets | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 271 | Field Count = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| signatureId = N/A | Field Length = 2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| protocolIdentifier = 4 | Field Length = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| riskRating = N/A | Field Length = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| subTemplateList = YYY | Field Length = 0xFFFF | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure C3: Encoding IPS Alert, Template for IPS Alert >> >> The subTemplateList in the alert Template Record contains a list >> of participants. >> >> The Length of basicList and subTemplateList are encoded in three >> bytes even though they may be less than 255 octets. >> >> >> The Data Set is represented as follows: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 271 | Length = 102 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | signatureId = 1003 | protocolId=17 | riskRating=10 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 255 |participant List Length = 91 |semantic=allOf | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | participant Template ID = 270 | 255 | P1 List Len = | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 41 | semantic=allOf| P1 List Field ID = YYY | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | P1 List Field ID Len = 0xFFFF | 255 |P1 attacker ...| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | List Len = 19 |sem=exactlyOne | P1 attacker Template ID = 269 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | P1 attacker A1 sourceIPv4Address = 192.0.2.3 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | P1 attacker A1 applicationId = 103 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | P1 attacker A2 sourceIPv4Address = 192.0.2.4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | P1 attacker A2 applicationId = 104 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 255 | P1 target List Len = 11 | sem=undefined | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | P1 target Template ID = 268 | P1 target T1 destinationIPv4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... Address = 192.0.2.103 |P1 target T1 applicationId =...| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... 3001 | 255 | P2 List Len = | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... 41 | semantic=allOf| P2 List Field ID = YYY | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | P2 List Field ID Len = 0xFFFF | 255 |P2 attacker ...| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | List Len = 11 | sem=undefined | P2 attacker Template ID = 269 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | P2 attacker A3 sourceIPv4Address = 192.0.2.5 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | P2 attacker A3 applicationId = 105 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 255 | P2 target List Len = 19 |semantic=allOf | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | P2 target Template ID = 268 | P2 target T2 destinationIPv4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... Address = 192.0.2.104 |P2 target T2 applicationId =...| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... 4001 | P2 target T3 destinationIPv4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... Address = 192.0.2.105 |P2 target T3 applicationId =...| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... 5001 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure C4: Encoding IPS Alert, Data Set >> >> > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > --------------040200090604060200060109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard,

I'm impressed by your review. I can see that you spent quite some time.
Let me address the biggest issue in this email thread.
Dear Benoit, all,

Here is my review of draft-ietf-ipfix-structured-data-02. It mainly
consists of suggestions and comments regarding the comprehensibility and
language.

There is one suggestion about the specification itself. I think that it
would be easier to understand if the meaning of the semantic of
subTemplateList and subTemplateMultiList would be the same, namely that
it specifies the semantic among the Data Records. At the moment, the
draft specifies (although not very clearly) that the semantic refers to
goups of Data Records associated to different Templates in the case of
the subTemplateMultiList. I do not see a use-case for this. Also, no
useful example is provided. On the contrary, it is always said that the
semantic of subTemplateMultiList is not sufficient.
  

That's an important one, to be discussed at the meeting tomorrow.
A use case could be a middle box function on a router, for which we want to export the series of flow records before the function, and the new series of flow records (*) after the function.
(*) a WAN optimization function could produce a completely different set of flow records, potentially because you encapsulate everything into a new transport.

Note that we give a workaround if we need two levels of semantics.


      Semantic
 
          The Semantic indicates the top level semantic among Template
          Records, i.e. the relationship among the series of Data
          Records from the different Template Records within this
          Structured Data.
 
          Note: if a semantic is required to describe the relationship
          among the different Data Records corresponding to a single
          Template ID within the subTemplateMultiList, then an encoding
          based on a basicList of subTemplateLists should be used. Refer
          to Section 5.6 for more information.


I'll have some slides tomorrow to explain this issue.

Regards, Benoit.

Regards,
Gerhard


  
     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. 
    
Maybe add some words about semantics?

  
     1. Overview 

     1.1. IPFIX Documents Overview 

      The IPFIX Protocol [RFC5101] provides network administrators with 
      access to IP Flow information. 
       
      The architecture for the export of measured IP Flow information 
      out of an IPFIX Exporting Process to a Collecting Process is 
      defined in the IPFIX Architecture [RFC5470], per the requirements 
      defined in RFC 3917 [RFC3917]. 
       
      The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records 
      and Templates are carried via a congestion-aware transport 
      protocol from IPFIX Exporting Processes to IPFIX Collecting 
      Processes. 
       
      IPFIX has a formal description of IPFIX Information Elements, 
      their name, type and additional semantic information, as specified 
      in the IPFIX information model [RFC5102]. 
       
      In order to gain a level of confidence in the IPFIX 
      implementation, probe the conformity and robustness, and allow 
      interoperability, the Guidelines for IPFIX Testing [RFC5471] 
      presents a list of tests for implementers of compliant Exporting 
      Processes and Collecting Processes. 
      
      The Bidirectional Flow Export [RFC5103] specifies a method for 
      exporting bidirectional flow (biflow) information using the IP 
      Flow Information Export (IPFIX) protocol, representing each Biflow 
      using a single Flow Record. 
       
      The "Reducing Redundancy in IP Flow Information Export (IPFIX) and 
      Packet Sampling (PSAMP) Reports" [RFC5473] specifies a bandwidth 
      saving method for exporting Flow or packet information, by 
      separating information common to several Flow Records from 
      information specific to an individual Flow Record: common Flow 
      information is exported only once. 
      
      
     1.2. Relationship between IPFIX and PSAMP 

      The specification in this document applies to the IPFIX protocol 
      specifications [RFC5101].  All specifications from [RFC5101] apply 
      unless specified otherwise in this document. 
       
      The Packet Sampling (PSAMP) protocol [RFC5476] specifies the 
      export of packet information from a PSAMP Exporting Process to a 
      PSAMP Collecting Process.  Like IPFIX, PSAMP has a formal 
      description of its information elements, their name, type and 
      additional semantic information.  The PSAMP information model is 
      defined in [RFC5477]. 
      
      As the PSAMP protocol specifications [RFC5476] are based on the 
      IPFIX protocol specifications, the specifications in this document 
      are also valid for the PSAMP protocol.  
        
      Indeed, the major difference between IPFIX and PSAMP is that the 
      IPFIX protocol exports Flow Records while the PSAMP protocol 
      exports Packet Reports.  From a pure export point of view, IPFIX 
      will not distinguish a Flow Record composed of several packets 
      aggregated together, from a Flow Record composed of a single 
      packet.  So the PSAMP export can be seen as a special IPFIX Flow 
      Record containing information about a single packet. 
      
      
     2. Terminology 

      IPFIX-specific terminology used in this document is defined in 
      Section 2 of the IPFIX protocol specification [RFC5101] and 
      Section 3 of PSAMP protocol specification [RFC5476].  As in 
      [RFC5101], these IPFIX-specific terms have the first letter of a 
      word capitalized when used in this document. 
       
       
     2.1. New Terminology 

      Structured Data Information Element 
       
          One of the Information Elements supporting structured data, 
          i.e., the basicList, subTemplateList, or subTemplateMultiList 
          Information Elements specified in section 4.3.  
      
      
     3. Introduction 

      While collecting the interface counters every five minutes has 
      proven to be useful in the past, more and more granular 
      information is required from network elements for a series of 
      applications: performance assurance, capacity planning, security, 
      billing, or simply monitoring.  However, the amount of information 
      has become so important that, when dealing with highly granular 
      information such as Flow information, a push mechanism (as opposed 
      to a pull mechanism, such as SNMP) is the only solution for 
      routers whose primary function is to route packets.  Indeed, 
      polling short-live Flows via SNMP is not an option: high end 
      routers can support hundreds of thousands of Flows simultaneously.  
      Furthermore, in order to reduce the export bandwidth requirements, 
      the network elements have to integrate mediation functions to 
      aggregate the collected information, both in space and time. 
       
      Typically, it would be beneficial if access routers could export 
      Flow Records, composed of the counters before and after the WAN 
      optimization mechanism, instead of exporting two Flow Records with 
      identical tuple information. 
    
It is not clear what "the WAN optimization mechanism" is.

  
      In terms of aggregation in time, let us imagine that, for 
      performance assurance, the network management application must 
      receive the performance metrics associated with a specific flow, 
      every millisecond.  Since the performance metrics will be 
      constantly changing, there is a new dimension to the Flow 
      definition: we are not dealing anymore with a single Flow lasting 
      a few seconds or a few minutes, but with a multitude of one 
      millisecond sub flows for which the performance metrics are 
      reported. 
                        
      Which current protocol is suitable for these requirements: push 
      mechanism, highly granular information, and huge number of similar 
      records? IPFIX, as specified in RFC5101 would give part of the 
      solution. 
       
      
     3.1. The IPFIX Track 

      The IPFIX working group has specified a protocol to export IP Flow 
      information [RFC5101].  This protocol is designed to export 
      information about IP traffic Flows and related measurement data, 
      where a Flow is defined by a set of key attributes (e.g. source 
      and destination IP address, source and destination port, etc.).   
       
      The IPFIX protocol specification [RFC5101] specifies that IP 
      traffic measurements for Flows are exported using a TLV (type, 
      length, value) format.  The information is exported using a 
      Template Record that is sent once to export the {type, length} 
      pairs that define the data format for the Information Elements in 
      a Flow.  The Data Records specify values for each Flow.   
       
      Based on the Requirements for IP Flow Information Export (IPFIX) 
      [RFC3917], the IPFIX protocol has been optimized to export Flow 
      related information.  However, thanks to its Template mechanism, 
      the IPFIX protocol can export any type of information, as long as 
      the relevant Information Element is specified in the IPFIX 
      information model [RFC5102], registered with IANA [IANA-IPFIX], or 
      specified as an enterprise-specific Information Element.  For each 
      Information Element, the IPFIX information model [RFC5102] defines 
      a numeric identifier, an abstract data type, an encoding mechanism 
      for the data type, and any semantic constraints.  Only basic, 
      single-valued data types, e.g., numbers, strings, and network 
      addresses are currently supported. 

      
     3.2. The IPFIX Limitations 

      The IPFIX protocol specification [RFC5101] does not support the 
      encoding of hierarchical structured data and arbitrary-length 
      lists (sequences) of Information Elements as fields within a 
      Template Record.  As it is currently specified, a Data Record is a 
      "flat" list of single-valued attributes.  However, it is a common 
      data modeling requirement to compose complex hierarchies of data 
      types, with multiple occurrences, e.g., 0..* cardinality allowed 
      for instances of each Information Element in the hierarchy.  

      A typical example is the MPLS label stack entries model.  An early 
      NetFlow implementation used two Information Elements to represent 
      the MPLS label stack entry: a "label stack entry position" 
      followed by a "label stack value".  However, several drawbacks 
      were discovered.  Firstly, the Information Elements in the 
      Template Record had to be imposed so that the position would 
      always precede the value.  However, some encoding optimizations 
      are based on the permutation of Information Element order.  
      Secondly, a new semantic intelligence, not described in the 
      information model, had to be hardcoded in the Collecting Process: 
      the label value at the position "X" in the stack is contained in 
      the "label stack value" Information Element following by a "label 
      stack entry position" Information Element containing the value 
      "X".  Therefore, this model was abandoned. 
       
      The selected solution in the IPFIX information model [RFC5102] is 
      a long series of Information Elements: mplsTopLabelStackSection, 
      mplsLabelStackSection2, mplsLabelStackSection3, 
      mplsLabelStackSection4, mplsLabelStackSection5, 
      mplsLabelStackSection6, mplsLabelStackSection7, 
      mplsLabelStackSection8, mplsLabelStackSection9, 
      mplsLabelStackSection10.  While this model removes any ambiguity, 
      it overloads the IPFIX information model with repetitive 
      information.  Furthermore, if mplsLabelStackSection11 is required, 
      IANA [IANA-IPFIX] will not be able to assign the new Information 
      Element next to the other ones in the registry, which might cause 
      some confusion. 
       
      Clearly a real structured data type composed of ("label stack 
      entry position", "label stack value") pairs, potentially repeated 
      multiple times in Flow Records would be more efficient from an 
      information model point of view. 
       
      Some more examples enter the same category: how to encode the list 
      of output interfaces in a multicast Flow, how to encode the list 
      of BGP Autonomous Systems (AS) in a BGP Flow, how to encode the 
      BGP communities in a BGP Flow, etc?  
       
      The one-way delay passive measurement, which is described in the 
      IPFIX Applicability [RFC5472], is yet another example that would 
      benefit from a structured data encoding.  Assuming synchronized 
      clocks, the Collector can deduce the one-way delay from the 
      following two Information Elements, collected from two different 
      Observation Points: 
          - Packet arrival time: observationTimeMicroseconds [RFC5477] 
          - Packet ID: digestHashValue [RFC5477] 
      Ideally, the measurement at the second Observation Point should 
      start a little bit later than at the first Observation Point, 
      allowing the packets to arrive at the destination.  
    
I do not understand this sentence. How does the measurement affect
packet forwarding? How can the measurement allow packets to arrive
somewhere?

  
In practice, 
      this implies that many pairs of (observationTimeMicroseconds, 
      digestHashValue) must be exported for each Observation Point, even 
      if some optimization based on Hash-Based Filtering [RFC5475] is 
      used.  
    
What can be "optimized" by HBF?

Maybe: "...even if Hash-Based Filtering is used."

  
Instead of exporting repetitive information as part of
      every single Flow Record (for example, the 5 tuple), an optimized 
    
I suggest to remove all occurrences of "optimize", "optimization" etc.
unless there is a metric based on which you optimize and unless you can
tell whether you reach a global optimum or a local optimum.

  
      flow record composed of a structured data type such as the 
      following would save a lot of bandwidth: 
       
          5 tuple 
    
It would be good to explain what "5 tuple" means.

  
                    { observationTimeMicroseconds 1, digestHashValue 1 } 
                    { observationTimeMicroseconds 2, digestHashValue 2 } 
                    { observationTimeMicroseconds 3, digestHashValue 3 } 
                    { ...  , ... } 
    
The example has remaind unclear to me until I understood what you
describe here. In particular, it is not obvious to me that OWD
measurements are exported in Flow Records together with the 5 tuple.

If you perform OWD measurements, isn't it sufficient to just export
digestHashValue and observationTimeMicroseconds?

Also, if you talk about Flow Records here, you actually mean PSAMP
Packet Report (i.e. one packet Flow), right? This is not explained.

  
      As a last example, here is a more complex case of hierarchical 
      structured data encoding.  Consider the example scenario of an IPS 
      (Intrusion Prevention System) alert data structure containing 
      multiple participants, where each participant contains multiple 
      attackers and multiple targets, with each target potentially 
      composed of multiple applications, as depicted below: 
       
          alert 
              signatureId 
              protocolIdentifier 
              riskRating 
              participant 1 
                  attacker 1 
                      sourceIPv4Address 
                      applicationId 
                  ... 
                  attacker N 
                      sourceIPv4Address 
                      applicationId 
                  target 1 
                      destinationIPv4Address 
                      applicationId 1 
                      ... 
                      applicationId n 
                  ... 
                  target N 
                      destinationIPv4Address 
                      applicationId 1 
                      ... 
                      applicationId n 
              participant 2 
                  ... 
       
      To export this information in IPFIX, the data would need to be 
      flattened (thus losing the hierarchical relationships) and a new 
      IPFIX Template created for each alert, according to the number of 
      applicationID elements in each target, the number of targets and 
      attackers in each participant, and the number of participants in 
      each alert.  Clearly each Template will be unique to each alert, 
      and a large amount of CPU, memory and export bandwidth will be 
      wasted creating, exporting, maintaining, and withdrawing the 
      Templates.  See Appendix C for a specific example related to this 
      case study. 
      
      
     3.3. The Proposal 

      This document specifies an IPFIX extension to support hierarchical 
      structured data and variable-length lists by defining three new 
      Information Elements and three corresponding new abstract data 
      types called basicList, subTemplateList, and subTemplateMultiList. 

      These are defined in Section 4.1.  The three list Information 
      Elements carry some semantic information so that the Collecting 
      Process can understand the relationship between the different list 
      elements.  
       
      It is important to note that whereas the Information Elements and 
      abstract data types defined in the IPFIX information model 
      [RFC5102] represent single values, these new abstract data types 
      are structural in nature and primarily contain references to other 
      Information Elements and to Templates.  By referencing other 
      Information Elements and Templates from an Information Element's 
      data content, it is possible to define complex data structures 
      such as variable-length lists and to specify hierarchical 
      containment relationships between Templates.  Therefore, this 
      document prefers the more generic "Data Record" term to the "Flow 
      Record" term. 
       
      This document specifies three new abstract data types, which are 
      basic blocks to represent structured data.  However, this document 
      does not comment on all possible combinations of basicList, 
      subTemplateList, and subTemplateMultiList.  Neither, does it limit 
      the possible combinations.  
      
     4. Linkage with the Information Model 

      As in the IPFIX Protocol specification [RFC5101], the new 
      Information Elements specified in Section 4.3. below MUST be sent 
      in canonical format in network-byte order (also known as the big-
      endian byte ordering). 
       
       
     4.1. New Abstract Data Types 

      This document specifies three new abstract data types, as 
      described below. 
       
       
     4.1.1. basicList 

      The type "basicList" represents a list of zero or more instances 
      of any single Information Element, primarily used for single-
      valued data types.  For example, a list of port numbers, a list of 
      interface indexes, a list of AS in a BGP AS-PATH, etc.  
         

     4.1.2. subTemplateList 

      The type "subTemplateList" represents a list of zero or more 
      instances of a structured data type, where the data type of each 
      list element is the same and corresponds with a single Template 
      Record.  For example, a structured data type composed of multiple 
      pairs of ("MPLS label stack entry position", "MPLS label stack 
      value"), a structured data type composed of performance metrics, a 
      structured data type composed of multiple pairs of IP address, 
      etc. 
       
       
     4.1.3. subTemplateMultiList 

      The type "subTemplateMultiList" represents a list of zero or more 
      instances of a structured data type, where the data type of each 
      list element can be different and corresponds with different 
      template definitions.  For example, a structured data type 
      composed of multiple access-list entries, where entries can be 
      composed of different criteria types. 
       
       
     4.2. New Data Type Semantic 

      This document specifies a new data type semantic, as described 
      below.  
       
       
     4.2.1. List 

      A list represents an arbitrary-length sequence of zero or more 
      structured data elements, either composed of regular Information 
      Elements or composed of data conforming to a Template Record. 
      
     4.3. New Information Elements 

      This document specifies three new Information Elements, as 
      described below. 
       
       
     4.3.1. basicList 

      A basicList specifies a generic Information Element with a 
      basicList abstract data type as defined in Section 4.1.1. and list 
      semantics as defined in Section 4.2.1.  For example, a list of 
      port numbers, a list of interface indexes, etc.   

      EDITOR'S NOTE: while waiting for IANA [IANA-IPFIX] to assign this 
      new Information Element identifier, the value XXX is used in all 
      the examples and in the XML in Appendix A. 
       
     4.3.2. subTemplateList 

      A subTemplateList specifies a generic Information Element with a 
      subTemplateList abstract data type as defined in Section 4.1.2. 
      and list semantics as defined in Section 4.2.1.  
       
      EDITOR'S NOTE: while waiting for IANA [IANA-IPFIX] to assign this 
      new Information Element identifier, the value YYY is used in all 
      the examples.   
       
       
     4.3.3. subTemplateMultiList 

      A subTemplateMultiList specifies a generic Information Element 
      with a subTemplateMultiList abstract data type as defined in 
      Section 4.1.3. and list semantics as defined in Section 4.2.1.  
       
      EDITOR'S NOTE: while waiting for IANA [IANA-IPFIX] to assign this 
      new Information Element identifier, the value ZZZ is used in all 
      the examples. 
       
     4.4. New Structured Data Type Semantics 

     Structured Data type semantics are provided in order to express 
    
Structured _d_ata type

  
     the relationship among multiple list elements in a Structured Data 
     Information Element.  These Structured Data type semantics require 
    
_s_tructured _d_ata (is not a term!)

Please check all further occurrences below! The usage of capital letters
is inconsistent.

  
     a new IPFIX subregistry, as specified in the "IANA Considerations" 
     section.  The semantics are specified in the next following 
     sections. 

     4.4.1. undefined 

     The "undefined" Structured Data type semantic specifies that the 
     semantic of list elements is not specified, and that, if a 
     semantic exists, then it is up to the Collecting Process to draw 
     its own conclusions.  The "undefined" structured data type 
     semantic is the default Structured Data type semantic.  

     4.4.2. noneOf 

     The "noneOf" Structured Data type semantic specifies that none of 
     the elements are actual properties of the Data Record.   

     For example, a mediator might want to report to a Collector that a 
     specific Flow is suspicious, but that it checked already that this 
     Flow does not belong to the attack type 1, attack type 2, and 
     attack type 3.  So this Flow might need some further inspection.  
     In such a case, the mediator would report the Flow Record with a 
     basicList composed of (attack type 1, attack type 2, attack type 
     3) and the respective Structured Data type semantic of "noneOf". 

     Another example is a router that monitors some specific BGP AS-
     PATHs and reports if a Flow belongs to any of them.  If the router 
     wants to export that a Flow does not belong to any of the 
     monitored BGP AS-PATHs, the router reports a Data Record with a 
     basicList composed of (BGP AS-PATH 1, BGP AS-PATH 2, BGP AS-PATH 
     3) and the respective Structured Data type semantic of "noneOf". 
      

     4.4.3. exactlyOneOf 

     The "exactlyOneOf" Structured Data type semantic specifies that 
     only a single element from the Structured Data is an actual 
     property of the Data Record.  This is equivalent to a logical XOR 
     operation. 

     For example, if a Flow record contains a basicList of outgoing 
     interfaces with the "exactlyOneOf" semantic, then it implies that 
     the reported Flow only egressed from a single interface, although 
     the Flow Record lists all of the possible outgoing interfaces.  
     This is a typical example of a per destination load-balanced Flow 
     IPFIX encoding. 
    
What does the last sentence mean? How can structured data be typical if
it has not even been standardized?

  
     For example, a mediator must report an aggregated observation 
    
"Another example is a mediator which must..."

You should explain what an "aggregate observation point" is.

  
     point, composed of multiple Template Records: 
    
Unclear. The information about OPs is exported in Data Records, not in
Template Records.

  
      
         Template Record 1: exporterIPaddress  
         This reports a specific exporter 
          
         Template Record 2: exporterIPaddress, basicList of interfaces 
         This reports a series of interfaces from an exporter 
          
         Template Record 3: exporterIPaddress, line card 
         This reports a specific line card from an exporter 

     If these three Template Records are exported with a 
     subTemplateMultiList with the semantic "exactlyOneOf", then it 
    
You only export Data Records in a subTemplateMultiList, not Template
Records!

  
     implies that the Flow Observation Point is reported with the 
    
"Flow's Observation Point"?

  
     values of either Template Record 1, Template Record 2, or Template 
     Record 3 but not more than one Template Record.  
    
I would rewrite it in two sentences, e.g.:

"The Flow Record exported by the mediator contains a
subTemplateMultiList field with semantic "exactlyOneOf" containing one
Data Record for each of the Template Records described above. This
implies that the Flow was observed at exactly one of the Observation
Points reported."

  
     4.4.4. oneOrMoreOf 

     The "oneOrMoreOf" Structured Data type semantic specifies that one 
     or more element(s) from the list in the Structured Data is/are 
    
I do not like (s) and "/" alternatives.

"elements .... are"

  
     actual propertie(s) of the Data Record.  This is equivalent to a 
    
"properties"

  
     logical OR operation.  

     For example, a mediator must report an aggregated Flow (for 
     example aggregated from IP addresses to IP prefixes), with an 
    
"(for ...)" => "(e.g. aggregating IP addresses with common IP prefixes)"

  
     aggregated observation point, composed of multiple Template 
     Records: 

      
         Template Record 1: exporterIPaddress  
         This reports a specific exporter 
          
         Template Record 2: exporterIPaddress, basicList of interfaces 
         This reports a series of interfaces from an exporter 
          
         Template Record 3: exporterIPaddress, line card 
         This reports a specific line card from an exporter 

     If these three Template Records are exported with a 
     subTemplateMultiList with the semantic "oneOrMoreOf", then the 
    
Same comments as in section 4.4.3.

  
     aggregated Flow has been observed on at least one of the 
     individual Observation Points reported with the values of a 
     specific Template Record, and potentially on multiple Observation 
     Points. 
      

     4.4.5. allOf 

     The "allOf" structured data type semantic specifies that all of 
     the list elements from the Structured Data are actual properties 
     of the Data Record. 

     For example, if a Record contains a basicList of outgoing 
     interfaces with the "allOf" semantic, then the observed Flow is 
     typically a multicast Flow where each packet in the Flow has been 
     replicated to each outgoing interface in the basicList. 
      

     4.4.6. ordered 

     The "ordered" Structured Data type semantic specifies that 
     elements from the list in the Structured Data are ordered. 

     For example, an Exporter might want to export the AS10 AS20 AS30 
     AS40 BGP AS-PATH.  In such a case, the Exporter would report a 
     basicList composed of (AS10, AS20, AS30, AS40) and the respective 
     Structured Data type semantic of "ordered". 

      
     4.5. Encoding of IPFIX Data Types 

      The following sections define the encoding of the data types 
    
abstract data types ?

  
      defined in Section 4.1. above. 
       
      When the encoding of a Structured Data Information Element has a 
      fixed length (because, for example, it contains the same number of 
      fixed-length elements, or if the permutations of elements in the 
      list always produces the same total length), the element length 
      can be encoded in the corresponding Template Record.  However, 
      when representing variable-length data, hierarchical data, and 
      repeated data with variable element counts, we RECOMMEND these are 
    
"...RECOMMEND that these..."

  
      encoded as a Variable-Length Information Element as described in 
    
_v_ariable-_l_ength

  
      Section 7 of [RFC5101], with the length carried in one or three 
      octets before the Structured Data Information Element encoding. 
       
       
     4.5.1. basicList 

      The basicList Information Element defined in Section 4.3.1.  
      represents a list of zero or more instances of an Information 
      Element and is encoded as follows: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |   Semantic    |0|          Field ID           |   Element...  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ...Length     |           BasicList Content ...               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                              ...                              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                              ...                              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                    
                Figure A: basicList Information Element Encoding  
       
       
      Semantic 
       
          The Semantic indicates the semantic of the list elements, 
    
remove "The" at the beginning of the sentence or write "The Semantic
field..."?

  
          i.e., the relationship among the different Information Element 
          values within this Structured Data. 
    
_s_tructured _d_ata

  
      
       
      Field ID 
       
          The Field ID is the Information Element identifier of the 
    
remove "The" at the beginning of the sentence or add "field"?

  
          Information Element(s) contained in the list. 
           
           
      Element Length 
       
          The Element Length indicates the length of each list element 
    
remove "The" at the beginning of the sentence or add "field"?

  
          specified by the Field ID, or contains the value 0xFFFF if the 
          length is encoded as a variable-length Information Element at 
          the start of the BasicList Content.  
           
          The Element Length field is effectively part of a header, so 
          even in the case of a zero-element list with no Enterprise 
          Number, it MUST NOT be omitted. 
    
why "with no Enterprise Number"?

I would remove the last paragraph. "header" is confusing. And you repeat
this requirement below.

  
           
           
      BasicList Content 
       
          A Collection Process decodes list elements from the BasicList 
          Content until no further data remains.  A field count is not 
          included but can be derived when the Information Element is 
          decoded. 
           
      Note that in the diagram above, the Field ID is shown with the 
    
maybe "..., Field ID...," or "..., the Field ID field ..." ?

  
      Enterprise bit (most significant bit) set to 0.  If instead the 
      Enterprise bit is set to 1, a four-byte Enterprise Number MUST be 
      encoded immediately after the Element Length as shown below.  See 
      the "Field Specifier Format" section in the IPFIX Protocol 
      [RFC5101] for additional information. 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |    Semantic   |1|         Field ID            |   Element...  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ...Length     |               Enterprise Number ...           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      ...      |              BasicList Content ...            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                              ...                              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
       
       
              Figure B: basicList Encoding with Enterprise Number 
       

      Also note that, if a basicList has zero elements, the encoded data 
      contains the Semantic, Field ID, the Element Length and the four-
      byte Enterprise Number (if present), while the BasicList Content 
      is empty. 

      If the basicList is encoded as a Variable-Length Information 
    
variable-length (also appears multiple times below)

  
      Element in less than 255 octets, it is encoded with the Length per 
    
"Length" => "Length field" (multiple times below)

  
      Section 7 of [RFC5101] as follows: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Length (< 255)|               basicList Content               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                      ... continuing as needed                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                        
        Figure C: Variable-Length basicList Information Element Encoding 
                             (Length < 255 octets) 
       
       
      If the basicList is encoded as a Variable-Length Information 
      Element in 255 or more octets, it is encoded with the Length per 
      Section 7 of [RFC5101] as follows: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      255      |      Length (0 to 65535)      |      ...      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                       basicList Content                       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

        Figure D: Variable-Length basicList Information Element Encoding 
                           (Length 0 to 65535 octets) 
         
         
     4.5.2. subTemplateList 

      The subTemplateList Information Element represents a list of zero 
      or more instances of Template data.  Because the Template Record 
    
what do you mean by "instances of Template data" ?

This would be clearer: "Data Records associated to one specific
(Options) Template"

Or do you think that the term "Data Record" should not be used here?
Yet, you also use it below in this context...

  
      referenced by a subTemplateList Information Element can itself 
      contain other subTemplateList Information Elements, and because 
      these Template Record references are part of the Information 
      Elements content in the Data Record, it is possible to represent 
      complex hierarchical data structures.  The following diagram shows 
      how a subTemplateList Information Element is encoded within a Data 
      Record: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |   Semantic    |         Template ID           |     ...       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                SubTemplateList Content    ...                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                              ...                              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
                       Figure E: subTemplateList Encoding 
       
       
      Semantic 
      
          The Semantic indicates the semantic of the list elements, i.e. 
    
remove "The" at the beginning of the sentence? Or "The Semantic field"?

  
          the relationship among the different Data Records within this 
          Structured Data. 
       
      Template ID 
       
          The Template ID is the ID of the template used to encode and 
    
This sentence is confusing because Template ID is an IPFIX term! So, it
sound like a redefinition.

Better: "The Template ID field contains the ID of the ...."

  
          decode the SubTemplateList Content. 
           
      SubTemplateList Content 
       
          The SubTemplateList Content consists of zero or more instances 
          of Data Records corresponding to the Template ID.  A 
    
"...Template ID specified in the Template ID field."  ?

Well, it's pedantic and I would not insist on this change :)

  
          Collecting Process decodes the Data Records until no further 
          data remains.  A record count is not included but can be 
          derived when the subTemplateList is decoded.  Encoding and 
          decoding are performed recursively if the specified Template 
          itself contains Structured Data Information Elements as 
          described here. 

       
      Note that, if a subTemplateList has zero elements, the encoded 
      data contains only the Semantic and the Template ID, while the 
      SubTemplateList Content is empty. 
       
      If the subTemplateList is encoded as a Variable-Length Information 
    
variable-length (same below)

  
      Element in less than 255 octets, it is encoded with the Length per 
    
Length field (same below)

  
      Section 7 of [RFC5101] as follows:  
       
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Length (< 255)|            subTemplateList Content            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                    ... continuing as needed                   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                        
         Figure F: Variable-Length subTemplateList Information Element 
                         Encoding (Length < 255 octets) 
       
       
      If the subTemplateList is encoded as a Variable-Length Information 
      Element in 255 or more octets, it is encoded with the Length per 
      Section 7 of [RFC5101] as follows: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      255      |      Length (0 to 65535)      |      ...      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |               ...  SubTemplateList Content                    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

         Figure G: Variable-Length subTemplateList Information Element 
                      Encoding (Length 0 to 65535 octets) 
      

     4.5.3. subTemplateMultiList 

      Whereas each top-level element in a subTemplateList Information 
    
what is meant by "top-level"? It means that there are levels below. Remove?

  
      Element corresponds with a single Template ID and therefore has 
    
"corresponds to"

  
      the same data type, sometimes it is useful for a list to contain 
    
Why "same data type"? Each element is a Data Record associated to the
same (Options) Template.

", sometimes it..." => "..., it is sometimes useful..."

  
      elements of more than one data type.  To support this case, each 
    
Why "data type"? You talk about Templates.

  
      top-level element in a subTemplateMultiList Information Element 
      carries a Template ID, Length and zero or more Data Records 
      corresponding to the Template ID.  The following diagram shows how 
      a subTemplateMultiList Information Element is encoded within a 
      Data Record.  Note that the subTemplateMultiList encoding is 
      consistent with Set Header specified in [RFC5101], once the 
    
"with Set Header" => "with the Set Header" ?

  
      Semantic field has been decoded. 
    
well, not only after decoding Semantic, also after encoding it :)

Better:
"Note that the encoding following the Semantic field is consistent with
the Set Header specified in [RFC5101]."

  
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |    Semantic   |         Template ID X         |Data Records...| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ... Length X  |        Data Record X.1 Content ...            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                              ...                              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      ...      |        Data Record X.2 Content ...            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                              ...                              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      ...      |        Data Record X.L Content ...            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                              ...                              |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      ...      |         Template ID Y         |Data Records...|  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ... Length Y  |        Data Record  Y.1 Content ...           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                              ...                              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      ...      |        Data Record Y.2 Content ...            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                              ...                              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      ...      |        Data Record Y.M Content ...            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                              ...                              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      ...      |         Template ID Z         |Data Records...| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ... Length Z  |        Data Record Z.1 Content ...            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                              ...                              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      ...      |        Data Record Z.2 Content ...            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                              ...                              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      ...      |        Data Record Z.N Content ...            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                              ...                              |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      ...      |    
      +-+-+-+-+-+-+-+-+   
       
                   Figure H: subTemplateMultiList Encoding 
                                        
      Semantic 
       
          The Semantic indicates the top level semantic among Template 
    
Remove "The" or "Semantic field"?

remove "top level"

"among the Data Records"?

Comment added later: Now as I have read section 5.4, I understand that
you want to restrict to the semantic among sequences of Data Records
belonging to different Templates. This does not become clear. Wouldn't
it be simpler to say that Semantic defines the semantic among all Data
Records, regardless of the Template?

  
          Records, i.e. the relationship among the series of Data 
          Records from the different Template Records within this 
    
"from" => "associated with"

  
          Structured Data. 
    
_s_tructured _d_ata

  
           
          Note: if a semantic is required to describe the relationship 
          among the different Data Records corresponding to a single 
          Template ID within the subTemplateMultiList, then an encoding 
          based on a basicList of subTemplateLists should be used. Refer 
    
I would remove "basicList" because it does not support Templates. So, it
is not a general alternative.

  
          to Section 5.6 for more information. 
           
      Template ID 
       
          Unlike the subTemplateList Information Element, each list 
          element contains a Template ID which specifies the encoding of 
    
"each element of subTemplateMultiList contains..."

  
          the following Data Records. 
           
      Data Records Length 
        
          The total length of the Data Records encoding for the Template 
          ID previously specified, including the 2 bytes for the 
          Template ID and the 2 bytes for the Data Records Length field 
          itself. 
          
      Data Record X.M  
       
          The Data Record X.M consists of the Mth Data Record of the 
          Template Record X.  A Collecting Process decodes the Data 
          Records until no further data remains, according to the Data 
          Records Length.  A record count is not included but can be 
          derived when the Element Content is decoded.  Encoding and 
          decoding are performed recursively if the specified Template 
          itself contains Structured Data Information Elements as 
          described here. 
       
      In the exceptional case of zero instances in the 
      subTemplateMultiList, no data is encoded and the Data Record 
      Length is set to zero. 
       
      If the subTemplateMultiList is encoded as a Variable-Length 
    
variable-length

  
      Information Element in less than 255 octets, it is encoded with 
      the Length per Section 7 of [RFC5101] as follows: 
    
Length field

  
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Length (< 255)|   subTemplateMultiList Information Element    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                      ... continuing as needed                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                        
      Figure I: Variable-Length subTemplateMultiList Information Element 
                        Encoding (Length < 255 octets) 
       
       
      If the subTemplateMultiList is encoded as a Variable-Length 
      Information Element in 255 or more octets, it is encoded with the 
      Length per Section 7 of [RFC5101] as follows: 
    
same comments as above

  
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      255      |      Length (0 to 65535)      |       IE      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                      ... continuing as needed                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

           Figure J: Variable-Length subTemplateMultiList Information 
                  Element Encoding (Length 0 to 65535 octets) 
       
       
     5. Structured Data Format 

       
     5.1. Length Encoding Considerations 

      The new Structured Data Information Elements represent a list that 
      potentially carries complex hierarchical and repeated data.  In 
      the normal case where the number and length of elements can vary 
      from record to record, these Information Elements are encoded as 
      variable-length Information Elements as described in Section 7 of 
      [RFC5101]. 
      
      Because of the complex and repeated nature of the data, it is 
      potentially difficult for the Exporting Process to efficiently 
      know in advance the exact encoding size. 
    
I would replace the following

  
As a result, data may be
      recursively encoded starting at a fixed offset, with the final 
      length only known and filled in afterwards. 

      Therefore, the three-byte length encoding is RECOMMENDED for 
      variable-length information elements in all Template Records 
      containing a Structured Data Information Element, even if the 
      encoded length can be less than 255 bytes, because the starting 
      offset of the data is known in advance. 
    
by:
"In this case, the Exporting Process may encode the available data and
fill in the final length afterwards.  Therefore, it may be convenient to
always use the three-byte long encoding of the Length field of the
variable-length Structured Data Information Element (even if the final
length is less than 255 bytes) to allow the data encoding to start at a
fixed offset."

  
       
      An Exporting Process MUST take care when encoding such data to not 
      exceed the maximum allowed length of an IPFIX Message, 65535 
      bytes, respecting the IPFIX specifications [RFC5101] that imposes: 
      "The IPFIX Message Header 16-bit Length field limits the length of 
      an IPFIX Message to 65535 octets, including the header".
    
I do not think that a quotation is necessary.

"When encoding such data, an Exporting Process MUST take care to not
exceed the maximum allowed IPFIX Message length of 65535 bytes which is
specified in [RFC5101]."

  
       
       
     5.2. Recursive Structured Data 

      It is possible to define recursive relationships between IPFIX 
      structured data instances, for example when representing a tree 
      structure.  The simplest case of this might be a basicList where 
      each element is itself a basicList, or a subTemplateList where one 
      of the fields of the referenced template is itself a 
      subTemplateList referencing the same Template.  When such a 
      recursive relationship exists, variable-length encoding as 
      described in Section 7 of [RFC5101] MUST be used.  Also, the 
      Exporting Process MUST take care when encoding recursively-defined 
      structured data, not to exceed the maximum allowed length of an 
      IPFIX Message (as noted in Length Encoding Considerations). 
       
       
     5.3. Structured Data Information Elements Applicability in Options 
        Template Sets 

      Structured Data Information Elements MAY be used in Options 
      Template Sets. 
       
      As an example, consider a mediation function that must aggregate 
      Data Records from multiple Observation Point types:  
       
         Router 1, (interface 1)  
         Router 2, (line card A)  
         Router 3, (line card B)  
         Router 4, (line card C, interface 2)  
       
      In order to encode the PSAMP Selection Sequence Report 
      Interpretation [RFC5476], the mediation function must express this 
      combination of Observation Points as a single new Observation 
      Point.  Recall from [RFC5476] that the PSAMP Selection Sequence 
      Report Interpretation consists of the following fields:  
       
        Scope:     selectionSequenceId  
        Non-Scope: one Information Element mapping the Observation Point  
                   selectorId (one or more)  
       
      Without structured data, there is clearly no way to express the 
      complex aggregated Observation Point as "one Information Element 
      mapping the Observation Point".  However, the desired result may 
      be easily achieved using the structured data types.  Refer to 
      Section 8.5. for an encoding example related to this case study. 
       
      Regarding the scope in the Options Template Record, the IPFIX 
      specification [RFC5101] mentions that "The IPFIX protocol doesn't 
      prevent the use of any Information Elements for scope".  
      Therefore, a Structured Data Information Element MAY be used as 
      scope in an Options Template Set.   
       
      Extending the previous example, the mediation function could 
      export a given name for this complex aggregated Observation Point:  
       
         Scope: Aggregated Observation Point (Structured Data)  
         Non-Scope: a new Information Element containing the name   
       
       
     5.4. Usage Guidelines for Equivalent Data Representations 

      Because basicList, subTemplateList, and subTemplateMultiList are 
      all lists, in several cases there is more than one way to 
      represent what is effectively the same data structure.  However, 
      in some cases, one approach has an advantage over the other e.g. 
      more compact, uses fewer resources, etc., and is therefore 
      preferred over an alternate representation. 

      A subTemplateList can represent the same simple list of single-
      value Information Elements as a basicList, if the Template 
      referenced by the subTemplateList contains only one single-valued 
      Information Element.  Although the encoding is more compact than a 
      basicList by two bytes, using a subTemplateList in this case 
      requires a new Template per Information Element.  The basicList 
      requires no additional Template and is therefore RECOMMENDED in 
      this case.  

      Although a subTemplateMultiList with one Element can represent the 
      contents of a subTemplateList, the subTemplateMultiList carries 
      two additional bytes (Element Length).  It is also potentially 
      useful to a Collecting Process to know in advance that a 
      subTemplateList directly indicates that list element types are 
      consistent.  The subTemplateList Information Element is therefore 
      RECOMMENDED in this case. 

      The Semantic in a subTemplateMultiList indicates the top level 
    
Semantic field

  
      semantic among Template Records, i.e. the relationship among the 
    
Template Records => Data Records ?

See comment above in section 4.5.3.

  
      series of Data Records from the different Template Records, within 
      this Structured Data.  If a semantic is required to describe the 
      relationship among the different Data Records corresponding to a 
      single Template ID within the subTemplateMultiList, then an 
      encoding based on a basicList of subTemplateLists should be used. 

      Note that the referenced Information Element(s) in the Structured 
      Data Information Elements can be taken from the IPFIX information 
      model [RFC5102], the PSAMP information model [RFC5477], or any of 
      the Information Elements defined in the IANA IPFIX registry [IANA-
      IPFIX]. 
    
Hm, what about enterprise-specific IEs?

  
       
       
     5.5. Padding 

      The Exporting Process MAY insert some padding octets in structured 
      data field values in a Data Record by including the 
      'paddingOctets' Information Element as described in [RFC5101] 
      Section 3.3.1.  The paddingOctets Information Element can be 
      included in a Template Record referenced by Structured Data 
      Information Element for this purpose.
    
Do we need this section? If you keep it, provide an example where
padding might be useful in the context of structured data.

  
       
                            
     5.6. Semantic  

     Semantic interpretations of received Data Records at or beyond the 
     Collecting Process remain explicitly undefined, unless that data 
     is transmitted using this extension with explicit Structured Data 
     type semantic information. 
    
Do we need this sentence? It seems to define an unnecessary restriction.
Maybe we specify further mechanisms for IPFIX semantics in another RFC
which could conflict with this sentence.

  
     The Exporter SHOULD NOT check all semantically meaningless 
     combinations before exporting the Data Record. 
    
I do not understand.
SHOULD NOT => SHOULD
or
SHOULD NOT => "does not have to"

  
     Most forms of Structured Data type semantics are possible, without 
     necessarily specifying new semantic values. 
    
Is there a proof for this statement?

Otherwise:
"More complex semantics can be expressed as a combination of the
Semantic Data Information Elements specified in this document."

  
     For example, the export of the AS10 AS20 AS30 AS40 {AS50,AS60} BGP 
     AS-PATH would be reported as a basicList of two elements, each 
     element being a basicList of BGP AS, with the top level Structured 
     Data type semantic of "ordered".  The first element would contain 
     a basicList composed of (AS10,AS20,AS30,AS40) and the respective 
     Structured Data type semantic of "ordered", while the second 
     element would contain a basicList composed of (AS50, AS60) and the 
     respective Structured Data type semantic of "exactlyOneOf".  A 
     high level Data Record diagram would be represented as:  

          (basicList, ordered,  

              (basicList, ordered, AS10,AS20,AS30,AS40),  

              (basicList, exactlyOneOf, AS50, AS60) 

          )  

     Note that the subTemplateMultiList Structured Data type semantic 
     provides the top level semantic among Template Records, i.e. the 
     relationship among the series of Data Records from the different 
     Template Records within this Structured Data, and not the 
     relationships of the different Data Records corresponding to a 
     single Template ID within the subTemplateMultiList.  If this is 
     required, semantic information needs to be exported for every 
     Template ID, in other words a basicList of subTemplateLists should 
     be used. 
    
Remove this paragraph as it is repeated from section 5.4.

  
     The following case studies show the advantage of a basicList of 
     subTemplateLists over a subTemplateMultiList. 

      Case study 1:  

     In this example, an Exporter monitoring security attacks must 
     export a list of attackers and targets.  For the sake of the 
     example, consider attackers A1 or A2 may attack targets T1 and T2. 
    
"consider" => "imagine that"

  
     The first case uses a subTemplateMultiList composed of two 
     Template Records, one representing the attacker and one 
     representing the target, each of them containing an IP address and 
     a port. 

          Attacker Template Record = (src IP address, src port) 
          Target Template Record = (dst IP address, dst port) 

     A high level Data Record diagram would be represented as:  

           (subTemplateMultiList, allOf,  

              (Attacker Template Record, A1, A2), 

              (Target Template Record, T1, T2) 

           ) 

     The Collecting Process can only conclude that all of the attackers 
     A1, A2 and the targets T1, T2 are present, without knowing the 
     relationship amongst attackers and targets. The Exporting Process 
     would have to explicitly call out the relationship amongst 
     attackers and targets and the top level semantic offered by the 
    
second "and" => "as" ?

  
     subTemplateMultiList isn't sufficient. 

     The only proper encoding for the previous semantic (i.e. attacker 
     A1 or A2 may attack target T1 and T2) uses a basicList of 
     subTemplateLists and is represented as follows:  

          Attacker Template Record = (src IP address, src port) 

          Target Template Record = (dst IP address, dst port) 

          (basicList, allof,  

                (subTemplateList, exactlyOneOf, attacker A1, A2) 

                (subTemplateList, allOf, target T1, T2) 

          )   

       

      Case study 2:  

     In this example, an Exporter monitoring security attacks must 
     export a list of attackers and targets.  For the sake of the 
     example, attackers A1 or A2 may attack targets T1, attacker A3 is 
    
"targets" => "target"

  
     attacking targets T2 and T3.  The first case uses a 
     subTemplateMultiList composed of two Template Records, one 
    
"Data Records associated to two different Templates"

  
     representing the attacker and one representing the target, each of 
     them containing an IP address and a port. 

          Attacker Template Record = (src IP address, src port) 

          Target Template Record = (dst IP address, dst port) 

     A high level Data Record diagram would be represented as:  

           (subTemplateMultiList, allOf,  

              (Attacker Template Record, A1, A2, A3), 

              (Target Template Record, T1, T2, T3) 

           ) 

     The Collecting Process can only conclude that all of the attackers 
     A1, A2, A3 and the targets T1, T2, T3 are present, without knowing 
     the relationship amongst attackers and targets. 

     The second case could use a Data Record definition composed of the 
     following: 

           (subTemplateMultiList, allOf,  

              (Attacker Template Record, A1, A2), 

              (Target Template Record, T1), 

              (Attacker Template Record, A3), 

              (Target Template Record, T2, T3) 

           ) 

     With the above representation, the Collecting Process can possibly 
     deduce that some relationship exists among (A1, A2, T1) and (A3, 
     T2, T3) but cannot understand what it is exactly.  So, there is a 
     need for the Exporting Process to explicitly define the 
     relationship between the attackers and targets and the top level 
     semantic of the subTemplateMultiList is not sufficient. 

     The only proper encoding for the previous semantic (i.e. attacker 
     A1 or A2 attack target T1, attacker A3 attacks targets T2 and T3) 
     uses a basicList of subTemplateLists and is represented as 
     follows:  

          Attacker Template Record = (src IP address, src port) 

          Target Template Record = (dst IP address, dst port) 
    
I would not repeat these Template Records here because you do not show
the Participant and Alarm Templates either.

  
          Participant P1: 

          (basicList, allOf,  

                (subTemplateList, exactlyOneOf, attacker A1, A2) 

                (subTemplateList, undefined, target T1) 

          ) 

          Participant P2: 

          (basicList, allOf,  

                (subTemplateList, undefined, attacker A3, 

                (subTemplateList, allOf, targets T2, T3) 

          ) 

     The security alert is represented as a subTemplateList of 
     participants. 

          Alert 

             (subTemplateList, allOf, Participant P1, Participant P2) 

     Note that, in the particular case of a single element in a 
     Structured Data Information Element, the semantic field is 
     actually not very useful since it specifies the relationship among 
     multiple elements.  Any choice of allOf, exactlyOneOr, or 
     OneOrMoreOf would provide the same result semantically.  
     Therefore, in case of a single element in a Structured Data 
     Information Element, the default "undefined" semantic SHOULD be 
     used. 
         
         
     6. Template Management  

      This section introduces some more specific Template Management and 
    
_m_anagement

  
      Template Withdrawal Message-related specifications compared to the 
      IPFIX protocol specification [RFC5101]. 
       
      First of all, the Template ID uniqueness is unchanged compared to 
      [RFC5101]; the uniqueness is local to the Transport Session and 
      Observation Domain that generated the Template ID.  In other 
      words, the Set ID used to export the Template Record does not 
      influence the Template ID uniqueness. 
      
      While [RFC5101] mentions that: "If an Information Element is 
      required more than once in a Template, the different occurrences 
      of this Information Element SHOULD follow the logical order of 
      their treatments by the Metering Process.", this rule MAY not be 
      followed for the Structured Data Information Elements.   
      
      As specified in [RFC5101], Templates that are not used anymore 
      SHOULD be deleted.  Before reusing a Template ID, the Template 
      MUST be deleted.  In order to delete an allocated Template, the 
      Template is withdrawn through the use of a Template Withdrawal 
      Message.  
    
You might clarify that deleting a Template implies that it may not be
used within subTemplateList and subTemplateMultiList any more.

  
      
      
     7. The Collecting Process's Side  

      This section introduces some more specific specifications to the 
      Collection Process compared to Section 9 in the IPFIX Protocol 
      [RFC5101].   
      
      As described in [RFC5101], a Collecting Process MUST note the 
      Information Element identifier of any Information Element that it 
      does not understand and MAY discard that Information Element from 
      the Flow Record.  Therefore a Collection Process that does not 
      support the extension specified in this document can ignore the 
      Structured Data Information Elements in a Data Record, or it can 
      ignore Data Records containing these new Structured Data 
      Information Elements while continuing to process other Data 
      Records. 
       
     If the Structured Data contains the "undefined" Structured Data 
     type semantic, the Collecting Process MAY attempt to draw its own 
     conclusion in terms of the semantic contained in the Data Record, 
     exactly as it would have done before the introduction of this 
     specification. 
    
Maybe remove "exactly as..." because without this specification, you
cannot nest Data Records anyway, so the CP never has the problem to
interpret nested Data Records.

  
      
     8. Structured Data Encoding Examples 

      The following examples are created solely for the purpose of 
      illustrating how the extensions proposed in this document are 
      encoded. 


     8.1. Encoding a Multicast Data Record with BasicList 

      Consider encoding a multicast Data Record containing the following 
     data: 

      --------------------------------------------------------------- 
       Ingress If | Source IP   | Destination IP  | Egress Interfaces 
      --------------------------------------------------------------- 
            9       192.0.2.201      233.252.0.1         1, 4, 8 
      --------------------------------------------------------------- 
       
      Template Record for the multicast Flows, with the Template ID 256: 

       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Set ID = 2            |      Length = 24 octets       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Template ID = 256       |       Field Count = 4         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|    ingressInterface = 10    |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|   sourceIPv4Address = 8     |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| DestinationIPv4Address = 12 |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|       basicList = XXX       |     Field Length = 0xFFFF     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
                 Figure K: Encoding basicList, Template Record 
       

      The list of outgoing interfaces is represented as a basicList with 
      semantic allOf, and the Length of the list is chosen to be encoded 
      in three bytes even though it may be less than 255 octets. 

      The Data Set is represented as follows: 

       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          Set ID = 256         |          Length = 36          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                     ingressInterface = 9                      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |               sourceIPv4Address = 192.0.2.201                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |             DestinationIPv4Address = 233.252.0.1              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      255      |        List Length = 17       | semantic=allOf| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | egressInterface FieldId = 14  |egressInterface Field Length=4 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                egressInterface value 1 = 1                    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                egressInterface value 2 = 4                    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                egressInterface value 3 = 8                    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
          
           Figure L: Encoding basicList, Data Record, Semantic allOf 
      
        In the example above, the BasicList contains fixed-length 
        elements.  To illustrate how variable-length elements would be 
        encoded, the same example is shown below with variable-length 
        interface names in the BasicList instead: 

       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          Set ID = 256         |          Length = 44          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                     ingressInterface = 9                      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |               sourceIPv4Address = 192.0.2.201                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |             DestinationIPv4Address = 233.252.0.1              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      255      |        List Length = 25       | semantic=allOf| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| InterfaceName FieldId = 82  | InterfaceName Field Len=0xFFFF| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  Length = 5   |      'F'      |      'E'      |      '0'      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     '/'       |      '0'      |  Length = 7   |      'F'      |              
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     'E'       |      '1'      |      '0'      |      '/'      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     '1'       |      '0'      |  Length = 5   |      'F'      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     'E'       |      '2'      |     '/'       |      '2'      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            
       
       Figure M: Encoding basicList, Data Record with Variable-Length 
                          Elements, Semantic allOf  
      
                                         
     8.2. Encoding a Load-balanced Data Record with a BasicList 

      Consider encoding a load-balanced Data Record containing the 
      following data: 

      --------------------------------------------------------------- 
       Ingress If | Source IP   | Destination IP  | Egress Interfaces 
      --------------------------------------------------------------- 
            9       192.0.2.201      233.252.0.1         1, 4, 8 
      --------------------------------------------------------------- 
       

      So the Data Record egressed from either interface 1, 4, or 8.  The 
      Data Set is represented as follows: 

       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          Set ID = 256         |          Length = 36          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                     ingressInterface = 9                      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |               sourceIPv4Address = 192.0.2.201                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |             DestinationIPv4Address = 233.252.0.1              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      255      |        List Length = 17       |sem=exactlyOne | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | egressInterface FieldId = 14  |egressInterface Field Length=4 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                egressInterface value 1 = 1                    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                egressInterface value 2 = 4                    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                egressInterface value 3 = 8                    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

        Figure N: Encoding basicList, Data Record, Semantic ExactlyOneOf 
                                         
                                         
     8.3. Encoding subTemplateList 

      As explained in Section 3.2. , multiple pairs of 
      (observationTimeMicroseconds, digestHashValue) must be collected 
      from two different Observation Points to passively compute the 
      one-way delay across the network.  This data can be exported with 
      an optimized Data Record that consists of the following 
      attributes:  
       
          5 tuple 
                    { observationTimeMicroseconds 1, digestHashValue 1 } 
                    { observationTimeMicroseconds 2, digestHashValue 2 } 
                    { observationTimeMicroseconds 3, digestHashValue 3 } 
                    { ...  , ... } 
      

      A subTemplateList is best suited for exporting the list of 
      (observationTimeMicroseconds, digestHashValue).  For illustration 
      purposes, the number of elements in the list is 5; in practice, it 
      could be more. 
      
      ------------------------------------------------------------------ 
      srcIP     | dstIP      | src   | dst  |proto| one-way delay 
                |            | Port  | Port |     |   metrics 
      ------------------------------------------------------------------ 
      192.0.2.1  192.0.2.105   1025     80     6    Time1, 0x0x91230613   
                                                    Time2, 0x0x91230650   
                                                    Time3, 0x0x91230725   
                                                    Time4, 0x0x91230844   
                                                    Time5, 0x0x91230978 
      ------------------------------------------------------------------ 
      
      The following Template is defined for exporting the one-way delay 
      metrics: 
      
      0                   1                   2                   3 
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |        Set ID = 2             |      Length = 16 octets       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Template ID = 257       |       Field Count = 2         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| observationTimeMicroSec=324 |       Field Length = 8        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|   digestHashValue = 326     |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
         Figure O: Encoding subTemplateList, Template for One-Way Delay 
                                    Metrics 
      
       
      The Template Record for the Optimized Data Record is as follows: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Set ID = 2            |      Length = 32 octets       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Template ID = 258       |       Field Count = 6         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|   sourceIPv4Address = 8     |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| destinationIPv4Address = 12 |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|  sourceTransportPort = 7    |       Field Length = 2        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| destinationTransportPort= 11|       Field Length = 2        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| protocolIdentifier = 4      |       Field Length = 1        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|  subTemplateList = YYY      |     Field Length = 0xFFFF     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                         
              Figure P: Encoding subTemplateList, Template Record 
      
     The list of (observationTimeMicroseconds, digestHashValue) is 
     exported as a subTemplateList with semantic allOf.  The Length of 
     the subTemplatelist is chosen to be encoded in three bytes even 
     though it may be less than 255 octets. 
      
     The Data Record is represented as follows: 
      
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Set ID = 258          |      Length = 83 octets       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                sourceIPv4Address = 192.0.2.1                  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |              destinationIPV4Address = 192.0.2.105             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | sourceTransportPort = 1025    | destinationTransportPort = 80 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Protocol = 6  |      255      | one-way metrics list len = 63 |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | semantic=allOf|       TemplateID = 257        | TimeValue1    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                 ... octets 2-5 of TimeValue1                  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          ... octets 6-8 of TimeValue1         |digestHashVal1=| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                ... 0x0x91230613               | TimeValue2    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                 ... octets 2-5 of TimeValue2                  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          ... octets 6-8 of TimeValue2         |digestHashVal2=| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                ... 0x0x91230650               | TimeValue3    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                 ... octets 2-5 of TimeValue3                  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          ... octets 6-8 of TimeValue3         |digestHashVal3=| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                ... 0x0x91230725               | TimeValue4    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                 ... octets 2-5 of TimeValue4                  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          ... octets 6-8 of TimeValue4         |digestHashVal4=| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                ... 0x0x91230844               | TimeValue5    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                 ... octets 2-5 of TimeValue5                  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          ... octets 6-8 of TimeValue5         |digestHashVal5=| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                ... 0x0x91230978               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
               
      
                   Figure Q: Encoding subTemplateList, Data Set 
           

     8.4. Encoding subTemplateMultiList  

     As explained in Section 4.4.3., a subTemplateMultiList is used to 
     export a list of mixed-type content where each top level element 
     corresponds to a different Template Record.   

     To illustrate this, consider the Data Record with the following 
     attributes: 

       
          5 tuple (Flow Keys), octetCount, packetCount 
                    attributes for classification 
                         selectorId,  
                         selectorAlgorithm 
                    attributes for sampling 
                         selectorId,  
                         selectorAlgorithm,  
                         samplingPacketInterval,  
                         samplingPacketSpace 
         
     This example demonstrates that the Selector Report Interpretation 
     [RFC5476] can be encoded with the subTemplateMultiList.  More 
     specifically, the example describes Property Match Filtering 
     Selector Report Interpretation [RFC5476] used for classification 
    
IMO, "classification" can be misunderstood.
Why do not use the word "filtering"? Or "selection"?

  
     purposes, and the Systemic Count-Based Sampling as described in 
     Section 6.5.2.1 of [RFC5476].  Some traffic will be filtered 
     according to match properties configured, some will be sampled, 
     some will be filtered and sampled, and some will not be filtered or 
     be sampled. 
      
     A subTemplateMultiList is best suited for exporting this variable 
     data.  A Template is defined for classification attributes and 
    
Again, I would say: filtering attributes.

  
     another Template is defined for sampling attributes.  A Data Record 
     can contain data corresponding to either of the Templates, both of 
     them, or neither of them.  

      
     Consider the example below where the following Data Record contains 
     both classification and sampling attributes. 

     Key attributes of the Data Record: 

      ------------------------------------------------------------------ 
      srcIP     | dstIP     | src   | dst  | proto | octetCount | packet  
                |           | Port  | Port |       |            | Count 
      ------------------------------------------------------------------ 
      192.0.2.1  192.0.2.105  1025     80      6       108000      120 
      ------------------------------------------------------------------ 
      

     Classification attributes: 

      ------------------------------------------- 
      selectorId  | selectorAlgorithm 
      ------------------------------------------- 
         100         5 (Property Match Filtering)      
      ------------------------------------------- 
      

     Sampling attributes: 

     For Systemic Count-Based Sampling as defined in Section 6.5.2.1 of 
     [RFC5476] the required algorithm-specific Information Elements are: 

           samplingPacketInterval: number of packets selected in a row 
           samplingPacketSpace:    number of packets between selections 
      
        Example of a simple 1 out-of 100 systematic count-based Selector 
        definition, where the samplingPacketInterval is 1 and the 
        samplingPacketSpace is 99. 
       
      -------------------------------------------------------------- 
      selectorId | selectorAlgorithm        | sampling | sampling 
                 |                          | Packet   | Packet 
                 |                          | Interval | Space 
      -------------------------------------------------------------- 
         15        1 (Count-Based Sampling)      1         99 
      -------------------------------------------------------------- 
      

     To represent the Data Record, the following Template Records are 
     defined: 

         Template for classification attributes: 259 
          Template for sampling attributes: 260 
          Template for Flow Record: 261 
                                         
          Flow record (261) 
              |  (sourceIPv4Address) 
              |  (destinationIPv4Address) 
              |  (sourceTransportPort) 
              |  (destinationTransportPort) 
              |  (protocolIdentifier) 
              |  (octetTotalCount) 
              |  (packetTotalCount) 
              | 
              +------ classification attributes (259) 
              |          (selectorId) 
              |          (selectorAlgorithm) 
              | 
              +------ sampling attributes (260) 
              |          (selectorId) 
              |          (selectorAlgorithm) 
              |          (samplingPacketInterval) 
              |          (samplingPacketSpace) 
                
       
      The following Template Record is defined for classification 
      attributes: 
        
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          Set ID = 2           |          Length = 16          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      Template ID = 259        |        Field Count = 2        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|    selectorId = 302         |        Field Length = 4       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| selectorAlgorithm = 304     |        Field Length = 1       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                        
            Figure R: Encoding subTemplateMultiList, Template for 
                          Classification Attributes 
       
      The Template for sampling attributes is defined as follows:  
       
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          Set ID = 2           |          Length = 24          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      Template ID = 260        |        Field Count = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|    selectorId = 302         |        Field Length = 4       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|  selectorAlgorithm = 304    |        Field Length = 1       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| samplingPacketInteval = 305 |        Field Length = 1       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| samplingPacketSpace = 306   |        Field Length = 1       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                        
        Figure S: Encoding subTemplateMultiList, Template for Sampling 
                                  Attributes 
         

        Note that while selectorId is defined as unsigned64, it is 
    
Actually, selectorId is unsigned32 (at least according to WG consensus)

  
        compressed down to 4 octet here as allowed by Reduced Size 
        Encoding in Section 6.2 of the IPFIX protocol specifications 
        [RFC5101]. 

        Note that while selectorAlgorithm is defined as unsigned16, and 
        samplingPacketInterval and samplingPacketSpace are defined as 
        unsigned32, they are compressed down to 1 octet here as allowed 
        by Reduced Size Encoding in Section 6.2 of the IPFIX protocol 
        specifications [RFC5101]. 

         
      Template for the Flow Record is defined as shown below: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          Set ID = 2           |          Length = 40          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      Template ID = 261        |        Field Count = 8        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|   sourceIPv4Address = 8     |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| destinationIPv4Address = 12 |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| sourceTransportPort = 7     |       Field Length = 2        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| destinationTransportPort=11 |       Field Length = 2        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| protocolIdentifier = 4      |       Field Length = 1        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|   octetTotalCount = 85      |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|   packetTotalCount = 86     |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| subTemplateMultiList = ZZZ  |     Field Length = 0XFFFF     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                        
      Figure T: Encoding subTemplateMultiList, Template for Flow Record 
      
       
     A subTemplateMultiList with semantic allOf is used to export the 
     classification and sampling attributes.  The Length of the 
     subTemplateMultilist is chosen to be encoded in three bytes even 
     though it may be less than 255 octets. 
      
     The Data Record is encoded as follows: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Set ID = 261            |          Length = 49          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                 sourceIPv4Address = 192.0.2.1                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |              destinationIPv4Address = 192.0.2.105             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  sourceTransportPort = 1025   | destinationTransportPort = 80 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | protocol = 6  |        octetTotalCount = 108000               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     ...       |        packetTotalCount = 120                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     ...       |      255      | Attributes List Length = 21   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |semantic=allOf |   Classif. Template ID = 259  | Classif. Attr | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ...Length = 9 |              selectorId = ...                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ...  100      |selectorAlg = 5|  Sampling Template ID = 260   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Sampling Attributes Length=11 |         selectorId = ...      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  ...         15               |selectorAlg = 1|  Interval = 1 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Space = 99    | 
      +-+-+-+-+-+-+-+-+   
       
              Figure U: Encoding subTemplateMultiList, Data Set 
      
         
     8.5. Encoding an Options Template Set using Structured Data 

      As described in Section 5.3. , consider a mediation function that 
      must aggregate Data Records from multiple different Observation 
      Points. 
       
      Say Observation Point 1 consists of one or more interfaces, 
      Observation Points 2 and 3 consist of one or more line cards, and 
      Observation Point 4 consists of one or more interfaces and one or 
      more line cards.  Without structured data, a template would have 
      to be defined for every possible combination to interpret the data 
      corresponding to each of the Observation Points.  However, with 
      structured data, a basicList can be used to encode the list of 
      interfaces and another basicList can be used to encode the list of 
      line cards.  
       
      For the sake of simplicity, each Observation Point shown below has 
      an <interface> or <linecard> or <line card and interface>.  This 
      can very well be extended to include a list of interfaces and a 
      list of linecards using basicLists as explained above. 
       
         Observation Point 1: Router 1, (interface 1)  
         Observation Point 2: Router 2, (line card A)   
         Observation Point 3: Router 3, (line card B)   
         Observation Point 4: Router 4, (line card C, interface 2)  
       
       
      The mediation function wishes to express this as a single 
      Observation Point, in order to encode the PSAMP Selection Sequence 
      Report Interpretation (SSRI).  Recall from [RFC5476] that the 
      PSAMP Selection Sequence Report Interpretation consists of the 
      following fields:  
       
        Scope:     selectionSequenceId  
        Non-Scope: one Information Element mapping the Observation Point  
                   selectorId (one or more)  
       
      For example, the Observation Point detailed above may be encoded 
      in a PSAMP Selection Sequence Report Interpretation as shown 
      below:  
       
       Selection Sequence 7 (Filter->Sampling):  
         observation point: subTemplateMultiList.  
                              Router 1, (interface 1)  
                              Router 2, (line card A)  
                              Router 3, (line card B) 
                              Router 4, (line card C, interface 2)  
         selectorId: 5 (Filter, match IPV4SourceAddress 192.0.2.1)  
         selectorId: 10 (Sampler, Random 1 out-of ten) 
       
      The following Templates are defined to represent the PSAMP SSRI: 
      Template for representing PSAMP SSRI: 262 
      Template for representing interface: 263 
      Template for representing linecard: 264 
      Template for representing linecard and interface: 265 
       
          
           PSAMP SSRI (262) 
              | (SelectionSequenceId) 
              | 
              +--- Observation Point 1 (263) 
              |      (Interface Id) 
              | 
              +--- Observation Point 2 and 3 (264) 
              |      (line card) 
              |     
              +--- Observation Point 4 (265) 
              |      (line card) 
              |      (Interface Id) 
              | 
              | (selectorId 1) 
              | (selectorId 2) 
       
                                        
                      Figure V: PSAMP SSRI to be encoded 
       
        0                   1                   2                   3  
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |          Set ID = 3           |          Length = 26          |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |        Template ID = 262      |         Field Count = 4       |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |     Scope Field Count =  1    |0|  selectionSequenceId = 301  |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |       Scope 1 Length = 4      |0| subTemplateMultiList =  ZZZ |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |     Field Length = 0xFFFF     |0|      selectorId = 302       |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |        Field Length = 4       |0|      selectorId = 302       |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |        Field Length = 4       |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                         
             Figure W: Options Template Record for PSAMP SSRI using 
                              subTemplateMultiList 
                                         
      A subTemplateMultiList with semantic allOf is used to encode the 
      list of Observation Points. 
       
        0                   1                   2                   3  
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |          Set ID = 2           |          Length = 12          |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |        Template ID = 263      |         Field Count = 1       |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |0|   ingressInterface = 10     |        Field Length = 4       | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                        
             Figure X: PSAMP SSRI, Template Record for interface 
                                        
                                        
        0                   1                   2                   3  
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |          Set ID = 2           |          Length = 12          |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |        Template ID = 264      |         Field Count = 1       |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |0|      lineCardId = 141       |        Field Length = 4       | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
        
              Figure Y: PSAMP SSRI, Template Record for linecard  
                                        
                                        
        0                   1                   2                   3  
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |          Set ID = 2           |          Length = 16          |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |        Template ID = 265      |         Field Count = 2       |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |0|      lineCardId = 141       |        Field Length = 4       | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |0|    ingressInterface = 10    |        Field Length = 4       | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       
       Figure Z: PSAMP SSRI, Template Record for linecard and interface 
                                         
                                        
      The PSAMP SSRI Data Set is represented as follows: 
                                        
        0                   1                   2                   3  
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |          Set ID = 262         |           Length = 52         |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |                    selectionSequenceId = 7                    |  
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       |      255      | Observation Point List Len=33 |semantic=allOf | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |     OP1 Template ID = 263     |        OP1 Length = 8         | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                  OP1 ingressInterface = 1                     | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |    OP2&3 Template ID = 264    |     OP2&3 Length = 12         | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                      OP2 lineCardId = A                       | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                      OP3 lineCardId = B                       | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |     OP4 Template ID = 265     |         OP4 Length = 12       | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                      OP4 lineCardId = C                       | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                   OP4 ingressInterface = 2                    | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                         selectorId = 5                        | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                         selectorId = 10                       | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      
       Figure ZA: Example of a PSAMP SSRI Data Record, Encoded using a 
                             subTemplateMultiList 
         
      Note that the Data Record above contains multiple instances of 
      Template 264 to represent Observation Point 2 (line card A) and 
      Observation Point 3 (line card B).  Instead, if a single 
      Observation Point had both line card A and line card B, a 
      basicList would be used to represent the list of line cards. 
     
      
      
     9. Relationship with the Other IFPIX Documents 

     9.1. Relationship with Reducing Redundancy  

        "Reducing Redundancy in IP Flow Information Export (IPFIX) and 
        Packet Sampling (PSAMP) Reports" [RFC5473] describes a bandwidth 
        saving method for exporting Flow or packet information using the 
        IP Flow Information eXport (IPFIX) protocol. 

        It defines the commonPropertiesID Information Element for 
        exporting Common Properties. 

      

     9.1.1. Encoding Structured Data Element using Common Properties. 

        When Structured Data Information Elements contain repeated 
        elements, these elements may be replaced with a 
        commonPropertiesID Information Element as specified in 
        [RFC5473].  The replaced elements may include the basicList, 
        subTemplateList and subTemplateMultiList Information Elements. 

        This technique might help reducing the bandwidth requirements 
        for the export.  However, a detailed analysis of the gain has 
        not been done; refer to Section 8.3 of [RFC5473] for further 
        considerations. 

         

     9.1.2. Encoding Common Properties elements With Structured Data 
        Element. 

        Structured Data Information Element MAY be used to define a list 
        of commonPropertiesID, as a replacement for the specifications 
        in [RFC5473]. 

        Indeed, the example in figures 1 and 2 of [RFC5473] can be 
        encoded with the specifications in this document.   

      
           +----------------+-------------+---------------------------+ 
           | sourceAddressA | sourcePortA |     <Flow1 information>   | 
           +----------------+-------------+---------------------------+ 
           | sourceAddressA | sourcePortA |     <Flow2 information>   | 
           +----------------+-------------+---------------------------+ 
           | sourceAddressA | sourcePortA |     <Flow3 information>   | 
           +----------------+-------------+---------------------------+ 
           | sourceAddressA | sourcePortA |     <Flow4 information>   | 
           +----------------+-------------+---------------------------+ 
           |      ...       |     ...     |            ...            | 
           +----------------+-------------+---------------------------+ 
         
          Figure ZB: Common and Specific Properties Exported Together 
                                   [RFC5473] 
                                         
           +------------------------+-----------------+-------------+ 
           | index for properties A | sourceAddressA  | sourcePortA | 
           +------------------------+-----------------+-------------+ 
           |          ...           |      ...        |     ...     | 
           +------------------------+-----------------+-------------+ 
         
         
           +------------------------+---------------------------+ 
           | index for properties A |     <Flow1 information>   | 
           +------------------------+---------------------------+ 
           | index for properties A |     <Flow2 information>   | 
           +------------------------+---------------------------+ 
           | index for properties A |     <Flow3 information>   | 
           +------------------------+---------------------------+ 
           | index for properties A |     <Flow4 information>   | 
           +------------------------+---------------------------+ 
         
         Figure ZC: Common and Specific Properties Exported Separately  
                             according to [RFC5473] 
                                         
           +----------------+-------------+---------------------------+ 
           | sourceAddressA | sourcePortA |     <Flow1 information>   | 
           +----------------+-------------+---------------------------+ 
                                          |     <Flow2 information>   | 
                                          +---------------------------+ 
                                          |     <Flow3 information>   | 
                                          +---------------------------+ 
                                          |     <Flow4 information>   | 
                                          +---------------------------+ 
                                          |            ...            | 
                                          +---------------------------+ 
         
            Figure ZD: Common and Specific Properties Exported with 
                      Structured Data Information Element 
         

        The example in figure ZC could be encoded with a basicList if 
    
Isn't it in figure ZD?

  
        the <Flow information> represents a single Information Element, 
        with a subTemplateList if the <Flow information> represents a 
        Template Record, or with a subTemplateMultiList if the <Flow 
        information> is composed of different Template Records.  

        Using Structured Data Information Elements as a replacement for 
        the techniques specified in "Reducing Redundancy in IP Flow 
        Information Export (IPFIX) and Packet Sampling (PSAMP) Reports" 
        [RFC5473] offers the advantage that a single Template Record is 
        defined.  Hence the Collectors job is simplified in terms of 
        Template management and combining Template/Options Template 
        Records.  

        However, it must be noted that using Structured Data Information 
        Elements as a replacement for the techniques specified in 
        "Reducing Redundancy in IP Flow Information Export (IPFIX) and 
        Packet Sampling (PSAMP) Reports" only applies to simplified 
        cases.  For example, the "Multiple Data Reduction" (Section 7.1 
        [RFC5473]) might be too complex to encode with Structured Data 
        Information Elements.  

      

     9.2. Relationship with Guidelines for IPFIX Testing 

        [RFC5471] presents a list of tests for implementers of IP Flow 
        Information eXport (IPFIX) compliant Exporting Processes and 
        Collecting Processes.  

        Although [RFC5471] doesn't define any structured data element 
        specific tests, the Structured Data Information Elements can be 
        used in many of the [RFC5471] tests. 

        The [RFC5471] series of test could be useful because the 
        document specifies that every Information Element type should be 
        tested.  However, not all cases from this document are tested in 
        [RFC5471]. 

        The following sections are especially noteworthy: 

          . 3.2.1.  Transmission of Template with fixed size 
             Information Elements 

               - each data type should be used in at least one test. 
                  The new data types specified in Section 4.1. should 
                  be included in this test. 

          .  3.2.2. Transmission of Template with variable length 
             Information Elements 

               - this test should be expanded to include Data Records 
                  containing variable length basicList, 
                  subTemplateList, and subTemplateMultiList Information 
                  Elements. 

          . 3.3.1. Enterprise-specific Information Elements 
               - this test should include the export of basicList, 
                  subTemplateList, and subTemplateMultiList Information 
                  Elements containing Enterprise-specific Information 
                  Elements. e.g., see the example in figure B. 

          . 3.3.3. Multiple instances of the same Information Element 
             in one Template 

               - this test should verify that multiple instances of the 
                  basicList, subTemplateList and subTemplateMultiList 
                  Information Elements are accepted. 

          . 3.5 Stress/Load tests 

               - since the structured data types defined here allow 
                  modeling of complex data structures, they may be 
                  useful for stress testing both Exporting Processes 
                  and Collecting Processes. 

                

     9.3. Relationship with Bidirectional Flow Export  

        [RFC5103] describes a method for exporting bidirectional flow 
        information, and defines the biflowDirection Information Element 
        for this purpose. 
         
        [RFC5103] Biflows may be encoded in a subTemplateList or 
        subTemplateMultiList. The basicList requires recurrence of a 
        single element, so is not suitable for Biflows. 
         
        Encoding Biflows with subTemplateList or subTemplateMultiList 
        provides a more logical division of the information in both 
        directions, although this encoding incurs a small additional 
        bandwidth penalty. 
         
        An example of Biflow encoding using Structure Data Information 
        Elements and comparison with the [RFC5103] Biflow encoding is 
        shown in Appendix B. 
         
         
     9.4. Relationship with IPFIX Mediation Function 

        The Structured Data Information Elements would be beneficial for 
        the export of aggregated Data Records in mediation function, as 
        was demonstrated with the example of the aggregated Observation 
        Point in Section 5.3.  
      

     10. IANA Considerations 

      This document specifies several new IPFIX abstract data types, a 
      new IPFIX Data Type Semantic, and several new Information 
      Elements. 
       
      These require the creation of two new IPFIX registries and 
      updating the existing IPFIX Information Element registry as 
      detailed below. 
       
       
     10.1. New Abstract Data Types 

      Section 4.1. of this document specifies several new IPFIX abstract 
      data types.  Per Section 6 of the IPFIX information model 
      [RFC5102], new abstract data types can be added to the IPFIX 
      information model.  This requires creation of a new IPFIX 
      "abstract data types" registry at 
      http://www.iana.org/assignments/ipfix.  This registry should 
      include all the abstract data types from Section 3.1 of [RFC5102].  
       
      Abstract data types to be added to the IPFIX "abstract data types" 
      registry are listed below.  
       
       
     10.1.1. basicList 

      The type "basicList" represents a list of any Information Element 
      used for single-valued data types.  
       
       
     10.1.2. subTemplateList 

      The type "subTemplateList" represents a list of a structured data 
      type, where the data type of each list element is the same and 
      corresponds with a single Template Record.  
       
       
     10.1.3. subTemplateMultiList 

      The type "subTemplateMultiList" represents a list of structured 
      data types, where the data types of the list elements can be 
      different and correspond with different template definitions. 
      

     10.2. New Data Type Semantics 

     Section 4.2. of this document specifies a new IPFIX Data Type 
     Semantic.  Per Section 3.2 of the IPFIX information model 
     [RFC5102], new data type semantics can be added to the IPFIX 
     information model.  Therefore, the IANA IPFIX 
     informationElementSemantics registry [IANA-IPFIX], which contains 
     all the data type semantics from Section 3.2 of [RFC5102], must be 
     augmented with the "list" value below. 
      
         
     10.2.1. list 

      A list is a structured data type, being composed of a sequence of 
      elements e.g. Information Element, Template Record, etc.  
       
       
     10.3. New Information Elements 

      Section 4.3. of this document specifies several new Information 
      Elements which are to be created in the IPFIX Information Element 
      registry [IANA-IPFIX].  
       
      New Information Elements to be added to the IPFIX Information 
      Element registry are listed below. 
       
      EDITOR'S NOTE: the XML specification in Appendix A must be updated 
      with the elementID values allocated below. 
      
     10.3.1. basicList  

      Name: basicList  
      Description:  
      Specifies a generic Information Element with a basicList abstract 
      data type.  For example, a list of port numbers, a list of 
      interface indexes, etc.  
      Abstract Data Type: basicList  
      Data Type Semantics: list  
      ElementId: XXX (to be specified by IANA)  
      Status: current  
      
     10.3.2. subTemplateList 

      Name: subTemplateList  
      Description:  
      Specifies a generic Information Element with a subTemplateList 
      abstract data type.  
      Abstract Data Type: subTemplateList  
      Data Type Semantics: list  
      ElementId: YYY (to be specified by IANA)  
      Status: current 
      
     10.3.3. subTemplateMultiList 

      Name: subTemplateMultiList  
      Description:  
      Specifies a generic Information Element with a 
      subTemplateMultiList abstract data type.  
      Abstract Data Type: subTemplateMultiList  
      Data Type Semantics: list  
      ElementId: ZZZ (to be specified by IANA)  
      Status: current 

     10.4. New Structured Data Semantics 

     Section 4.4. of this document specifies a series of new IPFIX 
     structured data type semantics, which is expressed as an 8-bit 
     value.  This requires the creation of a new IPFIX "structured data 
     types semantics" IPFIX subregistry [IANA-IPFIX].   
      
     Entries may be added to this subregistry subject to a Standards 
     Action [RFC5226].  Initially, this registry should include all the 
     structured data type semantics listed below.   
      
      
     10.4.1. undefined 

      A list is a structured data type, being composed of a sequence of 
      elements e.g. Information Element, Template Record, etc.  
      Value: 0xFF 
      Description: undefined 
      Reference: <this future RFC> 
       
       
     10.4.2. noneOf 

      A list is a structured data type, being composed of a sequence of 
      elements e.g. Information Element, Template Record, etc. 
      Value: 0x00 
      Description: noneOf 
      Reference: <this future RFC> 
         

     10.4.3. exactlyOneOf 

      A list is a structured data type, being composed of a sequence of 
      elements e.g. Information Element, Template Record, etc.  
      Value: 0x01 
      Description: exactlyOneOf 
      Reference: <this future RFC> 
       
       
     10.4.4. oneOrMoreOf 

      A list is a structured data type, being composed of a sequence of 
      elements e.g. Information Element, Template Record, etc.  
      Value: 0x02 
      Description: oneOrMoreOf 
      Reference: <this future RFC> 
       
     10.4.5. allOf 

      A list is a structured data type, being composed of a sequence of 
      elements e.g. Information Element, Template Record, etc.  
      Value: 0x03 
      Description: allOf 
      Reference: <this future RFC> 
      
       
     10.4.6. ordered 

      A list is a structured data type, being composed of a sequence of 
      elements e.g. Information Element, Template Record, etc.  
      Value: 0x04 
      Description: ordered 
      Reference: <this future RFC> 
      
      
     11. Security Considerations 

      The same security considerations as for the IPFIX Protocol 
      [RFC5101] apply. 
       
      
     12. References 

     12.1. Normative References 

        [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 
                Requirement Levels, BCP 14, RFC 2119, March 1997. 
      
        [RFC5101] Claise, B., Ed., "Specification of the IP Flow 
                Information Export (IPFIX) Protocol for the Exchange of 
                IP Traffic Flow Information", RFC 5101, January 2008. 
      
        [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and 
                J. Meyer, "Information Model for IP Flow Information 
                Export", RFC 5102, January 2008. 
         
        [RFC5226] T. Narten, T., Alverstrand, H. , "Guidelines for 
                Writing an IANA Considerations Section in RFCs", 
                RFC5226, May 2008. 
         
         
     12.2. Informative References 

         
        [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 
                Requirements for IP Flow Information Export, RFC 3917, 
                October 2004. 
         
        [RFC5103] Trammell, B., and E. Boschi, "Bidirectional Flow 
                Export Using IP Flow Information Export (IPFIX)", RFC 
                5103, January 2008. 
      
        [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 
                Quittek, "Architecture for IP Flow Information Export", 
                RFC 5470, March 2009. 
         
        [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines 
                for IP Flow Information Export (IPFIX) Testing", RFC 
                5471, March 2009. 
         
        [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, 
                "IP Flow Information Export (IPFIX) Applicability", RFC 
                5472, March 2009. 
         
        [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 
                Redundancy in IP Flow Information Export (IPFIX) and 
                Packet Sampling (PSAMP) Reports", RFC 5473, March 2009. 
      
        [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., 
                and F. Raspall, "Sampling and Filtering Techniques for 
                IP Packet Selection", RFC 5475, March 2009. 
      
        [RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol 
                Specifications", RFC 5476, March 2009. 
      
        [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and 
                G. Carle, "Information Model for Packet Sampling 
                Exports", RFC 5477, March 2009. 
         
        [IANA-IPFIX] http://www.iana.org/assignments/ipfix/ipfix.xhtml 
         

     13. Acknowledgement 

      The authors would like to thank Zhipu Jin, Nagaraj Varadharajan, 
      Brian Trammel, and Atsushi Kobayashi for their feedback. 
       
       
     14. Authors' Addresses 

       
      Benoit Claise 
      Cisco Systems Inc. 
      De Kleetlaan 6a b1 
      Diegem 1813 
      Belgium 
          
      Phone: +32 2 704 5622 
      EMail: bclaise@cisco.com 
       
       
      Gowri Dhandapani 
      Cisco Systems Inc. 
      13615 Dulles Technology Drive 
      Herndon, Virigina 20171 
      United States 
          
      Phone: +1 408 853 0480 
      EMail: gowri@cisco.com 
       
       
      Stan Yates 
      Cisco Systems Inc. 
      7100-8 Kit Creek Road 
      PO Box 14987 
      Research Triangle Park 
      North Carolina, 27709-4987 
      United States 
          
      Phone: +1 919 392 8044 
      EMail: syates@cisco.com 
      
      
       
      Paul Aitken 
      Cisco Systems (Scotland) Ltd. 
      96 Commercial Quay 
      Commercial Street 
      Edinburgh, EH6 6LX, United Kingdom 
          
      Phone: +44 131 561 3616 
      EMail: paitken@cisco.com 
      
            

      Appendix A.  Additions to XML Specification of IPFIX Information 
      Elements and Abstract Data Types 

      This appendix contains additions to the machine-readable 
      description of the IPFIX information model coded in XML in 
      Appendix A and Appendix B in [RFC5102].  Note that this appendix 
      is of informational nature, while the text in section 4. 
      (generated from this appendix) is normative. 
       
      The following field definitions are appended to the IPFIX 
      information model in Appendix A of [RFC5102]. 
      
         <field name="basicList" 
                 dataType="basicList" 
                 group="structured-data" 
                 dataTypeSemantics="List" 
                 elementId="XXX" applicability="all" status="current"> 
            <description> 
              <paragraph> 
                 Represents a list of zero or more instances of 
                 any single Information Element, primarily used for 
                 single-valued data types. For example, a list of port 
                 numbers, list of interface indexes, list of AS in a  
                 BGP AS-PATH, etc. 
              </paragraph> 
            </description> 
          </field> 
            
          <field name="subTemplateList" 
                 dataType="subTemplateList" 
                 group="structured-data" 
                 dataTypeSemantics="List" 
                 elementId="XXX" applicability="all" status="current"> 
            <description> 
              <paragraph> 
                 Represents a list of zero or more instances of a 
                 structured data type, where the data type of each list 
                 element is the same and corresponds with a single 
                 Template Record. For example, a structured data type 
                 composed of multiple pairs of ("MPLS label stack entry 
                 position", "MPLS label stack value"), a structured data 
                 type composed of performance metrics, a structured data 
                 type composed of multiple pairs of IP address, etc. 
              </paragraph> 
            </description> 
          </field> 
         
          <field name="subTemplateMultiList"               
                 dataType="subTemplateMultiList" 
                 group="structured-data" 
                 dataTypeSemantics="List" 
                 elementId="XXX" applicability="all" status="current"> 
            <description> 
              <paragraph> 
                Represents a list of zero or more instances of 
                structured data types, where the data type of each list 
                element can be different and corresponds with 
                different template definitions. For example, a  
                structured data type composed of multiple access-list  
                entries, where entries can be composed of different  
                criteria types. 
              </paragraph> 
            </description> 
          </field> 
       
       
      The following structured data type semantic definitions are 
      appended to the the IPFIX information model in Appendix A of 
      [RFC5102]. 
       
       
        <structuredDataTypeSemantics> 
          <structuredDataTypeSemantic name="undefined" value="255"> 
            <description> 
              <paragraph> 
                Specifies that the semantic of list elements is not 
                specified, and that, if a semantic exists, then it is up 
        to 
                the Collecting Process to draw its own conclusions.  The 
                "undefined" structured data type semantic is the default 
                Structured Data type semantic. 
              </paragraph> 
            </description> 
          </structuredDataTypeSemantic> 
         
          <structuredDataTypeSemantic name="noneOf" value="0"> 
            <description> 
              <paragraph> 
                Specifies that none of the elements are actual 
        properties 
                of the Data Record. 
              </paragraph> 
            </description> 
          </structuredDataTypeSemantic> 
         
          <structuredDataTypeSemantic name="exactlyOneOf" value="1"> 
            <description> 
              <paragraph> 
                Specifies that only a single element from the  
                Structured Data is an actual property of the Data  
                Record.  This is equivalent to a logical XOR operation. 
              </paragraph> 
            </description> 
          </structuredDataTypeSemantic> 
         
          <structuredDataTypeSemantic name="oneOrMoreOf" value="2"> 
            <description> 
              <paragraph> 
                Specifies that one or more element(s) from the list in  
                the Structured Data is/are actual propertie(s) of the  
                Data Record.  This is equivalent to a logical OR  
                operation. 
              </paragraph> 
            </description> 
          </structuredDataTypeSemantic> 
          
          <structuredDataTypeSemantic name="allOf" value="3"> 
            <description> 
              <paragraph> 
                Specifies that all of the list elements from the  
                Structured Data are actual properties of the Data  
                Record. 
              </paragraph> 
            </description> 
          </structuredDataTypeSemantic> 
          
          <structuredDataTypeSemantic name="ordered" value="4"> 
            <description> 
              <paragraph> 
                Specifies that elements from the list in the  
                Structured Data are ordered. 
              </paragraph> 
            </description> 
          </structuredDataTypeSemantic> 
        </structuredDataTypeSemantics> 
      
       
      The following schema definitions are appended to the abstract data 
      types defined in Appendix B of [RFC5102]. 
       
       
        <simpleType name="dataType"> 
          <restriction base="string"> 
            <enumeration value="basicList"> 
              <annotation> 
                <documentation> 
                  Represents a list of zero or more instances of 
                  any single Information Element, primarily used for 
                  single-valued data types. For example, a list of port 
                  numbers, list of interface indexes, list of AS in a 
                  BGP AS-PATH, etc. 
                </documentation> 
              </annotation> 
            </enumeration> 
            <enumeration value="subTemplateList"> 
              <annotation> 
                <documentation> 
                  Represents a list of zero or more instances of a 
                  structured data type, where the data type of each list 
                  element is the same and corresponds with a single 
                  Template Record. For example, a structured data type 
                  composed of multiple pairs of ("MPLS label stack entry 
                  position", "MPLS label stack value"), a structured 
                  data type composed of performance metrics, a 
                  structured data type composed of multiple pairs of IP 
                  address, etc. 
                </documentation> 
              </annotation> 
            </enumeration> 
            <enumeration value="subTemplateMultiList"> 
              <annotation> 
                <documentation> 
                  Represents a list of zero or more instances of 
                  structured data types, where the data type of each 
                  list element can be different and corresponds with 
                  different template definitions. For example, a 
                  structured data type composed of multiple  
                  access-list entries, where entries can be  
                  composed of different criteria types. 
                </documentation> 
              </annotation> 
            </enumeration> 
          </restriction> 
        </simpleType> 
         
        <simpleType name="dataTypeSemantics"> 
          <restriction base="string"> 
            <enumeration value="List"> 
              <annotation> 
                <documentation> 
                  Represents an arbitrary-length sequence of structured 
                  data elements, either composed of regular Information 
                  Elements or composed of data conforming to a Template 
                  Record.               
                </documentation> 
              </annotation> 
            </enumeration> 
          </restriction> 
        </simpleType> 
         
        <complexType name="structuredDataTypeSemantics"> 
          <sequence> 
            <element name="structuredDataTypeSemantic" 
                     minOccurs="1" maxOccurs="unbounded"> 
              <complexType> 
                <sequence> 
                  <element name="description" type="text"/> 
                </sequence> 
                <attribute name="name" type="string" use="required"/> 
                <attribute name="value" type="unsignedByte" 
      use="required"/> 
              </complexType> 
            </element> 
          </sequence> 
        </complexType> 
       
        <element name="structuredDataTypeSemantics" 
                 type="structuredDataTypeSemantics"> 
          <annotation> 
            <documentation> 
              Structured Data type semantics express the relationship 
              among multiple list elements in a Structured Data 
              Information Element. 
            </documentation> 
          </annotation> 
        </element> 
       
       
       
      Appendix B.  Example of Biflow Encoding using Structured Data 
      Information Elements 

        Referring to [RFC5103] figure 1, a Biflow consists of two parts: 
        some "key" fields such as src/dst information (IP addresses, 
        ports), followed by a set of forward/reverse pairs.  
         
        Then looking at [RFC5103] figure 7, we see that the Reverse PEN 
        is repeated many times to indicate fields which were observed in 
        the reverse direction. Clearly that repetition is wasteful.  
    
You mean that it is wasteful if such a Template is used in a Structured
Data Information Element?
Or in general? In this case, I do not think that the PEN is a problem.
The Template is exported only once.

  
         
        Looking back at [RFC5103] figure 1, it's clear that the encoding 
        can use a Template Record consisting of the Flow Keys followed 
        by a subTemplateList consisting of two elements: one for the 
        forward direction, the other for the reverse direction. 
         
        The subTemplateList uses a single Template Record to describe 
        the fields in both lists since they are a set of forward/reverse 
        pairs. 
         
  
               Uniflow                             Uniflow  
 +-------+-------+-----------------+ +-------+-------+-----------------+ 
 | src A | dst B | counters/values | | src B | dst A | counters/values | 
 +-------+-------+-----------------+ +-------+-------+-----------------+ 
     |       |            |                             |  
     V       V            V                             V  
 +-------+-------+---------------------+---------------------+  
 | src A | dst B | fwd counters/values | rev counters/values |  
 +-------+-------+---------------------+---------------------+  
          |                  |                     |  
          V                  V                     V  
     key fields         fwd element          rev element  
  
           Figure B0: Using a subTemplateList to represent a Biflow. 
    
You should show where the subTemplateList is.

  
       
      The following example shows the example from Appendix A of 
      [RFC5103] encoded using a subTemplateList: 
       

       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          Set ID = 2           |          Length = 24          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      Template ID = 266        |        Field Count = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| flowDirection            61 |       Field Length = 1        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| flowStartSeconds        150 |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| octetTotalCount          85 |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| packetTotalCount         86 |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
                   Figure B1: Template for the Biflow Fields 
       
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          Set ID = 2           |          Length = 32          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      Template ID = 267        |        Field Count = 6        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| sourceIPv4Address         8 |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| destinationIPv4Address   12 |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| sourceTransportPort       7 |       Field Length = 2        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| destinationTransportPort 11 |       Field Length = 2        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| protocolIdentifier        4 |       Field Length = 1        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|  subTemplateList = YYY      |       Field Length = 29       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
                     Figure B2: Template for the Key Fields 
       
      The Template Record includes a subTemplateList with semantic allOf 
      for encoding the BiFlow fields for the forward and reverse 
      direction.  Note that the subTemplateList is encoded using Fixed 
      Length, as shown in the above template definition. 
    
_f_ixed _l_ength, _T_emplate

  
       

      Also, note that the overall template size is 24 + 32 = 56 octets, 
      compared with 64 octets in the [RFC5103] example - so a small 
      saving is achieved. 
    
Is the Template length actually relevant? The Template is exported only
once.

  
       
       
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Set ID = 267            |          Length = 46          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                 sourceIPv4Address = 192.0.2.2                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |              destinationIPv4Address = 192.0.2.3               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  sourceTransportPort = 32770  | destinationTransportPort = 80 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | protocol = 6  |semantic=allOf |       Template ID = 266       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | dir = forward |     flowStartSeconds = 2006-02-01 17:00:00    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      ...      |           octetTotalCount = 18000             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      ...      |           packetTotalCount = 65               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      ...      | dir = reverse |   flowStartSeconds  = ...     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  ...    2006-02-01 17:00:01   |  octetTotalCount = 128000 ... | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |              ...              |   packetTotalCount = 110      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |              ...              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                         
            Figure B3: Biflow Data Set Encoded using Structured Data 
       
       
      Note that the Data Set length is 46, compared with 41 in RFC5103. 
      The five additional octets are due to the inclusion of the 8-bit 
      semantic, 16-bit Template ID and two, 8-bit direction indicators. 
       
      Clearly structured data offers an alternative way to encode 
      Biflows.  Although this may not be best suited if the number of 
      elements is small as in this example, it does offer a more robust 
      and scalable solution if multiple elements need to be encoded. 
    
I do not understand. The Data Record will always be larger than in the
RFC5103 case. So, where is a scalability advantage? And where is a
robustness advantage? In both cases, the flow information is included in
one Data Record.

  
      Appendix C.  Encoding IPS Alert using Structured Data Information 
      Elements 

      In this section, an IPS alert example is used to demonstrate how 
      complex data and multiple levels of hierarchy can be encoded using 
      Structured Data Information Elements.  Also, this example 
      demonstrates how a basicList of subTemplateLists can be used to 
      represent semantics at multiple levels in the hierarchy.  
       
      An IPS alert consists of the following mandatory attributes:  
      signatureId, protocolIdentifier and riskRating.  It can also 
      contain zero or more participants, each participant can contain 
      zero or more attackers and zero or more targets.  An attacker 
      contains the attributes sourceIPv4Address and applicationId, and 
      a target contains the attributes destinationIPv4Address and 
      applicationId. 
       
      Note that the signatureId and riskRating Information Element 
      fields are created for these examples only; the Field IDs are 
      shown as N/A.  The signatureId helps to uniquely identify the IPS 
      signature that triggered the alert.  The riskRating identifies the 
      potential risk, on a scale of 0-100 (100 being most serious), of 
      the traffic that triggered the alert. 
       
      Consider the example described in case study 2 of Section 5.6. The 
      IPS alert contains participants encoded as a subTemplateList with 
      semantic allOf.  Each participant uses a basicList of 
      subTemplateLists to represent attackers and targets.  For the sake 
      of simplicity, the alert has two participants P1 and P2.  In 
      participant P1, attacker A1 or A2 attack target T1.  In 
      participant P2, attacker A3 attacks targets T2 and T3.  
       
     Participant P1: 

          (basicList, allof,  

                (subTemplateList, exactlyOneOf, attacker A1, A2) 

                (subTemplateList, undefined, target T1) 

          ) 

     Participant P2: 

          (basicList, allOf,  

                (subTemplateList, undefined, attacker A3, 
                (subTemplateList, allOf, targets T2, T3) 

          ) 

     Alert : 

             (subTemplateList, allOf, Participant P1, Participant P2) 

       
      ------------------------------------------------------------------ 
            |        |        |             participant  
      sigId |protocol| risk   |      attacker   |      target            
            |   Id   | Rating |    IP   | appId |    IP      | appId 
      ------------------------------------------------------------------ 
      1003     17      10      192.0.2.3  103    192.0.2.103    3001 
                               192.0.2.4  104    
       
                               192.0.2.5  105    192.0.2.104    4001 
                                                 192.0.2.105    5001 
      ------------------------------------------------------------------ 
       
      Participant P1 contains: 
      Attacker A1: (IP, appID)=(192.0.2.3, 103) 
      Attacker A2: (IP, appID)=(192.0.2.4, 104) 
      Target T1: (IP, appID)= (192.0.2.103, 3001) 
       
      Participant P2 contains: 
      Attacker A3: (IP, appID) = (192.0.2.5, 105) 
      Target T2: (IP, appID)= (192.0.2.104, 4001) 
      Target T3: (IP, appID)= (192.0.2.105, 5001) 
       
       
      To represent an alert, the following Templates are defined: 
      Template for target (268) 
      Template for attacker (269) 
      Template for participant (270) 
      Template for alert (271) 
       
           alert (271) 
           |  (signatureId) 
           |  (protocolIdentifier) 
           |  (riskRating) 
           | 
           +------- participant (270) 
                    | 
                    +------- attacker (269) 
                    |           (sourceIPv4Address) 
                    |           (applicationId) 
                    | 
                    +------- target (268) 
                             |  (destinationIPv4Address) 
                             |  (applicationId) 
                              
      Note that the attackers are always composed of a single 
      applicationId, while the targets typically have multiple 
      applicationId, for the sake of simplicity this example shows only 
      one applicationId in the target. 
       
      Template Record for target, with the Template ID 268: 
       
      0                   1                   2                   3 
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |        Set ID = 2             |      Length = 16 octets       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Template ID = 268       |       Field Count = 2         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0| destinationIPv4Address = 12 |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|       applicationId = 95    |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
               Figure C0: Encoding IPS Alert, Template for Target 
      
       
      Template Record for attacker, with the Template ID 269: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Set ID = 2            |      Length = 16 octets       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Template ID = 269       |       Field Count = 2         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|    sourceIPv4Address = 8    |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|     applicationId = 95      |       Field Length = 4        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
              Figure C1: Encoding IPS Alert, Template for Attacker 
       
       
      Template Record for participant, with the Template ID 270: 
       
      
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Set ID = 2            |      Length = 12 octets       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Template ID = 270       |       Field Count = 1         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|       basicList = XXX       |     Field Length = 0xFFFF     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                        
            Figure C2: Encoding IPS Alert, Template for Participant 
       
       
      The Template Record for the participant has one basicList 
      Information Element, which is a list of subTemplateLists of 
      attackers and targets. 
          
      Template Record for IPS alert, with the Template ID 271: 
       
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Set ID = 2            |      Length = 24 octets       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Template ID = 271       |       Field Count = 4         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|    signatureId = N/A        |       Field Length = 2        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|   protocolIdentifier = 4    |       Field Length = 1        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|     riskRating = N/A        |       Field Length = 1        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |0|     subTemplateList = YYY   |     Field Length = 0xFFFF     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
             Figure C3: Encoding IPS Alert, Template for IPS Alert 
       
      The subTemplateList in the alert Template Record contains a list 
      of participants.   
       
      The Length of basicList and subTemplateList are encoded in three 
      bytes even though they may be less than 255 octets. 
       
       
      The Data Set is represented as follows: 
        
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          Set ID = 271         |         Length = 102          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      signatureId = 1003       | protocolId=17 | riskRating=10 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      255      |participant List Length  = 91  |semantic=allOf | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | participant Template ID = 270 |     255       | P1 List Len = | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      41       | semantic=allOf|    P1 List Field ID = YYY     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | P1 List Field ID Len = 0xFFFF |      255      |P1 attacker ...| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | List Len = 19 |sem=exactlyOne | P1 attacker Template ID = 269 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          P1 attacker A1 sourceIPv4Address = 192.0.2.3         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |               P1 attacker A1 applicationId = 103              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          P1 attacker A2 sourceIPv4Address = 192.0.2.4         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |               P1 attacker A2 applicationId = 104              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      255      | P1 target List Len = 11       | sem=undefined | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  P1 target Template ID = 268  | P1 target T1 destinationIPv4  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ... Address = 192.0.2.103     |P1 target T1 applicationId =...| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ...       3001                |      255      | P2 List Len = | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ...  41       | semantic=allOf|    P2 List Field ID = YYY     | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | P2 List Field ID Len = 0xFFFF |      255      |P2 attacker ...| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | List Len = 11 | sem=undefined | P2 attacker Template ID = 269 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |          P2 attacker A3 sourceIPv4Address = 192.0.2.5         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |               P2 attacker A3 applicationId = 105              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |      255      |    P2 target List Len = 19    |semantic=allOf | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  P2 target Template ID = 268  | P2 target T2 destinationIPv4  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ... Address = 192.0.2.104     |P2 target T2 applicationId =...| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ...       4001                | P2 target T3 destinationIPv4  | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ... Address = 192.0.2.105     |P2 target T3 applicationId =...| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | ...       5001                | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
                    Figure C4: Encoding IPS Alert, Data Set 
        
    
  

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

--------------040200090604060200060109-- From n.brownlee@auckland.ac.nz Thu Jul 29 01:05:09 2010 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 2B5853A6910 for ; Thu, 29 Jul 2010 01:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 hSJYWMaHGXog for ; Thu, 29 Jul 2010 01:05:06 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id B0E373A6853 for ; Thu, 29 Jul 2010 01:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1280390729; x=1311926729; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4C51363E.8060208@auckland.ac.nz>|Date:=20 Thu,=2029=20Jul=202010=2001:05:18=20-0700|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20list=20|Subject:=20T his=20afternoon's=20IPFIX=20meeting=20at=20IETF-78 |Content-Transfer-Encoding:=207bit; bh=ECwuxsN0rEoNP7hpET+5Em3FtxtElkhirj7iWM5aS18=; b=Y07hS82GMaXRU2VRbBR+5+vLtstd82jdCeq9XYvbx7vB6MqWSKeRFj7i sYuZSbBMqrGmG0+YRyTq3ABSVdMHxgf3fluuGjQUDkc2LgYP7pme2TYfQ R0bkpsqZVB51V91WkJJqwAYLxRiWH4A+7cSVViUAPpHq2xJM4QCcWXuk3 Y=; X-IronPort-AV: E=Sophos;i="4.55,279,1278244800"; d="scan'208";a="18150378" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.116.206 - Outgoing - Outgoing-SSL Received: from dhcp-74ce.meeting.ietf.org (HELO [130.129.116.206]) ([130.129.116.206]) by mx2-int.auckland.ac.nz with ESMTP; 29 Jul 2010 20:05:20 +1200 Message-ID: <4C51363E.8060208@auckland.ac.nz> Date: Thu, 29 Jul 2010 01:05:18 -0700 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] This afternoon's IPFIX meeting at IETF-78 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, 29 Jul 2010 08:05:09 -0000 Hi all: The slides for today's meeting are now on the Meeting Materials web page, i.e. at https://datatracker.ietf.org/meeting/78/materials.html We'll be looking for a scribe at the meeting, and a jabber scribe. If you can help, please email ipfix-chairs@ietf.org ! See you there, 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 muenz@net.in.tum.de Thu Jul 29 01:39:21 2010 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 F31173A69C0 for ; Thu, 29 Jul 2010 01:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.583, 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 x+lYQNPJwGas for ; Thu, 29 Jul 2010 01:39:20 -0700 (PDT) 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 DC1B93A69F9 for ; Thu, 29 Jul 2010 01:39:19 -0700 (PDT) Received: from [130.129.113.123] (dhcp-717b.meeting.ietf.org [130.129.113.123]) by mail.net.in.tum.de (Postfix) with ESMTPSA id EE635200A881; Thu, 29 Jul 2010 10:33:03 +0200 (CEST) Message-ID: <4C513CE5.5000906@net.in.tum.de> Date: Thu, 29 Jul 2010 10:33:41 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Benoit Claise References: <4C5094AC.2020803@cisco.com> In-Reply-To: <4C5094AC.2020803@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040505040306080306090305" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] WG LC for IPFIX structured data 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, 29 Jul 2010 08:39:21 -0000 This is a cryptographically signed message in MIME format. --------------ms040505040306080306090305 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Benoit, Benoit Claise wrote: > Rahul, > > Thank you very much for your review. > See my replies in line. [...] >> Comment #3 >> >> ========== >> >> Page 46 >> >> >> >> >> >> Rahul# In the same example (above), instead of 'allof" if "ordered" is >> >> used then does it imply that there is order in template 264 (line card A, >> >> line card B) even though it is just a regular template? >> > Yes. I'm confused. As far as I understand the current semantic (see my review), linecard A and B would not be ordered. The order would only concern the relationship between groups of Data Records belonging to different Templates, i.e. ingressInterface 1 <=> {linecards A and B} <=> linecard C Gerhard --------------ms040505040306080306090305 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDcyOTA4MzM0MVowIwYJKoZIhvcNAQkEMRYEFDXI 85ctWirx+vMRUDuidhXLTtuDMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQATXdT7VDvon98F8TA7ylFCE2VOtquMsC/PlZITKqUBX8cOcA2tcUNA TekgYlvl8kcggQxmR7gCkRK857VDn4JJIjdcjGCvndfLGemocxa3KQJQugr0YDmngrYcHYCF QhNLpdPak9EsQ26qFgzJpC3j+YYLvvPL92f8LdVvFEMpgBej3Gzc2X3YGa6cePPzkdfjyeET aLueO8ye3TovaRQTUhRFJBWQVbPYezKgWb0RYBgqNMTkuQla2f5pMc07JZPBO6c2JuO7dvCS Vf0c24+1l9GaupQ8xP6iy/zQqyAV6pNoPqW3Wl5hh6DJSxBFhGLFRvMM3RgkTKgZ7EEwc3pM AAAAAAAA --------------ms040505040306080306090305-- From trammell@tik.ee.ethz.ch Thu Jul 29 02:55:23 2010 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 C15E33A6840 for ; Thu, 29 Jul 2010 02:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAtDkOorlZwY for ; Thu, 29 Jul 2010 02:55:22 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 1A45C3A67EE for ; Thu, 29 Jul 2010 02:55:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D26C5D932E for ; Thu, 29 Jul 2010 11:55:44 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1UA8wrGUAhqj for ; Thu, 29 Jul 2010 11:55:44 +0200 (MEST) Received: from dhcp-62f2.meeting.ietf.org (dhcp-62f2.meeting.ietf.org [130.129.98.242]) (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 D83CFD934D for ; Thu, 29 Jul 2010 11:55:43 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Brian Trammell In-Reply-To: <4C4E996E.2000300@net.in.tum.de> Date: Thu, 29 Jul 2010 11:55:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C4E996E.2000300@net.in.tum.de> To: IETF IPFIX Working Group X-Mailer: Apple Mail (2.1081) Subject: Re: [IPFIX] Review: draft-ietf-ipfix-structured-data-02.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, 29 Jul 2010 09:55:23 -0000 Hi, all, Here are the high points of my review of structured-data -03. Apologies = for the short lead-time before today's meeting; I'll make the most = important points at the mike today. Short, short version, I think we're getting there, but the specification = still needs work. On Jul 27, 2010, at 10:31 AM, Gerhard Muenz wrote: >=20 > Dear Benoit, all, >=20 > Here is my review of draft-ietf-ipfix-structured-data-02. It mainly > consists of suggestions and comments regarding the comprehensibility = and > language. >=20 > There is one suggestion about the specification itself. I think that = it > would be easier to understand if the meaning of the semantic of > subTemplateList and subTemplateMultiList would be the same, namely = that > it specifies the semantic among the Data Records. At the moment, the > draft specifies (although not very clearly) that the semantic refers = to > goups of Data Records associated to different Templates in the case of > the subTemplateMultiList. I do not see a use-case for this. Also, no > useful example is provided. On the contrary, it is always said that = the > semantic of subTemplateMultiList is not sufficient. Agreed with Gerhard on this point, and this would be the most important = comment in my own review. Semantics, as I understand them, bind to the = set of _values_ within a list structure. The value in a = subTemplateMultiList are the records (each of which, indeed, may be = associated with a different Template). Binding semantics to templates = breaks this clean design. Section 5.6 almost seems like a paean to why = SubTemplateMultiList sucks, which if you're applying semantics at the = template level, not the record level, it seems to. I see the primary use of subTemplateMultiList as semantically identical = to subTemplateList, allowing the usage of different templates = representing semantically similar but situationally different data = (e.g., mixing v4 and v6 flows) within the same List. Here, Templates are = (as in IPFIX itself) an encoding mechanism, not a semantic one. Given this confusion, I've not reviewed the rest of the = subTemplateMultiList-relevant content. I would strongly suggest a = statement up front of the universality of semantics - applying to list = values in all cases - and a statement up front that subTemplateMultiList = is a convenience for allowing different encoding of semantically similar = information. Second comment: the document is in places somewhat = implementation-specific, but presents these implementation specific = things as essential parts of the problem. The most glaring of these is = the recommendation to use three-byte encoding for all varlen fields = (Section 5.1, Page 26). It might be useful to note that certain = lazy-evaluating exporters might do this, so that collectors won't assume = they'll never see such inefficient things FF 00 01 as a length (i.e., a = three byte encoding of "1") -- but if they're 5101-compliant, this won't = cause any problems. :) I have some other "high-level" applicability concerns - it should be = clear than IPFIX is still mostly useful in situations where _most_ = things fit into the outer template, and SDIEs are used for additional = sub-record-level structure. A guideline I'd like to see here: if you = ever export a template just containing one subTemplateList, you should = be exporting a Set instead. If you're ever exporting a template just = containing one subTemplateMultiList, what you want is a Message. IPFIX = records that are _just_ used as the root of a depth-first traversal of a = semantic tree should be exported using something like XML instead.=20 Editorial: I would suggest reworking the illustrations in section 4.5. = I'll talk about basicList here but this applies generally. Figures C and = D are not particularly useful, they just illustrate how varlen works. In = addition, by overloading the term "basicList Content", they risk being = confusing. At the same time, Figures A and B make basicList look like = alignment poison. However, the alignment-brokenness of varlen encoding = and the alignment-brokenness of semantic tagging cancel each other out. = So combining these would make things more easily understandable, and = certainly prettier: 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20= | 255 | Length (0 to 65535) | Semantic |=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20= | IE Number | Content . . .=20= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20= (While I recall commenting on this a long time ago, I rescind my = much-earlier "but isn't this technically independent from valen = encoding?" I cannot think of a realistic example where you'd do this -> = it just buys you the pain of not having structured data while forcing = you to pay for it.) Other specific points (copied from Gerhard's review) >>=20 >> 6. Template Management =20 >>=20 >> This section introduces some more specific Template Management = and=20 >=20 > _m_anagement >=20 >> Template Withdrawal Message-related specifications compared to = the=20 >> IPFIX protocol specification [RFC5101].=20 >>=20 >> First of all, the Template ID uniqueness is unchanged compared = to=20 >> [RFC5101]; the uniqueness is local to the Transport Session and=20= >> Observation Domain that generated the Template ID. In other=20 >> words, the Set ID used to export the Template Record does not=20 >> influence the Template ID uniqueness.=20 >>=20 >> While [RFC5101] mentions that: "If an Information Element is=20 >> required more than once in a Template, the different occurrences=20= >> of this Information Element SHOULD follow the logical order of=20= >> their treatments by the Metering Process.", this rule MAY not be=20= >> followed for the Structured Data Information Elements. =20 While technically 2119-correct, the English here is a little confusing. = Suggest: "...this rule MAY be ignored within Structured Data Information = Elements" This raises another point: there are now three ways to get multiple = information elements into a Template: directly (in which case = treatment-order is the only way to intepret), indirectly by a SDIE (in = which case semantics rule; question: does "undefined" basicList default = to allOf in treatment order?), directly with an SDIE (in = subTemplateList/subTemplateMultiList, a Template containing multiple IEs = directly still has those IEs interpreted as in treatment order, because = the semantics apply only to the relationship among list members, not = among IEs within list members). It would be nice to see this addressed somewhere. >> As specified in [RFC5101], Templates that are not used anymore=20= >> SHOULD be deleted. Before reusing a Template ID, the Template=20= >> MUST be deleted. In order to delete an allocated Template, the=20= >> Template is withdrawn through the use of a Template Withdrawal=20= >> Message. =20 >=20 > You might clarify that deleting a Template implies that it may not be > used within subTemplateList and subTemplateMultiList any more. +1 More to follow on the list, I'm sure; just wanted to make sure I got = these points out before today's meeting. Regards, Brian From rahulp@cisco.com Thu Jul 29 07:16:48 2010 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 54C4F28C113 for ; Thu, 29 Jul 2010 07:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.133 X-Spam-Level: X-Spam-Status: No, score=-10.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TfqBqBvNK+Cv for ; Thu, 29 Jul 2010 07:16:23 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5986B28C139 for ; Thu, 29 Jul 2010 07:16:19 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtwFAHcqUUytJV2a/2dsb2JhbACBRJ5EcaU7mwOFOASEE4ckDAE X-IronPort-AV: E=Sophos;i="4.55,280,1278288000"; d="scan'208,217";a="140832879" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 29 Jul 2010 14:16:42 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o6TEGgtW026474 for ; Thu, 29 Jul 2010 14:16:42 GMT Received: from xmb-rcd-213.cisco.com ([72.163.62.220]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Jul 2010 09:16:42 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2F28.AAAA3AA1" Date: Thu, 29 Jul 2010 09:16:40 -0500 Message-ID: In-Reply-To: <4C5094AC.2020803@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG LC for IPFIX structured data Thread-Index: AcsulHxriQnkw5Z7Qc6l9MvWWGCBYAAkI5rA References: <4C5094AC.2020803@cisco.com> From: "Rahul Patel (rahulp)" To: "Benoit Claise (bclaise)" X-OriginalArrivalTime: 29 Jul 2010 14:16:42.0153 (UTC) FILETIME=[AAD5D990:01CB2F28] Cc: ipfix@ietf.org Subject: Re: [IPFIX] WG LC for IPFIX structured data 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, 29 Jul 2010 14:16:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2F28.AAAA3AA1 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Benoit, =20 Comment inline ..[RP] =20 From: Benoit Claise (bclaise)=20 Sent: Wednesday, July 28, 2010 4:36 PM To: Rahul Patel (rahulp) Cc: ipfix@ietf.org Subject: Re: WG LC for IPFIX structured data =20 Rahul, Thank you very much for your review. See my replies in line. Resending it. =20 -Rahul =20 From: Rahul Patel (rahulp)=20 Sent: Monday, July 19, 2010 11:49 AM To: 'ipfix@ietf.org' Subject: WG LC for IPFIX structured data =20 Few comments on Rev2 =20 comment #1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Page 45-46: " Selection Sequence 7 (Filter->Sampling): =20 observation point: subTemplateMultiList. =20 Router 1, (interface 1) =20 Router 2, (line card A) =20 Router 3, (line card B)=20 Router 4, (line card C, interface 2) =20 selectorId: 5 (Filter, match IPV4SourceAddress 192.0.2.1) =20 selectorId: 10 (Sampler, Random 1 out-of ten)=20 =20 The following Templates are defined to represent the PSAMP SSRI:=20 Template for representing PSAMP SSRI: 262=20 Template for representing interface: 263=20 " =20 Rahul# Wouldn't it be better to include RouterID in addition to=20 Interface and/or linecard in the example. Without router id interface has no meaning unless interfaces are unique across routers which is=20 unlikely. OLD: =20 PSAMP SSRI (262) | (SelectionSequenceId) | +--- Observation Point 1 (263) | (Interface Id) | +--- Observation Point 2 and 3 (264) | (line card) | +--- Observation Point 4 (265) | (line card) | (Interface Id) | | (selectorId 1) | (selectorId 2) NEW: =20 PSAMP SSRI (262) | (SelectionSequenceId) | +--- Observation Point 1 (263) | (exporterIPv4Address) | (Interface Id) | +--- Observation Point 2 and 3 (264) | (exporterIPv4Address) | (line card) | +--- Observation Point 4 (265) | (exporterIPv4Address) | (line card) | (Interface Id) | | (selectorId 1) | (selectorId 2) This would good enough? =20 [RP] This is fine. Or you want the full example, with (subTemplateMultiList, exactlyOneOf, exporterIPv4Address, exporterIPv6Address)? This would be: PSAMP SSRI (262) | (SelectionSequenceId) | +--- Exporter IPv4 address (262) | (exporterIPv4Address) | +--- Exporter IPv6 address (263) | (exporterIPv6Address) | +--- Observation Point 1 (264) | (Interface Id) | +--- Observation Point 2 and 3 (265) | (line card) | +--- Observation Point 4 (266) | (line card) | (Interface Id) | | (selectorId 1) | (selectorId 2) =20 =20 comment #2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Page 46 " Note that the Data Record above contains multiple instances of=20 Template 264 to represent Observation Point 2 (line card A) and=20 Observation Point 3 (line card B). Instead, if a single=20 Observation Point had both line card A and line card B, a=20 basicList would be used to represent the list of line cards.=20 " =20 Rahul# There is an implicit assumption that each record belongs to a different router.=20 You're right, the example shows so. That is why you would have to use basicList if line card A and line card B were to be on OB Point 2. Right. Alternatively, the proposals above would solve this by repeating the exporterIPv4Address=20 =20 =20 Comment #3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Page 46 =20 =20 Rahul# In the same example (above), instead of 'allof" if "ordered" is used then does it imply that there is order in template 264 (line card A, line card B) even though it is just a regular template? Yes. =20 Comment #4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Page 16 " Another example is a router that monitors some specific BGP AS- PATHs and reports if a Flow belongs to any of them. If the router=20 wants to export that a Flow does not belong to any of the=20 monitored BGP AS-PATHs, the router reports a Data Record with a=20 basicList composed of (BGP AS-PATH 1, BGP AS-PATH 2, BGP AS-PATH=20 3) and the respective Structured Data type semantic of "noneOf". " =20 Rahul# If there are many flows which are exported with "noneOf" then that would not be efficient because each flow is carring path1, path2 and path3. Can you do following? How? =20 List of flows that didn't match monitored AS paths -> AS_PATH { path1, path2, path3} -> Flows - Flow1 - Flow2 - Flow3 - Flow4 How would you express this semantically? (allOf, Flows) allOf (noOff, BGP AS) (allOf, Flows) none (allOf, BGP AS) >From there, we could map it with a basicList of subTemplateMultiList. [RP]=20 (basicList, allOf, =20 =20 (subTemplateList, noneOff, AS1, AS2, AS3) =20 (subTemplateList, allOf, Flow1, Flow2, Flow3, Flow4) =20 =20 -Rahul =20 Regards, Benoit. =20 -Rahul =20 ------_=_NextPart_001_01CB2F28.AAAA3AA1 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi = Benoit,

 

Comment inline = ..[RP]

 

From: Benoit Claise (bclaise)
Sent: Wednesday, July 28, 2010 = 4:36 PM
To: Rahul Patel (rahulp)
Cc: = ipfix@ietf.org
Subject: Re: WG LC for IPFIX structured = data

 

Rahul,

Thank you very much for your = review.
See my replies in line.

Resending = it.

 

-Rahul

 

From:= = Rahul Patel (rahulp)
Sent: Monday, July 19, 2010 11:49 = AM
To: 'ipfix@ietf.org'
Subject: WG = LC for IPFIX structured data

 

Few comments on = Rev2

 

comment = #1:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Page 45-46:

"       Selection Sequence 7 = (Filter->Sampling): 

         observation = point: subTemplateMultiList. 

           &= nbsp;           &n= bsp;      Router 1, (interface 1)  =

           &= nbsp;           &n= bsp;      Router 2, (line card A)  =

           &= nbsp;           &n= bsp;      Router 3, (line card B) =

           &= nbsp;           &n= bsp;      Router 4, (line card C, = interface 2) 

         selectorId: = 5 (Filter, match IPV4SourceAddress 192.0.2.1)  =

         selectorId: = 10 (Sampler, Random 1 out-of ten)

       

      The following Templates are = defined to represent the PSAMP SSRI:

      Template for representing = PSAMP SSRI: 262

      Template for representing = interface: 263

"

 

Rahul# Wouldn't it be better to = include RouterID in addition to

Interface = and/or linecard in the example. Without router id = interface

has no meaning unless interfaces are = unique across routers which is

unlikely.


OLD:

 =

        &nb=
sp;  PSAMP SSRI =
(262)
       &nbs=
p;      | =
(SelectionSequenceId)
     =
         =
|
        &n=
bsp;     +--- Observation Point 1 =
(263)
       &nbs=
p;      |      =
(Interface =
Id)
        =
      =
|
        &n=
bsp;     +--- Observation Point 2 and 3 =
(264)
       &nbs=
p;      |      (line =
card)
       &nbs=
p;      =
|
        &n=
bsp;     +--- Observation Point 4 =
(265)
       &nbs=
p;      |      (line =
card)
       &nbs=
p;      |      =
(Interface =
Id)
        =
      =
|
        &n=
bsp;     | (selectorId =
1)
        &=
nbsp;     | (selectorId 2)


NEW:

 =

        &nb=
sp;  PSAMP SSRI =
(262)
       &nbs=
p;      | =
(SelectionSequenceId)
     =
         =
|
        &n=
bsp;     +--- Observation Point 1 =
(263)
       &nbs=
p;      |    =
  (exporterIPv4Address)
   =
           =
|      (Interface =
Id)
        =
      =
|
        &n=
bsp;     +--- Observation Point 2 and 3 =
(264)
       &nbs=
p;      |      =
(exporterIPv4Address)
     =
         =
|      (line =
card)
       &nbs=
p;      =
|
        &n=
bsp;     +--- Observation Point 4 =
(265)
       &nbs=
p;      |      =
(exporterIPv4Address)
     =
         =
|      (line =
card)
       &nbs=
p;      |      =
(Interface =
Id)
        =
      =
|
        &n=
bsp;     | (selectorId =
1)
        &=
nbsp;     | (selectorId 2)


This would good enough?

 

[RP] This is = fine.


Or = you want the full example,  with (subTemplateMultiList, = exactlyOneOf, exporterIPv4Address, exporterIPv6Address)?
This would = be:

       &=
nbsp;   PSAMP SSRI =
(262)
       &nbs=
p;      | =
(SelectionSequenceId)
     =
         =
|
        &n=
bsp;     +--- Exporter IPv4 address =
(262)
       &nbs=
p;      |      =
(exporterIPv4Address)
     =
         =
|
        &n=
bsp;     +--- Exporter IPv6 address =
(263)
       &nbs=
p;      |      =
(exporterIPv6Address)
     =
         =
|
        &n=
bsp;     +--- Observation Point 1 =
(264)
       &nbs=
p;      |      =
(Interface =
Id)
        =
      =
|
        &n=
bsp;     +--- Observation Point 2 and 3 =
(265)
       &nbs=
p;      |      (line =
card)
       &nbs=
p;      =
|
        &n=
bsp;     +--- Observation Point 4 =
(266)
       &nbs=
p;      |      (line =
card)
       &nbs=
p;      |      =
(Interface =
Id)
        =
      =
|
        &n=
bsp;     | (selectorId =
1)
         =
     | (selectorId 2)




 

 

comment #2

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Page 46

"      Note that the Data Record = above contains multiple instances of

      Template 264 to represent = Observation Point 2 (line card A) and

      Observation Point 3 (line card = B).  Instead, if a single

      Observation Point had both = line card A and line card B, a

      basicList would be used to = represent the list of line cards.

"

 

Rahul# There = is an implicit assumption that each record belongs to = a

different router. =

You're = right, the example shows so.

That is why you would have to use = basicList if line

card A and line card B were to be on = OB Point 2.

Right.
Alternatively, the proposals above would solve = this by repeating the exporterIPv4Address

 

 

Comment #3

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Page = 46

 

 

Rahul# In the same example (above), = instead of 'allof" if "ordered" = is

used then does it imply that there = is order in template 264 (line card A,

line card B) = even though it is just a regular template?

Yes.

 

Comment = #4

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Page = 16

“     = Another example is a router that monitors some specific BGP = AS-

     PATHs and = reports if a Flow belongs to any of them.  If the router =

     wants = to export that a Flow does not belong to any of the =

     monitored BGP AS-PATHs, the router = reports a Data Record with a

     basicList composed of (BGP AS-PATH = 1, BGP AS-PATH 2, BGP AS-PATH

     3) and the respective Structured = Data type semantic of "noneOf".

“

 

Rahul# If = there are many flows which are exported with “noneOf” then = that

would not be efficient because each = flow is carring path1, path2 and path3.

Can you do = following? How?

 

List of = flows that didn’t

match monitored AS paths -> = AS_PATH { path1, path2, path3}

           &= nbsp;            = -> Flows

           &= nbsp;           &n= bsp;       - Flow1

           &= nbsp;           &n= bsp;       - Flow2

           &= nbsp;           &n= bsp;       - Flow3

           &= nbsp;           &n= bsp;       - = Flow4

How = would you express this semantically?
    (allOf, = Flows) allOf (noOff, BGP AS)
    (allOf, Flows) none = (allOf, BGP AS)
From there, we could map it with a basicList of = subTemplateMultiList.

[RP] =

(basicList, allOf, 

 

        &n= bsp;       (subTemplateList, noneOff, AS1, = AS2, AS3)

 

        &n= bsp;       (subTemplateList, allOf, Flow1, = Flow2, Flow3, Flow4)

 

 

-Rahul

 


Regards, Benoit.

 

-Rahul

 

------_=_NextPart_001_01CB2F28.AAAA3AA1--