From muenz@net.in.tum.de Tue Aug 3 05:10:15 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BE223A681D for ; Tue, 3 Aug 2010 05:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.382 X-Spam-Level: X-Spam-Status: No, score=-1.382 tagged_above=-999 required=5 tests=[AWL=0.867, 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 Zwb3JceHF4f2 for ; Tue, 3 Aug 2010 05:10:09 -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 B11E63A67D1 for ; Tue, 3 Aug 2010 05:10:06 -0700 (PDT) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 37A1C208C31A for ; Tue, 3 Aug 2010 14:10:34 +0200 (CEST) Message-ID: <4C580765.5060100@net.in.tum.de> Date: Tue, 03 Aug 2010 14:11:17 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: NETMOD Working Group Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000401070202010207000204" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 12:10:15 -0000 This is a cryptographically signed message in MIME format. --------------ms000401070202010207000204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all, In the IPFIX WG, we will have a second WGLC for draft-ietf-ipfix-configuration-model-07. It would be nice if some YANG experts could have a look at the document, too. The YANG module was validated with pyang and seems to be correct. Nevertheless, you might have further comments. We also tried to make the document compliant with the YANG guidelines. If you think that something is missing or should be changed, please let me know. Thanks a lot for you help, Gerhard -------- Original Message -------- Subject: [IPFIX] I-D Action:draft-ietf-ipfix-configuration-model-07.txt Date: Tue, 3 Aug 2010 04:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: ipfix@ietf.org 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-07.txt Pages : 123 Date : 2010-08-03 This document specifies a data model for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX and PSAMP compliant Monitoring Devices using the NETCONF protocol [RFC4741]. The data model is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG [I-D.ietf-netmod-yang]. The configuration data is encoded in Extensible Markup Language (XML). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-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. --------------ms000401070202010207000204 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgwMzEyMTExN1owIwYJKoZIhvcNAQkEMRYEFHZS b3UADTGQDicCfe7YIsRljOpOMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQBt7hFqqG8K/UwwAH4i125UWq3wW8X1obLJDuIQ607nJIeap4XaGWt5 6heIUILijM6UfZHQ1IsWgGPlrCIo7UFo/H3UnyIhISROfo8/ePW2wRnny1rOg4Qu8UNv2+X3 U2i9gdQpALZEEhwxeooOhPVYH2dUKDvdqI5oMGWmCvMdmhpxjG4wkhu3nGSPNIeyehUVUM5D uPjcM4xzqkO223rN2E+A08HS27LjSCfrCClAmWJtKAIerZBOVr9rJxF4Ifsy5T4UmmbmK1A8 Qt4h+wChaFLzND3k5ln3PiYgr4mvlGkC8lWIz3+foA+kBsESvnGhTRKK2RgmFFyCiz4zKfl9 AAAAAAAA --------------ms000401070202010207000204-- From ietf@andybierman.com Wed Aug 4 22:39:51 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3E953A6A9D for ; Wed, 4 Aug 2010 22:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.812 X-Spam-Level: X-Spam-Status: No, score=-1.812 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 wCETAtZJ072A for ; Wed, 4 Aug 2010 22:39:49 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 542C83A6A94 for ; Wed, 4 Aug 2010 22:39:49 -0700 (PDT) Received: (qmail 37869 invoked from network); 5 Aug 2010 05:40:14 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 04 Aug 2010 22:40:14 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: jm3iclwVM1lk7DGr88XdeQpzfsUk0dd4dX50vj0Ryni5vzS FRsIFmnP_vm4DJ9_f_IvMq3Ifg7LYjuMN29YmFr8vzci9EMZkD87puPozg_J nbdmttmJ3ZI0xX6nah9S.aIXG3ktmKtNAsk_5cW5V95kYiD_onhm3FZ0RnbO H.eOUtGYE5RHooiV0FH1rgwRFV84fPdiEV_SZ9tMorpR03tsEQKQlOANOyIU fe_ETWSL2DWeZl.oqt3LYoOqKUiyGWwMV9yKwSRW6HDt4CoDdlTpIESF89Q2 pzOu0iaHGLc9ZBHKgKEOJ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C5A4EBD.9050205@andybierman.com> Date: Wed, 04 Aug 2010 22:40:13 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Gerhard Muenz References: <4C580765.5060100@net.in.tum.de> In-Reply-To: <4C580765.5060100@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 05:39:52 -0000 On 08/03/2010 05:11 AM, Gerhard Muenz wrote: > > Dear all, > > In the IPFIX WG, we will have a second WGLC for > draft-ietf-ipfix-configuration-model-07. > > It would be nice if some YANG experts could have a look at the document, > too. > > The YANG module was validated with pyang and seems to be correct. > Nevertheless, you might have further comments. > > We also tried to make the document compliant with the YANG guidelines. > If you think that something is missing or should be changed, please let > me know. > I have one concern already, which is the usage of ifIndex or ifName for identifying an interface. This is problematic. Eventually there will be an interfaces module in YANG, even if it is just scaffolding so we know where all the vendor per-interface config belongs. Is there an assumption that the NETCONF server co-exists with an SNMP agent? It looks that way. IMO, the NETCONF/SNMP interactions are critically important to interoperability. It should be designed, not ad-hoc. I don't want to hold up ipfix-psamp.yang, but I don't want to let it constrain the eventual interfaces.yang solution either. (So a future Iipfix-psamp.yang revision may wish to support the YANG interfaces table, which will probably not be indexed by either ifInex or ifName.) > Thanks a lot for you help, > Gerhard > Andy > > -------- Original Message -------- > Subject: [IPFIX] I-D Action:draft-ietf-ipfix-configuration-model-07.txt > Date: Tue, 3 Aug 2010 04:45:02 -0700 (PDT) > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > CC: ipfix@ietf.org > > 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-07.txt > Pages : 123 > Date : 2010-08-03 > > This document specifies a data model for configuring and monitoring > Selection Processes, Caches, Exporting Processes, and Collecting > Processes of IPFIX and PSAMP compliant Monitoring Devices using the > NETCONF protocol [RFC4741]. The data model is defined using UML > (Unified Modeling Language) class diagrams and formally specified > using YANG [I-D.ietf-netmod-yang]. The configuration data is encoded > in Extensible Markup Language (XML). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-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. > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From muenz@net.in.tum.de Thu Aug 5 00:26:13 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7D2A3A69E8 for ; Thu, 5 Aug 2010 00:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_20=-0.74, 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 Vm-BP+TE98nE for ; Thu, 5 Aug 2010 00:26:12 -0700 (PDT) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) by core3.amsl.com (Postfix) with ESMTP id B04843A6884 for ; Thu, 5 Aug 2010 00:26:12 -0700 (PDT) Received: from [131.159.20.249] (vpn-3.net.in.tum.de [131.159.20.249]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 4D289210B74E; Thu, 5 Aug 2010 09:26:39 +0200 (CEST) Message-ID: <4C5A67D7.4040408@net.in.tum.de> Date: Thu, 05 Aug 2010 09:27:19 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andy Bierman References: <4C580765.5060100@net.in.tum.de> <4C5A4EBD.9050205@andybierman.com> In-Reply-To: <4C5A4EBD.9050205@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: NETMOD Working Group Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 07:26:13 -0000 Hi Andy, Thank you for your answer. I did not pay attention to this point. Andy Bierman wrote: > On 08/03/2010 05:11 AM, Gerhard Muenz wrote: >> Dear all, >> >> In the IPFIX WG, we will have a second WGLC for >> draft-ietf-ipfix-configuration-model-07. >> >> It would be nice if some YANG experts could have a look at the document, >> too. >> >> The YANG module was validated with pyang and seems to be correct. >> Nevertheless, you might have further comments. >> >> We also tried to make the document compliant with the YANG guidelines. >> If you think that something is missing or should be changed, please let >> me know. >> > > > I have one concern already, which is the usage of > ifIndex or ifName for identifying an interface. This is problematic. > Eventually there will be an interfaces module in YANG, even if it is > just scaffolding so we know where all the vendor per-interface config belongs. > > Is there an assumption that the NETCONF server co-exists with an SNMP agent? For commercial routers, this will very probably be the case. However, the configuration model should not depend on an SNMP agent implementing the IF-MIB module. You are right that this is unclear at the moment. > It looks that way. IMO, the NETCONF/SNMP interactions are critically important > to interoperability. It should be designed, not ad-hoc. I don't want to hold up > ipfix-psamp.yang, but I don't want to let it constrain the eventual interfaces.yang > solution either. Can you propose an intermediate solution? At the moment, we allow ifIndex or ifName for identifying an interface. These are fine for devices which do have an SNMP agent. Shall we add a third neutral option for devices without SNMP? > (So a future Iipfix-psamp.yang revision may wish to support the YANG interfaces table, > which will probably not be indexed by either ifInex or ifName.) Sure. So, we should take care that the model can easily be extended by a new option to identify an interface. As far as I understand, we can use the augment statement to add another leaf to choice OPLocation. Gerhard > > >> Thanks a lot for you help, >> Gerhard >> > > Andy > From j.schoenwaelder@jacobs-university.de Thu Aug 5 00:48:20 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1793A6A01 for ; Thu, 5 Aug 2010 00:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.619 X-Spam-Level: X-Spam-Status: No, score=-101.619 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpH6quyKi19c for ; Thu, 5 Aug 2010 00:48:19 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1CA9B3A6922 for ; Thu, 5 Aug 2010 00:48:19 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F26A6C0004; Thu, 5 Aug 2010 09:48:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zLTpeiiBnqus; Thu, 5 Aug 2010 09:48:47 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B09AC0015; Thu, 5 Aug 2010 09:48:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 97C161414040; Thu, 5 Aug 2010 09:48:40 +0200 (CEST) Date: Thu, 5 Aug 2010 09:48:40 +0200 From: Juergen Schoenwaelder To: Gerhard Muenz Message-ID: <20100805074840.GB89539@elstar.local> Mail-Followup-To: Gerhard Muenz , Andy Bierman , NETMOD Working Group References: <4C580765.5060100@net.in.tum.de> <4C5A4EBD.9050205@andybierman.com> <4C5A67D7.4040408@net.in.tum.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C5A67D7.4040408@net.in.tum.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 07:48:20 -0000 On Thu, Aug 05, 2010 at 09:27:19AM +0200, Gerhard Muenz wrote: > Thank you for your answer. I did not pay attention to this point. I did share Andy's concerns when I skimmed the document but then I thought it is also unfair to raise a flag because there is nothing better in place and so far we have not even a WG chartered to produce something more appropriate. > > It looks that way. IMO, the NETCONF/SNMP interactions are > > critically important to interoperability. It should be designed, > > not ad-hoc. I don't want to hold up ipfix-psamp.yang, but I don't > > want to let it constrain the eventual interfaces.yang solution > > either. > > Can you propose an intermediate solution? > > At the moment, we allow ifIndex or ifName for identifying an interface. > These are fine for devices which do have an SNMP agent. > Shall we add a third neutral option for devices without SNMP? Supporting several different ways to identify an interface is not a good long term solution overall. Perhaps the best we can do is to accept the fact that there is nothing better yet but to be prepared that a future revision might change this part of the data model. > > (So a future Iipfix-psamp.yang revision may wish to support the YANG interfaces table, > > which will probably not be indexed by either ifInex or ifName.) > > Sure. So, we should take care that the model can easily be extended by a > new option to identify an interface. As far as I understand, we can use > the augment statement to add another leaf to choice OPLocation. I would rather see this "fixed" in place once the document is up for revision. BTW, is there already implementation with this config model? I am not following IPFIX in all detail so I am not sure how mature things are (implementation experience always helps to understand details better). All that said and reading the DESCRIPTION of ifName again, I consider it very likely that semantically ifName _values_ are going to be used to refer to interfaces in YANG. How this is done (e.g. by direct reference to the IF-MIB or via a separate YANG typedef that is semantically equivalent) I do not know (although I do have an opinion ;-). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Thu Aug 5 01:23:22 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299163A6A69 for ; Thu, 5 Aug 2010 01:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] 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 wbOIviIIm3or for ; Thu, 5 Aug 2010 01:23:21 -0700 (PDT) Received: from smtp109.sbc.mail.gq1.yahoo.com (smtp109.sbc.mail.gq1.yahoo.com [67.195.14.39]) by core3.amsl.com (Postfix) with SMTP id 4AF2E3A69EA for ; Thu, 5 Aug 2010 01:23:21 -0700 (PDT) Received: (qmail 46817 invoked from network); 5 Aug 2010 08:23:49 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp109.sbc.mail.gq1.yahoo.com with SMTP; 05 Aug 2010 01:23:48 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: Z6GqaI8VM1kfMKeUeulotXREESoOfyqf9.ndfIP9rnTSnNl RPUzQPvuCehHhB6L1MU7O3XEGmCHqQh1tyazmoWu_YKg1Y2f9EQbREywynXh GOCdQkQU.evFufMTmqIWhCF2G.EHTogzX4fOMMX0sZS.fML097u0AG.LYUPG mS7mgNedEVu_BtjK9YOYS3UwAnFSPenBj9QEom5J_U7H9B7Zq5A6Uav_8eWw ymBoHXmKEokRtrZQDL7iTS4kK6hZT X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C5A7514.9070700@andybierman.com> Date: Thu, 05 Aug 2010 01:23:48 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Gerhard Muenz References: <4C580765.5060100@net.in.tum.de> <4C5A4EBD.9050205@andybierman.com> <4C5A67D7.4040408@net.in.tum.de> In-Reply-To: <4C5A67D7.4040408@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 08:23:22 -0000 On 08/05/2010 12:27 AM, Gerhard Muenz wrote: > > Hi Andy, > > Thank you for your answer. I did not pay attention to this point. > > Andy Bierman wrote: >> On 08/03/2010 05:11 AM, Gerhard Muenz wrote: >>> Dear all, >>> >>> In the IPFIX WG, we will have a second WGLC for >>> draft-ietf-ipfix-configuration-model-07. >>> >>> It would be nice if some YANG experts could have a look at the document, >>> too. >>> >>> The YANG module was validated with pyang and seems to be correct. >>> Nevertheless, you might have further comments. >>> >>> We also tried to make the document compliant with the YANG guidelines. >>> If you think that something is missing or should be changed, please let >>> me know. >>> >> >> >> I have one concern already, which is the usage of >> ifIndex or ifName for identifying an interface. This is problematic. >> Eventually there will be an interfaces module in YANG, even if it is >> just scaffolding so we know where all the vendor per-interface config belongs. >> >> Is there an assumption that the NETCONF server co-exists with an SNMP agent? > > For commercial routers, this will very probably be the case. > However, the configuration model should not depend on an SNMP agent > implementing the IF-MIB module. You are right that this is unclear at > the moment. > >> It looks that way. IMO, the NETCONF/SNMP interactions are critically important >> to interoperability. It should be designed, not ad-hoc. I don't want to hold up >> ipfix-psamp.yang, but I don't want to let it constrain the eventual interfaces.yang >> solution either. > > Can you propose an intermediate solution? > not yet. I prefer a solution that actually attempts to provide machine readable structure to the if-name, and make if-index go away. Martin started on a solution (e.g., if-name is a string and some YANG extension-stmt defines the embedded structure). I think that has the most promise. > At the moment, we allow ifIndex or ifName for identifying an interface. > These are fine for devices which do have an SNMP agent. > Shall we add a third neutral option for devices without SNMP? > >> (So a future Iipfix-psamp.yang revision may wish to support the YANG interfaces table, >> which will probably not be indexed by either ifInex or ifName.) > > Sure. So, we should take care that the model can easily be extended by a > new option to identify an interface. As far as I understand, we can use > the augment statement to add another leaf to choice OPLocation. > > Gerhard > Andy >> >> >>> Thanks a lot for you help, >>> Gerhard >>> >> >> Andy >> > > From muenz@net.in.tum.de Thu Aug 5 01:43:19 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AF973A6ACE for ; Thu, 5 Aug 2010 01:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.336 X-Spam-Level: X-Spam-Status: No, score=-0.336 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_40=-0.185, 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 8o-mNKAz5ZcQ for ; Thu, 5 Aug 2010 01:43:18 -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 29B5A3A6ADA for ; Thu, 5 Aug 2010 01:43:17 -0700 (PDT) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by mail.net.in.tum.de (Postfix) with ESMTPSA id A8CA0210B6DE; Thu, 5 Aug 2010 10:43:29 +0200 (CEST) Message-ID: <4C5A79DD.9040603@net.in.tum.de> Date: Thu, 05 Aug 2010 10:44:13 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gerhard Muenz , Andy Bierman , NETMOD Working Group References: <4C580765.5060100@net.in.tum.de> <4C5A4EBD.9050205@andybierman.com> <4C5A67D7.4040408@net.in.tum.de> <20100805074840.GB89539@elstar.local> In-Reply-To: <20100805074840.GB89539@elstar.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000004010504040005010709" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 08:43:19 -0000 This is a cryptographically signed message in MIME format. --------------ms000004010504040005010709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi J=FCrgen, Juergen Schoenwaelder wrote: > On Thu, Aug 05, 2010 at 09:27:19AM +0200, Gerhard Muenz wrote: > =20 >> Thank you for your answer. I did not pay attention to this point. >=20 > I did share Andy's concerns when I skimmed the document but then I > thought it is also unfair to raise a flag because there is nothing > better in place and so far we have not even a WG chartered to produce > something more appropriate. > =20 >>> It looks that way. IMO, the NETCONF/SNMP interactions are >>> critically important to interoperability. It should be designed, >>> not ad-hoc. I don't want to hold up ipfix-psamp.yang, but I don't >>> want to let it constrain the eventual interfaces.yang solution >>> either. >> Can you propose an intermediate solution? >> >> At the moment, we allow ifIndex or ifName for identifying an interface= =2E >> These are fine for devices which do have an SNMP agent. >> Shall we add a third neutral option for devices without SNMP? >=20 > Supporting several different ways to identify an interface is not a > good long term solution overall. Perhaps the best we can do is to > accept the fact that there is nothing better yet but to be prepared > that a future revision might change this part of the data model. Should we mention this somewhere in the draft? And in the module itself? >>> (So a future Iipfix-psamp.yang revision may wish to support the YANG = interfaces table, >>> which will probably not be indexed by either ifInex or ifName.) >> Sure. So, we should take care that the model can easily be extended by= a >> new option to identify an interface. As far as I understand, we can us= e >> the augment statement to add another leaf to choice OPLocation. >=20 > I would rather see this "fixed" in place once the document is up for > revision. BTW, is there already implementation with this config model? > I am not following IPFIX in all detail so I am not sure how mature > things are (implementation experience always helps to understand > details better). No, there is no implementation. However, we have two NetFlow/IPFIX implementations in mind: Cisco Flexible NetFlow and Vermont (which is a software probe). > All that said and reading the DESCRIPTION of ifName again, I consider > it very likely that semantically ifName _values_ are going to be used > to refer to interfaces in YANG. How this is done (e.g. by direct > reference to the IF-MIB or via a separate YANG typedef that is > semantically equivalent) I do not know (although I do have an opinion > ;-). I share your opinion regarding the interfaces. I also assume that ifName will be used in practice, just like in the Cisco CLI. What I can say for Vermont, there are no plans to implement an SNMP agent because we do not see a use-case. As it is done in the current Vermont configuration, we will use ifName to identify an interface on a PC (e.g. "eth0"). Hm, maybe we can decide to remove ifIndex and entPhysicalIndex? Would this address your concerns at least partially? Regards, Gerhard >=20 > /js >=20 --------------ms000004010504040005010709 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgwNTA4NDQxM1owIwYJKoZIhvcNAQkEMRYEFJA0 nJ8O+sUAXIyVwtsY+pKnkKoAMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQBEnneKrytOoNi0conXsHKe7bvOBk4jY7oUF7V0SDPCd9RRPVQ1Tr72 ufqSbzBYTkuIGq4CP0kxODAtO2qbipdPKvpvFpIJujbvHOHnykBgkLWJPAeRW0MFQlSztzvT 6zSJJa9y8xJA6gKuOZobiaTNXMdlG2Sd7Cj0MjLXLGxON0zXsGaMGLt+IOnsiBPQrqkG82Pe 0lF9z2zd8HF1e4LaAftmiRkK3EXs4OigeSP4D+F7SxFMQIsRVoWg3ipqjsluJbWoKkn91okC 7jhFiMte8vjEEmNgUPbYW7SzlHwv1xLVdZCwIk7OZsKkqUyT5OET6oDMM0zyULLMtXXTnjl+ AAAAAAAA --------------ms000004010504040005010709-- From j.schoenwaelder@jacobs-university.de Thu Aug 5 01:55:46 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EB663A6A3C for ; Thu, 5 Aug 2010 01:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.636 X-Spam-Level: X-Spam-Status: No, score=-101.636 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DgsQOT2DJ9C for ; Thu, 5 Aug 2010 01:55:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 572C93A68CB for ; Thu, 5 Aug 2010 01:55:45 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 48B7EC0019; Thu, 5 Aug 2010 10:56:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qgNRIMAE42ZR; Thu, 5 Aug 2010 10:56:14 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A3642C0004; Thu, 5 Aug 2010 10:56:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1000A1414404; Thu, 5 Aug 2010 10:56:10 +0200 (CEST) Date: Thu, 5 Aug 2010 10:56:09 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100805085609.GB89667@elstar.local> Mail-Followup-To: Andy Bierman , Gerhard Muenz , NETMOD Working Group References: <4C580765.5060100@net.in.tum.de> <4C5A4EBD.9050205@andybierman.com> <4C5A67D7.4040408@net.in.tum.de> <4C5A7514.9070700@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C5A7514.9070700@andybierman.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group , Gerhard Muenz Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 08:55:46 -0000 On Thu, Aug 05, 2010 at 10:23:48AM +0200, Andy Bierman wrote: > not yet. I prefer a solution that actually attempts to provide > machine readable structure to the if-name, and make if-index go > away. Martin started on a solution (e.g., if-name is a string and > some YANG extension-stmt defines the embedded structure). I think > that has the most promise. Given the wide variety of different ifNames I have seen, I doubt this will work out. I am sceptic that we will do any better than saying what essentially is in the DESCRIPTION of ifName. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu Aug 5 02:05:55 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED33E3A68E3 for ; Thu, 5 Aug 2010 02:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MU9yOUIbh3h for ; Thu, 5 Aug 2010 02:05:54 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 8CF953A659C for ; Thu, 5 Aug 2010 02:05:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,320,1278302400"; d="scan'208";a="201284049" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Aug 2010 05:06:24 -0400 X-IronPort-AV: E=Sophos;i="4.55,320,1278302400"; d="scan'208";a="489534159" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 05 Aug 2010 05:06:22 -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: Thu, 5 Aug 2010 11:05:56 +0200 Message-ID: In-Reply-To: <4C5A4EBD.9050205@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 Thread-Index: Acs0YMD5HkQyn/YwRxigmf+N4Q2t3wAHH64g References: <4C580765.5060100@net.in.tum.de> <4C5A4EBD.9050205@andybierman.com> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "Gerhard Muenz" Cc: NETMOD Working Group Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 09:05:56 -0000 Should I mention the fact that this discussion shows how important is to have the core YANG modules standardized as fast as possible?=20 Dan =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Thursday, August 05, 2010 8:40 AM > To: Gerhard Muenz > Cc: NETMOD Working Group > Subject: Re: [netmod] Feedback on=20 > draft-ietf-ipfix-configuration-model-07 >=20 > On 08/03/2010 05:11 AM, Gerhard Muenz wrote: > >=20 > > Dear all, > >=20 > > In the IPFIX WG, we will have a second WGLC for=20 > > draft-ietf-ipfix-configuration-model-07. > >=20 > > It would be nice if some YANG experts could have a look at the=20 > > document, too. > >=20 > > The YANG module was validated with pyang and seems to be correct. > > Nevertheless, you might have further comments. > >=20 > > We also tried to make the document compliant with the YANG=20 > guidelines. > > If you think that something is missing or should be changed, please=20 > > let me know. > >=20 >=20 >=20 > I have one concern already, which is the usage of ifIndex or=20 > ifName for identifying an interface. This is problematic. > Eventually there will be an interfaces module in YANG, even=20 > if it is just scaffolding so we know where all the vendor=20 > per-interface config belongs. >=20 > Is there an assumption that the NETCONF server co-exists with=20 > an SNMP agent? > It looks that way. IMO, the NETCONF/SNMP interactions are=20 > critically important to interoperability. It should be=20 > designed, not ad-hoc. I don't want to hold up=20 > ipfix-psamp.yang, but I don't want to let it constrain the=20 > eventual interfaces.yang solution either. >=20 > (So a future Iipfix-psamp.yang revision may wish to support=20 > the YANG interfaces table, which will probably not be indexed=20 > by either ifInex or ifName.) >=20 >=20 > > Thanks a lot for you help, > > Gerhard > >=20 >=20 > Andy >=20 >=20 > >=20 > > -------- Original Message -------- > > Subject: [IPFIX] I-D=20 > > Action:draft-ietf-ipfix-configuration-model-07.txt > > Date: Tue, 3 Aug 2010 04:45:02 -0700 (PDT) > > From: Internet-Drafts@ietf.org > > To: i-d-announce@ietf.org > > CC: ipfix@ietf.org > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > This draft is a work item of the IP Flow Information Export Working=20 > > Group of the IETF. > >=20 > >=20 > > Title : Configuration Data Model for IPFIX and PSAMP > > Author(s) : G. Muenz, et al. > > Filename : draft-ietf-ipfix-configuration-model-07.txt > > Pages : 123 > > Date : 2010-08-03 > >=20 > > This document specifies a data model for configuring and monitoring=20 > > Selection Processes, Caches, Exporting Processes, and Collecting=20 > > Processes of IPFIX and PSAMP compliant Monitoring Devices using the=20 > > NETCONF protocol [RFC4741]. The data model is defined using UML=20 > > (Unified Modeling Language) class diagrams and formally specified=20 > > using YANG [I-D.ietf-netmod-yang]. The configuration data=20 > is encoded=20 > > in Extensible Markup Language (XML). > >=20 > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-mod > > el-07.txt > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From j.schoenwaelder@jacobs-university.de Thu Aug 5 02:13:13 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326533A69DA for ; Thu, 5 Aug 2010 02:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.652 X-Spam-Level: X-Spam-Status: No, score=-101.652 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-WUo5JC6CQr for ; Thu, 5 Aug 2010 02:13:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DD8B53A6AEA for ; Thu, 5 Aug 2010 02:13:11 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CDAC4C0016; Thu, 5 Aug 2010 11:13:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kFnSAS07Rk8P; Thu, 5 Aug 2010 11:13:40 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 99C6AC0004; Thu, 5 Aug 2010 11:13:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0B4CA1414484; Thu, 5 Aug 2010 11:13:37 +0200 (CEST) Date: Thu, 5 Aug 2010 11:13:36 +0200 From: Juergen Schoenwaelder To: Gerhard Muenz Message-ID: <20100805091336.GC89667@elstar.local> Mail-Followup-To: Gerhard Muenz , Andy Bierman , NETMOD Working Group References: <4C580765.5060100@net.in.tum.de> <4C5A4EBD.9050205@andybierman.com> <4C5A67D7.4040408@net.in.tum.de> <20100805074840.GB89539@elstar.local> <4C5A79DD.9040603@net.in.tum.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C5A79DD.9040603@net.in.tum.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 09:13:13 -0000 On Thu, Aug 05, 2010 at 10:44:13AM +0200, Gerhard Muenz wrote: > Hm, maybe we can decide to remove ifIndex and entPhysicalIndex? > Would this address your concerns at least partially? Partially. I do not understand entPhysicalIndex or entPhysicalName since they are supposed to refer to a "linecard". Is the assumption here that a linecard has exactly one interface? Or is this an observation point attached on purpose to multiple interfaces of a linecard? I could probably ask many more questions concerning the YANG model but so far I did not have time to read things carefully. In general, I think it would be valuable to have more typedefs for basic IPFIX concepts. See for instance observation domain ID. RFC 5101 gives the value 0 a special meaning, this is not reflected in the observationDomainId leafs (and one of the three leafs does not even refer to RFC 5101). I personally would also prefer to change leaf names to make the names of leafs unique within the module (makes communication easier) and I would prefer using YANG dashed writing style. But to be really prepared, I would have to read the whole thing (123 pages) and use tools to inspect the structure of the data model or make drawings myself. And then I would have to spent time checking for consistency between the data model and what is in the class diagrams and whether the semantics in the supporting text are also reflected in the YANG definitions. And then there are MIB modules to be consistent with and of IPFIX and PSAMP itself. Sometimes, having less overlapping text makes things simpler. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Thu Aug 5 02:15:15 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13FA03A6AEA for ; Thu, 5 Aug 2010 02:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 cro-bwYZX71o for ; Thu, 5 Aug 2010 02:15:14 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 3D4A23A6AE1 for ; Thu, 5 Aug 2010 02:15:14 -0700 (PDT) Received: (qmail 52017 invoked from network); 5 Aug 2010 09:15:41 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 05 Aug 2010 02:15:41 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 8hAag2wVM1mOzcdBFFP0yj5_474uA68LHKp1g81SlkdC5HU Px6gBOthJMhZw3UHbnaakUdy2IwOJxd3eDYtmTBwPDQEUcQ4JPr6EDC.FY0V tKlBZt.6oFBFQj.hANcuYOrj0OTuNgBdMA5waSE3XrdKcOii24imSOqcnmeb jyroBvFuK7R8vGMk8yW3hQydcRrqPCDD_ynwGWm56bpvEMA0RzrywJiyEYHn PRFjv9oKJgvth_SLLfnLD94TCVtbi X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C5A813D.5040306@andybierman.com> Date: Thu, 05 Aug 2010 02:15:41 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Gerhard Muenz , NETMOD Working Group References: <4C580765.5060100@net.in.tum.de> <4C5A4EBD.9050205@andybierman.com> <4C5A67D7.4040408@net.in.tum.de> <4C5A7514.9070700@andybierman.com> <20100805085609.GB89667@elstar.local> In-Reply-To: <20100805085609.GB89667@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 09:15:15 -0000 On 08/05/2010 01:56 AM, Juergen Schoenwaelder wrote: > On Thu, Aug 05, 2010 at 10:23:48AM +0200, Andy Bierman wrote: > >> not yet. I prefer a solution that actually attempts to provide >> machine readable structure to the if-name, and make if-index go >> away. Martin started on a solution (e.g., if-name is a string and >> some YANG extension-stmt defines the embedded structure). I think >> that has the most promise. > > Given the wide variety of different ifNames I have seen, I doubt this > will work out. I am sceptic that we will do any better than saying > what essentially is in the DESCRIPTION of ifName. > Of course there is a description-stmt, but there can also be out-of-band vendor extension-stmts. The structure is different, but predictable for a given subset of a given vendor's products, right? extension my-if-structure { ... } acme:my-if-structure { acme:if-separators "/ ."; leaf machine-id { type string { length 4; } } leaf slot { type uint16; } leaf port { type uint32; } ... } Then the vendor needs to provide this YANG as an annotation somewhere and the standard leaf can be parsed semi-automatically. We don't need to get the IETF to agree on the uber-if-name definition. > /js > Andy From j.schoenwaelder@jacobs-university.de Thu Aug 5 02:44:28 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5143A68F6 for ; Thu, 5 Aug 2010 02:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.738 X-Spam-Level: X-Spam-Status: No, score=-100.738 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_20=-0.74, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7R0USPXWcAw for ; Thu, 5 Aug 2010 02:44:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7D3F83A6801 for ; Thu, 5 Aug 2010 02:44:26 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 74BDFC0016; Thu, 5 Aug 2010 11:44:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RzGW0+jbimc0; Thu, 5 Aug 2010 11:44:55 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF9A4C0004; Thu, 5 Aug 2010 11:44:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 30EC614146FA; Thu, 5 Aug 2010 11:44:51 +0200 (CEST) Date: Thu, 5 Aug 2010 11:44:51 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100805094451.GB89935@elstar.local> Mail-Followup-To: Andy Bierman , Gerhard Muenz , NETMOD Working Group References: <4C580765.5060100@net.in.tum.de> <4C5A4EBD.9050205@andybierman.com> <4C5A67D7.4040408@net.in.tum.de> <4C5A7514.9070700@andybierman.com> <20100805085609.GB89667@elstar.local> <4C5A813D.5040306@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C5A813D.5040306@andybierman.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group , Gerhard Muenz Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 09:44:28 -0000 On Thu, Aug 05, 2010 at 11:15:41AM +0200, Andy Bierman wrote: > On 08/05/2010 01:56 AM, Juergen Schoenwaelder wrote: > > On Thu, Aug 05, 2010 at 10:23:48AM +0200, Andy Bierman wrote: > > > >> not yet. I prefer a solution that actually attempts to provide > >> machine readable structure to the if-name, and make if-index go > >> away. Martin started on a solution (e.g., if-name is a string and > >> some YANG extension-stmt defines the embedded structure). I think > >> that has the most promise. > > > > Given the wide variety of different ifNames I have seen, I doubt this > > will work out. I am sceptic that we will do any better than saying > > what essentially is in the DESCRIPTION of ifName. > > > > Of course there is a description-stmt, but there can > also be out-of-band vendor extension-stmts. > > The structure is different, but predictable for a given subset > of a given vendor's products, right? > > extension my-if-structure { ... } > > acme:my-if-structure { > acme:if-separators "/ ."; > leaf machine-id { > type string { length 4; } > } > leaf slot { type uint16; } > leaf port { type uint32; } > ... > } > > Then the vendor needs to provide this YANG as an annotation somewhere > and the standard leaf can be parsed semi-automatically. We can choose to have slot and port leafs, e.g. list interface { key "name"; leaf name { ... }; leaf port { ... }; leaf slot { ... }; } or we can follow the old MIB approach where the physical port sitting in a containment hierarchy representing the physical structure of the device can point to logical interfaces. Both are workable solutions, none of them requires that we agree on the format of an interface name or that we have to parse and interpret the name itself. The more fun part will be what we do with interfaces that come and go, what config means for interfaces that come and go etc. And boxes differ here - some boxes have interfaces where the name carries a logical function (vlan42) or discovery order (eth0) while others have interfaces where the name carries structural information. Once you flip interfaces, the results you get when say ipfix config refers to an interface name will depend quite a bit on the naming scheme (eth0 might still be a valid interface, even though it now sits in a different slot, vlan42 might still do the expected, the reference to a physical slot might be invalid). It may make sense to distinguish between interface names that are associated with a physical location and names that are associated with a function so that config snippets can use what makes most sense. I might prefer to write firewall rules for an interfaces called "customer-xyz" so that I do not have to change firewall rules if I move the customer to a different interface (so I am talking about ifAlias vs ifName in MIB terms, although IF-MIB's ifAlias does not guarantee uniqueness I think). Yes Dan, this is a crucial piece of work to be done. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu Aug 5 03:10:30 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 744DC3A6A44 for ; Thu, 5 Aug 2010 03:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8JZ37FMAtTN for ; Thu, 5 Aug 2010 03:10:24 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id CD26D3A69F6 for ; Thu, 5 Aug 2010 03:10:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,320,1278302400"; d="scan'208";a="28386325" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 05 Aug 2010 06:10:52 -0400 X-IronPort-AV: E=Sophos;i="4.55,320,1278302400"; d="scan'208";a="497591299" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Aug 2010 06:10:51 -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: Thu, 5 Aug 2010 12:10:40 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: YANG Doctors Team - Call for Volunteers Thread-Index: Acs0hnU2hT1bh+ZeQZSgDpHQrym5rQ== From: "Romascanu, Dan (Dan)" To: "NETMOD Working Group" Subject: [netmod] YANG Doctors Team - Call for Volunteers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 10:10:30 -0000 With the (soon-to-come) publication of the YANG RFC, and of the guidelines document we hope and expect for more teams within and our of the IETF to start writing YANG modules. We already know about a few examples. I think that time has come to form a YANG Doctors directorate (review team) modeled on the activity of the MIB Doctors team. This basically means that it will be a closed group which will review documents and discuss YANG-related queries and issues. All YANG documents in the IETF will be directed to this team for expert review. Reviews will be performed on volunteer basis, but the team leader (for MIB Doctors this was the management AD, but we can discuss other options for the YANG Doctors) may ask team members to perform reviews if volunteers do not step up.=20 Please volunteer! Thanks and Regards, Dan From muenz@net.in.tum.de Thu Aug 5 04:06:45 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9EAA3A67EC for ; Thu, 5 Aug 2010 04:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_05=-1.11, 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 YwuWMzYCBNcT for ; Thu, 5 Aug 2010 04:06:44 -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 77B933A6875 for ; Thu, 5 Aug 2010 04:06:44 -0700 (PDT) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 7CBBB20AEA5F; Thu, 5 Aug 2010 13:06:48 +0200 (CEST) Message-ID: <4C5A9B74.1090200@net.in.tum.de> Date: Thu, 05 Aug 2010 13:07:32 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Juergen Schoenwaelder , NETMOD Working Group References: <4C580765.5060100@net.in.tum.de> <4C5A4EBD.9050205@andybierman.com> <4C5A67D7.4040408@net.in.tum.de> <20100805074840.GB89539@elstar.local> <4C5A79DD.9040603@net.in.tum.de> <20100805091336.GC89667@elstar.local> In-Reply-To: <20100805091336.GC89667@elstar.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060803090401030104080508" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 11:06:45 -0000 This is a cryptographically signed message in MIME format. --------------ms060803090401030104080508 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > On Thu, Aug 05, 2010 at 10:44:13AM +0200, Gerhard Muenz wrote: > >> Hm, maybe we can decide to remove ifIndex and entPhysicalIndex? >> Would this address your concerns at least partially? > > Partially. > > I do not understand entPhysicalIndex or entPhysicalName since they are > supposed to refer to a "linecard". Is the assumption here that a > linecard has exactly one interface? Or is this an observation point > attached on purpose to multiple interfaces of a linecard? The later is true. From RFC5101: An Observation Point is a location in the network where IP packets can be observed. Examples include: a line to which a probe is attached, a shared medium, such as an Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router. > I could probably ask many more questions concerning the YANG model but > so far I did not have time to read things carefully. In general, I > think it would be valuable to have more typedefs for basic IPFIX > concepts. See for instance observation domain ID. RFC 5101 gives the > value 0 a special meaning, this is not reflected in the > observationDomainId leafs (and one of the three leafs does not even > refer to RFC 5101). More typedefs for IPFIX-specific values are a good suggestion. I'll try to include that. > I personally would also prefer to change leaf > names to make the names of leafs unique within the module (makes > communication easier) and I would prefer using YANG dashed writing > style. Is there a general preference for dashed writing style in YANG? MIB object names do not use it. > But to be really prepared, I would have to read the whole thing (123 > pages) and use tools to inspect the structure of the data model or > make drawings myself. And then I would have to spent time checking for > consistency between the data model and what is in the class diagrams > and whether the semantics in the supporting text are also reflected in > the YANG definitions. And then there are MIB modules to be consistent > with and of IPFIX and PSAMP itself. Sometimes, having less overlapping > text makes things simpler. I see that you understand the complexity of the defining such a model :) Of course, it would be nice if reviewers would check all these details, but I do not think that this whole effort can be expected. The most important feedback from the NETMOD working group is what you already offer right now: comments about the form of the document and specific design issues of the module. Thanks, Gerhard --------------ms060803090401030104080508 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgwNTExMDczMlowIwYJKoZIhvcNAQkEMRYEFBtn BNpj/PuI+5iZqJn29R2yePmAMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQAVvCp0vXFIyKvAtvQRxGy4e9L6jB5aQ68C7q6kbIkujRyY+Z/4LFVp lBfR8ohiPjS5H+de4s41MYJB/WGYuZGZ69CavthzGU9cdBzKNwHpk2RXVcYND2z/nYmTPNfD B5T2j8is3Q9ftYRAAIufs4D7v8XCPs3JTCLi8DDA4/JHZbSbKZZ3rtk/GvdHJlC78HVgpSjC sOuX1ex2nT1WoRigng4HtQVNspEkfn25kAVa+OH0JydCRZwEhHsifjYULAahnw7nWgg6xZb6 bYA5S1jnMDKXOCZks48HmR4RooPL8syWMF6aBuUhNRMdoammew7uVlu2sT+logHFo0bcVGKW AAAAAAAA --------------ms060803090401030104080508-- From j.schoenwaelder@jacobs-university.de Thu Aug 5 04:25:46 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACABC3A67EC for ; Thu, 5 Aug 2010 04:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.659 X-Spam-Level: X-Spam-Status: No, score=-101.659 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMubv3SzX6H9 for ; Thu, 5 Aug 2010 04:25:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BE7033A6A61 for ; Thu, 5 Aug 2010 04:25:44 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C4F65C001D; Thu, 5 Aug 2010 13:26:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IEPKzBSC5IGw; Thu, 5 Aug 2010 13:26:13 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB349C001B; Thu, 5 Aug 2010 13:26:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4C930141D501; Thu, 5 Aug 2010 13:26:09 +0200 (CEST) Date: Thu, 5 Aug 2010 13:26:09 +0200 From: Juergen Schoenwaelder To: Gerhard Muenz Message-ID: <20100805112609.GC90243@elstar.local> Mail-Followup-To: Gerhard Muenz , NETMOD Working Group References: <4C580765.5060100@net.in.tum.de> <4C5A4EBD.9050205@andybierman.com> <4C5A67D7.4040408@net.in.tum.de> <20100805074840.GB89539@elstar.local> <4C5A79DD.9040603@net.in.tum.de> <20100805091336.GC89667@elstar.local> <4C5A9B74.1090200@net.in.tum.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C5A9B74.1090200@net.in.tum.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 11:25:46 -0000 On Thu, Aug 05, 2010 at 01:07:32PM +0200, Gerhard Muenz wrote: > Juergen Schoenwaelder wrote: > > On Thu, Aug 05, 2010 at 10:44:13AM +0200, Gerhard Muenz wrote: > > > >> Hm, maybe we can decide to remove ifIndex and entPhysicalIndex? > >> Would this address your concerns at least partially? > > > > Partially. > > > > I do not understand entPhysicalIndex or entPhysicalName since they are > > supposed to refer to a "linecard". Is the assumption here that a > > linecard has exactly one interface? Or is this an observation point > > attached on purpose to multiple interfaces of a linecard? > > The later is true. From RFC5101: > > An Observation Point is a location in the network where IP packets > can be observed. Examples include: a line to which a probe is > attached, a shared medium, such as an Ethernet-based LAN, a single > port of a router, or a set of interfaces (physical or logical) of > a router. This does not line up. RFC 5101 leaves it pretty open what an observation point is and only provides examples. The YANG configuration module is much more restrictive. This might be what the WG wants but clearly what is in the YANG model does not follow directly from this quote of RFC5101. > > I personally would also prefer to change leaf > > names to make the names of leafs unique within the module (makes > > communication easier) and I would prefer using YANG dashed writing > > style. > > Is there a general preference for dashed writing style in YANG? > MIB object names do not use it. The YANG language plus all modules produced or in the making in the NETMOD/NETCONF WGs use the hyphen style. You may want to discard my second comment concerning uniqueness of identifiers - I might actually not like the idea on second thought (since we have a path notation available that can be used easily and avoid extremely long and difficult to read identifiers). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Thu Aug 5 10:51:36 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1A773A6B17 for ; Thu, 5 Aug 2010 10:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] 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 lF5BdArqX2u0 for ; Thu, 5 Aug 2010 10:51:36 -0700 (PDT) Received: from smtp105.sbc.mail.gq1.yahoo.com (smtp105.sbc.mail.gq1.yahoo.com [67.195.14.108]) by core3.amsl.com (Postfix) with SMTP id 043BE3A6A8C for ; Thu, 5 Aug 2010 10:51:35 -0700 (PDT) Received: (qmail 88785 invoked from network); 5 Aug 2010 17:52:03 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp105.sbc.mail.gq1.yahoo.com with SMTP; 05 Aug 2010 10:52:03 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: vkh8O0cVM1kQr1qbwjpkqRvywFgLyDJX7NuKiSvBixJgGlM AkZAsfzfa9P1p9yvW8K5Cx1qT7D.Auo92yn6T21PsbukUjL7.IXTKAxFahR0 qIh.XrX9LHVw.H8m1ZgyD_z3wLxqC93SJaw0MqcDCCmrA5Jt0L1faR70UGeT L2gQE0ZyISVBPwgENUWFcXsa1004GM3i5KuiJ549tjARzJfGFzrOg8e2V557 BF0BWDI3M3iyIFu1MaPmto4WXOLM6MuNQBZxoXqKZTzXfxxVIE8.4ViDTUQr bBfALs5y7bpqjY98iaLTRSQRDqwdAxjVQLVQ8gjRpUYMVcw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C5AFA42.5030802@andybierman.com> Date: Thu, 05 Aug 2010 10:52:02 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: NETCONF , NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] FYI: open-source NETCONF implementation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 17:51:36 -0000 Hi, I have made my NETCONF tools into an open-source project with a BSD license: http://yuma.sourceforge.net/ I have started a new job (yet another email change to follow...), so I am looking for volunteers to maintain and improve the code base. (See the TODO list in the top directory.) I do not have enough time to actively work on code enhancements anymore. Andy From lhotka@cesnet.cz Fri Aug 6 07:28:32 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24E63A6A8F for ; Fri, 6 Aug 2010 07:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.241, 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 wSZxYSOSQIB0 for ; Fri, 6 Aug 2010 07:28:31 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 9D3EF3A6AA6 for ; Fri, 6 Aug 2010 07:28:30 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id A0D2B2CDE05B for ; Fri, 6 Aug 2010 16:29:00 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <4C580765.5060100@net.in.tum.de> References: <4C580765.5060100@net.in.tum.de> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 06 Aug 2010 16:28:59 +0200 Message-ID: <1281104939.5027.35.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 14:28:32 -0000 Hi Gerhard, I have the following comments/questions: 1. You only have one revision covering the entire history of the module. I would expect at least one revision of the module for each revision of the I-D. 2. Given the large number of declared features (17), perhaps it would be better to have multiple modules, e.g. separate modules for "meter", "exporter", "collector" and "psamp". Have you considered this option? Lada Gerhard Muenz píše v Út 03. 08. 2010 v 14:11 +0200: > Dear all, > > In the IPFIX WG, we will have a second WGLC for > draft-ietf-ipfix-configuration-model-07. > > It would be nice if some YANG experts could have a look at the document, > too. > > The YANG module was validated with pyang and seems to be correct. > Nevertheless, you might have further comments. > > We also tried to make the document compliant with the YANG guidelines. > If you think that something is missing or should be changed, please let > me know. > > Thanks a lot for you help, > Gerhard > > > -------- Original Message -------- > Subject: [IPFIX] I-D Action:draft-ietf-ipfix-configuration-model-07.txt > Date: Tue, 3 Aug 2010 04:45:02 -0700 (PDT) > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > CC: ipfix@ietf.org > > 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-07.txt > Pages : 123 > Date : 2010-08-03 > > This document specifies a data model for configuring and monitoring > Selection Processes, Caches, Exporting Processes, and Collecting > Processes of IPFIX and PSAMP compliant Monitoring Devices using the > NETCONF protocol [RFC4741]. The data model is defined using UML > (Unified Modeling Language) class diagrams and formally specified > using YANG [I-D.ietf-netmod-yang]. The configuration data is encoded > in Extensible Markup Language (XML). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-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. > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Fri Aug 6 07:43:40 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A733A6AD3 for ; Fri, 6 Aug 2010 07:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.673 X-Spam-Level: X-Spam-Status: No, score=-101.673 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7ACmNL+8kgl for ; Fri, 6 Aug 2010 07:43:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 066AD3A68F0 for ; Fri, 6 Aug 2010 07:43:20 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2349C0007; Fri, 6 Aug 2010 16:43:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id y3LS6Ycr0x8v; Fri, 6 Aug 2010 16:43:49 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4BACFC001B; Fri, 6 Aug 2010 16:43:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C42AD1420823; Fri, 6 Aug 2010 16:43:45 +0200 (CEST) Date: Fri, 6 Aug 2010 16:43:45 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20100806144345.GA4343@elstar.local> Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" References: <4C580765.5060100@net.in.tum.de> <1281104939.5027.35.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1281104939.5027.35.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 14:43:41 -0000 On Fri, Aug 06, 2010 at 04:28:59PM +0200, Ladislav Lhotka wrote: > 1. You only have one revision covering the entire history of the module. > I would expect at least one revision of the module for each revision of > the I-D. I think we decided to follow the SMIv2 model (this is my understanding of section 4.6 in the YANG usage document) where a revision is used to track "published" modules, where "published" means published as RFC (or published by a vendor by shipping it with their hard-/software. So I expect only one revision clause which just states that this is the initial revision. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Fri Aug 6 08:20:08 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 541F73A6A53 for ; Fri, 6 Aug 2010 08:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.05 X-Spam-Level: X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 UkyArsiaFcN0 for ; Fri, 6 Aug 2010 08:20:07 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 7DB9B3A695E for ; Fri, 6 Aug 2010 08:20:07 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id E38EB2CDE05B; Fri, 6 Aug 2010 17:20:07 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20100806144345.GA4343@elstar.local> References: <4C580765.5060100@net.in.tum.de> <1281104939.5027.35.camel@missotis> <20100806144345.GA4343@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 06 Aug 2010 17:20:06 +0200 Message-ID: <1281108006.5027.58.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 15:20:08 -0000 Juergen Schoenwaelder píše v Pá 06. 08. 2010 v 16:43 +0200: > On Fri, Aug 06, 2010 at 04:28:59PM +0200, Ladislav Lhotka wrote: > > > 1. You only have one revision covering the entire history of the module. > > I would expect at least one revision of the module for each revision of > > the I-D. > > I think we decided to follow the SMIv2 model (this is my understanding > of section 4.6 in the YANG usage document) where a revision is used to > track "published" modules, where "published" means published as RFC > (or published by a vendor by shipping it with their hard-/software. > So I expect only one revision clause which just states that this is > the initial revision. Well, the last paragraph of section 4.7 in draft-ietf-netmod-yang-usage-09 is IMO quite clear: "It is acceptable to reuse the same revision statement within unpublished versions (i.e., Internet-Drafts), but the revision date MUST be updated to a higher value each time the Internet-Draft is re- published." I think this is appropriate since even an I-D is a form of publication, and may actually get implemented, so it seems helpful to state clearly the revision history. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf@andybierman.com Fri Aug 6 09:03:43 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DB63A67F0 for ; Fri, 6 Aug 2010 09:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 mS+1bqbeOWAn for ; Fri, 6 Aug 2010 09:03:42 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 4B3AF3A67B3 for ; Fri, 6 Aug 2010 09:03:42 -0700 (PDT) Received: (qmail 81423 invoked from network); 6 Aug 2010 16:04:12 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 06 Aug 2010 09:04:12 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 58N0h0MVM1kgfO6J8ybzag.WtDjsoRhKlJWVsCHs1ViI4un ePozyH_LOqlWMEej.wYpM3LT_bvgr1w2JDrj6o6cY6hOU7x3HY1ZcNqMsCXG IEdZfVvAAkAGITPHA.l.HZPJAnaCRnkVsspohBT.Y6kCpJI8C1niNLPeD5E. LKqJv4WQUqOS79T7LNz8RsaBd0Qzz8LjJRxAU8ArGKXoc7ZDR.j0HVBearY8 JmclXDqtKZtinue5WhkrL4e_LTR09N7cujW05CTKuv.shyrVt X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C5C327D.5070005@andybierman.com> Date: Fri, 06 Aug 2010 09:04:13 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Ladislav Lhotka References: <4C580765.5060100@net.in.tum.de> <1281104939.5027.35.camel@missotis> <20100806144345.GA4343@elstar.local> <1281108006.5027.58.camel@missotis> In-Reply-To: <1281108006.5027.58.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 16:03:43 -0000 On 08/06/2010 08:20 AM, Ladislav Lhotka wrote: > Juergen Schoenwaelder píše v Pá 06. 08. 2010 v 16:43 +0200: >> On Fri, Aug 06, 2010 at 04:28:59PM +0200, Ladislav Lhotka wrote: >> >>> 1. You only have one revision covering the entire history of the module. >>> I would expect at least one revision of the module for each revision of >>> the I-D. >> >> I think we decided to follow the SMIv2 model (this is my understanding >> of section 4.6 in the YANG usage document) where a revision is used to >> track "published" modules, where "published" means published as RFC >> (or published by a vendor by shipping it with their hard-/software. >> So I expect only one revision clause which just states that this is >> the initial revision. > > Well, the last paragraph of section 4.7 in > draft-ietf-netmod-yang-usage-09 is IMO quite clear: > > "It is acceptable to reuse the same revision statement within > unpublished versions (i.e., Internet-Drafts), but the revision date > MUST be updated to a higher value each time the Internet-Draft is re- > published." > > I think this is appropriate since even an I-D is a form of publication, > and may actually get implemented, so it seems helpful to state clearly > the revision history. > This is a bit too strict. Sometimes the I-D is updated and the YANG module within the I-D has not been touched. IMO, s/MUST/SHOULD/ (w this explanation added) should be made to the usage guidelines. I.e, revision date MUST be updated if any contents of the module has changed. > Lada > >> >> /js >> > Andy From j.schoenwaelder@jacobs-university.de Fri Aug 6 09:05:50 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17B8E3A67F0 for ; Fri, 6 Aug 2010 09:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.687 X-Spam-Level: X-Spam-Status: No, score=-101.687 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7UYeWjTZSMq for ; Fri, 6 Aug 2010 09:05:49 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D00AD3A67B3 for ; Fri, 6 Aug 2010 09:05:48 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DDC27C0007; Fri, 6 Aug 2010 18:06:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eDKZF+OVy-lh; Fri, 6 Aug 2010 18:06:18 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A58FC0004; Fri, 6 Aug 2010 18:06:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5295B1420BEB; Fri, 6 Aug 2010 18:06:14 +0200 (CEST) Date: Fri, 6 Aug 2010 18:06:14 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20100806160613.GA4685@elstar.local> Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" References: <4C580765.5060100@net.in.tum.de> <1281104939.5027.35.camel@missotis> <20100806144345.GA4343@elstar.local> <1281108006.5027.58.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1281108006.5027.58.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 16:05:50 -0000 On Fri, Aug 06, 2010 at 05:20:06PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v P?? 06. 08. 2010 v 16:43 +0200: > > On Fri, Aug 06, 2010 at 04:28:59PM +0200, Ladislav Lhotka wrote: > > > > > 1. You only have one revision covering the entire history of the module. > > > I would expect at least one revision of the module for each revision of > > > the I-D. > > > > I think we decided to follow the SMIv2 model (this is my understanding > > of section 4.6 in the YANG usage document) where a revision is used to > > track "published" modules, where "published" means published as RFC > > (or published by a vendor by shipping it with their hard-/software. > > So I expect only one revision clause which just states that this is > > the initial revision. > > Well, the last paragraph of section 4.7 in > draft-ietf-netmod-yang-usage-09 is IMO quite clear: > > "It is acceptable to reuse the same revision statement within > unpublished versions (i.e., Internet-Drafts), but the revision date > MUST be updated to a higher value each time the Internet-Draft is re- > published." > > I think this is appropriate since even an I-D is a form of publication, > and may actually get implemented, so it seems helpful to state clearly > the revision history. I disagree. The product of a WG is the RFC and while there is value in documenting the differences between subsequent RFCs for the users of RFCs, I do not see the need to document for the users of RFCs the differences between working documents. We should not encourage people to actually ship implementations of I-Ds. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Fri Aug 6 09:16:55 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC6663A679F for ; Fri, 6 Aug 2010 09:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 ug+fBSRZcLnV for ; Fri, 6 Aug 2010 09:16:54 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 00B6A3A6874 for ; Fri, 6 Aug 2010 09:16:53 -0700 (PDT) Received: (qmail 95173 invoked from network); 6 Aug 2010 16:17:25 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 06 Aug 2010 09:17:24 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 8ZWQeb0VM1kpQH0Iqedx_QKbRvLE5bInwVRWac.JHYqpBmF uUseI75Q4VUS.g56DyHg5LDA.hyUQw1NEjEPdkbM17By_8hAvCAoXVuBAREc diWoNjostgyZfz14juRopaKq4AL08b0tbEa_y2BSF85xRnzK7xLe7wNYFVKz Efn3rw3fCL5NpGNCn4hmJmsu5Vi7oj6CAzAvkybNOiaz9a8ETBQJQfN9kamv LzEzcxwNxEt_Q8NBd47TqOLNbOvkGsCLE3cgVsg_bF.byiDzP7hv7hFcOP0x bQrzYOt8T4c2nOXHSzAVvV1XN X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C5C3595.7070606@andybierman.com> Date: Fri, 06 Aug 2010 09:17:25 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Ladislav Lhotka , "netmod@ietf.org" References: <4C580765.5060100@net.in.tum.de> <1281104939.5027.35.camel@missotis> <20100806144345.GA4343@elstar.local> <1281108006.5027.58.camel@missotis> <20100806160613.GA4685@elstar.local> In-Reply-To: <20100806160613.GA4685@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 16:16:55 -0000 On 08/06/2010 09:06 AM, Juergen Schoenwaelder wrote: > On Fri, Aug 06, 2010 at 05:20:06PM +0200, Ladislav Lhotka wrote: >> Juergen Schoenwaelder p????e v P?? 06. 08. 2010 v 16:43 +0200: >>> On Fri, Aug 06, 2010 at 04:28:59PM +0200, Ladislav Lhotka wrote: >>> >>>> 1. You only have one revision covering the entire history of the module. >>>> I would expect at least one revision of the module for each revision of >>>> the I-D. >>> >>> I think we decided to follow the SMIv2 model (this is my understanding >>> of section 4.6 in the YANG usage document) where a revision is used to >>> track "published" modules, where "published" means published as RFC >>> (or published by a vendor by shipping it with their hard-/software. >>> So I expect only one revision clause which just states that this is >>> the initial revision. >> >> Well, the last paragraph of section 4.7 in >> draft-ietf-netmod-yang-usage-09 is IMO quite clear: >> >> "It is acceptable to reuse the same revision statement within >> unpublished versions (i.e., Internet-Drafts), but the revision date >> MUST be updated to a higher value each time the Internet-Draft is re- >> published." >> >> I think this is appropriate since even an I-D is a form of publication, >> and may actually get implemented, so it seems helpful to state clearly >> the revision history. > > I disagree. The product of a WG is the RFC and while there is value in > documenting the differences between subsequent RFCs for the users of > RFCs, I do not see the need to document for the users of RFCs the > differences between working documents. We should not encourage people > to actually ship implementations of I-Ds. > I agree this is a slippery slope, but we want to encourage early implementation, so we can find the bugs ASAP. This also applies to readers of the extracted YANG module, who want to know if the work-in-progress changed at all. Vendors are going to ship I-Ds at their peril. If the revision date is updated, YANG tools can easily deal with new and old revisions. Also, opensource projects may be intended to support IETF work-in-progress, so they are harmed by improper updating of the revision date. > /js > Andy From lhotka@cesnet.cz Fri Aug 6 09:45:34 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502063A68AD for ; Fri, 6 Aug 2010 09:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.201, 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 iwTlF0KwG+Vu for ; Fri, 6 Aug 2010 09:45:33 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id D71D33A6A0A for ; Fri, 6 Aug 2010 09:45:32 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 8AE5E2CDE05B; Fri, 6 Aug 2010 18:46:02 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4C5C3595.7070606@andybierman.com> References: <4C580765.5060100@net.in.tum.de> <1281104939.5027.35.camel@missotis> <20100806144345.GA4343@elstar.local> <1281108006.5027.58.camel@missotis> <20100806160613.GA4685@elstar.local> <4C5C3595.7070606@andybierman.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Fri, 06 Aug 2010 18:46:01 +0200 Message-ID: <1281113161.5027.70.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 16:45:34 -0000 Andy Bierman píše v Pá 06. 08. 2010 v 09:17 -0700: > On 08/06/2010 09:06 AM, Juergen Schoenwaelder wrote: > > On Fri, Aug 06, 2010 at 05:20:06PM +0200, Ladislav Lhotka wrote: > >> Juergen Schoenwaelder p????e v P?? 06. 08. 2010 v 16:43 +0200: > >>> On Fri, Aug 06, 2010 at 04:28:59PM +0200, Ladislav Lhotka wrote: > >>> > >>>> 1. You only have one revision covering the entire history of the module. > >>>> I would expect at least one revision of the module for each revision of > >>>> the I-D. > >>> > >>> I think we decided to follow the SMIv2 model (this is my understanding > >>> of section 4.6 in the YANG usage document) where a revision is used to > >>> track "published" modules, where "published" means published as RFC > >>> (or published by a vendor by shipping it with their hard-/software. > >>> So I expect only one revision clause which just states that this is > >>> the initial revision. > >> > >> Well, the last paragraph of section 4.7 in > >> draft-ietf-netmod-yang-usage-09 is IMO quite clear: > >> > >> "It is acceptable to reuse the same revision statement within > >> unpublished versions (i.e., Internet-Drafts), but the revision date > >> MUST be updated to a higher value each time the Internet-Draft is re- > >> published." > >> > >> I think this is appropriate since even an I-D is a form of publication, > >> and may actually get implemented, so it seems helpful to state clearly > >> the revision history. > > > > I disagree. The product of a WG is the RFC and while there is value in > > documenting the differences between subsequent RFCs for the users of > > RFCs, I do not see the need to document for the users of RFCs the > > differences between working documents. We should not encourage people > > to actually ship implementations of I-Ds. > > > > I agree this is a slippery slope, but we want to encourage early implementation, > so we can find the bugs ASAP. This also applies to readers of the extracted > YANG module, who want to know if the work-in-progress changed at all. > > Vendors are going to ship I-Ds at their peril. > If the revision date is updated, YANG tools can easily > deal with new and old revisions. Also, opensource projects > may be intended to support IETF work-in-progress, so they > are harmed by improper updating of the revision date. Actually, my comment was not about improper updating of the revision date - every revision of that I-D in fact uses a new revision date for the module - but rather about the practice of "forgetting" the old revisions and moving all descriptions from the old revisions to the most recent one. I would prefer to keep the old revision info intact to be able to clearly see the revision in which each change happened. Lada > > > > /js > > > > Andy -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf@andybierman.com Fri Aug 6 10:07:16 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFE073A67F2 for ; Fri, 6 Aug 2010 10:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 ewKybXTl0Grt for ; Fri, 6 Aug 2010 10:07:16 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 00BF43A683C for ; Fri, 6 Aug 2010 10:07:15 -0700 (PDT) Received: (qmail 51181 invoked from network); 6 Aug 2010 17:07:45 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 06 Aug 2010 10:07:45 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: a5HzdlMVM1lmH94enelJfgMjPjbiCQ6Gg6scTzv.cJYcPfJ dBpSj5AzEF0ML6rJZAaAWm4hu6B563vAj1N5yeHgxu420hoEBK9KjpxhNcQG fRHX8Qr4y229GvAeoQQyU2mMfVRCB32BtI3QYyNp_Y5DhKtPwqLRa.UY7S5X tvX9F8mNwG1DLRlSwnWLICTUCX47C0kJy07bUUGI4cYbjEn70.51DAOsfnYL n3bikN0_Lzg5WV8JCS8_TgTlmGrxC X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C5C4161.6090804@andybierman.com> Date: Fri, 06 Aug 2010 10:07:45 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Ladislav Lhotka References: <4C580765.5060100@net.in.tum.de> <1281104939.5027.35.camel@missotis> <20100806144345.GA4343@elstar.local> <1281108006.5027.58.camel@missotis> <20100806160613.GA4685@elstar.local> <4C5C3595.7070606@andybierman.com> <1281113161.5027.70.camel@missotis> In-Reply-To: <1281113161.5027.70.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "netmod@ietf.org" Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 17:07:16 -0000 On 08/06/2010 09:46 AM, Ladislav Lhotka wrote: > Andy Bierman píše v Pá 06. 08. 2010 v 09:17 -0700: >> On 08/06/2010 09:06 AM, Juergen Schoenwaelder wrote: >>> On Fri, Aug 06, 2010 at 05:20:06PM +0200, Ladislav Lhotka wrote: >>>> Juergen Schoenwaelder p????e v P?? 06. 08. 2010 v 16:43 +0200: >>>>> On Fri, Aug 06, 2010 at 04:28:59PM +0200, Ladislav Lhotka wrote: >>>>> >>>>>> 1. You only have one revision covering the entire history of the module. >>>>>> I would expect at least one revision of the module for each revision of >>>>>> the I-D. >>>>> >>>>> I think we decided to follow the SMIv2 model (this is my understanding >>>>> of section 4.6 in the YANG usage document) where a revision is used to >>>>> track "published" modules, where "published" means published as RFC >>>>> (or published by a vendor by shipping it with their hard-/software. >>>>> So I expect only one revision clause which just states that this is >>>>> the initial revision. >>>> >>>> Well, the last paragraph of section 4.7 in >>>> draft-ietf-netmod-yang-usage-09 is IMO quite clear: >>>> >>>> "It is acceptable to reuse the same revision statement within >>>> unpublished versions (i.e., Internet-Drafts), but the revision date >>>> MUST be updated to a higher value each time the Internet-Draft is re- >>>> published." >>>> >>>> I think this is appropriate since even an I-D is a form of publication, >>>> and may actually get implemented, so it seems helpful to state clearly >>>> the revision history. >>> >>> I disagree. The product of a WG is the RFC and while there is value in >>> documenting the differences between subsequent RFCs for the users of >>> RFCs, I do not see the need to document for the users of RFCs the >>> differences between working documents. We should not encourage people >>> to actually ship implementations of I-Ds. >>> >> >> I agree this is a slippery slope, but we want to encourage early implementation, >> so we can find the bugs ASAP. This also applies to readers of the extracted >> YANG module, who want to know if the work-in-progress changed at all. >> >> Vendors are going to ship I-Ds at their peril. >> If the revision date is updated, YANG tools can easily >> deal with new and old revisions. Also, opensource projects >> may be intended to support IETF work-in-progress, so they >> are harmed by improper updating of the revision date. > > Actually, my comment was not about improper updating of the revision > date - every revision of that I-D in fact uses a new revision date for > the module - but rather about the practice of "forgetting" the old > revisions and moving all descriptions from the old revisions to the most > recent one. > > I would prefer to keep the old revision info intact to be able to > clearly see the revision in which each change happened. > IMO this is not needed because the I-D already has a change log section. > Lada > Andy From mbj@tail-f.com Mon Aug 9 13:55:53 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3D33A68B5 for ; Mon, 9 Aug 2010 13:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] 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 J00aOfzyxux0 for ; Mon, 9 Aug 2010 13:55:52 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C3BD83A67B7 for ; Mon, 9 Aug 2010 13:55:52 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 00411616008; Mon, 9 Aug 2010 22:56:20 +0200 (CEST) Date: Mon, 09 Aug 2010 22:56:20 +0200 (CEST) Message-Id: <20100809.225620.48375620.mbj@tail-f.com> To: muenz@net.in.tum.de From: Martin Bjorklund In-Reply-To: <4C580765.5060100@net.in.tum.de> References: <4C580765.5060100@net.in.tum.de> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 20:55:53 -0000 Hi, Gerhard Muenz wrote: > > Dear all, > > In the IPFIX WG, we will have a second WGLC for > draft-ietf-ipfix-configuration-model-07. > > It would be nice if some YANG experts could have a look at the document, > too. > > The YANG module was validated with pyang and seems to be correct. > Nevertheless, you might have further comments. I have done a very brief review, but I won't have time in the very near future to do a deeper review, so I thought I should send what I had: 1. IMO, there should be one (1) revision statement, which should not contain the history of all drafts; it should simple state that this is the initial revision. 2. I agree with Juergen that it might be a good idea to use dash-style-names instead of loCamelCase, in order to have a consistent IETF style. 3. /ipfix/collectingProcess/exportingProcess is a leafref to /ipfix/exportingProcess/name. exportingProcess is optional based on the 'exporter' feature. Maybe /ipfix/collectingProcess/exportingProcess also should have "if-feature exporter;"? 4. Ditto for /ipfix/collectingProcess/exportingProcess. 5. In the when expressions, identityref values should have a prefix. E.g. when "../cacheMode != 'immediate'" { should be when "../cacheMode != 'ipfix:immediate'" { (this is actually not clear from the YANG spec...) 6. The leaf ipfixVersion in grouping commonExporterParameters and grouping fileWriterParameters uses a default value of "10". These leafs should probably have a reference statement. /martin From ietf@andybierman.com Mon Aug 9 15:09:08 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF603A6949 for ; Mon, 9 Aug 2010 15:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] 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 EsuQGGW6V7dE for ; Mon, 9 Aug 2010 15:09:07 -0700 (PDT) Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54]) by core3.amsl.com (Postfix) with ESMTP id 9702E3A68EC for ; Mon, 9 Aug 2010 15:09:06 -0700 (PDT) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o79M9ex9021470 for ; Mon, 9 Aug 2010 18:09:40 -0400 Authentication-Results: cm-omr9 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [173.151.105.24] ([173.151.105.24:49752] helo=[173.151.105.24]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 5D/FD-23668-3AC706C4; Mon, 09 Aug 2010 18:09:40 -0400 To: "=?utf-8?B?TWFydGluIEJqb3JrbHVuZA==?=" , muenz@net.in.tum.de Message-ID: <5D.FD.23668.3AC706C4@cm-omr9> From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Mon, 09 Aug 2010 15:09:54 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1_1281391794838" Cc: netmod@ietf.org Subject: Re: [netmod] =?utf-8?q?Feedback_on_draft-ietf-ipfix-configuration-mod?= =?utf-8?q?el-07?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 22:09:08 -0000 ------=_Part_1_1281391794838 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksCgpJdCBpcyBhIGJpZyBkZWFsIHRvIGNoYW5nZSBhbGwgdGhlIGNhbWVsTmFtZXMgdG8gZGFz aGVkLQpuYW1lcyAuCklNTywgYXMgbG9uZyBhcyB0aGUgdXNhZ2UgaXMgc2VsZiBjb25zaXN0ZW50 LCB0aGF0IGlzIG9rLiAKVGhlIG5ldyBkYXNoZXMgYXJlIG5vdCBjb25zaXN0ZW50IHdpdGggU01J IG5hbWVzLgoKQW5keQoKLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9tOiAiTWFydGluIEJq b3JrbHVuZCIgPG1iakB0YWlsLWYuY29tPgpEYXRlOiBNb24sIEF1ZyA5LCAyMDEwIDEzOjU2ClN1 YmplY3Q6IFtuZXRtb2RdIEZlZWRiYWNrIG9uIGRyYWZ0LWlldGYtaXBmaXgtY29uZmlndXJhdGlv bi1tb2RlbC0wNwpUbzogPG11ZW56QG5ldC5pbi50dW0uZGU+CkNjOiA8bmV0bW9kQGlldGYub3Jn PgoKCkhpLAoKR2VyaGFyZCBNdWVueiA8bXVlbnpAbmV0LmluLnR1bS5kZT4gd3JvdGU6Cj4gCj4g RGVhciBhbGwsCj4gCj4gSW4gdGhlIElQRklYIFdHLCB3ZSB3aWxsIGhhdmUgYSBzZWNvbmQgV0dM QyBmb3IKPiBkcmFmdC1pZXRmLWlwZml4LWNvbmZpZ3VyYXRpb24tbW9kZWwtMDcuCj4gCj4gSXQg d291bGQgYmUgbmljZSBpZiBzb21lIFlBTkcgZXhwZXJ0cyBjb3VsZCBoYXZlIGEgbG9vayBhdCB0 aGUgZG9jdW1lbnQsCj4gdG9vLgo+IAo+IFRoZSBZQU5HIG1vZHVsZSB3YXMgdmFsaWRhdGVkIHdp dGggcHlhbmcgYW5kIHNlZW1zIHRvIGJlIGNvcnJlY3QuCj4gTmV2ZXJ0aGVsZXNzLCB5b3UgbWln aHQgaGF2ZSBmdXJ0aGVyIGNvbW1lbnRzLgoKSSBoYXZlIGRvbmUgYSB2ZXJ5IGJyaWVmIHJldmll dywgYnV0IEkgd29uJ3QgaGF2ZSB0aW1lIGluIHRoZSB2ZXJ5Cm5lYXIgZnV0dXJlIHRvIGRvIGEg ZGVlcGVyIHJldmlldywgc28gSSB0aG91Z2h0IEkgc2hvdWxkIHNlbmQgd2hhdCBJCmhhZDoKCjEu ICBJTU8sIHRoZXJlIHNob3VsZCBiZSBvbmUgKDEpIHJldmlzaW9uIHN0YXRlbWVudCwgd2hpY2gg c2hvdWxkIG5vdAogICAgY29udGFpbiB0aGUgaGlzdG9yeSBvZiBhbGwgZHJhZnRzOyBpdCBzaG91 bGQgc2ltcGxlIHN0YXRlIHRoYXQKICAgIHRoaXMgaXMgdGhlIGluaXRpYWwgcmV2aXNpb24uCgoK Mi4gIEkgYWdyZWUgd2l0aCBKdWVyZ2VuIHRoYXQgaXQgbWlnaHQgYmUgYSBnb29kIGlkZWEgdG8g dXNlCiAgICBkYXNoLXN0eWxlLW5hbWVzIGluc3RlYWQgb2YgbG9DYW1lbENhc2UsIGluIG9yZGVy IHRvIGhhdmUgYQogICAgY29uc2lzdGVudCBJRVRGIHN0eWxlLgoKCjMuICAvaXBmaXgvY29sbGVj dGluZ1Byb2Nlc3MvZXhwb3J0aW5nUHJvY2VzcyBpcyBhIGxlYWZyZWYgdG8KICAgIC9pcGZpeC9l eHBvcnRpbmdQcm9jZXNzL25hbWUuICBleHBvcnRpbmdQcm9jZXNzIGlzIG9wdGlvbmFsIGJhc2Vk CiAgICBvbiB0aGUgJ2V4cG9ydGVyJyBmZWF0dXJlLiAgTWF5YmUKICAgIC9pcGZpeC9jb2xsZWN0 aW5nUHJvY2Vzcy9leHBvcnRpbmdQcm9jZXNzIGFsc28gc2hvdWxkIGhhdmUKICAgICJpZi1mZWF0 dXJlIGV4cG9ydGVyOyI/CgoKNC4gIERpdHRvIGZvciAvaXBmaXgvY29sbGVjdGluZ1Byb2Nlc3Mv ZXhwb3J0aW5nUHJvY2Vzcy4KCgo1LiAgSW4gdGhlIHdoZW4gZXhwcmVzc2lvbnMsIGlkZW50aXR5 cmVmIHZhbHVlcyBzaG91bGQgaGF2ZSBhIHByZWZpeC4KICAgIEUuZy4gCiAgICAgICB3aGVuICIu Li9jYWNoZU1vZGUgIT0gJ2ltbWVkaWF0ZSciIHsKICAgIHNob3VsZCBiZQogICAgICAgd2hlbiAi Li4vY2FjaGVNb2RlICE9ICdpcGZpeDppbW1lZGlhdGUnIiB7CgogICAgKHRoaXMgaXMgYWN0dWFs bHkgbm90IGNsZWFyIGZyb20gdGhlIFlBTkcgc3BlYy4uLikKCgo2LiAgVGhlIGxlYWYgaXBmaXhW ZXJzaW9uIGluIGdyb3VwaW5nIGNvbW1vbkV4cG9ydGVyUGFyYW1ldGVycyBhbmQKICAgIGdyb3Vw aW5nIGZpbGVXcml0ZXJQYXJhbWV0ZXJzIHVzZXMgYSBkZWZhdWx0IHZhbHVlIG9mICIxMCIuICBU aGVzZQogICAgbGVhZnMgc2hvdWxkIHByb2JhYmx5IGhhdmUgYSByZWZlcmVuY2Ugc3RhdGVtZW50 LgoKCgovbWFydGluCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCgo= ------=_Part_1_1281391794838 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksPGJyPjxicj5JdCBpcyBhIGJpZyBkZWFsIHRvIGNoYW5nZSBhbGwgdGhlIGNhbWVsTmFtZXMg dG8gZGFzaGVkLTxicj5uYW1lcyAuPGJyPklNTywgYXMgbG9uZyBhcyB0aGUgdXNhZ2UgaXMgc2Vs ZiBjb25zaXN0ZW50LCB0aGF0IGlzIG9rLiA8YnI+VGhlIG5ldyBkYXNoZXMgYXJlIG5vdCBjb25z aXN0ZW50IHdpdGggU01JIG5hbWVzLjxicj48YnI+QW5keTxicj48YnI+LS0tLS0gUmVwbHkgbWVz c2FnZSAtLS0tLTxicj5Gcm9tOiAmcXVvdDtNYXJ0aW4gQmpvcmtsdW5kJnF1b3Q7ICZsdDttYmpA dGFpbC1mLmNvbSZndDs8YnI+RGF0ZTogTW9uLCBBdWcgOSwgMjAxMCAxMzo1Njxicj5TdWJqZWN0 OiBbbmV0bW9kXSBGZWVkYmFjayBvbiBkcmFmdC1pZXRmLWlwZml4LWNvbmZpZ3VyYXRpb24tbW9k ZWwtMDc8YnI+VG86ICZsdDttdWVuekBuZXQuaW4udHVtLmRlJmd0Ozxicj5DYzogJmx0O25ldG1v ZEBpZXRmLm9yZyZndDs8YnI+PGJyPjxicj5IaSw8YnI+PGJyPkdlcmhhcmQgTXVlbnogJmx0O211 ZW56QG5ldC5pbi50dW0uZGUmZ3Q7IHdyb3RlOjxicj4mZ3Q7IDxicj4mZ3Q7IERlYXIgYWxsLDxi cj4mZ3Q7IDxicj4mZ3Q7IEluIHRoZSBJUEZJWCBXRywgd2Ugd2lsbCBoYXZlIGEgc2Vjb25kIFdH TEMgZm9yPGJyPiZndDsgZHJhZnQtaWV0Zi1pcGZpeC1jb25maWd1cmF0aW9uLW1vZGVsLTA3Ljxi cj4mZ3Q7IDxicj4mZ3Q7IEl0IHdvdWxkIGJlIG5pY2UgaWYgc29tZSBZQU5HIGV4cGVydHMgY291 bGQgaGF2ZSBhIGxvb2sgYXQgdGhlIGRvY3VtZW50LDxicj4mZ3Q7IHRvby48YnI+Jmd0OyA8YnI+ Jmd0OyBUaGUgWUFORyBtb2R1bGUgd2FzIHZhbGlkYXRlZCB3aXRoIHB5YW5nIGFuZCBzZWVtcyB0 byBiZSBjb3JyZWN0Ljxicj4mZ3Q7IE5ldmVydGhlbGVzcywgeW91IG1pZ2h0IGhhdmUgZnVydGhl ciBjb21tZW50cy48YnI+PGJyPkkgaGF2ZSBkb25lIGEgdmVyeSBicmllZiByZXZpZXcsIGJ1dCBJ IHdvbiYjMzk7dCBoYXZlIHRpbWUgaW4gdGhlIHZlcnk8YnI+bmVhciBmdXR1cmUgdG8gZG8gYSBk ZWVwZXIgcmV2aWV3LCBzbyBJIHRob3VnaHQgSSBzaG91bGQgc2VuZCB3aGF0IEk8YnI+aGFkOjxi cj48YnI+MS4gJm5ic3A7SU1PLCB0aGVyZSBzaG91bGQgYmUgb25lICgxKSByZXZpc2lvbiBzdGF0 ZW1lbnQsIHdoaWNoIHNob3VsZCBub3Q8YnI+ICZuYnNwOyAmbmJzcDtjb250YWluIHRoZSBoaXN0 b3J5IG9mIGFsbCBkcmFmdHM7IGl0IHNob3VsZCBzaW1wbGUgc3RhdGUgdGhhdDxicj4gJm5ic3A7 ICZuYnNwO3RoaXMgaXMgdGhlIGluaXRpYWwgcmV2aXNpb24uPGJyPjxicj48YnI+Mi4gJm5ic3A7 SSBhZ3JlZSB3aXRoIEp1ZXJnZW4gdGhhdCBpdCBtaWdodCBiZSBhIGdvb2QgaWRlYSB0byB1c2U8 YnI+ICZuYnNwOyAmbmJzcDtkYXNoLXN0eWxlLW5hbWVzIGluc3RlYWQgb2YgbG9DYW1lbENhc2Us IGluIG9yZGVyIHRvIGhhdmUgYTxicj4gJm5ic3A7ICZuYnNwO2NvbnNpc3RlbnQgSUVURiBzdHls ZS48YnI+PGJyPjxicj4zLiAmbmJzcDsvaXBmaXgvY29sbGVjdGluZ1Byb2Nlc3MvZXhwb3J0aW5n UHJvY2VzcyBpcyBhIGxlYWZyZWYgdG88YnI+ICZuYnNwOyAmbmJzcDsvaXBmaXgvZXhwb3J0aW5n UHJvY2Vzcy9uYW1lLiAmbmJzcDtleHBvcnRpbmdQcm9jZXNzIGlzIG9wdGlvbmFsIGJhc2VkPGJy PiAmbmJzcDsgJm5ic3A7b24gdGhlICYjMzk7ZXhwb3J0ZXImIzM5OyBmZWF0dXJlLiAmbmJzcDtN YXliZTxicj4gJm5ic3A7ICZuYnNwOy9pcGZpeC9jb2xsZWN0aW5nUHJvY2Vzcy9leHBvcnRpbmdQ cm9jZXNzIGFsc28gc2hvdWxkIGhhdmU8YnI+ICZuYnNwOyAmbmJzcDsmcXVvdDtpZi1mZWF0dXJl IGV4cG9ydGVyOyZxdW90Oz88YnI+PGJyPjxicj40LiAmbmJzcDtEaXR0byBmb3IgL2lwZml4L2Nv bGxlY3RpbmdQcm9jZXNzL2V4cG9ydGluZ1Byb2Nlc3MuPGJyPjxicj48YnI+NS4gJm5ic3A7SW4g dGhlIHdoZW4gZXhwcmVzc2lvbnMsIGlkZW50aXR5cmVmIHZhbHVlcyBzaG91bGQgaGF2ZSBhIHBy ZWZpeC48YnI+ICZuYnNwOyAmbmJzcDtFLmcuIDxicj4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgd2hl biAmcXVvdDsuLi9jYWNoZU1vZGUgIT0gJiMzOTtpbW1lZGlhdGUmIzM5OyZxdW90OyB7PGJyPiAm bmJzcDsgJm5ic3A7c2hvdWxkIGJlPGJyPiAmbmJzcDsgJm5ic3A7ICZuYnNwOyB3aGVuICZxdW90 Oy4uL2NhY2hlTW9kZSAhPSAmIzM5O2lwZml4OmltbWVkaWF0ZSYjMzk7JnF1b3Q7IHs8YnI+PGJy PiAmbmJzcDsgJm5ic3A7KHRoaXMgaXMgYWN0dWFsbHkgbm90IGNsZWFyIGZyb20gdGhlIFlBTkcg c3BlYy4uLik8YnI+PGJyPjxicj42LiAmbmJzcDtUaGUgbGVhZiBpcGZpeFZlcnNpb24gaW4gZ3Jv dXBpbmcgY29tbW9uRXhwb3J0ZXJQYXJhbWV0ZXJzIGFuZDxicj4gJm5ic3A7ICZuYnNwO2dyb3Vw aW5nIGZpbGVXcml0ZXJQYXJhbWV0ZXJzIHVzZXMgYSBkZWZhdWx0IHZhbHVlIG9mICZxdW90OzEw JnF1b3Q7LiAmbmJzcDtUaGVzZTxicj4gJm5ic3A7ICZuYnNwO2xlYWZzIHNob3VsZCBwcm9iYWJs eSBoYXZlIGEgcmVmZXJlbmNlIHN0YXRlbWVudC48YnI+PGJyPjxicj48YnI+L21hcnRpbjxicj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5uZXRtb2Qg bWFpbGluZyBsaXN0PGJyPm5ldG1vZEBpZXRmLm9yZzxicj48YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJyPjxicj48YnI+PGJyPg== ------=_Part_1_1281391794838-- From j.schoenwaelder@jacobs-university.de Mon Aug 9 23:26:25 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBF7D3A680D for ; Mon, 9 Aug 2010 23:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.679 X-Spam-Level: X-Spam-Status: No, score=-101.679 tagged_above=-999 required=5 tests=[AWL=0.570, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axLgd0GXklSD for ; Mon, 9 Aug 2010 23:26:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B1A443A67FA for ; Mon, 9 Aug 2010 23:26:24 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1AB6C0008; Tue, 10 Aug 2010 08:26:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XDayhq5Ffdvv; Tue, 10 Aug 2010 08:26:58 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 97602C0006; Tue, 10 Aug 2010 08:26:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C7E0E1429F89; Tue, 10 Aug 2010 08:26:53 +0200 (CEST) Date: Tue, 10 Aug 2010 08:26:53 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100810062653.GA30286@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "muenz@net.in.tum.de" , "netmod@ietf.org" References: <5D.FD.23668.3AC706C4@cm-omr9> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D.FD.23668.3AC706C4@cm-omr9> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" , "muenz@net.in.tum.de" Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 06:26:25 -0000 On Tue, Aug 10, 2010 at 12:09:54AM +0200, Andy Bierman wrote: > Hi, > > It is a big deal to change all the camelNames to dashed- names . > IMO, as long as the usage is self consistent, that is ok. Its going to become a mess if we have no common coding rules. > The new dashes are not consistent with SMI names. This can be considered a feature. Anyway, we have settled on the writing style for the YANG keywords and the core modules a long time ago. I see little value to go back reiterating the discussion. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From muenz@net.in.tum.de Tue Aug 10 01:04:29 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9EE3A6A70 for ; Tue, 10 Aug 2010 01:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=0.783, 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 IUjV-0uH-AHe for ; Tue, 10 Aug 2010 01:04:28 -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 2E8A83A69CA for ; Tue, 10 Aug 2010 01:04:27 -0700 (PDT) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 4C8E8208C318 for ; Tue, 10 Aug 2010 10:04:51 +0200 (CEST) Message-ID: <4C610855.7010609@net.in.tum.de> Date: Tue, 10 Aug 2010 10:05:41 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: NETMOD Working Group References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 08:04:29 -0000 Hi Lada, Thank you for your comments. > Hi Gerhard, > > I have the following comments/questions: > > 1. You only have one revision covering the entire history of the module. > I would expect at least one revision of the module for each revision of > the I-D. The only official (and hopefully bug-free) module will be the one published in the RFC. The change log text only exists to keep track of changes during the development process. It will be delete in the RFC in order not to confuse any user. > 2. Given the large number of declared features (17), perhaps it would be > better to have multiple modules, e.g. separate modules for "meter", > "exporter", "collector" and "psamp". Have you considered this option? I have not thought about this. There are a lot of dependencies and restrictions which would then be defined across module boundaries. Therefore, I'm not sure whether your suggestion works. Maybe you can sketch how you would split the configuration. Gerhard From bertietf@bwijnen.net Tue Aug 10 03:06:13 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9C23A68AB; Tue, 10 Aug 2010 03:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.236 X-Spam-Level: X-Spam-Status: No, score=-99.236 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DMqSsK-13Cg; Tue, 10 Aug 2010 03:06:12 -0700 (PDT) Received: from relay.versatel.net (relay55.tele2.vuurwerk.nl [62.250.3.55]) by core3.amsl.com (Postfix) with ESMTP id D88213A68D0; Tue, 10 Aug 2010 03:06:11 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1OiljJ-0006Er-0j; Tue, 10 Aug 2010 12:06:45 +0200 Message-ID: <8ED2319ABA69470A9736F0F737146B09@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" , "NETMOD Working Group" Date: Tue, 10 Aug 2010 12:05:55 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18197 Subject: [netmod] Fw: "Recent Advances in IETF Standards" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 10:06:13 -0000 I would think that it might be good to write an article on NETCONF and YANG. But I do not have the time. So any (small set of) volunteers? Bert ----- Original Message ----- From: "Henning Schulzrinne" To: "IETF discussion list" Sent: Tuesday, August 10, 2010 11:57 AM Subject: CFP: "Recent Advances in IETF Standards" I wouldn't normally post a CFP here, but the topic is uniquely relevant to the list. Henning ================================================================== Call For Papers - IEEE Communications Magazine Feature Topic on "Recent Advances in IETF Standards" ================================================================== The mission of the Internet engineering Task Force (IETF) is to "make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet". This is a continuous process driving and driven by the rapid evolution of the Internet. Protocols and other technical standards developed by the IETF are fundamental building blocks of the networked society. This feature topic will give an overview of recent achievements in creating standards that soon will have an impact on design, use and management of the Internet. We welcome tutorial style papers that describe new IETF standards as well as research papers presenting results that had an impact on the standardization process or that investigate the expected impact of recent standards. All submissions should be written to be understandable and appealing to a general audience. Areas of Interest ================= Areas of interest include standards track work that has been completed recently or will be completed soon from all areas of the IETF including but not limited to - Emergency service - Location based services - Internationalization - Peer-to-peer communication - Network address translation - Congestion control - IP6 transition - Mobility and mobility management - Secure DNS - Routing security - Locator/Identifier Separation - MPLS Transport Profile - Better-than-nothing security - Network configuration with XML - Internet metrics and measurement Schedule ======== Full paper submission: October 1, 2010 Author notifications: December 17, 2010 Manuscripts in final form: January 27, 2011 Publication date: April 2011 Submission Instructions ======================= Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the field. Authors must follow the IEEE Communications Magazine's guidelines for preparation of the manuscript. Complete guidelines for prospective authors can be found at http://www.comsoc.org/livepubs/ci1/info/sub_guidelines.html. All articles to be considered for publication must be submitted through the IEEE Manuscript Central (http://commag-ieee.manuscriptcentral.com). Guest Editors ============= Juergen Quittek, NEC Europe Ltd., quittek@neclab.eu Henning Schulzrinne, Columbia University, hgs@cs.columbia.edu Joe Touch, Postel Center, USC/ISI, touch@isi.edu _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From j.schoenwaelder@jacobs-university.de Tue Aug 10 03:19:12 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0683A6807; Tue, 10 Aug 2010 03:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.692 X-Spam-Level: X-Spam-Status: No, score=-101.692 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWOYijh-eqhq; Tue, 10 Aug 2010 03:19:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 204413A686E; Tue, 10 Aug 2010 03:19:11 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C6276C0008; Tue, 10 Aug 2010 12:19:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iP3jYg88Ra-9; Tue, 10 Aug 2010 12:19:45 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D798CC0006; Tue, 10 Aug 2010 12:19:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 96026142B2F1; Tue, 10 Aug 2010 12:19:41 +0200 (CEST) Date: Tue, 10 Aug 2010 12:19:41 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20100810101941.GB31333@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , Netconf , NETMOD Working Group References: <8ED2319ABA69470A9736F0F737146B09@BertLaptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ED2319ABA69470A9736F0F737146B09@BertLaptop> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Netconf , NETMOD Working Group Subject: Re: [netmod] Fw: "Recent Advances in IETF Standards" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 10:19:12 -0000 On Tue, Aug 10, 2010 at 12:05:55PM +0200, Bert Wijnen (IETF) wrote: > I would think that it might be good to write an article on > NETCONF and YANG. > > But I do not have the time. So any (small set of) volunteers? This paper has already been written, likely to appear in the September issue (this was the last thing I heard - but they tend to reschedule papers sometimes and as long as YANG has no RFC number I won't complain ;-). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Tue Aug 10 05:29:26 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01E9A3A684C for ; Tue, 10 Aug 2010 05:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.128 X-Spam-Level: X-Spam-Status: No, score=-1.128 tagged_above=-999 required=5 tests=[AWL=-1.128, BAYES_50=0.001, 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 MAGJvs4+kE0y for ; Tue, 10 Aug 2010 05:29:25 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id A4DC93A6834 for ; Tue, 10 Aug 2010 05:29:24 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 173F82CDE05C for ; Tue, 10 Aug 2010 14:29:58 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <4C610855.7010609@net.in.tum.de> References: <4C610855.7010609@net.in.tum.de> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 10 Aug 2010 14:29:56 +0200 Message-ID: <1281443396.24563.30.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 12:29:26 -0000 Gerhard Muenz píše v Út 10. 08. 2010 v 10:05 +0200: > Hi Lada, > > Thank you for your comments. > > > Hi Gerhard, > > > > I have the following comments/questions: > > > > 1. You only have one revision covering the entire history of the module. > > I would expect at least one revision of the module for each revision of > > the I-D. > > The only official (and hopefully bug-free) module will be the one > published in the RFC. > > The change log text only exists to keep track of changes during the > development process. It will be delete in the RFC in order not to > confuse any user. OK, fair enough, this is clearly the majority opinion. > > > 2. Given the large number of declared features (17), perhaps it would be > > better to have multiple modules, e.g. separate modules for "meter", > > "exporter", "collector" and "psamp". Have you considered this option? > > I have not thought about this. > > There are a lot of dependencies and restrictions which would then be > defined across module boundaries. Therefore, I'm not sure whether your > suggestion works. > > Maybe you can sketch how you would split the configuration. You can get the respective data models by turning on the features "collector", "meter" and "exporter" selectively, so any must-have dependencies among them would be a problem anyway. module collector { ... list collectingProcess { ... } } module meter { ... list observationPoint { ... } list selectionProcess { ... } list cache { ... } } module exporter { ... list exportingProcess { ... } } The only thing you would lose this way is the top-level "ipfix" container, right? In order to keep it, you could also have a wrapper module "ipfix" and define the three modules above as augments of the top-level element, e.g. module collector { ... import ipfix { prefix ipfix; } augment "/ipfix:ipfix" { list collectingProcess { ... } } } But, in my opinion, the original "unrooted" modules should be just fine. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Aug 10 06:15:21 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A2C3A68E3 for ; Tue, 10 Aug 2010 06:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 WofpXTE5BhhG for ; Tue, 10 Aug 2010 06:15:20 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 470F13A6961 for ; Tue, 10 Aug 2010 06:15:19 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 42F8B616001; Tue, 10 Aug 2010 15:15:53 +0200 (CEST) Date: Tue, 10 Aug 2010 15:15:52 +0200 (CEST) Message-Id: <20100810.151552.12711230.mbj@tail-f.com> To: muenz@net.in.tum.de From: Martin Bjorklund In-Reply-To: <4C610855.7010609@net.in.tum.de> References: <4C610855.7010609@net.in.tum.de> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 13:15:21 -0000 Gerhard Muenz wrote: > > Hi Lada, > > 2. Given the large number of declared features (17), perhaps it would be > > better to have multiple modules, e.g. separate modules for "meter", > > "exporter", "collector" and "psamp". Have you considered this option? > > I have not thought about this. > > There are a lot of dependencies and restrictions which would then be > defined across module boundaries. Therefore, I'm not sure whether your > suggestion works. I think one module for ipfix is fine. I do not understand what problem is solved by splitting into more modules. If the problem is the size of the module, or that individual parts may be updated individually, you could split the module into submodules, but as I said, I do not think it is necessary. /martin From lhotka@cesnet.cz Tue Aug 10 06:47:16 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A17B3A6835 for ; Tue, 10 Aug 2010 06:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.313, 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 SFNGskOSOQ0G for ; Tue, 10 Aug 2010 06:47:15 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 4B3853A6407 for ; Tue, 10 Aug 2010 06:47:15 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 3D8932CDE05B for ; Tue, 10 Aug 2010 15:47:49 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20100810.151552.12711230.mbj@tail-f.com> References: <4C610855.7010609@net.in.tum.de> <20100810.151552.12711230.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 10 Aug 2010 15:47:47 +0200 Message-ID: <1281448068.24563.58.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 13:47:16 -0000 Martin Bjorklund píše v Út 10. 08. 2010 v 15:15 +0200: > Gerhard Muenz wrote: > > > > Hi Lada, > > > 2. Given the large number of declared features (17), perhaps it would be > > > better to have multiple modules, e.g. separate modules for "meter", > > > "exporter", "collector" and "psamp". Have you considered this option? > > > > I have not thought about this. > > > > There are a lot of dependencies and restrictions which would then be > > defined across module boundaries. Therefore, I'm not sure whether your > > suggestion works. > > I think one module for ipfix is fine. I do not understand what > problem is solved by splitting into more modules. Smaller relatively independent modules are IMO easier to understand. The present approach with features is like a C source file with a lot of ifdefs. From the practical point of view, flow-handling devices most often implement either the meter&exporter part or the collector part. > > If the problem is the size of the module, or that individual parts may > be updated individually, you could split the module into submodules, > but as I said, I do not think it is necessary. Using the same logic, someone could start writing an all-encompassing "router" module: module router { ... feature static; feature bgp; feature ospf; ... } I hope we all agree it shouldn't (and won't) be done this way. So what's the difference? Overall size, of course, but the "ipfix" module is quite long, too - its tree representation from pyang is 8 pages long. Lada > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Aug 10 08:21:09 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 935683A6A82 for ; Tue, 10 Aug 2010 08:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.703 X-Spam-Level: X-Spam-Status: No, score=-101.703 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+lZ-dHAPGrs for ; Tue, 10 Aug 2010 08:21:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3E3303A6A80 for ; Tue, 10 Aug 2010 08:21:08 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B9B7AC0015; Tue, 10 Aug 2010 17:21:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Hl22TqdpPVpm; Tue, 10 Aug 2010 17:21:41 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1368FC0018; Tue, 10 Aug 2010 17:21:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D7B01142BC52; Tue, 10 Aug 2010 17:21:37 +0200 (CEST) Date: Tue, 10 Aug 2010 17:21:37 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100810152137.GB33219@elstar.local> Mail-Followup-To: Martin Bjorklund , "muenz@net.in.tum.de" , "netmod@ietf.org" References: <4C610855.7010609@net.in.tum.de> <20100810.151552.12711230.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100810.151552.12711230.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netmod@ietf.org" , "muenz@net.in.tum.de" Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 15:21:09 -0000 On Tue, Aug 10, 2010 at 03:15:52PM +0200, Martin Bjorklund wrote: > Gerhard Muenz wrote: > > > > Hi Lada, > > > 2. Given the large number of declared features (17), perhaps it would be > > > better to have multiple modules, e.g. separate modules for "meter", > > > "exporter", "collector" and "psamp". Have you considered this option? > > > > I have not thought about this. > > > > There are a lot of dependencies and restrictions which would then be > > defined across module boundaries. Therefore, I'm not sure whether your > > suggestion works. > > I think one module for ipfix is fine. I do not understand what > problem is solved by splitting into more modules. Same feeling here. Perhaps there is also an implicit request for tools that can help with making the feature partitions easier to inspect and analyze. The downside of many modules is the number of namespaces that need to be dealt with - especially by humans (machines have it easier to sort out many namespaces). Another level of modularization are submodules but it is unclear whether or how they work in the IETF since we lack operational experience with them. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Tue Aug 10 08:42:25 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA533A6884 for ; Tue, 10 Aug 2010 08:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] 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 sjDuWbrCp2A8 for ; Tue, 10 Aug 2010 08:42:24 -0700 (PDT) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by core3.amsl.com (Postfix) with ESMTP id 447573A67A1 for ; Tue, 10 Aug 2010 08:42:24 -0700 (PDT) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o7AFguLW012647 for ; Tue, 10 Aug 2010 11:42:56 -0400 Authentication-Results: cm-omr9 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [184.192.36.190] ([184.192.36.190:40953] helo=[184.192.36.190]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id E0/7C-23668-E73716C4; Tue, 10 Aug 2010 11:42:56 -0400 To: "=?utf-8?B?SnVlcmdlbiBTY2hvZW53YWVsZGVy?=" , "=?utf-8?B?TWFydGluIEJqb3JrbHVuZA==?=" Message-ID: From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Tue, 10 Aug 2010 08:43:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3_1281454989859" Cc: =?utf-8?B?bmV0bW9kQGlldGYub3Jn?= , =?utf-8?B?bXVlbnpAbmV0LmluLnR1bS5kZQ==?= Subject: Re: [netmod] =?utf-8?q?Feedback_on_draft-ietf-ipfix-configuration-mod?= =?utf-8?q?el-07?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 15:42:26 -0000 ------=_Part_3_1281454989859 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksCgpJIGRvIG5vdCB0aGluayB0aGUgbW9kdWxlIG5lZWRzIHRvIGJlIHNwbGl0IHVwLCBvciB0 aGF0IHRoZSBjYW1lbENhc2UgbmVlZHMgdG8gYmUgY2hhbmdlZC4gIE5laXRoZXIgd2lsbCBoZWxw IHNvbWVib2R5IHVuZGVyc3RhbmQgdGhlIGNvbXBsZXhpdHkgb2YgaXBmaXguCgooU2hhbWVsZXNz IHBsdWcpIFRoZSBvcGVuc291cmNlIHlhbmdkdW1wIHByb2dyYW0gY2FuIGdlbmVyYXRlIHRoZSBl eHBhbmRlZCBZQU5HIHdoaWNoIEkgZmluZCBlYXNpZXIgdG8gcmVhZCB0aGFuIGZvbGxvd2luZyB0 aGUgdXNlcyBzdGF0ZW1lbnRzLgoKQW5keQoKCi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS0KRnJv bTogIkp1ZXJnZW4gU2Nob2Vud2FlbGRlciIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVy c2l0eS5kZT4KRGF0ZTogVHVlLCBBdWcgMTAsIDIwMTAgMDg6MjEKU3ViamVjdDogW25ldG1vZF0g RmVlZGJhY2sgb24gZHJhZnQtaWV0Zi1pcGZpeC1jb25maWd1cmF0aW9uLW1vZGVsLTA3ClRvOiAi TWFydGluIEJqb3JrbHVuZCIgPG1iakB0YWlsLWYuY29tPgpDYzogIm5ldG1vZEBpZXRmLm9yZyIg PG5ldG1vZEBpZXRmLm9yZz4sICJtdWVuekBuZXQuaW4udHVtLmRlIiA8bXVlbnpAbmV0LmluLnR1 bS5kZT4KCgpPbiBUdWUsIEF1ZyAxMCwgMjAxMCBhdCAwMzoxNTo1MlBNICswMjAwLCBNYXJ0aW4g QmpvcmtsdW5kIHdyb3RlOgo+IEdlcmhhcmQgTXVlbnogPG11ZW56QG5ldC5pbi50dW0uZGU+IHdy b3RlOgo+ID4gCj4gPiBIaSBMYWRhLAo+ID4gPiAyLiBHaXZlbiB0aGUgbGFyZ2UgbnVtYmVyIG9m IGRlY2xhcmVkIGZlYXR1cmVzICgxNyksIHBlcmhhcHMgaXQgd291bGQgYmUKPiA+ID4gYmV0dGVy IHRvIGhhdmUgbXVsdGlwbGUgbW9kdWxlcywgZS5nLiBzZXBhcmF0ZSBtb2R1bGVzIGZvciAibWV0 ZXIiLAo+ID4gPiAiZXhwb3J0ZXIiLCAiY29sbGVjdG9yIiBhbmQgInBzYW1wIi4gSGF2ZSB5b3Ug Y29uc2lkZXJlZCB0aGlzIG9wdGlvbj8KPiA+IAo+ID4gSSBoYXZlIG5vdCB0aG91Z2h0IGFib3V0 IHRoaXMuCj4gPiAKPiA+IFRoZXJlIGFyZSBhIGxvdCBvZiBkZXBlbmRlbmNpZXMgYW5kIHJlc3Ry aWN0aW9ucyB3aGljaCB3b3VsZCB0aGVuIGJlCj4gPiBkZWZpbmVkIGFjcm9zcyBtb2R1bGUgYm91 bmRhcmllcy4gVGhlcmVmb3JlLCBJJ20gbm90IHN1cmUgd2hldGhlciB5b3VyCj4gPiBzdWdnZXN0 aW9uIHdvcmtzLgo+IAo+IEkgdGhpbmsgb25lIG1vZHVsZSBmb3IgaXBmaXggaXMgZmluZS4gIEkg ZG8gbm90IHVuZGVyc3RhbmQgd2hhdAo+IHByb2JsZW0gaXMgc29sdmVkIGJ5IHNwbGl0dGluZyBp bnRvIG1vcmUgbW9kdWxlcy4KClNhbWUgZmVlbGluZyBoZXJlLiBQZXJoYXBzIHRoZXJlIGlzIGFs c28gYW4gaW1wbGljaXQgcmVxdWVzdCBmb3IgdG9vbHMKdGhhdCBjYW4gaGVscCB3aXRoIG1ha2lu ZyB0aGUgZmVhdHVyZSBwYXJ0aXRpb25zIGVhc2llciB0byBpbnNwZWN0IGFuZAphbmFseXplLgoK VGhlIGRvd25zaWRlIG9mIG1hbnkgbW9kdWxlcyBpcyB0aGUgbnVtYmVyIG9mIG5hbWVzcGFjZXMg dGhhdCBuZWVkIHRvCmJlIGRlYWx0IHdpdGggLSBlc3BlY2lhbGx5IGJ5IGh1bWFucyAobWFjaGlu ZXMgaGF2ZSBpdCBlYXNpZXIgdG8gc29ydApvdXQgbWFueSBuYW1lc3BhY2VzKS4gQW5vdGhlciBs ZXZlbCBvZiBtb2R1bGFyaXphdGlvbiBhcmUgc3VibW9kdWxlcwpidXQgaXQgaXMgdW5jbGVhciB3 aGV0aGVyIG9yIGhvdyB0aGV5IHdvcmsgaW4gdGhlIElFVEYgc2luY2Ugd2UgbGFjawpvcGVyYXRp b25hbCBleHBlcmllbmNlIHdpdGggdGhlbS4KCi9qcyAKCi0tIApKdWVyZ2VuIFNjaG9lbndhZWxk ZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSApQaG9uZTogKzQ5IDQy MSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEsIDI4NzU5IEJyZW1lbiwgR2VybWFueQpG YXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJz aXR5LmRlLz4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K bmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRtb2QKCg== ------=_Part_3_1281454989859 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksPGJyPjxicj5JIGRvIG5vdCB0aGluayB0aGUgbW9kdWxlIG5lZWRzIHRvIGJlIHNwbGl0IHVw LCBvciB0aGF0IHRoZSBjYW1lbENhc2UgbmVlZHMgdG8gYmUgY2hhbmdlZC4gJm5ic3A7TmVpdGhl ciB3aWxsIGhlbHAgc29tZWJvZHkgdW5kZXJzdGFuZCB0aGUgY29tcGxleGl0eSBvZiBpcGZpeC48 YnI+PGJyPihTaGFtZWxlc3MgcGx1ZykgVGhlIG9wZW5zb3VyY2UgeWFuZ2R1bXAgcHJvZ3JhbSBj YW4gZ2VuZXJhdGUgdGhlIGV4cGFuZGVkIFlBTkcgd2hpY2ggSSBmaW5kIGVhc2llciB0byByZWFk IHRoYW4gZm9sbG93aW5nIHRoZSB1c2VzIHN0YXRlbWVudHMuPGJyPjxicj5BbmR5PGJyPjxicj48 YnI+LS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj5Gcm9tOiAmcXVvdDtKdWVyZ2VuIFNjaG9l bndhZWxkZXImcXVvdDsgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZn dDs8YnI+RGF0ZTogVHVlLCBBdWcgMTAsIDIwMTAgMDg6MjE8YnI+U3ViamVjdDogW25ldG1vZF0g RmVlZGJhY2sgb24gZHJhZnQtaWV0Zi1pcGZpeC1jb25maWd1cmF0aW9uLW1vZGVsLTA3PGJyPlRv OiAmcXVvdDtNYXJ0aW4gQmpvcmtsdW5kJnF1b3Q7ICZsdDttYmpAdGFpbC1mLmNvbSZndDs8YnI+ Q2M6ICZxdW90O25ldG1vZEBpZXRmLm9yZyZxdW90OyAmbHQ7bmV0bW9kQGlldGYub3JnJmd0Oywg JnF1b3Q7bXVlbnpAbmV0LmluLnR1bS5kZSZxdW90OyAmbHQ7bXVlbnpAbmV0LmluLnR1bS5kZSZn dDs8YnI+PGJyPjxicj5PbiBUdWUsIEF1ZyAxMCwgMjAxMCBhdCAwMzoxNTo1MlBNICswMjAwLCBN YXJ0aW4gQmpvcmtsdW5kIHdyb3RlOjxicj4mZ3Q7IEdlcmhhcmQgTXVlbnogJmx0O211ZW56QG5l dC5pbi50dW0uZGUmZ3Q7IHdyb3RlOjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBIaSBMYWRh LDxicj4mZ3Q7ICZndDsgJmd0OyAyLiBHaXZlbiB0aGUgbGFyZ2UgbnVtYmVyIG9mIGRlY2xhcmVk IGZlYXR1cmVzICgxNyksIHBlcmhhcHMgaXQgd291bGQgYmU8YnI+Jmd0OyAmZ3Q7ICZndDsgYmV0 dGVyIHRvIGhhdmUgbXVsdGlwbGUgbW9kdWxlcywgZS5nLiBzZXBhcmF0ZSBtb2R1bGVzIGZvciAm cXVvdDttZXRlciZxdW90Oyw8YnI+Jmd0OyAmZ3Q7ICZndDsgJnF1b3Q7ZXhwb3J0ZXImcXVvdDss ICZxdW90O2NvbGxlY3RvciZxdW90OyBhbmQgJnF1b3Q7cHNhbXAmcXVvdDsuIEhhdmUgeW91IGNv bnNpZGVyZWQgdGhpcyBvcHRpb24/PGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IEkgaGF2ZSBu b3QgdGhvdWdodCBhYm91dCB0aGlzLjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBUaGVyZSBh cmUgYSBsb3Qgb2YgZGVwZW5kZW5jaWVzIGFuZCByZXN0cmljdGlvbnMgd2hpY2ggd291bGQgdGhl biBiZTxicj4mZ3Q7ICZndDsgZGVmaW5lZCBhY3Jvc3MgbW9kdWxlIGJvdW5kYXJpZXMuIFRoZXJl Zm9yZSwgSSYjMzk7bSBub3Qgc3VyZSB3aGV0aGVyIHlvdXI8YnI+Jmd0OyAmZ3Q7IHN1Z2dlc3Rp b24gd29ya3MuPGJyPiZndDsgPGJyPiZndDsgSSB0aGluayBvbmUgbW9kdWxlIGZvciBpcGZpeCBp cyBmaW5lLiAmbmJzcDtJIGRvIG5vdCB1bmRlcnN0YW5kIHdoYXQ8YnI+Jmd0OyBwcm9ibGVtIGlz IHNvbHZlZCBieSBzcGxpdHRpbmcgaW50byBtb3JlIG1vZHVsZXMuPGJyPjxicj5TYW1lIGZlZWxp bmcgaGVyZS4gUGVyaGFwcyB0aGVyZSBpcyBhbHNvIGFuIGltcGxpY2l0IHJlcXVlc3QgZm9yIHRv b2xzPGJyPnRoYXQgY2FuIGhlbHAgd2l0aCBtYWtpbmcgdGhlIGZlYXR1cmUgcGFydGl0aW9ucyBl YXNpZXIgdG8gaW5zcGVjdCBhbmQ8YnI+YW5hbHl6ZS48YnI+PGJyPlRoZSBkb3duc2lkZSBvZiBt YW55IG1vZHVsZXMgaXMgdGhlIG51bWJlciBvZiBuYW1lc3BhY2VzIHRoYXQgbmVlZCB0bzxicj5i ZSBkZWFsdCB3aXRoIC0gZXNwZWNpYWxseSBieSBodW1hbnMgKG1hY2hpbmVzIGhhdmUgaXQgZWFz aWVyIHRvIHNvcnQ8YnI+b3V0IG1hbnkgbmFtZXNwYWNlcykuIEFub3RoZXIgbGV2ZWwgb2YgbW9k dWxhcml6YXRpb24gYXJlIHN1Ym1vZHVsZXM8YnI+YnV0IGl0IGlzIHVuY2xlYXIgd2hldGhlciBv ciBob3cgdGhleSB3b3JrIGluIHRoZSBJRVRGIHNpbmNlIHdlIGxhY2s8YnI+b3BlcmF0aW9uYWwg ZXhwZXJpZW5jZSB3aXRoIHRoZW0uPGJyPjxicj4vanMgPGJyPjxicj4tLSA8YnI+SnVlcmdlbiBT Y2hvZW53YWVsZGVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSmFjb2JzIFVu aXZlcnNpdHkgQnJlbWVuIGdHbWJIPGJyPlBob25lOiArNDkgNDIxIDIwMCAzNTg3ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBDYW1wdXMgUmluZyAxLCAyODc1OSBCcmVtZW4sIEdlcm1hbnk8 YnI+RmF4OiAmbmJzcDsgKzQ5IDQyMSAyMDAgMzEwMyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJmx0OzxhIGhyZWY9Imh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIj5odHRwOi8v d3d3LmphY29icy11bml2ZXJzaXR5LmRlLzwvYT4mZ3Q7PGJyPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+bmV0 bW9kQGlldGYub3JnPGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZDwvYT48YnI+PGJyPjxicj48YnI+ ------=_Part_3_1281454989859-- From lhotka@cesnet.cz Tue Aug 10 09:30:25 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30A2D3A6A8B for ; Tue, 10 Aug 2010 09:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.279, 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 wxjPtT6p+NzC for ; Tue, 10 Aug 2010 09:30:20 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 4587D3A6A8C for ; Tue, 10 Aug 2010 09:30:13 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:215:60ff:fead:16dc] (missotis.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 57E442CDE05B for ; Tue, 10 Aug 2010 18:30:45 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <4C580765.5060100@net.in.tum.de> References: <4C580765.5060100@net.in.tum.de> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 10 Aug 2010 18:30:44 +0200 Message-ID: <1281457844.24563.68.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Subject: [netmod] encapsulating containers - Re: Feedback on draft-ietf-ipfix-configuration-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 16:30:25 -0000 Gerhard Muenz píše v Út 03. 08. 2010 v 14:11 +0200: > Dear all, > > In the IPFIX WG, we will have a second WGLC for > draft-ietf-ipfix-configuration-model-07. > > It would be nice if some YANG experts could have a look at the document, > too. Another observation: Perhaps it would be useful to introduce extra containers encapsualting the entries of each list, e.g. container collectingProcesses { list collectingProcess { ... } } As it is now, entries from different lists could be freely interleaved, for instance ... ... ... This is usually not very desirable. Lada > > The YANG module was validated with pyang and seems to be correct. > Nevertheless, you might have further comments. > > We also tried to make the document compliant with the YANG guidelines. > If you think that something is missing or should be changed, please let > me know. > > Thanks a lot for you help, > Gerhard > > > -------- Original Message -------- > Subject: [IPFIX] I-D Action:draft-ietf-ipfix-configuration-model-07.txt > Date: Tue, 3 Aug 2010 04:45:02 -0700 (PDT) > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > CC: ipfix@ietf.org > > 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-07.txt > Pages : 123 > Date : 2010-08-03 > > This document specifies a data model for configuring and monitoring > Selection Processes, Caches, Exporting Processes, and Collecting > Processes of IPFIX and PSAMP compliant Monitoring Devices using the > NETCONF protocol [RFC4741]. The data model is defined using UML > (Unified Modeling Language) class diagrams and formally specified > using YANG [I-D.ietf-netmod-yang]. The configuration data is encoded > in Extensible Markup Language (XML). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-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. > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From root@core3.amsl.com Wed Aug 11 10:45:02 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 53CE03A68A2; Wed, 11 Aug 2010 10:45: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: <20100811174502.53CE03A68A2@core3.amsl.com> Date: Wed, 11 Aug 2010 10:45:02 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-usage-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 17:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Guidelines for Authors and Reviewers of YANG Data Model Documents Author(s) : A. Bierman Filename : draft-ietf-netmod-yang-usage-10.txt Pages : 36 Date : 2010-08-11 This memo provides guidelines for authors and reviewers of standards track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) implementations which utilize YANG data model modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-usage-10.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-netmod-yang-usage-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-11104222.I-D@ietf.org> --NextPart-- From muenz@net.in.tum.de Wed Aug 11 12:15:34 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031D53A67A2 for ; Wed, 11 Aug 2010 12:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.564 X-Spam-Level: X-Spam-Status: No, score=-1.564 tagged_above=-999 required=5 tests=[AWL=0.685, 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 u9n0O4Th4SyY for ; Wed, 11 Aug 2010 12:15: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 5F20F3A6A89 for ; Wed, 11 Aug 2010 12:15:31 -0700 (PDT) Received: from [131.159.20.249] (vpn-3.net.in.tum.de [131.159.20.249]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 111B1208C31A for ; Wed, 11 Aug 2010 21:16:05 +0200 (CEST) Message-ID: <4C62F736.4050900@net.in.tum.de> Date: Wed, 11 Aug 2010 21:17:10 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: netmod@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [netmod] encapsulating containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 19:15:34 -0000 Hi Lada, > Another observation: Perhaps it would be useful to introduce extra > containers encapsualting the entries of each list, e.g. > > container collectingProcesses { > list collectingProcess { > ... > } > } > > As it is now, entries from different lists could be freely interleaved, > for instance > > ... > ... > ... Is this true? There is no choice statement but a sequence of list statements. So, one list should follow the other. List elements should not be interleaved. Anyway, I do not think that interleaving is a problem. Gerhard > > This is usually not very desirable. > > Lada From ietf@andybierman.com Wed Aug 11 12:54:40 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADCA83A67D1 for ; Wed, 11 Aug 2010 12:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] 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 yIdGUyq0lY44 for ; Wed, 11 Aug 2010 12:54:39 -0700 (PDT) Received: from smtp104.sbc.mail.gq1.yahoo.com (smtp104.sbc.mail.gq1.yahoo.com [67.195.15.63]) by core3.amsl.com (Postfix) with SMTP id DA04D3A693B for ; Wed, 11 Aug 2010 12:54:39 -0700 (PDT) Received: (qmail 97694 invoked from network); 11 Aug 2010 19:55:04 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp104.sbc.mail.gq1.yahoo.com with SMTP; 11 Aug 2010 12:55:04 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: kaLbBoEVM1nezjztp82fwcUNfxqdTwcVvN88HhSIkeTciBq H5Q6CBkuXrUWDlyqjGQJdiLevFibj7wXSBCK7pcWk9Ech6rZmGg_uuQ28Mum NjVtvjW4qaNtOruL8iK2mB595QJvhGehHfOD6teiKnjm1Uni6QG.OE5jVtbx y6leypjjJSwO.7WS5Empi4lQJrp_3.P9r37Y8WkH5En.N.JMqtvPcVlTKuJf mW7yqF0Goge7Ak5NIP.E_HJPpIff6JoL.F7M1m30jx.s1nD7RFNRQ_V5RSNu hjPG5 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C630018.4050601@andybierman.com> Date: Wed, 11 Aug 2010 12:55:04 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Gerhard Muenz References: <4C62F736.4050900@net.in.tum.de> In-Reply-To: <4C62F736.4050900@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] encapsulating containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 19:54:40 -0000 On 08/11/2010 12:17 PM, Gerhard Muenz wrote: > > Hi Lada, > >> Another observation: Perhaps it would be useful to introduce extra >> containers encapsualting the entries of each list, e.g. >> >> container collectingProcesses { >> list collectingProcess { >> ... >> } >> } >> >> As it is now, entries from different lists could be freely interleaved, >> for instance >> >> ... >> ... >> ... > > Is this true? There is no choice statement but a sequence of list > statements. So, one list should follow the other. List elements should > not be interleaved. > I agree. A server should be able to find all the siblings no matter what order. It turns out that preserving CLI order is an interesting problem. (Which is interesting if CLI order matters to existing instrumentation.) A use-case could be that the application wants the data processed in document order, or the application is converting CLI to NETCONF on the fly, and grouping all sibling nodes together in the application breaks that use-case. > Gerhard > >> >> This is usually not very desirable. to the server it should not matter, and to the application wrt/ user-ordered data, it may matter. >> >> Lada Andy From david.kessens@nsn.com Wed Aug 11 16:05:31 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24F4D3A6845 for ; Wed, 11 Aug 2010 16:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=-1.509, BAYES_20=-0.74, J_CHICKENPOX_46=0.6, J_CHICKENPOX_65=0.6] 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 MxMFdncBAJRI for ; Wed, 11 Aug 2010 16:05:29 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id ED8B23A680B for ; Wed, 11 Aug 2010 16:05:28 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o7BN62Qf019614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 12 Aug 2010 01:06:02 +0200 Received: from localhost.localdomain ([10.138.49.165]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7BN61bg025276 for ; Thu, 12 Aug 2010 01:06:02 +0200 Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.14.4/8.14.3) with ESMTP id o7BN615U025516 for ; Wed, 11 Aug 2010 16:06:01 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.4/8.14.4/Submit) id o7BN600K025513 for netmod@ietf.org; Wed, 11 Aug 2010 16:06:00 -0700 X-Authentication-Warning: localhost.localdomain: david set sender to david.kessens@nsn.com using -f Date: Wed, 11 Aug 2010 16:06:00 -0700 From: David Kessens To: netmod@ietf.org Message-ID: <20100811230559.GD19813@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-08-17) Subject: [netmod] Approval of minutes 20100820: Draft minutes (v1) of netmod working group session IETF 78 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 23:05:31 -0000 Please see attached for our first version of the minutes. We would like to declare the minutes final if we don't receive any comments (other than editorial corrections) by August 20, 2010. Thanks, David & David --- Draft minutes (v1) of netmod working group session IETF 78 Meeting: IETF 78 Location: MECC, Maastricht, Netherlands TUESDAY, July 27, 2010, 09.00-11.30, Meeting Room: 0.9 Athens WG Chairs: David Kessens (david.kessens at nsn.com) David Partain (david.partain at ericsson.com), not present Jabber: xmpp:netmod at jabber.ietf.org WG URL: http://tools.ietf.org/wg/netmod/ Minute taker: Andy Bierman The working group session started with an status update compared to the netmod working group charter and on all relevant drafts. The working group is a little late compared to the charter but most of the work is now at the IESG level or beyond so the working group is getting close to completion. The chairs expressed their happiness with the work done so far and thanked all participants for getting the work so close to the finish line. The status of the following working group drafts were discussed: 1) Common YANG Data Types http://tools.ietf.org/html/draft-ietf-netmod-yang-types-09 Status: RFC Ed Queue (Juergen Schoenwaelder) no further updates from the authors or comments 2) YANG - A data modeling language for NETCONF http://tools.ietf.org/html/draft-ietf-netmod-yang-13 Status: RFC Ed Queue (Martin Bjorklund) no further updates from the authors or comments 3) YANG Usage Guidelines http://tools.ietf.org/html/draft-ietf-netmod-yang-usage-09 Status: Waiting for AD Go-Ahead Slides: http://www.ietf.org/proceedings/78/slides/netmod-4.pdf (Andy Bierman) Andy Bierman discussed the current status and updates since last meeting: - updated details from Gen-ART review - should security guidelines be online or in doc [ put current text in draft; pointer to WEB; note that WEB is normative] - mandatory=false; config=false [ put note that data model writer needs to clarify conditions for server implementation; object semantics may make it clear what to do; if not text should be present to clarify conditions; 3.4 NETMOD Architecture http://tools.ietf.org/html/draft-ietf-netmod-arch-07 Status: IETF Last Call Requested (Phil Shafer) no further updates from the authors or comments 3.5 Mapping of YANG to DSDL http://tools.ietf.org/html/draft-ietf-netmod-dsdl-map-06 Status: AD Evaluation Slides: http://www.ietf.org/proceedings/78/slides/netmod-0.pdf (Ladislav Lhotka) Ladislav Lhotka discussed the current status and updates since last meeting: - WGLC and external review changes - list of terms added - terminology cleanup - simplified the mapping procedure - implementation in pyang tool (yang2dsdl) is now up to date with the draft - DSDL tutorial added - see www.yang-central.org for details - Issue brought up by Dan Romascanu: there is a normative reference to an Informational RFC - needs to be changed/dealt with by calling it out in Last Call message After the working group drafts, the status of other individual drafts relevant for the netmod working group were discussed: 1) draft-bierman-netconf-system-monitoring-00.txt Status: new submission (Andy Bierman) Draft was discussed in the NETCONF working group. The working group chairswanted to make sure that everybody is aware of this work. 2) draft-linowski-netmod-yang-abstract-03.txt Status: headed for AD sponsored experimental (Bernd Linowski) This draft was discussed during the Ops Area working group session. This work was not part of the current netmod charter and was accepted by the Operations and Management Area Director to be considered and published as an experimental RFC. The chairs asked for volunteers for a review of this document to help Dan. Martin Bjorklund volunteered to be Dan's reviewer. 3) draft-schoenw-netmod-smi-yang-00.txt Status: expired, but possible work item for new charter Earlier presented slides: http://www.ietf.org/proceedings/75/slides/netmod-0.pdf Slides this meeting: http://www.ietf.org/proceedings/78/slides/netmod-1.pdf (Juergen Schoenwaelder) Juergen Schoenwaelder discussed his draft in the context of accepting this work as a future work item for a rechartered netmod working group: - mapping SMIv2 modules into YANG - code is part of libsmi - allows access to SNMP instrumentation via NETCONF - direct translation - code rewrite will allow more conversions - do we need a translation for SMIv2 to YANG A large part of the meeting time was allocated to discuss the next steps for the netmod working group. Whether is is decided to recharter or close a new working group, the chairs proposed to discuss what work still remains to be done now that netmods scheduled work items are mostly complete. David Kessens presented the following presentation: http://www.ietf.org/proceedings/78/slides/netmod-3.pdf The slides presented a number of questions that needed discussion or answers before a new proposed charter can be contructed. The first discussion item that was brought up was whether the working group should close down or continue with a fresh new charter. - Area Director: should use this meeting time to discuss recharter now need to continue momentum and add YANG modules - David Kessens: last meeting preference seemed to be for recharter The following topic was on what issues still need to be solved in the IETF to make YANG deployment happen. The working group was invited to comment. - Lada: improvement to data type system - native IP address instead of patterns - how better: string compare can cause same addess in different forms not to match - string compare should work because the server will normalize - objection to using extensions to build the standard; - Martin: what about network-wide-config; is that in scope? - Andy: need to deal with SNMP data structures being referenced from NETCONF (they do not exist in NETCONF; assumption that SNMP agent will be present) - system core module is needed - interface list should be core module - refinements to the conformance model over time - mapping from SMIv2 to YANG is not exactly the same as mapping SNMP to NETCONF (e.g., contextId is part of SNMP, not SMI) Slide 3 was about what work should be explicitly excluded and the floor was opened for comments: - no desire to start YANG 2.0 now - network-wide config may require changes to YANG - framework for net-wide-config may lead to lots of of different work; not clear yet what this will be - need for YANG Doctors review team, but not done in the NETMOD WG - operational state? not in the charter but will come up - config alternative states (pre-provisioning, disabled config, etc.) Slide 4 asked for specific work items and whether there were volunteers to work on them: - SMI to YANG mapping (Juergen) - network-wide config (Phil) - routing table data model - SMIv2 is horrible for representing a routing table - need YANG model that can be extended with protocol-specific properties Finally, Andy and Juergen volunteered to work on a new charter text together with David Kessens based on the comments received during the previous discussions. The question on whether a new working group should be started or a recharter was better was brought up again. - AD: slightly easier to recharter than start a new WG - David Kessens (wgchair): prefer to close and charter a new WG, but no objection to writing charter text assuming a recharter Also, the topic of net-wide config was brought up again: - need to see more details to know what the charter text - not really needed - David asked the working group: should be included? - 1 OK; 3 no; 3 leave in the middle; 14 don't care Under the "Any other Business" agenda topic, Dan Romascanu brought up the issue of a YANG module review team. He made it clear that he believes a YANG doctor group should be setup and he announced that he was going to create a mailing list and announce a call for volunteers for the team. One issue was brought up for the architecture draft, whether the data distinction problem described (operational vs. config) needs 2 leafs for operational vs. config. - Martin agrees to add; Andy agrees; no objections. ============================================= From lhotka@cesnet.cz Thu Aug 12 00:18:39 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 071C53A69D4 for ; Thu, 12 Aug 2010 00:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.251, 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 lVpNppvTAIPe for ; Thu, 12 Aug 2010 00:18:38 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id B11053A69D3 for ; Thu, 12 Aug 2010 00:18:37 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:221:ff:feb6:15fe] (unknown [IPv6:2001:718:1a02:7:221:ff:feb6:15fe]) by office2.cesnet.cz (Postfix) with ESMTPSA id 8FA9F2CDE058; Thu, 12 Aug 2010 09:19:12 +0200 (CEST) From: Ladislav Lhotka To: Gerhard Muenz In-Reply-To: <4C62F736.4050900@net.in.tum.de> References: <4C62F736.4050900@net.in.tum.de> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 12 Aug 2010 09:19:07 +0200 Message-ID: <1281597547.1886.2.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] encapsulating containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 07:18:39 -0000 On St, 2010-08-11 at 21:17 +0200, Gerhard Muenz wrote: > > As it is now, entries from different lists could be freely interleaved, > > for instance > > > > ... > > ... > > ... > > Is this true? There is no choice statement but a sequence of list > statements. So, one list should follow the other. List elements should > not be interleaved. Yes, see the last paragraph in section 7.8.5. Lada > > Anyway, I do not think that interleaving is a problem. > > Gerhard > > > > > This is usually not very desirable. > > > > Lada > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mehmet.ersue@nsn.com Thu Aug 12 11:18:25 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98593A6A04; Thu, 12 Aug 2010 11:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7d8dq8jF+me; Thu, 12 Aug 2010 11:18:24 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id C389D3A69F4; Thu, 12 Aug 2010 11:18:23 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o7CIIqbn003972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Aug 2010 20:18:52 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7CIIpSZ019323; Thu, 12 Aug 2010 20:18:51 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Aug 2010 20:18:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Aug 2010 20:18:49 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64D17E7D@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Network-wide Configuration - TM Forum View thread-index: Acs5PW1cqsiUctr7QHSkDxLM5YesGAAbqK5wABozHqAAACks8AAAovpQAAEs46AAAD2ZkAAAG+sAAAA+g2AAADkW4AAA0omAAAC564A= From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" , "Phil Shafer" , "ext Martin Bjorklund" , "ext Bert (IETF) Wijnen" , , "Linowski, Bernd (EXT-Other - DE)" , "Kessens, David (NSN - US/Mountain View)" , "Juergen Schoenwaelder" , "ext Ladislav Lhotka" , "ext Davis, Nigel" X-OriginalArrivalTime: 12 Aug 2010 18:18:51.0748 (UTC) FILETIME=[D0EE9A40:01CB3A4A] X-Mailman-Approved-At: Thu, 12 Aug 2010 11:21:53 -0700 Cc: netconf@ietf.org, NETMOD Working Group Subject: [netmod] Network-wide Configuration - TM Forum View X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 18:18:25 -0000 Hi All, as discussed in the Network-wide configuration BarBof in Maastricht Nigel Davis from TM Forum volunteered to=20 give us an overview on the TMF network model, NE-Mediation- EMS as well as the modeling and tooling framework at TMF.=20 Following is a draft agenda: - Level set on purpose of meeting with respect to the bar BoF discussion - Briefly discuss NE-Mediation-EMS approach to dealing with normalisation - Examine the TMF network model and documentation structure/locations - Discuss next step, possible liaison and ongoing work approach Please let Nigel know if you would like to have additional=20 agenda points.=20 The proposed date for a conf call (1.5 hours) is next=20 Thursday (8/19) or Friday (8/20). Please check the doodle=20 below and enter your preferred time. http://www.doodle.com/4gq3niupbev3vg6m PS: We hope 8/19 or 8/20 does work for a conf call. If not we can arrange another date. Cheers, Mehmet From ietf@andybierman.com Thu Aug 12 11:45:37 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A5A628C143 for ; Thu, 12 Aug 2010 11:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 59Lm3EJilzEP for ; Thu, 12 Aug 2010 11:45:36 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 867F128C13E for ; Thu, 12 Aug 2010 11:45:36 -0700 (PDT) Received: (qmail 78773 invoked from network); 12 Aug 2010 18:46:11 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 12 Aug 2010 11:46:11 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: HVVBLogVM1ngzLvc1GkWXhgrVYKBp7b8lIkHgtNFxGy5tVO HYQO0oNjdxZjIj7SDThsDg5r91.Vjj.Iyb0NTu1dNgRBfsFrWs3aNUfBRu26 t7.CenXhQW0GxUC.n_I5nYPJZtqmLe8198EvwSxEyhI.ABJQt2TdfTlB3Lm2 VU56iKuMDF2daEj1M4o5Dr0_FMK8DqBtdbMG6Mu3CIpDBejwgdGvYDc3Kjsg zFk4QKJajQYd8JHD6.rFeno2hBtPUF3pRvOCMJe65fgld.QpSOAJPVsciyys pbMs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C644174.3000605@andybierman.com> Date: Thu, 12 Aug 2010 11:46:12 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Ersue, Mehmet \(NSN - DE/Munich\)" References: <80A0822C5E9A4440A5117C2F4CD36A64D17E7D@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64D17E7D@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 12 Aug 2010 12:27:08 -0700 Cc: NETMOD Working Group , netconf@ietf.org, "ext Davis, Nigel" Subject: Re: [netmod] Network-wide Configuration - TM Forum View X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 18:45:37 -0000 On 08/12/2010 11:18 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi All, > > as discussed in the Network-wide configuration BarBof > in Maastricht Nigel Davis from TM Forum volunteered to > give us an overview on the TMF network model, NE-Mediation- > EMS as well as the modeling and tooling framework at TMF. > > Following is a draft agenda: > > - Level set on purpose of meeting with respect to the bar BoF discussion > - Briefly discuss NE-Mediation-EMS approach to dealing with > normalisation > - Examine the TMF network model and documentation structure/locations > - Discuss next step, possible liaison and ongoing work approach > > Please let Nigel know if you would like to have additional > agenda points. > I am very interested in understanding how we are going to build on what we already have. We have network devices that contain NETCONF servers (and possibly SSH for CLI, SNMP for SMIv2 data and notifications and SYSLOG for system events). We also have a new data modeling language called YANG, so a client can understand how to access/control the content layer for a NETCONF server. Getting from a high-level SID (or other) model to a NETCONF client managing NETCONF servers with standard YANG data models looks like a lot of hand-waving to me so far. I want to understand what work is needed, why this is the best approach, and how the network model translates/maps to the device-level NETCONF/YANG interface. I am hoping people will write drafts on this topic for a real BoF at the next IETF. > The proposed date for a conf call (1.5 hours) is next > Thursday (8/19) or Friday (8/20). Please check the doodle > below and enter your preferred time. > > http://www.doodle.com/4gq3niupbev3vg6m > > PS: We hope 8/19 or 8/20 does work for a conf call. > If not we can arrange another date. > > Cheers, > Mehmet > > > Andy From ndavis@ciena.com Fri Aug 13 05:42:22 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4938F3A696F; Fri, 13 Aug 2010 05:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 yVvJZbXIp-Ic; Fri, 13 Aug 2010 05:42:20 -0700 (PDT) Received: from ripley.ciena.com (ripley.ciena.com [63.118.34.24]) by core3.amsl.com (Postfix) with ESMTP id E16D03A68CC; Fri, 13 Aug 2010 05:42:19 -0700 (PDT) From: "Davis, Nigel" To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Andy Bierman , Phil Shafer , ext Martin Bjorklund , "ext Bert (IETF) Wijnen" , "dromasca@avaya.com" , "Linowski, Bernd (EXT-Other - DE)" , "Kessens, David (NSN - US/Mountain View)" , Juergen Schoenwaelder , ext Ladislav Lhotka Date: Fri, 13 Aug 2010 08:41:07 -0400 Thread-Topic: Network-wide Configuration - TM Forum View Thread-Index: Acs5PW1cqsiUctr7QHSkDxLM5YesGAAbqK5wABozHqAAACks8AAAovpQAAEs46AAAD2ZkAAAG+sAAAA+g2AAADkW4AAA0omAAAC564AAL5BE8A== Message-ID: <08F15C31754FA341A7B1A106DF42FDB8702DED81@ONWEXGMB01.ciena.com> References: <80A0822C5E9A4440A5117C2F4CD36A64D17E7D@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64D17E7D@DEMUEXC006.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 13 Aug 2010 05:45:35 -0700 Cc: "netconf@ietf.org" , NETMOD Working Group Subject: Re: [netmod] Network-wide Configuration - TM Forum View X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 12:42:22 -0000 Hi, If you do want to attend this session please do use the doodle link to high= light your availability as we can then try our best to ensure that your cal= endar challenges can be accommodated (and when you get to the link you will= notice that my browser generously applied my availability twice :) ). Nigel -----Original Message----- From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com]=20 Sent: 12 August 2010 19:19 To: ext Andy Bierman; Phil Shafer; ext Martin Bjorklund; ext Bert (IETF) Wi= jnen; dromasca@avaya.com; Linowski, Bernd (EXT-Other - DE); Kessens, David = (NSN - US/Mountain View); Juergen Schoenwaelder; ext Ladislav Lhotka; Davis= , Nigel Cc: netconf@ietf.org; NETMOD Working Group Subject: Network-wide Configuration - TM Forum View Hi All, as discussed in the Network-wide configuration BarBof in Maastricht Nigel D= avis from TM Forum volunteered to give us an overview on the TMF network mo= del, NE-Mediation- EMS as well as the modeling and tooling framework at TMF= .=20 Following is a draft agenda: - Level set on purpose of meeting with respect to the bar BoF discussion - Briefly discuss NE-Mediation-EMS approach to dealing with normalisation - Examine the TMF network model and documentation structure/locations - Discuss next step, possible liaison and ongoing work approach Please let Nigel know if you would like to have additional agenda points.=20 The proposed date for a conf call (1.5 hours) is next Thursday (8/19) or Fr= iday (8/20). Please check the doodle below and enter your preferred time. http://www.doodle.com/4gq3niupbev3vg6m PS: We hope 8/19 or 8/20 does work for a conf call. If not we can arrange another date. Cheers, Mehmet From mehmet.ersue@nsn.com Wed Aug 18 05:07:30 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A171F3A6870; Wed, 18 Aug 2010 05:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.384 X-Spam-Level: X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0FyeQIg566Q; Wed, 18 Aug 2010 05:07:29 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id ED7B63A68CF; Wed, 18 Aug 2010 05:07:28 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o7IC7pXF011337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Aug 2010 14:07:52 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7IC7ndF028252; Wed, 18 Aug 2010 14:07:50 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 14:07:49 +0200 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: Wed, 18 Aug 2010 14:07:45 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64D63CDD@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64D17E7D@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Network-wide Configuration - TM Forum View thread-index: Acs5PW1cqsiUctr7QHSkDxLM5YesGAAbqK5wABozHqAAACks8AAAovpQAAEs46AAAD2ZkAAAG+sAAAA+g2AAADkW4AAA0omAAAC564ABKXrDkA== References: <80A0822C5E9A4440A5117C2F4CD36A64D17E7D@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" , "Phil Shafer" , "ext Martin Bjorklund" , "ext Bert (IETF) Wijnen" , , "Linowski, Bernd (EXT-Other - DE)" , "Kessens, David (NSN - US/Mountain View)" , "Juergen Schoenwaelder" , "ext Ladislav Lhotka" , "ext Davis, Nigel" X-OriginalArrivalTime: 18 Aug 2010 12:07:49.0518 (UTC) FILETIME=[FA1662E0:01CB3ECD] X-Mailman-Approved-At: Wed, 18 Aug 2010 05:10:03 -0700 Cc: netconf@ietf.org, NETMOD Working Group Subject: Re: [netmod] [Netconf] Network-wide Configuration - TM Forum View X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 12:07:30 -0000 Hi All, there was no consensus on doodle for a conf time.=20 Some keyplayer cannot on the time where the majority=20 can. Pls fill out the new doodle: http://www.doodle.com/piexidce9kctgctz=20 This time the majority will win ;-) To make it more supportive for consensus I excluded=20 some obvious time slots (e.g. IESG chat). Nigel will take care on conf bridge and webex a few days before the meeting. PS: I am in vacation betw. 8/23-9/6. Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) > Sent: Thursday, August 12, 2010 8:19 PM > To: ext Andy Bierman; Phil Shafer; ext Martin Bjorklund; ext Bert > (IETF) Wijnen; dromasca@avaya.com; Linowski, Bernd (EXT-Other - DE); > Kessens, David (NSN - US/Mountain View); Juergen Schoenwaelder; ext > Ladislav Lhotka; ext Davis, Nigel > Cc: netconf@ietf.org; NETMOD Working Group > Subject: [Netconf] Network-wide Configuration - TM Forum View >=20 > Hi All, >=20 > as discussed in the Network-wide configuration BarBof > in Maastricht Nigel Davis from TM Forum volunteered to > give us an overview on the TMF network model, NE-Mediation- > EMS as well as the modeling and tooling framework at TMF. >=20 > Following is a draft agenda: >=20 > - Level set on purpose of meeting with respect to the bar BoF > discussion > - Briefly discuss NE-Mediation-EMS approach to dealing with > normalisation > - Examine the TMF network model and documentation structure/locations > - Discuss next step, possible liaison and ongoing work approach >=20 > Please let Nigel know if you would like to have additional > agenda points. >=20 > The proposed date for a conf call (1.5 hours) is next > Thursday (8/19) or Friday (8/20). Please check the doodle > below and enter your preferred time. >=20 > http://www.doodle.com/4gq3niupbev3vg6m >=20 > PS: We hope 8/19 or 8/20 does work for a conf call. > If not we can arrange another date. >=20 > Cheers, > Mehmet >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From ietf@andybierman.com Thu Aug 19 09:27:51 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0078F3A697D for ; Thu, 19 Aug 2010 09:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 HBxohGftTWWE for ; Thu, 19 Aug 2010 09:27:50 -0700 (PDT) Received: from smtp109.sbc.mail.gq1.yahoo.com (smtp109.sbc.mail.gq1.yahoo.com [67.195.14.39]) by core3.amsl.com (Postfix) with SMTP id 348BA3A6961 for ; Thu, 19 Aug 2010 09:27:50 -0700 (PDT) Received: (qmail 88972 invoked from network); 19 Aug 2010 16:28:23 -0000 Received: from [192.168.0.9] (ietf@75.84.164.152 with plain) by smtp109.sbc.mail.gq1.yahoo.com with SMTP; 19 Aug 2010 09:28:22 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: Ag2YnCYVM1nyE.lT8l2WFumFnIvJlIx1i1XNN7hHSCbX9Nn lmBV7V8MtFgTNpaj47TmokSQknvLW0.hCzq7VUCM1s0_erFBCN2r4q3P1Qc_ VGmp2TTJRICT.quVunfF0eJkTABBuV5YkJN.fCqmI8kEDPd09Tl8aSdjzs2B zDX4w0jkY1Ql1CcCRrAnISY_M1En.dX7v6e5BgEmlUJIwfGBgWvJkUi5w1QU jH8.XbQodvuxEamITnL41hJH84zmlEKTRCp5Ox9qArNpt7JF07_awzvQsph2 Y_xkC X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C6D5BA4.2090200@andybierman.com> Date: Thu, 19 Aug 2010 09:28:20 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] YANG include-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 16:27:51 -0000 Hi, I want to clarify which external symbols should be visible in a given [sub]module. submodule foo { belongs-to top { prefix top; } include bar; } submodule bar { belongs-to top { prefix top; } container x; } submodule baz { belongs-to top { prefix top; } include foo; augment /x { leaf y { type int32; } } } yangdump is complaining that '/x' is not found. IMO, this is correct, because submodule 'baz' does not have an 'include bar' statement. I think pyang is accepting this as valid YANG. Which is correct? I think the YANG spec says an import or include must be present for every external symbol used, but not sure where. thanks, Andy From dromasca@avaya.com Thu Aug 19 09:58:21 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18ED33A6A30 for ; Thu, 19 Aug 2010 09:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.56 X-Spam-Level: X-Spam-Status: No, score=-101.56 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKhxMvwnlWBF for ; Thu, 19 Aug 2010 09:58:19 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id E00333A68CB for ; Thu, 19 Aug 2010 09:58:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,234,1280721600"; d="scan'208";a="30662036" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 19 Aug 2010 12:57:17 -0400 X-IronPort-AV: E=Sophos;i="4.56,234,1280721600"; d="scan'208";a="505193233" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Aug 2010 12:57:17 -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: Thu, 19 Aug 2010 18:56:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-netmod-dsdl-map Thread-Index: Acs/v4eruw8YCyUUT8eSz/h8N/3UWQ== From: "Romascanu, Dan (Dan)" To: "NETMOD Working Group" Subject: [netmod] AD review of draft-ietf-netmod-dsdl-map X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 16:58:21 -0000 Please find below my AD review for draft-ietf-netmod-dsdl-map-06.txt. I believe that a revised I-D is needed before proceeding to IETF Last Call. Also, you need to answer issue T1 either by moving the reference to 5013 to Informational, or by specifying the downref in the IETF Last Call.=20 The comments are divided into Technical and Editorial.=20 T1. There is a normative reference to RFC 5013 which is Informational. This is a downref. If this reference must be normative, the downref must be explicitly mentioned in the IETF Last Call. Is this the intention?=20 T2. Introduction=20 > The NETMOD Working Group was chartered to address this problem by defining a new human-friendly modeling language based on SMIng [RFC3216] and called YANG [YANG]. I do not believe that this statement is true. There was no requirement in the charter to base the YANG on SMIng. T3. Section 8.4:=20 > Each embedded element must declare the namespace of the corresponding module using the @ns attribute. Use capitalized MUST.=20 T4. Section 10.13 > This statement MAY be ignored. Otherwise, it is mapped to the DTD compatibility element and ARGUMENT becomes its text. What does the second sentence mean? What to do when mapping or what not to do?=20 T5. Same question as above for 10.47 T6. Section 10.56:=20 > Implementations MAY ignore this statement. Why? T7. Section 10.60:=20 > This statement is not mapped to the output schema. However, an implementation SHOULD check that it is compatible with the YANG version declared by the statement (currently version 1). What should an implementation do if the yang-version is not compatible? (which may happen in the future) T8. Section 11: > In general, the second mapping step has to accomplish the following three tasks: What does 'In general' mean here? Are there exceptions? Which ones?=20 E1. Introduction: s/SNMP Management Information Bases (MIBs)/SNMP Management Information Base (MIB) modules/ E2. Expand acronyms at the first occurrence: DSRL, etc. E3.In section 3: s/the inverse mapping from DSDL to YANG beyond the scope of this document/the inverse mapping from DSDL to YANG is beyond the scope of this document/ E4. Section 4 - reference for ISO/IEC 19757, RelaxNG, Schematron, DSRL are desirable in the introduction part of the section.=20 E5. I see no reason to list the URIs separately and format them separately then the rest of the Informative references. Actually [XSD] is also referenced by an URI, although included with the other references.=20 E6. In section 8.2 s/SNMP MIBs/SNMP MIB modules/ E7. The non-usage of quotation marks in the titles of subsections in 10 is confusing. For example should not 10.11 be The 'container' Statement rather than The container statement - so that the use of the noun container in the text can be differentiated from the name of the statement? Or in 10.12 we have The default Statement as the title of the subsection while the text of the section speaks about the 'default' statement.=20 E8. Section 12: s/we will denote CONTELEM/we will call CONTELEM/ E9. The IANA considerations section mentions registering three namespace URIs, but then lists only two.=20 E10. Make explicit that Appendix D will be removed at document publication. From mbj@tail-f.com Thu Aug 19 10:16:50 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 424C43A6961 for ; Thu, 19 Aug 2010 10:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] 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 0jekpBlQoziv for ; Thu, 19 Aug 2010 10:16:49 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 3FC593A67F1 for ; Thu, 19 Aug 2010 10:16:49 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 8714C616005; Thu, 19 Aug 2010 19:17:21 +0200 (CEST) Date: Thu, 19 Aug 2010 19:17:14 +0200 (CEST) Message-Id: <20100819.191714.231079025.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <4C6D5BA4.2090200@andybierman.com> References: <4C6D5BA4.2090200@andybierman.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG include-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:16:50 -0000 Hi, Andy Bierman wrote: > Hi, > > I want to clarify which external symbols should be visible in a > given [sub]module. > > > submodule foo { > belongs-to top { prefix top; } > include bar; > } > > > submodule bar { > belongs-to top { prefix top; } > > container x; > } > > > submodule baz { > belongs-to top { prefix top; } > include foo; > > augment /x { > leaf y { type int32; } > } > } > > yangdump is complaining that '/x' is not found. > IMO, this is correct, because submodule 'baz' does not > have an 'include bar' statement. I think pyang is accepting > this as valid YANG. > > Which is correct? I agree with you that baz must include bar. pyang needs to be fixed. > I think the YANG spec says an import or include must be present > for every external symbol used, but not sure where. Third bullet of 5.1: o For a submodule to reference definitions in a second submodule of the same module, the first submodule MUST include the second submodule. /martin From ietf@andybierman.com Thu Aug 19 10:24:58 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 447C33A68A7 for ; Thu, 19 Aug 2010 10:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 Aal5Io75p1y1 for ; Thu, 19 Aug 2010 10:24:57 -0700 (PDT) Received: from smtp108.sbc.mail.gq1.yahoo.com (smtp108.sbc.mail.gq1.yahoo.com [67.195.14.111]) by core3.amsl.com (Postfix) with SMTP id 73F403A65A6 for ; Thu, 19 Aug 2010 10:24:57 -0700 (PDT) Received: (qmail 99824 invoked from network); 19 Aug 2010 17:25:29 -0000 Received: from [192.168.0.9] (ietf@75.84.164.152 with plain) by smtp108.sbc.mail.gq1.yahoo.com with SMTP; 19 Aug 2010 10:25:29 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: LczkRSgVM1lcH1tWnMDGIpO_o4zmN3jDX.ecZiSJ0FnNWkU VxEv2bYB9HseEWUY7FX3vSUM_0taAiNf8y4dVuR.AJkZ0vcawg5hQuYb3dUh YL.tKhtAa6.5f8HmhXavtXBuJAQGeUozdUVWrcTR.ArstWw6bIDBw5bUR_C1 iU0rhPykPVZkpTsABuTOkjyPz8H2oqsB2oLRXhivsApqmXWF9MTs9.ljsFmo xS2eGOLY5ynBOogOIUGJfBrKEdj6s7bgtrfhSMWMt0n6WjHmeFHyeKdJpXPB Jtmszl0gDpDci30y8hoeXqIsKsg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C6D6906.5000700@andybierman.com> Date: Thu, 19 Aug 2010 10:25:26 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Martin Bjorklund References: <4C6D5BA4.2090200@andybierman.com> <20100819.191714.231079025.mbj@tail-f.com> In-Reply-To: <20100819.191714.231079025.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG include-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:24:58 -0000 On 08/19/2010 10:17 AM, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Hi, >> >> I want to clarify which external symbols should be visible in a >> given [sub]module. >> >> >> submodule foo { >> belongs-to top { prefix top; } >> include bar; >> } >> >> >> submodule bar { >> belongs-to top { prefix top; } >> >> container x; >> } >> >> >> submodule baz { >> belongs-to top { prefix top; } >> include foo; >> >> augment /x { >> leaf y { type int32; } >> } >> } >> >> yangdump is complaining that '/x' is not found. >> IMO, this is correct, because submodule 'baz' does not >> have an 'include bar' statement. I think pyang is accepting >> this as valid YANG. >> >> Which is correct? > > I agree with you that baz must include bar. pyang needs to be fixed. > >> I think the YANG spec says an import or include must be present >> for every external symbol used, but not sure where. > > Third bullet of 5.1: > > o For a submodule to reference definitions in a second submodule of > the same module, the first submodule MUST include the second > submodule. > Yes -- even though this is not what C programmers expect from #include. I think that is why the data model author left out the 2nd include. When include-by-revision is used, this becomes even more important. > > /martin > Andy From lhotka@cesnet.cz Thu Aug 19 12:27:22 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD0733A691A for ; Thu, 19 Aug 2010 12:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.961 X-Spam-Level: X-Spam-Status: No, score=-0.961 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 4BB17uMrImDW for ; Thu, 19 Aug 2010 12:27:21 -0700 (PDT) Received: from trail.lhotka.cesnet.cz (trail.lhotka.cesnet.cz [195.113.161.162]) by core3.amsl.com (Postfix) with ESMTP id 447D83A680D for ; Thu, 19 Aug 2010 12:27:21 -0700 (PDT) Received: from localhost (missotis.lhotkovi.cz [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.cesnet.cz (Postfix) with ESMTPSA id 5CB853E0046; Thu, 19 Aug 2010 21:27:33 +0200 (CEST) From: Ladislav Lhotka To: "Romascanu\, Dan \(Dan\)" , NETMOD Working Group In-Reply-To: References: User-Agent: Notmuch/0.3.1-59-g676d251 (http://notmuchmail.org) Emacs/23.1.1 (i486-pc-linux-gnu) Mail-Followup-To: "Romascanu\, Dan \(Dan\)" , NETMOD Working Group Date: Thu, 19 Aug 2010 21:27:50 +0200 Message-ID: <87y6c22yix.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] AD review of draft-ietf-netmod-dsdl-map X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 19:27:22 -0000 Hi Dan, thank you for the review, I'll roll out the -07 revision soon. Please see my responses and suggested changes inline. Lada On Thu, 19 Aug 2010 18:56:55 +0200, "Romascanu, Dan (Dan)" wrote: > Please find below my AD review for draft-ietf-netmod-dsdl-map-06.txt. I > believe that a revised I-D is needed before proceeding to IETF Last > Call. Also, you need to answer issue T1 either by moving the reference > to 5013 to Informational, or by specifying the downref in the IETF Last > Call. > > The comments are divided into Technical and Editorial. > > > T1. There is a normative reference to RFC 5013 which is Informational. > This is a downref. If this reference must be normative, the downref must > be explicitly mentioned in the IETF Last Call. Is this the intention? This reference can be moved to Informational. I just wasn't aware of this downref issue. > > T2. Introduction > > The NETMOD Working Group was chartered to address this problem by > defining a new human-friendly modeling language based on SMIng > [RFC3216] and called YANG [YANG]. > > I do not believe that this statement is true. There was no requirement > in the charter to base the YANG on SMIng. Is this better? (I hope the text will eventually refer to the YANG RFC). OLD: The NETMOD Working Group was chartered to address this problem by defining a new human-friendly modeling language based on SMIng [RFC3216] and called YANG [YANG]. NEW: The NETMOD Working Group was chartered to address this problem by defining a new human-friendly data modeling language called YANG. The definition of YANG version 1 was published recently [YANG]. Its syntax is loosely based on SMIng [RFC3216]. Alternatively, the last sentence can be removed. > > T3. Section 8.4: > > > Each embedded element must declare the namespace of > the corresponding module using the @ns attribute. > > Use capitalized MUST. OK > > T4. Section 10.13 > > This statement MAY be ignored. Otherwise, it is mapped to the DTD > compatibility element and ARGUMENT becomes its text. > > What does the second sentence mean? What to do when mapping or what not > to do? OLD This statement MAY be ignored. Otherwise, it is mapped to the DTD compatibility element and ARGUMENT becomes its text. NEW This statement is mapped to the DTD compatibility element and ARGUMENT becomes its text. > > T5. Same question as above for 10.47 > The same change, mutatis mutandis. > T6. Section 10.56: > > > Implementations MAY ignore this statement. > > Why? You are right, I'll remove this sentence. > > T7. Section 10.60: > > This statement is not mapped to the output schema. However, an > implementation SHOULD check that it is compatible with the YANG > version declared by the statement (currently version 1). > > What should an implementation do if the yang-version is not compatible? > (which may happen in the future) OLD: This statement is not mapped to the output schema. However, an implementation SHOULD check that it is compatible with the YANG version declared by the statement (currently version 1). NEW: This statement is not mapped to the output schema. However, an implementation SHOULD check that it is compatible with the YANG version declared by the statement (currently version 1). In the case of a mismatch, the implementation SHOULD report an error and terminate. > > T8. Section 11: > > In general, the second mapping step has to accomplish the following > three tasks: > > What does 'In general' mean here? Are there exceptions? Which ones? > OLD: In general, the second mapping step has to accomplish the following three tasks: NEW: The second mapping step has to accomplish the following three general tasks: > > E1. Introduction: s/SNMP Management Information Bases (MIBs)/SNMP > Management Information Base (MIB) modules/ OK > > E2. Expand acronyms at the first occurrence: DSRL, etc. Will do. > > E3.In section 3: s/the inverse mapping from DSDL to YANG beyond the > scope of this document/the inverse mapping from DSDL to YANG is beyond > the scope of this document/ OK > > E4. Section 4 - reference for ISO/IEC 19757, RelaxNG, Schematron, DSRL > are desirable in the introduction part of the section. I will put them there. > > E5. I see no reason to list the URIs separately and format them > separately then the rest of the Informative references. Actually [XSD] > is also referenced by an URI, although included with the other > references. This is how xml2rfc handles hyperlinks (). I don't like it either, so I will change them to standard informational references. > > E6. In section 8.2 s/SNMP MIBs/SNMP MIB modules/ OK > > E7. The non-usage of quotation marks in the titles of subsections in 10 > is confusing. For example should not 10.11 be The 'container' Statement > rather than The container statement - so that the use of the noun > container in the text can be differentiated from the name of the > statement? Or in 10.12 we have The default Statement as the title of the > subsection while the text of the section speaks about the 'default' > statement. I actually thought about this in an early stage but then decided to follow the suit of the YANG draft where the (double) quotes are omited in section titles, too. I will add the single quotes to titles. > > E8. Section 12: s/we will denote CONTELEM/we will call CONTELEM/ I suggest this: OLD: In the rest of this section, we will denote CONTELEM the name of this context element properly qualified with its namespace prefix. NEW: In the rest of this section, CONTELEM will denote the name of this context element properly qualified with its namespace prefix. > > E9. The IANA considerations section mentions registering three namespace > URIs, but then lists only two. I got rid of one between -05 and -06 and forgot to update the count. > > E10. Make explicit that Appendix D will be removed at document > publication. OK, I will add an instruction to the RFC Editor. > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Thu Aug 19 12:59:32 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B007B3A69F0 for ; Thu, 19 Aug 2010 12:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.814 X-Spam-Level: X-Spam-Status: No, score=-101.814 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suXmj9KFgiRG for ; Thu, 19 Aug 2010 12:59:31 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8C31C3A69E7 for ; Thu, 19 Aug 2010 12:59:31 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11E82C0018; Thu, 19 Aug 2010 22:00:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FFe3JOtZlBFP; Thu, 19 Aug 2010 22:00:04 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5DC28C001A; Thu, 19 Aug 2010 22:00:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A839414512AB; Thu, 19 Aug 2010 21:59:49 +0200 (CEST) Date: Thu, 19 Aug 2010 21:59:49 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" , NETMOD Working Group Message-ID: <20100819195949.GA4030@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , NETMOD Working Group References: <87y6c22yix.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87y6c22yix.fsf@cesnet.cz> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [netmod] AD review of draft-ietf-netmod-dsdl-map X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 19:59:32 -0000 On Thu, Aug 19, 2010 at 09:27:50PM +0200, Ladislav Lhotka wrote: > NEW: > > The NETMOD Working Group was chartered to address this problem by > defining a new human-friendly data modeling language called YANG. The > definition of YANG version 1 was published recently [YANG]. Its syntax > is loosely based on SMIng [RFC3216]. Although the syntax of YANG has some heritage of SMIng (and I generally appreciate references to SMIng for my ego ;-), I do not consider this important enough to be mentioned. I also do not think that the YANG version number matters in this context. Here is a quote of the original charter (which is still in the current charter): The WG will define a "human-friendly" modeling language defining the semantics of operational data, configuration data, notifications, and operations. This language will focus on readability and ease of use. This language must be able to serve as the normative description of NETCONF data models. So the text should perhaps read like this: The NETMOD Working Group was chartered to define a "human-friendly" modeling language called YANG [YANG] defining the semantics of operational data, configuration data, notifications, and operations. This language focuses on readability and ease of use and it serves as the normative description of NETCONF data models. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Thu Aug 19 13:28:32 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031043A691B for ; Thu, 19 Aug 2010 13:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 RUWlVK8n-7kC for ; Thu, 19 Aug 2010 13:28:31 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 39D243A6895 for ; Thu, 19 Aug 2010 13:28:31 -0700 (PDT) Received: (qmail 64860 invoked from network); 19 Aug 2010 20:29:04 -0000 Received: from [192.168.0.9] (ietf@75.84.164.152 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 19 Aug 2010 13:29:04 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: pyD0NVMVM1k4Nd2qzO7PgpOQ5S2dkwOSyRmoegJBPqaer9P ifrS.1PnfV_FqgM8PniASCkScj9WsQwtYC8NBe9hBx6gQdRLCjFMxh5.o9MS 5ilz43gF1os3ZY2Bjmqj8jqxs1Mbb9mk6A6XSrrN2D3VdYtN9hFq05uEob.6 80IhOQwWowrfapnSyxAtQCtaOykpZMPlFCfdFYAz.RA9oa3h43c0m6X7HVgD JnXwHr93JdqbafWUNgN1pMhMjyycm X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C6D940B.2030109@andybierman.com> Date: Thu, 19 Aug 2010 13:28:59 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" , NETMOD Working Group References: <87y6c22yix.fsf@cesnet.cz> <20100819195949.GA4030@elstar.local> In-Reply-To: <20100819195949.GA4030@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] AD review of draft-ietf-netmod-dsdl-map X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 20:28:32 -0000 On 08/19/2010 12:59 PM, Juergen Schoenwaelder wrote: > On Thu, Aug 19, 2010 at 09:27:50PM +0200, Ladislav Lhotka wrote: > >> NEW: >> >> The NETMOD Working Group was chartered to address this problem by >> defining a new human-friendly data modeling language called YANG. The >> definition of YANG version 1 was published recently [YANG]. Its syntax >> is loosely based on SMIng [RFC3216]. > > Although the syntax of YANG has some heritage of SMIng (and I > generally appreciate references to SMIng for my ego ;-), I do not > consider this important enough to be mentioned. I also do not think > that the YANG version number matters in this context. Here is a quote > of the original charter (which is still in the current charter): > > The WG will define a "human-friendly" modeling language defining > the semantics of operational data, configuration data, > notifications, and operations. This language will focus on > readability and ease of use. This language must be able to serve > as the normative description of NETCONF data models. > > So the text should perhaps read like this: > > The NETMOD Working Group was chartered to define a "human-friendly" > modeling language called YANG [YANG] defining the semantics of > operational data, configuration data, notifications, and > operations. This language focuses on readability and ease of use and > it serves as the normative description of NETCONF data models. > I agree. Actually, YANG has some 'best hits' constructs from 3 different proprietary data modeling languages, plus SMIng. IMO, the sum is greater than the parts this time. YANG turned out much better than any one of the 4 individual languages. (The way standards are supposed to come together ;-) > /js > Andy From ietf@andybierman.com Fri Aug 20 11:44:00 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 656083A6B2E for ; Fri, 20 Aug 2010 11:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 jaq8Da4aqYEc for ; Fri, 20 Aug 2010 11:43:59 -0700 (PDT) Received: from smtp102.sbc.mail.gq1.yahoo.com (smtp102.sbc.mail.gq1.yahoo.com [67.195.15.61]) by core3.amsl.com (Postfix) with SMTP id 618113A6B20 for ; Fri, 20 Aug 2010 11:43:59 -0700 (PDT) Received: (qmail 53847 invoked from network); 20 Aug 2010 18:44:31 -0000 Received: from [192.168.0.9] (ietf@75.84.164.152 with plain) by smtp102.sbc.mail.gq1.yahoo.com with SMTP; 20 Aug 2010 11:44:31 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: E4yAabkVM1m9pCgq5NMIVP5XuoayMsaAym8dasm9mvGXUoo .s9K5QXXaYxlM4acD5xBLWOqCnTAVKkfsHPCk43JrYVlinkFuvKQyyUSa0pr OLDxB8DjVfzcO_ohBhl8012EHIgX_KuEm.6LGo9DNlJ09BvuKfJevzvyhFon BlSzhExQHtFxKoHN04yo2ja6H65jjsJbUGkKoYWQLZVOCh4CcubqxFTraPXR 85LNr5roBeRVD4nTU1uqVSKAGnPGbb4sbfh5yiNb90Yb4KTeaSXFpks3xXPJ cfyEaaE5r X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C6ECD0E.7050402@andybierman.com> Date: Fri, 20 Aug 2010 11:44:30 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] bug in yang-13 ABNF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 18:44:00 -0000 Hi, Fixing a bug in yangdump, so I checked yang-13 again. A list does not have to declare any data-def statements. list-stmt ABNF: OLD: 1*(data-def-stmt stmtsep) NEW: *(data-def-stmt stmtsep) Andy From phil@juniper.net Fri Aug 20 14:00:00 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAC583A6AEF for ; Fri, 20 Aug 2010 14:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.483 X-Spam-Level: X-Spam-Status: No, score=-5.483 tagged_above=-999 required=5 tests=[AWL=-1.484, BAYES_50=0.001, 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 ml0YvO9vwIQ0 for ; Fri, 20 Aug 2010 13:59:59 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 919C23A6A7C for ; Fri, 20 Aug 2010 13:59:58 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTG7s7cSmAfk9YpFWCGB5XoDY214MwSnJ@postini.com; Fri, 20 Aug 2010 14:00:34 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 20 Aug 2010 13:54:08 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o7KKs7U35201; Fri, 20 Aug 2010 13:54:07 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o7KKZEpD091707; Fri, 20 Aug 2010 20:35:14 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201008202035.o7KKZEpD091707@idle.juniper.net> To: "Romascanu, Dan (Dan)" In-Reply-To: Date: Fri, 20 Aug 2010 16:35:14 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] AD review of draft-ietf-netmod-arch-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 21:00:01 -0000 "Romascanu, Dan (Dan)" writes: >Please find below the AD review of draft-ietf-netmod-arch-07.txt Thank you for the review. >> Existing data modeling > languages such as XSD and Relax NG were considered, but were rejected > because the problem domains have little natural overlap. > >I do not understand this - what 'problem domains'? As I remember XSD and >Relax NG were not considered sufficient because they did not meet a >number of specific requirements for network device modeling, as well as >some of the format needs. The next sentence discusses the normal use for existing schema languages (text documents), but I've added some more explanatory text. >T2. Section 3.2: >> Network-wide configuration: NETCONF supports robust network-wide >configuration transactions via the confirmed-commit capability >This claim sounds a little 'marketing' - why is confirmed-commit >necessarily related to network-wide configuration? Is it sufficient? I don't see this as marketing, but I've added some additional text to back up the claim. >T3. > >> Implementation costs: Significant effort has been made to keep >implementation costs as low as possible. > >Maybe. What are the results of these efforts? Do we have any information >about implementation costs at this stage? How are they measured? Not sure what to do with this comment. The claim is that we worked to keep implementation costs down, which is true. I do not have proof that implementation costs are lower that any competitive design, but that doesn't invalidate the claim that we tried to be conscious of the costs and worked to reduce them. >T4. Section 3.3.4.1 - I believe that we need to discuss here the >implications of the non-compliant servers on hard-coded applications. >How can a developer avoid that they break? Would the deviations >mechanism help in preventing at least some cases of non-compliance that >can be anticipated? We have no firm guidance in this area, since this is something only experience can provide. The need to violate contracts are typically overly specific and implementation-specific details appearing in modules that are supposed to run on a variety of implementations. Also the attitude of "well, heck, everyone will do it the way I did it! Shucks, why wouldn't they?". Are you looking for this sort of additional text? >E1. idnits complains of several things among which the following need to >be addressed: > >Miscellaneous warnings: > >------------------------------------------------------------------------ >---- > > -- The document has a disclaimer for pre-RFC5378 work, but was first > submitted on or after 10 November 2008. Does it really need the > disclaimer? This change was something xml2rfc required. > == Outdated reference: A later version (-06) exists of > == Outdated reference: A later version (-09) exists of Fixed. >E2. Section 1.1 - >> The NETCONF specification defines a small set of operations >a reference to 4741 seems to be in place at this point. Fixed. >E3. same - >> In 2008 and 2009, the NETMOD working group produced a specification >Well, we are beyond mid-2010 and the RFC is not yet approved. We should >say 2008-1010 and hopefully we'll stay with this. The work was done in 2008 and 2009. Most of 2010 was spent in intense discussion about what "default value" means. >E4. Section 2.1 - what does the list of operations in the table in page >8 include 'commit' and does not include 'delete-config', 'close-session' >and 'kill-session'? I added delete-config, but not the *-session, since they are more self-management that real operations. No one is looking for a network management protocol that knows how to kill a session. >E5. Section 2.3.2 >> DSDL is considered to be the best choice for the given purpose >What purpose? Fixed. >E6. Section 3.1: >> The sequence of events for the typical client/server interaction is > as follows: >... > Note that there is no requirement for the client or server to process > the YANG modules in this way. >The two statements seem contradictory. If the second statement is true >than in the first s/is as follows/may be as follows/ Fixed. >E7. Section 3.2 >> YANG addresses many of the issues raised in the IAB NM workshop. >s/YANG addresses/NETCONF and YANG address/ Fixed. >E8. >> Post-processing: Use of XML will maximize the opportunities for >post-processing of data, possibly using XML-based technologies like >XPath, XQuery, and XSLT. Fixed. A new version should be out by Monday. Thanks, Phil From dromasca@avaya.com Fri Aug 20 14:14:30 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5086F3A6407 for ; Fri, 20 Aug 2010 14:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7FjTyyjjRMY for ; Fri, 20 Aug 2010 14:14:29 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id C93853A686B for ; Fri, 20 Aug 2010 14:14:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,242,1280721600"; d="scan'208";a="30884109" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 20 Aug 2010 17:14:50 -0400 X-IronPort-AV: E=Sophos;i="4.56,242,1280721600"; d="scan'208";a="505815258" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Aug 2010 17:14:49 -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: Fri, 20 Aug 2010 23:14:25 +0200 Message-ID: In-Reply-To: <201008202035.o7KKZEpD091707@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] AD review of draft-ietf-netmod-arch-07 Thread-Index: ActAqr16cDAyVm1JS9OTmyNVJMMgCwAAdSVg References: <201008202035.o7KKZEpD091707@idle.juniper.net> From: "Romascanu, Dan (Dan)" To: "Phil Shafer" Cc: netmod@ietf.org Subject: Re: [netmod] AD review of draft-ietf-netmod-arch-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 21:14:30 -0000 =20 > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net]=20 >=20 > A new version should be out by Monday. >=20 Looks good, thanks for addressing my comments.=20 Dan From root@core3.amsl.com Fri Aug 20 14:30:06 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B09E93A69F8; Fri, 20 Aug 2010 14:30: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: <20100820213005.B09E93A69F8@core3.amsl.com> Date: Fri, 20 Aug 2010 14:30:02 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-arch-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 21:30:06 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : An Architecture for Network Management using NETCONF and YANG Author(s) : P. Shafer Filename : draft-ietf-netmod-arch-08.txt Pages : 34 Date : 2010-08-20 NETCONF gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities. This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-arch-08.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-netmod-arch-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-20141958.I-D@ietf.org> --NextPart-- From dromasca@avaya.com Sun Aug 22 08:10:55 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC63C3A68CD for ; Sun, 22 Aug 2010 08:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbsAdZLaxeN2 for ; Sun, 22 Aug 2010 08:10:52 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id C93583A68BD for ; Sun, 22 Aug 2010 08:10:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,252,1280721600"; d="scan'208";a="31053559" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 22 Aug 2010 11:11:23 -0400 X-IronPort-AV: E=Sophos;i="4.56,252,1280721600"; d="scan'208";a="506398400" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Aug 2010 11:11:22 -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: Sun, 22 Aug 2010 17:10:58 +0200 Message-ID: In-Reply-To: <87y6c22yix.fsf@cesnet.cz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] AD review of draft-ietf-netmod-dsdl-map Thread-Index: Acs/1KC9KfZSLNXyQPqk6LqEKuYAGACNoy4Q References: <87y6c22yix.fsf@cesnet.cz> From: "Romascanu, Dan (Dan)" To: "Ladislav Lhotka" , "NETMOD Working Group" Subject: Re: [netmod] AD review of draft-ietf-netmod-dsdl-map X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 15:10:55 -0000 Hi Lada, Thank you for your answers. All the changes proposed by you in this mail are fine with me with the exception of the change in answer to my comment T2. In that case I would suggest that you make the change proposed by Juergen.=20 Thanks and Regards, Dan =20 > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@cesnet.cz]=20 > Sent: Thursday, August 19, 2010 10:28 PM > To: Romascanu, Dan (Dan); NETMOD Working Group > Subject: Re: [netmod] AD review of draft-ietf-netmod-dsdl-map >=20 > Hi Dan, >=20 > thank you for the review, I'll roll out the -07 revision=20 > soon. Please see my responses and suggested changes inline. >=20 > Lada >=20 > On Thu, 19 Aug 2010 18:56:55 +0200, "Romascanu, Dan (Dan)"=20 > wrote: > > Please find below my AD review for=20 > draft-ietf-netmod-dsdl-map-06.txt.=20 > > I believe that a revised I-D is needed before proceeding to=20 > IETF Last=20 > > Call. Also, you need to answer issue T1 either by moving=20 > the reference=20 > > to 5013 to Informational, or by specifying the downref in the IETF=20 > > Last Call. > >=20 > > The comments are divided into Technical and Editorial.=20 > >=20 > >=20 > > T1. There is a normative reference to RFC 5013 which is=20 > Informational. > > This is a downref. If this reference must be normative, the downref=20 > > must be explicitly mentioned in the IETF Last Call. Is this=20 > the intention? >=20 > This reference can be moved to Informational. I just wasn't=20 > aware of this downref issue. >=20 > >=20 > > T2. Introduction > >=20 > > The NETMOD Working Group was chartered to address this problem by=20 > > defining a new human-friendly modeling language based on SMIng=20 > > [RFC3216] and called YANG [YANG]. > >=20 > > I do not believe that this statement is true. There was no=20 > requirement=20 > > in the charter to base the YANG on SMIng. >=20 > Is this better? (I hope the text will eventually refer to the=20 > YANG RFC). >=20 > OLD: >=20 > The NETMOD Working Group was chartered to address this=20 > problem by defining a new human-friendly modeling language=20 > based on SMIng [RFC3216] and called YANG [YANG]. >=20 > NEW: >=20 > The NETMOD Working Group was chartered to address this=20 > problem by defining a new human-friendly data modeling=20 > language called YANG. The definition of YANG version 1 was=20 > published recently [YANG]. Its syntax is loosely based on=20 > SMIng [RFC3216]. >=20 > Alternatively, the last sentence can be removed. >=20 > >=20 > > T3. Section 8.4:=20 > >=20 > > > Each embedded element must declare the namespace of > > the corresponding module using the @ns attribute. > >=20 > > Use capitalized MUST.=20 >=20 > OK >=20 > >=20 > > T4. Section 10.13 > >=20 > > This statement MAY be ignored. Otherwise, it is mapped to the DTD=20 > > compatibility element and ARGUMENT=20 > becomes its text. > >=20 > > What does the second sentence mean? What to do when mapping or what=20 > > not to do? >=20 > OLD >=20 > This statement MAY be ignored. Otherwise, it is mapped to=20 > the DTD compatibility element and ARGUMENT=20 > becomes its text. >=20 > NEW >=20 > This statement is mapped to the DTD compatibility element=20 > and ARGUMENT becomes its text. > =20 > >=20 > > T5. Same question as above for 10.47 > >=20 >=20 > The same change, mutatis mutandis. >=20 > > T6. Section 10.56:=20 > >=20 > > > Implementations MAY ignore this statement. > >=20 > > Why? >=20 > You are right, I'll remove this sentence. >=20 > >=20 > > T7. Section 10.60:=20 > >=20 > > This statement is not mapped to the output schema. However, an=20 > > implementation SHOULD check that it is compatible with the YANG=20 > > version declared by the statement (currently version 1). > >=20 > > What should an implementation do if the yang-version is not=20 > compatible? > > (which may happen in the future) >=20 > OLD: >=20 > This statement is not mapped to the output schema. However,=20 > an implementation SHOULD check that it is compatible with the=20 > YANG version declared by the statement (currently version 1). >=20 > NEW: >=20 > This statement is not mapped to the output schema. However,=20 > an implementation SHOULD check that it is compatible with the=20 > YANG version declared by the statement (currently version 1).=20 > In the case of a mismatch, the implementation SHOULD report=20 > an error and terminate. >=20 > >=20 > > T8. Section 11: > >=20 > > In general, the second mapping step has to accomplish the following=20 > > three tasks: > >=20 > > What does 'In general' mean here? Are there exceptions? Which ones?=20 > >=20 >=20 > OLD: >=20 > In general, the second mapping step has to accomplish the=20 > following three tasks: >=20 > NEW: >=20 > The second mapping step has to accomplish the following three general > tasks: >=20 > >=20 > > E1. Introduction: s/SNMP Management Information Bases (MIBs)/SNMP=20 > > Management Information Base (MIB) modules/ >=20 > OK >=20 > >=20 > > E2. Expand acronyms at the first occurrence: DSRL, etc. >=20 > Will do. >=20 > >=20 > > E3.In section 3: s/the inverse mapping from DSDL to YANG beyond the=20 > > scope of this document/the inverse mapping from DSDL to=20 > YANG is beyond=20 > > the scope of this document/ >=20 > OK >=20 > >=20 > > E4. Section 4 - reference for ISO/IEC 19757, RelaxNG,=20 > Schematron, DSRL=20 > > are desirable in the introduction part of the section. >=20 > I will put them there. > =20 > >=20 > > E5. I see no reason to list the URIs separately and format them=20 > > separately then the rest of the Informative references.=20 > Actually [XSD]=20 > > is also referenced by an URI, although included with the other=20 > > references. >=20 > This is how xml2rfc handles hyperlinks (). I don't like=20 > it either, so I will change them to standard informational references. > =20 > >=20 > > E6. In section 8.2 s/SNMP MIBs/SNMP MIB modules/ >=20 > OK >=20 > >=20 > > E7. The non-usage of quotation marks in the titles of=20 > subsections in=20 > > 10 is confusing. For example should not 10.11 be The 'container'=20 > > Statement rather than The container statement - so that the=20 > use of the=20 > > noun container in the text can be differentiated from the=20 > name of the=20 > > statement? Or in 10.12 we have The default Statement as the=20 > title of=20 > > the subsection while the text of the section speaks about=20 > the 'default' > > statement. >=20 > I actually thought about this in an early stage but then=20 > decided to follow the suit of the YANG draft where the=20 > (double) quotes are omited in section titles, too. I will add=20 > the single quotes to titles. >=20 > >=20 > > E8. Section 12: s/we will denote CONTELEM/we will call CONTELEM/ >=20 > I suggest this: >=20 > OLD: >=20 > In the rest of this section, we will denote CONTELEM the name=20 > of this context element properly qualified with its namespace prefix. >=20 > NEW: >=20 > In the rest of this section, CONTELEM will denote the name of=20 > this context element properly qualified with its namespace prefix. >=20 > >=20 > > E9. The IANA considerations section mentions registering three=20 > > namespace URIs, but then lists only two. >=20 > I got rid of one between -05 and -06 and forgot to update the count. >=20 > >=20 > > E10. Make explicit that Appendix D will be removed at document=20 > > publication. >=20 > OK, I will add an instruction to the RFC Editor. >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C >=20 From lhotka@cesnet.cz Mon Aug 23 01:17:11 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F3DC3A6908 for ; Mon, 23 Aug 2010 01:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 PaMNwOhCMcPi for ; Mon, 23 Aug 2010 01:17:10 -0700 (PDT) Received: from trail.lhotka.cesnet.cz (trail.lhotka.cesnet.cz [195.113.161.162]) by core3.amsl.com (Postfix) with ESMTP id C7AAF3A67CC for ; Mon, 23 Aug 2010 01:17:09 -0700 (PDT) Received: from localhost (missotis.lhotkovi.cz [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.cesnet.cz (Postfix) with ESMTPSA id BA8DA3E048F; Mon, 23 Aug 2010 10:17:38 +0200 (CEST) From: Ladislav Lhotka To: "Romascanu\, Dan \(Dan\)" , NETMOD Working Group In-Reply-To: References: <87y6c22yix.fsf@cesnet.cz> User-Agent: Notmuch/0.3.1-59-g676d251 (http://notmuchmail.org) Emacs/23.1.1 (i486-pc-linux-gnu) Mail-Followup-To: "Romascanu\, Dan \(Dan\)" , NETMOD Working Group Date: Mon, 23 Aug 2010 10:17:38 +0200 Message-ID: <87eidpzqsd.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] AD review of draft-ietf-netmod-dsdl-map X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 08:17:11 -0000 On Sun, 22 Aug 2010 17:10:58 +0200, "Romascanu, Dan (Dan)" wrote: > Hi Lada, > > Thank you for your answers. All the changes proposed by you in this mail > are fine with me with the exception of the change in answer to my > comment T2. In that case I would suggest that you make the change > proposed by Juergen. I'd also like to communicate the fact that NETMOD not only was chartered to deliver but indeed delivered the language. I propose the following reformulation of Juergen's text: The NETMOD Working Group was chartered to design a modeling language defining the semantics of operational data, configuration data, event notifications and operations, with focus on "human-friendliness", i.e., readability and ease of use. The result is the YANG data modeling language [YANG], which now serves for the normative description of NETCONF data models. Is this wording acceptable? Thanks, Lada > > Thanks and Regards, > > Dan > > > > -----Original Message----- > > From: Ladislav Lhotka [mailto:lhotka@cesnet.cz] > > Sent: Thursday, August 19, 2010 10:28 PM > > To: Romascanu, Dan (Dan); NETMOD Working Group > > Subject: Re: [netmod] AD review of draft-ietf-netmod-dsdl-map > > > > Hi Dan, > > > > thank you for the review, I'll roll out the -07 revision > > soon. Please see my responses and suggested changes inline. > > > > Lada > > > > On Thu, 19 Aug 2010 18:56:55 +0200, "Romascanu, Dan (Dan)" > > wrote: > > > Please find below my AD review for > > draft-ietf-netmod-dsdl-map-06.txt. > > > I believe that a revised I-D is needed before proceeding to > > IETF Last > > > Call. Also, you need to answer issue T1 either by moving > > the reference > > > to 5013 to Informational, or by specifying the downref in the IETF > > > Last Call. > > > > > > The comments are divided into Technical and Editorial. > > > > > > > > > T1. There is a normative reference to RFC 5013 which is > > Informational. > > > This is a downref. If this reference must be normative, the downref > > > must be explicitly mentioned in the IETF Last Call. Is this > > the intention? > > > > This reference can be moved to Informational. I just wasn't > > aware of this downref issue. > > > > > > > > T2. Introduction > > > > > > The NETMOD Working Group was chartered to address this problem by > > > defining a new human-friendly modeling language based on SMIng > > > [RFC3216] and called YANG [YANG]. > > > > > > I do not believe that this statement is true. There was no > > requirement > > > in the charter to base the YANG on SMIng. > > > > Is this better? (I hope the text will eventually refer to the > > YANG RFC). > > > > OLD: > > > > The NETMOD Working Group was chartered to address this > > problem by defining a new human-friendly modeling language > > based on SMIng [RFC3216] and called YANG [YANG]. > > > > NEW: > > > > The NETMOD Working Group was chartered to address this > > problem by defining a new human-friendly data modeling > > language called YANG. The definition of YANG version 1 was > > published recently [YANG]. Its syntax is loosely based on > > SMIng [RFC3216]. > > > > Alternatively, the last sentence can be removed. > > > > > > > > T3. Section 8.4: > > > > > > > Each embedded element must declare the namespace of > > > the corresponding module using the @ns attribute. > > > > > > Use capitalized MUST. > > > > OK > > > > > > > > T4. Section 10.13 > > > > > > This statement MAY be ignored. Otherwise, it is mapped to the DTD > > > compatibility element and ARGUMENT > > becomes its text. > > > > > > What does the second sentence mean? What to do when mapping or what > > > not to do? > > > > OLD > > > > This statement MAY be ignored. Otherwise, it is mapped to > > the DTD compatibility element and ARGUMENT > > becomes its text. > > > > NEW > > > > This statement is mapped to the DTD compatibility element > > and ARGUMENT becomes its text. > > > > > > > > T5. Same question as above for 10.47 > > > > > > > The same change, mutatis mutandis. > > > > > T6. Section 10.56: > > > > > > > Implementations MAY ignore this statement. > > > > > > Why? > > > > You are right, I'll remove this sentence. > > > > > > > > T7. Section 10.60: > > > > > > This statement is not mapped to the output schema. However, an > > > implementation SHOULD check that it is compatible with the YANG > > > version declared by the statement (currently version 1). > > > > > > What should an implementation do if the yang-version is not > > compatible? > > > (which may happen in the future) > > > > OLD: > > > > This statement is not mapped to the output schema. However, > > an implementation SHOULD check that it is compatible with the > > YANG version declared by the statement (currently version 1). > > > > NEW: > > > > This statement is not mapped to the output schema. However, > > an implementation SHOULD check that it is compatible with the > > YANG version declared by the statement (currently version 1). > > In the case of a mismatch, the implementation SHOULD report > > an error and terminate. > > > > > > > > T8. Section 11: > > > > > > In general, the second mapping step has to accomplish the following > > > three tasks: > > > > > > What does 'In general' mean here? Are there exceptions? Which ones? > > > > > > > OLD: > > > > In general, the second mapping step has to accomplish the > > following three tasks: > > > > NEW: > > > > The second mapping step has to accomplish the following three general > > tasks: > > > > > > > > E1. Introduction: s/SNMP Management Information Bases (MIBs)/SNMP > > > Management Information Base (MIB) modules/ > > > > OK > > > > > > > > E2. Expand acronyms at the first occurrence: DSRL, etc. > > > > Will do. > > > > > > > > E3.In section 3: s/the inverse mapping from DSDL to YANG beyond the > > > scope of this document/the inverse mapping from DSDL to > > YANG is beyond > > > the scope of this document/ > > > > OK > > > > > > > > E4. Section 4 - reference for ISO/IEC 19757, RelaxNG, > > Schematron, DSRL > > > are desirable in the introduction part of the section. > > > > I will put them there. > > > > > > > > E5. I see no reason to list the URIs separately and format them > > > separately then the rest of the Informative references. > > Actually [XSD] > > > is also referenced by an URI, although included with the other > > > references. > > > > This is how xml2rfc handles hyperlinks (). I don't like > > it either, so I will change them to standard informational references. > > > > > > > > E6. In section 8.2 s/SNMP MIBs/SNMP MIB modules/ > > > > OK > > > > > > > > E7. The non-usage of quotation marks in the titles of > > subsections in > > > 10 is confusing. For example should not 10.11 be The 'container' > > > Statement rather than The container statement - so that the > > use of the > > > noun container in the text can be differentiated from the > > name of the > > > statement? Or in 10.12 we have The default Statement as the > > title of > > > the subsection while the text of the section speaks about > > the 'default' > > > statement. > > > > I actually thought about this in an early stage but then > > decided to follow the suit of the YANG draft where the > > (double) quotes are omited in section titles, too. I will add > > the single quotes to titles. > > > > > > > > E8. Section 12: s/we will denote CONTELEM/we will call CONTELEM/ > > > > I suggest this: > > > > OLD: > > > > In the rest of this section, we will denote CONTELEM the name > > of this context element properly qualified with its namespace prefix. > > > > NEW: > > > > In the rest of this section, CONTELEM will denote the name of > > this context element properly qualified with its namespace prefix. > > > > > > > > E9. The IANA considerations section mentions registering three > > > namespace URIs, but then lists only two. > > > > I got rid of one between -05 and -06 and forgot to update the count. > > > > > > > > E10. Make explicit that Appendix D will be removed at document > > > publication. > > > > OK, I will add an instruction to the RFC Editor. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CESNET > > PGP Key ID: E74E8C0C > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From dromasca@avaya.com Mon Aug 23 04:17:16 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2167E3A672E for ; Mon, 23 Aug 2010 04:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1nb1ii5qpsR for ; Mon, 23 Aug 2010 04:17:14 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 28B083A682F for ; Mon, 23 Aug 2010 04:17:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,256,1280721600"; d="scan'208";a="31149588" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 23 Aug 2010 07:17:47 -0400 X-IronPort-AV: E=Sophos;i="4.56,257,1280721600"; d="scan'208";a="506693449" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Aug 2010 07:17:46 -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: Mon, 23 Aug 2010 13:17:30 +0200 Message-ID: In-Reply-To: <87eidpzqsd.fsf@cesnet.cz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] AD review of draft-ietf-netmod-dsdl-map Thread-Index: ActCm6kHsLQ0J1W7RmWH1JtWoI0gZAAGEllw References: <87y6c22yix.fsf@cesnet.cz> <87eidpzqsd.fsf@cesnet.cz> From: "Romascanu, Dan (Dan)" To: "Ladislav Lhotka" , "NETMOD Working Group" Subject: Re: [netmod] AD review of draft-ietf-netmod-dsdl-map X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 11:17:16 -0000 No problem for me with this change of wording.=20 Dan > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@cesnet.cz]=20 > Sent: Monday, August 23, 2010 11:18 AM > To: Romascanu, Dan (Dan); NETMOD Working Group > Subject: RE: [netmod] AD review of draft-ietf-netmod-dsdl-map >=20 > On Sun, 22 Aug 2010 17:10:58 +0200, "Romascanu, Dan (Dan)"=20 > wrote: > > Hi Lada, > >=20 > > Thank you for your answers. All the changes proposed by you in this=20 > > mail are fine with me with the exception of the change in=20 > answer to my=20 > > comment T2. In that case I would suggest that you make the change=20 > > proposed by Juergen. >=20 > I'd also like to communicate the fact that NETMOD not only=20 > was chartered to deliver but indeed delivered the language. I=20 > propose the following reformulation of Juergen's text: >=20 > The NETMOD Working Group was chartered to design a=20 > modeling language > defining the semantics of operational data, configuration data, > event notifications and operations, with focus on > "human-friendliness", i.e., readability and ease of use.=20 > The result > is the YANG data modeling language [YANG], which now=20 > serves for the > normative description of NETCONF data models. >=20 > Is this wording acceptable? >=20 > Thanks, Lada >=20 > >=20 > > Thanks and Regards, > >=20 > > Dan > > =20 > >=20 > > > -----Original Message----- > > > From: Ladislav Lhotka [mailto:lhotka@cesnet.cz] > > > Sent: Thursday, August 19, 2010 10:28 PM > > > To: Romascanu, Dan (Dan); NETMOD Working Group > > > Subject: Re: [netmod] AD review of draft-ietf-netmod-dsdl-map > > >=20 > > > Hi Dan, > > >=20 > > > thank you for the review, I'll roll out the -07 revision soon.=20 > > > Please see my responses and suggested changes inline. > > >=20 > > > Lada > > >=20 > > > On Thu, 19 Aug 2010 18:56:55 +0200, "Romascanu, Dan (Dan)"=20 > > > wrote: > > > > Please find below my AD review for > > > draft-ietf-netmod-dsdl-map-06.txt.=20 > > > > I believe that a revised I-D is needed before proceeding to > > > IETF Last > > > > Call. Also, you need to answer issue T1 either by moving > > > the reference > > > > to 5013 to Informational, or by specifying the downref=20 > in the IETF=20 > > > > Last Call. > > > >=20 > > > > The comments are divided into Technical and Editorial.=20 > > > >=20 > > > >=20 > > > > T1. There is a normative reference to RFC 5013 which is > > > Informational. > > > > This is a downref. If this reference must be normative, the=20 > > > > downref must be explicitly mentioned in the IETF Last Call. Is=20 > > > > this > > > the intention? > > >=20 > > > This reference can be moved to Informational. I just=20 > wasn't aware of=20 > > > this downref issue. > > >=20 > > > >=20 > > > > T2. Introduction > > > >=20 > > > > The NETMOD Working Group was chartered to address this=20 > problem by=20 > > > > defining a new human-friendly modeling language based on SMIng=20 > > > > [RFC3216] and called YANG [YANG]. > > > >=20 > > > > I do not believe that this statement is true. There was no > > > requirement > > > > in the charter to base the YANG on SMIng. > > >=20 > > > Is this better? (I hope the text will eventually refer to=20 > the YANG=20 > > > RFC). > > >=20 > > > OLD: > > >=20 > > > The NETMOD Working Group was chartered to address this problem by=20 > > > defining a new human-friendly modeling language based on SMIng=20 > > > [RFC3216] and called YANG [YANG]. > > >=20 > > > NEW: > > >=20 > > > The NETMOD Working Group was chartered to address this problem by=20 > > > defining a new human-friendly data modeling language called YANG.=20 > > > The definition of YANG version 1 was published recently=20 > [YANG]. Its=20 > > > syntax is loosely based on SMIng [RFC3216]. > > >=20 > > > Alternatively, the last sentence can be removed. > > >=20 > > > >=20 > > > > T3. Section 8.4:=20 > > > >=20 > > > > > Each embedded element must declare the=20 > namespace=20 > > > > > of > > > > the corresponding module using the @ns attribute. > > > >=20 > > > > Use capitalized MUST.=20 > > >=20 > > > OK > > >=20 > > > >=20 > > > > T4. Section 10.13 > > > >=20 > > > > This statement MAY be ignored. Otherwise, it is mapped=20 > to the DTD=20 > > > > compatibility element and ARGUMENT > > > becomes its text. > > > >=20 > > > > What does the second sentence mean? What to do when mapping or=20 > > > > what not to do? > > >=20 > > > OLD > > >=20 > > > This statement MAY be ignored. Otherwise, it is mapped=20 > to the DTD=20 > > > compatibility element and ARGUMENT becomes its=20 > > > text. > > >=20 > > > NEW > > >=20 > > > This statement is mapped to the DTD compatibility element=20 > > > and ARGUMENT becomes its text. > > > =20 > > > >=20 > > > > T5. Same question as above for 10.47 > > > >=20 > > >=20 > > > The same change, mutatis mutandis. > > >=20 > > > > T6. Section 10.56:=20 > > > >=20 > > > > > Implementations MAY ignore this statement. > > > >=20 > > > > Why? > > >=20 > > > You are right, I'll remove this sentence. > > >=20 > > > >=20 > > > > T7. Section 10.60:=20 > > > >=20 > > > > This statement is not mapped to the output schema. However, an=20 > > > > implementation SHOULD check that it is compatible with the YANG=20 > > > > version declared by the statement (currently version 1). > > > >=20 > > > > What should an implementation do if the yang-version is not > > > compatible? > > > > (which may happen in the future) > > >=20 > > > OLD: > > >=20 > > > This statement is not mapped to the output schema. However, an=20 > > > implementation SHOULD check that it is compatible with the YANG=20 > > > version declared by the statement (currently version 1). > > >=20 > > > NEW: > > >=20 > > > This statement is not mapped to the output schema. However, an=20 > > > implementation SHOULD check that it is compatible with the YANG=20 > > > version declared by the statement (currently version 1). > > > In the case of a mismatch, the implementation SHOULD=20 > report an error=20 > > > and terminate. > > >=20 > > > >=20 > > > > T8. Section 11: > > > >=20 > > > > In general, the second mapping step has to accomplish the=20 > > > > following three tasks: > > > >=20 > > > > What does 'In general' mean here? Are there exceptions?=20 > Which ones?=20 > > > >=20 > > >=20 > > > OLD: > > >=20 > > > In general, the second mapping step has to accomplish the=20 > following=20 > > > three tasks: > > >=20 > > > NEW: > > >=20 > > > The second mapping step has to accomplish the following three=20 > > > general > > > tasks: > > >=20 > > > >=20 > > > > E1. Introduction: s/SNMP Management Information Bases=20 > (MIBs)/SNMP=20 > > > > Management Information Base (MIB) modules/ > > >=20 > > > OK > > >=20 > > > >=20 > > > > E2. Expand acronyms at the first occurrence: DSRL, etc. > > >=20 > > > Will do. > > >=20 > > > >=20 > > > > E3.In section 3: s/the inverse mapping from DSDL to YANG beyond=20 > > > > the scope of this document/the inverse mapping from DSDL to > > > YANG is beyond > > > > the scope of this document/ > > >=20 > > > OK > > >=20 > > > >=20 > > > > E4. Section 4 - reference for ISO/IEC 19757, RelaxNG, > > > Schematron, DSRL > > > > are desirable in the introduction part of the section. > > >=20 > > > I will put them there. > > > =20 > > > >=20 > > > > E5. I see no reason to list the URIs separately and format them=20 > > > > separately then the rest of the Informative references. > > > Actually [XSD] > > > > is also referenced by an URI, although included with the other=20 > > > > references. > > >=20 > > > This is how xml2rfc handles hyperlinks (). I don't like it=20 > > > either, so I will change them to standard informational=20 > references. > > > =20 > > > >=20 > > > > E6. In section 8.2 s/SNMP MIBs/SNMP MIB modules/ > > >=20 > > > OK > > >=20 > > > >=20 > > > > E7. The non-usage of quotation marks in the titles of > > > subsections in > > > > 10 is confusing. For example should not 10.11 be The=20 > 'container'=20 > > > > Statement rather than The container statement - so that the > > > use of the > > > > noun container in the text can be differentiated from the > > > name of the > > > > statement? Or in 10.12 we have The default Statement as the > > > title of > > > > the subsection while the text of the section speaks about > > > the 'default' > > > > statement. > > >=20 > > > I actually thought about this in an early stage but then=20 > decided to=20 > > > follow the suit of the YANG draft where the > > > (double) quotes are omited in section titles, too. I will add the=20 > > > single quotes to titles. > > >=20 > > > >=20 > > > > E8. Section 12: s/we will denote CONTELEM/we will call CONTELEM/ > > >=20 > > > I suggest this: > > >=20 > > > OLD: > > >=20 > > > In the rest of this section, we will denote CONTELEM the name of=20 > > > this context element properly qualified with its namespace prefix. > > >=20 > > > NEW: > > >=20 > > > In the rest of this section, CONTELEM will denote the=20 > name of this=20 > > > context element properly qualified with its namespace prefix. > > >=20 > > > >=20 > > > > E9. The IANA considerations section mentions registering three=20 > > > > namespace URIs, but then lists only two. > > >=20 > > > I got rid of one between -05 and -06 and forgot to update=20 > the count. > > >=20 > > > >=20 > > > > E10. Make explicit that Appendix D will be removed at document=20 > > > > publication. > > >=20 > > > OK, I will add an instruction to the RFC Editor. > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > >=20 > > > -- > > > Ladislav Lhotka, CESNET > > > PGP Key ID: E74E8C0C > > >=20 >=20 > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C >=20 From root@core3.amsl.com Mon Aug 23 12:45:01 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 92E163A6ADA; Mon, 23 Aug 2010 12:45: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: <20100823194501.92E163A6ADA@core3.amsl.com> Date: Mon, 23 Aug 2010 12:45:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-dsdl-map-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content Author(s) : L. Lhotka, et al. Filename : draft-ietf-netmod-dsdl-map-07.txt Pages : 111 Date : 2010-08-23 This draft specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO/IEC 19757. The following DSDL schema languages are addressed by the mapping: RELAX NG, Schematron and Document Schema Renaming Language (DSRL). The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type - datastore content, NETCONF message etc. Procedures for schema-based validation of such documents are also discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-dsdl-map-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-netmod-dsdl-map-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-23123331.I-D@ietf.org> --NextPart-- From iesg-secretary@ietf.org Tue Aug 24 10:56:52 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37D383A6BA6; Tue, 24 Aug 2010 10:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8bzuJEFfrwD; Tue, 24 Aug 2010 10:56:51 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CA2E3A6B8C; Tue, 24 Aug 2010 10:56:51 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no Message-ID: <20100824175651.23017.87413.idtracker@localhost> Date: Tue, 24 Aug 2010 10:56:51 -0700 X-Mailman-Approved-At: Tue, 24 Aug 2010 11:22:05 -0700 Cc: netmod@ietf.org Subject: [netmod] Last Call: (Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 17:56:52 -0000 The IESG has received a request from the NETCONF Data Modeling Language WG (netmod) to consider the following document: - 'Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-09-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netmod-dsdl-map/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netmod-dsdl-map/ No IPR declarations were found that appear related to this I-D. From dromasca@avaya.com Thu Aug 26 07:03:32 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09AD3A6970 for ; Thu, 26 Aug 2010 07:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4NRH1+3HsiW for ; Thu, 26 Aug 2010 07:03:27 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 102E43A697A for ; Thu, 26 Aug 2010 07:03:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,273,1280721600"; d="scan'208";a="31757090" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 26 Aug 2010 10:03:55 -0400 X-IronPort-AV: E=Sophos;i="4.56,273,1280721600"; d="scan'208";a="508391426" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Aug 2010 10:03:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Aug 2010 16:03:43 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-netmod-yang-usage-10 Thread-Index: ActFJrehQrPIwQUQSlu11zUkLsu/HAAAMI3A From: "Romascanu, Dan (Dan)" To: "NETMOD Working Group" Subject: [netmod] FW: draft-ietf-netmod-yang-usage-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 14:03:32 -0000 =20 -----Original Message----- From: Jari Arkko [mailto:jari.arkko@ericsson.com]=20 Sent: Thursday, August 26, 2010 4:58 PM To: draft-ietf-netmod-yang-usage@tools.ietf.org; Romascanu, Dan (Dan) Cc: Ari Ker=E4nen Subject: draft-ietf-netmod-yang-usage-10 My colleague Ari had a question about this draft: ---- 4.6. Lifecycle Management If submodules are used, then the document containing the main module MUST be updated so that the main module revision date is equal or more recent than the revision date of any submodule which is (directly or indirectly) included by the main module. Does this mean that if all the documents are RFCs and a submodule = document is updated by a new RFC, also the main module RFC needs to be = bis'ed even if there are no changes? From j.schoenwaelder@jacobs-university.de Thu Aug 26 07:13:28 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2BC73A681A for ; Thu, 26 Aug 2010 07:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.633 X-Spam-Level: X-Spam-Status: No, score=-101.633 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DF34W6bpFEYc for ; Thu, 26 Aug 2010 07:13:27 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 076363A67E5 for ; Thu, 26 Aug 2010 07:13:27 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C05B8C0016; Thu, 26 Aug 2010 16:13:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id x6ZQP5QO3lXn; Thu, 26 Aug 2010 16:13:57 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24071C0014; Thu, 26 Aug 2010 16:13:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6B4C91465C0A; Thu, 26 Aug 2010 16:13:37 +0200 (CEST) Date: Thu, 26 Aug 2010 16:13:37 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20100826141337.GB6056@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , NETMOD Working Group References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] FW: draft-ietf-netmod-yang-usage-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 14:13:28 -0000 On Thu, Aug 26, 2010 at 04:03:43PM +0200, Romascanu, Dan (Dan) wrote: > > > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@ericsson.com] > Sent: Thursday, August 26, 2010 4:58 PM > To: draft-ietf-netmod-yang-usage@tools.ietf.org; Romascanu, Dan (Dan) > Cc: Ari Ker?nen > Subject: draft-ietf-netmod-yang-usage-10 > > My colleague Ari had a question about this draft: > > ---- > > 4.6. Lifecycle Management > > If submodules are used, then the document containing the main module > MUST be updated so that the main module revision date is equal or > more recent than the revision date of any submodule which is > (directly or indirectly) included by the main module. > > Does this mean that if all the documents are RFCs and a submodule document is updated by a new RFC, also the main module RFC needs to be bis'ed even if there are no changes? That is what I think the text says. This, of course, is not practical. However, a main module just consisting of includes could perhaps reasonably given to IANA and than IANA would maintain the includes and the revision log, pretty much like they do for the interface type MIB module. That said, the usage of submodules in the IETF space is something we have to get experience with. They might be a nice tool to keep the namespaces clean and mean but we just have not yet much operational experience with this approach yet. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Thu Aug 26 08:39:04 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C04D3A697D for ; Thu, 26 Aug 2010 08:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6] 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 NJF64TeAnJfp for ; Thu, 26 Aug 2010 08:39:03 -0700 (PDT) Received: from smtp102.sbc.mail.gq1.yahoo.com (smtp102.sbc.mail.gq1.yahoo.com [67.195.15.61]) by core3.amsl.com (Postfix) with SMTP id D7F9A3A687C for ; Thu, 26 Aug 2010 08:39:03 -0700 (PDT) Received: (qmail 40175 invoked from network); 26 Aug 2010 15:39:33 -0000 Received: from [192.168.0.9] (ietf@75.84.164.152 with plain) by smtp102.sbc.mail.gq1.yahoo.com with SMTP; 26 Aug 2010 08:39:33 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: _IQ8LlcVM1mL98Uz91TxQBFx7x471xg8eqjKnXbEqawTNOY XxeO4Duv5vFTTizqy9q2ptAohWo8HAa020hwPGZoE8qnRXQHQ3111fYlYXIG 6_CIcmSlSvbYsZuucaAcBGkMuJzwksVkbJHgMBz_ZjI3rVjmJoOJSRSzBdCb eMP3Arr4p.t4VitWR5AfyOzULDtnmOKi881IyIfVHTv5PMtgyc0bTwB1XAPp EVQQYKf68BPhAWSfl94ByaHN1jYDSDtYPxkfk15KI_1iPVaBP445kB9gMlPB 3WEqFAQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C768AB4.9020003@andybierman.com> Date: Thu, 26 Aug 2010 08:39:32 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" , NETMOD Working Group References: <20100826141337.GB6056@elstar.local> In-Reply-To: <20100826141337.GB6056@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] FW: draft-ietf-netmod-yang-usage-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 15:39:04 -0000 On 08/26/2010 07:13 AM, Juergen Schoenwaelder wrote: > On Thu, Aug 26, 2010 at 04:03:43PM +0200, Romascanu, Dan (Dan) wrote: >> >> >> -----Original Message----- >> From: Jari Arkko [mailto:jari.arkko@ericsson.com] >> Sent: Thursday, August 26, 2010 4:58 PM >> To: draft-ietf-netmod-yang-usage@tools.ietf.org; Romascanu, Dan (Dan) >> Cc: Ari Ker?nen >> Subject: draft-ietf-netmod-yang-usage-10 >> >> My colleague Ari had a question about this draft: >> >> ---- >> >> 4.6. Lifecycle Management >> >> If submodules are used, then the document containing the main module >> MUST be updated so that the main module revision date is equal or >> more recent than the revision date of any submodule which is >> (directly or indirectly) included by the main module. >> >> Does this mean that if all the documents are RFCs and a submodule document is updated by a new RFC, also the main module RFC needs to be bis'ed even if there are no changes? > > That is what I think the text says. This, of course, is not > practical. However, a main module just consisting of includes could > perhaps reasonably given to IANA and than IANA would maintain the > includes and the revision log, pretty much like they do for the > interface type MIB module. > > That said, the usage of submodules in the IETF space is something we > have to get experience with. They might be a nice tool to keep the > namespaces clean and mean but we just have not yet much operational > experience with this approach yet. > Submodules are not practical for the IETF to use. This has been understood (by me anyway) from the start. If the main module needs an 'include-stmt' added, then it needs to be republished in a new RFC. Period. Conformance in the IETF and this industry is based on RFC numbers, not revision dates buried within some code component. Whether additional online resources exist is another matter. > /js > Andy From mbj@tail-f.com Mon Aug 30 03:45:30 2010 Return-Path: X-Original-To: netmod@core3.amsl.com Delivered-To: netmod@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE773A67A3 for ; Mon, 30 Aug 2010 03:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_28=0.6] 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 IfatR99+9FzK for ; Mon, 30 Aug 2010 03:45:28 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A985E3A6781 for ; Mon, 30 Aug 2010 03:45:26 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 18315616004 for ; Mon, 30 Aug 2010 12:45:56 +0200 (CEST) Date: Mon, 30 Aug 2010 12:45:55 +0200 (CEST) Message-Id: <20100830.124555.66370838.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] Review of draft-linowski-netmod-yang-abstract-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 10:45:30 -0000 Hi, I have reviewed the document draft-linowski-netmod-yang-abstract-03.txt. I have ( tried to :) stay away from my opinion on the features introduced; I think I have made those clear already. ------------------------------------------------------------ s 1.3. bullet 3. s/It is not necessary to explicitly add a key statement to containers/ It is not necessary to explicitly add a key statement to lists/ ------------------------------------------------------------ s 1.5.1. yang module udmcore Is this module supposed to be an example? If so, the namespace should probably be something like http://example.com/udmcore. Same comment applies to modules "hardware-entities" and "hw". ------------------------------------------------------------ s 2.2. In the list of statements and cardinality in this section and others, I suggest you use the prefixed notation for the new statements, to make it easier to follow. E.g.: OLD: +---------------+-------------+ | substatement | cardinality | +---------------+-------------+ | abstract | 0..1 | | anyxml | 0..n | NEW: +---------------+-------------+ | substatement | cardinality | +---------------+-------------+ | ct:abstract | 0..1 | | anyxml | 0..n | etc ------------------------------------------------------------ s 2.2. Complex-type definitions do not create nodes in the management information tree. The term "management information tree" is not defined. It is used in other places as well. Did you mean "schema tree", as defined in YANG? ------------------------------------------------------------ s 2.3, 2.4. The lists of substatements include "type", I think it should be ct:instance-type. ------------------------------------------------------------ s 2.4. Common YANG statements may be used as substatements of the "element" statement. What is the "element" statement? The term "element" is used in other places as well, e.g.: In case the instance list represents configuration data, the used complex type of an element MUST have an element key. I suggest you go through the document and change this to the appropriate term. ------------------------------------------------------------ s 2.6. OLD: The complex type serves only as a base type for derived concrete complex types and cannot be used as a type for an instance in NETCONF payload. NEW: An abstract complex type serves only as a base type for derived concrete complex types and cannot be used as a type for an instance in NETCONF payload. ------------------------------------------------------------ s 2.8. OLD: The suggested namespace prefix is "ct". I suggest you use the prefix "cti", in order to not confuse complex-type-instance with complex-type. ------------------------------------------------------------ s 2.8. It seems the type encoding rules impose a strict order among the XML elements. Note that YANG does not impose such a strict order, so I suggest you clearly state that these rules change the rules defined by YANG. Also, what happens if class B derives from class A, and class B defines the keys? In YANG, the keys are always encoded first, but this text says that class A's leafs are encoded before class B's leafs. This must be clarified. Will the meta-data "cti:type" element be encoded before the keys? This must be clarified. ------------------------------------------------------------ s 2.8. You are defining new NETCONF error-tags. I think you meant to use error-app-tag. I think the error-tag should be "bad-attribute", and error-app-tag "wrong-type" (or maybe "wrong-complex-type"). For "missing-type", I suggest you instead use the standard error-tag "missing-attribute". ------------------------------------------------------------ s 2.9. Why do you define the "complex-type" feature? Why is this feature important to a client? How will the client adapt depending on if this feature is present or not? IMO, it is not needed at all. If the server advertises support for a module that uses complex-types, it obvioulsy implements complex-types. ------------------------------------------------------------ s 2.9. Change the name of "complex-types" to "ietf-complex-types" or "ietf-experimental-complex-types". ------------------------------------------------------------ s 2.12. OLD: o New data definition statements MAY be added to a complex type only if: * they are not mandatory and * they are not conditionally dependent on a new feature (i.e., have an "if-feature" statement, which refers to a new feature). This is probably not correct. I think you mean: NEW: o New data definition statements MAY be added to a complex type only if: * they are not mandatory or * they are conditionally dependent on a new feature (i.e., have an "if-feature" statement, which refers to a new feature). ------------------------------------------------------------ s 2.13 s/namespace/XML namespace/ ? ------------------------------------------------------------ s 2.13.2 Is it correct that if one uses recursive complex types, then the resulting hiearchy cannot be augmented? Isn't this a pretty severe restriction? If nothing else, I think this restriction should be noted when recursive complex types are defined. ------------------------------------------------------------ s 2.13.3 A module might not want to support all complex types derived from a base class defined in another module. Did you mean s/module/server/? Note that deviations are used to indicate how a server implementation deviates from a module. Deviations cannot be used in normal modules. ------------------------------------------------------------ s 3.1 Typed instance identifier relationships are an addition to the relationship types already defined in YANG, where the leafref relationship is location dependent, and the instance-identifier is not type-safe. Please explain what you mean with "type-safe". It is true that there is no formal way of specificying what an i-i can point to in YANG, but it can be defined in the description statement. ------------------------------------------------------------ s 3.2. Please explain the term "scoped name". ------------------------------------------------------------ s 3.2. This extension statement MUST be used as a substatement of the instance-identifier statement. There is no "instance-identifier" statement. Please clarify. ------------------------------------------------------------ Appendix B and C The modules in these Appendicies import "yang-types" and "inet-types". These should be "ietf-yang-types" and "ietf-inet-types". Also, the prefix for ietf-yang-types should be "yang" (not "yt"). ------------------------------------------------------------ Appendix C.1 Second bullet says: o All associations between the concepts (which are not containment) are represented with typed identifiers. That avoids having to refer to a particular location in the tree, which is not mandated by the original model. To be fair; the original model doesn't say that the reference is supposed to be to any place in the tree either. In general, I have a hard time appreciating this (location independent reference) as a feature. I think it introduces more problems than it solves, and there are other ways to solve the underlying problem. ------------------------------------------------------------ If complex-types are used, some of the flexibility of YANG is lost. For example, in your equipment example, suppose vendor X wants to add its own proprietary attributes to all "ManagedHardware". This will not be possible unless all classes derived from ManagedHardware at some point are tracked down, and all ct:instance statements for these classes are augmented with the new attributes. ------------------------------------------------------------ I have checked the main module, "complex-types", and the example modules using pyang. The module ipfix-psamp has a couple of errors: - The type autonomous-system-number is not found (it is called as-number). - It uses the statement "type" instead of ct:instance-type. - There is a syntax error: type instance-identifier {ct :instance-type PhysicalEntity; } ^^^^^^ /martin