From muenz@net.in.tum.de Fri Jul 2 07:32:42 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 1EA113A68B9 for ; Fri, 2 Jul 2010 07:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.346 X-Spam-Level: X-Spam-Status: No, score=-0.346 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+tnfGeYNa2O for ; Fri, 2 Jul 2010 07:32:37 -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 1972C3A67B2 for ; Fri, 2 Jul 2010 07:32:33 -0700 (PDT) Received: from [131.159.14.152] (charlie.net.in.tum.de [131.159.14.152]) by mail.net.in.tum.de (Postfix) with ESMTPSA id B8DC0210FD4D for ; Fri, 2 Jul 2010 16:32:44 +0200 (CEST) Message-ID: <4C2DF896.5050000@net.in.tum.de> Date: Fri, 02 Jul 2010 16:32:54 +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="------------ms080502010906050609010509" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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, 02 Jul 2010 14:32:42 -0000 This is a cryptographically signed message in MIME format. --------------ms080502010906050609010509 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all, The YANG guidelines say: 4.10. Data Types ... For string data types, data definition semantics SHOULD NOT rely on preservation of leading and trailing whitespace characters. So, I assume that leading and trailing whitespaces should be disallowed by the pattern statement if different string node values in a YANG module need to match. What would be the right pattern statement to disallow leading and trailing whitespaces as well as all non-printable characters? Currently, I have: length "1..max"; pattern "\S([#20\c]*\S)?"; Thanks for your help. Gerhard --------------ms080502010906050609010509 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDcwMjE0MzI1NFowIwYJKoZIhvcNAQkEMRYEFLMu 8xel7cI9sQqr/CQNMSYfoLnLMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQCDOC46R5qDRmbzVJSN6vQ8qrGUmxR2NOSlR6WXbrROtZMVU/5UjAR8 5W/Jg1XTE0NoPRrUmLSrD26pKpJnK/gQ3OicTRPckWAF771ewVHZ1DC/E+XXvxDe0kuyS8Iy X0Nj8dBOGTHTK2mEoULlQnlElBZu+ZVKn5FbFdHSKvPEacCSoAzg8UNRBPYzi/Qq1OBT/dEK fjnmJRVRQNYcW4i6TNwULEc4yWTUsjZQnMEBcHnr67W5kLWHdMEJH4aduSJEa+343ayPXVDI e1diwe4w/h/gec9SkV/Xn6LCF6EBivgztfEX1ixW7VkixupsmMbN64WyGWEnTLJSuDJbHsFr AAAAAAAA --------------ms080502010906050609010509-- From andyb@iwl.com Fri Jul 2 07:40:23 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 9F62D3A67A4 for ; Fri, 2 Jul 2010 07:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[AWL=-0.285, 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 ii2LMgrknJcN for ; Fri, 2 Jul 2010 07:40:22 -0700 (PDT) Received: from smtp165.dfw.emailsrvr.com (smtp165.dfw.emailsrvr.com [67.192.241.165]) by core3.amsl.com (Postfix) with ESMTP id 9A7AD3A679C for ; Fri, 2 Jul 2010 07:40:22 -0700 (PDT) Received: from relay6.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay6.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 8C566300A3; Fri, 2 Jul 2010 10:40:33 -0400 (EDT) Received: by relay6.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 41806301A6; Fri, 2 Jul 2010 10:40:33 -0400 (EDT) Message-ID: <4C2DFA65.8070203@iwl.com> Date: Fri, 02 Jul 2010 07:40:37 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Gerhard Muenz References: <4C2DF896.5050000@net.in.tum.de> In-Reply-To: <4C2DF896.5050000@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 14:40:24 -0000 On 07/02/2010 07:32 AM, Gerhard Muenz wrote: > Dear all, > > The YANG guidelines say: > > 4.10. Data Types > > ... > > For string data types, data definition semantics SHOULD NOT rely on > preservation of leading and trailing whitespace characters. > > > So, I assume that leading and trailing whitespaces should be disallowed > by the pattern statement if different string node values in a YANG > module need to match. > > What would be the right pattern statement to disallow leading and > trailing whitespaces as well as all non-printable characters? > > Currently, I have: > > length "1..max"; > pattern "\S([#20\c]*\S)?"; > > Thanks for your help. > > The YANG Guildelines are much more conservative than the YANG spec. That is why they exist -- to prevent YANG from needing these CLRs. For example, YANG allows billion char identifiers, but a standard YANG module can only use 64 character identifiers. The intent of this separation seems to be to allow vendors to be more liberal in their own proprietary YANG usage than standard YANG modules, which need to stick to a common subset of all YANG behavior. > Gerhard > Andy From j.schoenwaelder@jacobs-university.de Fri Jul 2 09:16: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 63FDF3A68E3 for ; Fri, 2 Jul 2010 09:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fs5zkEbwaCE for ; Fri, 2 Jul 2010 09:16:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 481973A67D4 for ; Fri, 2 Jul 2010 09:16:38 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9EA03C0058; Fri, 2 Jul 2010 18:16:49 +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 TvXgbGS4zRtu; Fri, 2 Jul 2010 18:16:48 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E3BFC0010; Fri, 2 Jul 2010 18:16:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 43DD5137874A; Fri, 2 Jul 2010 18:16:45 +0200 (CEST) Date: Fri, 2 Jul 2010 18:16:45 +0200 From: Juergen Schoenwaelder To: Gerhard Muenz Message-ID: <20100702161645.GB50757@elstar.local> Mail-Followup-To: Gerhard Muenz , NETMOD Working Group References: <4C2DF896.5050000@net.in.tum.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C2DF896.5050000@net.in.tum.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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, 02 Jul 2010 16:16:39 -0000 On Fri, Jul 02, 2010 at 04:32:54PM +0200, Gerhard Muenz wrote: > > Dear all, > > The YANG guidelines say: > > 4.10. Data Types > > ... > > For string data types, data definition semantics SHOULD NOT rely on > preservation of leading and trailing whitespace characters. Now that I read this in isolation, I am not sure why we have this rule. I believe things are simpler if a value simply does not change. If we allow white space changes, we make things more complex rather than simpler... > What would be the right pattern statement to disallow leading and > trailing whitespaces as well as all non-printable characters? > > Currently, I have: > > length "1..max"; > pattern "\S([#20\c]*\S)?"; And this kind of proves my point. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Fri Jul 2 09:43: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 4EFC43A68F2 for ; Fri, 2 Jul 2010 09:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAcU9k08n3jK for ; Fri, 2 Jul 2010 09:43:27 -0700 (PDT) Received: from smtp195.iad.emailsrvr.com (smtp195.iad.emailsrvr.com [207.97.245.195]) by core3.amsl.com (Postfix) with ESMTP id 2FB173A63D3 for ; Fri, 2 Jul 2010 09:43:27 -0700 (PDT) Received: from relay29.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay29.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 350251B4822; Fri, 2 Jul 2010 12:43:39 -0400 (EDT) Received: by relay29.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id D8F171B47D3; Fri, 2 Jul 2010 12:43:38 -0400 (EDT) Message-ID: <4C2E1740.4000800@iwl.com> Date: Fri, 02 Jul 2010 09:43:44 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Gerhard Muenz , NETMOD Working Group References: <4C2DF896.5050000@net.in.tum.de> <20100702161645.GB50757@elstar.local> In-Reply-To: <20100702161645.GB50757@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 16:43:28 -0000 On 07/02/2010 09:16 AM, Juergen Schoenwaelder wrote: > On Fri, Jul 02, 2010 at 04:32:54PM +0200, Gerhard Muenz wrote: > >> Dear all, >> >> The YANG guidelines say: >> >> 4.10. Data Types >> >> ... >> >> For string data types, data definition semantics SHOULD NOT rely on >> preservation of leading and trailing whitespace characters. >> > Now that I read this in isolation, I am not sure why we have this > rule. I believe things are simpler if a value simply does not change. > If we allow white space changes, we make things more complex rather > than simpler... > > Except this does not deal with the reality that different XML parser implementations are likely to deal with this issue the same way. We can remove the guideline, and just let users get what they get from implementors. The XML spec says that whitespace is significant, so we can defer to their ownership of the problem. XML says the client can rely on preservation of whitespace, so maybe there is no need to worry about it, even if it is common practice for server code to strip strings before using them. >> What would be the right pattern statement to disallow leading and >> trailing whitespaces as well as all non-printable characters? >> >> Currently, I have: >> >> length "1..max"; >> pattern "\S([#20\c]*\S)?"; >> > And this kind of proves my point. ;-) > > /js > > Andy From j.schoenwaelder@jacobs-university.de Fri Jul 2 09:55: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 510D73A68E3 for ; Fri, 2 Jul 2010 09:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.26 X-Spam-Level: X-Spam-Status: No, score=0.26 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8-4F0AIBQbF for ; Fri, 2 Jul 2010 09:55:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2BD5A3A68D6 for ; Fri, 2 Jul 2010 09:55:35 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D8104C0058; Fri, 2 Jul 2010 18:55:46 +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 xxTI-t-s1gPA; Fri, 2 Jul 2010 18:55: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 B5B46C0010; Fri, 2 Jul 2010 18:55:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8B2DE1378A7E; Fri, 2 Jul 2010 18:55:45 +0200 (CEST) Date: Fri, 2 Jul 2010 18:55:45 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100702165545.GB50924@elstar.local> Mail-Followup-To: Andy Bierman , Gerhard Muenz , NETMOD Working Group References: <4C2DF896.5050000@net.in.tum.de> <20100702161645.GB50757@elstar.local> <4C2E1740.4000800@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C2E1740.4000800@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group , Gerhard Muenz Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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, 02 Jul 2010 16:55:36 -0000 On Fri, Jul 02, 2010 at 06:43:44PM +0200, Andy Bierman wrote: > We can remove the guideline, and just let users get what they get > from implementors. The XML spec says that whitespace is > significant, so we can defer to their ownership of the problem. > XML says the client can rely on preservation of whitespace, > so maybe there is no need to worry about it, even if it is common > practice for server code to strip strings before using them. I believe we are heading in the wrong direction if we encourage data model writers to create rather complex regular expressions just because something down in the NETCONF encoding layer might not follow a particular standard. We better have test cases / test suites that make it clear what a correct implementation should do and fix the problem where it is, perhaps even adding clear language to 4741bis. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Fri Jul 2 10:36: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 9AC323A68F5 for ; Fri, 2 Jul 2010 10:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVVDXrjfc07d for ; Fri, 2 Jul 2010 10:36:34 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 235433A68C7 for ; Fri, 2 Jul 2010 10:36:30 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTC4jp8OZhlP0F0OIi3v5jk6phMdEk3eV@postini.com; Fri, 02 Jul 2010 10:36:46 PDT Received: from p-emfe03-sac.jnpr.net (66.129.254.75) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.2.254.0; Fri, 2 Jul 2010 10:29:27 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe03-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Jul 2010 10:29:27 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Jul 2010 10:29:26 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Jul 2010 10:29:26 -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 o62HTPD94095; Fri, 2 Jul 2010 10:29:25 -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 o62HBK3J057548; Fri, 2 Jul 2010 17:11:20 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201007021711.o62HBK3J057548@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20100702161645.GB50757@elstar.local> Date: Fri, 2 Jul 2010 13:11:20 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 Jul 2010 17:29:26.0266 (UTC) FILETIME=[1E6E35A0:01CB1A0C] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group , Gerhard Muenz Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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, 02 Jul 2010 17:36:34 -0000 Juergen Schoenwaelder writes: >Now that I read this in isolation, I am not sure why we have this >rule. I believe things are simpler if a value simply does not change. >If we allow white space changes, we make things more complex rather >than simpler... This rule is required to deal with the variety of XML processing tools that treat whitespace as something that can be freely introduced, especially indentation and newlines. XSLT is notorious in this regard. Thanks, Phil From j.schoenwaelder@jacobs-university.de Fri Jul 2 10:44:02 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 C171828C122 for ; Fri, 2 Jul 2010 10:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.17 X-Spam-Level: X-Spam-Status: No, score=0.17 tagged_above=-999 required=5 tests=[AWL=0.005, 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 d01S9fDwPwWn for ; Fri, 2 Jul 2010 10:44:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CD0833A6943 for ; Fri, 2 Jul 2010 10:44:01 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87E5DC005C; Fri, 2 Jul 2010 19:44:13 +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 Qb5o4o8hlGml; Fri, 2 Jul 2010 19:44:12 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15DDDC0010; Fri, 2 Jul 2010 19:44:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DEF7A1378F74; Fri, 2 Jul 2010 19:44:11 +0200 (CEST) Date: Fri, 2 Jul 2010 19:44:11 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20100702174411.GA247@elstar.local> Mail-Followup-To: Phil Shafer , Gerhard Muenz , NETMOD Working Group References: <20100702161645.GB50757@elstar.local> <201007021711.o62HBK3J057548@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007021711.o62HBK3J057548@idle.juniper.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group , Gerhard Muenz Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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, 02 Jul 2010 17:44:03 -0000 On Fri, Jul 02, 2010 at 07:11:20PM +0200, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >Now that I read this in isolation, I am not sure why we have this > >rule. I believe things are simpler if a value simply does not change. > >If we allow white space changes, we make things more complex rather > >than simpler... > > This rule is required to deal with the variety of XML > processing tools that treat whitespace as something > that can be freely introduced, especially indentation > and newlines. XSLT is notorious in this regard. How good that we use something as advanced as XML then... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Fri Jul 2 10:59:48 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 7F5433A681F for ; Fri, 2 Jul 2010 10:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqEeVaPN8LlV for ; Fri, 2 Jul 2010 10:59:47 -0700 (PDT) Received: from smtp215.iad.emailsrvr.com (smtp215.iad.emailsrvr.com [207.97.245.215]) by core3.amsl.com (Postfix) with ESMTP id B08523A6933 for ; Fri, 2 Jul 2010 10:59:47 -0700 (PDT) Received: from relay11.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay11.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 3C1AF1B408D; Fri, 2 Jul 2010 13:59:59 -0400 (EDT) Received: by relay11.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id D848B1B4093; Fri, 2 Jul 2010 13:59:58 -0400 (EDT) Message-ID: <4C2E2924.8060305@iwl.com> Date: Fri, 02 Jul 2010 11:00:04 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Phil Shafer , Gerhard Muenz , NETMOD Working Group References: <20100702161645.GB50757@elstar.local> <201007021711.o62HBK3J057548@idle.juniper.net> <20100702174411.GA247@elstar.local> In-Reply-To: <20100702174411.GA247@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 17:59:48 -0000 On 07/02/2010 10:44 AM, Juergen Schoenwaelder wrote: > On Fri, Jul 02, 2010 at 07:11:20PM +0200, Phil Shafer wrote: > >> Juergen Schoenwaelder writes: >> >>> Now that I read this in isolation, I am not sure why we have this >>> rule. I believe things are simpler if a value simply does not change. >>> If we allow white space changes, we make things more complex rather >>> than simpler... >>> >> This rule is required to deal with the variety of XML >> processing tools that treat whitespace as something >> that can be freely introduced, especially indentation >> and newlines. XSLT is notorious in this regard. >> > How good that we use something as advanced as XML then... > > So we put up an 'orange cone' and tell the drivers not to hit it. Relying on preservation of leading and trailing whitespace is not what tools do today at all. Why start relying on it now? Better to advice people to follow the industry practice. > /js > > Andy From j.schoenwaelder@jacobs-university.de Fri Jul 2 11:10:33 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 AD4EA28C14C for ; Fri, 2 Jul 2010 11:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnUdqxbIsT7Q for ; Fri, 2 Jul 2010 11:10:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8DA833A6832 for ; Fri, 2 Jul 2010 11:10:32 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47AF0C0058; Fri, 2 Jul 2010 20:10:44 +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 bY4EZ3pcAVgZ; Fri, 2 Jul 2010 20:10:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA9F3C0010; Fri, 2 Jul 2010 20:10:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DBABB1379166; Fri, 2 Jul 2010 20:10:42 +0200 (CEST) Date: Fri, 2 Jul 2010 20:10:42 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100702181042.GA525@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , Gerhard Muenz , NETMOD Working Group References: <20100702161645.GB50757@elstar.local> <201007021711.o62HBK3J057548@idle.juniper.net> <20100702174411.GA247@elstar.local> <4C2E2924.8060305@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C2E2924.8060305@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group , Gerhard Muenz Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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, 02 Jul 2010 18:10:33 -0000 On Fri, Jul 02, 2010 at 08:00:04PM +0200, Andy Bierman wrote: > On 07/02/2010 10:44 AM, Juergen Schoenwaelder wrote: > > On Fri, Jul 02, 2010 at 07:11:20PM +0200, Phil Shafer wrote: > > > >> Juergen Schoenwaelder writes: > >> > >>> Now that I read this in isolation, I am not sure why we have this > >>> rule. I believe things are simpler if a value simply does not change. > >>> If we allow white space changes, we make things more complex rather > >>> than simpler... > >>> > >> This rule is required to deal with the variety of XML > >> processing tools that treat whitespace as something > >> that can be freely introduced, especially indentation > >> and newlines. XSLT is notorious in this regard. > >> > > How good that we use something as advanced as XML then... > > > > > > So we put up an 'orange cone' and tell the drivers > not to hit it. Relying on preservation of leading and > trailing whitespace is not what tools do today at all. > Why start relying on it now? Better to advice people > to follow the industry practice. I love "industry practice". So do we have an example where it makes sense to allow white space even though we know it won't be preserved? In other words, why allow leading/trailing white space at all if it can be arbitrarily changed? Are there "industry practice" tools add leading/trailing white space or just "industry practice" tools removing leading/trailing white space? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Fri Jul 2 11:58:05 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 D6EE03A6901 for ; Fri, 2 Jul 2010 11:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.963 X-Spam-Level: X-Spam-Status: No, score=-2.963 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksQB5i+Pi7zM for ; Fri, 2 Jul 2010 11:58:05 -0700 (PDT) Received: from smtp205.iad.emailsrvr.com (smtp205.iad.emailsrvr.com [207.97.245.205]) by core3.amsl.com (Postfix) with ESMTP id EF7553A68BA for ; Fri, 2 Jul 2010 11:58:04 -0700 (PDT) Received: from relay10.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay10.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 087D61EA58B; Fri, 2 Jul 2010 14:58:17 -0400 (EDT) Received: by relay10.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id A1D651EBC3D; Fri, 2 Jul 2010 14:58:16 -0400 (EDT) Message-ID: <4C2E36CF.2050802@iwl.com> Date: Fri, 02 Jul 2010 11:58:23 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Phil Shafer , Gerhard Muenz , NETMOD Working Group References: <20100702161645.GB50757@elstar.local> <201007021711.o62HBK3J057548@idle.juniper.net> <20100702174411.GA247@elstar.local> <4C2E2924.8060305@iwl.com> <20100702181042.GA525@elstar.local> In-Reply-To: <20100702181042.GA525@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 18:58:05 -0000 On 07/02/2010 11:10 AM, Juergen Schoenwaelder wrote: > On Fri, Jul 02, 2010 at 08:00:04PM +0200, Andy Bierman wrote: > >> On 07/02/2010 10:44 AM, Juergen Schoenwaelder wrote: >> >>> On Fri, Jul 02, 2010 at 07:11:20PM +0200, Phil Shafer wrote: >>> >>> >>>> Juergen Schoenwaelder writes: >>>> >>>> >>>>> Now that I read this in isolation, I am not sure why we have this >>>>> rule. I believe things are simpler if a value simply does not change. >>>>> If we allow white space changes, we make things more complex rather >>>>> than simpler... >>>>> >>>>> >>>> This rule is required to deal with the variety of XML >>>> processing tools that treat whitespace as something >>>> that can be freely introduced, especially indentation >>>> and newlines. XSLT is notorious in this regard. >>>> >>>> >>> How good that we use something as advanced as XML then... >>> >>> >>> >> So we put up an 'orange cone' and tell the drivers >> not to hit it. Relying on preservation of leading and >> trailing whitespace is not what tools do today at all. >> Why start relying on it now? Better to advice people >> to follow the industry practice. >> > I love "industry practice". So do we have an example where it makes > sense to allow white space even though we know it won't be preserved? > In other words, why allow leading/trailing white space at all if it > can be arbitrarily changed? Are there "industry practice" tools add > leading/trailing white space or just "industry practice" tools > removing leading/trailing white space? > > So you want to change SHOULD NOT to MUST NOT? OK -- I do not object to that. But this means MUST NOT rely on whitespace preservation. Is that the same thing as MUST NOT use leading or trailing whitespace in a pattern? Is there a need for both guidelines? > /js > > Andy From j.schoenwaelder@jacobs-university.de Fri Jul 2 12:30: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 DA94D3A67A3 for ; Fri, 2 Jul 2010 12:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.265 X-Spam-Level: X-Spam-Status: No, score=0.265 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liQsGx5TTK+y for ; Fri, 2 Jul 2010 12:30:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EA5AD3A6817 for ; Fri, 2 Jul 2010 12:30:12 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 485A1C005C; Fri, 2 Jul 2010 21:30:22 +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 fcLYvc17j3P9; Fri, 2 Jul 2010 21:30:20 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8DAEEC0010; Fri, 2 Jul 2010 21:30:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7AAF71379472; Fri, 2 Jul 2010 21:30:20 +0200 (CEST) Date: Fri, 2 Jul 2010 21:30:20 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100702193020.GB778@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , Gerhard Muenz , NETMOD Working Group References: <20100702161645.GB50757@elstar.local> <201007021711.o62HBK3J057548@idle.juniper.net> <20100702174411.GA247@elstar.local> <4C2E2924.8060305@iwl.com> <20100702181042.GA525@elstar.local> <4C2E36CF.2050802@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C2E36CF.2050802@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group , Gerhard Muenz Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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, 02 Jul 2010 19:30:22 -0000 On Fri, Jul 02, 2010 at 08:58:23PM +0200, Andy Bierman wrote: > On 07/02/2010 11:10 AM, Juergen Schoenwaelder wrote: > > On Fri, Jul 02, 2010 at 08:00:04PM +0200, Andy Bierman wrote: > > > >> On 07/02/2010 10:44 AM, Juergen Schoenwaelder wrote: > >> > >>> On Fri, Jul 02, 2010 at 07:11:20PM +0200, Phil Shafer wrote: > >>> > >>> > >>>> Juergen Schoenwaelder writes: > >>>> > >>>> > >>>>> Now that I read this in isolation, I am not sure why we have this > >>>>> rule. I believe things are simpler if a value simply does not change. > >>>>> If we allow white space changes, we make things more complex rather > >>>>> than simpler... > >>>>> > >>>>> > >>>> This rule is required to deal with the variety of XML > >>>> processing tools that treat whitespace as something > >>>> that can be freely introduced, especially indentation > >>>> and newlines. XSLT is notorious in this regard. > >>>> > >>>> > >>> How good that we use something as advanced as XML then... > >>> > >>> > >>> > >> So we put up an 'orange cone' and tell the drivers > >> not to hit it. Relying on preservation of leading and > >> trailing whitespace is not what tools do today at all. > >> Why start relying on it now? Better to advice people > >> to follow the industry practice. > >> > > I love "industry practice". So do we have an example where it makes > > sense to allow white space even though we know it won't be preserved? > > In other words, why allow leading/trailing white space at all if it > > can be arbitrarily changed? Are there "industry practice" tools add > > leading/trailing white space or just "industry practice" tools > > removing leading/trailing white space? > > > > > > So you want to change SHOULD NOT to MUST NOT? > OK -- I do not object to that. > > But this means MUST NOT rely on whitespace preservation. > Is that the same thing as MUST NOT use leading or trailing whitespace > in a pattern? Is there a need for both guidelines? As usual, we do not communicate well. Give me an example where it makes sense to allow for leading/trailing white space in a pattern that can be arbitrarily removed. My point is that in such a case, the pattern should likely not allow leading/trailing white space in the first place since the leading/trailing white space obviously is not meaningful. I have a problem with encouraging people to write pattern like the one that started this thread (unfortunately we do not know what this type is going to model). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Fri Jul 2 12:32:47 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 0E7483A67A3 for ; Fri, 2 Jul 2010 12:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgBPFr5x1wtM for ; Fri, 2 Jul 2010 12:32:45 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id D4A6B3A690C for ; Fri, 2 Jul 2010 12:32:39 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTC4+4da6y9DPg6Vm9oGy2RKAU4kBk/fb@postini.com; Fri, 02 Jul 2010 12:32:57 PDT Received: from p-emfe02-sac.jnpr.net (66.129.254.73) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.2.254.0; Fri, 2 Jul 2010 12:30:39 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Jul 2010 12:30:39 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Jul 2010 12:30:39 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Jul 2010 12:30:38 -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 o62JUcD36497; Fri, 2 Jul 2010 12:30:38 -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 o62JCX86058298; Fri, 2 Jul 2010 19:12:33 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201007021912.o62JCX86058298@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20100702174411.GA247@elstar.local> Date: Fri, 2 Jul 2010 15:12:33 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 Jul 2010 19:30:38.0815 (UTC) FILETIME=[0D351EF0:01CB1A1D] MIME-Version: 1.0 Content-Type: text/plain Cc: NETMOD Working Group , Gerhard Muenz Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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, 02 Jul 2010 19:32:47 -0000 Juergen Schoenwaelder writes: >How good that we use something as advanced as XML then... Yup, like most things, it's simple only went viewed from a distance. On a related XML encoding note we finally gave up and started encoding control characters (which XML does not support (shockingly)) using a "private use" unicode range starting at 0xE000. I could not find a better way to do it, and it needed to be done. Can/should we standardize on this encoding? Is there a means of documenting it? My current encoding issue is that because XML lacks a real escaping mechanism, strings in XSLT XPath expression cannot have both single and double quotes, even when resorting to the """ and "&pos;" encodings. This means there's no simple, safe way of lifting a string from, say, a YANG file and stuffing it into an XPath string. I'm having to break the string up, and turn it into a concat() of two or more strings, which is just plain sad. Had no one heard of the backslash character? :-( (aka &sad;) Thanks, Phil From andyb@iwl.com Fri Jul 2 12:36: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 E68883A690C for ; Fri, 2 Jul 2010 12:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.003 X-Spam-Level: X-Spam-Status: No, score=-3.003 tagged_above=-999 required=5 tests=[AWL=0.596, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KISBkiunNEA for ; Fri, 2 Jul 2010 12:36:40 -0700 (PDT) Received: from smtp165.iad.emailsrvr.com (smtp165.iad.emailsrvr.com [207.97.245.165]) by core3.amsl.com (Postfix) with ESMTP id D7AEF3A68BA for ; Fri, 2 Jul 2010 12:36:39 -0700 (PDT) Received: from relay26.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay26.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id E64621B4011; Fri, 2 Jul 2010 15:36:51 -0400 (EDT) Received: by relay26.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 8C8851B4052; Fri, 2 Jul 2010 15:36:51 -0400 (EDT) Message-ID: <4C2E3FDA.6060704@iwl.com> Date: Fri, 02 Jul 2010 12:36:58 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Phil Shafer , Gerhard Muenz , NETMOD Working Group References: <20100702161645.GB50757@elstar.local> <201007021711.o62HBK3J057548@idle.juniper.net> <20100702174411.GA247@elstar.local> <4C2E2924.8060305@iwl.com> <20100702181042.GA525@elstar.local> <4C2E36CF.2050802@iwl.com> <20100702193020.GB778@elstar.local> In-Reply-To: <20100702193020.GB778@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 19:36:41 -0000 On 07/02/2010 12:30 PM, Juergen Schoenwaelder wrote: > On Fri, Jul 02, 2010 at 08:58:23PM +0200, Andy Bierman wrote: > >> On 07/02/2010 11:10 AM, Juergen Schoenwaelder wrote: >> >>> On Fri, Jul 02, 2010 at 08:00:04PM +0200, Andy Bierman wrote: >>> >>> >>>> On 07/02/2010 10:44 AM, Juergen Schoenwaelder wrote: >>>> >>>> >>>>> On Fri, Jul 02, 2010 at 07:11:20PM +0200, Phil Shafer wrote: >>>>> >>>>> >>>>> >>>>>> Juergen Schoenwaelder writes: >>>>>> >>>>>> >>>>>> >>>>>>> Now that I read this in isolation, I am not sure why we have this >>>>>>> rule. I believe things are simpler if a value simply does not change. >>>>>>> If we allow white space changes, we make things more complex rather >>>>>>> than simpler... >>>>>>> >>>>>>> >>>>>>> >>>>>> This rule is required to deal with the variety of XML >>>>>> processing tools that treat whitespace as something >>>>>> that can be freely introduced, especially indentation >>>>>> and newlines. XSLT is notorious in this regard. >>>>>> >>>>>> >>>>>> >>>>> How good that we use something as advanced as XML then... >>>>> >>>>> >>>>> >>>>> >>>> So we put up an 'orange cone' and tell the drivers >>>> not to hit it. Relying on preservation of leading and >>>> trailing whitespace is not what tools do today at all. >>>> Why start relying on it now? Better to advice people >>>> to follow the industry practice. >>>> >>>> >>> I love "industry practice". So do we have an example where it makes >>> sense to allow white space even though we know it won't be preserved? >>> In other words, why allow leading/trailing white space at all if it >>> can be arbitrarily changed? Are there "industry practice" tools add >>> leading/trailing white space or just "industry practice" tools >>> removing leading/trailing white space? >>> >>> >>> >> So you want to change SHOULD NOT to MUST NOT? >> OK -- I do not object to that. >> >> But this means MUST NOT rely on whitespace preservation. >> Is that the same thing as MUST NOT use leading or trailing whitespace >> in a pattern? Is there a need for both guidelines? >> > I think we are communicating. Provide some OLD: and NEW: text proposals in RFC Editor format, and I will have a better idea what you want to change in the document. Andy > As usual, we do not communicate well. Give me an example where it > makes sense to allow for leading/trailing white space in a pattern > that can be arbitrarily removed. My point is that in such a case, the > pattern should likely not allow leading/trailing white space in the > first place since the leading/trailing white space obviously is not > meaningful. > > I have a problem with encouraging people to write pattern like the one > that started this thread (unfortunately we do not know what this type > is going to model). > > /js > > From j.schoenwaelder@jacobs-university.de Fri Jul 2 12:53:49 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 9B5943A67A3 for ; Fri, 2 Jul 2010 12:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.268 X-Spam-Level: X-Spam-Status: No, score=0.268 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GST8PD-0UfC1 for ; Fri, 2 Jul 2010 12:53:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3241F3A6862 for ; Fri, 2 Jul 2010 12:53:47 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7F26C005C; Fri, 2 Jul 2010 21:53:58 +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 fpE80n4htMzG; Fri, 2 Jul 2010 21:53: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 1E071C0010; Fri, 2 Jul 2010 21:53:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 121CC137954F; Fri, 2 Jul 2010 21:53:57 +0200 (CEST) Date: Fri, 2 Jul 2010 21:53:57 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100702195356.GA873@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , Gerhard Muenz , NETMOD Working Group References: <20100702161645.GB50757@elstar.local> <201007021711.o62HBK3J057548@idle.juniper.net> <20100702174411.GA247@elstar.local> <4C2E2924.8060305@iwl.com> <20100702181042.GA525@elstar.local> <4C2E36CF.2050802@iwl.com> <20100702193020.GB778@elstar.local> <4C2E3FDA.6060704@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C2E3FDA.6060704@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group , Gerhard Muenz Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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, 02 Jul 2010 19:53:49 -0000 On Fri, Jul 02, 2010 at 09:36:58PM +0200, Andy Bierman wrote: > On 07/02/2010 12:30 PM, Juergen Schoenwaelder wrote: > > On Fri, Jul 02, 2010 at 08:58:23PM +0200, Andy Bierman wrote: > > > >> On 07/02/2010 11:10 AM, Juergen Schoenwaelder wrote: > >> > >>> On Fri, Jul 02, 2010 at 08:00:04PM +0200, Andy Bierman wrote: > >>> > >>> > >>>> On 07/02/2010 10:44 AM, Juergen Schoenwaelder wrote: > >>>> > >>>> > >>>>> On Fri, Jul 02, 2010 at 07:11:20PM +0200, Phil Shafer wrote: > >>>>> > >>>>> > >>>>> > >>>>>> Juergen Schoenwaelder writes: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Now that I read this in isolation, I am not sure why we have this > >>>>>>> rule. I believe things are simpler if a value simply does not change. > >>>>>>> If we allow white space changes, we make things more complex rather > >>>>>>> than simpler... > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> This rule is required to deal with the variety of XML > >>>>>> processing tools that treat whitespace as something > >>>>>> that can be freely introduced, especially indentation > >>>>>> and newlines. XSLT is notorious in this regard. > >>>>>> > >>>>>> > >>>>>> > >>>>> How good that we use something as advanced as XML then... > >>>>> > >>>>> > >>>>> > >>>>> > >>>> So we put up an 'orange cone' and tell the drivers > >>>> not to hit it. Relying on preservation of leading and > >>>> trailing whitespace is not what tools do today at all. > >>>> Why start relying on it now? Better to advice people > >>>> to follow the industry practice. > >>>> > >>>> > >>> I love "industry practice". So do we have an example where it makes > >>> sense to allow white space even though we know it won't be preserved? > >>> In other words, why allow leading/trailing white space at all if it > >>> can be arbitrarily changed? Are there "industry practice" tools add > >>> leading/trailing white space or just "industry practice" tools > >>> removing leading/trailing white space? > >>> > >>> > >>> > >> So you want to change SHOULD NOT to MUST NOT? > >> OK -- I do not object to that. > >> > >> But this means MUST NOT rely on whitespace preservation. > >> Is that the same thing as MUST NOT use leading or trailing whitespace > >> in a pattern? Is there a need for both guidelines? > >> > > > > I think we are communicating. > Provide some OLD: and NEW: text proposals > in RFC Editor format, and I will have a better > idea what you want to change in the document. OLD: For string data types, data definition semantics SHOULD NOT rely on preservation of leading and trailing whitespace characters. NEW: Since XML tools often do not preserve leading and trailing white space characters, string data types SHOULD where possible avoid leading and trailing white space characters. Rationale: - Provide an explanation why the rule exists. Encourage people not to - allow leading/trailing white space, the previous text did encourage people to allow such characters by making them optional. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Fri Jul 2 13:09: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 EA9FF3A690C for ; Fri, 2 Jul 2010 13:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.038 X-Spam-Level: X-Spam-Status: No, score=-3.038 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPbyZALJegEd for ; Fri, 2 Jul 2010 13:09:15 -0700 (PDT) Received: from smtp195.iad.emailsrvr.com (smtp195.iad.emailsrvr.com [207.97.245.195]) by core3.amsl.com (Postfix) with ESMTP id 33C643A6850 for ; Fri, 2 Jul 2010 13:09:15 -0700 (PDT) Received: from relay29.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay29.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 3D8FF1B4055; Fri, 2 Jul 2010 16:09:27 -0400 (EDT) Received: by relay29.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id B44C01B4032; Fri, 2 Jul 2010 16:09:26 -0400 (EDT) Message-ID: <4C2E477D.7090304@iwl.com> Date: Fri, 02 Jul 2010 13:09:33 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Phil Shafer , Gerhard Muenz , NETMOD Working Group References: <20100702161645.GB50757@elstar.local> <201007021711.o62HBK3J057548@idle.juniper.net> <20100702174411.GA247@elstar.local> <4C2E2924.8060305@iwl.com> <20100702181042.GA525@elstar.local> <4C2E36CF.2050802@iwl.com> <20100702193020.GB778@elstar.local> <4C2E3FDA.6060704@iwl.com> <20100702195356.GA873@elstar.local> In-Reply-To: <20100702195356.GA873@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 20:09:17 -0000 On 07/02/2010 12:53 PM, Juergen Schoenwaelder wrote: > On Fri, Jul 02, 2010 at 09:36:58PM +0200, Andy Bierman wrote: > >> On 07/02/2010 12:30 PM, Juergen Schoenwaelder wrote: >> >>> On Fri, Jul 02, 2010 at 08:58:23PM +0200, Andy Bierman wrote: >>> >>> >>>> On 07/02/2010 11:10 AM, Juergen Schoenwaelder wrote: >>>> >>>> >>>>> On Fri, Jul 02, 2010 at 08:00:04PM +0200, Andy Bierman wrote: >>>>> >>>>> >>>>> >>>>>> On 07/02/2010 10:44 AM, Juergen Schoenwaelder wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On Fri, Jul 02, 2010 at 07:11:20PM +0200, Phil Shafer wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Juergen Schoenwaelder writes: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Now that I read this in isolation, I am not sure why we have this >>>>>>>>> rule. I believe things are simpler if a value simply does not change. >>>>>>>>> If we allow white space changes, we make things more complex rather >>>>>>>>> than simpler... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> This rule is required to deal with the variety of XML >>>>>>>> processing tools that treat whitespace as something >>>>>>>> that can be freely introduced, especially indentation >>>>>>>> and newlines. XSLT is notorious in this regard. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> How good that we use something as advanced as XML then... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> So we put up an 'orange cone' and tell the drivers >>>>>> not to hit it. Relying on preservation of leading and >>>>>> trailing whitespace is not what tools do today at all. >>>>>> Why start relying on it now? Better to advice people >>>>>> to follow the industry practice. >>>>>> >>>>>> >>>>>> >>>>> I love "industry practice". So do we have an example where it makes >>>>> sense to allow white space even though we know it won't be preserved? >>>>> In other words, why allow leading/trailing white space at all if it >>>>> can be arbitrarily changed? Are there "industry practice" tools add >>>>> leading/trailing white space or just "industry practice" tools >>>>> removing leading/trailing white space? >>>>> >>>>> >>>>> >>>>> >>>> So you want to change SHOULD NOT to MUST NOT? >>>> OK -- I do not object to that. >>>> >>>> But this means MUST NOT rely on whitespace preservation. >>>> Is that the same thing as MUST NOT use leading or trailing whitespace >>>> in a pattern? Is there a need for both guidelines? >>>> >>>> >>> >>> >> I think we are communicating. >> Provide some OLD: and NEW: text proposals >> in RFC Editor format, and I will have a better >> idea what you want to change in the document. >> > OLD: > > For string data types, data definition semantics SHOULD NOT rely on > preservation of leading and trailing whitespace characters. > > NEW: > > Since XML tools often do not preserve leading and trailing white > space characters, string data types SHOULD where possible avoid > leading and trailing white space characters. > > s/avoid leading/avoid using leading/ I thought you wanted MUST instead of SHOULD? I don't careeither way --your edit is fine with me. (See how easy that was? :-) > Rationale: > > - Provide an explanation why the rule exists. Encourage people not to > - allow leading/trailing white space, the previous text did encourage > people to allow such characters by making them optional. > > /js > > Andy From mbj@tail-f.com Fri Jul 2 14:24:49 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 941AB3A680C for ; Fri, 2 Jul 2010 14:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.368 X-Spam-Level: X-Spam-Status: No, score=0.368 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 KmBladpLyX4T for ; Fri, 2 Jul 2010 14:24:48 -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 DF4323A67F5 for ; Fri, 2 Jul 2010 14:24:47 -0700 (PDT) Received: from localhost (78-70-162-131-no181.tbcn.telia.com [78.70.162.131]) by mail.tail-f.com (Postfix) with ESMTPSA id 3B66676C0F8; Fri, 2 Jul 2010 23:24:58 +0200 (CEST) Date: Fri, 02 Jul 2010 23:24:57 +0200 (CEST) Message-Id: <20100702.232457.84055025.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100702195356.GA873@elstar.local> References: <20100702193020.GB778@elstar.local> <4C2E3FDA.6060704@iwl.com> <20100702195356.GA873@elstar.local> 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, muenz@net.in.tum.de Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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, 02 Jul 2010 21:24:49 -0000 Juergen Schoenwaelder wrote: > On Fri, Jul 02, 2010 at 09:36:58PM +0200, Andy Bierman wrote: > > On 07/02/2010 12:30 PM, Juergen Schoenwaelder wrote: > > > On Fri, Jul 02, 2010 at 08:58:23PM +0200, Andy Bierman wrote: > > > > > >> On 07/02/2010 11:10 AM, Juergen Schoenwaelder wrote: > > >> > > >>> On Fri, Jul 02, 2010 at 08:00:04PM +0200, Andy Bierman wrote: > > >>> > > >>> > > >>>> On 07/02/2010 10:44 AM, Juergen Schoenwaelder wrote: > > >>>> > > >>>> > > >>>>> On Fri, Jul 02, 2010 at 07:11:20PM +0200, Phil Shafer wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>>> Juergen Schoenwaelder writes: > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>> Now that I read this in isolation, I am not sure why we have this > > >>>>>>> rule. I believe things are simpler if a value simply does not change. > > >>>>>>> If we allow white space changes, we make things more complex rather > > >>>>>>> than simpler... > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>> This rule is required to deal with the variety of XML > > >>>>>> processing tools that treat whitespace as something > > >>>>>> that can be freely introduced, especially indentation > > >>>>>> and newlines. XSLT is notorious in this regard. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>> How good that we use something as advanced as XML then... > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>> So we put up an 'orange cone' and tell the drivers > > >>>> not to hit it. Relying on preservation of leading and > > >>>> trailing whitespace is not what tools do today at all. > > >>>> Why start relying on it now? Better to advice people > > >>>> to follow the industry practice. > > >>>> > > >>>> > > >>> I love "industry practice". So do we have an example where it makes > > >>> sense to allow white space even though we know it won't be preserved? > > >>> In other words, why allow leading/trailing white space at all if it > > >>> can be arbitrarily changed? Are there "industry practice" tools add > > >>> leading/trailing white space or just "industry practice" tools > > >>> removing leading/trailing white space? > > >>> > > >>> > > >>> > > >> So you want to change SHOULD NOT to MUST NOT? > > >> OK -- I do not object to that. > > >> > > >> But this means MUST NOT rely on whitespace preservation. > > >> Is that the same thing as MUST NOT use leading or trailing whitespace > > >> in a pattern? Is there a need for both guidelines? > > >> > > > > > > > I think we are communicating. > > Provide some OLD: and NEW: text proposals > > in RFC Editor format, and I will have a better > > idea what you want to change in the document. > > OLD: > > For string data types, data definition semantics SHOULD NOT rely on > preservation of leading and trailing whitespace characters. > > NEW: > > Since XML tools often do not preserve leading and trailing white > space characters, string data types SHOULD where possible avoid > leading and trailing white space characters. What sort of XML tool does not preserve leading and trailing whitespace? In my experience XML tools do preserve this whitespace. Phil had a different explaination: phil> This rule is required to deal with the variety of XML phil> processing tools that treat whitespace as something phil> that can be freely introduced, especially indentation phil> and newlines. XSLT is notorious in this regard. But if this is the case, the rule above is not sufficient, and if we want to guard against tools that introduce whitespace we need other mechanisms to deal with this in the YANG language (which I do not want to do). XML itself has no special rules for this whitespace in element data, and that's just how it works. We should simply play along. Also, I wonder what the practical impact of this rule is. Are we saying that the 'string' data type should not be used? Do we have an alternative, or should every data model invent their own my-better-string data type? /martin From muenz@net.in.tum.de Sat Jul 3 04:47:35 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 51D9C28C0EC for ; Sat, 3 Jul 2010 04:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.206 X-Spam-Level: X-Spam-Status: No, score=-0.206 tagged_above=-999 required=5 tests=[AWL=-0.371, 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 vIbydbFxe+Ak for ; Sat, 3 Jul 2010 04:47:06 -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 D73023A6783 for ; Sat, 3 Jul 2010 04:47:03 -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 F386A224AB7E; Sat, 3 Jul 2010 13:47:14 +0200 (CEST) Message-ID: <4C2F2352.2060703@net.in.tum.de> Date: Sat, 03 Jul 2010 13:47:30 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <20100702161645.GB50757@elstar.local> <201007021711.o62HBK3J057548@idle.juniper.net> <20100702174411.GA247@elstar.local> <4C2E2924.8060305@iwl.com> <20100702181042.GA525@elstar.local> <4C2E36CF.2050802@iwl.com> <20100702193020.GB778@elstar.local> In-Reply-To: <20100702193020.GB778@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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: Sat, 03 Jul 2010 11:47:36 -0000 On 02.07.2010 21:30, Juergen Schoenwaelder wrote: > I have a problem with encouraging people to write pattern like the one > that started this thread (unfortunately we do not know what this type > is going to model). In IPFIX-CONFIG, we use string nodes as identifiers. They are used as key in config lists etc., and they are being referenced by leafref. Hence, we have to make sure that if the user configures the same string at two different places (nodes), they must be recognized as identical. Gerhard From muenz@net.in.tum.de Sat Jul 3 04:51: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 66DAC3A6814 for ; Sat, 3 Jul 2010 04:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.114 X-Spam-Level: X-Spam-Status: No, score=-0.114 tagged_above=-999 required=5 tests=[AWL=-0.279, 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 m4Gd7Tw1XN59 for ; Sat, 3 Jul 2010 04:51:51 -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 97DA13A67BD for ; Sat, 3 Jul 2010 04:51:51 -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 E20A9224AB7E; Sat, 3 Jul 2010 13:52:02 +0200 (CEST) Message-ID: <4C2F2472.5020702@net.in.tum.de> Date: Sat, 03 Jul 2010 13:52:18 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <20100702161645.GB50757@elstar.local> <201007021711.o62HBK3J057548@idle.juniper.net> <20100702174411.GA247@elstar.local> <4C2E2924.8060305@iwl.com> <20100702181042.GA525@elstar.local> <4C2E36CF.2050802@iwl.com> <20100702193020.GB778@elstar.local> <4C2F2352.2060703@net.in.tum.de> In-Reply-To: <4C2F2352.2060703@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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: Sat, 03 Jul 2010 11:51:52 -0000 On 03.07.2010 13:47, Gerhard Muenz wrote: > > On 02.07.2010 21:30, Juergen Schoenwaelder wrote: >> I have a problem with encouraging people to write pattern like the one >> that started this thread (unfortunately we do not know what this type >> is going to model). > > In IPFIX-CONFIG, we use string nodes as identifiers. > They are used as key in config lists etc., and they are being referenced > by leafref. Hence, we have to make sure that if the user configures the > same string at two different places (nodes), they must be recognized as > identical. And the other way round, of course: if the strings differ, they must be recognized as different. I assume that other people might have this problem. So, I suggest to either remove the paragraph from the guidelines or to provide a solution for this problem, e.g. an example pattern or a common type. Thanks, Gerhard From andyb@iwl.com Sat Jul 3 07:10:10 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 629D83A6820 for ; Sat, 3 Jul 2010 07:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.069 X-Spam-Level: X-Spam-Status: No, score=-3.069 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBzDMUGh6WPn for ; Sat, 3 Jul 2010 07:10:08 -0700 (PDT) Received: from smtp145.iad.emailsrvr.com (smtp145.iad.emailsrvr.com [207.97.245.145]) by core3.amsl.com (Postfix) with ESMTP id 2BD9B3A6830 for ; Sat, 3 Jul 2010 07:10:08 -0700 (PDT) Received: from relay4.r5.iad.mlsrvr.com (localhost [127.0.0.1]) by relay4.r5.iad.mlsrvr.com (SMTP Server) with ESMTP id 77FDAC101; Sat, 3 Jul 2010 10:10:20 -0400 (EDT) Received: by relay4.r5.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 0CC52C11E; Sat, 3 Jul 2010 10:10:19 -0400 (EDT) Message-ID: <4C2F44DA.9000003@iwl.com> Date: Sat, 03 Jul 2010 07:10:34 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Gerhard Muenz References: <20100702161645.GB50757@elstar.local> <201007021711.o62HBK3J057548@idle.juniper.net> <20100702174411.GA247@elstar.local> <4C2E2924.8060305@iwl.com> <20100702181042.GA525@elstar.local> <4C2E36CF.2050802@iwl.com> <20100702193020.GB778@elstar.local> <4C2F2352.2060703@net.in.tum.de> <4C2F2472.5020702@net.in.tum.de> In-Reply-To: <4C2F2472.5020702@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 14:10:10 -0000 On 07/03/2010 04:52 AM, Gerhard Muenz wrote: > > > On 03.07.2010 13:47, Gerhard Muenz wrote: >> >> On 02.07.2010 21:30, Juergen Schoenwaelder wrote: >>> I have a problem with encouraging people to write pattern like the one >>> that started this thread (unfortunately we do not know what this type >>> is going to model). >> >> In IPFIX-CONFIG, we use string nodes as identifiers. >> They are used as key in config lists etc., and they are being referenced >> by leafref. Hence, we have to make sure that if the user configures the >> same string at two different places (nodes), they must be recognized as >> identical. > > And the other way round, of course: if the strings differ, they must > be recognized as different. > > I assume that other people might have this problem. So, I suggest to > either remove the paragraph from the guidelines or to provide a > solution for this problem, e.g. an example pattern or a common type. > Removing the guideline is fine with me. I do not think using leading whitespace in a name string is a good idea. I cannot think of any use-case at all where using leading and trailing whitespace in a YANG string value would be helpful. > Thanks, > Gerhard > Andy From j.schoenwaelder@jacobs-university.de Sat Jul 3 14:08: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 771F53A6359 for ; Sat, 3 Jul 2010 14:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[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 3tIo+pG3b2LE for ; Sat, 3 Jul 2010 14:08: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 20C3F3A683C for ; Sat, 3 Jul 2010 14:08:22 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DD0F8C0010; Sat, 3 Jul 2010 23:08:20 +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 dOtBz3fIZgda; Sat, 3 Jul 2010 23:08:20 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71347C0006; Sat, 3 Jul 2010 23:08:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5A8A8137ACB4; Sat, 3 Jul 2010 23:08:18 +0200 (CEST) Date: Sat, 3 Jul 2010 23:08:18 +0200 From: Juergen Schoenwaelder To: Gerhard Muenz Message-ID: <20100703210818.GA2840@elstar.local> Mail-Followup-To: Gerhard Muenz , Andy Bierman , Phil Shafer , NETMOD Working Group References: <20100702161645.GB50757@elstar.local> <201007021711.o62HBK3J057548@idle.juniper.net> <20100702174411.GA247@elstar.local> <4C2E2924.8060305@iwl.com> <20100702181042.GA525@elstar.local> <4C2E36CF.2050802@iwl.com> <20100702193020.GB778@elstar.local> <4C2F2352.2060703@net.in.tum.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C2F2352.2060703@net.in.tum.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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: Sat, 03 Jul 2010 21:08:32 -0000 On Sat, Jul 03, 2010 at 01:47:30PM +0200, Gerhard Muenz wrote: > In IPFIX-CONFIG, we use string nodes as identifiers. > They are used as key in config lists etc., and they are being referenced > by leafref. Hence, we have to make sure that if the user configures the > same string at two different places (nodes), they must be recognized as > identical. In this case, it seems you like to restrict the string such that it does not contain any leading/trailing whitespace (perhaps no whitespace at all). /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 Mon Jul 5 08:15:49 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 F1E4B3A6983 for ; Mon, 5 Jul 2010 08:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHSBqecn6rAV for ; Mon, 5 Jul 2010 08:15:49 -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 9AF713A6828 for ; Mon, 5 Jul 2010 08:15:48 -0700 (PDT) Received: from [131.159.14.152] (charlie.net.in.tum.de [131.159.14.152]) by mail.net.in.tum.de (Postfix) with ESMTPSA id EE1312096A56; Mon, 5 Jul 2010 17:15:37 +0200 (CEST) Message-ID: <4C31F727.2030408@net.in.tum.de> Date: Mon, 05 Jul 2010 17:15:51 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gerhard Muenz , Andy Bierman , Phil Shafer , NETMOD Working Group References: <20100702161645.GB50757@elstar.local> <201007021711.o62HBK3J057548@idle.juniper.net> <20100702174411.GA247@elstar.local> <4C2E2924.8060305@iwl.com> <20100702181042.GA525@elstar.local> <4C2E36CF.2050802@iwl.com> <20100702193020.GB778@elstar.local> <4C2F2352.2060703@net.in.tum.de> <20100703210818.GA2840@elstar.local> In-Reply-To: <20100703210818.GA2840@elstar.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000708020207030807080005" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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, 05 Jul 2010 15:15:50 -0000 This is a cryptographically signed message in MIME format. --------------ms000708020207030807080005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > On Sat, Jul 03, 2010 at 01:47:30PM +0200, Gerhard Muenz wrote: > >> In IPFIX-CONFIG, we use string nodes as identifiers. >> They are used as key in config lists etc., and they are being referenced >> by leafref. Hence, we have to make sure that if the user configures the >> same string at two different places (nodes), they must be recognized as >> identical. > > In this case, it seems you like to restrict the string such that > it does not contain any leading/trailing whitespace (perhaps no > whitespace at all). We want to allow whitespaces in the middle of the string if possible. So, is the following pattern appropriate? pattern "\S([#20\c]*\S)?"; Are there better alternatives? Or shall I just ignore the issue? Thanks, Gerhard --------------ms000708020207030807080005 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDcwNTE1MTU1MVowIwYJKoZIhvcNAQkEMRYEFED+ CewYaXz1Ge5zvDxGHN/sb0jfMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQBR4dw2YOGgiLmEyInXWouj7QWPYmd396jCbMhqn5RrYdzGclhmuc8l j8W3jXRJBjIBTLz5TAbIpz7hfRRGI/51gQSGL/TqTHX4LrzclIQkcQ89OebtiqMsQbwzvK8N 8IakzR9RkPZhC3nAN9P4QYaS0HZsNoPfp19FSFMGNNCcA04EhUffllkP3+dnaqrMV3L90Go6 lvjahlHgd+cIsRPe/XN5RHojyg4c1+E9qKLOcRAScOduF1iuksG50FeJzqjyTauPaGenpMs3 vYE0rkwlk7acKM05t3z5cTH+ERLLDmedN7SRTavWrU0hF6o0sX8SOUKcr6PxLMJ+/j9GoL95 AAAAAAAA --------------ms000708020207030807080005-- From muenz@net.in.tum.de Tue Jul 6 00:41: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 4C8FB3A67D1 for ; Tue, 6 Jul 2010 00:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytQEyDgRDmg7 for ; Tue, 6 Jul 2010 00:41:19 -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 43CDF3A6900 for ; Tue, 6 Jul 2010 00:41:19 -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 F01F920DA4E1; Tue, 6 Jul 2010 09:41:07 +0200 (CEST) Message-ID: <4C32DE21.8020302@net.in.tum.de> Date: Tue, 06 Jul 2010 09:41:21 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Juergen Schoenwaelder References: <20100702161645.GB50757@elstar.local> <201007021711.o62HBK3J057548@idle.juniper.net> <20100702174411.GA247@elstar.local> <4C2E2924.8060305@iwl.com> <20100702181042.GA525@elstar.local> <4C2E36CF.2050802@iwl.com> <20100702193020.GB778@elstar.local> <4C2F2352.2060703@net.in.tum.de> <20100703210818.GA2840@elstar.local> <4C31F727.2030408@net.in.tum.de> <20100705225049.GA30605@elstar.local> In-Reply-To: <20100705225049.GA30605@elstar.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050801080208060302070702" X-Virus-Scanned: ClamAV using ClamSMTP Cc: NETMOD Working Group Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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, 06 Jul 2010 07:41:20 -0000 This is a cryptographically signed message in MIME format. --------------ms050801080208060302070702 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi J=FCrgen, Juergen Schoenwaelder wrote: > On Mon, Jul 05, 2010 at 05:15:51PM +0200, Gerhard Muenz wrote: >=20 >> We want to allow whitespaces in the middle of the string if possible. >> >> So, is the following pattern appropriate? >> >> pattern "\S([#20\c]*\S)?"; >> >> Are there better alternatives? >=20 > Should that not be #x20 instead of #20? Indeed. I changed it to pattern "\S([\s\c]*\S)?"; yet this does not allow "/". For simplicity, I use pattern "\S(.*\S)?"; for the moment. Nevertheless, I think that it is strange that the guidelines indirectly disadvice the usage of string type nodes as keys and targets of leafrefs.= Either the string type is robust enough to be used in these cases without any patterns or it should be stated explicitly that unrestricted strings should not be used. In the later case, it would be nice to have a second string type which can be used instead. Sorry for insisting on this, but from the point of view of a data model writer, the current guidelines are a bit confusing in this regard. Thanks, Gerhard --------------ms050801080208060302070702 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDcwNjA3NDEyMVowIwYJKoZIhvcNAQkEMRYEFIze UVZXlU7QQBXFwX50erIGvu43MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQAnNvg9EVLZt5mfn2+SuRw2+khRw2udXYUfgPO+Jv3kyz2f4GQx27Ub UVoHFryn26iwPqrdn757ORAzZSo7RrtBGTIx/wp9UTgwuFudOYs+Jh/JQw8j5yYnLcp5g2ID b5pL0iCQwBlafBOzKnVC1DFnJAD1ZXhDASwjGpFAecDhb9pTL7VkwdKF3nD9cc0tlSxxBUjO V/jCM+MJsfrWvTZBwX3laFeGb4ifI62xom8esAi5MYeQ79b3ZHnMOn4wF3QQmbCEFVpVX7O7 4LpR7UpBbwD0C9iGvUGkBKzFdcNKLCtWrkp013NzJ8WLUvx3hJhwdq/25JOX5kUGmRUba79n AAAAAAAA --------------ms050801080208060302070702-- From j.schoenwaelder@jacobs-university.de Tue Jul 6 01:07: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 8D80A3A6816 for ; Tue, 6 Jul 2010 01:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KPLmdlGz0Ej for ; Tue, 6 Jul 2010 01:07:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 83B6B3A6867 for ; Tue, 6 Jul 2010 01:07:28 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D4E76C0007; Tue, 6 Jul 2010 10:07:29 +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 W26v+DjXXqX7; Tue, 6 Jul 2010 10:07:28 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 718A5C0002; Tue, 6 Jul 2010 10:07:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5B9C11386E5C; Tue, 6 Jul 2010 10:07:28 +0200 (CEST) Date: Tue, 6 Jul 2010 10:07:28 +0200 From: Juergen Schoenwaelder To: Gerhard Muenz Message-ID: <20100706080728.GA31404@elstar.local> Mail-Followup-To: Gerhard Muenz , NETMOD Working Group References: <20100702174411.GA247@elstar.local> <4C2E2924.8060305@iwl.com> <20100702181042.GA525@elstar.local> <4C2E36CF.2050802@iwl.com> <20100702193020.GB778@elstar.local> <4C2F2352.2060703@net.in.tum.de> <20100703210818.GA2840@elstar.local> <4C31F727.2030408@net.in.tum.de> <20100705225049.GA30605@elstar.local> <4C32DE21.8020302@net.in.tum.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C32DE21.8020302@net.in.tum.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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, 06 Jul 2010 08:07:29 -0000 On Tue, Jul 06, 2010 at 09:41:21AM +0200, Gerhard Muenz wrote: > Nevertheless, I think that it is strange that the guidelines indirectly > disadvice the usage of string type nodes as keys and targets of leafrefs. > > Either the string type is robust enough to be used in these cases > without any patterns or it should be stated explicitly that unrestricted > strings should not be used. In the later case, it would be nice to have > a second string type which can be used instead. > > Sorry for insisting on this, but from the point of view of a data model > writer, the current guidelines are a bit confusing in this regard. I agree and I hope that NETCONF implementations do not mess around with any values in XML elements that are part of the (config) payload. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Jul 6 13:05: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 B6E133A693B for ; Tue, 6 Jul 2010 13:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 WCtm3++1o9CU for ; Tue, 6 Jul 2010 13:05:57 -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 BFC323A699A for ; Tue, 6 Jul 2010 13:05:57 -0700 (PDT) Received: from localhost (78-70-162-131-no181.tbcn.telia.com [78.70.162.131]) by mail.tail-f.com (Postfix) with ESMTPSA id B309C616006; Tue, 6 Jul 2010 22:05:59 +0200 (CEST) Date: Tue, 06 Jul 2010 22:05:58 +0200 (CEST) Message-Id: <20100706.220558.117401500.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100706080728.GA31404@elstar.local> References: <20100705225049.GA30605@elstar.local> <4C32DE21.8020302@net.in.tum.de> <20100706080728.GA31404@elstar.local> 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, muenz@net.in.tum.de Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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, 06 Jul 2010 20:05:58 -0000 Juergen Schoenwaelder wrote: > On Tue, Jul 06, 2010 at 09:41:21AM +0200, Gerhard Muenz wrote: > > > Nevertheless, I think that it is strange that the guidelines indirectly > > disadvice the usage of string type nodes as keys and targets of leafrefs. > > > > Either the string type is robust enough to be used in these cases > > without any patterns or it should be stated explicitly that unrestricted > > strings should not be used. In the later case, it would be nice to have > > a second string type which can be used instead. > > > > Sorry for insisting on this, but from the point of view of a data model > > writer, the current guidelines are a bit confusing in this regard. > > I agree and I hope that NETCONF implementations do not mess around > with any values in XML elements that are part of the (config) payload. +1 I think this guideline should be removed, and it should be fine to use 'string' as is. /martin From lhotka@cesnet.cz Wed Jul 7 02:34: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 70CE73A682A for ; Wed, 7 Jul 2010 02:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.35 X-Spam-Level: * X-Spam-Status: No, score=1.35 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 FsIIMT-C1ggJ for ; Wed, 7 Jul 2010 02:34:36 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 36CED3A67DB for ; Wed, 7 Jul 2010 02:34:35 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id C7A602CDE059; Wed, 7 Jul 2010 11:34:37 +0200 (CEST) From: Ladislav Lhotka To: andyb@iwl.com In-Reply-To: <4C2F44DA.9000003@iwl.com> References: <20100702161645.GB50757@elstar.local> <201007021711.o62HBK3J057548@idle.juniper.net> <20100702174411.GA247@elstar.local> <4C2E2924.8060305@iwl.com> <20100702181042.GA525@elstar.local> <4C2E36CF.2050802@iwl.com> <20100702193020.GB778@elstar.local> <4C2F2352.2060703@net.in.tum.de> <4C2F2472.5020702@net.in.tum.de> <4C2F44DA.9000003@iwl.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 07 Jul 2010 11:34:35 +0200 Message-ID: <1278495275.10719.12.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group , Gerhard Muenz Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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, 07 Jul 2010 09:34:37 -0000 Andy Bierman píše v So 03. 07. 2010 v 07:10 -0700: > On 07/03/2010 04:52 AM, Gerhard Muenz wrote: > > > > > > On 03.07.2010 13:47, Gerhard Muenz wrote: > >> > >> On 02.07.2010 21:30, Juergen Schoenwaelder wrote: > >>> I have a problem with encouraging people to write pattern like the one > >>> that started this thread (unfortunately we do not know what this type > >>> is going to model). > >> > >> In IPFIX-CONFIG, we use string nodes as identifiers. > >> They are used as key in config lists etc., and they are being referenced > >> by leafref. Hence, we have to make sure that if the user configures the > >> same string at two different places (nodes), they must be recognized as > >> identical. > > > > And the other way round, of course: if the strings differ, they must > > be recognized as different. > > > > I assume that other people might have this problem. So, I suggest to > > either remove the paragraph from the guidelines or to provide a > > solution for this problem, e.g. an example pattern or a common type. > > > > Removing the guideline is fine with me. > I do not think using leading whitespace in a name string > is a good idea. I cannot think of any use-case at all > where using leading and trailing whitespace in a > YANG string value would be helpful. Perhaps YANG could define the canonical value for strings to be normalized in some way, either as XML attribute values or just by stripping leading and trailing whitespace. Lada > > > Thanks, > > Gerhard > > > > Andy > > _______________________________________________ > 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 Wed Jul 7 02:48: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 6EA413A67CF for ; Wed, 7 Jul 2010 02:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.11 X-Spam-Level: X-Spam-Status: No, score=-0.11 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypWJwUX-A4NH for ; Wed, 7 Jul 2010 02:48: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 649F93A659C for ; Wed, 7 Jul 2010 02:48:49 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1762AC0008; Wed, 7 Jul 2010 11:48:52 +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 3Dz9sPCb+yPp; Wed, 7 Jul 2010 11:48:51 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5EFD9C0004; Wed, 7 Jul 2010 11:48:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6934713947FD; Wed, 7 Jul 2010 11:48:45 +0200 (CEST) Date: Wed, 7 Jul 2010 11:48:45 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20100707094845.GA17385@elstar.local> Mail-Followup-To: Ladislav Lhotka , "andyb@iwl.com" , NETMOD Working Group , Gerhard Muenz References: <201007021711.o62HBK3J057548@idle.juniper.net> <20100702174411.GA247@elstar.local> <4C2E2924.8060305@iwl.com> <20100702181042.GA525@elstar.local> <4C2E36CF.2050802@iwl.com> <20100702193020.GB778@elstar.local> <4C2F2352.2060703@net.in.tum.de> <4C2F2472.5020702@net.in.tum.de> <4C2F44DA.9000003@iwl.com> <1278495275.10719.12.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1278495275.10719.12.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group , Gerhard Muenz Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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: Wed, 07 Jul 2010 09:48:50 -0000 On Wed, Jul 07, 2010 at 11:34:35AM +0200, Ladislav Lhotka wrote: > Perhaps YANG could define the canonical value for strings to be > normalized in some way, either as XML attribute values or just by > stripping leading and trailing whitespace. I believe NETCONF implementations should treat a plain string value as an opaque value and not mess around with it. There might be "industry practice" tools that do this kind of bad thing but that is not a good reason for us to introduce the same misbehaviour into NETCONF. /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 Wed Jul 7 03:02: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 463C43A6784 for ; Wed, 7 Jul 2010 03:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.35 X-Spam-Level: * X-Spam-Status: No, score=1.35 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 1rcpFpylskmU for ; Wed, 7 Jul 2010 03:02:08 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 66C423A67FE for ; Wed, 7 Jul 2010 03:02:08 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTPSA id 3B84D2CDE059; Wed, 7 Jul 2010 12:02:10 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20100707094845.GA17385@elstar.local> References: <201007021711.o62HBK3J057548@idle.juniper.net> <20100702174411.GA247@elstar.local> <4C2E2924.8060305@iwl.com> <20100702181042.GA525@elstar.local> <4C2E36CF.2050802@iwl.com> <20100702193020.GB778@elstar.local> <4C2F2352.2060703@net.in.tum.de> <4C2F2472.5020702@net.in.tum.de> <4C2F44DA.9000003@iwl.com> <1278495275.10719.12.camel@missotis> <20100707094845.GA17385@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 07 Jul 2010 12:02:08 +0200 Message-ID: <1278496928.10719.25.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group , Gerhard Muenz Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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, 07 Jul 2010 10:02:09 -0000 Juergen Schoenwaelder píše v St 07. 07. 2010 v 11:48 +0200: > On Wed, Jul 07, 2010 at 11:34:35AM +0200, Ladislav Lhotka wrote: > > > Perhaps YANG could define the canonical value for strings to be > > normalized in some way, either as XML attribute values or just by > > stripping leading and trailing whitespace. > > I believe NETCONF implementations should treat a plain string value as > an opaque value and not mess around with it. There might be "industry > practice" tools that do this kind of bad thing but that is not a good > reason for us to introduce the same misbehaviour into NETCONF. I agree, except that using strings as list keys may lead to tricky problems, especially when the values are entered manually. That's why key-like things are invariably implemented as attributes in XML, e.g. rather than foo Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Jul 7 03:20: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 8F8453A67CF for ; Wed, 7 Jul 2010 03:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.072 X-Spam-Level: X-Spam-Status: No, score=-0.072 tagged_above=-999 required=5 tests=[AWL=-0.423, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kghWw7deA9y for ; Wed, 7 Jul 2010 03:20:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6F4BB3A67CC for ; Wed, 7 Jul 2010 03:20:15 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2420FC0004; Wed, 7 Jul 2010 12:20:18 +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 eaL5N1uqZQMT; Wed, 7 Jul 2010 12:20:16 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8271BC0002; Wed, 7 Jul 2010 12:20:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 984EE13948F7; Wed, 7 Jul 2010 12:20:12 +0200 (CEST) Date: Wed, 7 Jul 2010 12:20:12 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20100707102012.GA17443@elstar.local> Mail-Followup-To: Ladislav Lhotka , "andyb@iwl.com" , NETMOD Working Group , Gerhard Muenz References: <4C2E2924.8060305@iwl.com> <20100702181042.GA525@elstar.local> <4C2E36CF.2050802@iwl.com> <20100702193020.GB778@elstar.local> <4C2F2352.2060703@net.in.tum.de> <4C2F2472.5020702@net.in.tum.de> <4C2F44DA.9000003@iwl.com> <1278495275.10719.12.camel@missotis> <20100707094845.GA17385@elstar.local> <1278496928.10719.25.camel@missotis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1278496928.10719.25.camel@missotis> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group , Gerhard Muenz Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings 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: Wed, 07 Jul 2010 10:20:16 -0000 On Wed, Jul 07, 2010 at 12:02:08PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder p????e v St 07. 07. 2010 v 11:48 +0200: > > On Wed, Jul 07, 2010 at 11:34:35AM +0200, Ladislav Lhotka wrote: > > > > > Perhaps YANG could define the canonical value for strings to be > > > normalized in some way, either as XML attribute values or just by > > > stripping leading and trailing whitespace. > > > > I believe NETCONF implementations should treat a plain string value as > > an opaque value and not mess around with it. There might be "industry > > practice" tools that do this kind of bad thing but that is not a good > > reason for us to introduce the same misbehaviour into NETCONF. > > I agree, except that using strings as list keys may lead to tricky > problems, especially when the values are entered manually. That's why > key-like things are invariably implemented as attributes in XML, e.g. > > > > rather than > > foo As a data model writer, I would not use unconstrained strings as identifiers or keys. But this is a issue unrelated to the question whether NETCONF messes around with string values. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Wed Jul 7 09:06: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 5427B3A6800 for ; Wed, 7 Jul 2010 09:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiqBKsCYhpYr for ; Wed, 7 Jul 2010 09:06:14 -0700 (PDT) Received: from smtp235.iad.emailsrvr.com (smtp235.iad.emailsrvr.com [207.97.245.235]) by core3.amsl.com (Postfix) with ESMTP id 52B8A3A6847 for ; Wed, 7 Jul 2010 09:06:14 -0700 (PDT) Received: from relay13.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay13.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 8B8E41D4D7C; Wed, 7 Jul 2010 12:06:17 -0400 (EDT) Received: by relay13.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 2FCBE1CCD44; Wed, 7 Jul 2010 12:06:17 -0400 (EDT) Message-ID: <4C34A5E1.30809@iwl.com> Date: Wed, 07 Jul 2010 09:05:53 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100528 Thunderbird/3.0.5 MIME-Version: 1.0 To: Ladislav Lhotka , NETMOD Working Group , Gerhard Muenz References: <4C2E2924.8060305@iwl.com> <20100702181042.GA525@elstar.local> <4C2E36CF.2050802@iwl.com> <20100702193020.GB778@elstar.local> <4C2F2352.2060703@net.in.tum.de> <4C2F2472.5020702@net.in.tum.de> <4C2F44DA.9000003@iwl.com> <1278495275.10719.12.camel@missotis> <20100707094845.GA17385@elstar.local> <1278496928.10719.25.camel@missotis> <20100707102012.GA17443@elstar.local> In-Reply-To: <20100707102012.GA17443@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Disallow leading/trailing whitespaces and non-printable chars in strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 16:06:15 -0000 On 07/07/2010 03:20 AM, Juergen Schoenwaelder wrote: > On Wed, Jul 07, 2010 at 12:02:08PM +0200, Ladislav Lhotka wrote: > >> Juergen Schoenwaelder p????e v St 07. 07. 2010 v 11:48 +0200: >> >>> On Wed, Jul 07, 2010 at 11:34:35AM +0200, Ladislav Lhotka wrote: >>> >>> >>>> Perhaps YANG could define the canonical value for strings to be >>>> normalized in some way, either as XML attribute values or just by >>>> stripping leading and trailing whitespace. >>>> >>> I believe NETCONF implementations should treat a plain string value as >>> an opaque value and not mess around with it. There might be "industry >>> practice" tools that do this kind of bad thing but that is not a good >>> reason for us to introduce the same misbehaviour into NETCONF. >>> >> I agree, except that using strings as list keys may lead to tricky >> problems, especially when the values are entered manually. That's why >> key-like things are invariably implemented as attributes in XML, e.g. >> >> >> >> rather than >> >> foo >> > As a data model writer, I would not use unconstrained strings as > identifiers or keys. But this is a issue unrelated to the question > whether NETCONF messes around with string values. > > Let's review... 1) Phil pointed out that some tools inject whitespace into XML 2) Nobody is claiming that using leading or trailing whitespace is a good idea. (There could be a corner-case like Lada's HTML 'banner' leaf, although unlikely.) 3) If the server encounters L or T WSP, it has to decide what to do with it. Should the server assume the 1 in 10,000 chance that the client really wants this WSP, or assume the 9,999 in 10,000 chance that it is injected WSP and remove it? Forcing every server to implement the 1 in 10,000 chance is a typical IETF move, but it goes against the Postel Principle and is IMO the wrong thing to do. There are claims in various NETCONF documents that NETCONF and even YIN are intended to work well with XSLT. Is this marketing hype or the true intent of the NETCONF and NETMOD WGs? I don't mind removing the guideline completely, but I object to forcing the server to do anything wrt/ whitespace. XML already says what to do, so the server is breaking an XML rule already, and there is no need for redundant guidelines like this one. > /js > > Andy From root@core3.amsl.com Thu Jul 8 12:15: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 898C33A6B57; Thu, 8 Jul 2010 12:15: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: <20100708191502.898C33A6B57@core3.amsl.com> Date: Thu, 8 Jul 2010 12:15:01 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-usage-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: Thu, 08 Jul 2010 19:15:03 -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-08.txt Pages : 32 Date : 2010-07-08 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 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-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-yang-usage-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-08121355.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 12 12:00:13 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 BFF793A6B6E; Mon, 12 Jul 2010 12:00:08 -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: <20100712190011.BFF793A6B6E@core3.amsl.com> Date: Mon, 12 Jul 2010 12:00:09 -0700 (PDT) Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-usage-09.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, 12 Jul 2010 19:00:13 -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-09.txt Pages : 33 Date : 2010-07-12 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-09.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-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12115947.I-D@ietf.org> --NextPart-- From mehmet.ersue@nsn.com Wed Jul 14 04:58: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 3EAB63A68A2 for ; Wed, 14 Jul 2010 04:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FGGo2nrOiLs for ; Wed, 14 Jul 2010 04:58:11 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 16CE43A688C for ; Wed, 14 Jul 2010 04:58:10 -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 o6EBwJSo003844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 14 Jul 2010 13:58:19 +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 o6EBwEpi018137 for ; Wed, 14 Jul 2010 13:58:19 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 13:58:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB234B.D689B8AB" Date: Wed, 14 Jul 2010 13:58:13 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64B1904D@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-linowski-netmod-yang-abstract-03.txt Thread-Index: Acsh50cfqs4dTZ3mT+OjxsOssPC1BwBY5WWg From: "Ersue, Mehmet (NSN - DE/Munich)" To: "NETMOD Working Group" X-OriginalArrivalTime: 14 Jul 2010 11:58:14.0457 (UTC) FILETIME=[D6DDCA90:01CB234B] Subject: [netmod] FW: I-D Action: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: Wed, 14 Jul 2010 11:58:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB234B.D689B8AB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, please find below the v03 draft on "Extending YANG=20 with Language Abstractions". As discussed in Anaheim we intend to publish it as=20 Experimental. Cheers, Mehmet -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext Internet-Drafts@ietf.org Sent: Monday, July 12, 2010 7:15 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-linowski-netmod-yang-abstract-03.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extending YANG with Language Abstractions Author(s) : B. Linowski, et al. Filename : draft-linowski-netmod-yang-abstract-03.txt Pages : 67 Date : 2010-07-12 YANG - the NETCONF Data Modeling Language - supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF. This memo suggests to enhance YANG with supplementary modeling features and language abstractions with the aim to improve the model extensibility and reuse. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-linowski-netmod-yang-abstract- 03.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_001_01CB234B.D689B8AB Content-Type: application/octet-stream; name="draft-linowski-netmod-yang-abstract-03.URL" Content-Transfer-Encoding: base64 Content-Description: draft-linowski-netmod-yang-abstract-03.URL Content-Disposition: attachment; filename="draft-linowski-netmod-yang-abstract-03.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1saW5vd3NraS1uZXRtb2QteWFuZy1hYnN0cmFjdC0wMy50eHQNCg== ------_=_NextPart_001_01CB234B.D689B8AB-- From dromasca@avaya.com Mon Jul 19 08:48:10 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 800DF3A6B20 for ; Mon, 19 Jul 2010 08:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDhtFolxMYd3 for ; Mon, 19 Jul 2010 08:48:09 -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 2E3F53A6922 for ; Mon, 19 Jul 2010 08:48:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,227,1278302400"; d="scan'208";a="25787012" 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 Jul 2010 11:48:22 -0400 X-IronPort-AV: E=Sophos;i="4.55,227,1278302400"; d="scan'208";a="492889419" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Jul 2010 11:48:21 -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, 19 Jul 2010 17:48:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-netmod-arch-07 Thread-Index: AcsnWc4rDd048tMXSGqgbIXhJvrayQ== From: "Romascanu, Dan (Dan)" To: Subject: [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: Mon, 19 Jul 2010 15:48:10 -0000 Please find below the AD review of draft-ietf-netmod-arch-07.txt. I found a number of issues, but none of them seems a show-stopper for me, so my proposal is to send this document to IETF Last Call, and consider these comments together with the other IETF LC comments.=20 Unless I hear any discontent I will send the document to LC tomorrow. Thanks and Regards, Dan ------------------------------------------------------------------------ --------------- The comments are divided into Technical and Editorial.=20 T1. Section 1.1:=20 > 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.=20 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?=20 T3.=20 > 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?=20 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?=20 E1. idnits complains of several things among which the following need to be addressed:=20 Miscellaneous warnings: =20 ------------------------------------------------------------------------ ---- -- 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? .... Checking references for intended status: Informational =20 ------------------------------------------------------------------------ ---- .... -- Unexpected draft version: The latest known version of=20 draft-ietf-netconf-with-defaults is -07, but you're referring to -09. -- Unexpected draft version: The latest known version of=20 draft-ietf-netmod-yang is -12, but you're referring to -13. =3D=3D Outdated reference: A later version (-06) exists of draft-ietf-netmod-dsdl-map-05 =3D=3D Outdated reference: A later version (-09) exists of draft-ietf-netmod-yang-usage-05 E2. Section 1.1 -=20 > The NETCONF specification defines a small set of operations a reference to 4741 seems to be in place at this point.=20 E3. same -=20 > 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.=20 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'?=20 E5. Section 2.3.2=20 > DSDL is considered to be the best choice for the given purpose What purpose? E6. Section 3.1:=20 > 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.=20 The two statements seem contradictory. If the second statement is true than in the first s/is as follows/may be as follows/ E7. Section 3.2 > YANG addresses many of the issues raised in the IAB NM workshop. s/YANG addresses/NETCONF and YANG address/ 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. References would be useful From david.kessens@nsn.com Wed Jul 21 12:24: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 454B53A6B16 for ; Wed, 21 Jul 2010 12:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_46=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 Wcz1oJ4Ob+fz for ; Wed, 21 Jul 2010 12:24:20 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 91F1F3A6AF3 for ; Wed, 21 Jul 2010 12:24:19 -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 o6LJOYXB026888 for ; Wed, 21 Jul 2010 21:24:34 +0200 Received: from localhost.localdomain ([10.138.51.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o6LJOXDb008422 for ; Wed, 21 Jul 2010 21:24:34 +0200 Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.14.4/8.14.3) with ESMTP id o6LJOX1c003329 for ; Wed, 21 Jul 2010 12:24:33 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.4/8.14.4/Submit) id o6LJOWHE003327 for netmod@ietf.org; Wed, 21 Jul 2010 12:24:32 -0700 X-Authentication-Warning: localhost.localdomain: david set sender to david.kessens@nsn.com using -f Date: Wed, 21 Jul 2010 12:24:32 -0700 From: David Kessens To: netmod@ietf.org Message-ID: <20100721192431.GM21326@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] Agenda for netmod session IETF 78 in Maastricht 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, 21 Jul 2010 19:24:21 -0000 Please see below for our first version of an agenda. First of all, we want to apologize that we are a bit late with a published agenda. One of our cochairs was on vacation while our other cochair, David Partain, unfortunately had to, and is still dealing with an emergency which will most likely mean that he cannot make it to Maastricht. As you all know, we are pretty much at the end of our list of work items as defined in our charter. We are very pleased that we reached this point and would like to take the opportunity to thank everybody again who contributed their time and efforts to get us to this point. This also means that we could have theoretically gone without a physical working group session as we won't have to spend a lot of time on our actual work items. However, the fact that we have this much time available means we have the chance to take a look at the future: as discussed at our previous working group session, it becomes now important that we find ways to get the basic yang modules defined in order to make yang useful in the real world. Therefore, we intend to spend most of the time on trying to define a framework for a possible new charter that focusses on defining such a basic set of yang modules. We very much encourage you to start thinking about this topic and perhaps start some discussion on the mailing list on what the goals should be for yang related work in IETF for the short/intermediate term. After this session, we would like to come away with clear directions for (a) volunteer(s) to craft a draft charter. While this is not a formal Birds-of-a-Feather session, people might want to read rfc5434 as this can be a very helpful document to assist in having a focussed discussion. Please let us know whether you have any additional items that you would like to have added to the agenda or if you would like to have a slot for our 'future work' agenda item. David & David --- Agenda (v1): NETMOD WG Meeting: IETF 78 Location: MECC, Maastricht, Netherlands WG Chairs: David Kessens (david.kessens at nsn.com) David Partain (david.partain at ericsson.com) Jabber: xmpp:netmod at jabber.ietf.org WG URL: http://tools.ietf.org/wg/netmod/ TUESDAY, July 27, 2010, 09.00-11.30, Meeting Room: 0.9 Athens 1) Administrivia [chairs][ 5 min ] - minutes scribe {volunteers welcome in advance!} - jabber scribe {volunteers welcome in advance!} - blue sheets - agenda bashing 2) Status Update [chairs][ 5 min ] - How we're doing against the charter 3) Active Drafts For each draft: current status, delta from previous draft, open issues, and discussion. 3.1 Common YANG Data Types http://tools.ietf.org/html/draft-ietf-netmod-yang-types-09 Status: RFC Ed Queue (Juergen Schoenwaelder) 3.2 YANG - A data modeling language for NETCONF http://tools.ietf.org/html/draft-ietf-netmod-yang-13 Status: RFC Ed Queue (Martin Bjorklund) 3.3 YANG Usage Guidelines http://tools.ietf.org/html/draft-ietf-netmod-yang-usage-09 Status: Waiting for AD Go-Ahead (Andy Bierman) 3.4 NETMOD Architecture http://tools.ietf.org/html/draft-ietf-netmod-arch-07 Status: IETF Last Call Requested (Phil Shafer) 3.5 Mapping of YANG to DSDL http://tools.ietf.org/html/draft-ietf-netmod-dsdl-map-06 Status: AD Evaluation (Ladislav Lhotka) 4) Other (non WG) Internet-Drafts, for feedback and discussion [chairs, we will only spend time on these items if we have time] - draft-bierman-netconf-system-monitoring-00.txt Status: new submission (Andy Bierman) - 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 (Juergen Schoenwaelder) - draft-linowski-netmod-yang-abstract-03.txt Status: possibly headed for AD sponsored experimental (Bernd Linowski) 5) I/O with other WGs (NETCONF/IPFIX/others ?), activities this week [chairs] 6) Plans post IETF78 and after completion of charter Questions to answer are: Where do we go from here with yang ? What is still missing that needs to be defined to get yang deployment to happen ? What should not be done ? Volunteers for writing a draft charter ? Volunteers for working on proposed work items ? 7) A.O.B. and open mike [N.N.] {please identify issues in advance} --- From wwwrun@core3.amsl.com Thu Jul 22 07:48:21 2010 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id AFAB33A6BC4; Thu, 22 Jul 2010 07:48:21 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100722144821.AFAB33A6BC4@core3.amsl.com> Date: Thu, 22 Jul 2010 07:48:21 -0700 (PDT) X-Mailman-Approved-At: Thu, 22 Jul 2010 08:05:03 -0700 Cc: netmod@ietf.org Subject: [netmod] Last Call: draft-ietf-netmod-arch (An Architecture for Network Management using NETCONF and YANG) to Informational RFC X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 14:48:22 -0000 The IESG has received a request from the NETCONF Data Modeling Language WG (netmod) to consider the following document: - 'An Architecture for Network Management using NETCONF and YANG ' as an Informational RFC 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-08-05. 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 http://www.ietf.org/internet-drafts/draft-ietf-netmod-arch-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18322&rfc_flag=0 From ietf@andybierman.com Thu Jul 22 19:01:18 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 A966D3A6951 for ; Thu, 22 Jul 2010 19:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=0.642, 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 PyAvwbCMFNL4 for ; Thu, 22 Jul 2010 19:01:18 -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 F30053A68DF for ; Thu, 22 Jul 2010 19:01:17 -0700 (PDT) Received: (qmail 45057 invoked from network); 23 Jul 2010 02:01:33 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 22 Jul 2010 19:01:33 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: QgxmgIQVM1mSPGPpJF1Gy2RK_VVY0FZegimHmN6RRqQbxwv rVAT2hi1QAk1KpM3LdTisrn5Rx0nd08_U4tCiMlvH20vLlAPCB27zk_pwISk Op3R9wk1q97HPBUCrICBpMi3KZKWa65Kr6s3Cl27LZgcW57qocC6qSxaMYGu EWQTKwO.ZtdjrWyFioxCY3Jp2cXJqhwOqlBikCqwek_a2sCRljc2jIlzIGA7 r_cQKIxRY8J4VWz763Y.8HzHHDkyjgYdau_JXOKx9lqo7rVT5NpFOZYIA0DI - X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C48F7FC.1090407@andybierman.com> Date: Thu, 22 Jul 2010 19:01:32 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Thunderbird/3.0.5 MIME-Version: 1.0 To: NETCONF , NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] Network-wide Configuration Bar BoF (M:1700-1930) 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, 23 Jul 2010 02:01:18 -0000 Hi, I added the net-wide-config Bar BoF to the Wiki: http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 Hope everyone at the Maastricht meeting can be there. (Where 'there' is TBD -- a pub to be selected Saturday night :-) Andy From dromasca@avaya.com Fri Jul 23 00:04:56 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 79A293A6897; Fri, 23 Jul 2010 00:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqnjxgVvPET3; Fri, 23 Jul 2010 00:04:55 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 7E2193A68F2; Fri, 23 Jul 2010 00:04:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,246,1278302400"; d="scan'208";a="229240284" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Jul 2010 03:05:13 -0400 X-IronPort-AV: E=Sophos;i="4.55,246,1278302400"; d="scan'208";a="494019718" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Jul 2010 03:05:12 -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, 23 Jul 2010 09:04:54 +0200 Message-ID: In-Reply-To: <4C48F7FC.1090407@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Network-wide Configuration Bar BoF (M:1700-1930) Thread-Index: AcsqCv1qkQDqu2n9SNe931B2xs8KHwAKZHFQ References: <4C48F7FC.1090407@andybierman.com> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "NETCONF" , "NETMOD Working Group" Subject: Re: [netmod] [Netconf] Network-wide Configuration Bar BoF (M:1700-1930) 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, 23 Jul 2010 07:04:56 -0000 Well - you listed time as 17:00 - 19:30 on Monday. We have the open OPSAREA meeting runing until 17:20, and I hope that you and all or most of the potential participants in the BarBOF will attend this, especially as there are a couple of NETMOD related items on the agenda.=20 For me the time slot during the meeting times is not good as I need to cover for Ron (who cannot make the meeting in Maastricht) in OPSEC (17:40 to 19:40). Any reason for not holding the barBOF after meeting times?=20 Dan =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Friday, July 23, 2010 5:02 AM > To: NETCONF; NETMOD Working Group > Subject: [Netconf] Network-wide Configuration Bar BoF (M:1700-1930) >=20 > Hi, >=20 > I added the net-wide-config Bar BoF to the Wiki: >=20 > http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 >=20 > Hope everyone at the Maastricht meeting can be there. > (Where 'there' is TBD -- a pub to be selected Saturday night :-) >=20 >=20 > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From ietf@andybierman.com Fri Jul 23 05:09:38 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 588883A6828 for ; Fri, 23 Jul 2010 05:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.673 X-Spam-Level: X-Spam-Status: No, score=-1.673 tagged_above=-999 required=5 tests=[AWL=0.592, 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 zfRoA-HrnTRD for ; Fri, 23 Jul 2010 05:09:37 -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 98B963A6407 for ; Fri, 23 Jul 2010 05:09:37 -0700 (PDT) Received: (qmail 8414 invoked from network); 23 Jul 2010 12:09:53 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 23 Jul 2010 05:09:53 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: nSAZEc8VM1nBg1JROz_soF8a8JBgTdn8OkyMQ4tdm02oZAx dYiCPm..CmPlgcJWmG9Oimjffp74_ZOp9bsmVuS5myOaZG21juD4psap1jFZ 59RBJ1EBV6ayg2_F8hfc82uUErmP0rACz4IU3hOGQhm3mxVM8wfd9msFPShZ bH75phGw.wWatdNQsGuAAtWsMVt1XGsksjB6VG6NkFovw4d45Jy9PIqxgmWU SUDS8Qz5BxmOjqNTQwhvp0.S2WMZuRxw25STEVw_xyy6ADKYtvWlsTPeXKiJ B X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C498691.6070000@andybierman.com> Date: Fri, 23 Jul 2010 05:09:53 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" References: <4C48F7FC.1090407@andybierman.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF , NETMOD Working Group Subject: Re: [netmod] [Netconf] Network-wide Configuration Bar BoF (M:1700-1930) 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, 23 Jul 2010 12:09:38 -0000 On 07/23/2010 12:04 AM, Romascanu, Dan (Dan) wrote: > Well - you listed time as 17:00 - 19:30 on Monday. We have the open > OPSAREA meeting runing until 17:20, and I hope that you and all or most > of the potential participants in the BarBOF will attend this, especially > as there are a couple of NETMOD related items on the agenda. > > For me the time slot during the meeting times is not good as I need to > cover for Ron (who cannot make the meeting in Maastricht) in OPSEC > (17:40 to 19:40). Any reason for not holding the barBOF after meeting > times? oops -- my intent was to place the BoF after the break following the OPSAREA meeting. Martin had requested that Nigel be present, who could not attend later on. That is why it was 5pm. Should I change it to 17:40, 20:00, something else? > > Dan Andy > > >> -----Original Message----- >> From: netconf-bounces@ietf.org >> [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman >> Sent: Friday, July 23, 2010 5:02 AM >> To: NETCONF; NETMOD Working Group >> Subject: [Netconf] Network-wide Configuration Bar BoF (M:1700-1930) >> >> Hi, >> >> I added the net-wide-config Bar BoF to the Wiki: >> >> http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 >> >> Hope everyone at the Maastricht meeting can be there. >> (Where 'there' is TBD -- a pub to be selected Saturday night :-) >> >> >> Andy >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > From ietf@andybierman.com Fri Jul 23 10:59:18 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 692E83A69F2 for ; Fri, 23 Jul 2010 10:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.481, 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 7FFYmMlDl2ju for ; Fri, 23 Jul 2010 10:59:17 -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 740C63A6887 for ; Fri, 23 Jul 2010 10:59:15 -0700 (PDT) Received: (qmail 54714 invoked from network); 23 Jul 2010 17:59:31 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 23 Jul 2010 10:59:30 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: GC9Qk7IVM1kWiEQv.15nZeF2Lr1ayJ3XmfxFmUZeLSDONCe 3qOav3RcgPfG6ynO919Q92fpuzWzs5OKWXWSa3PBGTRpN.gtGxI7owkMrIXZ f5rzhf3wV5SrNJQjG0omwa2kWRYcNIz3A9dbYFwjPe3ZCzUcgNbkjmk6F.lB _KCN4o0UFFdrk3qrQOvHw_N7hQ0EreSI7UhC42Zmfub4_.1FqUx_5yZMKLcf ST4djRu_2M1klhCrXMNhXnrluoBqdnW_F7n4teL2ONpZjRheWZO9nTQGplSk - X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C49D881.4090404@andybierman.com> Date: Fri, 23 Jul 2010 10:59:29 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Thunderbird/3.0.5 MIME-Version: 1.0 To: NETCONF , NETMOD Working Group References: <4C48F7FC.1090407@andybierman.com> In-Reply-To: <4C48F7FC.1090407@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] [Netconf] Network-wide Configuration Bar BoF (M:1700-1930) 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, 23 Jul 2010 17:59:18 -0000 On 07/22/2010 07:01 PM, Andy Bierman wrote: > Hi, > > I added the net-wide-config Bar BoF to the Wiki: > > http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 > > Hope everyone at the Maastricht meeting can be there. > (Where 'there' is TBD -- a pub to be selected Saturday night :-) > I changed the time-slot: now 17:40 to 20:00. > Andy From ietf@andybierman.com Mon Jul 26 03:58: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 7BF433A6A49 for ; Mon, 26 Jul 2010 03:58:34 -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 F5KU8Vw0eKMF for ; Mon, 26 Jul 2010 03:58:33 -0700 (PDT) Received: from smtp102.sbc.mail.re3.yahoo.com (smtp102.sbc.mail.re3.yahoo.com [66.196.96.85]) by core3.amsl.com (Postfix) with SMTP id 83CAC3A6AA8 for ; Mon, 26 Jul 2010 03:58:33 -0700 (PDT) Received: (qmail 22324 invoked from network); 26 Jul 2010 10:58:52 -0000 Received: from [130.129.118.141] (ietf@130.129.118.141 with plain) by smtp102.sbc.mail.re3.yahoo.com with SMTP; 26 Jul 2010 03:58:52 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: IfRtACIVM1lkfBA7JdjBacVYLjJBQJjunpjpF5N_6pErDMn XOAONJ8YGuD6OocAZUOMHF5a5sBWYxoD_CbJ_P83ZpbNwpkHcejajtXt5sJ1 VZRugaPBzl9AnFsyAq8WmfCOinUGwiixVgyj1sQItvg5JX782xuo8zjsstIq nvhkk08DzV6BniFAgI44ogDEVhMoKITDfRhnMXDYDBZyGhjdrx6pXBF94ZBN pU2f9n8luLtdqWDWT4FuGoFPVLTlrHnRODXcm4Dq1hQb9Qp65XGQ8wq0lruH .Rvt8Vw_Mqqtj5g9a.A8cECwFStvU5_APMIq1D13u4rWBI0eajiPkvAtrHt6 kkm48SPqpp4kBgkysP3UfTNpNiOshQZ2nQAxdNc5l7Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C4D6A6B.6070406@andybierman.com> Date: Mon, 26 Jul 2010 03:58:51 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Thunderbird/3.0.5 MIME-Version: 1.0 To: NETCONF , NETMOD Working Group References: <4C48F7FC.1090407@andybierman.com> <4C49D881.4090404@andybierman.com> In-Reply-To: <4C49D881.4090404@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] [Netconf] Network-wide Configuration Bar BoF (M:1700-1930) 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, 26 Jul 2010 10:58:34 -0000 On 07/23/2010 10:59 AM, Andy Bierman wrote: > On 07/22/2010 07:01 PM, Andy Bierman wrote: >> Hi, >> >> I added the net-wide-config Bar BoF to the Wiki: >> >> http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 >> >> Hope everyone at the Maastricht meeting can be there. >> (Where 'there' is TBD -- a pub to be selected Saturday night :-) >> > > I changed the time-slot: now 17:40 to 20:00. > The network-wide config Bar BoF will be held at the bar in the lobby of the MH Maastricht hotel from 17:40 to about 19:40. After that, some people will be going to the city center for food and more beer. > >> > > Andy Andy From ietf@andybierman.com Mon Jul 26 05:39:59 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 8D1D43A6A21 for ; Mon, 26 Jul 2010 05:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZMJMR435rMd for ; Mon, 26 Jul 2010 05:39:58 -0700 (PDT) Received: from smtp103.sbc.mail.re3.yahoo.com (smtp103.sbc.mail.re3.yahoo.com [66.196.96.86]) by core3.amsl.com (Postfix) with SMTP id 751D83A6918 for ; Mon, 26 Jul 2010 05:39:58 -0700 (PDT) Received: (qmail 76984 invoked from network); 26 Jul 2010 12:40:16 -0000 Received: from [130.129.118.141] (ietf@130.129.118.141 with plain) by smtp103.sbc.mail.re3.yahoo.com with SMTP; 26 Jul 2010 05:40:16 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: RQLNPTkVM1lvID659MekazsOxmohbV8NiOENnHGAMyXnuzT XvhKblGFyqXByjhYAylVfCPvynKNx6gwiew_dPIf.y1KQIoW7UmswUl7UCi4 uti_D7i41zIJ0QmeO9IIvSKOjC_BMiyAOmRodELdNyTCR89FQV3YlebvUxpK i7V78uUzjBt75ia5q1SqFh_YXXv0x1mJmHTjhkjEWO2p98iPuGU2R8kqJ3Xu .3bZt8Ibbw_HApOC7Jd8YaAIEV_G7OuCZgzN7Iqy1vQ.8BreXhydYAX9urer 2480dKyM.IS.DqgSCg_oIKH5SF1NkaTKysqcHoRQAPPPRWJ7dkDCNAzFkxqT DxGOBM_mMMQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C4D822E.9020804@andybierman.com> Date: Mon, 26 Jul 2010 05:40:14 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Thunderbird/3.0.5 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [netmod] dsdl draft comments 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, 26 Jul 2010 12:39:59 -0000 Hi, I am reviewing the DSDL mapping document. I find it to be very thorough and complete, although I am not a DSDL expert at all. pg. 29) - perhaps the DSDL mapping for this YANG fragment should be added (outer/c1,c2,c3) pg 31) - perhaps container "cont" should be in the DSDL mapping. only the groupings are mapped, not the 'uses' in this container 10.13) why MAY be ignored? IMO the mapping to annotation should be mandatory. Not sure what is gained by making this optional Same comment for reference-stmt (10.47) and status-stmt (10.51) units-stmt (10.56) 10.16, 10.17) - I think the error-message and error-app-tag sub-stmts need to apply to pattern-stmt and range-stmt, not just must-stmt. 11. I don't really understand DSRL so it is hard to comment too much. I would be good to have examples in every case, but not critical. The overall need for a secondary schema after the hybrid schema is not very clear to me. I think it is to validate specific NETCONF operations, and the hybrid is a 'static database' view. If so, more intro text would be helpful. 12.9 I do not understand the purpose of the nma@leaf-list attribute C.3.4) it would be useful to have a final schema example for an edit-config or copy-config, not just get. From lhotka@cesnet.cz Mon Jul 26 07:51: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 CA9B93A681A for ; Mon, 26 Jul 2010 07:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.604, 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 cVJqwbUVm6Gu for ; Mon, 26 Jul 2010 07:51:19 -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 47FF23A680B for ; Mon, 26 Jul 2010 07:51:17 -0700 (PDT) Received: from [IPv6:2001:df8:0:144:221:ff:feb6:15fe] (unknown [IPv6:2001:df8:0:144:221:ff:feb6:15fe]) by office2.cesnet.cz (Postfix) with ESMTPSA id D1C672CDE061; Mon, 26 Jul 2010 16:51:36 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4C4D822E.9020804@andybierman.com> References: <4C4D822E.9020804@andybierman.com> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Mon, 26 Jul 2010 16:51:35 +0200 Message-ID: <1280155895.4787.90.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] dsdl draft comments 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, 26 Jul 2010 14:51:21 -0000 Hi Andy, thanks for your commments, my replies are inline. On Po, 2010-07-26 at 05:40 -0700, Andy Bierman wrote: > Hi, > > I am reviewing the DSDL mapping document. > I find it to be very thorough and complete, although > I am not a DSDL expert at all. > > pg. 29) > - perhaps the DSDL mapping for this YANG fragment should be added > (outer/c1,c2,c3) This example illustrates the notions of "mandatory" and "implicit" nodes, it could be confusing to use the annotations that represent them in the hybrid schema before these annotations are specified. > > pg 31) > - perhaps container "cont" should be in the DSDL mapping. > only the groupings are mapped, not the 'uses' in this container Yes, I could add it, but the advantage of showing only the named pattern definitions is that (unlike the definition of "cont") they don't use the module's NS prefix, so the prefix needn't be defined in the snippet. And having the entire hybrid schema here would IMO make the point less clear. > > 10.13) why MAY be ignored? > IMO the mapping to annotation should be mandatory. > Not sure what is gained by making this optional > Same comment for reference-stmt (10.47) and status-stmt (10.51) > units-stmt (10.56) Off-the-shelf tools can't make any use of these documentation strings, so I reckon it could be useful only for a (poor) person reading the hybrid schema, who should probably be reading the YANG module instead. > > 10.16, 10.17) > - I think the error-message and error-app-tag sub-stmts > need to apply to pattern-stmt and range-stmt, not just must-stmt. Error messages from 'must' are directly used in Schematron rules. In contrast, patterns and ranges are validated in RELAX NG and so the specific messages would be of no use, even if they were present in the hybrid schema. > > 11. I don't really understand DSRL so it is hard to comment too much. > I would be good to have examples in every case, but not critical. One example is in sec. 11.3 and another is the DHCP example in appendix C. > The overall need for a secondary schema after the hybrid schema > is not very clear to me. I think it is to validate specific > NETCONF operations, and the hybrid is a 'static database' view. > If so, more intro text would be helpful. The hybrid schema cannot be fed to any off-the-shelf tool, and the secondary schemas are the actual DSDL stuff that can be used for validating instance XML documents. > > 12.9 I do not understand the purpose of the nma@leaf-list attribute The purpose is to distinguish leaf-lists from other lists since leaf-lists has to be checked for duplicate entries. It may be recognizable directly from the hybrid schema, this annotation just makes it explicit and easier. > > C.3.4) it would be useful to have a final schema example for an > edit-config or copy-config, not just get. Schemas for edit-config - as well as e.g. get request with a subtree filter - is a harder problem and I don't have an acceptable solution yet. However, the relationship between the schemas for the datastore and edit-config is not specific to DSDL, so I consider it outside the scope of the DSDL mapping spec. I could add the schemas for copy-config but would it show anything new compared to the get reply? Lada > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From david.kessens@nsn.com Mon Jul 26 08:04: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 2B8AC3A6AC0 for ; Mon, 26 Jul 2010 08:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02npRm1KOV8s for ; Mon, 26 Jul 2010 08:04:30 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id DEB8D3A6AB5 for ; Mon, 26 Jul 2010 08:04:29 -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 o6QF4nhG017057 for ; Mon, 26 Jul 2010 17:04:49 +0200 Received: from localhost.localdomain ([10.150.189.113]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o6QF4nmS012880 for ; Mon, 26 Jul 2010 17:04:49 +0200 Received: from localhost.localdomain (david [127.0.0.1]) by localhost.localdomain (8.14.3/8.14.3) with ESMTP id o6QF4nru004259 for ; Mon, 26 Jul 2010 08:04:49 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.3/8.14.3/Submit) id o6QF4nao004257 for netmod@ietf.org; Mon, 26 Jul 2010 08:04:49 -0700 Date: Mon, 26 Jul 2010 08:04:49 -0700 From: David Kessens To: netmod@ietf.org Message-ID: <20100726150448.GE3915@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [netmod] Request for scribes 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, 26 Jul 2010 15:04:31 -0000 To get our meeting off to quick start, I would like to ask in advance whether anybody is willing to volunteer to be our minute taker and/or jabber scribe. Thanks! David Kessens --- From lhotka@cesnet.cz Tue Jul 27 01:24: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 D711C3A6A1F for ; Tue, 27 Jul 2010 01:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.402, 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 W1nVuDLqptaK for ; Tue, 27 Jul 2010 01:24:26 -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 DA9913A6A92 for ; Tue, 27 Jul 2010 01:24:25 -0700 (PDT) Received: from [IPv6:2001:df8:0:144:221:ff:feb6:15fe] (unknown [IPv6:2001:df8:0:144:221:ff:feb6:15fe]) by office2.cesnet.cz (Postfix) with ESMTPSA id 73A092CDE058 for ; Tue, 27 Jul 2010 10:24:46 +0200 (CEST) From: Ladislav Lhotka To: NETMOD Working Group Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 27 Jul 2010 10:24:45 +0200 Message-ID: <1280219085.1523.9.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [netmod] comparison of IP addresses 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, 27 Jul 2010 08:24:26 -0000 Hi, following Juergen's comment in the meeting, I looked up what YANG spec says about the canonical forms - it only requires the server to return each value in the canonical form. Nothing seems to prevent or discourage a module writer from using non-canonical constants in XPath expressions, for example must "ip-address = '0::1'"; This comparison won't work as expected. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Jul 27 01:47:05 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 264393A6BCA for ; Tue, 27 Jul 2010 01:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.68 X-Spam-Level: X-Spam-Status: No, score=-0.68 tagged_above=-999 required=5 tests=[AWL=0.080, 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 q0zNuesUNERg for ; Tue, 27 Jul 2010 01:47:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2FA7A3A6BC7 for ; Tue, 27 Jul 2010 01:46:53 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 79868C0002; Tue, 27 Jul 2010 10:47:14 +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 HTwSEJK7c6Px; Tue, 27 Jul 2010 10:47: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 5DED7C0009; Tue, 27 Jul 2010 10:47:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BBADC13DCCC0; Tue, 27 Jul 2010 10:47:12 +0200 (CEST) Date: Tue, 27 Jul 2010 10:47:12 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20100727084712.GA56495@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <1280219085.1523.9.camel@nomad> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1280219085.1523.9.camel@nomad> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] comparison of IP addresses 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, 27 Jul 2010 08:47:05 -0000 On Tue, Jul 27, 2010 at 10:24:45AM +0200, Ladislav Lhotka wrote: > Hi, > > following Juergen's comment in the meeting, I looked up what YANG spec > says about the canonical forms - it only requires the server to return > each value in the canonical form. Nothing seems to prevent or discourage > a module writer from using non-canonical constants in XPath expressions, > for example > > must "ip-address = '0::1'"; > > This comparison won't work as expected. Yes, this leads to the same result as "ip-address = 'foobar'". If we are lucky YANG compilers will get smart enough over time to detect such things and that would be cool. But clearly, the bug is made by the YANG module writer and at this time I do not think we need to add extensions to YANG to make YANG module writers more efficient. /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 Jul 27 02:32: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 A31E23A68CC for ; Tue, 27 Jul 2010 02:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.302, 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 PENW8AJFubx3 for ; Tue, 27 Jul 2010 02:32: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 50AB73A6A55 for ; Tue, 27 Jul 2010 02:32:23 -0700 (PDT) Received: from [IPv6:2001:df8:0:144:221:ff:feb6:15fe] (unknown [IPv6:2001:df8:0:144:221:ff:feb6:15fe]) by office2.cesnet.cz (Postfix) with ESMTPSA id 6E2792CDE058; Tue, 27 Jul 2010 11:32:44 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20100727084712.GA56495@elstar.local> References: <1280219085.1523.9.camel@nomad> <20100727084712.GA56495@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Tue, 27 Jul 2010 11:32:43 +0200 Message-ID: <1280223163.1523.29.camel@nomad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] comparison of IP addresses 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, 27 Jul 2010 09:32:27 -0000 On Út, 2010-07-27 at 10:47 +0200, Juergen Schoenwaelder wrote: > On Tue, Jul 27, 2010 at 10:24:45AM +0200, Ladislav Lhotka wrote: > > Hi, > > > > following Juergen's comment in the meeting, I looked up what YANG spec > > says about the canonical forms - it only requires the server to return > > each value in the canonical form. Nothing seems to prevent or discourage > > a module writer from using non-canonical constants in XPath expressions, > > for example > > > > must "ip-address = '0::1'"; > > > > This comparison won't work as expected. > > Yes, this leads to the same result as "ip-address = 'foobar'". If we > are lucky YANG compilers will get smart enough over time to detect > such things and that would be cool. But clearly, the bug is made by A non-canonical value may also come from the client, e.g. as a list key. Lada > the YANG module writer and at this time I do not think we need to add > extensions to YANG to make YANG module writers more efficient. > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Jul 27 05:13: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 D355E3A6A20 for ; Tue, 27 Jul 2010 05:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.428 X-Spam-Level: X-Spam-Status: No, score=-1.428 tagged_above=-999 required=5 tests=[AWL=0.821, 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 wxDlTUVwN2rH for ; Tue, 27 Jul 2010 05:13:09 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6AE333A68F6 for ; Tue, 27 Jul 2010 05:13:09 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0863BC0011; Tue, 27 Jul 2010 14:13:31 +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 gAlQw6-tpHEa; Tue, 27 Jul 2010 14:13:30 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 065C2C000F; Tue, 27 Jul 2010 14:13:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0EEA313DD3D6; Tue, 27 Jul 2010 14:13:29 +0200 (CEST) Date: Tue, 27 Jul 2010 14:13:29 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20100727121329.GA56725@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <1280219085.1523.9.camel@nomad> <20100727084712.GA56495@elstar.local> <1280223163.1523.29.camel@nomad> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1280223163.1523.29.camel@nomad> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] comparison of IP addresses 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, 27 Jul 2010 12:13:11 -0000 On Tue, Jul 27, 2010 at 11:32:43AM +0200, Ladislav Lhotka wrote: > On ??t, 2010-07-27 at 10:47 +0200, Juergen Schoenwaelder wrote: > > On Tue, Jul 27, 2010 at 10:24:45AM +0200, Ladislav Lhotka wrote: > > > Hi, > > > > > > following Juergen's comment in the meeting, I looked up what YANG spec > > > says about the canonical forms - it only requires the server to return > > > each value in the canonical form. Nothing seems to prevent or discourage > > > a module writer from using non-canonical constants in XPath expressions, > > > for example > > > > > > must "ip-address = '0::1'"; > > > > > > This comparison won't work as expected. > > > > Yes, this leads to the same result as "ip-address = 'foobar'". If we > > are lucky YANG compilers will get smart enough over time to detect > > such things and that would be cool. But clearly, the bug is made by > > A non-canonical value may also come from the client, e.g. as a list key. Yes, use of the canonical format is a good thing. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Wed Jul 28 03:49: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 3075A28C107; Wed, 28 Jul 2010 03:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id megdmv1h-9fn; Wed, 28 Jul 2010 03:49:54 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 145133A6A56; Wed, 28 Jul 2010 03:49:52 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o6SA7Uo5009576; Wed, 28 Jul 2010 12:07:30 +0200 (CEST) Received: from [10.61.89.228] (ams3-vpn-dhcp6629.cisco.com [10.61.89.228]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o6SA7UE3009568; Wed, 28 Jul 2010 12:07:30 +0200 (CEST) Message-ID: <4C500162.2010706@cisco.com> Date: Wed, 28 Jul 2010 12:07:30 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Andy Bierman References: <4C48F7FC.1090407@andybierman.com> <4C49D881.4090404@andybierman.com> <4C4D6A6B.6070406@andybierman.com> In-Reply-To: <4C4D6A6B.6070406@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETCONF , NETMOD Working Group Subject: Re: [netmod] [Netconf] Network-wide Configuration Bar BoF (M:1700-1930) 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, 28 Jul 2010 10:49:55 -0000 Andy, Any conclusions from this Bar BoF? Regards, Benoit. > The network-wide config Bar BoF will be held at the bar in the lobby > of the MH Maastricht hotel from 17:40 to about 19:40. > After that, some people will be going to the city center > for food and more beer. > > > >> >>> >> Andy >> > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From ietf@andybierman.com Wed Jul 28 05:56: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 76FEC28C178 for ; Wed, 28 Jul 2010 05:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.790, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BK16U2tlt0Vw for ; Wed, 28 Jul 2010 05:56:44 -0700 (PDT) Received: from smtp101.sbc.mail.re3.yahoo.com (smtp101.sbc.mail.re3.yahoo.com [66.196.96.84]) by core3.amsl.com (Postfix) with SMTP id 4C95028C175 for ; Wed, 28 Jul 2010 05:56:43 -0700 (PDT) Received: (qmail 22315 invoked from network); 28 Jul 2010 12:57:04 -0000 Received: from [130.129.118.141] (ietf@130.129.118.141 with plain) by smtp101.sbc.mail.re3.yahoo.com with SMTP; 28 Jul 2010 05:57:03 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: TaDyVKQVM1lWQRvhpBNa9bKzVdAb4wgebwHFZHF6vW8Rjya vTMdf58Nfrm2kPPcwM0qCBIJ8CotTzGz3Jq2qD7XTcfYoP_nKVp0t8ieOu_m miRxzW4Y3Kzj9LV9RzgdzgT8T5NJQTdC.yI6dhs_7u1KZAv9.2oZiLEMDrqz zG68nEJK6f5CZpTMAQgXveGMaQWc9Oklh6XDWA7xvrgj.EozW5V4.6CiOgP7 RqwL9u7Hm5s5tm9ZZs6o84A4Kbk7ZD5A9Zfkwxu18C12XhoT0BnjHwKPElpP ah90TDKl2YnJw9r.719IbCdhlnOIPqFiP.kbwWj3KLPVs71k9Drph8LHIzTF WRyoTiaBABb2DNJ9wADj0jAWAVx5KX_bkKcWnI3yAAA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C50291E.3000000@andybierman.com> Date: Wed, 28 Jul 2010 05:57: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: Benoit Claise References: <4C48F7FC.1090407@andybierman.com> <4C49D881.4090404@andybierman.com> <4C4D6A6B.6070406@andybierman.com> <4C500162.2010706@cisco.com> In-Reply-To: <4C500162.2010706@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETCONF , NETMOD Working Group Subject: Re: [netmod] [Netconf] Network-wide Configuration Bar BoF (M:1700-1930) 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, 28 Jul 2010 12:56:45 -0000 On 07/28/2010 03:07 AM, Benoit Claise wrote: > Andy, > > Any conclusions from this Bar BoF? > There was an interesting discussion. This topic means different things to different people. There is some concern that leaf-level device interoperability within the NETCONF database will be difficult to achieve, due to vendor product differentiation and inherent complexity of mixing config APIs within a single server. Solution discussion summary: - use of sophisticated config mechanisms to reduce the amount of 'raw config data' that a client must understand about the servers - use of dynamic defaults - use of XPath expressions and server-specific meta-data (e.g., XPath variables) to allow the server to fill in the raw config data instead of the client - use of a network view data model to identify all the servers and the config data associated with each server. The model would focus on the inter-connections between the servers and the simplified view of the network service being managed. This is what we called a network model. - use of the TM Forum SID as the network model to manage the NETCONF servers - use of YANG as the top-level model which would integrate somehow with YANG device models; not clear if a standard algorithm for converting from network to device-level would be possible or mandatory. There was agreement that the architecture requires a 2-tier 'compiler' approach. The client should only need to understand the network model (e.g. source code) and the NETCONF server should somehow translate the content from this model to device-specific content (e.g., ASM code). It is understood that the client may lose visibility of the device-level config contents if the network model is used instead. There is also a need to tune the device-level content sometimes. A traffic shaping example was discussed. Let's say a router has 5 ways to control traffic shaping. A network model would focus on the common properties and not the details of any specific method. The client would provide the desired parameters and the server would pick 1 of its 5 methods and setup the raw device config data accordingly. But if the client wants more control than that, a mechanism to force the server to pick a specific method of the 5 would be needed. It is not clear what this solution would look like. Next steps: - Phil Shafer will publish an I-D on network-wide config soon - produce 1 or more I-Ds and either have a BoF at IETF #79 or recharter the NETMOD WG to work on this - need to setup a conference-call to discuss SIM further and possible I-D on this approach > Regards, Benoit. Andy >> The network-wide config Bar BoF will be held at the bar in the lobby >> of the MH Maastricht hotel from 17:40 to about 19:40. >> After that, some people will be going to the city center >> for food and more beer. >> >> >> >>> >>>> >>> Andy >>> >> Andy >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > From j.schoenwaelder@jacobs-university.de Wed Jul 28 06:12:05 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 7C9D128C18E for ; Wed, 28 Jul 2010 06:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=0.727, 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 DPs3i9AqaVh5 for ; Wed, 28 Jul 2010 06:12:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E136C28C193 for ; Wed, 28 Jul 2010 06:12:03 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 79547C000C; Wed, 28 Jul 2010 15:12:26 +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 4pmBCs4mRuMY; Wed, 28 Jul 2010 15:12:25 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 764E2C0009; Wed, 28 Jul 2010 15:12:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A5E7713ECCE8; Wed, 28 Jul 2010 15:12:24 +0200 (CEST) Date: Wed, 28 Jul 2010 15:12:24 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100728131224.GB18698@elstar.local> Mail-Followup-To: Andy Bierman , NETMOD Working Group References: <4C48F7FC.1090407@andybierman.com> <4C49D881.4090404@andybierman.com> <4C4D6A6B.6070406@andybierman.com> <4C500162.2010706@cisco.com> <4C50291E.3000000@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C50291E.3000000@andybierman.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: NETMOD Working Group Subject: Re: [netmod] [Netconf] Network-wide Configuration Bar BoF (M:1700-1930) 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: Wed, 28 Jul 2010 13:12:05 -0000 On Wed, Jul 28, 2010 at 02:57:02PM +0200, Andy Bierman wrote: > - need to setup a conference-call to discuss SIM further > and possible I-D on this approach What is SIM? /js (dropping NETCONF form the CC list) -- 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 Wed Jul 28 06:15: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 1FCF428C181 for ; Wed, 28 Jul 2010 06:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFGl4wa3zITj for ; Wed, 28 Jul 2010 06:15:17 -0700 (PDT) Received: from smtp102.sbc.mail.ac4.yahoo.com (smtp102.sbc.mail.ac4.yahoo.com [76.13.13.241]) by core3.amsl.com (Postfix) with SMTP id 4DC4F28C175 for ; Wed, 28 Jul 2010 06:15:14 -0700 (PDT) Received: (qmail 3648 invoked from network); 28 Jul 2010 13:15:27 -0000 Received: from [130.129.128.249] (ietf@130.129.128.249 with plain) by smtp102.sbc.mail.ac4.yahoo.com with SMTP; 28 Jul 2010 06:15:26 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: YsZB7vMVM1kmwCLzAr6oPA4og5JoB4nRw5ucO7HP9cd674u b.ALiWIXCohu8lO8IVUWCqZcG37aJCHgQ3_n4LInBEXve_uKkkbehlfbW3ma JaFLhc0WVFOzpUJFzuPgoCpCxeqEa5FAg6apZ8imk6CAdrabwC1jN4k3ewl9 8XfiwABLUXdigJfbWOic3lLouC.7bI2B53dUsrmxrj64pvDpBfFe3NdwBqVu 0pzbXYwGWR7IjyAS6AKm0qQm0ycx0 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C502D6D.7030906@andybierman.com> Date: Wed, 28 Jul 2010 06:15: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: NETMOD Working Group References: <4C48F7FC.1090407@andybierman.com> <4C49D881.4090404@andybierman.com> <4C4D6A6B.6070406@andybierman.com> <4C500162.2010706@cisco.com> <4C50291E.3000000@andybierman.com> <20100728131224.GB18698@elstar.local> In-Reply-To: <20100728131224.GB18698@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] [Netconf] Network-wide Configuration Bar BoF (M:1700-1930) 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, 28 Jul 2010 13:15:20 -0000 On 07/28/2010 06:12 AM, Juergen Schoenwaelder wrote: > On Wed, Jul 28, 2010 at 02:57:02PM +0200, Andy Bierman wrote: > >> - need to setup a conference-call to discuss SIM further >> and possible I-D on this approach > > What is SIM? a typo -- I meant SID > > /js (dropping NETCONF form the CC list) > Andy