From mbj@tail-f.com Fri Dec 2 03:58:18 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8097621F942D for ; Fri, 2 Dec 2011 03:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6jxoidiDUZp for ; Fri, 2 Dec 2011 03:58:18 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 00A8021F9389 for ; Fri, 2 Dec 2011 03:58:17 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id EB08112008D2; Fri, 2 Dec 2011 12:58:15 +0100 (CET) Date: Fri, 02 Dec 2011 12:58:14 +0100 (CET) Message-Id: <20111202.125814.455123188.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <87borvcb3n.fsf@cesnet.cz> References: <20111114.135017.268510208816363038.mbj@tail-f.com> <87borvcb3n.fsf@cesnet.cz> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 11:58:18 -0000 Hi, Ladislav Lhotka wrote: > Hi, > > On Mon, 14 Nov 2011 13:50:17 +0100 (CET), Martin Bjorklund > wrote: > > > > o Why don't we have a ipv6-unicast module? > > > > I'd like to write the "ietf-ipv6-unicast-routing" module but first we > need to agree on the distribution of IPv6 parameters between this module > and "ietf-ip". > > In the next revision of the "ietf-routing" module, I plan to add a list > of interfaces under /rt:routing/rt:router with key being a leafref > pointing to a configured logical interface. This is necessary in order to > be able to specify the logical interfaces that belong to each logical > router. As a side effect, interface parameters that are only relevant > for routers, such as RA configuration, can be put here rather than under > /if:interfaces. > > Any opinions or suggestions? I need to think about the implications, but so far I think I like this idea. A couple of questions: Does each router have a *list* of interfaces? Can it be empty? Can an interface be pointed to by more than one router? /martin From lhotka@cesnet.cz Fri Dec 2 04:17:48 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F369321F993A for ; Fri, 2 Dec 2011 04:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwYo1BxVH3Kv for ; Fri, 2 Dec 2011 04:17:47 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 345F121F9934 for ; Fri, 2 Dec 2011 04:17:47 -0800 (PST) Received: from dhcp-73-142.eduroam.muni.cz (dhcp-73-142.eduroam.muni.cz [147.251.73.142]) by office2.cesnet.cz (Postfix) with ESMTPSA id A91B72CDE05C for ; Fri, 2 Dec 2011 13:17:43 +0100 (CET) From: Ladislav Lhotka Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_08BCD8A4-58CC-45BF-A5F8-77D063D1A90A"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 2 Dec 2011 13:17:43 +0100 In-Reply-To: <20111202.125814.455123188.mbj@tail-f.com> To: netmod@ietf.org References: <20111114.135017.268510208816363038.mbj@tail-f.com> <87borvcb3n.fsf@cesnet.cz> <20111202.125814.455123188.mbj@tail-f.com> Message-Id: <3BE63DC3-1EB4-40CC-B390-DE030F4B142D@cesnet.cz> X-Mailer: Apple Mail (2.1251.1) Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 12:17:48 -0000 --Apple-Mail=_08BCD8A4-58CC-45BF-A5F8-77D063D1A90A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 2, 2011, at 12:58 PM, Martin Bjorklund wrote: > Hi, >=20 >=20 > Ladislav Lhotka wrote: >> Hi, >>=20 >> On Mon, 14 Nov 2011 13:50:17 +0100 (CET), Martin Bjorklund = >> wrote: >>>=20 >>> o Why don't we have a ipv6-unicast module? >>>=20 >>=20 >> I'd like to write the "ietf-ipv6-unicast-routing" module but first we >> need to agree on the distribution of IPv6 parameters between this = module >> and "ietf-ip". >>=20 >> In the next revision of the "ietf-routing" module, I plan to add a = list >> of interfaces under /rt:routing/rt:router with key being a leafref >> pointing to a configured logical interface. This is necessary in = order to >> be able to specify the logical interfaces that belong to each logical >> router. As a side effect, interface parameters that are only relevant >> for routers, such as RA configuration, can be put here rather than = under >> /if:interfaces.=20 >>=20 >> Any opinions or suggestions? >=20 > I need to think about the implications, but so far I think I like this > idea. A couple of questions: >=20 > Does each router have a *list* of interfaces? Can it be empty? Yes, each router will have to have this list, probably with min-elements = =3D 1, because it doesn't make much sense to have a router without = interfaces. >=20 > Can an interface be pointed to by more than one router? JUNOS implementation of logical routers doesn't allow this but in = general I can imagine a different logic where this might be allowed, = for example if one logical router is for IPv4 and another for IPv6. So = my plan is not to have this constraint in the module, and leave it to = implementations to specify additional business rules if necessary.=20 Lada >=20 >=20 > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_08BCD8A4-58CC-45BF-A5F8-77D063D1A90A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMjAyMTIxNzQ0WjAjBgkqhkiG9w0BCQQxFgQUR2wrc+7R0aNZLcpyWiBBlZs/0jcwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQBUKUSnP7lFfpFddNQE3D2Tnthf jno85mtgY6tIkWSB+vFwYLPmrlLSteD/SfD5ekXuYYS0CygwkAVOeSWwk745eNZHE4N9QsF9gZCx yX6x4Adj5XQZcg9/bikbWeA2kI4ffUPF0z+lFrrK1U41stOLRaHDNiFXNF9Taf+NWyyz3ahyGcKo sgpRCSfPHS7iwct2quOCU+T4xKNltcYrE9hmYtSPtcYeCTGKqMlvwsuD+rjfcKJhIyQ7qCvaOl+N NFpW4RWMfKr9QztGqyK5Ed+roGMvCqzJ9cR/hXpeRtpTsr2oAD6Fv3DuysflAJyj571NjaCatPKP NcRXXnPKjj5PAAAAAAAA --Apple-Mail=_08BCD8A4-58CC-45BF-A5F8-77D063D1A90A-- From mbj@tail-f.com Fri Dec 2 04:38:11 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3F821F9856 for ; Fri, 2 Dec 2011 04:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPwZ9Fkr2QpY for ; Fri, 2 Dec 2011 04:38:11 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 180E621F9849 for ; Fri, 2 Dec 2011 04:38:11 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 3460112008D2; Fri, 2 Dec 2011 13:38:06 +0100 (CET) Date: Fri, 02 Dec 2011 13:38:04 +0100 (CET) Message-Id: <20111202.133804.503088292.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <3BE63DC3-1EB4-40CC-B390-DE030F4B142D@cesnet.cz> References: <87borvcb3n.fsf@cesnet.cz> <20111202.125814.455123188.mbj@tail-f.com> <3BE63DC3-1EB4-40CC-B390-DE030F4B142D@cesnet.cz> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 12:38:11 -0000 Ladislav Lhotka wrote: > > On Dec 2, 2011, at 12:58 PM, Martin Bjorklund wrote: > > Can an interface be pointed to by more than one router? > > JUNOS implementation of logical routers doesn't allow this but in general I can > imagine a different logic where this might be allowed, for example if one > logical router is for IPv4 and another for IPv6. What happens if two routers points to the same interface, and they have different RA configs? > So my plan is not to have this > constraint in the module, and leave it to implementations to specify additional > business rules if necessary. I think it should also be up to data models to specify additional constraints. Hmm, maybe this is just too obvious. /martin From lhotka@cesnet.cz Fri Dec 2 08:04:29 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EFB21F8B3A for ; Fri, 2 Dec 2011 08:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XdD3nAQNXOr for ; Fri, 2 Dec 2011 08:04:29 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 205C021F8B1F for ; Fri, 2 Dec 2011 08:04:29 -0800 (PST) Received: from dhcp-73-142.eduroam.muni.cz (dhcp-73-142.eduroam.muni.cz [147.251.73.142]) by office2.cesnet.cz (Postfix) with ESMTPSA id CC3F92CDE058 for ; Fri, 2 Dec 2011 17:04:27 +0100 (CET) From: Ladislav Lhotka Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_2FDCDB2D-D177-4106-99AE-1E89432A6A05"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 2 Dec 2011 17:04:27 +0100 In-Reply-To: <20111202.133804.503088292.mbj@tail-f.com> To: netmod@ietf.org References: <87borvcb3n.fsf@cesnet.cz> <20111202.125814.455123188.mbj@tail-f.com> <3BE63DC3-1EB4-40CC-B390-DE030F4B142D@cesnet.cz> <20111202.133804.503088292.mbj@tail-f.com> Message-Id: <0ED055C3-BB41-4A5F-9635-484CA68A9DF8@cesnet.cz> X-Mailer: Apple Mail (2.1251.1) Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 16:04:30 -0000 --Apple-Mail=_2FDCDB2D-D177-4106-99AE-1E89432A6A05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 2, 2011, at 1:38 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Dec 2, 2011, at 12:58 PM, Martin Bjorklund wrote: >>> Can an interface be pointed to by more than one router? >>=20 >> JUNOS implementation of logical routers doesn't allow this but in = general I can >> imagine a different logic where this might be allowed, for example if = one >> logical router is for IPv4 and another for IPv6. >=20 > What happens if two routers points to the same interface, and they > have different RA configs? IMO, this situation must not happen, and cannot happen both in JUNOS and = in my hypothetical scenario. >=20 >> So my plan is not to have this >> constraint in the module, and leave it to implementations to specify = additional >> business rules if necessary. >=20 > I think it should also be up to data models to specify additional > constraints. Hmm, maybe this is just too obvious. Do you mean the core routing data models or vendor-specific models = derived from them? Lada >=20 >=20 > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_2FDCDB2D-D177-4106-99AE-1E89432A6A05 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMjAyMTYwNDI4WjAjBgkqhkiG9w0BCQQxFgQU588hTPQ5pzOW6FLL1qXmnpP2OnIwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQChbgRy+Qe+rp6mRWrfuRdDPFnT Cf1wwQsdOlNOmiD3bplQGbRbGmypvgabb39YGTnWb0gxoGIyEqBWO/lUJZc/8mAOzHOJWVNJWtAz NrnHDyG7IjEwisKc5IauHS8UJK5mm+gCl3KtRdGUEeLwLUubShWkb2GDptHjoFt6nMYv25GMsrM6 15RCwVfmVKR4omnlgUhe4bpBJ84G7vpHqVJrjCNiSG6d2upPFH9EmEChIZi36wvB9eZLntMrAM2P R50w1yoi8ykPV+vyNcm8i5XhYOETt3EO2PsWCZSCCXNEoW9RC6VW806JkAv2+81izU6jP0YyyN5U FXH40RNZNeoXAAAAAAAA --Apple-Mail=_2FDCDB2D-D177-4106-99AE-1E89432A6A05-- From wjhns1@hardakers.net Mon Dec 5 10:16:05 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9E321F8C7E for ; Mon, 5 Dec 2011 10:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZxKHURc3UR7 for ; Mon, 5 Dec 2011 10:16:04 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id BEA3621F8C7C for ; Mon, 5 Dec 2011 10:16:04 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id D867E94; Mon, 5 Dec 2011 10:15:33 -0800 (PST) From: Wes Hardaker To: David Kessens References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> Date: Mon, 05 Dec 2011 10:15:32 -0800 In-Reply-To: <20111118054853.GA29390@elstar.local> (Juergen Schoenwaelder's message of "Fri, 18 Nov 2011 06:48:55 +0100") Message-ID: <0lty5e51h7.fsf@wjh.hardakers.net> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 18:16:05 -0000 >>>>> On Fri, 18 Nov 2011 06:48:55 +0100, Juergen Schoenwaelder said: JS> 5. Data model for configuring SNMP engines. The model must be capable JS> of representing all SNMP engine configurations possible with the JS> standard SNMPv3 MIB modules that are common operational practice. I don't think "common operational practice" can be put in there safely. Simply put, the IETF has had a miserable time collecting "what is common" and I don't think anyone in the IETF has a good clue about what is operationally deployed. I know that the questions I get on our mailing lists go far and above what is talked about within the IETF as "deployed", and I've heard similar statements by folks from SNMP Research as well. I'd drop everything after "modules". Or replace it with "that are implementable easily using yang". IE, the whole point of the previous text was to exclude the requirement to model aspects of the existing SNMP configuration components that would be a pain under yang (Note: I'm not blaming yang here; they're simply different and neither modeling language is at fault). Instead, just state that: some elements of the MIB modules may not be implementable in yang, so we won't. But we'll document anything that doesn't match properly. -- Wes Hardaker SPARTA, Inc. From j.schoenwaelder@jacobs-university.de Mon Dec 5 10:29:49 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D169C21F8C75 for ; Mon, 5 Dec 2011 10:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.079 X-Spam-Level: X-Spam-Status: No, score=-103.079 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muhf89oz1nwx for ; Mon, 5 Dec 2011 10:29:49 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCFD21F8C73 for ; Mon, 5 Dec 2011 10:29:49 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0913C20C63; Mon, 5 Dec 2011 19:29:48 +0100 (CET) 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 ZTroOHJgaSSm; Mon, 5 Dec 2011 19:29:47 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B4FDE20C5E; Mon, 5 Dec 2011 19:29:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EDF5D1C0693A; Mon, 5 Dec 2011 19:29:27 +0100 (CET) Date: Mon, 5 Dec 2011 19:29:27 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20111205182927.GA77176@elstar.local> Mail-Followup-To: Wes Hardaker , David Kessens , netmod@ietf.org References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> <0lty5e51h7.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0lty5e51h7.fsf@wjh.hardakers.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 05 Dec 2011 18:29:49 -0000 On Mon, Dec 05, 2011 at 10:15:32AM -0800, Wes Hardaker wrote: > >>>>> On Fri, 18 Nov 2011 06:48:55 +0100, Juergen Schoenwaelder said: > > JS> 5. Data model for configuring SNMP engines. The model must be capable > JS> of representing all SNMP engine configurations possible with the > JS> standard SNMPv3 MIB modules that are common operational practice. > [...] IE, the whole point of the previous text was to exclude the > requirement to model aspects of the existing SNMP configuration > components that would be a pain under yang (Note: I'm not blaming > yang here; they're simply different and neither modeling language is > at fault). Instead, just state that: some elements of the MIB > modules may not be implementable in yang, so we won't. But we'll > document anything that doesn't match properly. I am sorry Wes, but I believe this is pretty much off as far as I understand the discussion. I am not aware of any YANG limitation that affects this charter text - please let me know what I might have missed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Mon Dec 5 12:05:07 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F9021F8B3A for ; Mon, 5 Dec 2011 12:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9POx4R+1rqG for ; Mon, 5 Dec 2011 12:05:06 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id AB3C121F8B31 for ; Mon, 5 Dec 2011 12:05:06 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 78422118; Mon, 5 Dec 2011 12:04:34 -0800 (PST) From: Wes Hardaker To: Wes Hardaker References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> <0lty5e51h7.fsf@wjh.hardakers.net> <20111205182927.GA77176@elstar.local> Date: Mon, 05 Dec 2011 12:04:33 -0800 In-Reply-To: <20111205182927.GA77176@elstar.local> (Juergen Schoenwaelder's message of "Mon, 5 Dec 2011 19:29:27 +0100") Message-ID: <0lehwig4z2.fsf@wjh.hardakers.net> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 20:05:07 -0000 >>>>> On Mon, 5 Dec 2011 19:29:27 +0100, Juergen Schoenwaelder said: JS> 5. Data model for configuring SNMP engines. The model must be capable JS> of representing all SNMP engine configurations possible with the JS> standard SNMPv3 MIB modules that are common operational practice. >> [...] IE, the whole point of the previous text was to exclude the >> requirement to model aspects of the existing SNMP configuration >> components that would be a pain under yang (Note: I'm not blaming >> yang here; they're simply different and neither modeling language is >> at fault). Instead, just state that: some elements of the MIB >> modules may not be implementable in yang, so we won't. But we'll >> document anything that doesn't match properly. JS> I am sorry Wes, but I believe this is pretty much off as far as I JS> understand the discussion. I am not aware of any YANG limitation that JS> affects this charter text - please let me know what I might have JS> missed. What's the point of "that are common operational practice" mean? Why is it in there? -- Wes Hardaker SPARTA, Inc. From j.schoenwaelder@jacobs-university.de Mon Dec 5 13:12:38 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E791F0C87 for ; Mon, 5 Dec 2011 13:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.096 X-Spam-Level: X-Spam-Status: No, score=-103.096 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAqDGN9zaZbv for ; Mon, 5 Dec 2011 13:12:38 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D53001F0C7A for ; Mon, 5 Dec 2011 13:12:37 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 316E420C76; Mon, 5 Dec 2011 22:12:37 +0100 (CET) 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 wShVj2xlnfRX; Mon, 5 Dec 2011 22:12:36 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF14520C65; Mon, 5 Dec 2011 22:12:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5ABEE1C06ACE; Mon, 5 Dec 2011 22:12:17 +0100 (CET) Date: Mon, 5 Dec 2011 22:12:16 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20111205211216.GA77356@elstar.local> Mail-Followup-To: Wes Hardaker , netmod@ietf.org References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> <0lty5e51h7.fsf@wjh.hardakers.net> <20111205182927.GA77176@elstar.local> <0lehwig4z2.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0lehwig4z2.fsf@wjh.hardakers.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 05 Dec 2011 21:12:39 -0000 On Mon, Dec 05, 2011 at 12:04:33PM -0800, Wes Hardaker wrote: > >>>>> On Mon, 5 Dec 2011 19:29:27 +0100, Juergen Schoenwaelder said: > > JS> 5. Data model for configuring SNMP engines. The model must be capable > JS> of representing all SNMP engine configurations possible with the > JS> standard SNMPv3 MIB modules that are common operational practice. > > >> [...] IE, the whole point of the previous text was to exclude the > >> requirement to model aspects of the existing SNMP configuration > >> components that would be a pain under yang (Note: I'm not blaming > >> yang here; they're simply different and neither modeling language is > >> at fault). Instead, just state that: some elements of the MIB > >> modules may not be implementable in yang, so we won't. But we'll > >> document anything that doesn't match properly. > > JS> I am sorry Wes, but I believe this is pretty much off as far as I > JS> understand the discussion. I am not aware of any YANG limitation that > JS> affects this charter text - please let me know what I might have > JS> missed. > > What's the point of "that are common operational practice" mean? Why is > it in there? Instead of repeating the discussion, I suggest you read the mailing list archive to understand how we got where we are. Do you object the proposed charter text? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Mon Dec 5 20:32:05 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2B71F0C77 for ; Mon, 5 Dec 2011 20:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5musN8DtLXAN for ; Mon, 5 Dec 2011 20:32:05 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id DDCBD1F0C3B for ; Mon, 5 Dec 2011 20:32:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=kaLDb/D6f19xac1GB3wZwHX62buwjAzbD3o5grD93pMfbh18lMeLdqiXA6ucNXsB; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.52.166] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RXmhH-00007Q-OW for netmod@ietf.org; Mon, 05 Dec 2011 23:32:04 -0500 Message-ID: <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20111115035743.GF2731@nsn.com><20111118054853.GA29390@elstar.local><0lty5e51h7.fsf@wjh.hardakers.net> <20111205182927.GA77176@elstar.local> Date: Mon, 5 Dec 2011 20:33:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0fe8fc0381718d895304c35825f833eb9f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.52.166 Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 04:32:06 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Wes Hardaker" > Cc: > Sent: Monday, December 05, 2011 10:29 AM > Subject: Re: [netmod] Snmp configuration charter addition > > On Mon, Dec 05, 2011 at 10:15:32AM -0800, Wes Hardaker wrote: > > >>>>> On Fri, 18 Nov 2011 06:48:55 +0100, Juergen Schoenwaelder said: > > > > JS> 5. Data model for configuring SNMP engines. The model must be capable > > JS> of representing all SNMP engine configurations possible with the > > JS> standard SNMPv3 MIB modules that are common operational practice. > > > [...] IE, the whole point of the previous text was to exclude the > > requirement to model aspects of the existing SNMP configuration > > components that would be a pain under yang (Note: I'm not blaming > > yang here; they're simply different and neither modeling language is > > at fault). Instead, just state that: some elements of the MIB > > modules may not be implementable in yang, so we won't. But we'll > > document anything that doesn't match properly. > > I am sorry Wes, but I believe this is pretty much off as far as I > understand the discussion. I am not aware of any YANG limitation that > affects this charter text - please let me know what I might have > missed. I think Wes has a valid point. It's a perfectly reasonable requirement for the YANG models for configuring SNMP engines to be faithful to the corresponding MIB models, and to permit deviation only in cases where YANG cannot match the semantics, or can only do so with great difficulty. If there are no such cases, that would be a good thing. What has been argued on this list, however, is a desire to "improve" the models by eliminating possible configurations that from some point of view are either not useful or "meaningful". The text currently under discussion was an attempt to avoid the situation made manifest in the I-D, where perfectly reasonable and operationally useful MIB configurations were explicitly prohibited by the YANG model. The thrust of Wes' argument is that the WG would be skating on very thin ice. As he wrote: | I don't think "common operational practice" can be put in there safely. | Simply put, the IETF has had a miserable time collecting "what is | common" and I don't think anyone in the IETF has a good clue about what | is operationally deployed. Though I'm no longer "in the business", Wes' comment certainly seemed to apply when I was, and I don't see how things have changed in any way that would increase the IETF's chances of getting things right if the YANG models modified the constraints on what were "valid" configurations. I'm still convinced that to be useful as a configuration management tool, it needs to be able to back up and restore the any configuration from the set of configurations that could possibly have been put into effect in the SNMP engine in question via the MIB interface. I can live with the proposed language, but only because I'm not in the business any more and don't care as much about the potential for disaster, and think that at least some of the people who are active in the WG recognize the hubris in that language and will be willing to go out into deployments and verify that the things that end up being disallowed are in fact not used by any products in the field. Randy From j.schoenwaelder@jacobs-university.de Mon Dec 5 23:40:39 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A1F21F8ABD for ; Mon, 5 Dec 2011 23:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.11 X-Spam-Level: X-Spam-Status: No, score=-103.11 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cT4JMndXM976 for ; Mon, 5 Dec 2011 23:40:38 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BAFF221F8AA9 for ; Mon, 5 Dec 2011 23:40:38 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B78FA20C3B; Tue, 6 Dec 2011 08:40:37 +0100 (CET) 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 DwrAGOpECaos; Tue, 6 Dec 2011 08:40:36 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BAFB20C37; Tue, 6 Dec 2011 08:40:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 71AB81C06E37; Tue, 6 Dec 2011 08:40:18 +0100 (CET) Date: Tue, 6 Dec 2011 08:40:18 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20111206074018.GA78060@elstar.local> Mail-Followup-To: Randy Presuhn , netmod@ietf.org References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> <0lty5e51h7.fsf@wjh.hardakers.net> <20111205182927.GA77176@elstar.local> <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 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 Dec 2011 07:40:39 -0000 On Mon, Dec 05, 2011 at 08:33:49PM -0800, Randy Presuhn wrote: > I think Wes has a valid point. It's a perfectly reasonable requirement for > the YANG models for configuring SNMP engines to be faithful to the > corresponding MIB models, and to permit deviation only in cases where > YANG cannot match the semantics, or can only do so with great difficulty. > If there are no such cases, that would be a good thing. There is no YANG problem I am aware of. Can someone please explain this to me? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.org Tue Dec 6 01:49:25 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8909721F8B36 for ; Tue, 6 Dec 2011 01:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iq9rs95xdDon for ; Tue, 6 Dec 2011 01:49:25 -0800 (PST) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id E942921F8B14 for ; Tue, 6 Dec 2011 01:49:24 -0800 (PST) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pB69nLeO015284 for ; Tue, 6 Dec 2011 04:49:23 -0500 Authentication-Results: cm-omr14 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:56232] helo=[192.168.0.126]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 99/A8-24418-125EDDE4; Tue, 06 Dec 2011 04:49:21 -0500 Message-ID: <4EDDE520.1060708@netconfcentral.org> Date: Tue, 06 Dec 2011 01:49:20 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Randy Presuhn , netmod@ietf.org References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> <0lty5e51h7.fsf@wjh.hardakers.net> <20111205182927.GA77176@elstar.local> <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> <20111206074018.GA78060@elstar.local> In-Reply-To: <20111206074018.GA78060@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 09:49:25 -0000 On 12/05/2011 11:40 PM, Juergen Schoenwaelder wrote: > On Mon, Dec 05, 2011 at 08:33:49PM -0800, Randy Presuhn wrote: > >> I think Wes has a valid point. It's a perfectly reasonable requirement for >> the YANG models for configuring SNMP engines to be faithful to the >> corresponding MIB models, and to permit deviation only in cases where >> YANG cannot match the semantics, or can only do so with great difficulty. >> If there are no such cases, that would be a good thing. > There is no YANG problem I am aware of. Can someone please explain > this to me? Can someone explain to me why this level of detail is holding up a charter discussion? Can somebody explain why the normal process of vendors looking out for their own requirement to meet customer needs will not produce an adequate solution? If the solution is deficient, a vendor will say "we need knob X because we have customers that use feature Y". > /js > Andy From wjhns1@hardakers.net Tue Dec 6 08:08:34 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA78521F8511 for ; Tue, 6 Dec 2011 08:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-C6-9faM1qf for ; Tue, 6 Dec 2011 08:08:33 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF5B21F84FD for ; Tue, 6 Dec 2011 08:08:33 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id A520334B; Tue, 6 Dec 2011 08:08:02 -0800 (PST) From: Wes Hardaker To: Wes Hardaker References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> <0lty5e51h7.fsf@wjh.hardakers.net> <20111205182927.GA77176@elstar.local> <0lehwig4z2.fsf@wjh.hardakers.net> <20111205211216.GA77356@elstar.local> Date: Tue, 06 Dec 2011 08:08:00 -0800 In-Reply-To: <20111205211216.GA77356@elstar.local> (Juergen Schoenwaelder's message of "Mon, 5 Dec 2011 22:12:16 +0100") Message-ID: <0lliqpel9b.fsf@wjh.hardakers.net> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 16:08:34 -0000 >>>>> On Mon, 5 Dec 2011 22:12:16 +0100, Juergen Schoenwaelder said: JS> Instead of repeating the discussion, I suggest you read the mailing JS> list archive to understand how we got where we are. JS> Do you object the proposed charter text? I do, because I think its too subjective and unneeded in the first place. -- Wes Hardaker SPARTA, Inc. From spakes@snmp.com Tue Dec 6 08:45:27 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160D121F8BB6 for ; Tue, 6 Dec 2011 08:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTh6FU-rgacq for ; Tue, 6 Dec 2011 08:45:26 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id DC96E21F861E for ; Tue, 6 Dec 2011 08:45:25 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA22677; Tue, 6 Dec 2011 11:45:20 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA25034; Tue, 6 Dec 2011 11:45:11 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Tue, 6 Dec 2011 11:45:10 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder , Andy Bierman In-Reply-To: <4EDDE520.1060708@netconfcentral.org> Message-ID: References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> <0lty5e51h7.fsf@wjh.hardakers.net> <20111205182927.GA77176@elstar.local> <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> <20111206074018.GA78060@elstar.local> <4EDDE520.1060708@netconfcentral.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 16:45:27 -0000 The charter determines the guidelines and boundaries for the concept development. I believe Wes isn't talking about low-level knobs and switches but about the philosophy of the design. I believe Randy correctly identifies the two general directions that this group could take: 1. The YANG module(s) could preserve the structure of the USM/VACM MIB modules. In brief, the MIB modules define several tables that have flexible linkage between them. One table can refer to a single row in another table by specifying its index. Or, one table can refer to multiple rows in another table using tags and tag lists. This design is "second generation" because the designers applied lessons learned from an earlier model (party-party-context, RFC 1441-1447). 2. The YANG module could restructure the MIB tables to try to "improve" them. For example, one might consider it an improvement to use nested tables since YANG supports having a list inside another list. One might argue that a user must always be a member of a group so the list of users should belong inside the list of groups. This takes us in the direction of rigid linkage between the tables, reminiscent of party-party-context. The flexible linkage provided by the current MIB modules has practical and intentional purposes. I mentioned in an earlier post that "common operational practice" includes configuring USM users that are not connected to any VACM group. These are used as templates for creating other USM users without passing the new user's credentials across the network. These users represent shared secrets that are required to make remote administration of SNMPv3 highly secure. The flexible linkage provided by the current MIB modules has also allowed vendors to implement features that go beyond the original scope of USM/VACM. It is arguable that the YANG document need not be concerned with this case. JS> 5. Data model for configuring SNMP engines. The model must be capable JS> of representing all SNMP engine configurations possible with the JS> standard SNMPv3 MIB modules that are common operational practice. If the above statement stops after "the standard SNMPv3 MIB modules", it takes us in the direction #1 above (flexible linkage). If the above statement includes the phrase "that are common operational practice", it takes us in direction #2 above (rigid linkage). -dss On Tue, 6 Dec 2011, Andy Bierman wrote: > Can someone explain to me why this level of detail is holding up a > charter discussion? Can somebody explain why the normal process of > vendors looking out for their own requirement to meet customer needs > will not produce an adequate solution? If the solution is deficient, a > vendor will say "we need knob X because we have customers that use > feature Y". On Tue, 6 Dec 2011, Juergen Schoenwaelder wrote: > There is no YANG problem I am aware of. Can someone please explain > this to me? > > /js On Mon, 5 Dec 2011, Randy Presuhn wrote: > I think Wes has a valid point. It's a perfectly reasonable requirement for > the YANG models for configuring SNMP engines to be faithful to the > corresponding MIB models, and to permit deviation only in cases where > YANG cannot match the semantics, or can only do so with great difficulty. > If there are no such cases, that would be a good thing. > > What has been argued on this list, however, is a desire to "improve" the > models by eliminating possible configurations that from some point > of view are either not useful or "meaningful". The text currently under > discussion was an attempt to avoid the situation made manifest in the > I-D, where perfectly reasonable and operationally useful MIB > configurations were explicitly prohibited by the YANG model. On Mon, 5 Dec 2011, Wes Hardaker wrote: > I don't think "common operational practice" can be put in there safely. > Simply put, the IETF has had a miserable time collecting "what is > common" and I don't think anyone in the IETF has a good clue about what > is operationally deployed ... Instead, just state that: some elements > of the MIB modules may not be implementable in yang, so we won't. But > we'll document anything that doesn't match properly. ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From andy@netconfcentral.org Tue Dec 6 09:26:14 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF30F21F8BC5 for ; Tue, 6 Dec 2011 09:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+SUqMGDvUIo for ; Tue, 6 Dec 2011 09:26:14 -0800 (PST) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id 1043421F8BBE for ; Tue, 6 Dec 2011 09:26:11 -0800 (PST) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pB6HQ9TL016935 for ; Tue, 6 Dec 2011 12:26:11 -0500 Authentication-Results: cm-omr7 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:49551] helo=[192.168.0.126]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 3A/62-22041-0305EDE4; Tue, 06 Dec 2011 12:26:09 -0500 Message-ID: <4EDE5030.1040303@netconfcentral.org> Date: Tue, 06 Dec 2011 09:26:08 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David Spakes References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> <0lty5e51h7.fsf@wjh.hardakers.net> <20111205182927.GA77176@elstar.local> <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> <20111206074018.GA78060@elstar.local> <4EDDE520.1060708@netconfcentral.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 17:26:14 -0000 On 12/06/2011 08:45 AM, David Spakes wrote: > The charter determines the guidelines and boundaries for the concept > development. I believe Wes isn't talking about low-level knobs and > switches but about the philosophy of the design. I believe Randy > correctly identifies the two general directions that this group could > take: OK -- I see your point. > > 1. The YANG module(s) could preserve the structure of the USM/VACM MIB > modules. In brief, the MIB modules define several tables that have > flexible linkage between them. One table can refer to a single row in > another table by specifying its index. Or, one table can refer to > multiple rows in another table using tags and tag lists. This design > is "second generation" because the designers applied lessons learned > from an earlier model (party-party-context, RFC 1441-1447). If you want this approach, then run "smilint -f yang" (or your implementation of smi2yang) on the desired MIB modules. It would be a good test of the conversion algorithms. IMO, this is good enough and there is no point wasting WG resources to hand-convert SMIv2 modules. > 2. The YANG module could restructure the MIB tables to try to "improve" > them. For example, one might consider it an improvement to use nested > tables since YANG supports having a list inside another list. One might > argue that a user must always be a member of a group so the list of users > should belong inside the list of groups. This takes us in the direction > of rigid linkage between the tables, reminiscent of party-party-context. > I doubt that many vendors want to spend lots of IETF resources refining YANG data models for corner-case configurations they don't even support in their CLI. I thought the point of redoing these data models in YANG was to standardize the common bits of what vendors support in their products. YANG should be used full-strength, if the IETF is going to bother working on data models at all. > The flexible linkage provided by the current MIB modules has practical > and intentional purposes. I mentioned in an earlier post that "common > operational practice" includes configuring USM users that are not > connected to any VACM group. These are used as templates for creating > other USM users without passing the new user's credentials across the > network. These users represent shared secrets that are required to > make remote administration of SNMPv3 highly secure. > > The flexible linkage provided by the current MIB modules has also allowed > vendors to implement features that go beyond the original scope of > USM/VACM. It is arguable that the YANG document need not be concerned > with this case. If enough people support the feature, it should be in scope. Andy From j.schoenwaelder@jacobs-university.de Tue Dec 6 09:30:41 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E0F21F8BD3 for ; Tue, 6 Dec 2011 09:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.122 X-Spam-Level: X-Spam-Status: No, score=-103.122 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-OQhpmWhyeg for ; Tue, 6 Dec 2011 09:30:40 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B7E7821F8BC5 for ; Tue, 6 Dec 2011 09:30:40 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B236320C67; Tue, 6 Dec 2011 18:30:39 +0100 (CET) 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 1CKdmyCX9pG5; Tue, 6 Dec 2011 18:30:38 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3457320C65; Tue, 6 Dec 2011 18:30:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3CA641C081D2; Tue, 6 Dec 2011 18:30:19 +0100 (CET) Date: Tue, 6 Dec 2011 18:30:18 +0100 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20111206173018.GC81469@elstar.local> Mail-Followup-To: David Spakes , Andy Bierman , Randy Presuhn , netmod@ietf.org References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> <0lty5e51h7.fsf@wjh.hardakers.net> <20111205182927.GA77176@elstar.local> <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> <20111206074018.GA78060@elstar.local> <4EDDE520.1060708@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 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 Dec 2011 17:30:41 -0000 On Tue, Dec 06, 2011 at 11:45:10AM -0500, David Spakes wrote: > 2. The YANG module could restructure the MIB tables to try to "improve" > them. For example, one might consider it an improvement to use nested > tables since YANG supports having a list inside another list. One might > argue that a user must always be a member of a group so the list of users > should belong inside the list of groups. This takes us in the direction > of rigid linkage between the tables, reminiscent of party-party-context. As far as I understand, this is not something Martin's I-D actually does. You can have USM users that are not a member of any VACM groups and you can have VACM group members that do not exist anywhere as security names. I meanwhile believe we would be much better off if we all would be investing our energy on improving the I-D rather than having abstract charter discussions. My understanding is that Martin will lift the current leaf-ref restriction that requires that views exist and which got the whole discussion started. If there is anything else that needs changes, please let Martin / the WG know. /js (writing as a puzzled contributor) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.org Tue Dec 6 12:29:09 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F7721F8B27 for ; Tue, 6 Dec 2011 12:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ulufkdQJdfF for ; Tue, 6 Dec 2011 12:29:09 -0800 (PST) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id CCD5321F8B12 for ; Tue, 6 Dec 2011 12:29:08 -0800 (PST) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pB6KT5Fd017202 for ; Tue, 6 Dec 2011 15:29:08 -0500 Authentication-Results: cm-omr10 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:36292] helo=[192.168.0.126]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id AE/51-17214-11B7EDE4; Tue, 06 Dec 2011 15:29:05 -0500 Message-ID: <4EDE7B11.2050002@netconfcentral.org> Date: Tue, 06 Dec 2011 12:29:05 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David Spakes , Randy Presuhn , netmod@ietf.org References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> <0lty5e51h7.fsf@wjh.hardakers.net> <20111205182927.GA77176@elstar.local> <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> <20111206074018.GA78060@elstar.local> <4EDDE520.1060708@netconfcentral.org> <20111206173018.GC81469@elstar.local> In-Reply-To: <20111206173018.GC81469@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 20:29:09 -0000 On 12/06/2011 09:30 AM, Juergen Schoenwaelder wrote: > On Tue, Dec 06, 2011 at 11:45:10AM -0500, David Spakes wrote: > >> 2. The YANG module could restructure the MIB tables to try to "improve" >> them. For example, one might consider it an improvement to use nested >> tables since YANG supports having a list inside another list. One might >> argue that a user must always be a member of a group so the list of users >> should belong inside the list of groups. This takes us in the direction >> of rigid linkage between the tables, reminiscent of party-party-context. > As far as I understand, this is not something Martin's I-D actually > does. You can have USM users that are not a member of any VACM groups > and you can have VACM group members that do not exist anywhere as > security names. > > I meanwhile believe we would be much better off if we all would be > investing our energy on improving the I-D rather than having abstract > charter discussions. My understanding is that Martin will lift the > current leaf-ref restriction that requires that views exist and which > got the whole discussion started. If there is anything else that needs > changes, please let Martin / the WG know. OK -- so this is the source of all the debate: 5. Data model for configuring SNMP engines. The model must be capable of representing all meaningful SNMP engine configurations possible with the standard SNMPv3 MIB modules. Any differences in functionality and behavior should be documented. This text is flawed because 'must' in sentence 2 does not leave room for the WG to make judgments wrt/ cost/benefit per feature, etc. Change 'must' to 'should' and the text is fine. I don't see how this text in any way provides guidance for the specific YANG module constructs used in the solution (which is correct). It seems you guys have been debating solutions this whole time, not charter text. IMO, 'meaningful' in the text above implies "configurations used in common deployments", because our goal is to do common things in a common way. > /js (writing as a puzzled contributor) > Andy From randy_presuhn@mindspring.com Tue Dec 6 13:02:37 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A6C1F0C58 for ; Tue, 6 Dec 2011 13:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oj7xAYHqDl7a for ; Tue, 6 Dec 2011 13:02:36 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id AED701F0C53 for ; Tue, 6 Dec 2011 13:02:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=mY5qIseKoHg8F5aStNWl+4sRuKCiwsl4StHQxxf4PB6MM/8KVKhyHI/mwqxBLR8V; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.38.144.9] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RY29p-0002J8-8q for netmod@ietf.org; Tue, 06 Dec 2011 16:02:33 -0500 Message-ID: <003b01ccb45a$a10de340$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> <0lty5e51h7.fsf@wjh.hardakers.net> <20111205182927.GA77176@elstar.local> <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> <20111206074018.GA78060@elstar.local> <4EDDE520.1060708@netconfcentral.org> <20111206173018.GC81469@elstar.local> <4EDE7B11.2050002@netconfcentral.org> Date: Tue, 6 Dec 2011 13:04:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0f7b48d9f010aefa0e6511b3d72ff7fa3e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.144.9 Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 21:02:37 -0000 Hi - > From: "Andy Bierman" > To: "David Spakes" ; "Randy Presuhn" ; > Sent: Tuesday, December 06, 2011 12:29 PM > Subject: Re: [netmod] Snmp configuration charter addition ... > 5. Data model for configuring SNMP engines. The model must be capable of > representing all meaningful SNMP engine configurations possible with the > standard SNMPv3 MIB modules. Any differences in functionality and > behavior should be documented. > > > This text is flawed because 'must' in sentence 2 does not leave room > for the WG to make judgments wrt/ cost/benefit per feature, etc. > Change 'must' to 'should' and the text is fine. Actually, going to "should" would take the charter in precisely the direction I find objectionable. I'd want to see *less* wiggle room, not more, but was willing to go along with the proposed compromise text just so work could get underway. > I don't see how this text in any way provides guidance for the specific YANG module > constructs used in the solution (which is correct). It seems you guys have been debating > solutions this whole time, not charter text. > > IMO, 'meaningful' in the text above implies "configurations used in common deployments", > because our goal is to do common things in a common way. I find both too loose for comfort, but having made my case, I'm willing to live with the latter. I think the difference between Wes' position and mine is how much we're willing to trust the WG to do the right thing when given the opportunity to prohibit configurations that the MIB model permits. When Juergen makes his assurances, I feel like everything will be fine. When Andy talks about changing the "must" to a "should", I fear the worst. But again, I'm willing to go along with the currently proposed text because I think I've made my misgivings sufficiently clear. Randy From spakes@snmp.com Wed Dec 7 08:29:46 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEEE21F8BCD for ; Wed, 7 Dec 2011 08:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLz6WuP0tJ6l for ; Wed, 7 Dec 2011 08:29:42 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4A921F8B6C for ; Wed, 7 Dec 2011 08:29:41 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA06649; Wed, 7 Dec 2011 11:29:27 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA24459; Wed, 7 Dec 2011 11:29:06 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Wed, 7 Dec 2011 11:29:06 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: <4EDE5030.1040303@netconfcentral.org> Message-ID: References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> <0lty5e51h7.fsf@wjh.hardakers.net> <20111205182927.GA77176@elstar.local> <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> <20111206074018.GA78060@elstar.local> <4EDDE520.1060708@netconfcentral.org> <4EDE5030.1040303@netconfcentral.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 16:29:46 -0000 On Tue, 6 Dec 2011, Andy Bierman wrote: > > 1. The YANG module(s) could preserve the structure of the USM/VACM MIB > > modules. In brief, the MIB modules define several tables that have > > flexible linkage between them. One table can refer to a single row in > > another table by specifying its index. Or, one table can refer to > > multiple rows in another table using tags and tag lists. This design > > is "second generation" because the designers applied lessons learned > > from an earlier model (party-party-context, RFC 1441-1447). > > If you want this approach, then run "smilint -f yang" (or your > implementation of smi2yang) on the desired MIB modules. It would be a > good test of the conversion algorithms. IMO, this is good enough and > there is no point wasting WG resources to hand-convert SMIv2 modules. I believe than an automatic conversion of these MIB modules to YANG would NOT work properly. There are issues that would need to be worked out that would be worthy of IETF resources. The best example is the usmUserTable. You don't configure a user's authentication and privacy keys simply by pushing them in a protocol message. Also, key values are not readable. The localized keys depend on the authSnmpEngineID value, which must be unique for each SNMP entity. A NETCONF client might expect to be able to do a on one device and an on another device to copy a configuration, and that simply would not work using an automatically-converted document. > I thought the point of redoing these data models in YANG was to > standardize the common bits of what vendors support in their products. > YANG should be used full-strength, if the IETF is going to bother > working on data models at all. That sounds like a worthy goal. However, if the output of the WG is a new-and-improved administration framework for SNMP that is implemented in exactly zero devices in the field, then it will be years before it is placed into practical use, assuming that ever happens. Another goal could be to produce YANG modules that closely follow the existing MIB modules so they could be used to manage the configuration of existing SNMPv3 engines. In the short term, this could be done through a protocol translator that follows special-case procedures outlined in the document for difficult items like the usmUserTable. In the longer term, vendors could implement native support more easily because this approach would help them to maximize code re-use. > It seems you guys have been debating solutions this whole time, not > charter text. I am fairly neutral on this decision. Either way the WG decides to go, I imagine that in the coming months I'll be working to implement it. Obviously, I can't help but think how decisions like this will affect my implementation and others. Some choices are difficult to implement, but they're good for the technology and are worth the effort. Sometimes we make choices because they sound good in principle, but in the end the result is no better than what we started with, so the effort hardly seems worth it. It's not clear to me at this point that "YANG should be used full-strenth" in this particular instance. This may be the time to be subtle--to show that YANG can model and fit existing technology without needing to reinvent it. -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From andy@netconfcentral.org Wed Dec 7 08:50:06 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720AA21F8B81 for ; Wed, 7 Dec 2011 08:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtg87TQbmB39 for ; Wed, 7 Dec 2011 08:50:05 -0800 (PST) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9743321F8B73 for ; Wed, 7 Dec 2011 08:50:05 -0800 (PST) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pB7Go0qe019105 for ; Wed, 7 Dec 2011 11:50:02 -0500 Authentication-Results: cm-omr2 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:38017] helo=[192.168.0.126]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 96/5C-29388-7399FDE4; Wed, 07 Dec 2011 11:50:00 -0500 Message-ID: <4EDF9937.90908@netconfcentral.org> Date: Wed, 07 Dec 2011 08:49:59 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David Spakes References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> <0lty5e51h7.fsf@wjh.hardakers.net> <20111205182927.GA77176@elstar.local> <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> <20111206074018.GA78060@elstar.local> <4EDDE520.1060708@netconfcentral.org> <4EDE5030.1040303@netconfcentral.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 16:50:06 -0000 On 12/07/2011 08:29 AM, David Spakes wrote: > On Tue, 6 Dec 2011, Andy Bierman wrote: > >>> 1. The YANG module(s) could preserve the structure of the USM/VACM MIB >>> modules. In brief, the MIB modules define several tables that have >>> flexible linkage between them. One table can refer to a single row in >>> another table by specifying its index. Or, one table can refer to >>> multiple rows in another table using tags and tag lists. This design >>> is "second generation" because the designers applied lessons learned >>> from an earlier model (party-party-context, RFC 1441-1447). >> If you want this approach, then run "smilint -f yang" (or your >> implementation of smi2yang) on the desired MIB modules. It would be a >> good test of the conversion algorithms. IMO, this is good enough and >> there is no point wasting WG resources to hand-convert SMIv2 modules. > I believe than an automatic conversion of these MIB modules to YANG would > NOT work properly. There are issues that would need to be worked out that > would be worthy of IETF resources. > > The best example is the usmUserTable. You don't configure a user's > authentication and privacy keys simply by pushing them in a protocol > message. Also, key values are not readable. The localized keys depend on > the authSnmpEngineID value, which must be unique for each SNMP entity. A > NETCONF client might expect to be able to do a on one device > and an on another device to copy a configuration, and that > simply would not work using an automatically-converted document. Are you saying that a description-stmt could not be written telling client developers how to use the data model? You are raising an important point about SMI2YANG. Converting data modeling languages is only part of the problem. Using the data model with NETCONF is also important. Converting 'SNMP logic' to NETCONF may require some work. But since the SMI2YANG mapping is read-only, it is not applicable to this data model. > >> I thought the point of redoing these data models in YANG was to >> standardize the common bits of what vendors support in their products. >> YANG should be used full-strength, if the IETF is going to bother >> working on data models at all. > That sounds like a worthy goal. However, if the output of the WG is a > new-and-improved administration framework for SNMP that is implemented in > exactly zero devices in the field, then it will be years before it is > placed into practical use, assuming that ever happens. > > Another goal could be to produce YANG modules that closely follow the > existing MIB modules so they could be used to manage the configuration > of existing SNMPv3 engines. In the short term, this could be done > through a protocol translator that follows special-case procedures > outlined in the document for difficult items like the usmUserTable. > In the longer term, vendors could implement native support more easily > because this approach would help them to maximize code re-use. > > >> It seems you guys have been debating solutions this whole time, not >> charter text. > I am fairly neutral on this decision. Either way the WG decides to go, > I imagine that in the coming months I'll be working to implement it. > Obviously, I can't help but think how decisions like this will affect > my implementation and others. Some choices are difficult to implement, > but they're good for the technology and are worth the effort. Sometimes > we make choices because they sound good in principle, but in the end the > result is no better than what we started with, so the effort hardly seems > worth it. It's not clear to me at this point that "YANG should be used > full-strenth" in this particular instance. This may be the time to > be subtle--to show that YANG can model and fit existing technology > without needing to reinvent it. I think you will find that people without any direct business case for working on this data model are going to mostly ignore it. IMO, there are plenty of experts working on it (so it will get adequate review), but I don't expect many people will care about theoretical completeness. > > -dss Andy From spakes@snmp.com Wed Dec 7 11:30:21 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B3C11E80A5 for ; Wed, 7 Dec 2011 11:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWgMntcHK-0H for ; Wed, 7 Dec 2011 11:30:19 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 867ED11E8094 for ; Wed, 7 Dec 2011 11:30:11 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA19215; Wed, 7 Dec 2011 14:30:06 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id OAA28221; Wed, 7 Dec 2011 14:29:57 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Wed, 7 Dec 2011 14:29:57 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Andy Bierman In-Reply-To: <4EDF9937.90908@netconfcentral.org> Message-ID: References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> <0lty5e51h7.fsf@wjh.hardakers.net> <20111205182927.GA77176@elstar.local> <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> <20111206074018.GA78060@elstar.local> <4EDDE520.1060708@netconfcentral.org> <4EDE5030.1040303@netconfcentral.org> <4EDF9937.90908@netconfcentral.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 19:30:21 -0000 On Wed, 7 Dec 2011, Andy Bierman wrote: > >>> 1. The YANG module(s) could preserve the structure of the USM/VACM MIB > >>> modules. In brief, the MIB modules define several tables that have > >>> flexible linkage between them. One table can refer to a single row in > >>> another table by specifying its index. Or, one table can refer to > >>> multiple rows in another table using tags and tag lists. This design > >>> is "second generation" because the designers applied lessons learned > >>> from an earlier model (party-party-context, RFC 1441-1447). > >> If you want this approach, then run "smilint -f yang" (or your > >> implementation of smi2yang) on the desired MIB modules. It would be a > >> good test of the conversion algorithms. IMO, this is good enough and > >> there is no point wasting WG resources to hand-convert SMIv2 modules. > > I believe than an automatic conversion of these MIB modules to YANG would > > NOT work properly. There are issues that would need to be worked out that > > would be worthy of IETF resources. > > > > The best example is the usmUserTable. You don't configure a user's > > authentication and privacy keys simply by pushing them in a protocol > > message. Also, key values are not readable. The localized keys depend on > > the authSnmpEngineID value, which must be unique for each SNMP entity. A > > NETCONF client might expect to be able to do a on one device > > and an on another device to copy a configuration, and that > > simply would not work using an automatically-converted document. > > Are you saying that a description-stmt could not be written telling > client developers how to use the data model? You are raising an > important point about SMI2YANG. Converting data modeling languages is > only part of the problem. Using the data model with NETCONF is also > important. Converting 'SNMP logic' to NETCONF may require some work. > > But since the SMI2YANG mapping is read-only, it is not applicable to > this data model. The USM/VACM MIB modules were specifically created to support SNMP configuration. There is not much value in polling for these objects. Their usefulness comes from being able to create and delete rows and to modify the values. One could use the SMI2YANG mapping to create a read-only YANG module, but what would be the point? Hence, we are discussing the charter for a WG to design the data model that would allow NETCONF to be able to perform SNMP configuration. That data model could be very different, moderately different, somewhat similar, or very similar to the existing data model defined in SMIv2. There's nothing to prevent this WG from choosing to create a YANG module that is identical to the SMI2YANG mapping but with the following changes: - read-write and read-create objects are config true, not config false - as deemed necessary, make a NETCONF-saavy tweak the to usmUserTable - as deemed appropriate, since NETCONF has its own mechanism to create and delete rows, do not include RowStatus objects in the YANG module, or convert these objects as config false - some cosmetic changes as desired, such as converting SnmpTagList (space-separated words in a string) to a leaf-list > I think you will find that people without any direct business case for > working on this data model are going to mostly ignore it. IMO, there > are plenty of experts working on it (so it will get adequate review), > but I don't expect many people will care about theoretical completeness. I am a very practical person. My concept of completeness here is that an operator is able to switch back-and-forth from using an SNMP-based configuration tool and a NETCONF-based configuration tool. Changes made to the configuration of an SNMP entity by one tool show up nice and neat in dashboard of the other tool and vice-versa. -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From randy_presuhn@mindspring.com Wed Dec 7 11:51:47 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BE621F86EC for ; Wed, 7 Dec 2011 11:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.346 X-Spam-Level: X-Spam-Status: No, score=-101.346 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WN2CNVMgWG+Z for ; Wed, 7 Dec 2011 11:51:47 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 521051F0C35 for ; Wed, 7 Dec 2011 11:51:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=NFWtSI8FPVq+92Qgzwr1xDOXSwnD6ujgpyxPNsftRV6f/fst2oHaOqq4xXtzQkv+; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.53.231] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RYNWs-00005D-Cm for netmod@ietf.org; Wed, 07 Dec 2011 14:51:46 -0500 Message-ID: <000601ccb519$eb00a680$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> <0lty5e51h7.fsf@wjh.hardakers.net> <20111205182927.GA77176@elstar.local> <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> <20111206074018.GA78060@elstar.local> <4EDDE520.1060708@netconfcentral.org> <4EDE5030.1040303@netconfcentral.org> <4EDF9937.90908@netconfcentral.org> Date: Wed, 7 Dec 2011 11:53:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0fa4210238e3e7b37dcdcfa98ac350b77d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.53.231 Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 19:51:48 -0000 Hi - > From: "David Spakes" > To: "Andy Bierman" > Cc: "Juergen Schoenwaelder" ; "Randy Presuhn" ; "David Spakes" ; > Sent: Wednesday, December 07, 2011 11:29 AM > Subject: Re: [netmod] Snmp configuration charter addition ... > I am a very practical person. My concept of completeness here is that > an operator is able to switch back-and-forth from using an SNMP-based > configuration tool and a NETCONF-based configuration tool. Changes made > to the configuration of an SNMP entity by one tool show up nice and neat > in dashboard of the other tool and vice-versa. If we accept this as a requirement (I think it is an extremely reasonable one) then an immediate consequence is that the NETCONF model must allow all the configurations of the underlying instrumentation that could be set up by the MIB model. Randy From mbj@tail-f.com Wed Dec 7 12:21:00 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E428B11E80D8 for ; Wed, 7 Dec 2011 12:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0FYREMS9H2G for ; Wed, 7 Dec 2011 12:21:00 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 479EF11E80D3 for ; Wed, 7 Dec 2011 12:21:00 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 88E411200054; Wed, 7 Dec 2011 21:20:57 +0100 (CET) Date: Wed, 07 Dec 2011 21:20:56 +0100 (CET) Message-Id: <20111207.212056.143893729.mbj@tail-f.com> To: spakes@snmp.com From: Martin Bjorklund In-Reply-To: References: <4EDE5030.1040303@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 20:21:01 -0000 Hi, David Spakes wrote: > The best example is the usmUserTable. You don't configure a user's > authentication and privacy keys simply by pushing them in a protocol > message. Also, key values are not readable. The localized keys depend on > the authSnmpEngineID value, which must be unique for each SNMP entity. A > NETCONF client might expect to be able to do a on one device > and an on another device to copy a configuration, and that > simply would not work using an automatically-converted document. This is one area where the current draft needs more work. It would be great to work on this and see what can be done, and your input is very valuable. I suspect you have some way to handle this in your tools. If only we could agree on the charter text so we can work on the solution... /martin From andy@netconfcentral.org Wed Dec 7 12:32:19 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D963311E80C0 for ; Wed, 7 Dec 2011 12:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX2aoDPQ55Qh for ; Wed, 7 Dec 2011 12:32:19 -0800 (PST) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA4C11E80E7 for ; Wed, 7 Dec 2011 12:32:18 -0800 (PST) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pB7KWFS0012024 for ; Wed, 7 Dec 2011 15:32:17 -0500 Authentication-Results: cm-omr6 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:33497] helo=[192.168.0.126]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 7C/CA-09033-E4DCFDE4; Wed, 07 Dec 2011 15:32:15 -0500 Message-ID: <4EDFCD4E.3000804@netconfcentral.org> Date: Wed, 07 Dec 2011 12:32:14 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Randy Presuhn References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> <0lty5e51h7.fsf@wjh.hardakers.net> <20111205182927.GA77176@elstar.local> <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> <20111206074018.GA78060@elstar.local> <4EDDE520.1060708@netconfcentral.org> <4EDE5030.1040303@netconfcentral.org> <4EDF9937.90908@netconfcentral.org> <000601ccb519$eb00a680$6b01a8c0@oemcomputer> In-Reply-To: <000601ccb519$eb00a680$6b01a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 20:32:20 -0000 On 12/07/2011 11:53 AM, Randy Presuhn wrote: > Hi - > >> From: "David Spakes" >> To: "Andy Bierman" >> Cc: "Juergen Schoenwaelder"; "Randy Presuhn"; "David Spakes" > ; >> Sent: Wednesday, December 07, 2011 11:29 AM >> Subject: Re: [netmod] Snmp configuration charter addition > ... >> I am a very practical person. My concept of completeness here is that >> an operator is able to switch back-and-forth from using an SNMP-based >> configuration tool and a NETCONF-based configuration tool. Changes made >> to the configuration of an SNMP entity by one tool show up nice and neat >> in dashboard of the other tool and vice-versa. > If we accept this as a requirement (I think it is an extremely reasonable one) > then an immediate consequence is that the NETCONF model must allow > all the configurations of the underlying instrumentation that could be set up > by the MIB model. I hope you are referring only to the snmp-cfg YANG module, and not to all YANG modules produced by the IETF. I think most SNMP deployments are now configured with proprietary CLI. Any new YANG module is going to require new work by a vendor. It doesn't seem realistic to me that a NETCONF application developer would do anything special for config that happens to be for the SNMP agent vs. some other system component. The server capabilities and NETCONF/YANG specs will dictate how the application is written. If there are any SNMP agent configurations which the WG solution does not properly support, then these issues can be raised on the mailing list. Supporting config options for component combinations that are not actually used is kind of a waste of time. Mandating it in a charter is not going to avoid any debates on the details. > Randy Andy From david.kessens@nsn.com Wed Dec 7 22:37:01 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E7221F8B22 for ; Wed, 7 Dec 2011 22:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyoh82L3ve4U for ; Wed, 7 Dec 2011 22:37:00 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6403321F8B20 for ; Wed, 7 Dec 2011 22:37:00 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pB86au0W013516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Dec 2011 07:36:57 +0100 Received: from localhost.localdomain ([10.138.51.139]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pB86anS1005881; Thu, 8 Dec 2011 07:36:53 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id pB852Nwb018500; Wed, 7 Dec 2011 21:04:23 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id pB850KUn018473; Wed, 7 Dec 2011 21:00:20 -0800 Date: Wed, 7 Dec 2011 21:00:20 -0800 From: David Kessens To: Andy Bierman Message-ID: <20111208050020.GD3865@nsn.com> References: <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> <20111206074018.GA78060@elstar.local> <4EDDE520.1060708@netconfcentral.org> <4EDE5030.1040303@netconfcentral.org> <4EDF9937.90908@netconfcentral.org> <000601ccb519$eb00a680$6b01a8c0@oemcomputer> <4EDFCD4E.3000804@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EDFCD4E.3000804@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 06:37:01 -0000 On Wed, Dec 07, 2011 at 12:32:14PM -0800, Andy Bierman wrote: > > If there are any SNMP agent configurations which the WG solution does not > properly support, then these issues can be raised on the mailing list. > Supporting config options for component combinations that are not actually > used is kind of a waste of time. Mandating it in a charter is not going to avoid > any debates on the details. And this brings us back to the charter text: Randy/David: although you are not entirely happy with the current proposal, can you live with the text under assumption that the working group will take your contributions and concerns seriously (as we already are supposed to)? Basically, I much rather have us investing time on the draft itself and work out any real life differences for the draft than hypothetical issues for the charter text that might not even arise. A charter item is there to guide our work but it doesn't have to spell out the whole draft in advance. David Kessens co-chair netmod wg --- From spakes@snmp.com Thu Dec 8 07:27:52 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3856B21F8AFA for ; Thu, 8 Dec 2011 07:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1a94PqMB2Yh for ; Thu, 8 Dec 2011 07:27:51 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3D74421F8AF8 for ; Thu, 8 Dec 2011 07:27:50 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA13037; Thu, 8 Dec 2011 10:27:43 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA25196; Thu, 8 Dec 2011 10:27:40 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 8 Dec 2011 10:27:39 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: David Kessens In-Reply-To: <20111208050020.GD3865@nsn.com> Message-ID: References: <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> <20111206074018.GA78060@elstar.local> <4EDDE520.1060708@netconfcentral.org> <4EDE5030.1040303@netconfcentral.org> <4EDF9937.90908@netconfcentral.org> <000601ccb519$eb00a680$6b01a8c0@oemcomputer> <4EDFCD4E.3000804@netconfcentral.org> <20111208050020.GD3865@nsn.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 15:27:52 -0000 I said in an earlier post that I was neutral on this issue. Please don't hold up a charter text decision on my account. After the others who have provided input are content, I'll go along with the group decision. I'm not certain what is the current proposal at this point. I really liked Andy's suggestion to change 'must' to 'should' (with the phrase about common operational practice discarded). The text would be: 5. Data model for configuring SNMP engines. The model should be capable of representing all SNMP engine configurations possible with the standard SNMPv3 MIB modules. -dss On Wed, 7 Dec 2011, David Kessens wrote: > Randy/David: although you are not entirely happy with the current proposal, > can you live with the text under assumption that the working group will take > your contributions and concerns seriously (as we already are supposed to)? > > Basically, I much rather have us investing time on the draft itself and work > out any real life differences for the draft than hypothetical issues for the > charter text that might not even arise. A charter item is there to guide our > work but it doesn't have to spell out the whole draft in advance. > > David Kessens > co-chair netmod wg > --- On Tue, 6 Dec 2011, Andy Bierman wrote: > This text is flawed because 'must' in sentence 2 does not leave room > for the WG to make judgments wrt/ cost/benefit per feature, etc. > Change 'must' to 'should' and the text is fine. ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From randy_presuhn@mindspring.com Thu Dec 8 10:16:23 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFAD21F8B30 for ; Thu, 8 Dec 2011 10:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.763 X-Spam-Level: X-Spam-Status: No, score=-101.763 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jz+Scv0LAdIW for ; Thu, 8 Dec 2011 10:16:22 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 58C6721F8B1E for ; Thu, 8 Dec 2011 10:16:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rO1vss5GWj8/Gk/UjScFLBEMXcAONwbWbOZbBUE9IUniNn15tvDP3zv648ABdr8C; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.55.152] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RYiW4-0004VK-0f for netmod@ietf.org; Thu, 08 Dec 2011 13:16:20 -0500 Message-ID: <006701ccb5d5$c00ada60$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> <20111206074018.GA78060@elstar.local> <4EDDE520.1060708@netconfcentral.org> <4EDE5030.1040303@netconfcentral.org> <4EDF9937.90908@netconfcentral.org> <000601ccb519$eb00a680$6b01a8c0@oemcomputer> <4EDFCD4E.3000804@netconfcentral.org> <20111208050020.GD3865@nsn.com> Date: Thu, 8 Dec 2011 10:18:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0f4991edc79d064648d7d37f19f341494e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.55.152 Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 18:16:23 -0000 Hi - > From: "David Kessens" > To: "Andy Bierman" > Cc: "Randy Presuhn" ; ; "David Spakes" > Sent: Wednesday, December 07, 2011 9:00 PM > Subject: Re: [netmod] Snmp configuration charter addition ... > Randy/David: although you are not entirely happy with the current proposal, > can you live with the text under assumption that the working group will take > your contributions and concerns seriously (as we already are supposed to)? As I've said multiple times, I can live with the proposal. I'm no longer in the SNMP business, so to me the cost of the screwups it's inviting is negligible. I do think it is overly optimistic to assume that the WG will find out in a timely manner about the consequences of its decisions to introduce incompatibilities. The people most familiar with some of the SNMP engine code bases have been conspicuously absent from the discussion. However, people from the sole dominant vendor seem to be engaged, so that's probably good enough, and it's probably not a technical problem if the solution only works with that vendor's code. Personally, I have no particular motivation to follow this work closely, and certainly can't commit to reviewing the work. Again, I can live with the current proposal. Randy From internet-drafts@ietf.org Thu Dec 8 13:15:03 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBB421F8B74; Thu, 8 Dec 2011 13:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WxAR3nW3EzO; Thu, 8 Dec 2011 13:15:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A457221F8B6C; Thu, 8 Dec 2011 13:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111208211502.17802.89784.idtracker@ietfa.amsl.com> Date: Thu, 08 Dec 2011 13:15:02 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-smi-yang-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 21:15:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Workin= g Group of the IETF. Title : Translation of SMIv2 MIB Modules to YANG Modules Author(s) : Juergen Schoenwaelder Filename : draft-ietf-netmod-smi-yang-03.txt Pages : 41 Date : 2011-12-08 YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the SNMP protocol. This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only access to data objects defined in SMIv2 MIB modules via NETCONF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-smi-yang-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-smi-yang-03.txt From wjhns1@hardakers.net Fri Dec 9 13:16:28 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FC511E809B for ; Fri, 9 Dec 2011 13:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUJjNEBj9aKn for ; Fri, 9 Dec 2011 13:16:28 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id D32F811E8099 for ; Fri, 9 Dec 2011 13:16:27 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 18432245; Fri, 9 Dec 2011 13:15:57 -0800 (PST) From: Wes Hardaker To: "Randy Presuhn" References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> <0lty5e51h7.fsf@wjh.hardakers.net> <20111205182927.GA77176@elstar.local> <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> <20111206074018.GA78060@elstar.local> <4EDDE520.1060708@netconfcentral.org> <20111206173018.GC81469@elstar.local> <4EDE7B11.2050002@netconfcentral.org> <003b01ccb45a$a10de340$6b01a8c0@oemcomputer> Date: Fri, 09 Dec 2011 13:15:56 -0800 In-Reply-To: <003b01ccb45a$a10de340$6b01a8c0@oemcomputer> (Randy Presuhn's message of "Tue, 6 Dec 2011 13:04:21 -0800") Message-ID: <0lmxb1tpir.fsf@wjh.hardakers.net> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 21:16:28 -0000 >>>>> On Tue, 6 Dec 2011 13:04:21 -0800, "Randy Presuhn" said: RP> I think the difference between Wes' position and mine is how much RP> we're willing to trust the WG to do the right thing when given the RP> opportunity to prohibit configurations that the MIB model permits. Could be. I tend to like wiggle room in charters because I think you can work yourself into a corner and it's easier to put the wiggle room in first so you don't have to change it later. [But then, I think the SNMP configuration should be the last thing the WG works on in the first place; all the rest of the operational-impacting models should be done first as I think operators would find them more important to get out soon; but if we're going to do any of them I think you have to allow for "this is the best we could do" cases to go forward rather than be blocked by a "must" in the charter] -- Wes Hardaker SPARTA, Inc. From lhotka@cesnet.cz Sat Dec 10 03:25:35 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C468D21F8B3F for ; Sat, 10 Dec 2011 03:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTFWYOqRboL5 for ; Sat, 10 Dec 2011 03:25:35 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5D321F8AFE for ; Sat, 10 Dec 2011 03:25:34 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:219:99ff:fead:6129] (unknown [IPv6:2001:718:1a02:7:219:99ff:fead:6129]) by office2.cesnet.cz (Postfix) with ESMTPSA id 2968C2CDE058 for ; Sat, 10 Dec 2011 12:25:31 +0100 (CET) Message-ID: <4EE341AA.90701@cesnet.cz> Date: Sat, 10 Dec 2011 12:25:30 +0100 From: Ladislav Lhotka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: netmod@ietf.org References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> <0lty5e51h7.fsf@wjh.hardakers.net> <20111205182927.GA77176@elstar.local> <002201ccb3d0$410ad460$6b01a8c0@oemcomputer> <20111206074018.GA78060@elstar.local> <4EDDE520.1060708@netconfcentral.org> <20111206173018.GC81469@elstar.local> <4EDE7B11.2050002@netconfcentral.org> <003b01ccb45a$a10de340$6b01a8c0@oemcomputer> <0lmxb1tpir.fsf@wjh.hardakers.net> In-Reply-To: <0lmxb1tpir.fsf@wjh.hardakers.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 11:25:35 -0000 Dne 9.12.2011 22:15, Wes Hardaker napsal(a): >>>>>> On Tue, 6 Dec 2011 13:04:21 -0800, "Randy Presuhn" said: > > RP> I think the difference between Wes' position and mine is how much > RP> we're willing to trust the WG to do the right thing when given the > RP> opportunity to prohibit configurations that the MIB model permits. > > Could be. I tend to like wiggle room in charters because I think you > can work yourself into a corner and it's easier to put the wiggle room > in first so you don't have to change it later. > > [But then, I think the SNMP configuration should be the last thing the > WG works on in the first place; all the rest of the > operational-impacting models should be done first as I think operators > would find them more important to get out soon; but if we're going to > do any of them I think you have to allow for "this is the best we could > do" cases to go forward rather than be blocked by a "must" in the charter] Right, it has been my impression, too, that the WG spends a lot of cycles on this particular issue that could be better invested in the existing charter items. Lada > > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From andy@netconfcentral.org Sun Dec 11 11:49:37 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468EA21F8479 for ; Sun, 11 Dec 2011 11:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[AWL=-1.104, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czG8x9+2xIhX for ; Sun, 11 Dec 2011 11:49:36 -0800 (PST) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by ietfa.amsl.com (Postfix) with ESMTP id 41A8921F846C for ; Sun, 11 Dec 2011 11:49:36 -0800 (PST) Received: from cm-omr9 ([205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id pBBJnVUw031635 for ; Sun, 11 Dec 2011 14:49:33 -0500 Authentication-Results: cm-omr9 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:33691] helo=[192.168.0.126]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id F9/F2-02848-A4905EE4; Sun, 11 Dec 2011 14:49:31 -0500 Message-ID: <4EE5094A.9050004@netconfcentral.org> Date: Sun, 11 Dec 2011 11:49:30 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] choice-stmt syntax X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 19:49:37 -0000 Hi, I am curious about the differences between the 'short-case-stmt' and 'case-stmt' variants. short-case-stmt = container-stmt / leaf-stmt / leaf-list-stmt / list-stmt / anyxml-stmt This is essentially a data-def-stmt without choice-stmt or uses-stmt, A case-stmt uses *data-def-stmt. I understand why uses-stmt cannot be in a short-case-stmt -- it can expand to more than 1 data node which could be interpreted as multiple short-case-stmts. I don't understand why choice-stmt cannot be used: choice a { choice case-one { ... } // illegal leaf case-two { ... } } choice b { case one { choice case-one { ... } // legal } leaf case-two { ... } } This seems like a YANG CLR to me. (Among many) I know both nested choices could be pulled up into the top choice, but for user UI reasons, I could see how nested choices could end up in the data model instead. Andy From david.kessens@nsn.com Wed Dec 14 14:50:33 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DB921F8AFB for ; Wed, 14 Dec 2011 14:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.617 X-Spam-Level: X-Spam-Status: No, score=-6.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhEXibWj5rPw for ; Wed, 14 Dec 2011 14:50:32 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 347A021F8AF5 for ; Wed, 14 Dec 2011 14:50:31 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBEMoSbS029950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 14 Dec 2011 23:50:28 +0100 Received: from localhost.localdomain ([10.138.51.245]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBEMoOf8026021 for ; Wed, 14 Dec 2011 23:50:28 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id pBEMoOcj006436 for ; Wed, 14 Dec 2011 14:50:24 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id pBEMoOKB006435 for netmod@ietf.org; Wed, 14 Dec 2011 14:50:24 -0800 Date: Wed, 14 Dec 2011 14:50:24 -0800 From: David Kessens To: netmod@ietf.org Message-ID: <20111214225024.GM31395@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] Last Call: draft-ietf-netmod-smi-yang-03 (20120109) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 22:50:33 -0000 Hi, I would hereby like to start a second Last Call for: http://tools.ietf.org/html/draft-ietf-netmod-smi-yang-03 It appears that Juergen has addressed all concerns that were raised during the previous last call so it is time to do a final review. Please indicate your support by Jan 9, 2012. The Last Call deadline is unusually long as we are heading into the end of year holidays and I want to make sure people don't miss this last call due to their holiday plans. I would like to see at least three reviews of the draft to make sure that we have had sufficient review to move this draft to the next level so please indicate whether you have reviewed the current draft when you state your support. Thanks! David Kessens co-chair netmod wg --- From mbj@tail-f.com Fri Dec 16 01:39:35 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F039421F8AA8 for ; Fri, 16 Dec 2011 01:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCyDlVKdP54X for ; Fri, 16 Dec 2011 01:39:35 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6708C21F843D for ; Fri, 16 Dec 2011 01:39:35 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id C92B712008D7; Fri, 16 Dec 2011 10:39:32 +0100 (CET) Date: Fri, 16 Dec 2011 10:39:30 +0100 (CET) Message-Id: <20111216.103930.320461307.mbj@tail-f.com> To: david.kessens@nsn.com From: Martin Bjorklund In-Reply-To: <20111214225024.GM31395@nsn.com> References: <20111214225024.GM31395@nsn.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: draft-ietf-netmod-smi-yang-03 (20120109) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 09:39:36 -0000 Hi, I have reviewd the -03 version, and I think this document is ready for publication. All my previous comments have been addressed. I haven't implemented the mapping, but I have implemented the YANG extensions defined in ietf-yang-smiv2 in pyang (so that pyang validates these new statements). /martin From j.schoenwaelder@jacobs-university.de Sat Dec 17 02:39:10 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D5121F8BF9 for ; Sat, 17 Dec 2011 02:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.147 X-Spam-Level: X-Spam-Status: No, score=-103.147 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oef946MrhKOr for ; Sat, 17 Dec 2011 02:39:10 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E644E21F8B44 for ; Sat, 17 Dec 2011 02:39:09 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 437D520D82; Sat, 17 Dec 2011 11:39:09 +0100 (CET) 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 B9hWr_DCVcRG; Sat, 17 Dec 2011 11:39:07 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A180820D7F; Sat, 17 Dec 2011 11:39:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5085E1C1C9F0; Sat, 17 Dec 2011 11:38:49 +0100 (CET) Date: Sat, 17 Dec 2011 11:38:49 +0100 From: Juergen Schoenwaelder To: David Kessens Message-ID: <20111217103849.GB49087@elstar.local> Mail-Followup-To: David Kessens , netmod@ietf.org References: <20111104101628.GA2606@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111104101628.GA2606@nsn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: iana-if-type-01 & interfaces-cfg-02 (20111121) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 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, 17 Dec 2011 10:39:10 -0000 On Fri, Nov 04, 2011 at 03:16:28AM -0700, David Kessens wrote: > > Hi, > > I would hereby like to start a Last Call for: > > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-02.txt > http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-01.txt > > The drafts seem to stabilized enough so it is time to determine whether > they are ready to be send to the IESG for approval. > > Please indicate your support by Nov 21 2011, but preferably before our > working group session on Nov 15. I would like to see at least three reviews > of the drafts to make sure that we have had sufficient review to move them > to the next level so please indicate whether you have reviewed the current > drafts when you state your support. We only have received two supporting reviews and we (the chairs) feel this is not enough to move this document forward. We need more reviews and it would help a lot if there would even reports of people implementing or planning to implement this. More reviews please! /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.org Sat Dec 17 10:02:10 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D37421F8AA8 for ; Sat, 17 Dec 2011 10:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1BXGjQsnuWk for ; Sat, 17 Dec 2011 10:02:10 -0800 (PST) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id DE9E721F8A7A for ; Sat, 17 Dec 2011 10:02:09 -0800 (PST) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pBHI26Sl004120 for ; Sat, 17 Dec 2011 13:02:08 -0500 Authentication-Results: cm-omr5 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:50403] helo=[192.168.0.126]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 0C/A1-11322-E19DCEE4; Sat, 17 Dec 2011 13:02:06 -0500 Message-ID: <4EECD91D.3040405@netconfcentral.org> Date: Sat, 17 Dec 2011 10:02:05 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: David Kessens , netmod@ietf.org References: <20111104101628.GA2606@nsn.com> <20111217103849.GB49087@elstar.local> In-Reply-To: <20111217103849.GB49087@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Last Call: iana-if-type-01 & interfaces-cfg-02 (20111121) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 18:02:10 -0000 On 12/17/2011 02:38 AM, Juergen Schoenwaelder wrote: > On Fri, Nov 04, 2011 at 03:16:28AM -0700, David Kessens wrote: >> Hi, >> >> I would hereby like to start a Last Call for: I read both drafts and have a few comments. I think they are ready to send to the IESG. I have some concerns -- see below. >> >> http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-02.txt This draft is reasonable for a framework for interfaces. It will have value if it gets filled in with augmenting definitions. It is possible vendors will move their interface configuration to the /interfaces/interface list, but not likely. It is much more likely this data structure will need to have a lot of standard modules defined to make this more than an empty framework. There are only 2 real 'knobs' defined -- 'mtu' and 'enabled' leafs. The 'mtu' leaf is mandatory-to-implement and not always meaningful: This node might not be valid for all interface types. Media-specific modules must specify any restrictions on the mtu for their interface type."; All the writable leafs seem to have a lot of vendor or context-specific 'wiggle-room'. So much so, that I wonder how an application developer can really code anything concrete based on this module. The actual data node location (e.g., /interfaces/interface vs. /acme:interface/acme:ethernet) is not a real factor in the implementation complexity. Supporting 10 or 20 different data structure variants is the problem. This module demonstrates the main challenge with standard configuration. Integrating new config knobs into systems with existing proprietary solutions is hard. A vendor cannot just remove the old knobs. That is a non-starter. Even brand new platforms usually need to support the legacy/proprietary solutions. It is often expensive to re-design control code that assumes it is the only control path. Allowing the device instrumentation to change underneath, and have both sets of knobs instantly reflect the new config (in their own ways) is difficult. It also assumes that the data model mismatches are purely syntactic and not semantic. This is usually wrong. Perhaps some sort of instance-identifier 'pointers' would allow vendors to patch in proprietary data models. leaf-list additional-object { type instance-identifier; description "List of pointers to other managed objects related to this interface."; } The list of if-index values seems intended to provide the same sort of feature, except it is SNMP-centric. >> http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-01.txt I assume this module will be updated at different times than the official IANA list of interface enums. There will be a window when some vendors may want to use a newly assigned enum and it isn't published yet. I guess this is a minor problem. >> The drafts seem to stabilized enough so it is time to determine whether >> they are ready to be send to the IESG for approval. >> >> Please indicate your support by Nov 21 2011, but preferably before our >> working group session on Nov 15. I would like to see at least three reviews >> of the drafts to make sure that we have had sufficient review to move them >> to the next level so please indicate whether you have reviewed the current >> drafts when you state your support. > We only have received two supporting reviews and we (the chairs) feel > this is not enough to move this document forward. We need more reviews > and it would help a lot if there would even reports of people > implementing or planning to implement this. > > More reviews please! > > /js > Andy From mbj@tail-f.com Mon Dec 19 00:04:18 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0F821F8A70 for ; Mon, 19 Dec 2011 00:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCDdlxjJmBQ5 for ; Mon, 19 Dec 2011 00:04:17 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7675921F8A6F for ; Mon, 19 Dec 2011 00:04:16 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9E03F1200AC8; Mon, 19 Dec 2011 09:04:14 +0100 (CET) Date: Mon, 19 Dec 2011 09:04:14 +0100 (CET) Message-Id: <20111219.090414.995931631585760984.mbj@tail-f.com> To: andy@netconfcentral.org From: Martin Bjorklund In-Reply-To: <4EECD91D.3040405@netconfcentral.org> References: <20111104101628.GA2606@nsn.com> <20111217103849.GB49087@elstar.local> <4EECD91D.3040405@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: iana-if-type-01 & interfaces-cfg-02 (20111121) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 08:04:18 -0000 Hi Andy, Andy Bierman wrote: > On 12/17/2011 02:38 AM, Juergen Schoenwaelder wrote: > > On Fri, Nov 04, 2011 at 03:16:28AM -0700, David Kessens wrote: > >> Hi, > >> > >> I would hereby like to start a Last Call for: > > I read both drafts and have a few comments. > I think they are ready to send to the IESG. > I have some concerns -- see below. > > > >> > >> http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-02.txt > > This draft is reasonable for a framework for interfaces. > It will have value if it gets filled in with augmenting definitions. Agreed. > It is possible vendors will move their interface configuration > to the /interfaces/interface list, but not likely. It is much more > likely > this data structure will need to have a lot of standard modules > defined > to make this more than an empty framework. > > There are only 2 real 'knobs' defined -- 'mtu' and 'enabled' leafs. > The 'mtu' leaf is mandatory-to-implement and not always meaningful: > > This node might not be valid for all interface types. > > Media-specific modules must specify any restrictions on > the mtu for their interface type."; > > > All the writable leafs seem to have a lot of vendor or > context-specific 'wiggle-room'. > So much so, that I wonder how an application developer can really code > anything > concrete based on this module. The actual data node location (e.g., > /interfaces/interface > vs. /acme:interface/acme:ethernet) is not a real factor in the > implementation complexity. Having one standard place for interfaces is also valuable for other data models that need to reference an interface. Without this, we end up with solutions like the one in ietf-ipfix-psamp. > Supporting 10 or 20 different data structure variants is the problem. > > This module demonstrates the main challenge with standard > configuration. > Integrating new config knobs into systems with existing proprietary > solutions is hard. > A vendor cannot just remove the old knobs. That is a non-starter. > Even brand new platforms usually need to support the > legacy/proprietary solutions. > > It is often expensive to re-design control code that assumes it is the > only control path. > Allowing the device instrumentation to change underneath, and have > both sets of > knobs instantly reflect the new config (in their own ways) is > difficult. It also assumes > that the data model mismatches are purely syntactic and not semantic. > This is usually wrong. > > Perhaps some sort of instance-identifier 'pointers' would allow > vendors to patch in > proprietary data models. > > > leaf-list additional-object { > type instance-identifier; > description > "List of pointers to other managed objects related to this > interface."; > } I am not sure exactly what problem this would solve and how it would be used. With the current model, vendors can always add such an object if they need it. > The list of if-index values seems intended to provide the same sort of > feature, > except it is SNMP-centric. Not really; it is intended for co-existance with SNMP, so that you can relate SNMP info with NETCONF/YANG. > >> http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-01.txt > > > I assume this module will be updated at different times than the > official IANA list > of interface enums. No, the idea is to use the offical IANA list. Originally we used an identity for this instead, but the WG ruled that out in favor for the current solution. /martin