From stefan.winter@restena.lu Tue Feb 11 03:05:34 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEB71A07F2 for ; Tue, 11 Feb 2014 03:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1snNLUFiaieZ for ; Tue, 11 Feb 2014 03:05:31 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 0E36B1A07D2 for ; Tue, 11 Feb 2014 03:05:29 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 661FD10581 for ; Tue, 11 Feb 2014 12:05:28 +0100 (CET) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 5956C10580 for ; Tue, 11 Feb 2014 12:05:28 +0100 (CET) Message-ID: <52FA03EB.3090503@restena.lu> Date: Tue, 11 Feb 2014 12:05:15 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ops-area@ietf.org References: <20140210123846.21255.5774.idtracker@ietfa.amsl.com> In-Reply-To: <20140210123846.21255.5774.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JBejiea6wW0skbcRvvvhWsAGL9EOgj7IK" X-Virus-Scanned: ClamAV Subject: [OPS-AREA] New Version Notification for draft-winter-opsawg-eap-metadata-00.txt (fwd) X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 11:05:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JBejiea6wW0skbcRvvvhWsAGL9EOgj7IK Content-Type: multipart/mixed; boundary="------------040706060601010201060009" This is a multi-part message in MIME format. --------------040706060601010201060009 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A new version of I-D, draft-winter-opsawg-eap-metadata-00.txt has been successfully submitted by Stefan Winter and posted to the IETF repository. Name: draft-winter-opsawg-eap-metadata Revision: 00 Title: A Configuration File Format for Extensible Authentication Protocol (EAP) Deployments Document date: 2014-02-10 Group: Individual Submission Pages: 17 URL: http://www.ietf.org/internet-drafts/draft-winter-opsawg-eap-metadata-00.t= xt Status: https://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/ Htmlized: http://tools.ietf.org/html/draft-winter-opsawg-eap-metadata-00 Abstract: This document specifies a file format for transfering configuration information of deployments of the Extensible Authentication Protocol (EAP). Such configuration files are meant to be discovered, consumed and used by EAP supplicant software to achieve secure and automatic EAP configuration on the consuming device. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------040706060601010201060009 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------040706060601010201060009 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------040706060601010201060009-- --JBejiea6wW0skbcRvvvhWsAGL9EOgj7IK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJS+gPrAAoJEMDeajWKOdxmu8IP/RgCxi5/VoS9AoM4deE4IfCd Q4DJg40iSpeVk1W2NvYdxwxKRb2EGR93yFjmiN/NBp1eKlB0gHMQQkJOEfFb2jTN ZU8FGPHYidP8bbIcwA3aqlucjAq7MOFtiDoivlP/QZf9ZnJcBGt0IGy//BgjaKWs jUhEkPx2khjUitqXtZzMxoIU4LXxCk+PfH75hQlG9xUiK1rHm+WByoEjKsi0arcH LxHtuLj1WoAJW7PCw5cG1TtIg7qyL/Lut9raErLSKq2TIkcl5pdPfPkKSgHiWvnY 51aSBK3yPsnwkRwv+WbIDVMyI8V+U3OHBFUveCGM+S4X8Fok0TUkkB5iahaDmSMh nXGThi66qAR8h1GRTTHMZ4jIKUZSDiyXTXaZEGJ4g5CUj/RTwRLnLfgFy3+n8qUr fwVhM0+SPUnwAWH3or7BHqer/FPQkRe0aj9Pt/n1NAxZ907wziK8hFuFgRKKZCh8 c5a9zOsIh/S7A/KQAKPtFMnm6ShPGwM40e99ZPiUygp1mFlVa5WZIkqAoFFwiZyW h4SkLId8HoLdute8I9UECBUCuEPTFO1rqRQnPXUjLDhqymti/vQldHV7OXWUsPV2 tycvm0X0Zu+Qmz4HxbvfL/N42fja61u3GH6KWradx6a9uGIlpbAKa97nQ/U4K6bv L3iKE8OAEugdve+KbpCC =qDJR -----END PGP SIGNATURE----- --JBejiea6wW0skbcRvvvhWsAGL9EOgj7IK-- From stefan.winter@restena.lu Tue Feb 11 03:05:51 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF4B1A07E4 for ; Tue, 11 Feb 2014 03:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjQuitwr1Pct for ; Tue, 11 Feb 2014 03:05:49 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id E4D551A07D0 for ; Tue, 11 Feb 2014 03:05:46 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 48B5510581 for ; Tue, 11 Feb 2014 12:05:46 +0100 (CET) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 3A68910580 for ; Tue, 11 Feb 2014 12:05:46 +0100 (CET) Message-ID: <52FA03FD.6070308@restena.lu> Date: Tue, 11 Feb 2014 12:05:33 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ops-area@ietf.org" X-Enigmail-Version: 1.6 OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bbsi3ndEF7XE6icn1B4J3Dc3r5woWbd46" X-Virus-Scanned: ClamAV Subject: [OPS-AREA] EAP configuration metadata draft X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 11:05:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bbsi3ndEF7XE6icn1B4J3Dc3r5woWbd46 Content-Type: multipart/mixed; boundary="------------020508050701010003000307" This is a multi-part message in MIME format. --------------020508050701010003000307 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello (adding ops-area@), I would like to draw your attention to my submission of draft-winter-opsawg-eap-metadata-00 ( http://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/ ). I would like to ask the community how they feel about this work - is it needed, are we on the right track, etc. As a teaser for why our group thinks this piece of work is important and useful, please see the beginning of the Problem Statement section, pasted here for your convenience: "The IETF has produced the Extensible Authentication Protocol (EAP, [RFC3748] and numerous EAP methods (for example EAP-TTLS [RFC5281], EAP-TLS [RFC5216] and [RFC5931]); the methods have many properties which need to be setup on the EAP server and matched as configuration items on the EAP peer for a secure EAP deployment. Setting up these configuration items is comparatively easy if the end-user devices which implement the EAP peer functionality are under central administrative control, e.g. in closed enterprise environments. Group policies or device provisioning by the IT department can push the settings to user devices. In other environments, for example "BYOD" scenarios where users bring their own devices which are not under enterprise control, or in EAP- based WISP environments (see e.g. [HS20] and [I-D.wierenga-ietf-eduroam]) where it is not desired neither for the ISP nor for his user that the device control is in the ISPs hands, configuration of EAP is significantly harder as it has to be done by potentially very non-technical end users." There's plenty of proprietary approaches, they all vary in richness of expressability, most don't have complete public schemas or are even in binary with no explanations on how to construct them as an outsider. We find the lack of a public specification disturbing. It leads to duplication of efforts in numerous organisations, incompatiblities between the produced formats, and sometimes simply leads to bad quality specs. BTW, I have teased the list earlier (see my posting on 18 Dec 2013), and already got an on-list response (as well as offline). I believe this warrants allocation of slot time in London, and I would at this point ask the chairs if it's possible to get 5 mins (more if you have plenty :-) ) to discuss the problem itself and the solution we've put together in this first draft. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------020508050701010003000307 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------020508050701010003000307 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------020508050701010003000307-- --bbsi3ndEF7XE6icn1B4J3Dc3r5woWbd46 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJS+gP9AAoJEMDeajWKOdxmOMwQAIMcmoh2la9QkK7RG5vTEMqu Iik0m3fBmC/gDBlgi2DNDPU6VU9OnWoHUdQxlsxS/pyAApVKQc1qjGmI/Z8Lg7vR IKQSJn7+/TbDLSutkLK2hhTVwQKx2svISbPeF77yg2rzkqN2Yp0B7RoIiHszPoJL aWVPS7rPqwnCaNTVBZ0mGRpHN0aBhDuPgqTwkKLRh2/LyzBXMatB4LT+xK66U07c a/05V48oeQH1p2fk9tLjtsPpQJlrRaNPDR5QHWdTWdfYtd9kIwt0c4hrlDOKokIm 5ONsz4h1AEzW4AvDfX1qRW0CUwGA5QQ0YoZ+ikaVf4RLWPvdWyWSLhHbm/hMCye4 k7wxp49K0mNrV5zNiiAMN3CKo5rt3AraxBTpzz7pHB8fbGKsF87ASlcch2oiqaGj kjmoBObJDG7MW5zru7JnX/tQelw8eMPY6ULPCCuB38vJrEQ/tYVq8F7iqydqkDvw UMxwN7Hv2QT8qTcxlSGrsq2ExULzJ8V2tK3PqaJjEmMWufjqoki9dKbsu0yQJ7iS pBBoo3Pf0QOJCrpk8xAtq09F0ZoiKvhq4QhyuqFrldacVD8juxGWVpOk3FwjjirR jYyWRmNlFgr2I5pvA1XOON+hUFvbUTnq2lJjo6NVEYJvkYaGu++7BdZCrifKq4Te Nbt0mD4wR1quV+BZrg5R =5U2P -----END PGP SIGNATURE----- --bbsi3ndEF7XE6icn1B4J3Dc3r5woWbd46-- From nobody Thu Feb 13 16:40:11 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984491A002E for ; Thu, 13 Feb 2014 16:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.703 X-Spam-Level: X-Spam-Status: No, score=-6.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_lNSyUwri3H for ; Thu, 13 Feb 2014 16:40:06 -0800 (PST) Received: from aer-iport-4.cisco.com (unknown [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2172F1A0021 for ; Thu, 13 Feb 2014 16:40:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2908; q=dns/txt; s=iport; t=1392338405; x=1393548005; h=message-id:date:from:mime-version:to:subject; bh=XrndkOuTGmFjl5PXNEger8b14yyE88vZv89P1VBs2IE=; b=J+shLVqPyY0JIZQfgFUJy5h0vtT/GVV6cyjs2c40hkwKA6LvBHPwZi8z 8R2XtZPgmC3cuV050duWLWXR3yVfsz+NTWjHO10Xlshn2qnR4N90y6lno c6XT9GFD2bHo1cSny19HmdyG7+oFzM25ZZJRZbfrtsWFzlmKBabFOyrDq 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAMFk/VKQ/khM/2dsb2JhbABZgwaJbLgMFnSDJCABHBYYAwIBAgFLDQgBAYgBl0GxJxeTOASJSI5khkeLXINOGw X-IronPort-AV: E=Sophos;i="4.95,841,1384300800"; d="scan'208,217";a="290476" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-4.cisco.com with ESMTP; 14 Feb 2014 00:40:04 +0000 Received: from [10.21.124.51] (sjc-vpn6-1075.cisco.com [10.21.124.51]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1E0e1H8026928 for ; Fri, 14 Feb 2014 00:40:03 GMT Message-ID: <52FD65DD.4090609@cisco.com> Date: Thu, 13 Feb 2014 16:39:57 -0800 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ops-area@ietf.org" Content-Type: multipart/alternative; boundary="------------010402090609070302050209" Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/aRfOLJfXfLhOEIcXpWM5lypFuNU Subject: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 00:40:07 -0000 This is a multi-part message in MIME format. --------------010402090609070302050209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, We occasionally see read-write MIB module proposals within the IETF. However, the write capabilities of those MIB modules are rarely implemented. While discussing this issue with the MIB doctors, we arrive to the conclusion that it's now time to set the direction for future MIB developments within the IETF. Basically, let's not specify read-write MIB modules unless we have a good reason. Read-only MIB modules are still fine though, as SNMP is clearly used for monitoring purposes. Here is the statement we came up with: The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, specifically in new charters. SNMP MIB modules modifying persistent configuration state should only be produced by working groups in cases of clear utility and consensus to use SNMP write operations for configuration. Ideally, this should become an IESG statement. Your feedback is most welcome. Regards, the MIB doctors & Benoit --------------010402090609070302050209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

We occasionally see read-write MIB module proposals within the IETF.
However, the write capabilities of those MIB modules are rarely implemented.

While discussing this issue with the MIB doctors, we arrive to the conclusion that it's now time to set the direction for future MIB developments within the IETF. Basically, let's not specify read-write MIB modules unless we have a good reason. Read-only MIB modules are still fine though, as SNMP is clearly used for monitoring purposes.

Here is the statement we came up with:
The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, specifically in new charters. SNMP MIB modules modifying persistent configuration state should only be produced by working groups in cases of clear utility
and consensus to use SNMP write operations for configuration.
Ideally, this should become an IESG statement.
Your feedback is most welcome.

Regards, the MIB doctors & Benoit

--------------010402090609070302050209-- From nobody Thu Feb 13 20:48:02 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBCD1A00D5 for ; Thu, 13 Feb 2014 20:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.704 X-Spam-Level: X-Spam-Status: No, score=-6.704 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnh0TnixPkkV for ; Thu, 13 Feb 2014 20:47:59 -0800 (PST) Received: from aer-iport-3.cisco.com (unknown [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4431A00CF for ; Thu, 13 Feb 2014 20:47:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=417; q=dns/txt; s=iport; t=1392353279; x=1393562879; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=vd1lX7GZ9SL/g9sFVZcbLQJ0QQqXsOT/mvMflstuhvE=; b=m7DlieogauWm2IhpjDMIo/AUfSROlpcGsGPYFXTjxYjKqMMkoWGgFrPJ WIr4wsxDzA7LbqxQ51GFIQDIv/ox4/QD3G5iheuDxjB1RQpV77ccViiy3 MG6AuuKfPO63RVeW650GirCxClwSW6IHttJdHhHGvgQ8HXrwY7KmdDmjs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAL+f/VKQ/khN/2dsb2JhbABZgwbAXwqBGRZ0giYBAQQdGzoGESwWDwkDAgECAUUGDQgBAYgByFcXjwCEOAEDiUiOZIZHi1yDThs X-IronPort-AV: E=Sophos;i="4.95,842,1384300800"; d="scan'208";a="303698" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-3.cisco.com with ESMTP; 14 Feb 2014 04:47:52 +0000 Received: from [10.82.246.13] (rtp-vpn2-1547.cisco.com [10.82.246.13]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1E4loLJ020475 for ; Fri, 14 Feb 2014 04:47:51 GMT Message-ID: <52FD9FF8.5030708@cisco.com> Date: Thu, 13 Feb 2014 20:47:52 -0800 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ops-area@ietf.org" References: <5267FF2A.2060903@cisco.com> In-Reply-To: <5267FF2A.2060903@cisco.com> X-Forwarded-Message-Id: <5267FF2A.2060903@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/YIEVAfdgcWJzpIykwItUFpm48kE Subject: [OPS-AREA] call for agenda items for the OPSAREA open meeting at IETF-89 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 04:48:01 -0000 Dear all, We are planning again for a joint OPSAWG and OPSAREA open meeting, with the OPSAWG work items driving most of the agenda. The more general cross-area items or those related to the relation between work in the area and work out of the IETF should be part of the OPSAREA section. Please send us your requests for presentation and discussion slots. Thanks and Regards, Regards, Joel and Benoit From nobody Thu Feb 13 22:39:10 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B0E1A0111 for ; Thu, 13 Feb 2014 22:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1H8mmVKy2lD4 for ; Thu, 13 Feb 2014 22:39:04 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0155.outbound.protection.outlook.com [207.46.163.155]) by ietfa.amsl.com (Postfix) with ESMTP id 487781A0122 for ; Thu, 13 Feb 2014 22:39:04 -0800 (PST) Received: from DM2PR03MB414.namprd03.prod.outlook.com (10.141.84.145) by DM2PR03MB416.namprd03.prod.outlook.com (10.141.84.152) with Microsoft SMTP Server (TLS) id 15.0.873.15; Fri, 14 Feb 2014 06:39:01 +0000 Received: from DM2PR03MB414.namprd03.prod.outlook.com ([10.141.84.145]) by DM2PR03MB414.namprd03.prod.outlook.com ([10.141.84.145]) with mapi id 15.00.0873.009; Fri, 14 Feb 2014 06:39:01 +0000 From: Dave Thaler To: Benoit Claise , "ops-area@ietf.org" Thread-Topic: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules Thread-Index: AQHPKR1TI5JnIK2mFk2zTZVG6u0h5pq0S++A Date: Fri, 14 Feb 2014 06:39:00 +0000 Message-ID: References: <52FD65DD.4090609@cisco.com> In-Reply-To: <52FD65DD.4090609@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(164054003)(377454003)(199002)(189002)(87266001)(19300405004)(76796001)(65816001)(56816005)(74316001)(95666001)(74662001)(224303002)(92566001)(80022001)(83072002)(31966008)(90146001)(15975445006)(76576001)(76786001)(85852003)(81686001)(81816001)(66066001)(2656002)(47446002)(85306002)(93136001)(74502001)(33646001)(69226001)(561944002)(95416001)(86612001)(16236675002)(86362001)(93516002)(94946001)(74706001)(81542001)(46102001)(54356001)(53806001)(15202345003)(51856001)(94316002)(54316002)(56776001)(76482001)(4396001)(49866001)(47736001)(50986001)(74876001)(47976001)(81342001)(63696002)(74366001)(59766001)(87936001)(224313003)(19580395003)(83322001)(77982001)(79102001)(80976001)(19580405001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR03MB416; H:DM2PR03MB414.namprd03.prod.outlook.com; CLIP:50.135.4.20; FPR:; MLV:sfv; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_d7f4ac4dc52a431da78b48ac85a91a85DM2PR03MB414namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/rhnVORgeh_I6P8E7e3UG2epENfA Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 06:39:08 -0000 --_000_d7f4ac4dc52a431da78b48ac85a91a85DM2PR03MB414namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Benoit, this is definitely a step in the right direction. As a chair of WGs outside the OPS area, I'd still like to see additional gu= idance around notification/logging mechanisms as well (IPFIX vs Syslog vs SNMP traps/info= rms, etc.) So carry on and I would like to see more. Thanks, -Dave From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Benoit Clais= e Sent: Thursday, February 13, 2014 4:40 PM To: ops-area@ietf.org Subject: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG= modules Dear all, We occasionally see read-write MIB module proposals within the IETF. However, the write capabilities of those MIB modules are rarely implemented= . While discussing this issue with the MIB doctors, we arrive to the conclusi= on that it's now time to set the direction for future MIB developments with= in the IETF. Basically, let's not specify read-write MIB modules unless we = have a good reason. Read-only MIB modules are still fine though, as SNMP is= clearly used for monitoring purposes. Here is the statement we came up with: The OPS area recommends the use of NETCONF/YANG standards for configuration= . IETF working groups are therefore encouraged to use the NETCONF/YANG stan= dards for configuration, specifically in new charters. SNMP MIB modules mod= ifying persistent configuration state should only be produced by working gr= oups in cases of clear utility and consensus to use SNMP write operations for configuration. Ideally, this should become an IESG statement. Your feedback is most welcome. Regards, the MIB doctors & Benoit --_000_d7f4ac4dc52a431da78b48ac85a91a85DM2PR03MB414namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Benoit, this is de= finitely a step in the right direction.

As a chair of WGs outside= the OPS area, I’d still like to see additional guidance around<= /o:p>

notification/logging mech= anisms as well (IPFIX vs Syslog vs SNMP traps/informs, etc.)

 <= /p>

So carry on and I would l= ike to see more.

 <= /p>

Thanks,=

-Dave

 

From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Thursday, February 13, 2014 4:40 PM
To: ops-area@ietf.org
Subject: [OPS-AREA] configuration: writable MIB modules versus NETCO= NF/YANG modules

 

Dear all,

We occasionally see read-write MIB module proposals within the IETF.
However, the write capabilities of those MIB modules are rarely implemented= .

While discussing this issue with the MIB doctors, we arrive to the conclusi= on that it's now time to set the direction for future MIB developments with= in the IETF. Basically, let's not specify read-write MIB modules unless we = have a good reason. Read-only MIB modules are still fine though, as SNMP is clearly used for monitoring purp= oses.

Here is the statement we came up with:

The OPS area recommends the use of NETCONF/YANG stan= dards for configuration. IETF working groups are therefore encouraged to us= e the NETCONF/YANG standards for configuration, specifically in new charter= s. SNMP MIB modules modifying persistent configuration state should only be produced by working groups in cases of = clear utility
and consensus to use SNMP write operations for configuration.

Ideally, this should = become an IESG statement.
Your feedback is most welcome.

Regards, the MIB doctors & Benoit

--_000_d7f4ac4dc52a431da78b48ac85a91a85DM2PR03MB414namprd03pro_-- From nobody Fri Feb 14 00:46:36 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDD11A0151 for ; Fri, 14 Feb 2014 00:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TePwXxBPxtou for ; Fri, 14 Feb 2014 00:46:31 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A73751A0154 for ; Fri, 14 Feb 2014 00:46:30 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE99620072; Fri, 14 Feb 2014 09:46:28 +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 FkelmyAhhxUe; Fri, 14 Feb 2014 09:46:26 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A0D52005E; Fri, 14 Feb 2014 09:46:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4F5CC2B4C26D; Fri, 14 Feb 2014 09:46:18 +0100 (CET) Date: Fri, 14 Feb 2014 09:46:17 +0100 From: Juergen Schoenwaelder To: Dave Thaler Message-ID: <20140214084617.GB87344@elstar.local> Mail-Followup-To: Dave Thaler , Benoit Claise , "ops-area@ietf.org" References: <52FD65DD.4090609@cisco.com> 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) Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/5I3ZCP6V4jzGbixon1b608E3fPY Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 08:46:34 -0000 On Fri, Feb 14, 2014 at 06:39:00AM +0000, Dave Thaler wrote: > As a chair of WGs outside the OPS area, I'd still like to see > additional guidance around notification/logging mechanisms as well > (IPFIX vs Syslog vs SNMP traps/informs, etc.) This is much harder. Here is how I see things: IPFIX works well for large amounts of notification/logging data that has a common structure, i.e. you get things reported with a few IPFIX templates. SYSLOG works well with semi-structured data - traditionally there was very little common structure and the value was in the free-form text field. SNMP again works with structured data that is defined in data models (which is different from many IPFIX templates that IPFIX data processors are expected to discover at runtime, although I am aware of I-Ds trying to nail down IPFIX templates). Both, SYSLOG and SNMP notifications have seen many years of wide spread deployment, IPFIX for notification/logging is more a new kid on the block. IPFIX may have nice performance characteristics but most management systems I have seen support SNMP notifications and/or SYSLOG messages to extract notification/logging data but not IPFIX. I believe what is widely deployed today (and feel free to prove me wrong) is largely SYSLOG and SNMP for notification/logging data. What I am saying here is that the situation is less clear cut compared to SNMP for persistent configuration. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Feb 14 06:34:24 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E1B1A0284 for ; Fri, 14 Feb 2014 06:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.516 X-Spam-Level: X-Spam-Status: No, score=-0.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbXJpU_F20fu for ; Fri, 14 Feb 2014 06:34:17 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 905761A0273 for ; Fri, 14 Feb 2014 06:34:13 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-f9-52fe2962ea92 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 01.6F.04853.2692EF25; Fri, 14 Feb 2014 15:34:11 +0100 (CET) Received: from [159.107.198.10] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.2.347.0; Fri, 14 Feb 2014 15:34:10 +0100 Message-ID: <52FE2961.4040403@ericsson.com> Date: Fri, 14 Feb 2014 15:34:09 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Benoit Claise , "ops-area@ietf.org" References: <52FD65DD.4090609@cisco.com> In-Reply-To: <52FD65DD.4090609@cisco.com> Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUyM+JvjW6y5r8ggy/7uS2OPpawWH9wEpsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlXHi0BPmgr9iFd/u32RuYNwg2MXIySEhYCIx 7ck8NghbTOLCvfVANheHkMAJRonzDdfZIZw1jBLtb44wglTxCmhLNDa1s4DYLAKqEjc61oHZ bAJGElP7z4PZogJREj+vLGCHqBeUODnzCVhcRMBP4sz9r2BxZgFHiYMPIGqEBSIlnnTsYQax hQQ0JGa1LAS7iFNAU2LtV4g4s4CuxIX/U1ggbHmJ7W/nwNU/vPCXdQKj4Cwk62YhaZmFpGUB I/MqRsni1OLi3HQjA73c9NwSvdSizOTi4vw8veLUTYzAsD245bfRDsaTe+wPMUpzsCiJ815n rQkSEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLgilmup9ezI3Rdj5pcwu+0tu+d587/z/r+q nHrb2Qy3e2gfNr9VL7Hzqsru5M4lp53U/Q4d3W0l9WuDxbs9Cpb8vDKpE7Y7Wc1c1vPa0q7p VINR8L7LQh9V+v9rpNv1emZI+EsdyEv+L/RjukeJSd/qb4tN3SZOOp0e1xM1o4CzKF7e9cQz FiWW4oxEQy3mouJEAI+0tX8pAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/sTrTPKUzkBDvDxbWisAf-jpHjdc Cc: =?ISO-8859-1?Q?Attila_Mih=E1ly?= Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:34:18 -0000 Hello Benoit,
We have a use case that might end up in an IETF RFC, which involves updating a small set of data very frequently (2 times/sec).
 It is kind of on the border of configuration and SDN/routing.
What would be a good protocol for this purpose? Is it still Netconf, or a custom protocol?
regards Balazs

On 2014-02-14 01:39, Benoit Claise wrote:
Dear all,

We occasionally see read-write MIB module proposals within the IETF.
However, the write capabilities of those MIB modules are rarely implemented.

While discussing this issue with the MIB doctors, we arrive to the conclusion that it's now time to set the direction for future MIB developments within the IETF. Basically, let's not specify read-write MIB modules unless we have a good reason. Read-only MIB modules are still fine though, as SNMP is clearly used for monitoring purposes.

Here is the statement we came up with:
The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, specifically in new charters. SNMP MIB modules modifying persistent configuration state should only be produced by working groups in cases of clear utility
and consensus to use SNMP write operations for configuration.
Ideally, this should become an IESG statement.
Your feedback is most welcome.

Regards, the MIB doctors & Benoit



_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area


-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Fri Feb 14 06:36:41 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4101A0270 for ; Fri, 14 Feb 2014 06:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URTgYnkGDcqs for ; Fri, 14 Feb 2014 06:36:36 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id E8C1E1A0253 for ; Fri, 14 Feb 2014 06:36:35 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CA79DF82; Fri, 14 Feb 2014 15:36:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id q5Zrxm_FArYs; Fri, 14 Feb 2014 15:36:33 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Fri, 14 Feb 2014 15:36:33 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id EEFD720014; Fri, 14 Feb 2014 15:36:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2qhaW4PG3BmD; Fri, 14 Feb 2014 15:36:32 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6EA8320013; Fri, 14 Feb 2014 15:36:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 55D6A2B4DFCD; Fri, 14 Feb 2014 15:36:31 +0100 (CET) Date: Fri, 14 Feb 2014 15:36:31 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20140214143631.GC88879@elstar.local> Mail-Followup-To: Balazs Lengyel , Benoit Claise , "ops-area@ietf.org" , Attila =?iso-8859-1?Q?Mih=E1ly?= References: <52FD65DD.4090609@cisco.com> <52FE2961.4040403@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52FE2961.4040403@ericsson.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/ySPoHuD3iI3ObsUlFb_tCbxv90I Cc: Attila =?iso-8859-1?Q?Mih=E1ly?= , "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:36:38 -0000 On Fri, Feb 14, 2014 at 03:34:09PM +0100, Balazs Lengyel wrote: > Hello Benoit, > We have a use case that might end up in an IETF RFC, which involves > updating a small set of data very frequently (2 times/sec). > It is kind of on the border of configuration and SDN/routing. > What would be a good protocol for this purpose? Is it still Netconf, or a > custom protocol? Are the updates persistent or are you modifying operational state? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Feb 14 06:37:47 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2021C1A0284 for ; Fri, 14 Feb 2014 06:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jo2fuN7naLHA for ; Fri, 14 Feb 2014 06:37:42 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBB81A0283 for ; Fri, 14 Feb 2014 06:37:38 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-31-52fe2a30ff15 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id CB.DF.04853.03A2EF25; Fri, 14 Feb 2014 15:37:37 +0100 (CET) Received: from [159.107.198.10] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.2.347.0; Fri, 14 Feb 2014 15:37:36 +0100 Message-ID: <52FE2A30.2070708@ericsson.com> Date: Fri, 14 Feb 2014 15:37:36 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Benoit Claise , "ops-area@ietf.org" , =?ISO-8859-1?Q?Attila_Mih=E1ly?= References: <52FD65DD.4090609@cisco.com> <52FE2961.4040403@ericsson.com> <20140214143631.GC88879@elstar.local> In-Reply-To: <20140214143631.GC88879@elstar.local> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnluLIzCtJLcpLzFFi42KZGfG3RtdQ61+QwfXHXBZHH0tYrD84ic2B yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgyvi77gx7wX62ih0v3zI1MN5i6WLk4JAQMJF4 fle4i5ETyBSTuHBvPRuILSRwglHiw3a/LkYuIHsNo8Tlab+ZQBK8AtoSJ6feBytiEVCVmHn+ IAuIzSZgJDG1/zyYLSoQJfHzygJ2iHpBiZMzn4DFRQQmMkrcOlEKYgsLREo86djDDLEsT6J/ 5i0mkHs4geYc2WsKEmYWsJW4MOc6C4QtL7H97Ryocg2Jhxf+sk5gFJiFZMMsJC2zkLQsYGRe xShZnFpcnJtuZKCXm55bopdalJlcXJyfp1ecuokRGJgHt/w22sF4co/9IUZpDhYlcd7rrDVB QgLpiSWp2ampBalF8UWlOanFhxiZODilGhhjgk0OX4ufGrBolonVxcSu+FVTbKV3PQ6Y/4W/ /JHs5KaZcplTdgt84Tc9n/smvey48JO3uXPa5PnNPUv2x/+TduyvM+U+LbtcfeYlhuMcgbVe sd/ss0t/mLLuP/LMeJJzt4/k8ZM7pN3O5xR1h07Z2jKnqWGmrzF/6feQCGPXhdOjz8p7PVdi Kc5INNRiLipOBADf3eeaGgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/RUfxw59KG5NkjRfGwLeqVm9X25k Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:37:44 -0000 The updates are not persistent, they are operational state. Balazs On 2014-02-14 15:36, Juergen Schoenwaelder wrote: > On Fri, Feb 14, 2014 at 03:34:09PM +0100, Balazs Lengyel wrote: >> Hello Benoit, >> We have a use case that might end up in an IETF RFC, which involves >> updating a small set of data very frequently (2 times/sec). >> It is kind of on the border of configuration and SDN/routing. >> What would be a good protocol for this purpose? Is it still Netconf, or a >> custom protocol? > Are the updates persistent or are you modifying operational state? > > /js > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Fri Feb 14 06:56:26 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC211A0292 for ; Fri, 14 Feb 2014 06:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu1cd9B-Ac9b for ; Fri, 14 Feb 2014 06:56:23 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id F208B1A022E for ; Fri, 14 Feb 2014 06:56:22 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 66680240C1F1; Fri, 14 Feb 2014 15:56:10 +0100 (CET) Date: Fri, 14 Feb 2014 15:55:59 +0100 (CET) Message-Id: <20140214.155559.287645408.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <52FE2A30.2070708@ericsson.com> References: <52FE2961.4040403@ericsson.com> <20140214143631.GC88879@elstar.local> <52FE2A30.2070708@ericsson.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/XWFIcwXRm-Ma0gvFG_oZoMnWrDA Cc: attila.mihaly@ericsson.com, ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:56:25 -0000 Balazs Lengyel wrote: > The updates are not persistent, they are operational state. If you want to model your data in a MIB, it seems SNMP works fine for this use case. If you want to model your data in YANG, a "custom rpc" can be defined for the data modification, and NETCONF or RESTCONF can be used to invoke the custom rpc. /martin > Balazs > > On 2014-02-14 15:36, Juergen Schoenwaelder wrote: > > On Fri, Feb 14, 2014 at 03:34:09PM +0100, Balazs Lengyel wrote: > >> Hello Benoit, > >> We have a use case that might end up in an IETF RFC, which involves > >> updating a small set of data very frequently (2 times/sec). > >> It is kind of on the border of configuration and SDN/routing. > >> What would be a good protocol for this purpose? Is it still Netconf, or a > >> custom protocol? > > Are the updates persistent or are you modifying operational state? > > > > /js > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > System Manager > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > From nobody Fri Feb 14 06:59:29 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200081A02A2 for ; Fri, 14 Feb 2014 06:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnh46EOqSkos for ; Fri, 14 Feb 2014 06:59:26 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 150121A022E for ; Fri, 14 Feb 2014 06:59:26 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 597F1F83; Fri, 14 Feb 2014 15:59:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id CeuP9WhKnXh4; Fri, 14 Feb 2014 15:59:23 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Fri, 14 Feb 2014 15:59:19 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C7BFA2002D; Fri, 14 Feb 2014 15:58:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id W3BhYf2Y0068; Fri, 14 Feb 2014 15:58:20 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 55A362002B; Fri, 14 Feb 2014 15:58:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8946F2B4E1AF; Fri, 14 Feb 2014 15:58:18 +0100 (CET) Date: Fri, 14 Feb 2014 15:58:18 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20140214145818.GA89076@elstar.local> Mail-Followup-To: Balazs Lengyel , Benoit Claise , "ops-area@ietf.org" , Attila =?iso-8859-1?Q?Mih=E1ly?= References: <52FD65DD.4090609@cisco.com> <52FE2961.4040403@ericsson.com> <20140214143631.GC88879@elstar.local> <52FE2A30.2070708@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52FE2A30.2070708@ericsson.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/5gRQPGaKGO4gv7ZWfMcGyCaCrq0 Cc: Attila =?iso-8859-1?Q?Mih=E1ly?= , "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:59:28 -0000 On Fri, Feb 14, 2014 at 03:37:36PM +0100, Balazs Lengyel wrote: > The updates are not persistent, they are operational state. The statement starting this thread was primarily about persistent configuration state. And the basic NETCONF options do not modify operational state, as you know (but of course one can add new RPCs). But you asked Benoit, so I will let him answer. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Feb 14 07:00:07 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58181A0292 for ; Fri, 14 Feb 2014 07:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kW0P0vOM72kV for ; Fri, 14 Feb 2014 07:00:03 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id DF62B1A022E for ; Fri, 14 Feb 2014 07:00:02 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta10.westchester.pa.mail.comcast.net with comcast id SCzJ1n0021wpRvQ5AF013m; Fri, 14 Feb 2014 15:00:01 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta18.westchester.pa.mail.comcast.net with comcast id SF001n01B2yZEBF3eF01Ec; Fri, 14 Feb 2014 15:00:01 +0000 From: "ietfdbh" To: "'Juergen Schoenwaelder'" , "'Dave Thaler'" References: <52FD65DD.4090609@cisco.com> <20140214084617.GB87344@elstar.local> In-Reply-To: <20140214084617.GB87344@elstar.local> Date: Fri, 14 Feb 2014 09:59:57 -0500 Message-ID: <008101cf2995$6daddb10$49099130$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxxz5juTd3n7gDSXffXOKa4rE1VAKG/UfEAfZqOTqaS5tBAA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392390001; bh=NPnyCBvu9YWsc4+Fi3HEzcZWmaF2Tpe3cg1uZgDA234=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=G68hDsAZWXl3IkrTMQgmp8Hw48Psn5rkfihEpW2kFWYSyKIun+wu2/HTbUjG9v7IL Y7L41h36KMl3/jlnFl3aVd5+u9LwTAsyosSgjh/qtEHWQgv+EQQtdoI6imY9+TBkL+ y/YHiEoSAIfS4z3BoGYeq+V5p4Uuj/5vuV7VWIahRVYlFtAAwf/42YRB3E8XiO0X6M PFjW+Dw88OStCd9EBBLQ9U7qYbZA07xdRsKijprfpxGKiVbOmhDbSLMsjZVwKAykEe DDQFJD8v80LOFACgkdgAvfY1cb2On7IFWle84NajCRLcVOM2Ssmm7evus9myxrUi5+ ZZvgyYa/muC0Q== Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/RASfru7omdOhzANDs_KACb1I4wA Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:00:06 -0000 Hi, I agree we could provide some guidance on notification/logging mechanisms. Here's how I see things: The Syslog community insisted on maintaining the freeform text fields when the IETF developed a standardized message format. The Syslog WG developed the SDE format to provide more structured and standardized data to supplement the freeform text. There have been few SDEs standardized in the IETF, and they tend to be singletons rather than cohesive data models. Since humans are good at interpreting freeform text, but applications typically have difficulty with freeform text, Syslog is good for uses where a human will be looking at the messages. Sys-logs can be filtered by priority and word-matching techniques to lessen the onerous task of finding relevant messages in the stream, but it comes down to human review and interpretation, typically at the device/endpoint level. I don't work with ipfix, but had some experience with one of the candidate protocols that led to ipfix. My impression of ipfix is that it is really better at three major things than SNMP and Syslog: 1) capturing and reporting large quantities of potentially short-lived data, such as the creation and deletion of IP flows or NAT bindings, and 2) offloading large amounts of data quickly and reliably, since it works over streaming sessions, and 3) efficiency, since it uses templates rather than self-identifying varbinds or full syslog messages, cutting message overhead. SNMP provides standardized objects organized into data models using OIDs, that can be hard for operators to understand, but easier for applications to process. SNMP applications can correlate standardized data models across multiple devices, can initiate a poll in response to a notification to get more information, and can correlate notifications with polled information (often including historic polled data). SNMP applications can also act upon its data analysis by automated modification of configurations using RW objects, where supported. SNMP notifications end up being useful for large-scale automated management, and for network management applications rather than just device management applications, because SNMP is not only notification/logging, but an integrated package of notification/logging + polling + cohesive data models consistent across vendors + (where available) automatable SET capability. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Friday, February 14, 2014 3:46 AM > To: Dave Thaler > Cc: ops-area@ietf.org > Subject: Re: [OPS-AREA] configuration: writable MIB modules versus > NETCONF/YANG modules > > On Fri, Feb 14, 2014 at 06:39:00AM +0000, Dave Thaler wrote: > > > As a chair of WGs outside the OPS area, I'd still like to see > > additional guidance around notification/logging mechanisms as well > > (IPFIX vs Syslog vs SNMP traps/informs, etc.) > > This is much harder. Here is how I see things: > > IPFIX works well for large amounts of notification/logging data that > has a common structure, i.e. you get things reported with a few IPFIX > templates. SYSLOG works well with semi-structured data - traditionally > there was very little common structure and the value was in the > free-form text field. SNMP again works with structured data that is > defined in data models (which is different from many IPFIX templates > that IPFIX data processors are expected to discover at runtime, > although I am aware of I-Ds trying to nail down IPFIX templates). > > Both, SYSLOG and SNMP notifications have seen many years of wide > spread deployment, IPFIX for notification/logging is more a new kid on > the block. IPFIX may have nice performance characteristics but most > management systems I have seen support SNMP notifications and/or > SYSLOG messages to extract notification/logging data but not IPFIX. I > believe what is widely deployed today (and feel free to prove me > wrong) is largely SYSLOG and SNMP for notification/logging data. > > What I am saying here is that the situation is less clear cut compared > to SNMP for persistent configuration. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area From nobody Fri Feb 14 07:07:13 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2F41A027F for ; Fri, 14 Feb 2014 07:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7r1xsPNPMUZ for ; Fri, 14 Feb 2014 07:07:04 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0012.outbound.protection.outlook.com [213.199.154.12]) by ietfa.amsl.com (Postfix) with ESMTP id 35FE41A0260 for ; Fri, 14 Feb 2014 07:07:04 -0800 (PST) Received: from AMXPRD0111HT002.eurprd01.prod.exchangelabs.com (157.56.250.117) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.0.878.16; Fri, 14 Feb 2014 15:07:01 +0000 Message-ID: <028e01cf2995$bef7a3c0$4001a8c0@gateway.2wire.net> From: t.petch To: Benoit Claise , References: <52FD65DD.4090609@cisco.com> Date: Fri, 14 Feb 2014 15:02:06 +0000 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.250.117] X-ClientProxiedBy: AM3PR07CA009.eurprd07.prod.outlook.com (10.242.16.49) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) X-Forefront-PRVS: 01221E3973 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(377454003)(51704005)(13464003)(47736001)(87266001)(44736004)(50226001)(69226001)(74662001)(47446002)(74502001)(87286001)(23756003)(77982001)(76786001)(49866001)(47976001)(50986001)(74366001)(19580405001)(19580395003)(74706001)(85306002)(80976001)(76796001)(4396001)(31966008)(83322001)(77156001)(50466002)(14496001)(56776001)(54316002)(53806001)(95666001)(46102001)(74876001)(59766001)(94316002)(51856001)(76482001)(95416001)(42186004)(47776003)(84392001)(63696002)(87976001)(62966002)(81542001)(61296002)(92566001)(86362001)(56816005)(90146001)(89996001)(88136002)(81342001)(92726001)(93516002)(94946001)(93916002)(80022001)(65816001)(93136001)(77096001)(79102001)(33646001)(85852003)(561944002)(44716002)(66066001)(62236002)(83072002)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB049; H:AMXPRD0111HT002.eurprd01.prod.exchangelabs.com; CLIP:157.56.250.117; FPR:E8E6F035.9FD39DDA.31D59FBF.46E60170.20300; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/smggwxV0aABN7i10z3YCTQGGU4I Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANGmodules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:07:08 -0000 ----- Original Message ----- From: "Benoit Claise" To: Sent: Friday, February 14, 2014 12:39 AM > Dear all, > > We occasionally see read-write MIB module proposals within the IETF. > However, the write capabilities of those MIB modules are rarely implemented. > > While discussing this issue with the MIB doctors, we arrive to the > conclusion that it's now time to set the direction for future MIB > developments within the IETF. Basically, let's not specify read-write > MIB modules unless we have a good reason. Read-only MIB modules are > still fine though, as SNMP is clearly used for monitoring purposes. > > Here is the statement we came up with: > > The OPS area recommends the use of NETCONF/YANG standards for > configuration. IETF working groups are therefore encouraged to use > the NETCONF/YANG standards for configuration, specifically in new > charters. SNMP MIB modules modifying persistent configuration state > should only be produced by working groups in cases of clear utility > and consensus to use SNMP write operations for configuration. > > Ideally, this should become an IESG statement. > Your feedback is most welcome. You probably know that there is currently a consensus call in progress over "Please indicate Support or Oppose for this MIB (draft-ietf-mpls-tp-te-mib) to be read-only." and I was pleasantly surprised to see opposition, albeit with one opponent later changing their mind (perhaps they were sat on from a height:-). I don't see much sign of Netxxxx in the mpls arena but there is a need there for configuration, since there need not be a control plane to set things up. Perhaps writable MIB modules will still be with us in the distant future in some corners of the Internet.. Ideally, this idea would be fleshed out in an I-D. Tom Petch > Regards, the MIB doctors & Benoit From nobody Fri Feb 14 07:12:50 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672161A02BD for ; Fri, 14 Feb 2014 07:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZzpHXDHvhtf for ; Fri, 14 Feb 2014 07:12:43 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id AD2ED1A02C1 for ; Fri, 14 Feb 2014 07:12:43 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id k4so18737778qaq.29 for ; Fri, 14 Feb 2014 07:12:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=0bSkHr5awLHwpJApot3AT3qEPV5gThBB2AzaigGC41E=; b=by/WN7k64430VB5st9RfpgDncG8BwTklpQ4oZQLJvSHPRJcNoRNXtej0HdxK1QyLY9 xLvwNXOTOfHfh2tfDb3Q4Ee6hoZq2tXPddoApiRlvHnJcb/FK8xyWYmFAWKQz/coNqWs HLRddr9dwFh6sLc0nPNRWrdpuTxVOddHEG2yshWkjjxuP2EkhKxVap50Q5YgWKEYMikp yofzEhqHvZLRaRTgABhMHXIm9fm5Dx5QPA3OnvjCfXV3NPkOIg+8fP770ZORU6/WGN4i 0IM9+E/s3j4EHXtmYShZ+MW8VkP5gKt9ZkvYy+Ivky6DPoQoGQv6vxl6LtOGcekYfw2q q/PA== X-Gm-Message-State: ALoCoQmHUVmkFAfipnvxBZ1GdXazEcEN8aXSm44T2pD2LMwz0KPwdfxXBxh9cFh1YX3qR1R5I2OT MIME-Version: 1.0 X-Received: by 10.140.85.179 with SMTP id n48mr12824102qgd.91.1392390761938; Fri, 14 Feb 2014 07:12:41 -0800 (PST) Received: by 10.140.28.2 with HTTP; Fri, 14 Feb 2014 07:12:41 -0800 (PST) X-Originating-IP: [98.234.99.22] Date: Fri, 14 Feb 2014 07:12:41 -0800 Message-ID: From: David Meyer To: Benoit Claise Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/VniEsw-Q-eH-TMDgKfZXi0gRAAw Cc: ops-area@ietf.org Subject: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:12:46 -0000 >> Dear all, >> >> We occasionally see read-write MIB module proposals within the IETF. >> However, the write capabilities of those MIB modules are rarely >> implemented. >> >> While discussing this issue with the MIB doctors, we arrive to the >> conclusion that it's now time to set the direction for future MIB >> developments within the IETF. Basically, let's not specify read-write >> MIB modules unless we have a good reason. Read-only MIB modules >> are still fine though, as SNMP is clearly used for monitoring purposes. >> >> Here is the statement we came up with: >> >> The OPS area recommends the use of NETCONF/YANG standards for >> configuration. IETF working groups are therefore encouraged to use the >> NETCONF/YANG standards for configuration, specifically in new >> charters. SNMP MIB modules modifying persistent configuration state >> should only be produced by working groups in cases of clear utility >> and consensus to use SNMP write operations for configuration. >> I>> deally, this should become an IESG statement. >> Your feedback is most welcome. >> >> Regards, the MIB doctors & Benoit Eminently reasonable and needed. +1 --dmm From nobody Fri Feb 14 07:19:28 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EAF1A0292 for ; Fri, 14 Feb 2014 07:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPo6SNats_Mq for ; Fri, 14 Feb 2014 07:19:23 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7CF1A0253 for ; Fri, 14 Feb 2014 07:19:22 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N0Z003J5RW47W@tid.hi.inet> for ops-area@ietf.org; Fri, 14 Feb 2014 16:19:16 +0100 (MET) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id A8.BD.03314.4F33EF25; Fri, 14 Feb 2014 16:19:16 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N0Z003J1RW47W@tid.hi.inet> for ops-area@ietf.org; Fri, 14 Feb 2014 16:19:16 +0100 (MET) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.201]) by EX10-HTCAS7-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 16:19:16 +0100 Date: Fri, 14 Feb 2014 15:19:15 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.64.115] To: "ops-area@ietf.org" Message-id: <54A2C027-3481-45D3-ABCE-FD3A6C2B7086@tid.es> Content-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules Thread-index: AQHPKZdAkyA+/qSJOkKnPs+CBUryuZq0zIsA X-AuditID: 0a5f4068-b7fe58e000000cf2-2a-52fe33f484ad X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsXCFe/ApfvF+F+QwcUNShbrD05ic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtXtDawFJ0QqFv/6yNjA2CLSxcjJISFgIrG6exkbhC0mceHe eiCbi0NI4ACjxPav21ggnF+MEq1dt6CcmYwSTzctYwZpYRFQlXh1uRWsnQ3IftT8mx3EFhaI lHjSsQeohoODUyBY4tZLTYgNChJ/zj1mAbFFBLQlrj2eDtbKK2ApsWXdM0YQm1nATOL64dfM EHFBiR+T77GAjGEWUJeYMiUXokRcorn1JguErSgxbVEDWCujgKzEu/nzWSHGR0lMalrDCGEb SWz8d4EV4gQBiSV7zjND2KISLx//A4sLCQRIzNw5n2UCo/gsJFfMQnLFLIQrZiG5YhaSKxYw sq5iFCtOKspMzyjJTczMSTcw1MvI1MvMSy3ZxAiJrYwdjMt3qhxiFOBgVOLhldD9FyTEmlhW XJl7iFGCg1lJhPeUBFCINyWxsiq1KD++qDQntfgQIxMHp1QDY9HXRD0Ta77v7Tbbm9yKV17o 3VHI7vV7idejlxrVWp+zWBjLN/u/aWBxfeV2Mjm+c6965EMLp63M6c85oxbuSD60oPlaX4RD H7PXdY2FFb9V9+YnbizgnbEwd9fU7/9jmbbnW9wUTnL/nPZDgvPv1uN5Z1o/iM3oiX85Udx2 86XXDzgZSn/+UmIpzkg01GIuKk4EABuOAdaLAgAA References: Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/lW3ZoDcV1LwccNoRMgB9jtw4J10 Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:19:26 -0000 DQpPbiAxNCBGZWIgMjAxNCwgYXQgMTY6MTIgLCBEYXZpZCBNZXllciA8ZG1tQDEtNC01Lm5ldD4g d3JvdGU6DQo+Pj4gRGVhciBhbGwsDQo+Pj4NCj4+PiBXZSBvY2Nhc2lvbmFsbHkgc2VlIHJlYWQt d3JpdGUgTUlCIG1vZHVsZSBwcm9wb3NhbHMgd2l0aGluIHRoZSBJRVRGLg0KPj4+IEhvd2V2ZXIs IHRoZSB3cml0ZSBjYXBhYmlsaXRpZXMgb2YgdGhvc2UgTUlCIG1vZHVsZXMgYXJlIHJhcmVseQ0K Pj4+IGltcGxlbWVudGVkLg0KPj4+DQo+Pj4gV2hpbGUgZGlzY3Vzc2luZyB0aGlzIGlzc3VlIHdp dGggdGhlIE1JQiBkb2N0b3JzLCB3ZSBhcnJpdmUgdG8gdGhlDQo+Pj4gY29uY2x1c2lvbiB0aGF0 IGl0J3Mgbm93IHRpbWUgdG8gc2V0IHRoZSBkaXJlY3Rpb24gZm9yIGZ1dHVyZSBNSUINCj4+PiBk ZXZlbG9wbWVudHMgd2l0aGluIHRoZSBJRVRGLiBCYXNpY2FsbHksIGxldCdzIG5vdCBzcGVjaWZ5 IHJlYWQtd3JpdGUNCj4+PiBNSUIgbW9kdWxlcyB1bmxlc3Mgd2UgaGF2ZSBhIGdvb2QgcmVhc29u LiBSZWFkLW9ubHkgTUlCIG1vZHVsZXMNCj4+PiBhcmUgc3RpbGwgZmluZSB0aG91Z2gsIGFzIFNO TVAgaXMgY2xlYXJseSB1c2VkIGZvciBtb25pdG9yaW5nIHB1cnBvc2VzLg0KPj4+DQo+Pj4gSGVy ZSBpcyB0aGUgc3RhdGVtZW50IHdlIGNhbWUgdXAgd2l0aDoNCj4+Pg0KPj4+IFRoZSBPUFMgYXJl YSByZWNvbW1lbmRzIHRoZSB1c2Ugb2YgTkVUQ09ORi9ZQU5HIHN0YW5kYXJkcyBmb3INCj4+PiBj b25maWd1cmF0aW9uLiBJRVRGIHdvcmtpbmcgZ3JvdXBzIGFyZSB0aGVyZWZvcmUgZW5jb3VyYWdl ZCB0byB1c2UgdGhlDQo+Pj4gTkVUQ09ORi9ZQU5HIHN0YW5kYXJkcyBmb3IgY29uZmlndXJhdGlv biwgc3BlY2lmaWNhbGx5IGluIG5ldw0KPj4+IGNoYXJ0ZXJzLiBTTk1QIE1JQiBtb2R1bGVzIG1v ZGlmeWluZyBwZXJzaXN0ZW50IGNvbmZpZ3VyYXRpb24gc3RhdGUNCj4+PiBzaG91bGQgb25seSBi ZSBwcm9kdWNlZCBieSB3b3JraW5nIGdyb3VwcyBpbiBjYXNlcyBvZiBjbGVhciB1dGlsaXR5DQo+ Pj4gYW5kIGNvbnNlbnN1cyB0byB1c2UgU05NUCB3cml0ZSBvcGVyYXRpb25zIGZvciBjb25maWd1 cmF0aW9uLg0KPj4+DQo+IEk+PiBkZWFsbHksIHRoaXMgc2hvdWxkIGJlY29tZSBhbiBJRVNHIHN0 YXRlbWVudC4NCj4+PiBZb3VyIGZlZWRiYWNrIGlzIG1vc3Qgd2VsY29tZS4NCj4+Pg0KPj4+IFJl Z2FyZHMsIHRoZSBNSUIgZG9jdG9ycyAmIEJlbm9pdA0KPg0KPiBFbWluZW50bHkgcmVhc29uYWJs ZSBhbmQgbmVlZGVkLg0KPg0KPiArMQ0KDQpJbmRlZWQhDQoNCisxIGFzIHdlbGwNCi0tDQoiRXN0 YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bl eg0KVGVsZWZvbmljYSBJK0QNCmh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6Lw0KDQpl LW1haWw6IGRpZWdvQHRpZC5lcw0KVGVsOiAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogKzM0 IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSBzZSBk aXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBu dWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLD s25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBpcyBp bnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCBy ZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdDoNCmh0dHA6 Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQo= From nobody Fri Feb 14 07:20:41 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C7B1A02A7 for ; Fri, 14 Feb 2014 07:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4s3F1QDrceW3 for ; Fri, 14 Feb 2014 07:20:37 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 33AE81A02A8 for ; Fri, 14 Feb 2014 07:20:31 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-a0-52fe343d8711 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 6E.AA.04249.D343EF25; Fri, 14 Feb 2014 16:20:29 +0100 (CET) Received: from [159.107.198.10] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.2.347.0; Fri, 14 Feb 2014 16:20:28 +0100 Message-ID: <52FE343C.9060804@ericsson.com> Date: Fri, 14 Feb 2014 16:20:28 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Diego R. Lopez" , "ops-area@ietf.org" References: <54A2C027-3481-45D3-ABCE-FD3A6C2B7086@tid.es> In-Reply-To: <54A2C027-3481-45D3-ABCE-FD3A6C2B7086@tid.es> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvja6tyb8gg2kP+C1WTrrLbrH+4CQ2 ByaPJUt+Mnk8+buFOYApissmJTUnsyy1SN8ugSujY81t5oJHQhU397cyNTC283cxcnJICJhI XNjzjgnCFpO4cG89WxcjF4eQwBFGiVX7VkE5axglVpw/wQZSxSugLbFzXicLiM0ioCrRsmER I4jNJmAkMbX/PFhcVCBK4ueVBewQ9YISJ2c+AYuLCPhIrJ37FswWFoiUeNKxhxnEFhKok1i4 /BqYzSlgJfG4+Q+YzSxgIbH4zUF2CFteonnrbKh6DYmHF/6yTmAUmIVkxSwkLbOQtCxgZF7F yFGcWpyUm25ksIkRGH4Ht/y22MF4+a/NIUZpDhYlcd6Pb52DhATSE0tSs1NTC1KL4otKc1KL DzEycXBKNTAetmNyXneJPbR53bMe1twMg6MfmPwbX/1l2Ljyg2vVyWusLPe3PRC9lZWqeiZu cbqkd5ejvkTE1d1bZkzaUd4dkdy6RK17mUHLjm/ivNdXP7geW6uew8K213ztFDPZiRX8Oa8D 9Tt+/vXrSjnU/JpLdMvpW21TksO7Q5g+tic+5SyYcvHsrRwlluKMREMt5qLiRAB+dtKuDQIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/4f8r2Oq8E0mOKFjfyYzgLY7ciK0 Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:20:40 -0000 +1 Balazs On 2014-02-14 16:19, Diego R. Lopez wrote: > On 14 Feb 2014, at 16:12 , David Meyer wrote: >>>> Dear all, >>>> >>>> We occasionally see read-write MIB module proposals within the IETF. >>>> However, the write capabilities of those MIB modules are rarely >>>> implemented. >>>> >>>> While discussing this issue with the MIB doctors, we arrive to the >>>> conclusion that it's now time to set the direction for future MIB >>>> developments within the IETF. Basically, let's not specify read-write >>>> MIB modules unless we have a good reason. Read-only MIB modules >>>> are still fine though, as SNMP is clearly used for monitoring purposes. >>>> >>>> Here is the statement we came up with: >>>> >>>> The OPS area recommends the use of NETCONF/YANG standards for >>>> configuration. IETF working groups are therefore encouraged to use the >>>> NETCONF/YANG standards for configuration, specifically in new >>>> charters. SNMP MIB modules modifying persistent configuration state >>>> should only be produced by working groups in cases of clear utility >>>> and consensus to use SNMP write operations for configuration. >>>> >> I>> deally, this should become an IESG statement. >>>> Your feedback is most welcome. >>>> >>>> Regards, the MIB doctors & Benoit >> Eminently reasonable and needed. >> >> +1 > Indeed! > > +1 as well > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: diego@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. > This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Fri Feb 14 07:24:51 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E3F1A0242 for ; Fri, 14 Feb 2014 07:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDEgANZi6a_w for ; Fri, 14 Feb 2014 07:24:46 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC3A1A0284 for ; Fri, 14 Feb 2014 07:24:45 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta14.westchester.pa.mail.comcast.net with comcast id SEUb1n0070Fqzac5EFQjy9; Fri, 14 Feb 2014 15:24:43 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta08.westchester.pa.mail.comcast.net with comcast id SFQj1n0012yZEBF3UFQjZM; Fri, 14 Feb 2014 15:24:43 +0000 From: "ietfdbh" To: "'Balazs Lengyel'" , "'Benoit Claise'" , References: <52FD65DD.4090609@cisco.com> <52FE2961.4040403@ericsson.com> In-Reply-To: <52FE2961.4040403@ericsson.com> Date: Fri, 14 Feb 2014 10:24:39 -0500 Message-ID: <008501cf2998$e1163310$a3429930$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0086_01CF296E.F8424DF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxxz5juTd3n7gDSXffXOKa4rE1VAKy/48hmloFzEA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392391483; bh=9JlXIcuZN/Gu3vrQPbdZvVTN4Z+giNhZfVeAZkGG4sc=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=AuocQ8R8d7mnA0BE/2Zt7RHvyKdRWU+qM3J4+8PzNMZzVc9hZok8ezBcHHkgeuyDK 49JOe9uPqVU8RlDr1D4lqw9KWh/gKZhuDVscrbnmv4+RwGnEmebFVJCVU6tPsGPtQ7 MKotkmMLXujnQEuRHVx1+x9fHyVMcQ/syc6ofDadHXbBxKxl645sAeoVp+zU+HuhJZ 4rCEEZGpy1OqgRxukojT10sIxpVfl+YZVosGV/QMcy6EYL5CK3uYYQzw6QH6x+BZzu 4kbU25m4E3xZPj1DWuGSsYE+vXO8ujkvbsb6axiw8gy+0HyHNRQcQ2Q2m2Nw1kXbqm dpi0iJtjErKDQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/C1m_nBHKbs2NaVFGvYJED0ByOYk Cc: =?iso-8859-1?Q?'Attila_Mih=E1ly'?= Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:24:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0086_01CF296E.F8424DF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 If it is a small set of operational data that needs updating, and if you want acknowledgement of the change at the receiver, then SNMP SET might = meet your needs, if the targeted environments support SNMP SET. If you only = need acknowledgement of the receipt of the update message, then SNMP Inform = might meet your needs.=20 =20 However, if this is updating routing information, then you might do = better to NOT use a layer 7 management protocol like Netconf or SNMP, but a = routing layer protocol to distribute such updates. =20 If you develop a custom protocol, then you are faced with getting that protocol implemented and deployed before the solution can be useful. A custom protocol might be a viable scenario for a solution that works = only within a single vendor=92s ecosystem, but is likely to be problematic in = a heterogeneous network, until the protocol is supported across multiple vendors=92 products. You might want to rethink the problem to make it = fit into an existing implemented and deployed infrastructure, such as SNMP or = Netconf or standard routing protocols. =20 Without more information (and I am not requesting that you turn this = thread into a discussion of your proposal), it is hard to provide advice. Why don=92t you start a separate thread by posting a pointer to a = relevant internet-draft, and ask what would be appropriate for that use case? =20 David Harrington ietfdbh@comcast.net +1-603-828-1401 From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Balazs Lengyel Sent: Friday, February 14, 2014 9:34 AM To: Benoit Claise; ops-area@ietf.org Cc: Attila Mih=E1ly Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules =20 Hello Benoit, We have a use case that might end up in an IETF RFC, which involves = updating a small set of data very frequently (2 times/sec). It is kind of on the border of configuration and SDN/routing. What would be a good protocol for this purpose? Is it still Netconf, or = a custom protocol? regards Balazs On 2014-02-14 01:39, Benoit Claise wrote: Dear all, We occasionally see read-write MIB module proposals within the IETF. However, the write capabilities of those MIB modules are rarely = implemented. While discussing this issue with the MIB doctors, we arrive to the conclusion that it's now time to set the direction for future MIB developments within the IETF. Basically, let's not specify read-write = MIB modules unless we have a good reason. Read-only MIB modules are still = fine though, as SNMP is clearly used for monitoring purposes. Here is the statement we came up with: The OPS area recommends the use of NETCONF/YANG standards for = configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, specifically in new charters. SNMP MIB = modules modifying persistent configuration state should only be produced by = working groups in cases of clear utility=20 and consensus to use SNMP write operations for configuration. Ideally, this should become an IESG statement. Your feedback is most welcome. Regards, the MIB doctors & Benoit _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area --=20 Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com=20 ------=_NextPart_000_0086_01CF296E.F8424DF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

If it is a small set of operational data that needs updating, and if = you want acknowledgement of the change at the receiver, then SNMP SET = might meet your needs, if the targeted environments support SNMP SET. If = you only need acknowledgement of the receipt of the update message, then = SNMP Inform might meet your needs.

 

However, if this is updating routing information, then you might do = better to NOT use a layer 7 management protocol like Netconf or SNMP, = but a routing layer protocol to distribute such = updates.

 

If you develop a custom protocol, then you are faced with getting = that protocol implemented and deployed before the solution can be = useful. A custom protocol might be a viable scenario for a solution that = works only within a single vendor’s ecosystem, but is likely to be = problematic in a heterogeneous network, until the protocol is supported = across multiple vendors’ products. You might want to rethink the = problem to make it fit into an existing implemented and deployed = infrastructure, such as SNMP or Netconf or standard routing = protocols.

 

Without more information (and I am not requesting that you turn this = thread into a discussion of your proposal), it is hard to provide = advice.

Why don’t you start a separate thread by posting a pointer to a = relevant internet-draft, and ask what would be appropriate for that use = case?

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of = Balazs Lengyel
Sent: Friday, February 14, 2014 9:34 = AM
To: Benoit Claise; ops-area@ietf.org
Cc: Attila = Mih=E1ly
Subject: Re: [OPS-AREA] configuration: writable MIB = modules versus NETCONF/YANG modules

 

Hello Benoit,
We have a use case that = might end up in an IETF RFC, which involves updating a small set of data = very frequently (2 times/sec).
 It is kind of on the border of = configuration and SDN/routing.
What would be a good protocol for this = purpose? Is it still Netconf, or a custom protocol?
regards = Balazs

On 2014-02-14 01:39, = Benoit Claise wrote:

Dear = all,

We occasionally see read-write MIB module proposals within = the IETF.
However, the write capabilities of those MIB modules are = rarely implemented.

While discussing this issue with the MIB = doctors, we arrive to the conclusion that it's now time to set the = direction for future MIB developments within the IETF. Basically, let's = not specify read-write MIB modules unless we have a good reason. = Read-only MIB modules are still fine though, as SNMP is clearly used for = monitoring purposes.

Here is the statement we came up = with:

The OPS area recommends the use = of NETCONF/YANG standards for configuration. IETF working groups are = therefore encouraged to use the NETCONF/YANG standards for = configuration, specifically in new charters. SNMP MIB modules modifying = persistent configuration state should only be produced by working groups = in cases of clear utility
and consensus to use SNMP write operations = for configuration.

Ideally, this = should become an IESG statement.
Your feedback is most = welcome.

Regards, the MIB doctors & = Benoit




___________________________=
____________________
OPS-AREA mailing =
list
OPS-AREA@ietf.org
<= pre>https://www.ietf.= org/mailman/listinfo/ops-area



-- =

Balazs =
Lengyel=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 Ericsson Hungary Ltd.
System =
Manager
ECN: 831 =
7320=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 Tel: +36-1-437-7320
Mobile: =
+36-70-330-7909=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 email: Balazs.Lengyel@ericsson.com
------=_NextPart_000_0086_01CF296E.F8424DF0-- From nobody Fri Feb 14 10:27:46 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B007B1A03DA for ; Fri, 14 Feb 2014 10:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5T_kIcK0HUX for ; Fri, 14 Feb 2014 10:27:40 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5D35D1A03DC for ; Fri, 14 Feb 2014 10:27:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=QVIg7lBwDybf1a6L3d+ezQsCni4bM3F+ILgVhHV81GENIjv/SXlHMhbUE+PKUbTN; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanTower) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WENU9-0001Dy-EH; Fri, 14 Feb 2014 13:27:37 -0500 From: "Joan Cucchiara" To: "'t.petch'" , "'Benoit Claise'" , References: <52FD65DD.4090609@cisco.com> <028e01cf2995$bef7a3c0$4001a8c0@gateway.2wire.net> In-Reply-To: <028e01cf2995$bef7a3c0$4001a8c0@gateway.2wire.net> Date: Fri, 14 Feb 2014 13:27:35 -0500 Message-ID: <01fc01cf29b2$6f51e7f0$4df5b7d0$@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxxz5juTd3n7gDSXffXOKa4rE1VAIBp6g5ml/AbfA= Content-Language: en-us X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654c01cf0db8bc46640a6ff06c4582f0d5d3ca473d225a0f487350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/-ksRa1b9u07hzcr1HfoqcZhpWC8 Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANGmodules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:27:43 -0000 Hi Tom, As the MIB Dr. on this draft, I have responded on the MIB Dr. thread that I do NOT see a way to make this draft (draft-ietf-mpls-tp-te-mib) read-only. This draft contains extension tables for tables in LSR and TE MIBS which are created by RowStatus (which is read-create). Like it or not, RowStatus of those MIBs (i.e. LSR and TE MIBs) effect the rows in the extension tables of this draft (think the case of row creation or row deletion). That is an SNMP Set operation which effects the draft. I believe the statement that Benoit puts forth would allow for such a situation as this draft, specifically: "... SNMP MIB modules modifying persistent configuration state should only be produced by working groups in cases of clear utility and consensus to use SNMP write operations for configuration." Perhaps, additional wording, such as "For example, in the case of proposed SNMP MIB modules which extend or augment rows that are created by configuration in a SNMP MIB module which is already a RFC, the proposed SNNP MIB modules will be grandfathered, if the working group finds consensus to do so." However, I am okay with the statement as written. Thanks, -Joan -----Original Message----- From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of t.petch Sent: Friday, February 14, 2014 10:02 AM To: Benoit Claise; ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANGmodules ----- Original Message ----- From: "Benoit Claise" To: Sent: Friday, February 14, 2014 12:39 AM > Dear all, > > We occasionally see read-write MIB module proposals within the IETF. > However, the write capabilities of those MIB modules are rarely implemented. > > While discussing this issue with the MIB doctors, we arrive to the > conclusion that it's now time to set the direction for future MIB > developments within the IETF. Basically, let's not specify read-write > MIB modules unless we have a good reason. Read-only MIB modules are > still fine though, as SNMP is clearly used for monitoring purposes. > > Here is the statement we came up with: > > The OPS area recommends the use of NETCONF/YANG standards for > configuration. IETF working groups are therefore encouraged to use > the NETCONF/YANG standards for configuration, specifically in new > charters. SNMP MIB modules modifying persistent configuration state > should only be produced by working groups in cases of clear utility > and consensus to use SNMP write operations for configuration. > > Ideally, this should become an IESG statement. > Your feedback is most welcome. You probably know that there is currently a consensus call in progress over "Please indicate Support or Oppose for this MIB (draft-ietf-mpls-tp-te-mib) to be read-only." and I was pleasantly surprised to see opposition, albeit with one opponent later changing their mind (perhaps they were sat on from a height:-). I don't see much sign of Netxxxx in the mpls arena but there is a need there for configuration, since there need not be a control plane to set things up. Perhaps writable MIB modules will still be with us in the distant future in some corners of the Internet.. Ideally, this idea would be fleshed out in an I-D. Tom Petch > Regards, the MIB doctors & Benoit _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3705/7092 - Release Date: 02/14/14 From nobody Sat Feb 15 08:36:10 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C3E1A0151 for ; Sat, 15 Feb 2014 08:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjH1TZcpa3PP for ; Sat, 15 Feb 2014 08:36:05 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 8E12E1A00BA for ; Sat, 15 Feb 2014 08:36:05 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta09.westchester.pa.mail.comcast.net with comcast id Sfp31n0070vyq2s59gc3py; Sat, 15 Feb 2014 16:36:03 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta05.westchester.pa.mail.comcast.net with comcast id Sgc31n0012yZEBF3Rgc39H; Sat, 15 Feb 2014 16:36:03 +0000 From: "ietfdbh" To: "'Benoit Claise'" References: <52FD65DD.4090609@cisco.com> In-Reply-To: <52FD65DD.4090609@cisco.com> Date: Sat, 15 Feb 2014 11:35:59 -0500 Message-ID: <014201cf2a6c$02072150$061563f0$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0143_01CF2A42.1931DCA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxxz5juTd3n7gDSXffXOKa4rE1VJpu/U7g Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392482163; bh=YtFqvtJL9IODTIEzhRZGggXUVVNdVFnEaw68DPD8J0E=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=DLd9kA3g/X2bUH6X/AQym+AUeqwwukRC/TvioCf283sZFK8MHV66VMje6msIrSgBx qfZUegOY4eSwplGzUc2EA7JBt5z7DBLxK/EMK2ywwZT9tX5YkW5ktF+Yuf4v9pX/ZW Zs6m/ZAbf1Ffb/LL0pBXUXNwpzEnzD0Sryo4BMA5KApbsj1c3q56AF9TNS18SwWH6N tHH2O+GmMToAlbaaJhK2sHL7USfwQTfJbNwnlFbyNiqBOmOTfyfVp1bg370GgIiJ2O 6gG+0aF20g6z909E8YlbRS6JXARNfHxaHMZY7DwmBxgxJcuw1/gd2/5gRowcJHE+jR IJ0dTgJDUZ78Q== Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/nWPN00Oj75OEYFY40n2D00STHV0 Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 16:36:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0143_01CF2A42.1931DCA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Benoit, I think the statement fails to provide advice about whether WGs should produce read-only MIB modules for monitoring. Your intro to the statement says it's still fine, but the statement itself does not. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Thursday, February 13, 2014 7:40 PM To: ops-area@ietf.org Subject: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules Dear all, We occasionally see read-write MIB module proposals within the IETF. However, the write capabilities of those MIB modules are rarely implemented. While discussing this issue with the MIB doctors, we arrive to the conclusion that it's now time to set the direction for future MIB developments within the IETF. Basically, let's not specify read-write MIB modules unless we have a good reason. Read-only MIB modules are still fine though, as SNMP is clearly used for monitoring purposes. Here is the statement we came up with: The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, specifically in new charters. SNMP MIB modules modifying persistent configuration state should only be produced by working groups in cases of clear utility and consensus to use SNMP write operations for configuration. Ideally, this should become an IESG statement. Your feedback is most welcome. Regards, the MIB doctors & Benoit ------=_NextPart_000_0143_01CF2A42.1931DCA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Benoit,

 

I think the statement fails to provide advice about whether WGs = should produce read-only MIB modules for = monitoring.

Your intro to the statement says it’s still fine, but the = statement itself does not.

 

David Harrington

ie= tfdbh@comcast.net

+1-603-828-1401

From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of = Benoit Claise
Sent: Thursday, February 13, 2014 7:40 = PM
To: ops-area@ietf.org
Subject: [OPS-AREA] = configuration: writable MIB modules versus NETCONF/YANG = modules

 

Dear = all,

We occasionally see read-write MIB module proposals within = the IETF.
However, the write capabilities of those MIB modules are = rarely implemented.

While discussing this issue with the MIB = doctors, we arrive to the conclusion that it's now time to set the = direction for future MIB developments within the IETF. Basically, let's = not specify read-write MIB modules unless we have a good reason. = Read-only MIB modules are still fine though, as SNMP is clearly used for = monitoring purposes.

Here is the statement we came up = with:

The OPS area recommends the use = of NETCONF/YANG standards for configuration. IETF working groups are = therefore encouraged to use the NETCONF/YANG standards for = configuration, specifically in new charters. SNMP MIB modules modifying = persistent configuration state should only be produced by working groups = in cases of clear utility
and consensus to use SNMP write operations = for configuration.

Ideally, this should become an IESG = statement.
Your feedback is most welcome.

Regards, the MIB = doctors & Benoit

------=_NextPart_000_0143_01CF2A42.1931DCA0-- From nobody Sat Feb 15 11:58:15 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1DE1A0303 for ; Sat, 15 Feb 2014 11:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMZMtOFirRDj for ; Sat, 15 Feb 2014 11:58:08 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id C7E501A02FC for ; Sat, 15 Feb 2014 11:58:07 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta14.westchester.pa.mail.comcast.net with comcast id SiXm1n0030SCNGk5Ejy5ie; Sat, 15 Feb 2014 19:58:05 +0000 Received: from [192.168.1.3] ([24.218.118.50]) by omta09.westchester.pa.mail.comcast.net with comcast id Sjy41n00a15KgXL3Vjy4bn; Sat, 15 Feb 2014 19:58:05 +0000 References: <52FD65DD.4090609@cisco.com> <014201cf2a6c$02072150$061563f0$@comcast.net> Mime-Version: 1.0 (1.0) In-Reply-To: <014201cf2a6c$02072150$061563f0$@comcast.net> Content-Type: multipart/alternative; boundary=Apple-Mail-8BD82469-F3DF-4736-9538-B29A3AA182E5 Content-Transfer-Encoding: 7bit Message-Id: <0E52090D-9C9A-48E7-B323-6DFFECE4715B@comcast.net> X-Mailer: iPhone Mail (11B554a) From: Andrew Donati Date: Sat, 15 Feb 2014 14:58:05 -0500 To: ietfdbh DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392494285; bh=1Zk21C0/frVnSK6J9GNBHruM3BGwE/rSyUV0/GhiSas=; h=Received:Received:Mime-Version:Content-Type:Message-Id:From: Subject:Date:To; b=Hy9fiVa0xV5WVN8yVZBf1bLG/t3/UoI5AeXXu59lGxRkuAOWJMVUoKlQu+/wnqz2V tnCWsxaZmO28ugTi7OLGh1lMfk9S/9drEsyiZ7dUsB61g7E7HEoz3sfjgwu9VgozCJ 77lS81j7zNhtQTwuLlEEfbyhBZVYAsnZQlOp+Wf71AMQ9DOUffcg0SMdO8R9DtZL/x YwTHCJxQzsR5XYSmygwejc3WIxQZ5WkUOgUH4dbxRr8Iqf+Mx61aDrnR1kxDTYUfbI m1s9uymjbdQYZwAZZGnI92ezhaPdVKoPfq6FBPCzEtL/LvQlxWvq1JLKuJyKt53Wzq Zo8QOwlBlUVRg== Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/kAIj5wyScOAuXR5eMB_rKK-JhM4 Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 19:58:10 -0000 --Apple-Mail-8BD82469-F3DF-4736-9538-B29A3AA182E5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable A > On Feb 15, 2014, at 11:35 AM, "ietfdbh" wrote: >=20 > Hi Benoit, > =20 > I think the statement fails to provide advice about whether WGs should pro= duce read-only MIB modules for monitoring. > Your intro to the statement says it=E2=80=99s still fine, but the statemen= t itself does not. > =20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Benoit Clai= se > Sent: Thursday, February 13, 2014 7:40 PM > To: ops-area@ietf.org > Subject: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YAN= G modules > =20 > Dear all, >=20 > We occasionally see read-write MIB module proposals within the IETF. > However, the write capabilities of those MIB modules are rarely implemente= d. >=20 > While discussing this issue with the MIB doctors, we arrive to the conclus= ion that it's now time to set the direction for future MIB developments with= in the IETF. Basically, let's not specify read-write MIB modules unless we h= ave a good reason. Read-only MIB modules are still fine though, as SNMP is c= learly used for monitoring purposes. >=20 > Here is the statement we came up with: > The OPS area recommends the use of NETCONF/YANG standards for configuratio= n. IETF working groups are therefore encouraged to use the NETCONF/YANG stan= dards for configuration, specifically in new charters. SNMP MIB modules modi= fying persistent configuration state should only be produced by working grou= ps in cases of clear utility=20 > and consensus to use SNMP write operations for configuration. > Ideally, this should become an IESG statement. > Your feedback is most welcome. >=20 > Regards, the MIB doctors & Benoit >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area --Apple-Mail-8BD82469-F3DF-4736-9538-B29A3AA182E5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

A

On Feb 15, 2014, a= t 11:35 AM, "ietfdbh" <ietfdbh@com= cast.net> wrote:

Hi Benoit,

 

I t= hink the statement fails to provide advice about whether WGs should produce r= ead-only MIB modules for monitoring.

Your intro to the statement says it=E2=80=99s= still fine, but the statement itself does not.

 

<= p class=3D"MsoNormal">David Harrington

ietfdbh@comcast.net=

+1-603-828-1401

From: OPS-AREA= [mailto:ops-area-bounces@ietf.= org] On Behalf Of Benoit Claise
Sent: Thursday, Februar= y 13, 2014 7:40 PM
To: ops-ar= ea@ietf.org
Subject: [OPS-AREA] configuration: writable MIB mo= dules versus NETCONF/YANG modules

 

Dear all,

We o= ccasionally see read-write MIB module proposals within the IETF.
However,= the write capabilities of those MIB modules are rarely implemented.

= While discussing this issue with the MIB doctors, we arrive to the conclusio= n that it's now time to set the direction for future MIB developments within= the IETF. Basically, let's not specify read-write MIB modules unless we hav= e a good reason. Read-only MIB modules are still fine though, as SNMP is cle= arly used for monitoring purposes.

Here is the statement we came up w= ith:

The OPS area recommends the use of= NETCONF/YANG standards for configuration. IETF working groups are therefore= encouraged to use the NETCONF/YANG standards for configuration, specificall= y in new charters. SNMP MIB modules modifying persistent configuration state= should only be produced by working groups in cases of clear utility
and= consensus to use SNMP write operations for configuration.

Ideally, this should becom= e an IESG statement.
Your feedback is most welcome.

Regards, the M= IB doctors & Benoit

______________________________________________= _
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/= ops-area
= --Apple-Mail-8BD82469-F3DF-4736-9538-B29A3AA182E5-- From nobody Sat Feb 15 12:05:08 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD2E1A0289 for ; Sat, 15 Feb 2014 12:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji4cBHhPcr9R for ; Sat, 15 Feb 2014 12:05:04 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 45F6E1A02B9 for ; Sat, 15 Feb 2014 12:05:04 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta03.westchester.pa.mail.comcast.net with comcast id Sjtn1n0021uE5Es53k527s; Sat, 15 Feb 2014 20:05:02 +0000 Received: from resmail-ch2-037v.sys.comcast.net ([162.150.48.66]) by omta16.westchester.pa.mail.comcast.net with comcast id Sk511n00R1Rh6p63ck529Y; Sat, 15 Feb 2014 20:05:02 +0000 Date: Sat, 15 Feb 2014 20:05:01 +0000 (UTC) From: andy.donati@comcast.net To: ietfdbh Message-ID: <1607851624.5502376.1392494701866.JavaMail.root@comcast.net> In-Reply-To: <014201cf2a6c$02072150$061563f0$@comcast.net> References: <52FD65DD.4090609@cisco.com> <014201cf2a6c$02072150$061563f0$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5502375_1473959167.1392494701865" X-Originating-IP: [::ffff:24.218.118.50] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF26 (Win)/8.0.3_GA_5664) Thread-Topic: configuration: writable MIB modules versus NETCONF/YANG modules Thread-Index: AQHxxz5juTd3n7gDSXffXOKa4rE1VJpu/U7gOZgeJS8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392494702; bh=vUGNo+v8DVuLZp9BfV5nmzrSQ3NdL/h7ABUCKyQipaw=; h=Received:Received:Date:From:To:Message-ID:Subject:MIME-Version: Content-Type; b=swrC9cLb16sUftP9tgpBtM/B2w8+QEWqCFS21KAW4cdcN+EEKaM6n+aexCx+yRo/0 8cpGYQa6LUtO6ZZUtg7j/eB2j8fgr00DN9h6u60YHklrcf1bH2DmlCzKpevS/vIXeJ D8OIV0NaNXBSe/vOxh+MwJQymUg7pcRqKzzElTytTw7d7h+K6tFK41CjU3RhmqXrFX zl8zgrfL27Hw6v5UuY9IUZNMZWXpUrkflkfGFlqDs+I/8oUVnds/OrCQ7BP36mF07g U9KPqp7SF+BGfJBBLq/kFU+qAIXOcDYVdoFrKAWSPOjOM1+5wleUUPIddADuLQFavc cUtdS78Ca7Fnw== Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/ZAbr6q6w7RZqTuKSxpcOyXxcLnk Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 20:05:07 -0000 ------=_Part_5502375_1473959167.1392494701865 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agree with Dave. Even though it may already be implied, the statement sho= uld explicitly state that read-only MIB modules can be produced for monitor= ing.=20 - Andy=20 ----- Original Message ----- From: "ietfdbh" =20 To: "Benoit Claise" =20 Cc: ops-area@ietf.org=20 Sent: Saturday, February 15, 2014 11:35:59 AM=20 Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/= YANG modules=20 Hi Benoit,=20 I think the statement fails to provide advice about whether WGs should prod= uce read-only MIB modules for monitoring.=20 Your intro to the statement says it=E2=80=99s still fine, but the statement= itself does not.=20 David Harrington=20 ietfdbh@comcast.net=20 +1-603-828-1401=20 From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Benoit Clais= e=20 Sent: Thursday, February 13, 2014 7:40 PM=20 To: ops-area@ietf.org=20 Subject: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG= modules=20 Dear all,=20 We occasionally see read-write MIB module proposals within the IETF.=20 However, the write capabilities of those MIB modules are rarely implemented= .=20 While discussing this issue with the MIB doctors, we arrive to the conclusi= on that it's now time to set the direction for future MIB developments with= in the IETF. Basically, let's not specify read-write MIB modules unless we = have a good reason. Read-only MIB modules are still fine though, as SNMP is= clearly used for monitoring purposes.=20 Here is the statement we came up with:=20 The OPS area recommends the use of NETCONF/YANG standards for configuration= . IETF working groups are therefore encouraged to use the NETCONF/YANG stan= dards for configuration, specifically in new charters. SNMP MIB modules mod= ifying persistent configuration state should only be produced by working gr= oups in cases of clear utility=20 and consensus to use SNMP write operations for configuration.=20 Ideally, this should become an IESG statement.=20 Your feedback is most welcome.=20 Regards, the MIB doctors & Benoit=20 _______________________________________________=20 OPS-AREA mailing list=20 OPS-AREA@ietf.org=20 https://www.ietf.org/mailman/listinfo/ops-area=20 ------=_Part_5502375_1473959167.1392494701865 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I agree with Dave.  Even though i= t may already be implied, the statement should explicitly state that read-o= nly MIB modules can be produced for monitoring.
- Andy

From: "iet= fdbh" <ietfdbh@comcast.net>
To: "Benoit Claise" <bclaise= @cisco.com>
Cc: ops-area@ietf.org
Sent: Saturday, Fe= bruary 15, 2014 11:35:59 AM
Subject: Re: [OPS-AREA] configuration= : writable MIB modules versus NETCONF/YANG     &nb= sp;  modules

Hi Benoit,

 

I think the statement fails to provide advi= ce about whether WGs should produce read-only MIB modules for monitoring.

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From: OPS-AREA [mailto:o= ps-area-bounces@ietf.org] On Behalf Of Benoit Claise
Sent:= Thursday, February 13, 2014 7:40 PM
To: ops-area@ietf.org
= Subject: [OPS-AREA] configuration: writable MIB modules versus NETCONF/= YANG modules

 

Dear all,


We o= ccasionally see read-write MIB module proposals within the IETF.
However= , the write capabilities of those MIB modules are rarely implemented.


While discussing this issue with th= e MIB doctors, we arrive to the conclusion that it's now time to set the di= rection for future MIB developments within the IETF. Basically, let's not s= pecify read-write MIB modules unless we have a good reason. Read-only MIB m= odules are still fine though, as SNMP is clearly used for monitoring purpos= es.


Here is the statement we c= ame up with:

The OPS area recommends the use of N= ETCONF/YANG standards for configuration. IETF working groups are therefore = encouraged to use the NETCONF/YANG standards for configuration, specificall= y in new charters. SNMP MIB modules modifying persistent configuration stat= e should only be produced by working groups in cases of clear utility
a= nd consensus to use SNMP write operations for configuration.

Ideally, this should become an IESG statement.
Your feedback i= s most welcome.


Regards, the MIB= doctors & Benoit


__________________________________= _____________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.= ietf.org/mailman/listinfo/ops-area

------=_Part_5502375_1473959167.1392494701865-- From nobody Sat Feb 15 14:51:45 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132401A02C7 for ; Sat, 15 Feb 2014 14:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JP_sm33nKar6 for ; Sat, 15 Feb 2014 14:51:41 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 873271A0106 for ; Sat, 15 Feb 2014 14:51:41 -0800 (PST) Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id DC9DA26F34D1; Sat, 15 Feb 2014 17:51:38 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_EDA38740-CACF-4EA3-8D2F-56F8F05CFB6D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: <1607851624.5502376.1392494701866.JavaMail.root@comcast.net> Date: Sat, 15 Feb 2014 17:51:38 -0500 Message-Id: <189DA6E6-88DE-46FD-B74F-CC0BD38DA6EE@lucidvision.com> References: <52FD65DD.4090609@cisco.com> <014201cf2a6c$02072150$061563f0$@comcast.net> <1607851624.5502376.1392494701866.JavaMail.root@comcast.net> To: andy.donati@comcast.net X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/cWJ2nA1049nims5jbzhhQXbYHRY Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 22:51:44 -0000 --Apple-Mail=_EDA38740-CACF-4EA3-8D2F-56F8F05CFB6D Content-Type: multipart/alternative; boundary="Apple-Mail=_F39AD5B4-505A-4D7C-AF17-D3BCDC2C8241" --Apple-Mail=_F39AD5B4-505A-4D7C-AF17-D3BCDC2C8241 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Indeed. We should not discourage that - even implicitly.=20 --Tom > I agree with Dave. Even though it may already be implied, the = statement should explicitly state that read-only MIB modules can be = produced for monitoring. > - Andy >=20 > From: "ietfdbh" > To: "Benoit Claise" > Cc: ops-area@ietf.org > Sent: Saturday, February 15, 2014 11:35:59 AM > Subject: Re: [OPS-AREA] configuration: writable MIB modules versus = NETCONF/YANG modules >=20 > Hi Benoit, > =20 > I think the statement fails to provide advice about whether WGs should = produce read-only MIB modules for monitoring. > Your intro to the statement says it=92s still fine, but the statement = itself does not. > =20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Benoit = Claise > Sent: Thursday, February 13, 2014 7:40 PM > To: ops-area@ietf.org > Subject: [OPS-AREA] configuration: writable MIB modules versus = NETCONF/YANG modules > =20 > Dear all, >=20 > We occasionally see read-write MIB module proposals within the IETF. > However, the write capabilities of those MIB modules are rarely = implemented. >=20 > While discussing this issue with the MIB doctors, we arrive to the = conclusion that it's now time to set the direction for future MIB = developments within the IETF. Basically, let's not specify read-write = MIB modules unless we have a good reason. Read-only MIB modules are = still fine though, as SNMP is clearly used for monitoring purposes. >=20 > Here is the statement we came up with: > The OPS area recommends the use of NETCONF/YANG standards for = configuration. IETF working groups are therefore encouraged to use the = NETCONF/YANG standards for configuration, specifically in new charters. = SNMP MIB modules modifying persistent configuration state should only be = produced by working groups in cases of clear utility=20 > and consensus to use SNMP write operations for configuration. > Ideally, this should become an IESG statement. > Your feedback is most welcome. >=20 >=20 > Regards, the MIB doctors & Benoit >=20 >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area --Apple-Mail=_F39AD5B4-505A-4D7C-AF17-D3BCDC2C8241 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Indeed. We should not discourage = that - even implicitly. 

= --Tom


I agree with Dave.  Even though it may already be implied, = the statement should explicitly state that read-only MIB modules can be = produced for monitoring.
- = Andy

From: "ietfdbh" <ietfdbh@comcast.net>
To: "Benoit Claise" <bclaise@cisco.com>
Cc: ops-area@ietf.org
Sent: Saturday, February 15, = 2014 11:35:59 AM
Subject: Re: [OPS-AREA] = configuration: writable MIB modules versus = NETCONF/YANG        modules

Hi = Benoit,

 

I think the = statement fails to provide advice about whether WGs should produce = read-only MIB modules for monitoring.
Your intro = to the statement says it=92s still fine, but the statement itself does = not.

 

David Harrington
+1-603-828-1401
From: OPS-AREA = [mailto:ops-area-bounces@ietf.org] On Behalf Of Benoit = Claise
Sent: Thursday, February 13, 2014 = 7:40 PM
To: ops-area@ietf.org
Subject: [OPS-AREA] configuration: = writable MIB modules versus NETCONF/YANG = modules

 

Dear = all,

We occasionally = see read-write MIB module proposals within the IETF.
However, the = write capabilities of those MIB modules are rarely = implemented.

While = discussing this issue with the MIB doctors, we arrive to the conclusion = that it's now time to set the direction for future MIB developments = within the IETF. Basically, let's not specify read-write MIB modules = unless we have a good reason. Read-only MIB modules are still fine = though, as SNMP is clearly used for monitoring = purposes.

Here = is the statement we came up with:
The = OPS area recommends the use of NETCONF/YANG standards for configuration. = IETF working groups are therefore encouraged to use the NETCONF/YANG = standards for configuration, specifically in new charters. SNMP MIB = modules modifying persistent configuration state should only be produced = by working groups in cases of clear utility 
and consensus to use = SNMP write operations for configuration.

Ideally, this = should become an IESG statement.
Your feedback is most = welcome.


Regards, the = MIB doctors & = Benoit


_______________________________________________<= br>OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area

_______________________________________________
OPS-= AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area

= --Apple-Mail=_F39AD5B4-505A-4D7C-AF17-D3BCDC2C8241-- --Apple-Mail=_EDA38740-CACF-4EA3-8D2F-56F8F05CFB6D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS/+96AAoJEPcO+I7eiUJZ5fMQAIj+L8rYygyy/dJQLnlyTlH6 USu8/668pdrGZCybRWLLc0ySn4tBRyiINf1Ml0oZR1FEFw/2nMsv+Ub6Rs16GaAV 3XNqRtJSKPGyvnovgB7wIVMJuZRiOxJ0STXEh0ebBtfA5Z3cg4I4H2D6tdQFJUzD wv4SEWKJRTxF/YipYpxUCTiGm3i9B3ooxPQI0WVQVSsmiBoBi6zdJHsqk++6q3zX cqxVVN+t773H/8U4+B/daHAa+bHPKfWa3zDF5JSz5gciJpVvc0q1wm2MZdNp3mQE IpXPOC1Rfg2NSEsnAH57GLTiit2AZa2vgLQwlf6gHPZIiJHDY0QGC2XzccL8tbXs GJMQ8AQYOToqcWfh3gGA/vTolwms7da9VgOxyYgycoO9hCl1hBMAAx/FChbxQf6p oOyy3hdq7iJViwy3PTWKD47Xq8dqBbBFSt+oSRWLUJyvbg3FGT+lg9TPs8Rt4Hee pXY2nljFW2eOtwWXj33IXlcTt/uu3JxEuchUb+ejcM23q8j0Nf2bkJS6kZDwBjBD WD0RVO13PDCdCMMrLVPt7thG5s3mOpWvq3QRHvTyfTtFtrWRY1JgkXyq+J/U2JIQ LKHM0sprBvvQj5Td6zBqYlca2PedTZc1smNXdZJEeOEMm3QolEOkQAzLV+JifcSS rmxm441lfOL+jVt/FCi0 =Zz0H -----END PGP SIGNATURE----- --Apple-Mail=_EDA38740-CACF-4EA3-8D2F-56F8F05CFB6D-- From nobody Sun Feb 16 04:21:11 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8742A1A03EC for ; Sun, 16 Feb 2014 04:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 973kAPHulrDg for ; Sun, 16 Feb 2014 04:21:08 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id A96BF1A03EB for ; Sun, 16 Feb 2014 04:21:08 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAFCsAFPGmAcV/2dsb2JhbABZgmUhOFe/NoEPFnSCJQEBAQEDAQEBDwsdNAQTBAIBCA0BAwQBAQsUCQcnCxQJCAIEARIIGodjAQyeG6tjEwSOUDgGgx6BFASfG4s0gy2CKg X-IronPort-AV: E=Sophos;i="4.95,855,1384318800"; d="scan'208";a="49638923" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 16 Feb 2014 07:21:06 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 16 Feb 2014 07:09:31 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Sun, 16 Feb 2014 13:21:04 +0100 From: "Romascanu, Dan (Dan)" To: Benoit Claise , "ops-area@ietf.org" Thread-Topic: [OPS-AREA] call for agenda items for the OPSAREA open meeting at IETF-89 Thread-Index: AQHPKT/yP2gadZb94UuAInLEPOGx6Zq30CbA Date: Sun, 16 Feb 2014 12:21:04 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E418930@AZ-FFEXMB04.global.avaya.com> References: <5267FF2A.2060903@cisco.com> <52FD9FF8.5030708@cisco.com> In-Reply-To: <52FD9FF8.5030708@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/HgTVWhjTAmDda9nxlaEAGFWPQRc Subject: Re: [OPS-AREA] call for agenda items for the OPSAREA open meeting at IETF-89 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 12:21:10 -0000 Hi Benoit, You may be planning to so this anyway already - I believe that it would be = good to spend some time (if available) on the topic of the (non) writable M= IB modules guidance.=20 Regards, Dan > -----Original Message----- > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Benoit > Claise > Sent: Friday, February 14, 2014 6:48 AM > To: ops-area@ietf.org > Subject: [OPS-AREA] call for agenda items for the OPSAREA open meeting at > IETF-89 >=20 > Dear all, >=20 > We are planning again for a joint OPSAWG and OPSAREA open meeting, with > the OPSAWG work items driving most of the agenda. The more general > cross-area items or those related to the relation between work in the are= a > and work out of the IETF should be part of the OPSAREA section. >=20 > Please send us your requests for presentation and discussion slots. >=20 > Thanks and Regards, >=20 > Regards, Joel and Benoit >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area From nobody Sun Feb 16 04:56:22 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A9A1A00D5 for ; Sun, 16 Feb 2014 04:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTy1AKxx9xb4 for ; Sun, 16 Feb 2014 04:56:18 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 21EE41A002B for ; Sun, 16 Feb 2014 04:56:18 -0800 (PST) Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id E895A26F3BFA; Sun, 16 Feb 2014 07:56:15 -0500 (EST) References: <5267FF2A.2060903@cisco.com> <52FD9FF8.5030708@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA2E418930@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 (1.0) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E418930@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11B554a) From: "Thomas D. Nadeau" Date: Sun, 16 Feb 2014 07:56:17 -0500 To: "Romascanu, Dan (Dan)" Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/-_CmvUoq4mk5G276BrYLpRTSOck Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] call for agenda items for the OPSAREA open meeting at IETF-89 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 12:56:20 -0000 I agree. I've already asked him for a slot to discuss this. If you want to h= elp with the slot, I'd love to join up. *) > On Feb 16, 2014, at 7:21 AM, "Romascanu, Dan (Dan)" w= rote: >=20 > Hi Benoit, >=20 > You may be planning to so this anyway already - I believe that it would be= good to spend some time (if available) on the topic of the (non) writable M= IB modules guidance.=20 >=20 > Regards, >=20 > Dan >=20 >=20 >> -----Original Message----- >> From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Benoit >> Claise >> Sent: Friday, February 14, 2014 6:48 AM >> To: ops-area@ietf.org >> Subject: [OPS-AREA] call for agenda items for the OPSAREA open meeting at= >> IETF-89 >>=20 >> Dear all, >>=20 >> We are planning again for a joint OPSAWG and OPSAREA open meeting, with >> the OPSAWG work items driving most of the agenda. The more general >> cross-area items or those related to the relation between work in the are= a >> and work out of the IETF should be part of the OPSAREA section. >>=20 >> Please send us your requests for presentation and discussion slots. >>=20 >> Thanks and Regards, >>=20 >> Regards, Joel and Benoit >>=20 >> _______________________________________________ >> OPS-AREA mailing list >> OPS-AREA@ietf.org >> https://www.ietf.org/mailman/listinfo/ops-area >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area >=20 From nobody Sun Feb 16 07:55:04 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582B21A00B2 for ; Sun, 16 Feb 2014 07:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMXzyLwzXhAJ for ; Sun, 16 Feb 2014 07:54:57 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 57FC21A00CD for ; Sun, 16 Feb 2014 07:54:57 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id k4so20972015qaq.1 for ; Sun, 16 Feb 2014 07:54:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CLLgTixQrzecP7E+3WxTqfWhyz3mwUxGWy6KrUeFRaE=; b=FCsxE/DOwCNvOlZ63yTAb9cWFf6XvtUjlt5+HjY0a7c0XBrezHAKVfbNJugnW/4Mi+ PEbuAjI4/6DkLeVW7HQw8uxJcLKDgJL4b6nOLTvqn6YDDmNxeZs2nagLH2N7VyHr3Sxo neMr3ROxX/S/OsW7GZEwCD57Rv8jTfSL19nlBxVTPomz7OLVmlHYELk2g/yQ1H0MRn4R R9IH7FXZ/E12P5pXy21im258xOe3SyVfyAv+HjNWVCgSVWLgSXXDQP+Kh3Cw1/Vg0/z0 YJiJAshTgoYOrxYaQ/T2k/YaFA7Rjypb6QuI11/54tyQ9nIemmQ0xHlePIBt0rO6256h Vmxg== X-Gm-Message-State: ALoCoQmklr3fLRZwJJGN/XYhjTohAYvtFhxhYkP/xM+u5gdpcqxS2FbZQKthij85+6UZ343K/OJB MIME-Version: 1.0 X-Received: by 10.224.49.69 with SMTP id u5mr1764138qaf.88.1392566094964; Sun, 16 Feb 2014 07:54:54 -0800 (PST) Received: by 10.140.98.130 with HTTP; Sun, 16 Feb 2014 07:54:54 -0800 (PST) In-Reply-To: <1607851624.5502376.1392494701866.JavaMail.root@comcast.net> References: <52FD65DD.4090609@cisco.com> <014201cf2a6c$02072150$061563f0$@comcast.net> <1607851624.5502376.1392494701866.JavaMail.root@comcast.net> Date: Sun, 16 Feb 2014 07:54:54 -0800 Message-ID: From: Andy Bierman To: andy.donati@comcast.net Content-Type: multipart/alternative; boundary=001a11c2f5a86abc4e04f2880f93 Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/oqzcPeMiDgRI0v25MBbESh_93wA Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 15:55:01 -0000 --001a11c2f5a86abc4e04f2880f93 Content-Type: text/plain; charset=ISO-8859-1 Hi, I think this recommendation should just say that it applies only to SNMP for configuration. I don't want it to say "SHOULD use NETCONF for configuration and (MUST/SHOULD) use SNMP for monitoring." In NETMOD WG, we started down this path for interfaces and some vendors said "give us the counters in NETCONF. We have no plans to implement SNMP in our device for anything." I think NETCONF and IPFIX are good monitoring candidates, better than SNMP by some metrics, and worse by other metrics. A WG should weigh all factors and make the best choice for their situation. A 1-size-fits-all policy is not that helpful here. Andy On Sat, Feb 15, 2014 at 12:05 PM, wrote: > I agree with Dave. Even though it may already be implied, the statement > should explicitly state that read-only MIB modules can be produced for > monitoring. > - Andy > > ------------------------------ > *From: *"ietfdbh" > *To: *"Benoit Claise" > *Cc: *ops-area@ietf.org > *Sent: *Saturday, February 15, 2014 11:35:59 AM > *Subject: *Re: [OPS-AREA] configuration: writable MIB modules versus > NETCONF/YANG modules > > Hi Benoit, > > > > I think the statement fails to provide advice about whether WGs should > produce read-only MIB modules for monitoring. > > Your intro to the statement says it's still fine, but the statement itself > does not. > > > > David Harrington > > ietfdbh@comcast.net > > +1-603-828-1401 > > *From:* OPS-AREA [mailto:ops-area-bounces@ietf.org] *On Behalf Of *Benoit > Claise > *Sent:* Thursday, February 13, 2014 7:40 PM > *To:* ops-area@ietf.org > *Subject:* [OPS-AREA] configuration: writable MIB modules versus > NETCONF/YANG modules > > > > Dear all, > > We occasionally see read-write MIB module proposals within the IETF. > However, the write capabilities of those MIB modules are rarely > implemented. > > While discussing this issue with the MIB doctors, we arrive to the > conclusion that it's now time to set the direction for future MIB > developments within the IETF. Basically, let's not specify read-write MIB > modules unless we have a good reason. Read-only MIB modules are still fine > though, as SNMP is clearly used for monitoring purposes. > > Here is the statement we came up with: > > The OPS area recommends the use of NETCONF/YANG standards for > configuration. IETF working groups are therefore encouraged to use the > NETCONF/YANG standards for configuration, specifically in new charters. > SNMP MIB modules modifying persistent configuration state should only be > produced by working groups in cases of clear utility > and consensus to use SNMP write operations for configuration. > > Ideally, this should become an IESG statement. > Your feedback is most welcome. > > Regards, the MIB doctors & Benoit > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > > --001a11c2f5a86abc4e04f2880f93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I think this recommendation should = just say that it applies only
to SNMP for configuration.  I = don't want it to say "SHOULD use
NETCONF for configurati= on and (MUST/SHOULD) use SNMP
for monitoring."

In NETMOD WG, we starte= d down this path for interfaces
and some vendors said "give = us the counters in NETCONF.
We have no plans to implement SNMP in= our device for anything."

I thin= k NETCONF and IPFIX are good monitoring candidates,
better than SNMP by some metrics, and worse by other metrics.
A WG should weigh all factors and make the best choice for their
situation.  A 1-size-fits-all policy is not that= helpful here.


Andy
<= br>


On S= at, Feb 15, 2014 at 12:05 PM, <andy.donati@comcast.net> wrote:
I agree with Dave.  Even though it may already be implie= d, the statement should explicitly state that read-only MIB modules can be = produced for monitoring.
- Andy

From: "ietfdbh" <ietfdbh@comcast.net>
To: "Benoit Claise" <bclaise@cisco.com>
Cc: ops-area@ietf.org
Sent: = Saturday, February 15, 2014 11:35:59 AM
Subject: Re: [OPS-AREA] configuration: writable MIB modules versus N= ETCONF/YANG        modules
=

Hi Benoit,

 

I think the statement fails to pr= ovide advice about whether WGs should produce read-only MIB modules for mon= itoring.

Your intro to the stateme= nt says it’s still fine, but the statement itself does not.

 

David Harrington=

ietfdbh@comcast.net

+1-603-828-1401

From: OPS-AREA [mailto:ops-area-bounces@ietf.o= rg] On Behalf Of Benoit Claise
Sent: Thursday, February 13, 2014 7:40 PM
To: ops-area@ietf.org
Subj= ect: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG= modules

 

Dear al= l,


We occasionally see read-wr= ite MIB module proposals within the IETF.
However, the write capabilitie= s of those MIB modules are rarely implemented.


While discussing this issue with = the MIB doctors, we arrive to the conclusion that it's now time to set = the direction for future MIB developments within the IETF. Basically, let&#= 39;s not specify read-write MIB modules unless we have a good reason. Read-= only MIB modules are still fine though, as SNMP is clearly used for monitor= ing purposes.


Here is the statement we came up = with:

The OPS area recommends the use of NETCONF/= YANG standards for configuration. IETF working groups are therefore encoura= ged to use the NETCONF/YANG standards for configuration, specifically in ne= w charters. SNMP MIB modules modifying persistent configuration state shoul= d only be produced by working groups in cases of clear utility
and consensus to use SNMP write operations for configuration.

Ideally, this should become a= n IESG statement.
Your feedback is most welcome.


<= p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"> Regards, the MIB doctors & Benoit


__________________= _____________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://ww= w.ietf.org/mailman/listinfo/ops-area


______________________________________= _________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area


--001a11c2f5a86abc4e04f2880f93-- From nobody Mon Feb 17 01:39:47 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4651A0394 for ; Mon, 17 Feb 2014 01:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZbWTTnh5-lM for ; Mon, 17 Feb 2014 01:39:43 -0800 (PST) Received: from iberico.switch.ch (outb-ib1-2.ham.switch.ch [IPv6:2001:620:0:14::7f]) by ietfa.amsl.com (Postfix) with ESMTP id CF6F71A042C for ; Mon, 17 Feb 2014 01:39:42 -0800 (PST) Received: from surlej.switch.ch (surlej.switch.ch [IPv6:2001:620:0:e::69]) by iberico.switch.ch (8.14.4/8.14.4/Debian-4) with ESMTP id s1H9dRNX028935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Feb 2014 10:39:28 +0100 Received: from macsl.switch.ch ([130.59.17.133] helo=Simons-MacBook-Air-35499.local) by surlej.switch.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WFKff-0001Kj-9C; Mon, 17 Feb 2014 10:39:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21249.55502.863663.945186@Simons-MacBook-Air-35499.local> Date: Mon, 17 Feb 2014 10:39:26 +0100 From: Simon Leinen To: Benoit Claise In-Reply-To: <52FD65DD.4090609@cisco.com> References: <52FD65DD.4090609@cisco.com> X-Mailer: VM 8.2.0b under 24.3.50.1 (x86_64-apple-darwin12.5.0) X-SWITCHham-Score: X-CanIt-Geo: ip=2001:620:0:e::69; country=CH X-CanItPRO-Stream: switch-ch:outbound (inherits from switch-ch:default, base:default) X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/Z_XxGtpeXY0J8Ob7ufGWyIp7dZM Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 09:39:45 -0000 Benoit Claise writes: > Here is the statement we came up with: > The OPS area recommends the use of NETCONF/YANG standards for > configuration. IETF working groups are therefore encouraged to > use the NETCONF/YANG standards for configuration, specifically > in new charters. SNMP MIB modules modifying persistent > configuration state should only be produced by working groups in > cases of clear utility and consensus to use SNMP write > operations for configuration. > Ideally, this should become an IESG statement. > Your feedback is most welcome. Agree - it's time for such a statement, and this is a good one. It doesn't make any recommendations about monitoring or notifications. I think that (absence) is also appropriate at this point. -- Simon. From nobody Mon Feb 17 01:54:16 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241FC1A047C for ; Mon, 17 Feb 2014 01:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCiAP0i35I08 for ; Mon, 17 Feb 2014 01:54:14 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7718B1A03C8 for ; Mon, 17 Feb 2014 01:54:13 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A68F0FEA; Mon, 17 Feb 2014 10:54:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UgfgiSiHQOdL; Mon, 17 Feb 2014 10:54:09 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Mon, 17 Feb 2014 10:54:09 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6CF0B20028; Mon, 17 Feb 2014 10:54: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 JL08n7YpSREt; Mon, 17 Feb 2014 10:54:09 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D334920026; Mon, 17 Feb 2014 10:54:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CCE052B54818; Mon, 17 Feb 2014 10:54:05 +0100 (CET) Date: Mon, 17 Feb 2014 10:54:05 +0100 From: Juergen Schoenwaelder To: Simon Leinen Message-ID: <20140217095405.GA96343@elstar.local> Mail-Followup-To: Simon Leinen , Benoit Claise , "ops-area@ietf.org" References: <52FD65DD.4090609@cisco.com> <21249.55502.863663.945186@Simons-MacBook-Air-35499.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21249.55502.863663.945186@Simons-MacBook-Air-35499.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/fM5LfuVwvtgzeyZh2emOUBnooAk Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 09:54:16 -0000 On Mon, Feb 17, 2014 at 10:39:26AM +0100, Simon Leinen wrote: > Benoit Claise writes: > > Here is the statement we came up with: > > > The OPS area recommends the use of NETCONF/YANG standards for > > configuration. IETF working groups are therefore encouraged to > > use the NETCONF/YANG standards for configuration, specifically > > in new charters. SNMP MIB modules modifying persistent > > configuration state should only be produced by working groups in > > cases of clear utility and consensus to use SNMP write > > operations for configuration. > > > Ideally, this should become an IESG statement. > > Your feedback is most welcome. > > Agree - it's time for such a statement, and this is a good one. > It doesn't make any recommendations about monitoring or notifications. > I think that (absence) is also appropriate at this point. I agree that it is a feature to be silent about things this statement is not talking about. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Feb 17 02:08:50 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47571A03C9 for ; Mon, 17 Feb 2014 02:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dw78zqpHMSik for ; Mon, 17 Feb 2014 02:08:45 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1604B1A03C8 for ; Mon, 17 Feb 2014 02:08:45 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WFL7w-0007rF-QL; Mon, 17 Feb 2014 11:08:41 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest123.guestnet.ripe.net) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WFL7w-0005Lo-NC; Mon, 17 Feb 2014 11:08:40 +0100 Message-ID: <5301DFA8.2040303@bwijnen.net> Date: Mon, 17 Feb 2014 11:08:40 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Simon Leinen , Benoit Claise , "ops-area@ietf.org" References: <52FD65DD.4090609@cisco.com> <21249.55502.863663.945186@Simons-MacBook-Air-35499.local> <20140217095405.GA96343@elstar.local> In-Reply-To: <20140217095405.GA96343@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4654be53ec4bee9fdd7c18dc194355608 Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/UjKPHh_wOMvevbuCsObY74H9cJ0 Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 10:08:47 -0000 Agree Bert On 17/02/14 10:54, Juergen Schoenwaelder wrote: > On Mon, Feb 17, 2014 at 10:39:26AM +0100, Simon Leinen wrote: >> Benoit Claise writes: >>> Here is the statement we came up with: >> >>> The OPS area recommends the use of NETCONF/YANG standards for >>> configuration. IETF working groups are therefore encouraged to >>> use the NETCONF/YANG standards for configuration, specifically >>> in new charters. SNMP MIB modules modifying persistent >>> configuration state should only be produced by working groups in >>> cases of clear utility and consensus to use SNMP write >>> operations for configuration. >> >>> Ideally, this should become an IESG statement. >>> Your feedback is most welcome. >> >> Agree - it's time for such a statement, and this is a good one. >> It doesn't make any recommendations about monitoring or notifications. >> I think that (absence) is also appropriate at this point. > > I agree that it is a feature to be silent about things this statement > is not talking about. > > /js > From nobody Mon Feb 17 02:19:26 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42F21A03C7 for ; Mon, 17 Feb 2014 02:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygyIBpm3tm8U for ; Mon, 17 Feb 2014 02:19:23 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 959F41A038D for ; Mon, 17 Feb 2014 02:19:23 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAN/gAVOHCzIm/2dsb2JhbABZgmUhOFe/NIEdFnSCJQEBAQEDAQEBDyg0FwQCAQgNBAQBAQEKFAkHJwsUCQgCBAESCBqHYwEMnzKsCxMEjlA4BoMegRQEnxuLNIMtgio X-IronPort-AV: E=Sophos;i="4.95,859,1384318800"; d="scan'208";a="49703278" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Feb 2014 05:19:20 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 17 Feb 2014 05:06:28 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Mon, 17 Feb 2014 11:19:19 +0100 From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , Simon Leinen , Benoit Claise , "ops-area@ietf.org" Thread-Topic: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules Thread-Index: AQHPK8QlaUQrwtYWPUmwYsf6MUER/Zq5JBeAgAAEEwCAABOqsA== Date: Mon, 17 Feb 2014 10:19:17 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E41B7E7@AZ-FFEXMB04.global.avaya.com> References: <52FD65DD.4090609@cisco.com> <21249.55502.863663.945186@Simons-MacBook-Air-35499.local> <20140217095405.GA96343@elstar.local> <5301DFA8.2040303@bwijnen.net> In-Reply-To: <5301DFA8.2040303@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/XNXJRQ7f8ZWCqrEAItSHPpG9ylk Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 10:19:25 -0000 +1 Dan > -----Original Message----- > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Bert > Wijnen (IETF) > Sent: Monday, February 17, 2014 12:09 PM > To: Simon Leinen; Benoit Claise; ops-area@ietf.org > Subject: Re: [OPS-AREA] configuration: writable MIB modules versus > NETCONF/YANG modules >=20 > Agree >=20 > Bert >=20 > On 17/02/14 10:54, Juergen Schoenwaelder wrote: > > On Mon, Feb 17, 2014 at 10:39:26AM +0100, Simon Leinen wrote: > >> Benoit Claise writes: > >>> Here is the statement we came up with: > >> > >>> The OPS area recommends the use of NETCONF/YANG standards for > >>> configuration. IETF working groups are therefore encouraged to > >>> use the NETCONF/YANG standards for configuration, specifically > >>> in new charters. SNMP MIB modules modifying persistent > >>> configuration state should only be produced by working groups in > >>> cases of clear utility and consensus to use SNMP write > >>> operations for configuration. > >> > >>> Ideally, this should become an IESG statement. > >>> Your feedback is most welcome. > >> > >> Agree - it's time for such a statement, and this is a good one. > >> It doesn't make any recommendations about monitoring or notifications. > >> I think that (absence) is also appropriate at this point. > > > > I agree that it is a feature to be silent about things this statement > > is not talking about. > > > > /js > > >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area From nobody Mon Feb 17 11:20:24 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2FD1A0221 for ; Mon, 17 Feb 2014 11:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmSgUmGgzLxZ for ; Mon, 17 Feb 2014 11:20:20 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8C63E1A053E for ; Mon, 17 Feb 2014 11:20:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=XoPPAqjwF0EzqGu1cJH3RSzkapXY5M79e3aMC+TBlvZm9Zftc0FYSgY3wXg1j5Lg; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanTower) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WFTjg-0001ms-JL; Mon, 17 Feb 2014 14:20:12 -0500 From: "Joan Cucchiara" To: "'Romascanu, Dan \(Dan\)'" , "'Bert Wijnen \(IETF\)'" , "'Simon Leinen'" , "'Benoit Claise'" , References: <52FD65DD.4090609@cisco.com> <21249.55502.863663.945186@Simons-MacBook-Air-35499.local> <20140217095405.GA96343@elstar.local> <5301DFA8.2040303@bwijnen.net> <9904FB1B0159DA42B0B887B7FA8119CA2E41B7E7@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E41B7E7@AZ-FFEXMB04.global.avaya.com> Date: Mon, 17 Feb 2014 14:20:09 -0500 Message-ID: <000001cf2c15$470f3cb0$d52db610$@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxxz5juTd3n7gDSXffXOKa4rE1VAMiG4pLAgrd9b8B+sQwmQIBwKEamitQARA= Content-Language: en-us X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265431305abefbebce0fd3dce6ad2c0a6f21667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/UuBdvMmiCnVtJ7yMN0G450T4Vdc Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 19:20:23 -0000 + 1 -Joan -----Original Message----- From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Monday, February 17, 2014 5:19 AM To: Bert Wijnen (IETF); Simon Leinen; Benoit Claise; ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules +1 Dan > -----Original Message----- > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Bert > Wijnen (IETF) > Sent: Monday, February 17, 2014 12:09 PM > To: Simon Leinen; Benoit Claise; ops-area@ietf.org > Subject: Re: [OPS-AREA] configuration: writable MIB modules versus > NETCONF/YANG modules > > Agree > > Bert > > On 17/02/14 10:54, Juergen Schoenwaelder wrote: > > On Mon, Feb 17, 2014 at 10:39:26AM +0100, Simon Leinen wrote: > >> Benoit Claise writes: > >>> Here is the statement we came up with: > >> > >>> The OPS area recommends the use of NETCONF/YANG standards for > >>> configuration. IETF working groups are therefore encouraged to > >>> use the NETCONF/YANG standards for configuration, specifically > >>> in new charters. SNMP MIB modules modifying persistent > >>> configuration state should only be produced by working groups in > >>> cases of clear utility and consensus to use SNMP write > >>> operations for configuration. > >> > >>> Ideally, this should become an IESG statement. > >>> Your feedback is most welcome. > >> > >> Agree - it's time for such a statement, and this is a good one. > >> It doesn't make any recommendations about monitoring or notifications. > >> I think that (absence) is also appropriate at this point. > > > > I agree that it is a feature to be silent about things this > > statement is not talking about. > > > > /js > > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3705/7098 - Release Date: 02/16/14 From nobody Mon Feb 17 11:23:04 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F571A0523 for ; Mon, 17 Feb 2014 11:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKgCJxm-iwkK for ; Mon, 17 Feb 2014 11:23:00 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0155.outbound.protection.outlook.com [207.46.163.155]) by ietfa.amsl.com (Postfix) with ESMTP id F2E441A0526 for ; Mon, 17 Feb 2014 11:22:59 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) with Microsoft SMTP Server (TLS) id 15.0.878.16; Mon, 17 Feb 2014 19:22:55 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0878.008; Mon, 17 Feb 2014 19:22:55 +0000 From: Dave Thaler To: Juergen Schoenwaelder , Simon Leinen Thread-Topic: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules Thread-Index: AQHPK8QzVaoMx/c6JUC2gmxXPpsV4Jq5NNqAgACefoA= Date: Mon, 17 Feb 2014 19:22:55 +0000 Message-ID: References: <52FD65DD.4090609@cisco.com> <21249.55502.863663.945186@Simons-MacBook-Air-35499.local> <20140217095405.GA96343@elstar.local> In-Reply-To: <20140217095405.GA96343@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::3] x-forefront-prvs: 012570D5A0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(51704005)(199002)(189002)(24454002)(377454003)(85852003)(56776001)(51856001)(54356001)(46102001)(83072002)(47976001)(49866001)(47736001)(76482001)(54316002)(93136001)(86612001)(94316002)(69226001)(92566001)(50986001)(4396001)(53806001)(95416001)(95666001)(94946001)(93516002)(86362001)(80022001)(65816001)(80976001)(19580405001)(19580395003)(83322001)(59766001)(77982001)(74366001)(74316001)(63696002)(81542001)(85306002)(47446002)(79102001)(33646001)(81342001)(76576001)(76796001)(2656002)(74876001)(56816005)(90146001)(74706001)(74502001)(31966008)(74662001)(81816001)(81686001)(76786001)(87266001)(87936001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB412; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::3; FPR:ECF6F015.9CF6D7A6.B1C77A70.4CE19CFF.202A4; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/PcNF7eOnrXWsoW4mgMMhxsrPlzQ Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 19:23:02 -0000 > -----Original Message----- > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Monday, February 17, 2014 1:54 AM > To: Simon Leinen > Cc: ops-area@ietf.org > Subject: Re: [OPS-AREA] configuration: writable MIB modules versus > NETCONF/YANG modules >=20 > On Mon, Feb 17, 2014 at 10:39:26AM +0100, Simon Leinen wrote: > > Benoit Claise writes: > > > Here is the statement we came up with: > > > > > The OPS area recommends the use of NETCONF/YANG standards for > > > configuration. IETF working groups are therefore encouraged to > > > use the NETCONF/YANG standards for configuration, specifically > > > in new charters. SNMP MIB modules modifying persistent > > > configuration state should only be produced by working groups in > > > cases of clear utility and consensus to use SNMP write > > > operations for configuration. > > > > > Ideally, this should become an IESG statement. > > > Your feedback is most welcome. > > > > Agree - it's time for such a statement, and this is a good one. > > It doesn't make any recommendations about monitoring or notifications. > > I think that (absence) is also appropriate at this point. >=20 > I agree that it is a feature to be silent about things this statement is = not > talking about. >=20 > /js It may be a feature to the OPS area, but it is not a feature as far as the = audience of the statement is concerned (I speak as one of the latter, and one who's = asked for a statement about notifications). It sounds like the silence is due to lack of any consensus or simple answer= . The lack of a simple consensus answer is a problem, not a feature. But that's the current world we live in. -Dave =20 From nobody Mon Feb 17 15:40:49 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236081A05E0 for ; Mon, 17 Feb 2014 15:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6B_OmK3mAMRY for ; Mon, 17 Feb 2014 15:40:44 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 46C481A05DF for ; Mon, 17 Feb 2014 15:40:44 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta12.westchester.pa.mail.comcast.net with comcast id Tame1n0060EZKEL5CbghnE; Mon, 17 Feb 2014 23:40:41 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta01.westchester.pa.mail.comcast.net with comcast id Tbgg1n00k2yZEBF3MbggXV; Mon, 17 Feb 2014 23:40:41 +0000 From: "ietfdbh" To: "'Dave Thaler'" , "'Juergen Schoenwaelder'" , "'Simon Leinen'" References: <52FD65DD.4090609@cisco.com> <21249.55502.863663.945186@Simons-MacBook-Air-35499.local> <20140217095405.GA96343@elstar.local> In-Reply-To: Date: Mon, 17 Feb 2014 18:40:41 -0500 Message-ID: <00a401cf2c39$abb41ea0$031c5be0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxxz5juTd3n7gDSXffXOKa4rE1VAMiG4pLAgrd9b8CM5jw4Jo53+Lw Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392680441; bh=aJJdC8Krb9nMZTF41C/IVL3iluuRgFdRfMIh7Q63JCQ=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=bP+W0ye4rBjk3xz03ueGzjQnRKMLfPOVsjor61uaTUj/WlV/JZNR44EvbyBC2fDqY lAIdpJl61oGv6vUQ7YLo7P0Wfe5ApQOdiigjURA6fdRx1s3Hmt7Q8KoCZ36QHoCScM wcHfLFZnZvtOx6NOqIVOMu896A4Q0xEYOymMoz/4hSk4UCMYvNMq1sLLfAYfSraog/ fypXsJ5gO2UiJdmDQAc9pB5LLAuZ7jko1uyYJC3ajO3I9H1IHs6ZQRe41TckJHOBe1 vj4dzKZ4tD6Llw5OuIDxiHbi8SKxvJ40QHktuGSZQ2QW3iRfIL/rqQb5QRBObi1tmi IEzWmGjtDcFOQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/1YF2Gk69btE0SHeYW4S-YfVCctg Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 23:40:47 -0000 I don't think remaining silent is a feature, when WGs have asked for guidance. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Dave > Thaler > Sent: Monday, February 17, 2014 2:23 PM > To: Juergen Schoenwaelder; Simon Leinen > Cc: ops-area@ietf.org > Subject: Re: [OPS-AREA] configuration: writable MIB modules versus > NETCONF/YANG modules > > > -----Original Message----- > > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Monday, February 17, 2014 1:54 AM > > To: Simon Leinen > > Cc: ops-area@ietf.org > > Subject: Re: [OPS-AREA] configuration: writable MIB modules versus > > NETCONF/YANG modules > > > > On Mon, Feb 17, 2014 at 10:39:26AM +0100, Simon Leinen wrote: > > > Benoit Claise writes: > > > > Here is the statement we came up with: > > > > > > > The OPS area recommends the use of NETCONF/YANG standards for > > > > configuration. IETF working groups are therefore encouraged to > > > > use the NETCONF/YANG standards for configuration, specifically > > > > in new charters. SNMP MIB modules modifying persistent > > > > configuration state should only be produced by working groups in > > > > cases of clear utility and consensus to use SNMP write > > > > operations for configuration. > > > > > > > Ideally, this should become an IESG statement. > > > > Your feedback is most welcome. > > > > > > Agree - it's time for such a statement, and this is a good one. > > > It doesn't make any recommendations about monitoring or notifications. > > > I think that (absence) is also appropriate at this point. > > > > I agree that it is a feature to be silent about things this statement is not > > talking about. > > > > /js > > It may be a feature to the OPS area, but it is not a feature as far as the > audience > of the statement is concerned (I speak as one of the latter, and one who's > asked > for a statement about notifications). > > It sounds like the silence is due to lack of any consensus or simple answer. > The lack of a simple consensus answer is a problem, not a feature. > But that's the current world we live in. > > -Dave > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area From nobody Mon Feb 17 16:07:02 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BC91A055E for ; Mon, 17 Feb 2014 16:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPlLnbibLc32 for ; Mon, 17 Feb 2014 16:06:56 -0800 (PST) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id D67D81A0013 for ; Mon, 17 Feb 2014 16:06:55 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id x13so24804830qcv.33 for ; Mon, 17 Feb 2014 16:06:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XgUoAuoyr95Wq+MDtNTA/o29TMCP1ezubfp2DZ+IsWQ=; b=Zvh5pf3KZ0DwCEXh+V8h8usE0NDFJ3klj9sYHzeYJuVnMhaaD8VeSxSGK6JL0cVICY l4UX978WU9RTWUGD47/6J641FRTJ2TmtAp6RHlgH0CZLUWDc3GaYQJmJ/qjuLI5cT++m 3fqsF+nG9IaerNyoENakmqeZDQaufLOfjrJiiLJNUTQGQdHDjaDsG2hCRxziSB4h4eW/ TXzIv1JKaEvoUFx+H0s3boHbkq55lc7gGdnv4homyAE/4sbFRIZWgLgz/tYekYQyaDra x3PSmD2DhCN6koGnDZi8uJxB9I9vFx8bcxtvr92xOcR8lNseql2f245nNSYg07rcwSfF XfJQ== X-Gm-Message-State: ALoCoQkmJe2rEcD6ITYRSIKruUfPkrHciedONVzo9TDIEuQbcYLrudQLyyGX3dmjlM2jGm8Dci6E MIME-Version: 1.0 X-Received: by 10.224.19.199 with SMTP id c7mr6738639qab.78.1392682013048; Mon, 17 Feb 2014 16:06:53 -0800 (PST) Received: by 10.140.98.130 with HTTP; Mon, 17 Feb 2014 16:06:52 -0800 (PST) In-Reply-To: <00a401cf2c39$abb41ea0$031c5be0$@comcast.net> References: <52FD65DD.4090609@cisco.com> <21249.55502.863663.945186@Simons-MacBook-Air-35499.local> <20140217095405.GA96343@elstar.local> <00a401cf2c39$abb41ea0$031c5be0$@comcast.net> Date: Mon, 17 Feb 2014 16:06:52 -0800 Message-ID: From: Andy Bierman To: ietfdbh Content-Type: multipart/alternative; boundary=001a11c2b3caac50c604f2a30c75 Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/71F67PbPbEnjsVbpOGdyvW5qTMI Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 00:06:59 -0000 --001a11c2b3caac50c604f2a30c75 Content-Type: text/plain; charset=ISO-8859-1 Hi, Note that none of the people asking for more text have provided any proposed changes. WGs should use the monitoring protocol(s) that best fit their requirements. How's that? Not sure it is worth the effort to create a cookbook for all possible requirements that could occur, or try to give meaningful guidance in 1 or 2 sentences. Andy On Mon, Feb 17, 2014 at 3:40 PM, ietfdbh wrote: > I don't think remaining silent is a feature, when WGs have asked for > guidance. > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > > -----Original Message----- > > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Dave > > Thaler > > Sent: Monday, February 17, 2014 2:23 PM > > To: Juergen Schoenwaelder; Simon Leinen > > Cc: ops-area@ietf.org > > Subject: Re: [OPS-AREA] configuration: writable MIB modules versus > > NETCONF/YANG modules > > > > > -----Original Message----- > > > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Juergen > > > Schoenwaelder > > > Sent: Monday, February 17, 2014 1:54 AM > > > To: Simon Leinen > > > Cc: ops-area@ietf.org > > > Subject: Re: [OPS-AREA] configuration: writable MIB modules versus > > > NETCONF/YANG modules > > > > > > On Mon, Feb 17, 2014 at 10:39:26AM +0100, Simon Leinen wrote: > > > > Benoit Claise writes: > > > > > Here is the statement we came up with: > > > > > > > > > The OPS area recommends the use of NETCONF/YANG standards for > > > > > configuration. IETF working groups are therefore encouraged to > > > > > use the NETCONF/YANG standards for configuration, specifically > > > > > in new charters. SNMP MIB modules modifying persistent > > > > > configuration state should only be produced by working groups > in > > > > > cases of clear utility and consensus to use SNMP write > > > > > operations for configuration. > > > > > > > > > Ideally, this should become an IESG statement. > > > > > Your feedback is most welcome. > > > > > > > > Agree - it's time for such a statement, and this is a good one. > > > > It doesn't make any recommendations about monitoring or > notifications. > > > > I think that (absence) is also appropriate at this point. > > > > > > I agree that it is a feature to be silent about things this statement > is > not > > > talking about. > > > > > > /js > > > > It may be a feature to the OPS area, but it is not a feature as far as > the > > audience > > of the statement is concerned (I speak as one of the latter, and one > who's > > asked > > for a statement about notifications). > > > > It sounds like the silence is due to lack of any consensus or simple > answer. > > The lack of a simple consensus answer is a problem, not a feature. > > But that's the current world we live in. > > > > -Dave > > > > > > _______________________________________________ > > OPS-AREA mailing list > > OPS-AREA@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-area > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > --001a11c2b3caac50c604f2a30c75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Note that none of the people asking= for more text have provided any
proposed changes.

=
=A0 =A0WGs should use the monitoring protocol(s) that best fit t= heir requirements.

How's that?

Not sure it is= worth the effort to create a cookbook
for all possible requireme= nts that could occur, or
try to give meaningful guidance in 1 or = 2 sentences.


Andy

On Mon, Feb 17, 2014 at 3:40 PM, ietfdbh <iet= fdbh@comcast.net> wrote:
I don't think remaining silent is a feature, when WGs have asked for guidance.

David Harrington
ietfdbh@comcast.ne= t
+1-603-828-1401
> -----Original Message-----
> From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Dave
> Thaler
> Sent: Monday, February 17, 2014 2:23 PM
> To: Juergen Schoenwaelder; Simon Leinen
> Cc: ops-area@ie= tf.org
> Subject: Re: [OPS-AREA] configuration: writable MIB modules versus
> NETCONF/YANG modules
>
> > -----Original Message-----
> > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder
> > Sent: Monday, February 17, 2014 1:54 AM
> > To: Simon Leinen
> > Cc: ops-ar= ea@ietf.org
> > Subject: Re: [OPS-AREA] configuration: writable MIB modules versu= s
> > NETCONF/YANG modules
> >
> > On Mon, Feb 17, 2014 at 10:39:26AM +0100, Simon Leinen wrote:
> > > Benoit Claise writes:
> > > > Here is the statement we came up with:
> > >
> > > > =A0 =A0 The OPS area recommends the use of NETCONF/YANG= standards for
> > > > =A0 =A0 configuration. IETF working groups are therefor= e encouraged to
> > > > =A0 =A0 use the NETCONF/YANG standards for configuratio= n, specifically
> > > > =A0 =A0 in new charters. SNMP MIB modules modifying per= sistent
> > > > =A0 =A0 configuration state should only be produced by = working groups in
> > > > =A0 =A0 cases of clear utility and consensus to use SNM= P write
> > > > =A0 =A0 operations for configuration.
> > >
> > > > Ideally, this should become an IESG statement.
> > > > Your feedback is most welcome.
> > >
> > > Agree - it's time for such a statement, and this is a go= od one.
> > > It doesn't make any recommendations about monitoring or = notifications.
> > > I think that (absence) is also appropriate at this point. > >
> > I agree that it is a feature to be silent about things this state= ment is
not
> > talking about.
> >
> > /js
>
> It may be a feature to the OPS area, but it is not a feature as far as= the
> audience
> of the statement is concerned (I speak as one of the latter, and one w= ho's
> asked
> for a statement about notifications).
>
> It sounds like the silence is due to lack of any consensus or simple answer.
> The lack of a simple consensus answer is a problem, not a feature.
> But that's the current world we live in.
>
> -Dave
>
>
> _______________________________________________
> OPS-AREA mailing list
> OPS-AREA@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/ops-area

_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area

--001a11c2b3caac50c604f2a30c75-- From nobody Mon Feb 17 16:20:34 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B4A1A0541 for ; Mon, 17 Feb 2014 16:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.749 X-Spam-Level: X-Spam-Status: No, score=-9.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTnBJ-VtrE-l for ; Mon, 17 Feb 2014 16:20:31 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 437FF1A051A for ; Mon, 17 Feb 2014 16:20:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=541; q=dns/txt; s=iport; t=1392682829; x=1393892429; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=CcLkbsns8zNBeE6uIyssg8ZhUAxmP0U7Zjibj3INl4U=; b=IuFi1KAgCvPF6vAYjD23P3KlizAskuV7brZDS6KeSV963YETApllNOtz 1EyuehMxYk+n4lslpNohpZbjrPJZEPoeRmA0roFCe9x3HQTUUVXyOIdiv 2fBlz2tcgnnfrl3Y1Yx+LvTzzj7PKzR8PMOHmbInNMfo9yuI8qHRpUBJU 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFANilAlOQ/khL/2dsb2JhbABZgwa9T4MKgRYWdIIlAQEBBDhAEQsYCRYPCQMCAQIBRQYBDAgBAYgBymkXjwiEOAEDmCyGR4tcgy47 X-IronPort-AV: E=Sophos;i="4.95,864,1384300800"; d="scan'208";a="4677923" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 18 Feb 2014 00:20:27 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1I0KR9D013534; Tue, 18 Feb 2014 00:20:27 GMT Message-ID: <5302A74B.4050008@cisco.com> Date: Tue, 18 Feb 2014 01:20:27 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Balazs Lengyel , "ops-area@ietf.org" , =?ISO-8859-1?Q?Attila_Mih=E1ly?= References: <52FD65DD.4090609@cisco.com> <52FE2961.4040403@ericsson.com> <20140214143631.GC88879@elstar.local> <52FE2A30.2070708@ericsson.com> <20140214145818.GA89076@elstar.local> In-Reply-To: <20140214145818.GA89076@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/TdPGCt8PTDi9DQ7szzg-d3qQ0IA Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 00:20:33 -0000 On 14/02/2014 15:58, Juergen Schoenwaelder wrote: > On Fri, Feb 14, 2014 at 03:37:36PM +0100, Balazs Lengyel wrote: >> The updates are not persistent, they are operational state. > The statement starting this thread was primarily about persistent > configuration state. And the basic NETCONF options do not modify > operational state, as you know (but of course one can add new > RPCs). But you asked Benoit, so I will let him answer. ;-) No perfect answer at this point. However, Martin provided a good summary. Regards, Benoit From nobody Mon Feb 17 16:25:27 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB571A0291 for ; Mon, 17 Feb 2014 16:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzyAMF6sP5Cp for ; Mon, 17 Feb 2014 16:25:24 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6A01A00CB for ; Mon, 17 Feb 2014 16:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2241; q=dns/txt; s=iport; t=1392683122; x=1393892722; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=IdcKuPQhGKy55hGvGoG2WSTiLZngLAIreDUpGeLA0xc=; b=DY1r0tSGNdijip5+beAYA5poigSWVxZ2ADB5x52A9UUdgG82VlG4FDho rcBgIsHR8MrC9H7zyjCOmLl12JhP81OOq+p31ZObOTRzAdz7lhVFScaf5 xObRHfCDKuElbieLLy7f0ElBouDaRKOzZpmm9rbNCK5eRz28lxdBHLPMB o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAK+nAlOQ/khR/2dsb2JhbABZgwbAWoEWFnSCJQEBAQQ4QA0ECxUBCxYPCQMCAQIBRQYBDAYCAQGIAcp6F48IhDgBA5gshkeLXIMuOw X-IronPort-AV: E=Sophos;i="4.95,864,1384300800"; d="scan'208";a="5345444" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 18 Feb 2014 00:25:20 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1I0PK9V014730; Tue, 18 Feb 2014 00:25:20 GMT Message-ID: <5302A870.1070202@cisco.com> Date: Tue, 18 Feb 2014 01:25:20 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "t.petch" , ops-area@ietf.org References: <52FD65DD.4090609@cisco.com> <028e01cf2995$bef7a3c0$4001a8c0@gateway.2wire.net> In-Reply-To: <028e01cf2995$bef7a3c0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/iiWfitMzmnL9fYM8a8PmVJyXO5g Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANGmodules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 00:25:26 -0000 Hi Tom, The important questions are: - will the writable aspects of the MIB module be implemented by the vendors (basically requested by the operators)? - will the writable aspects be used by the NMS'? Regards, Benoit > ----- Original Message ----- > From: "Benoit Claise" > To: > Sent: Friday, February 14, 2014 12:39 AM >> Dear all, >> >> We occasionally see read-write MIB module proposals within the IETF. >> However, the write capabilities of those MIB modules are rarely > implemented. >> While discussing this issue with the MIB doctors, we arrive to the >> conclusion that it's now time to set the direction for future MIB >> developments within the IETF. Basically, let's not specify read-write >> MIB modules unless we have a good reason. Read-only MIB modules are >> still fine though, as SNMP is clearly used for monitoring purposes. >> >> Here is the statement we came up with: >> >> The OPS area recommends the use of NETCONF/YANG standards for >> configuration. IETF working groups are therefore encouraged to use >> the NETCONF/YANG standards for configuration, specifically in new >> charters. SNMP MIB modules modifying persistent configuration > state >> should only be produced by working groups in cases of clear > utility >> and consensus to use SNMP write operations for configuration. >> >> Ideally, this should become an IESG statement. >> Your feedback is most welcome. > You probably know that there is currently a consensus call in progress > over > > "Please indicate Support or Oppose for this MIB > (draft-ietf-mpls-tp-te-mib) to be read-only." > > and I was pleasantly surprised to see opposition, albeit with one > opponent later changing their mind (perhaps they were sat on from a > height:-). I don't see much sign of Netxxxx in the mpls arena but there > is a need there for configuration, since there need not be a control > plane to set things up. Perhaps writable MIB modules will still be with > us in the distant future in some corners of the Internet.. > > Ideally, this idea would be fleshed out in an I-D. > > Tom Petch > >> Regards, the MIB doctors & Benoit > . > From nobody Mon Feb 17 16:38:46 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7515D1A01E9 for ; Mon, 17 Feb 2014 16:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oer3aaEK00H for ; Mon, 17 Feb 2014 16:38:43 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3593C1A0291 for ; Mon, 17 Feb 2014 16:38:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13521; q=dns/txt; s=iport; t=1392683920; x=1393893520; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=7QNKJepuoqfQ37YfbfLtpAJVPfBJTQpAucXjl33pemo=; b=MkHAaGZ2jYPgoVI4kzOFhd9yhqfXkYYCYuSXQRd7gYm3qMcNm4NjLnfu hHV2WM5OGS/3o/SnplMhHjG171f1O/YaT0x7sp9VvKzXkjAl0B4hvyC3Q wTa4pHUu6Y9kmeOUQxkzkRZbuzamH0EnHzPQGKFa2Z0OFNhF6SWJvc6GE k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0FADmrAlOQ/khL/2dsb2JhbABWA4MGOIk2tmyBFhZ0giUBAQEDAQEBAWsKAQwECxEEAQEBCRYIBwkDAgECARUfCQgGAQwBBQIBAYdtAwkIDcJCCIgUEwSOcRAHBguEJwSYLIZHi1yDLjs X-IronPort-AV: E=Sophos;i="4.95,864,1384300800"; d="scan'208,217";a="5346158" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 18 Feb 2014 00:38:38 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1I0ccc5019948; Tue, 18 Feb 2014 00:38:38 GMT Message-ID: <5302AB8E.6020805@cisco.com> Date: Tue, 18 Feb 2014 01:38:38 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Andy Bierman , ietfdbh References: <52FD65DD.4090609@cisco.com> <21249.55502.863663.945186@Simons-MacBook-Air-35499.local> <20140217095405.GA96343@elstar.local> <00a401cf2c39$abb41ea0$031c5be0$@comcast.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050507030207080600030800" Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/II3Tc1KX8FnA7JPCvyS74ro2-1s Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 00:38:45 -0000 This is a multi-part message in MIME format. --------------050507030207080600030800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear all, As pointed by Simon, Jürgen, Dan, Bert, Joan, yes, it was a feature not to speak about monitoring in this statement. If we do, then why not Fault, Accounting, Performance? If we take on the task to specify all FCAP aspects, this will be too big of a job for an IESG statement. However, as I mentioned multiple times, I'll work on this ... I have 2 years (to try) to achieve that. I foresee a lot of discussions. So, I would prefer to keep this statement purely for configuration. Regards, Benoit. > Hi, > > Note that none of the people asking for more text have provided any > proposed changes. > > WGs should use the monitoring protocol(s) that best fit their > requirements. > > How's that? > > Not sure it is worth the effort to create a cookbook > for all possible requirements that could occur, or > try to give meaningful guidance in 1 or 2 sentences. > > > Andy > > On Mon, Feb 17, 2014 at 3:40 PM, ietfdbh > wrote: > > I don't think remaining silent is a feature, when WGs have asked for > guidance. > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > > -----Original Message----- > > From: OPS-AREA [mailto:ops-area-bounces@ietf.org > ] On Behalf Of Dave > > Thaler > > Sent: Monday, February 17, 2014 2:23 PM > > To: Juergen Schoenwaelder; Simon Leinen > > Cc: ops-area@ietf.org > > Subject: Re: [OPS-AREA] configuration: writable MIB modules versus > > NETCONF/YANG modules > > > > > -----Original Message----- > > > From: OPS-AREA [mailto:ops-area-bounces@ietf.org > ] On Behalf Of Juergen > > > Schoenwaelder > > > Sent: Monday, February 17, 2014 1:54 AM > > > To: Simon Leinen > > > Cc: ops-area@ietf.org > > > Subject: Re: [OPS-AREA] configuration: writable MIB modules versus > > > NETCONF/YANG modules > > > > > > On Mon, Feb 17, 2014 at 10:39:26AM +0100, Simon Leinen wrote: > > > > Benoit Claise writes: > > > > > Here is the statement we came up with: > > > > > > > > > The OPS area recommends the use of NETCONF/YANG > standards for > > > > > configuration. IETF working groups are therefore > encouraged to > > > > > use the NETCONF/YANG standards for configuration, > specifically > > > > > in new charters. SNMP MIB modules modifying persistent > > > > > configuration state should only be produced by working > groups in > > > > > cases of clear utility and consensus to use SNMP write > > > > > operations for configuration. > > > > > > > > > Ideally, this should become an IESG statement. > > > > > Your feedback is most welcome. > > > > > > > > Agree - it's time for such a statement, and this is a good one. > > > > It doesn't make any recommendations about monitoring or > notifications. > > > > I think that (absence) is also appropriate at this point. > > > > > > I agree that it is a feature to be silent about things this > statement is > not > > > talking about. > > > > > > /js > > > > It may be a feature to the OPS area, but it is not a feature as > far as the > > audience > > of the statement is concerned (I speak as one of the latter, and > one who's > > asked > > for a statement about notifications). > > > > It sounds like the silence is due to lack of any consensus or simple > answer. > > The lack of a simple consensus answer is a problem, not a feature. > > But that's the current world we live in. > > > > -Dave > > > > > > _______________________________________________ > > OPS-AREA mailing list > > OPS-AREA@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-area > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > > > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area --------------050507030207080600030800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

As pointed by Simon, Jürgen, Dan, Bert, Joan, yes, it was a feature not to speak about monitoring in this statement. If we do, then why not Fault, Accounting, Performance?
If we take on the task to specify all FCAP aspects, this will be too big of a job for an IESG statement. However, as I mentioned multiple times, I'll work on this ... I have 2 years (to try) to achieve that. I foresee a lot of discussions.

So, I would prefer to keep this statement purely for configuration.

Regards, Benoit.
Hi,

Note that none of the people asking for more text have provided any
proposed changes.

   WGs should use the monitoring protocol(s) that best fit their requirements.

How's that?

Not sure it is worth the effort to create a cookbook
for all possible requirements that could occur, or
try to give meaningful guidance in 1 or 2 sentences.


Andy

On Mon, Feb 17, 2014 at 3:40 PM, ietfdbh <ietfdbh@comcast.net> wrote:
I don't think remaining silent is a feature, when WGs have asked for
guidance.

David Harrington
ietfdbh@comcast.net
+1-603-828-1401
> -----Original Message-----
> From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Dave
> Thaler
> Sent: Monday, February 17, 2014 2:23 PM
> To: Juergen Schoenwaelder; Simon Leinen
> Cc: ops-area@ietf.org
> Subject: Re: [OPS-AREA] configuration: writable MIB modules versus
> NETCONF/YANG modules
>
> > -----Original Message-----
> > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Juergen
> > Schoenwaelder
> > Sent: Monday, February 17, 2014 1:54 AM
> > To: Simon Leinen
> > Cc: ops-area@ietf.org
> > Subject: Re: [OPS-AREA] configuration: writable MIB modules versus
> > NETCONF/YANG modules
> >
> > On Mon, Feb 17, 2014 at 10:39:26AM +0100, Simon Leinen wrote:
> > > Benoit Claise writes:
> > > > Here is the statement we came up with:
> > >
> > > >     The OPS area recommends the use of NETCONF/YANG standards for
> > > >     configuration. IETF working groups are therefore encouraged to
> > > >     use the NETCONF/YANG standards for configuration, specifically
> > > >     in new charters. SNMP MIB modules modifying persistent
> > > >     configuration state should only be produced by working groups in
> > > >     cases of clear utility and consensus to use SNMP write
> > > >     operations for configuration.
> > >
> > > > Ideally, this should become an IESG statement.
> > > > Your feedback is most welcome.
> > >
> > > Agree - it's time for such a statement, and this is a good one.
> > > It doesn't make any recommendations about monitoring or notifications.
> > > I think that (absence) is also appropriate at this point.
> >
> > I agree that it is a feature to be silent about things this statement is
not
> > talking about.
> >
> > /js
>
> It may be a feature to the OPS area, but it is not a feature as far as the
> audience
> of the statement is concerned (I speak as one of the latter, and one who's
> asked
> for a statement about notifications).
>
> It sounds like the silence is due to lack of any consensus or simple
answer.
> The lack of a simple consensus answer is a problem, not a feature.
> But that's the current world we live in.
>
> -Dave
>
>
> _______________________________________________
> OPS-AREA mailing list
> OPS-AREA@ietf.org
> https://www.ietf.org/mailman/listinfo/ops-area

_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area



_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area

--------------050507030207080600030800-- From nobody Mon Feb 17 16:41:17 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392BA1A0431 for ; Mon, 17 Feb 2014 16:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gi0yQbMhzA8Z for ; Mon, 17 Feb 2014 16:41:13 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 199441A0291 for ; Mon, 17 Feb 2014 16:41:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1676; q=dns/txt; s=iport; t=1392684070; x=1393893670; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=55D3zZI8Lih20uaUKVRTQitNz78zZQmwg7Mg5TCjVp0=; b=b9bPagWVwcwswSvNqu9NOX2/2e3wDeJt6apt3EMwLWkByZvYyowZcRWZ IadiRhWmK17F50DdWe2XeKVUedK8W7V5W0vcTSeDC5qfv4owbzlIZdf0F 0ktmzY1xoqhp7H7ubU5DrSMRDUYVV/irwyGZP6S+MbEAN2ekMJEmSCKEi E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFADmrAlOQ/khN/2dsb2JhbABZgwY4wCKBFhZ0giUBAQEEAQEBGhs2BAYBDAQLEQQBAQEJFggHCQMCAQIBFR8JCAYNAQUCAQGIAQ3KXhMEjwEHBoQyAQOYLIZHi1yDLjs X-IronPort-AV: E=Sophos;i="4.95,864,1384300800"; d="scan'208";a="5346303" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 18 Feb 2014 00:41:09 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1I0f9HM022659; Tue, 18 Feb 2014 00:41:09 GMT Message-ID: <5302AC25.6050704@cisco.com> Date: Tue, 18 Feb 2014 01:41:09 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Thomas D. Nadeau" , "Romascanu, Dan (Dan)" References: <5267FF2A.2060903@cisco.com> <52FD9FF8.5030708@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA2E418930@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/SOoWNL3sz2sYnup2zEHJuPJi7SM Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] call for agenda items for the OPSAREA open meeting at IETF-89 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 00:41:15 -0000 Tom, Dan, Being optimistic, I hope that we can agree on this before the IETF meeting. If not, then yes, we should probably discuss it. Regards, Benoit > I agree. I've already asked him for a slot to discuss this. If you want to help with the slot, I'd love to join up. *) > >> On Feb 16, 2014, at 7:21 AM, "Romascanu, Dan (Dan)" wrote: >> >> Hi Benoit, >> >> You may be planning to so this anyway already - I believe that it would be good to spend some time (if available) on the topic of the (non) writable MIB modules guidance. >> >> Regards, >> >> Dan >> >> >>> -----Original Message----- >>> From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Benoit >>> Claise >>> Sent: Friday, February 14, 2014 6:48 AM >>> To: ops-area@ietf.org >>> Subject: [OPS-AREA] call for agenda items for the OPSAREA open meeting at >>> IETF-89 >>> >>> Dear all, >>> >>> We are planning again for a joint OPSAWG and OPSAREA open meeting, with >>> the OPSAWG work items driving most of the agenda. The more general >>> cross-area items or those related to the relation between work in the area >>> and work out of the IETF should be part of the OPSAREA section. >>> >>> Please send us your requests for presentation and discussion slots. >>> >>> Thanks and Regards, >>> >>> Regards, Joel and Benoit >>> >>> _______________________________________________ >>> OPS-AREA mailing list >>> OPS-AREA@ietf.org >>> https://www.ietf.org/mailman/listinfo/ops-area >> _______________________________________________ >> OPS-AREA mailing list >> OPS-AREA@ietf.org >> https://www.ietf.org/mailman/listinfo/ops-area >> > . > From nobody Mon Feb 17 16:50:22 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8906A1A0168 for ; Mon, 17 Feb 2014 16:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Dbx6kzf65xt for ; Mon, 17 Feb 2014 16:50:16 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id AA4661A016A for ; Mon, 17 Feb 2014 16:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1405; q=dns/txt; s=iport; t=1392684613; x=1393894213; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=egEF7nRejFXKTCvlbIb9BJ3f2A+LYihtCRdWUmOkwKM=; b=lh5jo8feNfY6g0D8Nw4Qup9Ok2o6LQp9pFC4/DXneXa19GaHR29Sx2DW 9S6d1bTrFnuWhEgMP47R6V9AqDG88UTj5mfGP7zsdLp0PowqYqLyotNPn IdaUx/36FhDJ2ntL9gcudj9qXiL8a0dYbTcoN+wpyLcoSiLlAJACUSG46 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAAatAlOQ/khR/2dsb2JhbABZgwY4v1NPgRYWdIIlAQEBAwEBAQE1NgoBBQsLIRYPCQMCAQIBFTAGAQwBBQIBAQWHdAgNyl4Xji0DAQFPB4Q4AQOYLIEyhRWLXIMuO4E1 X-IronPort-AV: E=Sophos;i="4.95,864,1384300800"; d="scan'208";a="4679603" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 18 Feb 2014 00:50:12 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1I0oCQc022790; Tue, 18 Feb 2014 00:50:12 GMT Message-ID: <5302AE44.8050906@cisco.com> Date: Tue, 18 Feb 2014 01:50:12 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Randy Bush , Warren Kumari References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/BJX_QIiIMKvFKr106KTiQ1T8WKI Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] [OPSAWG] Preliminary OPSAWG agenda. X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 00:50:19 -0000 Randy, I changed the mailer from opsawg to ops-area, where the discussion takes place. I understand from your comment below that you support the statement at http://www.ietf.org/mail-archive/web/ops-area/current/msg01115.html. This is great, and was expected btw :-) I have no intention to replay history (ideally, I don't even want to discuss this topic during the OPS-AREA meeting), but I want to carve this in stone with an IESG statement. Believe it or not, we still see some development of writable MIB modules in the IETF. Regards, Benoit > warren and any other friendly opsawg chairs: > > i have been told that you are actually wasting air time discussing snmp > write for configuration of devices. i thought we had and finished that > discussion over a decade ago at ietf 51 in london. we were in a large > room with many operators, and i asked all those operators who had snmp > write enabled to raise their hands. zero, count them zero, hands went > up. this resulted in the formation of the interminable netconf effort. > > and i have the tee shirt, see > > just because we're going to be back in london does not mean we need to > replay history. > > randy > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Mon Feb 17 23:15:38 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9702F1A043B for ; Mon, 17 Feb 2014 23:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1O0e3DB8ob_L for ; Mon, 17 Feb 2014 23:15:33 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 014A41A05DD for ; Mon, 17 Feb 2014 23:15:28 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 86D0A1005; Tue, 18 Feb 2014 08:15:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ElTIKchLR4A9; Tue, 18 Feb 2014 08:15:23 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Tue, 18 Feb 2014 08:15:23 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C5C5520026; Tue, 18 Feb 2014 08:15:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id soMHuAELGt-B; Tue, 18 Feb 2014 08:15:22 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D1EAC20015; Tue, 18 Feb 2014 08:15:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B16002B56D53; Tue, 18 Feb 2014 08:15:19 +0100 (CET) Date: Tue, 18 Feb 2014 08:15:19 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140218071519.GB1414@elstar.local> Mail-Followup-To: Andy Bierman , ietfdbh , Dave Thaler , Simon Leinen , ops-area@ietf.org References: <52FD65DD.4090609@cisco.com> <21249.55502.863663.945186@Simons-MacBook-Air-35499.local> <20140217095405.GA96343@elstar.local> <00a401cf2c39$abb41ea0$031c5be0$@comcast.net> 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) Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/LPxPmbunXxAGsIefN7o4dP64pB0 Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 07:15:35 -0000 On Mon, Feb 17, 2014 at 04:06:52PM -0800, Andy Bierman wrote: > Hi, > > Note that none of the people asking for more text have provided any > proposed changes. > > WGs should use the monitoring protocol(s) that best fit their > requirements. > > How's that? I do not see the value of such a statement since I assume this to be the default for any protocol selection. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Feb 17 23:28:09 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639001A0043 for ; Mon, 17 Feb 2014 23:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWK92dtuX_UG for ; Mon, 17 Feb 2014 23:28:05 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0A41A0449 for ; Mon, 17 Feb 2014 23:28:05 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4B4CDFF7; Tue, 18 Feb 2014 08:28:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 2mc30coRu376; Tue, 18 Feb 2014 08:28:01 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Tue, 18 Feb 2014 08:28:01 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 44B0820027; Tue, 18 Feb 2014 08:28:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id U-KVj3XCHk8f; Tue, 18 Feb 2014 08:28:01 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D363A20015; Tue, 18 Feb 2014 08:28:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BB2412B56D9D; Tue, 18 Feb 2014 08:27:59 +0100 (CET) Date: Tue, 18 Feb 2014 08:27:59 +0100 From: Juergen Schoenwaelder To: ietfdbh Message-ID: <20140218072759.GC1414@elstar.local> Mail-Followup-To: ietfdbh , 'Dave Thaler' , 'Simon Leinen' , ops-area@ietf.org References: <52FD65DD.4090609@cisco.com> <21249.55502.863663.945186@Simons-MacBook-Air-35499.local> <20140217095405.GA96343@elstar.local> <00a401cf2c39$abb41ea0$031c5be0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a401cf2c39$abb41ea0$031c5be0$@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/mKNK6qSKvk3XTr2YxjqjbWdGmzM Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 07:28:07 -0000 On Mon, Feb 17, 2014 at 06:40:41PM -0500, ietfdbh wrote: > I don't think remaining silent is a feature, when WGs have asked for > guidance. I do not think David's protocol selection problem warrants an IESG statement. Protocol selection is a question that many WGs face. It continue to believe that it is a feature that the proposed IESG statement stays focused. If people believe there could be an IESG statement concerning notifications, go ahead and draft text, start a discussion thread and build consensus around it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Feb 17 23:55:25 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C291A042F for ; Mon, 17 Feb 2014 23:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlTMhugEKjdp for ; Mon, 17 Feb 2014 23:55:21 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 10E021A0056 for ; Mon, 17 Feb 2014 23:55:20 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id c9so24929165qcz.41 for ; Mon, 17 Feb 2014 23:55:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=D7v9B1aIBlQb7EK9Hz9ze0+jPJTRhGvrdbd1MGghbJ8=; b=I9dB8cKQRktp1a1qKtzWym97ZeETSXurA6DrzWmjTLi3Yq89/g/LczisvxyYhhTxcP ixULLnuaf3mP1UvZPHvPC85kUH4scX/lXGt190EOvVcK5sId0UJb7DFTum5mhFGwZAmC y7xaQ7zSgVn+ohZ4k0FyBvFp9DM9FTI/px+VjaTwJ4AqS692Tt81/5ykmWmZc6oQJ1Xd dWqkaflI0CHPYr1PjGXg4KSXglIZfr053q7o4IrkHf3LSitjiyDca5U/CAczPn4o5x3B z1Ulvd7ZKMGwPT4kk2hf5Y5XEeEnQ7jpgpTV71wo0G8l1S2YXkAYUSjmYIH0c1WGLA3Y 01dw== X-Gm-Message-State: ALoCoQmryRYAh3ryp5Q6PyugS1btyASHU/mIKLR0vkORnzcvct3AJERcK1sAMxf5SbFeL/SMj2zb MIME-Version: 1.0 X-Received: by 10.224.127.202 with SMTP id h10mr41013519qas.23.1392710118139; Mon, 17 Feb 2014 23:55:18 -0800 (PST) Received: by 10.140.98.130 with HTTP; Mon, 17 Feb 2014 23:55:17 -0800 (PST) In-Reply-To: <20140218071519.GB1414@elstar.local> References: <52FD65DD.4090609@cisco.com> <21249.55502.863663.945186@Simons-MacBook-Air-35499.local> <20140217095405.GA96343@elstar.local> <00a401cf2c39$abb41ea0$031c5be0$@comcast.net> <20140218071519.GB1414@elstar.local> Date: Mon, 17 Feb 2014 23:55:17 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , ietfdbh , Dave Thaler , Simon Leinen , ops-area Content-Type: multipart/alternative; boundary=001a11c2bf04ddfaee04f2a997e1 Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/cRiBRemgpTJyQ5K0m8Z4cvD74U4 Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 07:55:23 -0000 --001a11c2bf04ddfaee04f2a997e1 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 17, 2014 at 11:15 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Feb 17, 2014 at 04:06:52PM -0800, Andy Bierman wrote: > > Hi, > > > > Note that none of the people asking for more text have provided any > > proposed changes. > > > > WGs should use the monitoring protocol(s) that best fit their > > requirements. > > > > How's that? > > I do not see the value of such a statement since I assume this to be > the default for any protocol selection. > > OK -- so no need for any statement on monitoring since there are no specific recommendations to make. > /js > Andy --001a11c2bf04ddfaee04f2a997e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 17, 2014 at 11:15 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Feb 17, 2014 at 04:06:52PM -0800, An= dy Bierman wrote:
> Hi,
>
> Note that none of the people asking for more text have provided any > proposed changes.
>
> =A0 =A0WGs should use the monitoring protocol(s) that best fit their > requirements.
>
> How's that?

I do not see the value of such a statement since I assume this to be
the default for any protocol selection.


OK -- so no need for any statement on monitoring sin= ce there are no specific
recommendations to make.
=A0
/js

Andy


--001a11c2bf04ddfaee04f2a997e1-- From nobody Tue Feb 18 00:00:49 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7779A1A037E for ; Tue, 18 Feb 2014 00:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.703 X-Spam-Level: X-Spam-Status: No, score=-6.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSHdbX5cZ8_E for ; Tue, 18 Feb 2014 00:00:45 -0800 (PST) Received: from aer-iport-3.cisco.com (unknown [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 680EE1A0317 for ; Tue, 18 Feb 2014 00:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4678; q=dns/txt; s=iport; t=1392710442; x=1393920042; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=M5olPSPqQZwp+E+KQFKNRWnyXggSvSyYAIsRqbyjHJU=; b=kRQh63r7kvOv0Y2LDr4rKgGh45sRSUAUmoDyn5Da1K7ixemrXoNV70/I 9dVE4KdIXYvAHdxQZbuYCC3QbaFMARerlNMxYhnEJ+Sw16HMnon89VSm9 /ESUL5YrMjMd8ikVOk6v69BpYOWXxevp5xYY9pO8clHVlNL99+ALDDYaZ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwFANASA1OQ/khR/2dsb2JhbABZgwY4iTa2cIEVFnSCJQEBAQQBAQFrChELEAgJFggHCQMCAQIBFR8RBgEMBgIBAYgBDcsREwSPCIQ4BJgshkeLXIMuOw X-IronPort-AV: E=Sophos;i="4.97,500,1389744000"; d="scan'208,217";a="616458" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-3.cisco.com with ESMTP; 18 Feb 2014 08:00:41 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1I80duh019544; Tue, 18 Feb 2014 08:00:40 GMT Message-ID: <53031327.9000606@cisco.com> Date: Tue, 18 Feb 2014 09:00:39 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Andy Bierman , Juergen Schoenwaelder , ietfdbh , Dave Thaler , Simon Leinen , ops-area References: <52FD65DD.4090609@cisco.com> <21249.55502.863663.945186@Simons-MacBook-Air-35499.local> <20140217095405.GA96343@elstar.local> <00a401cf2c39$abb41ea0$031c5be0$@comcast.net> <20140218071519.GB1414@elstar.local> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050801000408010001030105" Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/4s0_4CijAp0x-E_9HAVG-ViFhe8 Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 08:00:46 -0000 This is a multi-part message in MIME format. --------------050801000408010001030105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 18/02/2014 08:55, Andy Bierman wrote: > > > > On Mon, Feb 17, 2014 at 11:15 PM, Juergen Schoenwaelder > > wrote: > > On Mon, Feb 17, 2014 at 04:06:52PM -0800, Andy Bierman wrote: > > Hi, > > > > Note that none of the people asking for more text have provided any > > proposed changes. > > > > WGs should use the monitoring protocol(s) that best fit their > > requirements. > > > > How's that? > > I do not see the value of such a statement since I assume this to be > the default for any protocol selection. > > > OK -- so no need for any statement on monitoring since there are no > specific > recommendations to make. Exactly. Regards, Benoit > > /js > > > Andy > > > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area --------------050801000408010001030105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 18/02/2014 08:55, Andy Bierman wrote:



On Mon, Feb 17, 2014 at 11:15 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Feb 17, 2014 at 04:06:52PM -0800, Andy Bierman wrote:
> Hi,
>
> Note that none of the people asking for more text have provided any
> proposed changes.
>
>    WGs should use the monitoring protocol(s) that best fit their
> requirements.
>
> How's that?

I do not see the value of such a statement since I assume this to be
the default for any protocol selection.


OK -- so no need for any statement on monitoring since there are no specific
recommendations to make.
Exactly.

Regards, Benoit
 
/js

Andy




_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area

--------------050801000408010001030105-- From nobody Tue Feb 18 02:37:22 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC06A1A0664 for ; Tue, 18 Feb 2014 02:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcZuDPWw9Rb9 for ; Tue, 18 Feb 2014 02:37:17 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0016.outbound.protection.outlook.com [213.199.154.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF541A0663 for ; Tue, 18 Feb 2014 02:37:17 -0800 (PST) Received: from AMXPRD0111HT001.eurprd01.prod.exchangelabs.com (157.56.250.117) by DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) with Microsoft SMTP Server (TLS) id 15.0.883.10; Tue, 18 Feb 2014 10:37:13 +0000 Message-ID: <071d01cf2c94$b433a860$4001a8c0@gateway.2wire.net> From: t.petch To: Benoit Claise References: <52FD65DD.4090609@cisco.com> <21249.55502.863663.945186@Simons-MacBook-Air-35499.local> <20140217095405.GA96343@elstar.local> <00a401cf2c39$abb41ea0$031c5be0$@comcast.net> <5302AB8E.6020805@cisco.com> Date: Tue, 18 Feb 2014 10:30:51 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.250.117] X-ClientProxiedBy: DBXPR07CA020.eurprd07.prod.outlook.com (10.141.8.178) To DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) X-Forefront-PRVS: 0126A32F74 X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(377454003)(51444003)(5170?= =?iso-8859-1?Q?4005)(13464003)(24454002)(189002)(199002)(84392001)(853060?= =?iso-8859-1?Q?02)(44736004)(87266001)(87286001)(47736001)(50986001)(4797?= =?iso-8859-1?Q?6001)(74706001)(50226001)(74876001)(49866001)(4396001)(636?= =?iso-8859-1?Q?96002)(47776003)(65816001)(80022001)(74662001)(79102001)(6?= =?iso-8859-1?Q?2236002)(74502001)(44716002)(31966008)(47446002)(66066001)?= =?iso-8859-1?Q?(33646001)(56816005)(90146001)(89996001)(19580405001)(8332?= =?iso-8859-1?Q?2001)(56776001)(50466002)(19580395003)(59766001)(77982001)?= =?iso-8859-1?Q?(74366001)(61296002)(88136002)(62966002)(69226001)(8134200?= =?iso-8859-1?Q?1)(81542001)(23756003)(93136001)(94946001)(93516002)(93916?= =?iso-8859-1?Q?002)(95666001)(87976001)(80976001)(76482001)(92726001)(543?= =?iso-8859-1?Q?16002)(94316002)(14496001)(51856001)(46102001)(85852003)(8?= =?iso-8859-1?Q?3072002)(53806001)(92566001)(86362001)(95416001)(76786001)?= =?iso-8859-1?Q?(76796001)(42186004)(77096001)(77156001)(74416001)(7726001?= =?iso-8859-1?Q?);DIR:OUT;SFP:1101;SCL:1;SRVR:DB3PR07MB057;H:AMXPRD0111HT0?= =?iso-8859-1?Q?01.eurprd01.prod.exchangelabs.com;CLIP:157.56.250.117;FPR:?= =?iso-8859-1?Q?EE74F014.82C6D7A2.B1C5BA74.4EE59DCF.2045E;PTR:InfoNoRecord?= =?iso-8859-1?Q?s;MX:1;A:0;LANG:en;?= X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/GW0ZK2dKAquyoGQB7rCCpIX4e5g Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 10:37:21 -0000 ----- Original Message ----- From: "Benoit Claise" To: "Andy Bierman" ; "ietfdbh" Cc: Sent: Tuesday, February 18, 2014 12:38 AM > Dear all, > > As pointed by Simon, Jürgen, Dan, Bert, Joan, yes, it was a feature not > to speak about monitoring in this statement. If we do, then why not > Fault, Accounting, Performance? Because we already have 45 pages gently maturing on the topic (draft-ietf-opsawg-oam-overview)? I think that that I-D well demonstrates the challenges of producing satisfactory guidance on the work of the IETF. Tom Petch > If we take on the task to specify all FCAP aspects, this will be too big > of a job for an IESG statement. However, as I mentioned multiple times, > I'll work on this ... I have 2 years (to try) to achieve that. I foresee > a lot of discussions. > > So, I would prefer to keep this statement purely for configuration. > > Regards, Benoit. > > Hi, > > > > Note that none of the people asking for more text have provided any > > proposed changes. > > > > WGs should use the monitoring protocol(s) that best fit their > > requirements. > > > > How's that? > > > > Not sure it is worth the effort to create a cookbook > > for all possible requirements that could occur, or > > try to give meaningful guidance in 1 or 2 sentences. > > > > > > Andy > > > > On Mon, Feb 17, 2014 at 3:40 PM, ietfdbh > > wrote: > > > > I don't think remaining silent is a feature, when WGs have asked for > > guidance. > > > > David Harrington > > ietfdbh@comcast.net > > +1-603-828-1401 > > > -----Original Message----- > > > From: OPS-AREA [mailto:ops-area-bounces@ietf.org > > ] On Behalf Of Dave > > > Thaler > > > Sent: Monday, February 17, 2014 2:23 PM > > > To: Juergen Schoenwaelder; Simon Leinen > > > Cc: ops-area@ietf.org > > > > -----Original Message----- > > > > From: OPS-AREA [mailto:ops-area-bounces@ietf.org > > ] On Behalf Of Juergen > > > > Schoenwaelder > > > > Sent: Monday, February 17, 2014 1:54 AM > > > > To: Simon Leinen > > > > Cc: ops-area@ietf.org > > > > > > > > On Mon, Feb 17, 2014 at 10:39:26AM +0100, Simon Leinen wrote: > > > > > Benoit Claise writes: > > > > > > Here is the statement we came up with: > > > > > > > > > > > The OPS area recommends the use of NETCONF/YANG > > standards for > > > > > > configuration. IETF working groups are therefore > > encouraged to > > > > > > use the NETCONF/YANG standards for configuration, > > specifically > > > > > > in new charters. SNMP MIB modules modifying persistent > > > > > > configuration state should only be produced by working > > groups in > > > > > > cases of clear utility and consensus to use SNMP write > > > > > > operations for configuration. > > > > > > > > > > > Ideally, this should become an IESG statement. > > > > > > Your feedback is most welcome. > > > > > > > > > > Agree - it's time for such a statement, and this is a good one. > > > > > It doesn't make any recommendations about monitoring or > > notifications. > > > > > I think that (absence) is also appropriate at this point. > > > > > > > > I agree that it is a feature to be silent about things this > > statement is > > not > > > > talking about. > > > > > > > > /js > > > > > > It may be a feature to the OPS area, but it is not a feature as > > far as the > > > audience > > > of the statement is concerned (I speak as one of the latter, and > > one who's > > > asked > > > for a statement about notifications). > > > > > > It sounds like the silence is due to lack of any consensus or simple > > answer. > > > The lack of a simple consensus answer is a problem, not a feature. > > > But that's the current world we live in. > > > > > > -Dave From nobody Tue Feb 18 05:52:09 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6098B1A04D7 for ; Tue, 18 Feb 2014 05:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVCFvwbYo4-S for ; Tue, 18 Feb 2014 05:52:05 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 459B81A01DE for ; Tue, 18 Feb 2014 05:52:05 -0800 (PST) Received: from [192.168.1.106] (static-72-71-250-37.cncdnh.fast04.myfairpoint.net [72.71.250.37]) by lucidvision.com (Postfix) with ESMTP id 1F27426F79BE; Tue, 18 Feb 2014 08:52:02 -0500 (EST) References: <52FD65DD.4090609@cisco.com> <21249.55502.863663.945186@Simons-MacBook-Air-35499.local> <20140217095405.GA96343@elstar.local> <00a401cf2c39$abb41ea0$031c5be0$@comcast.net> <20140218071519.GB1414@elstar.local> Mime-Version: 1.0 (1.0) In-Reply-To: <20140218071519.GB1414@elstar.local> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9EFA4E3B-0FFF-442B-B81A-93E06F9A48AE@lucidvision.com> X-Mailer: iPad Mail (11B554a) From: "Thomas D. Nadeau" Date: Tue, 18 Feb 2014 08:52:00 -0500 To: Juergen Schoenwaelder Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/dxm3rqqCj4DKqnrUD3HQuu9aplQ Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 13:52:07 -0000 > On Feb 18, 2014, at 2:15 AM, Juergen Schoenwaelder wrote: >=20 >> On Mon, Feb 17, 2014 at 04:06:52PM -0800, Andy Bierman wrote: >> Hi, >>=20 >> Note that none of the people asking for more text have provided any >> proposed changes. >>=20 >> WGs should use the monitoring protocol(s) that best fit their >> requirements. >>=20 >> How's that? >=20 > I do not see the value of such a statement since I assume this to be > the default for any protocol selection. What we need is a statement as Benoit proposed because there is a *= defacto* and implicit statement that WGs should use SNMP for management - ju= st look at most charters.=20 --Tom >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area >=20 From nobody Tue Feb 18 14:09:02 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A591A04E5 for ; Tue, 18 Feb 2014 14:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T5nnlwiC2pk for ; Tue, 18 Feb 2014 14:08:57 -0800 (PST) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id 70D801A0296 for ; Tue, 18 Feb 2014 14:08:57 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q58so12296299wes.10 for ; Tue, 18 Feb 2014 14:08:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rUHMd+29MyAP79EXkboZRRZutXpQIdOy+7JeyNLoYxY=; b=ZFEh7srjrFT+lXIUCimZvoil7iGlnVsET4tt9MJxxBF0gyr9712L3ynUKnqLf19RoQ waomPLDyHa/UF8TKd97OFzO95zif9Tg97/A0XlmyrPZakxmVC4tnKu7V9o6JD710DQYa n2FxUCSKzZENISLTDGTwUHIDhEWPiduwRT05XS+3WuKuaHqdq1abi7ooKX5y+THkOIa4 Go8unl6wuUqer+2oKPW3EgIU3ORW9Rj/kx3qhZarqp7Ve/ZvKarUUw2otU9QyGHLFW42 t29EifSD4DujV/lM/j0QK/nKGFDKI8ZyswslO27N6UewOqH0M3Q+ldgcGI1S2DptTjCv NVKg== X-Gm-Message-State: ALoCoQnZdsLDGvEbUsdgmurOQN/9vAwJdeBdJZd8ZMM0SXPnh6VOvIaRKqDxw0XPB9Rq8tiJkWyM MIME-Version: 1.0 X-Received: by 10.180.77.74 with SMTP id q10mr20188010wiw.39.1392761333828; Tue, 18 Feb 2014 14:08:53 -0800 (PST) Received: by 10.194.54.167 with HTTP; Tue, 18 Feb 2014 14:08:53 -0800 (PST) X-Originating-IP: [98.244.98.35] In-Reply-To: <5302A870.1070202@cisco.com> References: <52FD65DD.4090609@cisco.com> <028e01cf2995$bef7a3c0$4001a8c0@gateway.2wire.net> <5302A870.1070202@cisco.com> Date: Tue, 18 Feb 2014 17:08:53 -0500 Message-ID: From: Warren Kumari To: Benoit Claise Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/jEQnxN-XT1YhGCZZTgl4GHEzrpQ Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANGmodules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 22:09:01 -0000 On Mon, Feb 17, 2014 at 7:25 PM, Benoit Claise wrote: > Hi Tom, > > The important questions are: > - will the writable aspects of the MIB module be implemented by the vendors > (basically requested by the operators)? Who knows if it would be implemented by the vendors, but I'm sure most operators would refuse to use it. As a test I just proposed enabling SNMP write and got some good giggles (actually I got a "Good plan! Do it with snmpv1, no one uses that.", but I'm not really able to convey the sarcasm / mocking tone in mail). I know of no large operator / network that allows write access -- I suspect that the risks are not really as bad as folk make out, but it has become network lore that snmp write is bad mojo and once something becomes lore... Things may be different in the enterprise space (I think ciscoworks tries to use snmp write). Oh, and Bay Network's Site Mangler used to -- which is why most people used BCC... W > - will the writable aspects be used by the NMS'? > > Regards, Benoit > >> ----- Original Message ----- >> From: "Benoit Claise" >> To: >> Sent: Friday, February 14, 2014 12:39 AM >>> >>> Dear all, >>> >>> We occasionally see read-write MIB module proposals within the IETF. >>> However, the write capabilities of those MIB modules are rarely >> >> implemented. >>> >>> While discussing this issue with the MIB doctors, we arrive to the >>> conclusion that it's now time to set the direction for future MIB >>> developments within the IETF. Basically, let's not specify read-write >>> MIB modules unless we have a good reason. Read-only MIB modules are >>> still fine though, as SNMP is clearly used for monitoring purposes. >>> >>> Here is the statement we came up with: >>> >>> The OPS area recommends the use of NETCONF/YANG standards for >>> configuration. IETF working groups are therefore encouraged to use >>> the NETCONF/YANG standards for configuration, specifically in new >>> charters. SNMP MIB modules modifying persistent configuration >> >> state >>> >>> should only be produced by working groups in cases of clear >> >> utility >>> >>> and consensus to use SNMP write operations for configuration. >>> >>> Ideally, this should become an IESG statement. >>> Your feedback is most welcome. >> >> You probably know that there is currently a consensus call in progress >> over >> >> "Please indicate Support or Oppose for this MIB >> (draft-ietf-mpls-tp-te-mib) to be read-only." >> >> and I was pleasantly surprised to see opposition, albeit with one >> opponent later changing their mind (perhaps they were sat on from a >> height:-). I don't see much sign of Netxxxx in the mpls arena but there >> is a need there for configuration, since there need not be a control >> plane to set things up. Perhaps writable MIB modules will still be with >> us in the distant future in some corners of the Internet.. >> >> Ideally, this idea would be fleshed out in an I-D. >> >> Tom Petch >> >>> Regards, the MIB doctors & Benoit >> >> . >> > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area From nobody Wed Feb 19 08:12:25 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29CE1A05CC for ; Wed, 19 Feb 2014 08:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbW0U7A-iSSE for ; Wed, 19 Feb 2014 08:12:21 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id E94011A05D1 for ; Wed, 19 Feb 2014 08:12:08 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15304d74d98a-1798a; Thu, 20 Feb 2014 00:09:49 +0800 (CST) X-RM-TRANSID: 2ee15304d74d98a-1798a Received: from X6X8D79D8F49E2 (unknown[125.97.246.162]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee15304d74c07b-31bc0; Thu, 20 Feb 2014 00:09:49 +0800 (CST) X-RM-TRANSID: 2ee15304d74c07b-31bc0 From: "Fan, Peng" To: References: <20140214144843.27860.28663.idtracker@ietfa.amsl.com> In-Reply-To: <20140214144843.27860.28663.idtracker@ietfa.amsl.com> Date: Thu, 20 Feb 2014 00:12:39 +0800 Message-ID: <001201cf2d8d$69c46130$3d4d2390$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIA2LgC8VeB+UqNJ2EqHiZjUs35hJpZXGPA Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/FWgQDSQsveCl8cT-YnIeLZ75Fe4 Subject: [OPS-AREA] FW: New Version Notification for draft-fan-deep-performance-visualization-00.txt X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 16:12:25 -0000 Dear all, We have posted a document discussing visualizing network performance, = and would like to get your attention and feedback. The proposal aims to = provide views of network performance for applications/systems/protocols = that desire this information to work better. Performance status can be = accessed through a unified interface, and comprehensive performance data = can be achieved by covering and processing metric values from different = areas/perspectives of network. The document is at = http://www.ietf.org/internet-drafts/draft-fan-deep-performance-visualizat= ion-00.txt. Any comments are welcome. Best regards, Peng -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Friday, February 14, 2014 10:49 PM To: Peng Fan; Peng Fan; Zhen Cao; Zhen Cao Subject: New Version Notification for = draft-fan-deep-performance-visualization-00.txt A new version of I-D, draft-fan-deep-performance-visualization-00.txt has been successfully submitted by Peng Fan and posted to the IETF = repository. Name: draft-fan-deep-performance-visualization Revision: 00 Title: Deep Performance Visualization: Use Cases, Requirements and = Framework Document date: 2014-02-14 Group: Individual Submission Pages: 7 URL: = http://www.ietf.org/internet-drafts/draft-fan-deep-performance-visualizat= ion-00.txt Status: = https://datatracker.ietf.org/doc/draft-fan-deep-performance-visualization= / Htmlized: = http://tools.ietf.org/html/draft-fan-deep-performance-visualization-00 Abstract: Providing deep performance information by the networks is expected in many use cases. This document intends to discuss a unified presentation of performance, by investigating use cases that benefit from performance information, describing relevant requirements, and proposing a framework of how the components work together to enable deep performance visualization. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Wed Feb 19 08:38:11 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3331A055A; Wed, 19 Feb 2014 08:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.704 X-Spam-Level: X-Spam-Status: No, score=-6.704 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8i4qiWJGFaFe; Wed, 19 Feb 2014 08:38:02 -0800 (PST) Received: from aer-iport-3.cisco.com (unknown [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id ADC991A0245; Wed, 19 Feb 2014 08:38:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=248; q=dns/txt; s=iport; t=1392827879; x=1394037479; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=3Zn5L4L71QbqPslgF8GIfNymMHgxxHfC2ll5DCwJlr8=; b=NtBmYiDVU/54YK22fsmMwLiTjr2JI9uwXbRr+71kVyvXJszp5cgMHDbh s4xsfKxZVTWwmxXCpT4kVkWL8UnlxCYR5dA5o+hGGav1Idckh/H19BPWQ NrwaJlyfxk2UtuaXOnvgiqOCWlE1gFHsSE05lFCUKmJMOd6vSWdzrm1c+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALrcBFOQ/khN/2dsb2JhbABZgwbCHxZ0gmR9NAJMAQwIAQGIAc1zF5MjAQOYMIZHi12DLTw X-IronPort-AV: E=Sophos;i="4.97,506,1389744000"; d="scan'208";a="740128" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-3.cisco.com with ESMTP; 19 Feb 2014 16:37:58 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1JGbvUc021194; Wed, 19 Feb 2014 16:37:57 GMT Message-ID: <5304DDE5.60209@cisco.com> Date: Wed, 19 Feb 2014 16:37:57 +0000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ops-area@ietf.org" , 89attendees@ietf.org, Joel jaeggli Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/YK5WySB0NrGHxZ4mp5i1qvRXE7g Subject: [OPS-AREA] OPS open hours office X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 16:38:06 -0000 Dear all, When: Wed 15:20 to 16:30 Where: TBD Please come to talk to us on any WG or area items, about new proposals, or about any other IETF-related business. An advanced notification would be appreciated. Regards, Joel and Benoit From nobody Thu Feb 20 01:59:06 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E6E1A009A for ; Thu, 20 Feb 2014 01:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwnJDRfMieFW for ; Thu, 20 Feb 2014 01:58:50 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0016.outbound.protection.outlook.com [213.199.154.16]) by ietfa.amsl.com (Postfix) with ESMTP id 291051A0072 for ; Thu, 20 Feb 2014 01:58:49 -0800 (PST) Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.883.10; Thu, 20 Feb 2014 09:58:44 +0000 Message-ID: <000701cf2e21$a78148a0$4001a8c0@gateway.2wire.net> From: t.petch To: Warren Kumari References: <52FD65DD.4090609@cisco.com><028e01cf2995$bef7a3c0$4001a8c0@gateway.2wire.net><5302A870.1070202@cisco.com> Date: Thu, 20 Feb 2014 09:37:14 +0000 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: AMSPR07CA007.eurprd07.prod.outlook.com (10.242.77.175) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 01283822F8 X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(51704005)(377454003)(1990?= =?iso-8859-1?Q?02)(189002)(13464003)(24454002)(47776003)(63696002)(767860?= =?iso-8859-1?Q?01)(76796001)(84392001)(62966002)(15975445006)(77156001)(7?= =?iso-8859-1?Q?4366001)(79102001)(44716002)(61296002)(77096001)(62236002)?= =?iso-8859-1?Q?(77982001)(59766001)(74706001)(74876001)(83072002)(8585200?= =?iso-8859-1?Q?3)(14496001)(90146001)(66066001)(56816005)(65816001)(92726?= =?iso-8859-1?Q?001)(93916002)(80022001)(89996001)(23756003)(95666001)(954?= =?iso-8859-1?Q?16001)(85306002)(50466002)(94316002)(86362001)(561944002)(?= =?iso-8859-1?Q?94946001)(69226001)(87266001)(87286001)(19580405001)(19580?= =?iso-8859-1?Q?395003)(76482001)(83322001)(54316002)(56776001)(31966008)(?= =?iso-8859-1?Q?74662001)(93136001)(51856001)(53806001)(42186004)(92566001?= =?iso-8859-1?Q?)(80976001)(74502001)(47446002)(93516002)(33646001)(461020?= =?iso-8859-1?Q?01)(47736001)(47976001)(50986001)(44736004)(87976001)(8813?= =?iso-8859-1?Q?6002)(81342001)(81542001)(4396001)(49866001)(50226001)(744?= =?iso-8859-1?Q?16001)(7726001);DIR:OUT;SFP:1101;SCL:1;SRVR:DB3PR07MB060;H?= =?iso-8859-1?Q?:AMXPRD0310HT002.eurprd03.prod.outlook.com;CLIP:157.56.248?= =?iso-8859-1?Q?.133;FPR:ECB8F13C.B7D29D22.D1D45FBB.4AE61170.20491;PTR:Inf?= =?iso-8859-1?Q?oNoRecords;A:0;MX:1;LANG:en;?= X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/Oeru6pQBbxX-6qbDNV8DLPNSzSE Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANGmodules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 09:58:54 -0000 ----- Original Message ----- From: "Warren Kumari" To: "Benoit Claise" Cc: "t.petch" ; Sent: Tuesday, February 18, 2014 10:08 PM > On Mon, Feb 17, 2014 at 7:25 PM, Benoit Claise wrote: > > Hi Tom, > > > > The important questions are: > > - will the writable aspects of the MIB module be implemented by the vendors > > (basically requested by the operators)? > > Who knows if it would be implemented by the vendors, but I'm sure most > operators would refuse to use it. > As a test I just proposed enabling SNMP write and got some good > giggles (actually I got a "Good plan! Do it with snmpv1, no one uses > that.", but I'm not really able to convey the sarcasm / mocking tone > in mail). > > I know of no large operator / network that allows write access -- I > suspect that the risks are not really as bad as folk make out, but it > has become network lore that snmp write is bad mojo and once something > becomes lore... I say again, go look at the mpls list, where draft-ietf-mpls-tp-te-mib has been returned to the WG to consider the question of making it read-only, and several have spoken up against. They are of course speaking as individuals and are not speaking for operators, or manufacturers, but they are a constituency in favour of writable MIB modules. And yes, I have in the past worked with enterprises who configure with SNMP (with security provided other than by SNMP). Tom Petch > Things may be different in the enterprise space (I think ciscoworks > tries to use snmp write). Oh, and Bay Network's Site Mangler used to > -- which is why most people used BCC... > > W > > > > > - will the writable aspects be used by the NMS'? > > > > Regards, Benoit > > > >> ----- Original Message ----- > >> From: "Benoit Claise" > >> To: > >> Sent: Friday, February 14, 2014 12:39 AM > >>> > >>> Dear all, > >>> > >>> We occasionally see read-write MIB module proposals within the IETF. > >>> However, the write capabilities of those MIB modules are rarely > >> > >> implemented. > >>> > >>> While discussing this issue with the MIB doctors, we arrive to the > >>> conclusion that it's now time to set the direction for future MIB > >>> developments within the IETF. Basically, let's not specify read-write > >>> MIB modules unless we have a good reason. Read-only MIB modules are > >>> still fine though, as SNMP is clearly used for monitoring purposes. > >>> > >>> Here is the statement we came up with: > >>> > >>> The OPS area recommends the use of NETCONF/YANG standards for > >>> configuration. IETF working groups are therefore encouraged to use > >>> the NETCONF/YANG standards for configuration, specifically in new > >>> charters. SNMP MIB modules modifying persistent configuration > >> > >> state > >>> > >>> should only be produced by working groups in cases of clear > >> > >> utility > >>> > >>> and consensus to use SNMP write operations for configuration. > >>> > >>> Ideally, this should become an IESG statement. > >>> Your feedback is most welcome. > >> > >> You probably know that there is currently a consensus call in progress > >> over > >> > >> "Please indicate Support or Oppose for this MIB > >> (draft-ietf-mpls-tp-te-mib) to be read-only." > >> > >> and I was pleasantly surprised to see opposition, albeit with one > >> opponent later changing their mind (perhaps they were sat on from a > >> height:-). I don't see much sign of Netxxxx in the mpls arena but there > >> is a need there for configuration, since there need not be a control > >> plane to set things up. Perhaps writable MIB modules will still be with > >> us in the distant future in some corners of the Internet.. > >> > >> Ideally, this idea would be fleshed out in an I-D. > >> > >> Tom Petch > >> > >>> Regards, the MIB doctors & Benoit > >> > >> . > >> > > > > _______________________________________________ > > OPS-AREA mailing list > > OPS-AREA@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-area > From nobody Thu Feb 20 06:50:20 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD701A01BF for ; Thu, 20 Feb 2014 06:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHPVa9JW6mr2 for ; Thu, 20 Feb 2014 06:50:11 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 65A3F1A0170 for ; Thu, 20 Feb 2014 06:50:11 -0800 (PST) Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id A022A26FD47B; Thu, 20 Feb 2014 09:50:07 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F5046477-F2BC-42C9-A4CA-AF61729BD0B8"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Thomas Nadeau X-Priority: 3 In-Reply-To: <000701cf2e21$a78148a0$4001a8c0@gateway.2wire.net> Date: Thu, 20 Feb 2014 09:50:05 -0500 Message-Id: References: <52FD65DD.4090609@cisco.com><028e01cf2995$bef7a3c0$4001a8c0@gateway.2wire.net><5302A870.1070202@cisco.com> <000701cf2e21$a78148a0$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/49JAk1DDDjbBdVEohW7AYpozI-4 Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANGmodules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 14:50:16 -0000 --Apple-Mail=_F5046477-F2BC-42C9-A4CA-AF61729BD0B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 20, 2014:4:37 AM, at 4:37 AM, t.petch = wrote: > ----- Original Message ----- > From: "Warren Kumari" > To: "Benoit Claise" > Cc: "t.petch" ; > Sent: Tuesday, February 18, 2014 10:08 PM >> On Mon, Feb 17, 2014 at 7:25 PM, Benoit Claise > wrote: >>> Hi Tom, >>>=20 >>> The important questions are: >>> - will the writable aspects of the MIB module be implemented by the > vendors >>> (basically requested by the operators)? >>=20 >> Who knows if it would be implemented by the vendors, but I'm sure = most >> operators would refuse to use it. >> As a test I just proposed enabling SNMP write and got some good >> giggles (actually I got a "Good plan! Do it with snmpv1, no one uses >> that.", but I'm not really able to convey the sarcasm / mocking tone >> in mail). >>=20 >> I know of no large operator / network that allows write access -- I >> suspect that the risks are not really as bad as folk make out, but it >> has become network lore that snmp write is bad mojo and once = something >> becomes lore... >=20 > I say again, go look at the mpls list, where > draft-ietf-mpls-tp-te-mib > has been returned to the WG to consider the question of making it > read-only, and several have spoken up against. They are of course > speaking as individuals and are not speaking for operators, or > manufacturers, but they are a constituency in favour of writable MIB > modules. >=20 > And yes, I have in the past worked with enterprises who configure with > SNMP (with security provided other than by SNMP). How many of those few enterprises that enable snmp writes do you = think run MPLS-TP?=20 --Tom >=20 > Tom Petch >=20 >> Things may be different in the enterprise space (I think ciscoworks >> tries to use snmp write). Oh, and Bay Network's Site Mangler used to >> -- which is why most people used BCC... >>=20 >> W >>=20 >>=20 >>=20 >>> - will the writable aspects be used by the NMS'? >>>=20 >>> Regards, Benoit >>>=20 >>>> ----- Original Message ----- >>>> From: "Benoit Claise" >>>> To: >>>> Sent: Friday, February 14, 2014 12:39 AM >>>>>=20 >>>>> Dear all, >>>>>=20 >>>>> We occasionally see read-write MIB module proposals within the > IETF. >>>>> However, the write capabilities of those MIB modules are rarely >>>>=20 >>>> implemented. >>>>>=20 >>>>> While discussing this issue with the MIB doctors, we arrive to the >>>>> conclusion that it's now time to set the direction for future MIB >>>>> developments within the IETF. Basically, let's not specify > read-write >>>>> MIB modules unless we have a good reason. Read-only MIB modules > are >>>>> still fine though, as SNMP is clearly used for monitoring > purposes. >>>>>=20 >>>>> Here is the statement we came up with: >>>>>=20 >>>>> The OPS area recommends the use of NETCONF/YANG standards for >>>>> configuration. IETF working groups are therefore encouraged > to use >>>>> the NETCONF/YANG standards for configuration, specifically in > new >>>>> charters. SNMP MIB modules modifying persistent configuration >>>>=20 >>>> state >>>>>=20 >>>>> should only be produced by working groups in cases of clear >>>>=20 >>>> utility >>>>>=20 >>>>> and consensus to use SNMP write operations for configuration. >>>>>=20 >>>>> Ideally, this should become an IESG statement. >>>>> Your feedback is most welcome. >>>>=20 >>>> You probably know that there is currently a consensus call in > progress >>>> over >>>>=20 >>>> "Please indicate Support or Oppose for this MIB >>>> (draft-ietf-mpls-tp-te-mib) to be read-only." >>>>=20 >>>> and I was pleasantly surprised to see opposition, albeit with one >>>> opponent later changing their mind (perhaps they were sat on from a >>>> height:-). I don't see much sign of Netxxxx in the mpls arena but > there >>>> is a need there for configuration, since there need not be a > control >>>> plane to set things up. Perhaps writable MIB modules will still be > with >>>> us in the distant future in some corners of the Internet.. >>>>=20 >>>> Ideally, this idea would be fleshed out in an I-D. >>>>=20 >>>> Tom Petch >>>>=20 >>>>> Regards, the MIB doctors & Benoit >>>>=20 >>>> . >>>>=20 >>>=20 >>> _______________________________________________ >>> OPS-AREA mailing list >>> OPS-AREA@ietf.org >>> https://www.ietf.org/mailman/listinfo/ops-area >>=20 >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area >=20 --Apple-Mail=_F5046477-F2BC-42C9-A4CA-AF61729BD0B8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTBhYeAAoJEPcO+I7eiUJZhEcP/RfVpjVTW6+klcEZMD1IuBPc TbybDMmwJaF2P1Q7UQuuB+UdFKS5eSGyHS416rYkXS4YpoLCV38xiX6sKQJxulbV WmdCsBHYfAoc7lpVhS3gor4fzdS9gz6zocBpbXB21mccyu6VcKM0mpu+kB+hdxWm kuCuaLWN28wTQGSYGRHA4Q7CAwlgbIyVwanLZurYw9gcDnrJZR7HT0NvP2Gd1JQt H2eoXwIBKpFb8DcUtm7aXMRDDnInz6U36UWyVwDa6xVxaTiydjuEbtS/yGxWyQDH aC2QTDgwMAWi1CjMY2CRwiZ4RteMz/j+55gUkkXVE2Rtioc6VoS22RDI7ybrZFal lgwet5JHDF5pCJHDCrReTPp9pFjN/mucfm9fySIrYgNPmD0rp3bcbB29ZEHhOl7N 8I7Yi+5Ww+qkXaujKY4wo4iMTdSnwTf47ZZl+qnCPmo415543r5NpvDyO+SnSTpc yCUeti+rUjbWxryK6E1P2b/qT5LBtGNcBJyqjvy8UoB7uAKOmrKN+4x55tfy0wpg QlZXFFkuxky96DylIL1icovVZ2p9LqvdzJ0uBV7bIuS0hY0TZ1BMNamNy6t/fUQT PDv/hUBs1RGOMekFYuUAeEDl7f0MtJY/ZyCuCe4WjE2w3J5zOh6z9yw2tQ+7d4pW nvzLm+QC7YhGmh9XemZx =f63d -----END PGP SIGNATURE----- --Apple-Mail=_F5046477-F2BC-42C9-A4CA-AF61729BD0B8-- From nobody Thu Feb 20 07:15:10 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DCA1A0170 for ; Thu, 20 Feb 2014 07:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.955 X-Spam-Level: X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jM7wH-afluf for ; Thu, 20 Feb 2014 07:15:08 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 139E01A01C3 for ; Thu, 20 Feb 2014 07:15:08 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 56B1525E65; Thu, 20 Feb 2014 07:15:04 -0800 (PST) From: Wes Hardaker To: Dave Thaler References: <52FD65DD.4090609@cisco.com> <20140214084617.GB87344@elstar.local> Date: Thu, 20 Feb 2014 07:15:04 -0800 In-Reply-To: <20140214084617.GB87344@elstar.local> (Juergen Schoenwaelder's message of "Fri, 14 Feb 2014 09:46:17 +0100") Message-ID: <0ly5157r47.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/HGse0cKfZHtY4Y6UAwrPePEMNWY Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 15:15:09 -0000 A little late to this discussion, but... Juergen Schoenwaelder writes: >> As a chair of WGs outside the OPS area, I'd still like to see >> additional guidance around notification/logging mechanisms as well >> (IPFIX vs Syslog vs SNMP traps/informs, etc.) > > This is much harder. Here is how I see things: > > IPFIX works well for large amounts of notification/logging data that > has a common structure, i.e. you get things reported with a few IPFIX > templates. SYSLOG works well with semi-structured data - traditionally > there was very little common structure and the value was in the > free-form text field. SNMP again works with structured data that is > defined in data models (which is different from many IPFIX templates > that IPFIX data processors are expected to discover at runtime, > although I am aware of I-Ds trying to nail down IPFIX templates). I've been saying for a while that a straight recommendation for "use X for Y" isn't helpful. Each of us typically thinks in certain realms, and by far the IETF considers high-end routers as the core case for most of their decisions. But the reality is that the protocols we develop are used in many many types of devices from embedded systems to high-end routers to satellites to packet radios to... And saying uniformly that "X is best for your Y usage" is simply not the truth. We've already had 3 sub-threads that have started in this discussion about "um, but is that true for this particular case?". I've argued (not enough) for a summary table in the past that compared and contrasted. What are the strengths of each protocol? What are the weaknesses? Juergen's last paragraph above is a great start down that road. Uniformity in a certain class of problems is definitely good. We don't want any device to have to implement SNMP, Netconf, IPFIX and Syslog because 4 working groups chose different tools. But it may be best for energy management type devices, which are highly constrained, to choose one solution while routers to choose another (and in fact, I'd argue there is no such thing any more as a "small" router). -- Wes Hardaker Parsons From nobody Thu Feb 20 07:48:07 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53431A01E4 for ; Thu, 20 Feb 2014 07:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9P8neMwM9g54 for ; Thu, 20 Feb 2014 07:48:02 -0800 (PST) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id 701971A01DD for ; Thu, 20 Feb 2014 07:48:02 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id i17so3534916qcy.11 for ; Thu, 20 Feb 2014 07:47:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Uj8VPLxd/Yx1wk7lR3osjKlNQuPM/cbk2rv19fYBB+4=; b=ROafp/qeOC+z+6k58XF3SNbufjQwu02dkAaic5VPWn5l/F9ot7hyh7pDdjA08k0qZJ A9nebSyCu9agEbVtFS1thv3N4DyZanUkwopZ+8KrGsUJcFQkRR7loHZYv46lWCw89fj8 BUdMiBEpI+vub530uomXk48KN3454BqtM+F6fvA+alxzdG5C9JiwwkkfI7MpaapSRuTh fvsoyNdFQHaJ4yBL+RvhCo235cAEaQxwb29AUH/Nn02jn7IdS65uLOTaXM53Xp/JLNy9 aTNU+0PSeCycxVOisAVWmICTsjStyQC3O8YPdF3IvJopBttZYRIIW8/y+cXqQDNIORq2 WOPQ== X-Gm-Message-State: ALoCoQn1cTqTGuLjnF0jV0OQBj4YprXTJGhm3K9tXzJpbvDjSwNK5sMWjiFdbq76Cb5AtAdFrX7Q MIME-Version: 1.0 X-Received: by 10.229.139.199 with SMTP id f7mr2575651qcu.2.1392911278664; Thu, 20 Feb 2014 07:47:58 -0800 (PST) Received: by 10.140.98.130 with HTTP; Thu, 20 Feb 2014 07:47:58 -0800 (PST) In-Reply-To: <0ly5157r47.fsf@wjh.hardakers.net> References: <52FD65DD.4090609@cisco.com> <20140214084617.GB87344@elstar.local> <0ly5157r47.fsf@wjh.hardakers.net> Date: Thu, 20 Feb 2014 07:47:58 -0800 Message-ID: From: Andy Bierman To: Wes Hardaker Content-Type: multipart/alternative; boundary=001a11c3e454f801ec04f2d86d13 Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/038NMCHgNVnxowUsefEQVMqVdoI Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 15:48:05 -0000 --001a11c3e454f801ec04f2d86d13 Content-Type: text/plain; charset=ISO-8859-1 Hi Wes, I agree, but I think NETCONF monitoring got left out of Juergen's summary. NETCONF has 4 main features for monitoring: - complete subtree selection: augment data is included in the same subtree as the data being augmented. This simplifies retrieval for the client - XPath filtering: powerful needle-in-a-haystack filtering is possible with XPath - custom RPC operations: dedicated filters for "show" commands allow canned (but extremely complex filtering) with little or no effort by the client - control over default leaf retrieval (usually redundant info can be easily suppressed) IMO if a WG is designing a NETCONF/YANG solution for some feature, it should include monitoring and notifications in NETCONF/YANG as well. I think SNMP makes the most sense for a WG if no configuration is standardized. Andy On Thu, Feb 20, 2014 at 7:15 AM, Wes Hardaker wrote: > > A little late to this discussion, but... > > Juergen Schoenwaelder writes: > > >> As a chair of WGs outside the OPS area, I'd still like to see > >> additional guidance around notification/logging mechanisms as well > >> (IPFIX vs Syslog vs SNMP traps/informs, etc.) > > > > This is much harder. Here is how I see things: > > > > IPFIX works well for large amounts of notification/logging data that > > has a common structure, i.e. you get things reported with a few IPFIX > > templates. SYSLOG works well with semi-structured data - traditionally > > there was very little common structure and the value was in the > > free-form text field. SNMP again works with structured data that is > > defined in data models (which is different from many IPFIX templates > > that IPFIX data processors are expected to discover at runtime, > > although I am aware of I-Ds trying to nail down IPFIX templates). > > I've been saying for a while that a straight recommendation for "use X > for Y" isn't helpful. Each of us typically thinks in certain realms, > and by far the IETF considers high-end routers as the core case for most > of their decisions. But the reality is that the protocols we develop > are used in many many types of devices from embedded systems to high-end > routers to satellites to packet radios to... And saying uniformly that > "X is best for your Y usage" is simply not the truth. We've already had > 3 sub-threads that have started in this discussion about "um, but is > that true for this particular case?". > > I've argued (not enough) for a summary table in the past that compared > and contrasted. What are the strengths of each protocol? What are the > weaknesses? Juergen's last paragraph above is a great start down that > road. > Uniformity in a certain class of problems is definitely good. We don't > want any device to have to implement SNMP, Netconf, IPFIX and Syslog > because 4 working groups chose different tools. But it may be best for > energy management type devices, which are highly constrained, to choose > one solution while routers to choose another (and in fact, I'd argue > there is no such thing any more as a "small" router). > > -- > Wes Hardaker > Parsons > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > --001a11c3e454f801ec04f2d86d13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Wes,

I agree, but I think NETCONF mo= nitoring got left out of Juergen's summary.
NETCONF has 4 mai= n features for monitoring:

=A0 =A0- complete subtr= ee selection: augment data is included in the same subtree as
=A0 =A0 =A0the data being augmented. =A0This simplifies retrieval for = the client
=A0 =A0- XPath filtering: powerful needle-in-a-haystac= k filtering is possible with XPath
=A0 =A0- custom RPC operations= : dedicated filters for "show" commands allow
=A0 =A0 =A0canned (but extremely complex filtering) with little or no = effort by the client
=A0 =A0- control over default leaf retrieval= (usually redundant info can be easily suppressed)

IMO if a WG is designing a NETCONF/YANG solution for some feature,
it should include monitoring and notifications in N= ETCONF/YANG as well.
I think SNMP makes the= most sense for a WG if no configuration
is standardized.


= Andy

<= br>
On Thu, Feb 20, 2014 at 7:15 AM, Wes Hardaker <wjhns1@hardakers.net= > wrote:

A little late to this discussion, but...

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:

>> As a chair of WGs outside the OPS area, I'd still like to see<= br> >> additional guidance around notification/logging mechanisms as well=
>> (IPFIX vs Syslog vs SNMP traps/informs, etc.)
>
> This is much harder. Here is how I see things:
>
> IPFIX works well for large amounts of notification/logging data that > has a common structure, i.e. you get things reported with a few IPFIX<= br> > templates. SYSLOG works well with semi-structured data - traditionally=
> there was very little common structure and the value was in the
> free-form text field. SNMP again works with structured data that is > defined in data models (which is different from many IPFIX templates > that IPFIX data processors are expected to discover at runtime,
> although I am aware of I-Ds trying to nail down IPFIX templates).

I've been saying for a while that a straight recommendation for "u= se X
for Y" isn't helpful. =A0Each of us typically thinks in certain re= alms,
and by far the IETF considers high-end routers as the core case for most of their decisions. =A0But the reality is that the protocols we develop
are used in many many types of devices from embedded systems to high-end routers to satellites to packet radios to... =A0And saying uniformly that "X is best for your Y usage" is simply not the truth. =A0We'v= e already had
3 sub-threads that have started in this discussion about "um, but is that true for this particular case?".

I've argued (not enough) for a summary table in the past that compared<= br> and contrasted. =A0What are the strengths of each protocol? =A0What are the=
weaknesses? =A0Juergen's last paragraph above is a great start down tha= t road.
Uniformity in a certain class of problems is definitely good. =A0We don'= ;t
want any device to have to implement SNMP, Netconf, IPFIX and Syslog
because 4 working groups chose different tools. =A0But it may be best for energy management type devices, which are highly constrained, to choose
one solution while routers to choose another (and in fact, I'd argue there is no such thing any more as a "small" router).

--
Wes Hardaker
Parsons

_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area

--001a11c3e454f801ec04f2d86d13-- From nobody Thu Feb 20 11:33:37 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2855A1A01F2 for ; Thu, 20 Feb 2014 11:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfb3fUj7O1to for ; Thu, 20 Feb 2014 11:33:33 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8C32E1A015F for ; Thu, 20 Feb 2014 11:33:33 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 025D7A1; Thu, 20 Feb 2014 20:33:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F285A9C for ; Thu, 20 Feb 2014 20:33:27 +0100 (CET) Date: Thu, 20 Feb 2014 20:33:27 +0100 (CET) From: Mikael Abrahamsson To: "ops-area@ietf.org" In-Reply-To: Message-ID: References: <52FD65DD.4090609@cisco.com> <20140214084617.GB87344@elstar.local> <0ly5157r47.fsf@wjh.hardakers.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/qNPHvO9VDxGwbG8cTvhJDGARzmQ Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 19:33:36 -0000 On Thu, 20 Feb 2014, Andy Bierman wrote: > IMO if a WG is designing a NETCONF/YANG solution for some feature, it > should include monitoring and notifications in NETCONF/YANG as well. I > think SNMP makes the most sense for a WG if no configuration is > standardized. My view is that we should try to replace SNMP over time, and netconf/yang should be used for monitoring and configuration. I wish SNMP write would go away, mainly due to beforementioned security problems. I am not sure the current implementation of netconf transport for yang makes sense for bulk collection of data, and that's perhaps something that should be rectified over time. However, I fully support the initial proposal to encourage more netconf/yang usage over SNMP and other configuration methods. Question is, since it's hard to make the working groups create SNMP MIBs, it's going to be even harder to make them create yang models (at least initially), how is this going to be achieved? Also, doing models by means of publishing RFCs is kind of heavy process approach to achieving a structured model of management. I wish we could come up with something a bit more lightweight that would support including model extensions within the drafts proposing new behaviour. For instance, today an author can request protocol number allocations from IANA etc. Wouldn't it make sense to have a similar model for extensions of yang models? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Feb 20 11:42:21 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FE21A0255 for ; Thu, 20 Feb 2014 11:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gdyj0YLOfxsk for ; Thu, 20 Feb 2014 11:42:08 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) by ietfa.amsl.com (Postfix) with ESMTP id 298471A0176 for ; Thu, 20 Feb 2014 11:42:08 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) with Microsoft SMTP Server (TLS) id 15.0.878.16; Thu, 20 Feb 2014 19:42:02 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0878.008; Thu, 20 Feb 2014 19:42:02 +0000 From: Dave Thaler To: Wes Hardaker Thread-Topic: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules Thread-Index: AQHPLk6LAAEyFS8AY0qxxuHltCPOWJq+il6w Date: Thu, 20 Feb 2014 19:42:01 +0000 Message-ID: <1b9d6432919c4dac9897b3e23e943916@BY2PR03MB412.namprd03.prod.outlook.com> References: <52FD65DD.4090609@cisco.com> <20140214084617.GB87344@elstar.local> <0ly5157r47.fsf@wjh.hardakers.net> In-Reply-To: <0ly5157r47.fsf@wjh.hardakers.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::4] x-forefront-prvs: 01283822F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(979002)(6009001)(51704005)(189002)(199002)(79102001)(81816001)(63696002)(81542001)(81686001)(47446002)(85306002)(31966008)(74502001)(74662001)(87266001)(87936001)(224303002)(95666003)(76786001)(76576001)(76796001)(81342001)(224313003)(33646001)(74366001)(90146001)(56816005)(2656002)(74706001)(74876001)(92566001)(94316002)(69226001)(46102001)(83072002)(76482001)(54316002)(47976001)(47736001)(49866001)(56776001)(51856001)(85852003)(54356001)(50986001)(4396001)(59766001)(19580395003)(80976001)(77982001)(83322001)(19580405001)(74316001)(86612001)(93136001)(53806001)(95416001)(65816001)(80022001)(86362001)(94946001)(93516002)(3826001)(24736002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB412; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::4; FPR:BCFAFE55.ACEA9739.B9D31748.44E4F58D.203C5; MLV:ovr; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/a1y51x4Ngo59-RVYw0h0X2-phyE Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 19:42:17 -0000 Wes Hardaker writes: > Juergen Schoenwaelder writes: > >> As a chair of WGs outside the OPS area, I'd still like to see > >> additional guidance around notification/logging mechanisms as well > >> (IPFIX vs Syslog vs SNMP traps/informs, etc.) > > > > This is much harder. Here is how I see things: > > > > IPFIX works well for large amounts of notification/logging data that > > has a common structure, i.e. you get things reported with a few IPFIX > > templates. SYSLOG works well with semi-structured data - traditionally > > there was very little common structure and the value was in the > > free-form text field. SNMP again works with structured data that is > > defined in data models (which is different from many IPFIX templates > > that IPFIX data processors are expected to discover at runtime, > > although I am aware of I-Ds trying to nail down IPFIX templates). >=20 > I've been saying for a while that a straight recommendation for "use X fo= r Y" > isn't helpful. Each of us typically thinks in certain realms, and by far= the IETF > considers high-end routers as the core case for most of their decisions. = But > the reality is that the protocols we develop are used in many many types = of > devices from embedded systems to high-end routers to satellites to packet > radios to... And saying uniformly that "X is best for your Y usage" is s= imply > not the truth. We've already had > 3 sub-threads that have started in this discussion about "um, but is that= true > for this particular case?". >=20 > I've argued (not enough) for a summary table in the past that compared an= d > contrasted. What are the strengths of each protocol? What are the > weaknesses? Juergen's last paragraph above is a great start down that ro= ad. > Uniformity in a certain class of problems is definitely good. We don't w= ant > any device to have to implement SNMP, Netconf, IPFIX and Syslog because 4 > working groups chose different tools. It's worse than that. The situation today is where the *same* WG had to ch= oose among 4 different tools. If there are different people in the WG with draf= ts proposing each of the 4 (or more...), there is no guidance to WGs on how to choose, or whether to adopt all 4 possibilities. And in that case, a devic= e might have to implement all 4 people the *same* WG standardized 4 different thing= s. -Dave (WG chair who's had exactly the above problem occur) From nobody Thu Feb 20 11:55:10 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED1B1A01D6 for ; Thu, 20 Feb 2014 11:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf4E9eQiD2q4 for ; Thu, 20 Feb 2014 11:55:06 -0800 (PST) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDBF1A019F for ; Thu, 20 Feb 2014 11:55:06 -0800 (PST) Received: by mail-qg0-f41.google.com with SMTP id i50so4989801qgf.0 for ; Thu, 20 Feb 2014 11:55:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zkg8W/JJktuF60Mfy6C37mYc5pmlx0q1R9Hj6LoB+3s=; b=AD0ZEiTMce+7vPpnlyxJQbbXU6zA/+LTcW490+wwr2nz8ONGSpEmO2n4Snp7CyRKn6 3pTysf8ACQMge3sC2SHF6YpU6/wMPSqD4MYunM2BY6MMz7a8P98wwyv37LP99P9n/bis e/9lPQi9C4VTbuNtptfnZnOwTZUqLocln67U/8hJsy/3f7Fqf54q3VC3bxOtKNKrOCWT UhfPsZEJkMWz9yur2mC3rPfxaCrnVEYHVNnUp07UddeDSs+XOD5SVylbc/jfvfAnE8Mt giQQFK9l0K5FNyInWwMEGc4kGQU90sUVYqNdICGaaFTzj6l4iuXYW+sPzGBf7nSb6Yel eETA== X-Gm-Message-State: ALoCoQnrbDAbcta1PuOy6GehU0ipFPVYPPtPmfC2PVH7hg/srScAcyOlQhAYXAzHJgZacemIPJp3 MIME-Version: 1.0 X-Received: by 10.224.66.8 with SMTP id l8mr4242592qai.16.1392926102644; Thu, 20 Feb 2014 11:55:02 -0800 (PST) Received: by 10.140.98.130 with HTTP; Thu, 20 Feb 2014 11:55:02 -0800 (PST) In-Reply-To: References: <52FD65DD.4090609@cisco.com> <20140214084617.GB87344@elstar.local> <0ly5157r47.fsf@wjh.hardakers.net> Date: Thu, 20 Feb 2014 11:55:02 -0800 Message-ID: From: Andy Bierman To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=001a11c2c27a8c1c3e04f2dbe1b7 Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/GspwJvSNsSOYDtyR3F24dkedtXM Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 19:55:08 -0000 --001a11c2c27a8c1c3e04f2dbe1b7 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Thu, Feb 20, 2014 at 11:33 AM, Mikael Abrahamsson wrote: > On Thu, 20 Feb 2014, Andy Bierman wrote: > > IMO if a WG is designing a NETCONF/YANG solution for some feature, it >> should include monitoring and notifications in NETCONF/YANG as well. I >> think SNMP makes the most sense for a WG if no configuration is >> standardized. >> > > My view is that we should try to replace SNMP over time, and netconf/yang > should be used for monitoring and configuration. I wish SNMP write would go > away, mainly due to beforementioned security problems. I am not sure the > current implementation of netconf transport for yang makes sense for bulk > collection of data, and that's perhaps something that should be rectified > over time. However, I fully support the initial proposal to encourage more > netconf/yang usage over SNMP and other configuration methods. > > Question is, since it's hard to make the working groups create SNMP MIBs, > it's going to be even harder to make them create yang models (at least > initially), how is this going to be achieved? > > For now the NETMOD WG is working on standard YANG modules. I think monitoring would only be done to support a configuration module. For existing MIB modules, we already have RFC 6643 to provide a direct (read-only) mapping from SMIv2 to YANG. Also, doing models by means of publishing RFCs is kind of heavy process > approach to achieving a structured model of management. I wish we could > come up with something a bit more lightweight that would support including > model extensions within the drafts proposing new behaviour. > > IMO, the bar is high in the IETF and that's a good thing. Vendors have to agree on the details. That's always been the hard part -- not the RFC publication process. For instance, today an author can request protocol number allocations from > IANA etc. Wouldn't it make sense to have a similar model for extensions of > yang models? Anybody can define their own YANG modules. IANA is not needed to publish non-IETF modules. > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > Andy --001a11c2c27a8c1c3e04f2dbe1b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,


On Thu, Feb 20, 2014 at 11:33 AM, Mikael Abrahamsson <swmike@s= wm.pp.se> wrote:
On Thu, 20 Feb 2014, Andy Bierman wrote:

IMO if a WG is designing a NETCONF/YANG solution for some feature, it shoul= d include monitoring and notifications in NETCONF/YANG as well. I think SNM= P makes the most sense for a WG if no configuration is standardized.

My view is that we should try to replace SNMP over time, and netconf/yang s= hould be used for monitoring and configuration. I wish SNMP write would go = away, mainly due to beforementioned security problems. I am not sure the cu= rrent implementation of netconf transport for yang makes sense for bulk col= lection of data, and that's perhaps something that should be rectified = over time. However, I fully support the initial proposal to encourage more = netconf/yang usage over SNMP and other configuration methods.

Question is, since it's hard to make the working groups create SNMP MIB= s, it's going to be even harder to make them create yang models (at lea= st initially), how is this going to be achieved?


For now the NETMOD WG is working on st= andard YANG modules.
I think monitoring would only be done to sup= port a configuration module.
For existing MIB modules, we already= have RFC 6643 to provide
a direct (read-only) mapping from SMIv2 to YANG.

<= div>
Also, doing models by means of publishing RFCs is kind of heavy process app= roach to achieving a structured model of management. I wish we could come u= p with something a bit more lightweight that would support including model = extensions within the drafts proposing new behaviour.


IMO, the bar is high in the IETF and t= hat's a good thing.
Vendors have to agree on the details. Tha= t's always been the
hard part -- not the RFC publication proc= ess.
=A0

For instance, today an author can request protocol number allocations from = IANA etc. Wouldn't it make sense to have a similar model for extensions= of yang models?

Anybody can define their o= wn YANG modules. IANA is not needed
to publish non-IETF modules.

=A0


--
Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se



Andy

--001a11c2c27a8c1c3e04f2dbe1b7-- From nobody Thu Feb 20 12:13:31 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2AF1A02C2 for ; Thu, 20 Feb 2014 12:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFU1Pz7ASfK5 for ; Thu, 20 Feb 2014 12:13:29 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id ED30F1A02B8 for ; Thu, 20 Feb 2014 12:13:28 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2700FA1; Thu, 20 Feb 2014 21:13:24 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 229C69C; Thu, 20 Feb 2014 21:13:24 +0100 (CET) Date: Thu, 20 Feb 2014 21:13:24 +0100 (CET) From: Mikael Abrahamsson To: Andy Bierman In-Reply-To: Message-ID: References: <52FD65DD.4090609@cisco.com> <20140214084617.GB87344@elstar.local> <0ly5157r47.fsf@wjh.hardakers.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/lmA9Ml8_C9X8x6dAFZLqCvsy-LQ Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 20:13:30 -0000 On Thu, 20 Feb 2014, Andy Bierman wrote: > For instance, today an author can request protocol number allocations from >> IANA etc. Wouldn't it make sense to have a similar model for extensions of >> yang models? > > Anybody can define their own YANG modules. IANA is not needed > to publish non-IETF modules. You completely missed my point. My point was to have yang modules defined in the same RFC as the proposed standard was defined in, and that a request would go out to some entity to approve the proposed yang model for whatever was being standardized. There would be a repository of IETF yang models somewhere, and these would no longer be published in RFC form, but by some other process. The IANA reference was just an example of existing such process/registry. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Feb 20 12:22:11 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C6B1A028D for ; Thu, 20 Feb 2014 12:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEvu3xGwOZOW for ; Thu, 20 Feb 2014 12:22:07 -0800 (PST) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7312C1A0253 for ; Thu, 20 Feb 2014 12:22:07 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id y10so2267707pdj.4 for ; Thu, 20 Feb 2014 12:22:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HJMVoMTy5MM9fmKmCM7Di1gk7QadGbACI5jEPIZgbjU=; b=HiVEjAoz2RWsGITXPSiy61OyxIqC5FET5janAip6eILAunWTU4dEBy6pJwmp7uBwPl aKgs/kQAT8srLWNVNdBHFSBRbD4H0b7g9Pd9h4zjMu8zV0fLeDcjoohsMtkp4i/SRL9s gzKUPqyo0xTSck2L9MrM0uzH2+BpUkSelqlr6OApTenoreBQyTDcrI7cG7RVanu0GNz0 gDZcHlZfX+XAYlGxn730MaqV2kiPxFwpQu2gtzMnk3wGrn60ZEdjzxajSQVpd6FONW0k iqUP0PaMfzwiIropcxJBr8zmYXLBvDjuUubdYg0mEOVrPfiYBfwYFih15e/ogn9wnaPb U6aQ== X-Gm-Message-State: ALoCoQlNbjyauldPoSLLFxYv20g82LTFChzjG31DRGWSUUbroBiI4PJ8UvH6es+Wy5jAv/n5dqwT MIME-Version: 1.0 X-Received: by 10.66.122.101 with SMTP id lr5mr4330218pab.130.1392927723935; Thu, 20 Feb 2014 12:22:03 -0800 (PST) Received: by 10.70.21.68 with HTTP; Thu, 20 Feb 2014 12:22:03 -0800 (PST) In-Reply-To: References: <52FD65DD.4090609@cisco.com> <20140214084617.GB87344@elstar.local> <0ly5157r47.fsf@wjh.hardakers.net> Date: Thu, 20 Feb 2014 12:22:03 -0800 Message-ID: From: Andy Bierman To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=047d7b2e0ddf2ef1a004f2dc4267 Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/R2xOnCUEDr4GK0o6wcD8USVYres Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 20:22:08 -0000 --047d7b2e0ddf2ef1a004f2dc4267 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 20, 2014 at 12:13 PM, Mikael Abrahamsson wrote: > On Thu, 20 Feb 2014, Andy Bierman wrote: > > For instance, today an author can request protocol number allocations from >> >>> IANA etc. Wouldn't it make sense to have a similar model for extensions >>> of >>> yang models? >>> >> >> Anybody can define their own YANG modules. IANA is not needed >> to publish non-IETF modules. >> > > You completely missed my point. My point was to have yang modules defined > in the same RFC as the proposed standard was defined in, and that a request > would go out to some entity to approve the proposed yang model for whatever > was being standardized. There would be a repository of IETF yang models > somewhere, and these would no longer be published in RFC form, but by some > other process. The IANA reference was just an example of existing such > process/registry. > > I don't see any reason to avoid the RFC publication process for YANG modules. > -- > Mikael Abrahamsson email: swmike@swm.pp.se > Andy --047d7b2e0ddf2ef1a004f2dc4267 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Feb 20, 2014 at 12:13 PM, Mikael Abrahamsson <swmike@swm.pp= .se> wrote:
On Thu, 20 Feb 2014, Andy Bierman wrote:

For instance, today an author can request protocol number allocations from<= br>
IANA etc. Wouldn't it make sense to have a similar model for extensions= of
yang models?

Anybody can define their own YANG modules. IANA is not needed
to publish non-IETF modules.

You completely missed my point. My point was to have yang modules defined i= n the same RFC as the proposed standard was defined in, and that a request = would go out to some entity to approve the proposed yang model for whatever= was being standardized. There would be a repository of IETF yang models so= mewhere, and these would no longer be published in RFC form, but by some ot= her process. The IANA reference was just an example of existing such proces= s/registry.


I don't see any reas= on to avoid the RFC publication process for YANG modules.
=A0
--
Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se

Andy<= /div>

--047d7b2e0ddf2ef1a004f2dc4267-- From nobody Thu Feb 20 20:09:54 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230151A03E2 for ; Thu, 20 Feb 2014 20:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mjc47_J6JMdr for ; Thu, 20 Feb 2014 20:09:51 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8B62F1A01CC for ; Thu, 20 Feb 2014 20:09:51 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 302CE2CBBE; Thu, 20 Feb 2014 20:09:47 -0800 (PST) From: Wes Hardaker To: Dave Thaler References: <52FD65DD.4090609@cisco.com> <20140214084617.GB87344@elstar.local> <0ly5157r47.fsf@wjh.hardakers.net> <1b9d6432919c4dac9897b3e23e943916@BY2PR03MB412.namprd03.prod.outlook.com> Date: Thu, 20 Feb 2014 20:09:47 -0800 In-Reply-To: <1b9d6432919c4dac9897b3e23e943916@BY2PR03MB412.namprd03.prod.outlook.com> (Dave Thaler's message of "Thu, 20 Feb 2014 19:42:01 +0000") Message-ID: <0lwqgp14z8.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/dV0JNcUhwP4KhOoeR543Eh99PeU Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 04:09:53 -0000 Dave Thaler writes: > It's worse than that. The situation today is where the *same* WG had to choose > among 4 different tools. Nope, I understand that. Because there is no comparison table to help them pick! -- Wes Hardaker Parsons From nobody Thu Feb 20 20:11:13 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2B11A03E2 for ; Thu, 20 Feb 2014 20:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.955 X-Spam-Level: X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0R_lvjOW7Jg for ; Thu, 20 Feb 2014 20:11:10 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3DC1A01CC for ; Thu, 20 Feb 2014 20:11:09 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 9B0E22DDCE; Thu, 20 Feb 2014 20:11:05 -0800 (PST) From: Wes Hardaker To: Andy Bierman References: <52FD65DD.4090609@cisco.com> <20140214084617.GB87344@elstar.local> <0ly5157r47.fsf@wjh.hardakers.net> Date: Thu, 20 Feb 2014 20:11:05 -0800 In-Reply-To: (Andy Bierman's message of "Thu, 20 Feb 2014 07:47:58 -0800") Message-ID: <0lsird14x2.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/pOTxgsjoVEQViBtNB05qog25tl8 Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 04:11:11 -0000 Andy Bierman writes: > I agree, but I think NETCONF monitoring got left out of Juergen's > summary. Yes, it's a start. Not a complete list. The point is that there are pluses and minuses to each one. But those are not spelled out anywhere (especially because each person biased toward the pluses of their own favorite and the minuses of everyone else's). -- Wes Hardaker Parsons From nobody Fri Feb 21 00:07:42 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720621A0070 for ; Fri, 21 Feb 2014 00:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn6JJUhA8_Xl for ; Fri, 21 Feb 2014 00:07:38 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id EE85B1A005B for ; Fri, 21 Feb 2014 00:07:37 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7EB44E88; Fri, 21 Feb 2014 09:07:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id f_9EUIdvRjwc; Fri, 21 Feb 2014 09:07:31 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Fri, 21 Feb 2014 09:07:31 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD60F20026; Fri, 21 Feb 2014 09:07:31 +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 P0uM5Lyek6sD; Fri, 21 Feb 2014 09:07:31 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01B5620015; Fri, 21 Feb 2014 09:07:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2257B2B6E903; Fri, 21 Feb 2014 09:07:29 +0100 (CET) Date: Fri, 21 Feb 2014 09:07:28 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20140221080728.GA91331@elstar.local> Mail-Followup-To: Wes Hardaker , Andy Bierman , "ops-area@ietf.org" References: <52FD65DD.4090609@cisco.com> <20140214084617.GB87344@elstar.local> <0ly5157r47.fsf@wjh.hardakers.net> <0lsird14x2.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: <0lsird14x2.fsf@wjh.hardakers.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/Tvyp8U_l1GmjuDddD8HuvZ_aAVI Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 08:07:41 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 20, 2014 at 08:11:05PM -0800, Wes Hardaker wrote: > Andy Bierman writes: > > > I agree, but I think NETCONF monitoring got left out of Juergen's > > summary. > > Yes, it's a start. Not a complete list. > > The point is that there are pluses and minuses to each one. But those > are not spelled out anywhere (especially because each person biased > toward the pluses of their own favorite and the minuses of everyone > else's). This whole NM protocol selection / guidance discussion comes up periodically. I just found what I wrote down the last time (plus a few minor modifications). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nm-guidelines.org" Guidelines for Developing Network Management Specifications * Introduction - WGs should consider operations and management aspects during the development of protocol specifications. For such guidelines, see RFC 5706. - IAB recommandations documented in RFC 1052 lead to the development of SNMP as the Internet network management protocol. This document is meanwhile obsolete and only of historic value. - Functional evolution of the SNMP framework failed (EOS working group, SMIng working), new approaches came along (COPS-PR, SPPI), resulting in an IAB workshop (documented in RFC 3535), which paved the way to the creation of NETCONF. - SYSLOG existed since the late 1980s but was not formally defined as a standard protocol specification, leading to many variants, making later attempts do document it challenging, see RFC 3164. Its only since 2009 that there is a standards-track IETF specification of SYSLOG [RFC5424]. - IPFIX [RFC5101], published in 2008 and replaced by RFC 7011 in 2013, is a standards-track version of NETFLOW, which dates back to the early 1990s, a proprietary protocol for exporting network flow information. - There are now several network management protocols that WGs can use to address their network management needs. This document aims at providing guidelines how to choose between the technologies. * Relevant Network Management Technologies ** NETCONF/YANG - NETCONF can transport and filter large amounts of data more efficiently than SNMP - NETCONF provides specific support to manipulate (persistent) configuration datastores, including locking mechanisms to control concurrency and rollback mechansims to run transactions across a number of devices - The NETCONF transports are all TCP based. Hence, NETCONF can suffer from shaky network conditions, e.g., high degrees of packet loss. - The data modeling language YANG allows to model complex structured data types much more easily than SMIv2, which is restricted to flat tables ** SNMP/SMIv2 - SNMP is very low overhead for regular polling activities and it provides a very lightweight event notification mechanism - SNMP is particularly efficient if little information from many devices is monitored - SNMP uses a trap-directed polling approach. As such, regular polling is assumed and notifications are essentially there to reduce latency (i.e., no need to wait until the next polling cycle and event notifications do not have to carry all details of the event). - The most widely deployed SNMP transports are UDP based and thus allow SNMP managers to cope with shaky network conditions, e.g., high degrees of packet loss. (But note that it is implementation dependent whether implementations do that.) - There is a large collection of SNMP-based tools that collect and integrate SNMP accessible data and do perform event correlation. ** SYSLOG - SYSLOG traditionally does not use formally defined structured data. Even though standards-track SYSLOG has support for structured data, this does not seem to be widely used (yet). - SYSLOG has a signature mechanism (RFC 5848), which can be very useful to address legal requirements. - Tools typically allow to filter SYSLOG messages (often by matching messages against collections of regular expressions) and offer to trigger reactions if a filter matches. ** IPFIX - IPFIX was originally designed to export information about network flows, often used for traffic engineering or accounting purposes - IPFIX is template driven, which allows a rather compact encoding of structured data that is sent frequently since the naming and type information is carried in a template, separated from the data itself * Network Management Avtivities ** Configuration - For configuration, NETCONF/YANG is the choice since there are no direct competitor for configuration. While SNMP can in principle be used to modify persistent configuration, this has proven over the years to be difficult. ** Periodic Monitoring - [TBD] ** Continuous Monitoring - [TBD] ** Logging - SYSLOG has been widely used for logging, mainly due to its flexibility. The SYSLOG signature mechanism makes it rather attractive in situations where legal requirements require to proof the origin and integrity of log messages. - IPFIX has more recently been proposed as an alternative for logging since it allows to bundle a number of similarly structured log messages into a single IPFIX messages. However, at this point in time, this is a proposal, it is not clear yet that the larger community has concensus on this direction of evolution of IPFIX. ** Alerting - SYSLOG has been widely used for event notification; it does not require a formal data model and thus is very flexible for device implementors but as a consequence requires more work on the event notification receiver side - SNMP has been widely used for event notification; it relies on a formal data model and thus is a bit easier to deal with on the even notificaiton receiver side but less flexible for device implementors - It seems there are deployments that prefer to translate all event notifications into SYSLOG format and there are deployments that prefer to translate all event notifications to SNMP format - NETCONF event notifications may make sense to provide event notifications to configuration management applications but likely will not compete any time soon with SNMP notifications and SYSLOG messages * Guidelines WGs are not required to produce SMIv2 data models (MIB modules) nor are they required to produce YANG data models (YANG modules). However, they are encouraged to do so. Note that MIB modules can be read-only by providing appropriate compliance statements. The decision whether SMIv2 or YANG is more appropriate must be taken by the WG. However, using SNMP for configuration should only be considered if there is strong concensus to do so. --ReaqsoxgOBHFXBhH-- From nobody Fri Feb 21 01:52:34 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9AA1A04DB for ; Fri, 21 Feb 2014 01:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boItK9up0aJW for ; Fri, 21 Feb 2014 01:52:30 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0080.outbound.protection.outlook.com [213.199.154.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE751A0452 for ; Fri, 21 Feb 2014 01:52:29 -0800 (PST) Received: from DBXPRD0210HT005.eurprd02.prod.outlook.com (157.56.253.181) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.883.10; Fri, 21 Feb 2014 09:52:23 +0000 Message-ID: <018a01cf2ee9$ee208500$4001a8c0@gateway.2wire.net> From: t.petch To: Wes Hardaker References: <52FD65DD.4090609@cisco.com> <20140214084617.GB87344@elstar.local> <0ly5157r47.fsf@wjh.hardakers.net> <1b9d6432919c4dac9897b3e23e943916@BY2PR03MB412.namprd03.prod.outlook.com> <0lwqgp14z8.fsf@wjh.hardakers.net> Date: Fri, 21 Feb 2014 09:47:13 +0000 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.181] X-ClientProxiedBy: AMSPR07CA003.eurprd07.prod.outlook.com (10.242.77.171) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 01294F875B X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(51704005)(377454003)(1990?= =?iso-8859-1?Q?02)(189002)(13464003)(47776003)(63696002)(76786001)(767960?= =?iso-8859-1?Q?01)(62966002)(84392001)(15975445006)(74366001)(77156001)(7?= =?iso-8859-1?Q?7096001)(44716002)(79102001)(77982001)(62236002)(59766001)?= =?iso-8859-1?Q?(61296002)(74706001)(83072002)(74876001)(85852003)(9566600?= =?iso-8859-1?Q?3)(14496001)(92726001)(65816001)(66066001)(90146001)(56816?= =?iso-8859-1?Q?005)(80022001)(89996001)(23756003)(95416001)(85306002)(504?= =?iso-8859-1?Q?66002)(46102001)(86362001)(94316002)(94946001)(224313003)(?= =?iso-8859-1?Q?69226001)(87266001)(87286001)(19580405001)(19580395003)(76?= =?iso-8859-1?Q?482001)(83322001)(54316002)(56776001)(92566001)(93916002)(?= =?iso-8859-1?Q?93516002)(93136001)(31966008)(74662001)(80976001)(51856001?= =?iso-8859-1?Q?)(53806001)(33646001)(42186004)(47446002)(47736001)(479760?= =?iso-8859-1?Q?01)(50986001)(44736004)(87976001)(81342001)(88136002)(7450?= =?iso-8859-1?Q?2001)(4396001)(81542001)(50226001)(224303002)(49866001)(74?= =?iso-8859-1?Q?416001)(7726001);DIR:OUT;SFP:1101;SCL:1;SRVR:DB3PR07MB060;?= =?iso-8859-1?Q?H:DBXPRD0210HT005.eurprd02.prod.outlook.com;CLIP:157.56.25?= =?iso-8859-1?Q?3.181;FPR:EBFA01F5.1C2F87F1.C3DFA589.D6E39CDC.201E1;PTR:In?= =?iso-8859-1?Q?foNoRecords;A:0;MX:1;LANG:en;?= X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/qcR0atVm4WvPaVYZfV1Jgtv9sMg Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 09:52:33 -0000 ----- Original Message ----- From: "Wes Hardaker" To: "Dave Thaler" Cc: Sent: Friday, February 21, 2014 4:09 AM > Dave Thaler writes: > > > It's worse than that. The situation today is where the *same* WG had to choose > > among 4 different tools. > > Nope, I understand that. Because there is no comparison table to help > them pick! Just like Security, where you and I have been involved in adding security to an existing IETF protocol and it has been do we use IPsec, Kerberos, SSL, SSH, .... with no help or guidance from a security directorate, just an army of WGs each busy working away on its own thing:-( The IETF can produced over-arching strategic considerations (or the IAB can) or the nitty gritty, but in between, we leave a hole. Tom Petch > -- > Wes Hardaker > Parsons > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > From nobody Fri Feb 21 08:57:55 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981E61A03FA for ; Fri, 21 Feb 2014 08:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzI33zdwwTXf for ; Fri, 21 Feb 2014 08:57:52 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBA51A01BF for ; Fri, 21 Feb 2014 08:57:52 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta09.westchester.pa.mail.comcast.net with comcast id V4Yi1n0031swQuc594xo7a; Fri, 21 Feb 2014 16:57:48 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta15.westchester.pa.mail.comcast.net with comcast id V4xo1n0032yZEBF3b4xogz; Fri, 21 Feb 2014 16:57:48 +0000 From: "ietfdbh" To: "'Wes Hardaker'" , "'Andy Bierman'" References: <52FD65DD.4090609@cisco.com> <20140214084617.GB87344@elstar.local> <0ly5157r47.fsf@wjh.hardakers.net> <0lsird14x2.fsf@wjh.hardakers.net> In-Reply-To: <0lsird14x2.fsf@wjh.hardakers.net> Date: Fri, 21 Feb 2014 11:57:48 -0500 Message-ID: <013101cf2f26$0d1caec0$27560c40$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxxz5juTd3n7gDSXffXOKa4rE1VAKG/UfEAfZqOToBJdrP2wHlokg1AUi5OBKaNC9VYA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393001868; bh=1hMu1BtTHJ4GLd6MbfYYtbRdez3uD1qP7SwaGU2EDLs=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=ebCNPTyUd78gifwX2v2fbF9c7wE+kXcIZFbCz4eNhyo15YE/ZvZF/332yvk9A6M0s 8zvAOLGJ9ngJmGMdzQwiunv94gkZcF9KizlcWjQSus6qIKszGZ19aS3PbofKIVwuJx x1tBX7eW2duUCj3SJsxBlasCvHHvHMf5jAWHzJLfMUG6gkqZ/LrNuJonQO+yYs1MC+ HUISyul5VyCQRZD2ArTrbS44/HTihQxe0g1CDzxK6Drej6j7h3cvVO0r4hPt+FXT7d j+dZ1/vW1oSnL9DLBqFgpNT8/D9/XqiSSdDR3Y+LrFy8aAYUzWUzTS/e5PT0g8dYik vouilgyJqshVQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/dcmRNPkFzky6LLkMjqZ38fBrqvo Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 16:57:54 -0000 Hi, I agree the biases and claims kind of get in the way of providing good advice. It would be good if we had some empirical research to back up our advice. Has anybody done an analysis of the timing/overhead of repetitive small queries between Netconf/MIB and SNMP/MIB? I'd love to see an analysis; unfortunately I don't have the environment to run such a test. Can anybody provide such tests? I would like to see comparisons of 1) a query for five counters in different tables, plus sysUptime, 2) a query for an initial read of a table with multiple rows of mixed types, 3) a query for an initial read of multiple inter-related tables, 4) a non-initial read of a table focusing on the objects that are likely to change dynamically in less than a (typical) day. Does anybody have other monitoring scenarios that should be tested? David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Wes > Hardaker > Sent: Thursday, February 20, 2014 11:11 PM > To: Andy Bierman > Cc: ops-area@ietf.org > Subject: Re: [OPS-AREA] configuration: writable MIB modules versus > NETCONF/YANG modules > > Andy Bierman writes: > > > I agree, but I think NETCONF monitoring got left out of Juergen's > > summary. > > Yes, it's a start. Not a complete list. > > The point is that there are pluses and minuses to each one. But those > are not spelled out anywhere (especially because each person biased > toward the pluses of their own favorite and the minuses of everyone > else's). > -- > Wes Hardaker > Parsons > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area From nobody Sun Feb 23 23:19:54 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2FB1A0363 for ; Sun, 23 Feb 2014 23:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8aVh5ppnNmR for ; Sun, 23 Feb 2014 23:19:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 006D31A0356 for ; Sun, 23 Feb 2014 23:19:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBL12939; Mon, 24 Feb 2014 07:19:49 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Feb 2014 07:19:44 +0000 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Feb 2014 07:19:48 +0000 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.239]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Mon, 24 Feb 2014 15:19:42 +0800 From: "Zhouqian (Cathy)" To: Benoit Claise , "ops-area@ietf.org" Thread-Topic: [OPS-AREA] call for agenda items for the OPSAREA open meeting at IETF-89 Thread-Index: AQHPKUBozqgDb1Ss8kC6oUf+zZCTC5rEByfwgAAHmXA= Date: Mon, 24 Feb 2014 07:19:41 +0000 Message-ID: References: <5267FF2A.2060903@cisco.com> <52FD9FF8.5030708@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/cOlmMm9JbV1MJqUDhU43O3PebLU Subject: Re: [OPS-AREA] call for agenda items for the OPSAREA open meeting at IETF-89 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 07:19:52 -0000 Dear Chairs, We'd like to request a 10min slot for open IPv6. The related documents link= s are as below: http://tools.ietf.org/html/draft-sun-openv6-problem-statement-01 http://tools.ietf.org/html/draft-liu-openv6-architecture-01 We had a side meeting in IETF 88, Vancouver, and people agreed that we shou= ld present this idea in opsarea to get more reviews and comments. The presenter will be Chongfeng Xie from China Telecom. Best Regards, Cathy > > -----Original Message----- > > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Benoit > > Claise > > Sent: Friday, February 14, 2014 12:48 PM > > To: ops-area@ietf.org > > Subject: [OPS-AREA] call for agenda items for the OPSAREA open meeting > > at > > IETF-89 > > > > Dear all, > > > > We are planning again for a joint OPSAWG and OPSAREA open meeting, > > with the OPSAWG work items driving most of the agenda. The more > > general cross-area items or those related to the relation between work > > in the area and work out of the IETF should be part of the OPSAREA sect= ion. > > > > Please send us your requests for presentation and discussion slots. > > > > Thanks and Regards, > > > > Regards, Joel and Benoit > > > > _______________________________________________ > > OPS-AREA mailing list > > OPS-AREA@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-area From nobody Mon Feb 24 00:54:47 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2551A04C6 for ; Fri, 21 Feb 2014 10:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNJlg8_75wEV for ; Fri, 21 Feb 2014 10:23:55 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 55DC91A04AD for ; Fri, 21 Feb 2014 10:23:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=c1hFfQRL7BXzfiJJdTWoN7RkNqvqUh0UwSw0XMZXpkXyiMUSmxha23kaGqbuy/dK; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.38] (helo=elwamui-lapwing.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WGulL-0000mu-4O for ops-area@ietf.org; Fri, 21 Feb 2014 13:23:51 -0500 Received: from 99.23.163.206 by webmail.earthlink.net with HTTP; Fri, 21 Feb 2014 13:23:50 -0500 Message-ID: <3671319.1393007030702.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Date: Fri, 21 Feb 2014 10:23:50 -0800 (GMT-08:00) From: Randy Presuhn To: ops-area@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88891b749bef7332bbc29160d3b5dbd4e26ed394c0512c30221350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.38 Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/IT6HgOleQb4amojGReCTGBPNz6w X-Mailman-Approved-At: Mon, 24 Feb 2014 00:54:46 -0800 Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 18:23:57 -0000 Hi - >From: ietfdbh >Sent: Feb 21, 2014 8:57 AM >To: 'Wes Hardaker' , 'Andy Bierman' >Cc: ops-area@ietf.org >Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules ... >Does anybody have other monitoring scenarios that should be tested? - Table walks of a tables with user-specific access restrictions / permissions configured in VACM for selected columns and rows. (Imagine an huge table of users or interfaces, and the user making the query is only permitted access to those "belonging" to his/her organization, not explicitly represented in the index structure, and the user is not given access to certain "sensitive" columns.) Randy From nobody Mon Feb 24 00:54:49 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FE91A025D for ; Fri, 21 Feb 2014 11:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1l24uKejgkO for ; Fri, 21 Feb 2014 11:05:17 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 32F411A0443 for ; Fri, 21 Feb 2014 11:05:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=L9cPDaVv9UzIroED3mqQkK85hdwmafqf3hRgV61eJvBXGxNXOsIsPp8EecEHq6Ak; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.38] (helo=elwamui-lapwing.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WGvPM-0008Di-Kb for ops-area@ietf.org; Fri, 21 Feb 2014 14:05:12 -0500 Received: from 99.23.163.206 by webmail.earthlink.net with HTTP; Fri, 21 Feb 2014 14:05:12 -0500 Message-ID: <20366448.1393009512653.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Date: Fri, 21 Feb 2014 11:05:12 -0800 (GMT-08:00) From: Randy Presuhn To: "ops-area@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88891b749bef7332bbc4fe244859584870bbf0aa1c825fba000350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.38 Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/UbU3vlePuvQOK0qnq4eKa0ovRlA X-Mailman-Approved-At: Mon, 24 Feb 2014 00:54:46 -0800 Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 19:05:19 -0000 Hi - >From: Mikael Abrahamsson >Sent: Feb 20, 2014 11:33 AM >To: "ops-area@ietf.org" >Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules ... >My view is that we should try to replace SNMP over time, and netconf/yang >should be used for monitoring and configuration. I wish SNMP write would >go away, mainly due to beforementioned security problems. ... Just to be clear... Are you saying that there are security problems with the RFC 3414 or RFC 3415 specifications, problems with the implementations, or something else? Randy From nobody Mon Feb 24 02:02:43 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2791A0855 for ; Mon, 24 Feb 2014 02:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.302 X-Spam-Level: * X-Spam-Status: No, score=1.302 tagged_above=-999 required=5 tests=[BAYES_60=1.5, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnbxGq9ONzCE for ; Mon, 24 Feb 2014 02:02:40 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB0D1A02FD for ; Mon, 24 Feb 2014 02:02:40 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 26D249C; Mon, 24 Feb 2014 11:02:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 21CB09A; Mon, 24 Feb 2014 11:02:38 +0100 (CET) Date: Mon, 24 Feb 2014 11:02:38 +0100 (CET) From: Mikael Abrahamsson To: Randy Presuhn In-Reply-To: <20366448.1393009512653.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Message-ID: References: <20366448.1393009512653.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/phIlYNUlEALNDVOTZjy3BQtanes Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 10:02:42 -0000 On Fri, 21 Feb 2014, Randy Presuhn wrote: > Just to be clear... Are you saying that there are security problems > with the RFC 3414 or RFC 3415 specifications, problems with the > implementations, or something else? I am saying that together with blind BCP38-less UDP spoofing, SNMPv1 and v2 together with how implementations handle views, and the complexity of SNMPv3 setup in most implementations, I wish for SNMP write to go away. I'm pretty sure with SNMPv3 only implementations this can be made to be secure, but I am not aware of anyone actually using SNMPv3 and every time I've looked into deploying SNMPv3 I shy away after just a short while. And my primary reason for this is people getting their configurations either stolen (uploaded) or modified by unfortunately misconfiguring or being hit by a bug that caused the command that was in place to limit the use of SNMP write, not working properly. So while the standard might be fine, in real life it's hard to do. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Feb 24 03:38:00 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261AB1A03EF for ; Mon, 24 Feb 2014 03:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.004 X-Spam-Level: X-Spam-Status: No, score=-4.004 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKz3RqR-cjJP for ; Mon, 24 Feb 2014 03:37:56 -0800 (PST) Received: from aer-iport-4.cisco.com (unknown [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id D1BEC1A03E4 for ; Mon, 24 Feb 2014 03:37:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2408; q=dns/txt; s=iport; t=1393241875; x=1394451475; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=5JJYi+Ae4dhWJnWExnjfan5H82zpc0bxlUjhBswzCh0=; b=FmdjCy9vBvDiKv07Ny5NxxN1zbx+F4BdXokpSEh34Cz+Shm3IB6golxw 0CD9cnopZVnLuqUifS9HEju82G+cxttJIrDiV8h1EerLzXwztT6Ed3UaU pKsLlp4CPT3lpnjxRDTjbJb++ORBKQZMN0YOEGEY34TgA4Eonr4rOXLqs 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAGwuC1OQ/khL/2dsb2JhbABZgwY7wT+BFhZ0giUBAQEEOEABEAsOAggJFg8JAwIBAgFFBgEMAQUCAQEXh2oNxhAXjmQHhDgBA5g0gTKFFotfgy47 X-IronPort-AV: E=Sophos;i="4.97,534,1389744000"; d="scan'208";a="1212073" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-4.cisco.com with ESMTP; 24 Feb 2014 11:37:54 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1OBbs9E010739; Mon, 24 Feb 2014 11:37:54 GMT Message-ID: <530B2F12.7030107@cisco.com> Date: Mon, 24 Feb 2014 12:37:54 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Wes Hardaker , Dave Thaler References: <52FD65DD.4090609@cisco.com> <20140214084617.GB87344@elstar.local> <0ly5157r47.fsf@wjh.hardakers.net> In-Reply-To: <0ly5157r47.fsf@wjh.hardakers.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/u5jKO05AwchUqmLWNlqApxbga24 Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 11:37:59 -0000 On 20/02/2014 16:15, Wes Hardaker wrote: > A little late to this discussion, but... > > Juergen Schoenwaelder writes: > >>> As a chair of WGs outside the OPS area, I'd still like to see >>> additional guidance around notification/logging mechanisms as well >>> (IPFIX vs Syslog vs SNMP traps/informs, etc.) >> This is much harder. Here is how I see things: >> >> IPFIX works well for large amounts of notification/logging data that >> has a common structure, i.e. you get things reported with a few IPFIX >> templates. SYSLOG works well with semi-structured data - traditionally >> there was very little common structure and the value was in the >> free-form text field. SNMP again works with structured data that is >> defined in data models (which is different from many IPFIX templates >> that IPFIX data processors are expected to discover at runtime, >> although I am aware of I-Ds trying to nail down IPFIX templates). > I've been saying for a while that a straight recommendation for "use X > for Y" isn't helpful. Each of us typically thinks in certain realms, > and by far the IETF considers high-end routers as the core case for most > of their decisions. But the reality is that the protocols we develop > are used in many many types of devices from embedded systems to high-end > routers to satellites to packet radios to... And saying uniformly that > "X is best for your Y usage" is simply not the truth. We've already had > 3 sub-threads that have started in this discussion about "um, but is > that true for this particular case?". > > I've argued (not enough) for a summary table in the past that compared > and contrasted. What are the strengths of each protocol? What are the > weaknesses? The tables at http://tools.ietf.org/html/rfc6632#appendix-A was a first attempt. Not complete for sure. Regards, Benoit > Juergen's last paragraph above is a great start down that road. > Uniformity in a certain class of problems is definitely good. We don't > want any device to have to implement SNMP, Netconf, IPFIX and Syslog > because 4 working groups chose different tools. But it may be best for > energy management type devices, which are highly constrained, to choose > one solution while routers to choose another (and in fact, I'd argue > there is no such thing any more as a "small" router). > From nobody Mon Feb 24 03:48:05 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE561A0849 for ; Mon, 24 Feb 2014 03:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.348 X-Spam-Level: X-Spam-Status: No, score=-7.348 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIkEn-9rySrp for ; Mon, 24 Feb 2014 03:48:02 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 43B921A07E7 for ; Mon, 24 Feb 2014 03:48:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1273; q=dns/txt; s=iport; t=1393242482; x=1394452082; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Zwl6OjDH/xhQGbV7b6B8PQtpM9jAkygjQY4YWU9/4zU=; b=BPf+ZrRLVtvq7LHnPmItHzsCXJCTw1LQYr/sjbezRILAPhrAoZHFBpHS +GdvGGIKQkWutPbvpPBUn3G4/c5GtleTIVDeOsYSkaFXOxmIVUGxss1Vy /ZrQuo7dVTGiABnM+vnMNQd7y1qL0j8DtYQPc4MYUOhp0QRQZmIZRKskj E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAAcxC1OQ/khN/2dsb2JhbABZgwbBeoEWFnSCJQEBAQMBOEABBQsLDgoJFg8JAwIBAgFFBgEMAQcBARaHYwjGHBeOZAeEOAEDmDSGSItfgy47 X-IronPort-AV: E=Sophos;i="4.97,534,1389744000"; d="scan'208";a="5968095" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 24 Feb 2014 11:48:01 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1OBm0BV028438; Mon, 24 Feb 2014 11:48:00 GMT Message-ID: <530B3170.6020902@cisco.com> Date: Mon, 24 Feb 2014 12:48:00 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Mikael Abrahamsson , Andy Bierman References: <52FD65DD.4090609@cisco.com> <20140214084617.GB87344@elstar.local> <0ly5157r47.fsf@wjh.hardakers.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/QLaFZivQOnMDPY9fekpft46GHO4 Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 11:48:04 -0000 Hi Mikael, I share the same concern. If the process to produce RFC-based YANG modules is too heavy, then the YANG modules will be defined out of the IETF process. Period. The good news is that YANG modules (based on some sort of consensus or running code) will be defined. The bad news is the IETF will not be relevant any longer. Easing the YANG modules production at the IETF is a top of mind priority. Regards, Benoit > On Thu, 20 Feb 2014, Andy Bierman wrote: > >> For instance, today an author can request protocol number allocations >> from >>> IANA etc. Wouldn't it make sense to have a similar model for >>> extensions of >>> yang models? >> >> Anybody can define their own YANG modules. IANA is not needed >> to publish non-IETF modules. > > You completely missed my point. My point was to have yang modules > defined in the same RFC as the proposed standard was defined in, and > that a request would go out to some entity to approve the proposed > yang model for whatever was being standardized. There would be a > repository of IETF yang models somewhere, and these would no longer be > published in RFC form, but by some other process. The IANA reference > was just an example of existing such process/registry. From nobody Mon Feb 24 05:16:07 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2BC1A00B9 for ; Mon, 24 Feb 2014 05:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duBJ2IB6C4ib for ; Mon, 24 Feb 2014 05:16:04 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id CB6CC1A0410 for ; Mon, 24 Feb 2014 05:16:03 -0800 (PST) Received: from [192.168.1.119] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id BDA9B2703760; Mon, 24 Feb 2014 08:16:02 -0500 (EST) References: <52FD65DD.4090609@cisco.com> <20140214084617.GB87344@elstar.local> <0ly5157r47.fsf@wjh.hardakers.net> <530B3170.6020902@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <530B3170.6020902@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <18E4D4A4-C411-4B06-8A4C-030F3534D88F@lucidvision.com> X-Mailer: iPad Mail (11B651) From: "Thomas D. Nadeau" Date: Mon, 24 Feb 2014 08:16:02 -0500 To: Benoit Claise Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/Q1A6PTcBB1Yo8VbvxtMcyUfieWw Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 13:16:05 -0000 To be fair, Mikael is partially correct - there are modules being d= efined outside of the IETF process in external organizations like Open Dayli= ght where the modules are being defined based on actual implementations. It i= s part of our mission in NETMOD and the other IETF WGs, to help bring these b= ack into the IETF process by helping folks bring them in and have them stand= ardized once real implementations have helped knock out most of the details.= This is really not different from how the IETF process is supposed to work:= running code, rough consensus. --Tom > On Feb 24, 2014, at 6:48 AM, Benoit Claise wrote: >=20 > Hi Mikael, >=20 > I share the same concern. If the process to produce RFC-based YANG modules= is too heavy, then the YANG modules will be defined out of the IETF process= . Period. > The good news is that YANG modules (based on some sort of consensus or run= ning code) will be defined. The bad news is the IETF will not be relevant an= y longer. >=20 > Easing the YANG modules production at the IETF is a top of mind priority. >=20 > Regards, Benoit >=20 >>> On Thu, 20 Feb 2014, Andy Bierman wrote: >>>=20 >>> For instance, today an author can request protocol number allocations fr= om >>>> IANA etc. Wouldn't it make sense to have a similar model for extensions= of >>>> yang models? >>>=20 >>> Anybody can define their own YANG modules. IANA is not needed >>> to publish non-IETF modules. >>=20 >> You completely missed my point. My point was to have yang modules defined= in the same RFC as the proposed standard was defined in, and that a request= would go out to some entity to approve the proposed yang model for whatever= was being standardized. There would be a repository of IETF yang models som= ewhere, and these would no longer be published in RFC form, but by some othe= r process. The IANA reference was just an example of existing such process/r= egistry. >=20 >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area >=20 From nobody Mon Feb 24 09:31:50 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7511A0169 for ; Mon, 24 Feb 2014 09:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCAmKnPmdF8Y for ; Mon, 24 Feb 2014 09:31:47 -0800 (PST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDBA1A0054 for ; Mon, 24 Feb 2014 09:31:45 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id e4so3359031wiv.16 for ; Mon, 24 Feb 2014 09:31:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=M6ezXVa5NL6QUVcJC9ihbS1hTk7GvqJvWxK43WOe9EA=; b=ayRdbcPrwOOcJe+b4G6hMeuRlxZXWio/jauCmFWBj452sDoXPd0WQEuBRvZHHevxYO Zb89mLQVZLBpf5WhrLwUJJQFQGcxDpschsuDtG1Fh95laMNJSybCtIky+O5SSqy6YvIb DQ1zNsvrugAUtjGF2rND9hmbuqfNZz6GrPCwZzkhxN8nl8Gpwh5tCD+/uu5tAGGl+VLa SGW7bbZpOlX6Yfwqd8EkWHcPpu1Ff24LcH/uKw4zdCGTFLDoRr5vhNxIUaTfup4SwU3A pPvBZZPLLBPUDXl1+L6bjuPS+vejTL7zX4dYoF2R6CyLbCR3jNdOr2l0Cz6VzFz2VBC9 6kBA== X-Gm-Message-State: ALoCoQmURms8OKkT2vUCKU0Gtw3b77kP4RQl5d8yDtjPLjlSglYKqVwnH44+oMDVlsrlQY/mZC8H MIME-Version: 1.0 X-Received: by 10.180.37.193 with SMTP id a1mr15504685wik.52.1393263104899; Mon, 24 Feb 2014 09:31:44 -0800 (PST) Received: by 10.194.54.167 with HTTP; Mon, 24 Feb 2014 09:31:44 -0800 (PST) X-Originating-IP: [98.244.98.35] In-Reply-To: References: <20366448.1393009512653.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Date: Mon, 24 Feb 2014 12:31:44 -0500 Message-ID: From: Warren Kumari To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/1ao5FelHpwMuCEBqNtjgh-XMhD4 Cc: Randy Presuhn , "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 17:31:49 -0000 On Mon, Feb 24, 2014 at 5:02 AM, Mikael Abrahamsson wrote: > On Fri, 21 Feb 2014, Randy Presuhn wrote: > >> Just to be clear... Are you saying that there are security problems with >> the RFC 3414 or RFC 3415 specifications, problems with the implementations, >> or something else? > > > I am saying that together with blind BCP38-less UDP spoofing, SNMPv1 and v2 > together with how implementations handle views, and the complexity of SNMPv3 > setup in most implementations, I wish for SNMP write to go away. +many lots. > > I'm pretty sure with SNMPv3 only implementations this can be made to be > secure, but I am not aware of anyone actually using SNMPv3 and every time > I've looked into deploying SNMPv3 I shy away after just a short while. Actually, I am -- and it has write enabled too (I'd forgotten it earlier). The IETF meeting network uses SNMPv3, but also has SNMPv2 (because lots of things don't support v3). Write access is enabled -- this is used to poke the access points and ask them to come fetch a new config from TFTP. I think that there is some element of dogfood here... > > And my primary reason for this is people getting their configurations either > stolen (uploaded) or modified by unfortunately misconfiguring or being hit > by a bug that caused the command that was in place to limit the use of SNMP > write, not working properly. > > So while the standard might be fine, in real life it's hard to do. Yes, yes it is.... W > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area From nobody Tue Feb 25 07:58:59 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1A91A013F for ; Tue, 25 Feb 2014 07:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2DABPGwwQA0 for ; Tue, 25 Feb 2014 07:58:55 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1E91A07CC for ; Tue, 25 Feb 2014 07:58:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1485; q=dns/txt; s=iport; t=1393343935; x=1394553535; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rFIgC6ceB3nm7IEabnL/1ORCSmNl7o3XfCJ4SB0giAc=; b=e6kgvSV2RqiXEFYnv+5H9rhGZjpLGPtMpRfW5f+wnS13YLWtd38d91yA sK75UiauBSh0Bhl+w87iIpMSpol4Ury+ACiqKfqGgMiO+KC13QwXYsjoP MKtdLCRyLZ3Ez4GtkzlQkyi+ypf9m38PbNEkkA8S6WVnV4WSEtglbShf6 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAEC9DFOQ/khL/2dsb2JhbABZgwY7wiiBGBZ0giUBAQEEAQEBGhs2BAYBDAQLEQEDAQEKFggHCQMCAQIBFR8DBggGAQwBBQIBAYgBDcZrF45kBwaEMgEDmDSBMoUWi1+DLjs X-IronPort-AV: E=Sophos;i="4.97,540,1389744000"; d="scan'208";a="1340564" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-4.cisco.com with ESMTP; 25 Feb 2014 15:58:54 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1PFwruC028709; Tue, 25 Feb 2014 15:58:53 GMT Message-ID: <530CBDBD.6050008@cisco.com> Date: Tue, 25 Feb 2014 16:58:53 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Zhouqian (Cathy)" , "ops-area@ietf.org" References: <5267FF2A.2060903@cisco.com> <52FD9FF8.5030708@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/KmsWb661MoCZVzi1bf3XBOswjDA Cc: "opsawg-chairs@tools.ietf.org" Subject: Re: [OPS-AREA] call for agenda items for the OPSAREA open meeting at IETF-89 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 15:58:57 -0000 Hi Cathy, Can you please let me know where those drafts have been socialized/discussed? Regards, Benoit > Dear Chairs, > We'd like to request a 10min slot for open IPv6. The related documents links are as below: > http://tools.ietf.org/html/draft-sun-openv6-problem-statement-01 > http://tools.ietf.org/html/draft-liu-openv6-architecture-01 > We had a side meeting in IETF 88, Vancouver, and people agreed that we should present this idea in opsarea to get more reviews and comments. > The presenter will be Chongfeng Xie from China Telecom. > > Best Regards, > Cathy > > >> -----Original Message----- >> From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Benoit >> Claise >> Sent: Friday, February 14, 2014 12:48 PM >> To: ops-area@ietf.org >> Subject: [OPS-AREA] call for agenda items for the OPSAREA open meeting at >> IETF-89 >> >> Dear all, >> >> We are planning again for a joint OPSAWG and OPSAREA open meeting, with >> the OPSAWG work items driving most of the agenda. The more general >> cross-area items or those related to the relation between work in the area and >> work out of the IETF should be part of the OPSAREA section. >> >> Please send us your requests for presentation and discussion slots. >> >> Thanks and Regards, >> >> Regards, Joel and Benoit >> >> _______________________________________________ >> OPS-AREA mailing list >> OPS-AREA@ietf.org >> https://www.ietf.org/mailman/listinfo/ops-area > . > From nobody Wed Feb 26 03:42:09 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470AC1A028C for ; Wed, 26 Feb 2014 03:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZT-K-Jm5Cgtu for ; Wed, 26 Feb 2014 03:42:02 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 296171A0252 for ; Wed, 26 Feb 2014 03:41:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=148; q=dns/txt; s=iport; t=1393414918; x=1394624518; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=zL7+EmYiccnRrv/2L66lHm9vgxCHJ8eEoj/V0nDoAns=; b=Ryfq5nsMq0EPrc+vwJoQ62cdbZ7SBIIJWqjbILo3vnCi2Qz77jr9ZGcq wUdUOLCZTRTg0AaGCB1q5jlZ+Mv5rEkZYIXJ2LaCO/RklnsiQx/CtcTLt WL2JJydnWnyKXMs7/z+HgaEhIQgOY7YkJjmL/cbpS3lg//eMMs8fqfU+0 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFACPSDVOQ/khN/2dsb2JhbABZgwY7wmcWdIJmQD0WGAMCAQIBSw0IAQGHdQ2YZLAjEwSTEgEDmDaGSYtfgy08 X-IronPort-AV: E=Sophos;i="4.97,547,1389744000"; d="scan'208";a="6188505" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 26 Feb 2014 11:41:57 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1QBfuJh008565 for ; Wed, 26 Feb 2014 11:41:56 GMT Message-ID: <530DD303.1050708@cisco.com> Date: Wed, 26 Feb 2014 11:41:55 +0000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ops-area@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/-EqlJMIs4jD2O_6Vw8cPmOC1CC8 Subject: [OPS-AREA] Updated OPS area agenda X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 11:42:06 -0000 Dear all, https://datatracker.ietf.org/meeting/89/agenda/opsawg/ Reminder: the OPSAREA meeting will be combined with OPSAWG Regards, Benoit From nobody Fri Feb 28 04:06:15 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34511A0732 for ; Fri, 28 Feb 2014 04:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.148 X-Spam-Level: X-Spam-Status: No, score=-8.148 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYOgu8Wt9DW1 for ; Fri, 28 Feb 2014 04:06:11 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id BCB741A0733 for ; Fri, 28 Feb 2014 04:06:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10658; q=dns/txt; s=iport; t=1393589169; x=1394798769; h=message-id:date:from:mime-version:to:subject; bh=ZTHnC9YoxD+FW2JWrFAl15aD+EtjGAUM2SKd8PPjpD0=; b=SFJWbx5ehCfvPaYM7cO7V2xl3LaMwblckb+QHsre7n001vAMBlVkLqZI RFzq4alXp1GWnVPg43FY6DcaQhOkDa1h4sj4DMybqZDSUN9gE5WI0zFQK 2puckFcFws2OHkyH0j/izRTWiXSH2I3iWG4B+46+U3RxJO5TRzP5OSOnj k=; X-IronPort-AV: E=Sophos;i="4.97,561,1389744000"; d="scan'208,217";a="1701571" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-4.cisco.com with ESMTP; 28 Feb 2014 12:06:08 +0000 Received: from [10.61.206.166] ([10.61.206.166]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1SC67j8017491; Fri, 28 Feb 2014 12:06:07 GMT Message-ID: <53107BAF.2050808@cisco.com> Date: Fri, 28 Feb 2014 12:06:07 +0000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ops-area@ietf.org" Content-Type: multipart/alternative; boundary="------------000602030604000103010606" Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/gvJVA4gI8K5QY9_njUTjXvo08UI Subject: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 12:06:14 -0000 This is a multi-part message in MIME format. --------------000602030604000103010606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, [I bcc'ed some people, with whom I discussed this issue privately. I want to make sure they're in the opsarea loop. Sorry, if you receive this email twice] I discussed the following statement with the IESG. I ideally wanted to have this statement approved as an IESG statement before the beginning of the week, but I realize that it might need some more discussion among the OPS community... The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, especially in new charters. SNMP MIB modules _creating and_ modifying persistent configuration state should only be produced by working groups in cases of clear utility and consensus to use SNMP write operations for configuration. Btw, one IESG member insisted on having "_creating and_ modifying" instead of "modifying". Let me focus on a more important issue. First let me make sure that we agree on one terminology. The NETCONF/YANG terminology is in RFC 6244: o Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state [RFC4741 ]. o Operational state data is a set of data that has been obtained by the system at runtime and influences the system's behavior similar to configuration data. In contrast to configuration data, operational state is transient and modified by interactions with internal components or other systems via specialized protocols. o Statistical data is the set of read-only data created by a system itself. It describes the performance of the system and its components. Operational state data is sometimes called ephemeral (or non-persistent configuration data), as opposed to the "configuration data" that is persistent. See RFC 6244 section 4.3.2.x for some useful examples. The statement has been carefully crafted to cover the 4 different cases: SNMP NETCONF/YANG +-----------------------------------------------------------------+--------------------------------------------------+ Configuration data | SHOULD NOT specify writable MIB modules | SHOULD use NETCONF/YANG | |-----------------------------------------------------------------+--------------------------------------------------| Operational State data | Not clear guidelines at time point in time (*) | SHOULD use NETCONF/YANG | +---------------------------------------------------------------------------------------------------------------------+ Let me focus on (*). Some of you are telling: SNMPset is not enabled in networks, period. Don't specify new writable MIB modules, even for operational state data, it doesn't make sense. Some others are telling: Note that this statement limits the discussion to configuration data. Note also that there is no standard way to modify operational state via NETCONF at this point in time (so it would be strange to discourage SNMP if there is no standardized alternative). I believe we need some more discussion on this specific point. Please share your point of view: - Should we keep the statement as it is, but better explain it? (which might require more background, so maybe a draft instead of a brief statement) - Should we extend the statement and remove "persistent" from this sentence: SNMP MIB modules creating and modifying persistent configuration state should only be produced by working groups in cases of clear utility and consensus to use SNMP write operations for configuration? - Something else? Regards, Benoit --------------000602030604000103010606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

[I bcc'ed some people, with whom I discussed this issue privately. I want to make sure they're in the opsarea loop. Sorry, if you receive this email twice]

I discussed the following statement with the IESG. I ideally wanted to have this statement approved as an IESG statement before the beginning of the week, but I realize that it might need some more discussion among the OPS community...
The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, especially in new charters. SNMP MIB modules creating and modifying persistent configuration state should only be produced by working groups in cases of clear utility and consensus to use SNMP write operations for configuration.
Btw, one IESG member insisted on having "creating and modifying" instead of "modifying".

Let me focus on a more important issue.
First let me make sure that we agree on one terminology. The NETCONF/YANG terminology is in RFC 6244:
  o  Configuration data is the set of writable data that is required to
      transform a system from its initial default state into its current
      state [RFC4741].

   o  Operational state data is a set of data that has been obtained by
      the system at runtime and influences the system's behavior similar
      to configuration data.  In contrast to configuration data,
      operational state is transient and modified by interactions with
      internal components or other systems via specialized protocols.

   o  Statistical data is the set of read-only data created by a system
      itself.  It describes the performance of the system and its
      components.
Operational state data is sometimes called ephemeral (or non-persistent configuration data), as opposed to the "configuration data" that is persistent.
See RFC 6244 section 4.3.2.x for some useful examples.

The statement has been carefully crafted to cover the 4 different cases:

                                                                             SNMP                                                         NETCONF/YANG
                                              +-----------------------------------------------------------------+--------------------------------------------------+
            Configuration data  | SHOULD NOT specify writable MIB modules    |  SHOULD use NETCONF/YANG          |
                                              |-----------------------------------------------------------------+--------------------------------------------------|
     Operational State data  | Not clear guidelines at time point in time  (*)   |   SHOULD use NETCONF/YANG         |
                                              +---------------------------------------------------------------------------------------------------------------------+                                             

Let me focus on (*).
Some of you are telling: SNMPset is not enabled in networks, period. Don't specify new writable MIB modules, even for operational state data, it doesn't make sense.
Some others are telling: Note that this statement limits the discussion to configuration data. Note also that there is no standard way to modify operational state via NETCONF at this point in time (so it would be strange to discourage SNMP if there is no standardized alternative).

I believe we need some more discussion on this specific point.  Please share your point of view:
- Should we keep the statement as it is, but better explain it? (which might require more background, so maybe a draft instead of a brief statement)
- Should we extend the statement and remove "persistent" from this sentence: SNMP MIB modules creating and modifying persistent configuration state should only be produced by working groups in cases of clear utility and consensus to use SNMP write operations for configuration?
- Something else?

Regards, Benoit




--------------000602030604000103010606-- From nobody Fri Feb 28 04:38:12 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E769D1A0739 for ; Fri, 28 Feb 2014 04:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.516 X-Spam-Level: X-Spam-Status: No, score=-0.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMmmJQhCKh5J for ; Fri, 28 Feb 2014 04:38:08 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 406191A07B5 for ; Fri, 28 Feb 2014 04:38:06 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-8c-5310832cde21 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 42.30.04853.C2380135; Fri, 28 Feb 2014 13:38:04 +0100 (CET) Received: from [159.107.197.144] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.2.347.0; Fri, 28 Feb 2014 13:38:03 +0100 Message-ID: <5310832B.8010404@ericsson.com> Date: Fri, 28 Feb 2014 13:38:03 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Benoit Claise , "ops-area@ietf.org" References: <53107BAF.2050808@cisco.com> In-Reply-To: <53107BAF.2050808@cisco.com> Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgluLIzCtJLcpLzFFi42KZGfG3RlenWSDYoHurvMXRxxIW6w9OYnNg 8pjyeyOrx5IlP5kCmKK4bFJSczLLUov07RK4Mvb9/sRccNqu4u3/p0wNjK+Nuhg5OCQETCQ2 HJXuYuQEMsUkLtxbz9bFyMUhJHCCUeLRqwusEM5aRolXz9+wgFTxCmhLLJl9khnEZhFQlZh7 7SxYnE3ASGJq/3kwW1QgSuLnlQXsEPWCEidnPgGLiwj4SZy5/xUsLiyQJHHyxXEWkCOEBDQk pl9wBwlzCmhKLL3zjRXEZhbQlbjwfwoLhC0vsf3tHLC1IOUPL/xlncAoMAvJhllIWmYhaVnA yLyKUbI4tbg4N93IQC83PbdEL7UoM7m4OD9Przh1EyMwNA9u+W20g/HkHvtDjNIcLErivNdZ a4KEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MIaI8OWY+bdKn8idu7zvA3vRz+Q7/83Cv6a/ lUtXbRBlzljkvXFtSqzN5m/fLHlsP566ZXKqPWZ/4vbJ9+qf/zvkOtlj5ZQyj93tISzHJ111 FlluXqFz4fn/DH4TsbXTPgTOjPhmUWxW7sEn31li/jvthmm7+0R5ibXdac/PKbwKkn1Rwf55 nxJLcUaioRZzUXEiAPh/PgsbAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/0OKRkXKpwmBjVmqSjASHxL6NujY Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 12:38:10 -0000 IMHO we should define in Netconf/YANG how to handle  operational state data.
Balazs

P.S. "Ephemeral configuration" is a much better name. It is writable configuration and it effects how the node behaves. The name "operational state" carries neither of these two meanings.

On 2014-02-28 13:06, Benoit Claise wrote:
Dear all,

[I bcc'ed some people, with whom I discussed this issue privately. I want to make sure they're in the opsarea loop. Sorry, if you receive this email twice]

I discussed the following statement with the IESG. I ideally wanted to have this statement approved as an IESG statement before the beginning of the week, but I realize that it might need some more discussion among the OPS community...
The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, especially in new charters. SNMP MIB modules creating and modifying persistent configuration state should only be produced by working groups in cases of clear utility and consensus to use SNMP write operations for configuration.
Btw, one IESG member insisted on having "creating and modifying" instead of "modifying".

Let me focus on a more important issue.
First let me make sure that we agree on one terminology. The NETCONF/YANG terminology is in RFC 6244:
  o  Configuration data is the set of writable data that is required to
      transform a system from its initial default state into its current
      state [RFC4741].

   o  Operational state data is a set of data that has been obtained by
      the system at runtime and influences the system's behavior similar
      to configuration data.  In contrast to configuration data,
      operational state is transient and modified by interactions with
      internal components or other systems via specialized protocols.

   o  Statistical data is the set of read-only data created by a system
      itself.  It describes the performance of the system and its
      components.
Operational state data is sometimes called ephemeral (or non-persistent configuration data), as opposed to the "configuration data" that is persistent.
See RFC 6244 section 4.3.2.x for some useful examples.

The statement has been carefully crafted to cover the 4 different cases:

                                                                             SNMP                                                         NETCONF/YANG
                                              +-----------------------------------------------------------------+--------------------------------------------------+
            Configuration data  | SHOULD NOT specify writable MIB modules    |  SHOULD use NETCONF/YANG          |
                                              |-----------------------------------------------------------------+--------------------------------------------------|
     Operational State data  | Not clear guidelines at time point in time  (*)   |   SHOULD use NETCONF/YANG         |
                                              +---------------------------------------------------------------------------------------------------------------------+                                             

Let me focus on (*).
Some of you are telling: SNMPset is not enabled in networks, period. Don't specify new writable MIB modules, even for operational state data, it doesn't make sense.
Some others are telling: Note that this statement limits the discussion to configuration data. Note also that there is no standard way to modify operational state via NETCONF at this point in time (so it would be strange to discourage SNMP if there is no standardized alternative).

I believe we need some more discussion on this specific point.  Please share your point of view:
- Should we keep the statement as it is, but better explain it? (which might require more background, so maybe a draft instead of a brief statement)
- Should we extend the statement and remove "persistent" from this sentence: SNMP MIB modules creating and modifying persistent configuration state should only be produced by working groups in cases of clear utility and consensus to use SNMP write operations for configuration?
- Something else?

Regards, Benoit






_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area


-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Fri Feb 28 04:44:14 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DD61A0227 for ; Fri, 28 Feb 2014 04:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqD2_2jidFyp for ; Fri, 28 Feb 2014 04:43:59 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0011.outbound.protection.outlook.com [213.199.154.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1259A1A079F for ; Fri, 28 Feb 2014 04:43:58 -0800 (PST) Received: from DB3PRD0411HT001.eurprd04.prod.outlook.com (157.56.253.53) by DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) with Microsoft SMTP Server (TLS) id 15.0.888.9; Fri, 28 Feb 2014 12:43:55 +0000 Message-ID: <006d01cf3482$071bf7e0$4001a8c0@gateway.2wire.net> From: t.petch To: Benoit Claise , References: <53107BAF.2050808@cisco.com> Date: Fri, 28 Feb 2014 12:38:41 +0000 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.53] X-ClientProxiedBy: AMSPR07CA019.eurprd07.prod.outlook.com (10.242.225.177) To DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) X-Forefront-PRVS: 0136C1DDA4 X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(3?= =?iso-8859-1?Q?77454003)(51704005)(13464003)(95666003)(47976001)(44736004?= =?iso-8859-1?Q?)(50986001)(93516002)(93916002)(86362001)(95416001)(504660?= =?iso-8859-1?Q?02)(69226001)(46102001)(31966008)(74662001)(74502001)(4744?= =?iso-8859-1?Q?6002)(51856001)(42186004)(94316002)(92566001)(76796001)(76?= =?iso-8859-1?Q?786001)(94946001)(92726001)(77096001)(77156001)(93136001)(?= =?iso-8859-1?Q?80976001)(74366001)(23756003)(83322001)(19580395003)(19580?= =?iso-8859-1?Q?405001)(56776001)(54316002)(76482001)(74706001)(88136002)(?= =?iso-8859-1?Q?87976001)(87266001)(87286001)(14496001)(85852003)(56816005?= =?iso-8859-1?Q?)(90146001)(59766001)(77982001)(74876001)(81542001)(612960?= =?iso-8859-1?Q?02)(66066001)(84392001)(65816001)(80022001)(50226001)(6296?= =?iso-8859-1?Q?6002)(53806001)(81342001)(49866001)(4396001)(47736001)(477?= =?iso-8859-1?Q?76003)(15975445006)(89996001)(83072002)(85306002)(79102001?= =?iso-8859-1?Q?)(44716002)(33646001)(62236002)(63696002)(74416001)(772600?= =?iso-8859-1?Q?1);DIR:OUT;SFP:1101;SCL:1;SRVR:DBXPR07MB061;H:DB3PRD0411HT?= =?iso-8859-1?Q?001.eurprd04.prod.outlook.com;CLIP:157.56.253.53;FPR:FCECF?= =?iso-8859-1?Q?135.A1F6D2C2.B1C4B630.46E5915C.2042C;PTR:InfoNoRecords;MX:?= =?iso-8859-1?Q?1;A:0;LANG:en;?= Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/6p1bnKdUi2_jyIASROIaCDztTlY Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 12:44:02 -0000 ----- Original Message ----- From: "Benoit Claise" To: Sent: Friday, February 28, 2014 12:06 PM Subject: [OPS-AREA] configuration: writable MIB modules versus > Dear all, > > [I bcc'ed some people, with whom I discussed this issue privately. I > want to make sure they're in the opsarea loop. Sorry, if you receive > this email twice] > > I discussed the following statement with the IESG. I ideally wanted to > have this statement approved as an IESG statement before the beginning > of the week, but I realize that it might need some more discussion among > the OPS community... > > The OPS area recommends the use of NETCONF/YANG standards for > configuration. IETF working groups are therefore encouraged to use > the NETCONF/YANG standards for configuration, especially in new > charters. SNMP MIB modules _creating and_ modifying persistent > configuration state should only be produced by working groups in > cases of clear utility and consensus to use SNMP write operations > for configuration. > > Btw, one IESG member insisted on having "_creating and_ modifying" > instead of "modifying". > > Let me focus on a more important issue. > First let me make sure that we agree on one terminology. The > NETCONF/YANG terminology is in RFC 6244: > > o Configuration data is the set of writable data that is required to > transform a system from its initial default state into its current > state [RFC4741 ]. > > o Operational state data is a set of data that has been obtained by > the system at runtime and influences the system's behavior similar > to configuration data. In contrast to configuration data, > operational state is transient and modified by interactions with > internal components or other systems via specialized protocols. > > o Statistical data is the set of read-only data created by a system > itself. It describes the performance of the system and its > components. > > Operational state data is sometimes called ephemeral (or non-persistent > configuration data), as opposed to the "configuration data" that is > persistent. > See RFC 6244 section 4.3.2.x for some useful examples. > > The statement has been carefully crafted to cover the 4 different cases: > > SNMP NETCONF/YANG > +-----------------------------------------------------------------+----- ---------------------------------------------+ > Configuration data | SHOULD NOT specify writable MIB > modules | SHOULD use NETCONF/YANG | > |-----------------------------------------------------------------+----- ---------------------------------------------| > Operational State data | Not clear guidelines at time point in > time (*) | SHOULD use NETCONF/YANG | > +----------------------------------------------------------------------- ----------------------------------------------+ > > > Let me focus on (*). > Some of you are telling: SNMPset is not enabled in networks, period. > Don't specify new writable MIB modules, even for operational state data, > it doesn't make sense. > Some others are telling: Note that this statement limits the discussion > to configuration data. Note also that there is no standard way to modify > operational state via NETCONF at this point in time (so it would be > strange to discourage SNMP if there is no standardized alternative). > > I believe we need some more discussion on this specific point. Please > share your point of view: > - Should we keep the statement as it is, but better explain it? (which > might require more background, so maybe a draft instead of a brief > statement) Make it a draft, with an IETF Last Call. It is too important for just this list. Tom Petch > - Should we extend the statement and remove "persistent" from this > sentence: SNMP MIB modules creating and modifying persistent > configuration state should only be produced by working groups in cases > of clear utility and consensus to use SNMP write operations for > configuration? > - Something else? > > Regards, Benoit > > > > > ------------------------------------------------------------------------ -------- > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > From nobody Fri Feb 28 05:32:16 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADA41A04AF for ; Fri, 28 Feb 2014 05:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuLZhbGaGkvA for ; Fri, 28 Feb 2014 05:32:12 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6C11A04A1 for ; Fri, 28 Feb 2014 05:32:11 -0800 (PST) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 23DFD13FACA; Fri, 28 Feb 2014 14:32:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1393594329; bh=9zDvaTxvojeiBzeSJ3g8n0dUpTZfNYsy5owmZEzK3VY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=JYE6NXMbW+u7y/cFJ6PF88+48gFzAGiWkEwlZkhTA2hObnSHCH23j+Za/VWEXOezf ephw5uDvm1RL8v/yKxXfOh1vcd4Ekfey8Qu+FObPzRYZ0/rNMqZK7YLXxruhmWeyJX megdLwRoLGmH7CerUYMrFI2yxWP43dGW9U13BAdg= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: <5310832B.8010404@ericsson.com> Date: Fri, 28 Feb 2014 14:32:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53107BAF.2050808@cisco.com> <5310832B.8010404@ericsson.com> To: Balazs Lengyel X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/qFLjzHhKGUIuTmkYXrE2cnAgIQ0 Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 13:32:14 -0000 On 28 Feb 2014, at 13:38, Balazs Lengyel = wrote: > IMHO we should define in Netconf/YANG how to handle operational state = data. I think the concept of operational state data should be defined in a way = that is independent of NETCONF - the rules should be common for all = protocols and other methods that read, create and modify operational = state data. The /proc filesystem is IMO a good model. A corollary to this is that YANG could be used for modelling operational = state data under the assumption that its specification is = protocol-neutral (which is currently not the case). In contrast, configuration can be considered NETCONF-specific. > =20 > Balazs >=20 > P.S. "Ephemeral configuration" is a much better name. It is writable = configuration and it effects how the node behaves. The name "operational = state" carries neither of these two meanings. My understanding is that operational state data may also include items = that are by definition not writable. Lada=20 >=20 > On 2014-02-28 13:06, Benoit Claise wrote: >> Dear all, >>=20 >> [I bcc'ed some people, with whom I discussed this issue privately. I = want to make sure they're in the opsarea loop. Sorry, if you receive = this email twice] >>=20 >> I discussed the following statement with the IESG. I ideally wanted = to have this statement approved as an IESG statement before the = beginning of the week, but I realize that it might need some more = discussion among the OPS community... >> The OPS area recommends the use of NETCONF/YANG standards for = configuration. IETF working groups are therefore encouraged to use the = NETCONF/YANG standards for configuration, especially in new charters. = SNMP MIB modules creating and modifying persistent configuration state = should only be produced by working groups in cases of clear utility and = consensus to use SNMP write operations for configuration. >> Btw, one IESG member insisted on having "creating and modifying" = instead of "modifying".=20 >>=20 >> Let me focus on a more important issue. >> First let me make sure that we agree on one terminology. The = NETCONF/YANG terminology is in RFC 6244: >> o Configuration data is the set of writable data that is required = to >> transform a system from its initial default state into its = current >> state [ >> RFC4741 >> ]. >>=20 >> o Operational state data is a set of data that has been obtained = by >> the system at runtime and influences the system's behavior = similar >> to configuration data. In contrast to configuration data, >> operational state is transient and modified by interactions = with >> internal components or other systems via specialized protocols. >>=20 >> o Statistical data is the set of read-only data created by a = system >> itself. It describes the performance of the system and its >> components.=20 >>=20 >> Operational state data is sometimes called ephemeral (or = non-persistent configuration data), as opposed to the "configuration = data" that is persistent. >> See RFC 6244 section 4.3.2.x for some useful examples. >>=20 >> The statement has been carefully crafted to cover the 4 different = cases: >>=20 >> = SNMP = NETCONF/YANG=20 >> = +-----------------------------------------------------------------+-------= -------------------------------------------+ >> Configuration data | SHOULD NOT specify writable MIB = modules | SHOULD use NETCONF/YANG | >> = |-----------------------------------------------------------------+-------= -------------------------------------------| >> Operational State data | Not clear guidelines at time point in = time (*) | SHOULD use NETCONF/YANG | >> = +-------------------------------------------------------------------------= --------------------------------------------+ = =20 >>=20 >> Let me focus on (*). >> Some of you are telling: SNMPset is not enabled in networks, period. = Don't specify new writable MIB modules, even for operational state data, = it doesn't make sense. >> Some others are telling: Note that this statement limits the = discussion to configuration data. Note also that there is no standard = way to modify operational state via NETCONF at this point in time (so it = would be strange to discourage SNMP if there is no standardized = alternative).=20 >>=20 >> I believe we need some more discussion on this specific point. = Please share your point of view: >> - Should we keep the statement as it is, but better explain it? = (which might require more background, so maybe a draft instead of a = brief statement) >> - Should we extend the statement and remove "persistent" from this = sentence: SNMP MIB modules creating and modifying persistent = configuration state should only be produced by working groups in cases = of clear utility and consensus to use SNMP write operations for = configuration? >> - Something else? >>=20 >> Regards, Benoit >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OPS-AREA mailing list >>=20 >> OPS-AREA@ietf.org >> https://www.ietf.org/mailman/listinfo/ops-area >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > System Manager > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email:=20 > Balazs.Lengyel@ericsson.com > =20 >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Feb 28 06:26:45 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35281A02A8 for ; Fri, 28 Feb 2014 06:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi_tTMGHcjSV for ; Fri, 28 Feb 2014 06:26:36 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id C6D541A0807 for ; Fri, 28 Feb 2014 06:26:35 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id x3so761411qcv.18 for ; Fri, 28 Feb 2014 06:26:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YTV1hhMeiUkMHQd47lQ+qgtPc0WVKggGTInpuKjvO1E=; b=O1Y3Nghb1FMoZu6qlknSs2d5hQrj6aJSw/2bMjYBNNGB4mhdy7yoE0f61IDF0vu6bz wfa2PAlqS9OfRGx6GQswVM5I3D5HIs0KW+cVM1bKFYjfvIVyuUs4KBORDHmF/XbWcWhv rS/go8KbyQQGeNSjrMJWhAxWffHS6RrrXp/gmrBaLTNIt+TCOIh/dLP0qm2z0VVaTKMd LfNsQrsyo1WRmQCEYSO4nRHpLJYi9yxfrR9BvkpDkRvIFaNSa6XosCaptbXRWMHDv6C6 HNv68IVNGDbQ/XsUkyi0SisoJsTS/NvRwSDVL8k3ojLB2UJHx7BhSyfwdhDBDTLyjGSJ lJyw== X-Gm-Message-State: ALoCoQmooSzCtqfwQhv4EUBS82LIQxQkb8sjvr/iHkDDPAie72oX1dG0akn81ItPGFGxp6M/jJNi MIME-Version: 1.0 X-Received: by 10.224.161.5 with SMTP id p5mr3965621qax.88.1393597593725; Fri, 28 Feb 2014 06:26:33 -0800 (PST) Received: by 10.140.104.194 with HTTP; Fri, 28 Feb 2014 06:26:33 -0800 (PST) In-Reply-To: <53107BAF.2050808@cisco.com> References: <53107BAF.2050808@cisco.com> Date: Fri, 28 Feb 2014 06:26:33 -0800 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: multipart/alternative; boundary=089e0149cae688d56804f37839fc Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/29F5jUXfcG1bmCdZV9pjQy9a3Dw Cc: "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 14:26:44 -0000 --089e0149cae688d56804f37839fc Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 28, 2014 at 4:06 AM, Benoit Claise wrote: > Dear all, > > [I bcc'ed some people, with whom I discussed this issue privately. I want > to make sure they're in the opsarea loop. Sorry, if you receive this email > twice] > > I discussed the following statement with the IESG. I ideally wanted to > have this statement approved as an IESG statement before the beginning of > the week, but I realize that it might need some more discussion among the > OPS community... > > The OPS area recommends the use of NETCONF/YANG standards for > configuration. IETF working groups are therefore encouraged to use the > NETCONF/YANG standards for configuration, especially in new charters. SNMP > MIB modules *creating and* modifying persistent configuration state > should only be produced by working groups in cases of clear utility and > consensus to use SNMP write operations for configuration. > > Btw, one IESG member insisted on having "*creating and* modifying" > instead of "modifying". > > Let me focus on a more important issue. > First let me make sure that we agree on one terminology. The NETCONF/YANG > terminology is in RFC 6244: > > o Configuration data is the set of writable data that is required to > transform a system from its initial default state into its current > state [RFC4741 ]. > > o Operational state data is a set of data that has been obtained by > the system at runtime and influences the system's behavior similar > to configuration data. In contrast to configuration data, > operational state is transient and modified by interactions with > internal components or other systems via specialized protocols. > > o Statistical data is the set of read-only data created by a system > itself. It describes the performance of the system and its > components. > > Operational state data is sometimes called ephemeral (or non-persistent > configuration data), as opposed to the "configuration data" that is > persistent. > See RFC 6244 section 4.3.2.x for some useful examples. > > The statement has been carefully crafted to cover the 4 different cases: > > > SNMP NETCONF/YANG > > +-----------------------------------------------------------------+--------------------------------------------------+ > Configuration data | SHOULD NOT specify writable MIB modules > | SHOULD use NETCONF/YANG | > > |-----------------------------------------------------------------+--------------------------------------------------| > Operational State data | Not clear guidelines at time point in time > (*) | SHOULD use NETCONF/YANG | > > +---------------------------------------------------------------------------------------------------------------------+ > > > Let me focus on (*). > Some of you are telling: SNMPset is not enabled in networks, period. Don't > specify new writable MIB modules, even for operational state data, it > doesn't make sense. > Some others are telling: Note that this statement limits the discussion to > configuration data. Note also that there is no standard way to modify > operational state via NETCONF at this point in time (so it would be strange > to discourage SNMP if there is no standardized alternative). > > I believe we need some more discussion on this specific point. Please > share your point of view: > - Should we keep the statement as it is, but better explain it? (which > might require more background, so maybe a draft instead of a brief > statement) > - Should we extend the statement and remove "persistent" from this > sentence: SNMP MIB modules creating and modifying persistent configuration > state should only be produced by working groups in cases of clear utility > and consensus to use SNMP write operations for configuration? > - Something else? > Unless some WG is asking to use SNMP Set to edit operational state, I don't see why new work (SNMPv4?) would begin, or even why guidance is needed in this matter. NETCONF already supports actions that can change operational state as a side-effect. A standard edit function to do the same could be added. I am more concerned with the security and operational issues related to editing operational state, than the editing mechanics. Where is the standard audit log for example? If we say "SHOULD use (whatever)", then it seems we are saying that any WG can start creating editable state. I don't think that is a good idea. It would be better to wait and see how it goes with I2RS before making general guidelines. IMO a protocol-independent architecture that properly deals with the interactions between "running config", "ephemeral config", "operational state", and "statistics" is needed. > Regards, Benoit > Andy > > > > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > > --089e0149cae688d56804f37839fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Feb 28, 2014 at 4:06 AM, Benoit Claise &l= t;bclaise@cisco.com<= /a>> wrote:
=20 =20 =20
Dear all,

[I bcc'ed some people, with whom I discussed this issue privately. = I want to make sure they're in the opsarea loop. Sorry, if you receiv= e this email twice]

I discussed the following statement with the IESG. I ideally wanted to have this statement approved as an IESG statement before the beginning of the week, but I realize that it might need some more discussion among the OPS community...
The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, especially in new charters. SNMP MIB modules creating and modifying persistent configuration state should only be produced by working groups in cases of clear utility and consensus to use SNMP write operations for configuration.
Btw, one IESG member insisted on having "creating and modifying" instead of "modifying".

Let me focus on a more important issue.
First let me make sure that we agree on one terminology. The NETCONF/YANG terminology is in RFC 6244:
  o  Configuration data is the set of writable data that is requir=
ed to
      transform a system from its initial default state into its current
      state [RFC4741].

   o  Operational state data is a set of data that has been obtained by
      the system at runtime and influences the system's behavior simila=
r
      to configuration data.  In contrast to configuration data,
      operational state is transient and modified by interactions with
      internal components or other systems via specialized protocols.

   o  Statistical data is the set of read-only data created by a system
      itself.  It describes the performance of the system and its
      components.
Operational state data is sometimes called ephemeral (or non-persistent configuration data), as opposed to the "configurati= on data" that is persistent.
See RFC 6244 section 4.3.2.x for some useful examples.

The statement has been carefully crafted to cover the 4 different cases:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SNMP =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 NETCONF/YANG
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------------------------------------------------+--------= ------------------------------------------+
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 Configuration data=A0 | SHOULD NOT specif= y writable MIB modules=A0 =A0 |=A0 SHOULD use NETCONF/YANG =A0 =A0=A0 =A0 =A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |-----------------------------------------------------------------+--------= ------------------------------------------|
=A0=A0=A0=A0 Operational State data=A0 | Not clear guidelines at time p= oint in time=A0 (*) =A0 |=A0=A0 SHOULD use NETCONF/YANG=A0 =A0 =A0 =A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +----------------------------------------------------------------------= -----------------------------------------------+=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

Let me focus on (*).
Some of you are telling: SNMPset is not enabled in networks, period. Don't specify new writable MIB modules, even for operational state data, it doesn't make sense.
Some others are telling: Note that this statement limits the discussion to configuration data. Note also that there is no standard way to modify operational state via NETCONF at this point in time (so it would be strange to discourage SNMP if there is no standardized alternative).

I believe we need some more discussion on this specific point.=A0 Please share your point of view:
- Should we keep the statement as it is, but better explain it? (which might require more background, so maybe a draft instead of a brief statement)
- Should we extend the statement and remove "persistent" from= this sentence: SNMP MIB modules creating and modifying persistent configuration state should only be produced by working groups in cases of clear utility and consensus to use SNMP write operations for configuration?
- Something else?


<= div>Unless some WG is asking to use SNMP Set to edit operational state, I d= on't
see why new work (SNMPv4?) would begin, or even why guid= ance is needed
in this matter.

NETCONF already supports acti= ons that can change operational state as
a side-effect. =A0A stan= dard edit function to do the same could be added.
I am more conce= rned with the security and operational issues related
to editing operational state, than the editing mechanics.
Wh= ere is the standard audit log for example?

If we s= ay "SHOULD use (whatever)", then it seems we are saying that
any WG can start creating editable state. =A0I don't think that is= a good idea.
It would be better to wait and see how it goes with= I2RS before making
general guidelines. =A0IMO a protocol-indepen= dent architecture that
properly deals with the interactions between "running config"= ;, "ephemeral config",
"operational state", a= nd "statistics" is needed.



Regards, Benoit

Andy
=A0





_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area


--089e0149cae688d56804f37839fc-- From nobody Fri Feb 28 08:28:19 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697D11A0184 for ; Fri, 28 Feb 2014 08:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjEEWEt3GbQL for ; Fri, 28 Feb 2014 08:28:15 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB761A00EF for ; Fri, 28 Feb 2014 08:28:15 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WJQIG-0006EB-G9; Fri, 28 Feb 2014 16:28:12 +0000 Date: Fri, 28 Feb 2014 16:28:11 +0000 Message-ID: From: Randy Bush To: Benoit Claise In-Reply-To: <53107BAF.2050808@cisco.com> References: <53107BAF.2050808@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/NP_d0jpVKUHvIlvjXjOEeEKwEB8 Cc: ops-area Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 16:28:17 -0000 > o Configuration data is the set of writable data that is required to > transform a system from its initial default state into its current > state [RFC4741 ]. > > o Operational state data is a set of data that has been obtained by > the system at runtime and influences the system's behavior similar > to configuration data. In contrast to configuration data, > operational state is transient and modified by interactions with > internal components or other systems via specialized protocols. data are plural, please i never understood the fantasy of this dichotomy. all (non measurement) data are operational. i do not see a difference between configuring a bgp peer, filters, interface up/down, ... the dichotomy is in my use models. do i configure systems programatically or do i have banana eater keyboard jockies running my network? the former uses netconf or expect and the latter use the cli. none of them use snmp write. i thought we made that point over a decade ago. randy From nobody Fri Feb 28 10:05:06 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9F61A0252 for ; Fri, 28 Feb 2014 10:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.847 X-Spam-Level: X-Spam-Status: No, score=0.847 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLqJ9S5BYUm2 for ; Fri, 28 Feb 2014 10:05:02 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7621A01A6 for ; Fri, 28 Feb 2014 10:05:02 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1SI4v0R017537; Fri, 28 Feb 2014 18:04:57 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1SI4sKT017506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Feb 2014 18:04:55 GMT From: "Adrian Farrel" To: "'Benoit Claise'" References: <53107BAF.2050808@cisco.com> In-Reply-To: Date: Fri, 28 Feb 2014 18:04:53 -0000 Message-ID: <15dc01cf34af$961c6c40$c25544c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIvDn7xpdUN7mq4kMlIt8MnA0+s0AJfA0Q/mfhGLVA= Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/vL1Sj-o5NvsnEk2-cv2ZcySHeug Cc: 'ops-area' Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 18:05:04 -0000 Top posting for the hell of it. My "problem" with these definitions are that their use of passive voice mistakes the view from the management station and the view from the node. Maybe this is the point Randy has. From the node's perspective, it doesn't care where the data came from (except maybe for prioritising it over other inputs). You don't forward packets differently on routes learnt from an IGP compared with routes programmed by an operator. Curiously, the definitions here seem to be different from those that I just read on a back-channel discussion with Benoit and others where we had: "operational data" includes both state learned from the network and the administrative state pushed to the various routing and such processes. "configuration data" can be persistent or ephemeral - but it's all held by the management side, whether that is CLI or NetConf. I am also having serious difficulty with the concept of persistence because it can be persistent in the management station or persistent in the node. (One hopes the latter is a subset of the former.) Maybe operational state can be persistent (at the node) and no-one thought to mention it? That could certainly complete the definitions. Anyway, is there any reason why the draft IESG statement text uses "configuration data" in all cases except "SNMP MIB modules creating and modifying persistent configuration"? Why "persistent" in this one case? Does it make any difference whether SNMP is used to write persistent or non-persistent configuration data? And lastly... +1 to Randy. I thought the main thrust of what we were trying to do was describe whether SNMP Set is valuable, and if so in what context. Cheers, Adrian > -----Original Message----- > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Randy Bush > Sent: 28 February 2014 16:28 > To: Benoit Claise > Cc: ops-area > Subject: Re: [OPS-AREA] configuration: writable MIB modules versus > NETCONF/YANG modules - part 2 > > > o Configuration data is the set of writable data that is required to > > transform a system from its initial default state into its current > > state [RFC4741 ]. > > > > o Operational state data is a set of data that has been obtained by > > the system at runtime and influences the system's behavior similar > > to configuration data. In contrast to configuration data, > > operational state is transient and modified by interactions with > > internal components or other systems via specialized protocols. > > i never understood the fantasy of this dichotomy. all (non measurement) > data are operational. i do not see a difference between configuring a > bgp peer, filters, interface up/down, ... the dichotomy is in my use > models. do i configure systems programatically or do i have banana > eater keyboard jockies running my network? the former uses netconf or > expect and the latter use the cli. > > none of them use snmp write. i thought we made that point over a decade > ago. > > randy > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area From nobody Fri Feb 28 10:57:32 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87F11A013A for ; Fri, 28 Feb 2014 10:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2w4nzv35Xn3 for ; Fri, 28 Feb 2014 10:57:28 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF771A0059 for ; Fri, 28 Feb 2014 10:57:28 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C4D571D03; Fri, 28 Feb 2014 19:57:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ya7g-NFV1fqt; Fri, 28 Feb 2014 19:57:24 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Fri, 28 Feb 2014 19:57:24 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4344E2002C; Fri, 28 Feb 2014 19:57:24 +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 SS7t3apKR3RH; Fri, 28 Feb 2014 19:57:22 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C5C420017; Fri, 28 Feb 2014 19:57:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 530552B8B68A; Fri, 28 Feb 2014 19:57:18 +0100 (CET) Date: Fri, 28 Feb 2014 19:57:17 +0100 From: Juergen Schoenwaelder To: Adrian Farrel Message-ID: <20140228185713.GA15098@elstar.local> Mail-Followup-To: Adrian Farrel , 'Benoit Claise' , 'ops-area' References: <53107BAF.2050808@cisco.com> <15dc01cf34af$961c6c40$c25544c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15dc01cf34af$961c6c40$c25544c0$@olddog.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/gzMhOjecAlquw0VtJbA37_DOfmk Cc: 'ops-area' Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 18:57:31 -0000 On Fri, Feb 28, 2014 at 06:04:53PM +0000, Adrian Farrel wrote: > Anyway, is there any reason why the draft IESG statement text uses > "configuration data" in all cases except "SNMP MIB modules creating > and modifying persistent configuration"? Why "persistent" in this > one case? Does it make any difference whether SNMP is used to write > persistent or non-persistent configuration data? For an NMS, it is crucial to know whether something is persistent configuration or dynamic operational state. Yes, a router's forwarding plane does not care where the forwarding table entry came from. However, those who have to troubleshoot things very likely want to know whether a forwarding entry is coming from persistent configuration or whether it is the result of some operational state picked up at runtime. Similarly, when an NMS makes change, it likes to know whether the change persists or not. CLIs often make clear distinctions between changes that are persistent and stuff that is forgotton on the next reload. For SNMP MIB modules, exposing the difference is somewhat complicated since you need to deal with StorageType objects to express what is persistent (well and even StorageType allows freedom so that the management system still has to guess). A simple operation such as "show the persistent configuration" or "show the configuration used at next reload" that every CLI supports is really hard to do with SNMP. In contrast, tweaking operational state at runtime of stuff that is there already is fairly easy. But even then, it often remains unclear whether a change persists or not. Note also that some SNMP tools tend to generate sequences of SNMP set requests to make a conceptual change. This (a) causes the generation of temporary state and (b) leaves it open when changes are actually committed to stable storage. This all rasies costs (on both the device and the NMS side) and makes things brittle. SNMP really is IMHO horribly broken for configuration management and attempts to fix it failed. This is long known and also documented in RFC 3535. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Feb 28 12:16:52 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386511A02D0 for ; Fri, 28 Feb 2014 12:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.217 X-Spam-Level: X-Spam-Status: No, score=0.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6Xe1xvooZMS for ; Fri, 28 Feb 2014 12:16:37 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id D61E91A0300 for ; Fri, 28 Feb 2014 12:16:29 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1SKGMrA007581; Fri, 28 Feb 2014 20:16:22 GMT Received: from 950129200 (13.17.90.92.rev.sfr.net [92.90.17.13]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1SKGKZ9007571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Feb 2014 20:16:21 GMT From: "Adrian Farrel" To: "'Juergen Schoenwaelder'" References: <53107BAF.2050808@cisco.com> <15dc01cf34af$961c6c40$c25544c0$@olddog.co.uk> <20140228185713.GA15098@elstar.local> In-Reply-To: <20140228185713.GA15098@elstar.local> Date: Fri, 28 Feb 2014 20:16:19 -0000 Message-ID: <163801cf34c1$f2a6e4b0$d7f4ae10$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIvDn7xpdUN7mq4kMlIt8MnA0+s0AJfA0Q/AVBCVm8B4b7ma5ne3jcQ Content-Language: en-gb X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/MnfNjHvyvyWh_gCMTxCuRCbhpvU Cc: 'ops-area' Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 20:16:39 -0000 Hi Juergen, Thanks for the explanation of the difference between "configuration data" and "persistent configuration data". >From your final statement... > SNMP really is IMHO horribly broken for > configuration management and attempts to fix it failed. This is long > known and also documented in RFC 3535. I take it that you would assert that the draft statement should read "SNMP MIB modules creating and modifying configuration" leaving out the word "persistent" Thanks, Adrian > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: 28 February 2014 18:57 > To: Adrian Farrel > Cc: 'Benoit Claise'; 'ops-area' > Subject: Re: [OPS-AREA] configuration: writable MIB modules versus > NETCONF/YANG modules - part 2 > > On Fri, Feb 28, 2014 at 06:04:53PM +0000, Adrian Farrel wrote: > > > Anyway, is there any reason why the draft IESG statement text uses > > "configuration data" in all cases except "SNMP MIB modules creating > > and modifying persistent configuration"? Why "persistent" in this > > one case? Does it make any difference whether SNMP is used to write > > persistent or non-persistent configuration data? > > For an NMS, it is crucial to know whether something is persistent > configuration or dynamic operational state. Yes, a router's forwarding > plane does not care where the forwarding table entry came from. > However, those who have to troubleshoot things very likely want to > know whether a forwarding entry is coming from persistent > configuration or whether it is the result of some operational state > picked up at runtime. Similarly, when an NMS makes change, it likes to > know whether the change persists or not. CLIs often make clear > distinctions between changes that are persistent and stuff that is > forgotton on the next reload. > > For SNMP MIB modules, exposing the difference is somewhat complicated > since you need to deal with StorageType objects to express what is > persistent (well and even StorageType allows freedom so that the > management system still has to guess). A simple operation such as > "show the persistent configuration" or "show the configuration used at > next reload" that every CLI supports is really hard to do with SNMP. > In contrast, tweaking operational state at runtime of stuff that is > there already is fairly easy. But even then, it often remains unclear > whether a change persists or not. Note also that some SNMP tools tend > to generate sequences of SNMP set requests to make a conceptual > change. This (a) causes the generation of temporary state and (b) > leaves it open when changes are actually committed to stable > storage. This all rasies costs (on both the device and the NMS side) > and makes things brittle. SNMP really is IMHO horribly broken for > configuration management and attempts to fix it failed. This is long > known and also documented in RFC 3535. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From nobody Fri Feb 28 12:43:09 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFFC1A0316 for ; Fri, 28 Feb 2014 12:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYgULyLjLwgp for ; Fri, 28 Feb 2014 12:43:06 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id EC2681A010F for ; Fri, 28 Feb 2014 12:43:05 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 70A311D03; Fri, 28 Feb 2014 21:43:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id oM5bRazILUZV; Fri, 28 Feb 2014 21:43:01 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Fri, 28 Feb 2014 21:43:01 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 185C42002C; Fri, 28 Feb 2014 21:43:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id h4p1eMMHEoHs; Fri, 28 Feb 2014 21:42:59 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7415B20017; Fri, 28 Feb 2014 21:42:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F374D2B8B9A1; Fri, 28 Feb 2014 21:42:55 +0100 (CET) Date: Fri, 28 Feb 2014 21:42:53 +0100 From: Juergen Schoenwaelder To: Adrian Farrel Message-ID: <20140228204251.GA15464@elstar.local> Mail-Followup-To: Adrian Farrel , 'Benoit Claise' , 'ops-area' References: <53107BAF.2050808@cisco.com> <15dc01cf34af$961c6c40$c25544c0$@olddog.co.uk> <20140228185713.GA15098@elstar.local> <163801cf34c1$f2a6e4b0$d7f4ae10$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <163801cf34c1$f2a6e4b0$d7f4ae10$@olddog.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/pIvoY0okD1mGyvLz_9YvVXbf9Ug Cc: 'ops-area' Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 20:43:08 -0000 On Fri, Feb 28, 2014 at 08:16:19PM +0000, Adrian Farrel wrote: > Hi Juergen, > > Thanks for the explanation of the difference between "configuration data" and > "persistent configuration data". > > From your final statement... > > SNMP really is IMHO horribly broken for > > configuration management and attempts to fix it failed. This is long > > known and also documented in RFC 3535. > > I take it that you would assert that the draft statement should read > "SNMP MIB modules creating and modifying configuration" leaving out > the word "persistent" There are different terminologies around and depending on the one used I may agree or not. I definitely agree with "SNMP MIB modules creating and modifying persistent configuration" but that is likely not what you want to hear. ;-) In the NETCONF world, configuration data is pretty much synonymous with what I think you call persistent configuration. (The term 'persistent' does never appear in RFC 3535 but then RFC 3535 distinguishes between 'configuration data', operational state data, and statistics. RFC 6244 says (section 4.3.2): o Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state [RFC4741]. This kind of implies that the configuration data is persistent since it needs to be there when the device re-initializes. o Operational state data is a set of data that has been obtained by the system at runtime and influences the system's behavior similar to configuration data. In contrast to configuration data, operational state is transient and modified by interactions with internal components or other systems via specialized protocols. This means that routing protocols or dhcp or even things like i2rs simply mess around with operational state. o Statistical data is the set of read-only data created by a system itself. It describes the performance of the system and its components. Given this terminology, I think what you call non-persistent configuration is operational state data. For relatively simple things that mess around with operational state (setting a threshold, turning off an interface), SNMP's peek and poke model can work. For more complex things, I personally would not recommend it but then I must also note that there is no well established better generic solution available in the IETF. Hence I believe it is right thing to limit the statement to 'persistent configuration'. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Feb 28 14:31:31 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C31B1A0262 for ; Fri, 28 Feb 2014 14:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY8Ag4Lvpzhh for ; Fri, 28 Feb 2014 14:31:27 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id C20B01A01C9 for ; Fri, 28 Feb 2014 14:31:26 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta08.westchester.pa.mail.comcast.net with comcast id XyBF1n00316LCl058yXQ6d; Fri, 28 Feb 2014 22:31:24 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta06.westchester.pa.mail.comcast.net with comcast id XyXP1n00i2yZEBF3SyXQq5; Fri, 28 Feb 2014 22:31:24 +0000 From: "ietfdbh" To: "'Juergen Schoenwaelder'" , "'Adrian Farrel'" References: <53107BAF.2050808@cisco.com> <15dc01cf34af$961c6c40$c25544c0$@olddog.co.uk> <20140228185713.GA15098@elstar.local> <163801cf34c1$f2a6e4b0$d7f4ae10$@olddog.co.uk> <20140228204251.GA15464@elstar.local> In-Reply-To: <20140228204251.GA15464@elstar.local> Date: Fri, 28 Feb 2014 17:31:19 -0500 Message-ID: <00ff01cf34d4$cdcb5640$696202c0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIvDn7xpdUN7mq4kMlIt8MnA0+s0AJfA0Q/AVBCVm8B4b7mawJuFZ/FA2GJle6ZsHTSEA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393626684; bh=Mr8YJaQ500R4kKoCWBH1FDvao5znHH8wawlAqMY15AA=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=HN2Ac1hdjhzRchXOHKHOoQAD3r97iLM3Eza+ie9rSbEUU2/ay+BtBrJYQzfsu461f cM7sXgvueXWJf17C8P298m3DLo4C6KiPyJ1h7Goj2RPVGGXy4mWblR5Pw90SY3GHtw vWOL0nptuSQ+VsbvpfZ4e7usXgrUjSk7wnlQ9DJENehIfuFDK2azyogcrmRwr1AIlV tkbg+br8wYMVIGZa+4SQj3fHcOqGeBVFHnjT1wnjFffaGu41X/JYuZ9Hq4IByfRTq8 35Z5ZyL48RDnjO9uFC4akOkT4ZS/fdcaV/BGBvVmO7egZ3m4lHRe6KRNps1ha2fhHS 3feaytGMU0FPw== Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/sB9X5EdR2bvh34A-JNQpQCeIkfE Cc: 'ops-area' Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 22:31:29 -0000 Hi, Comments inline. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Friday, February 28, 2014 3:43 PM > To: Adrian Farrel > Cc: 'ops-area' > Subject: Re: [OPS-AREA] configuration: writable MIB modules versus > NETCONF/YANG modules - part 2 > > On Fri, Feb 28, 2014 at 08:16:19PM +0000, Adrian Farrel wrote: > > Hi Juergen, > > > > Thanks for the explanation of the difference between "configuration data" > and > > "persistent configuration data". > > > > From your final statement... > > > SNMP really is IMHO horribly broken for > > > configuration management and attempts to fix it failed. This is long > > > known and also documented in RFC 3535. I agree that SNMP is horribly broken for configuration management and attempts to fix it have failed. I think a major part of the "brokenness" is that SNMP does not recognize the difference between startup config and running config. An SNMP SET cannot specify whether a change 1) should be applied only to the running config and NOT persist beyond system reboot, or 2) should be applied to the running config and SHOULD persist across reboots, or 3) should be applied to a startup config and not take effect until a system reboot. The community string or context can be used to specify which "config store" to apply a SET to, but such usage has never been standardized, and community and context are so overloaded with proprietary uses that trying to use them to standardize standardize config stores after the fact is not viable. Around 1991-1992, there was an effort to try to standardize "temporal contexts", but it got mired in the SNMP wars, and got dropped from SNMPv3. While the SET message in the (v1,v2,and v3 versions of the) SNMP protocol has no field to specify which config store should be affected, a MIB object description CAN specify that a RW object's value MUST persist across reboot. If the object doesn't specify such persistence, then any modification of the value does not persist across reboot. Putting this into startup vs running config store terminology supported by Netconf (and by some CLIs), but not required of a netconf implementation, the non-persistent modification (#1) happens to the "running" config, while the persistent modification (#2) happens to both the running and the startup config, while #3 only happens to the startup config. Equipment vendors have had to deal with the relationship between the running config and startup config when an SNMP SET modifies the running config, when persistence is called for. Part of the problem we have discussing this issue is terminology. If Netconf or a CLI configures a device with a "running" config, and a subsequent SNMP SET modifies one of the configuration variables in a non-persistent manner, is this still called the running config, or is this now called operational state? Personally, based on what my equipment vendor co-workers called it, I think the modifiable variable is still part of the running config; the running configuration has simply been modified. I think of operational state as all the information provided to a query - that would include read-only values, current read-write values, plus counters. I never think of operational state as something you can write to with a SET or a Netconf edit command; you write to the running configuration, which is then echoed in the reported state. I think this is reflected in MIB-2 (RFC1213), where they defined a RW object for ifAdminStatus (the desired state of the interface) and a RO object for ifOperStatus (the current operational state of the interface). If Netconf configures a device, and an SNMP SET modifies it, does that means it is now operational state? then what is it called if Netconf configures the device, and then a subsequent netconf edit command modifies it? is it still the running config, or is it now operational state? Does the act of modifying the configuration change it from config to operational state, or is it the act of querying it that changes it to operational state? > > > > I take it that you would assert that the draft statement should read > > "SNMP MIB modules creating and modifying configuration" leaving out > > the word "persistent" > > There are different terminologies around and depending on the one used > I may agree or not. I definitely agree with "SNMP MIB modules creating > and modifying persistent configuration" but that is likely not what > you want to hear. ;-) > > In the NETCONF world, configuration data is pretty much synonymous > with what I think you call persistent configuration. (The term > 'persistent' does never appear in RFC 3535 but then RFC 3535 > distinguishes between 'configuration data', operational state data, > and statistics. RFC 6244 says (section 4.3.2): > > o Configuration data is the set of writable data that is required to > transform a system from its initial default state into its current > state [RFC4741]. > > This kind of implies that the configuration data is persistent since it > needs to be there when the device re-initializes. > > o Operational state data is a set of data that has been obtained by > the system at runtime and influences the system's behavior similar > to configuration data. In contrast to configuration data, > operational state is transient and modified by interactions with > internal components or other systems via specialized protocols. > > This means that routing protocols or dhcp or even things like i2rs > simply mess around with operational state. > > o Statistical data is the set of read-only data created by a system > itself. It describes the performance of the system and its > components. > > Given this terminology, I think what you call non-persistent > configuration is operational state data. For relatively simple things > that mess around with operational state (setting a threshold, turning > off an interface), SNMP's peek and poke model can work. For more > complex things, I personally would not recommend it but then I must > also note that there is no well established better generic solution > available in the IETF. Hence I believe it is right thing to limit > the statement to 'persistent configuration'. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area From nobody Fri Feb 28 14:45:36 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C730E1A0226 for ; Fri, 28 Feb 2014 14:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYjxSzUJA-YY for ; Fri, 28 Feb 2014 14:45:32 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 567391A013E for ; Fri, 28 Feb 2014 14:45:32 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EE8791D1A; Fri, 28 Feb 2014 23:45:29 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 2C_ptkCirSbg; Fri, 28 Feb 2014 23:45:28 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Fri, 28 Feb 2014 23:45:28 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D9692002F; Fri, 28 Feb 2014 23:45:28 +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 cD5a2ULkB7rq; Fri, 28 Feb 2014 23:45:27 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 647FD2002C; Fri, 28 Feb 2014 23:45:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5605C2B8BCBE; Fri, 28 Feb 2014 23:45:23 +0100 (CET) Date: Fri, 28 Feb 2014 23:45:22 +0100 From: Juergen Schoenwaelder To: ietfdbh Message-ID: <20140228224520.GA15788@elstar.local> Mail-Followup-To: ietfdbh , 'Adrian Farrel' , 'ops-area' References: <53107BAF.2050808@cisco.com> <15dc01cf34af$961c6c40$c25544c0$@olddog.co.uk> <20140228185713.GA15098@elstar.local> <163801cf34c1$f2a6e4b0$d7f4ae10$@olddog.co.uk> <20140228204251.GA15464@elstar.local> <00ff01cf34d4$cdcb5640$696202c0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ff01cf34d4$cdcb5640$696202c0$@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/LO1nT_bpzFledceKJrLC2CDbqkw Cc: 'ops-area' Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 22:45:34 -0000 On Fri, Feb 28, 2014 at 05:31:19PM -0500, ietfdbh wrote: > If Netconf configures a device, and an SNMP SET modifies it, does that means > it is now operational state? then what is it called if Netconf configures > the device, and then a subsequent netconf edit command modifies it? is it > still the running config, or is it now operational state? Does the act of > modifying the configuration change it from config to operational state, or > is it the act of querying it that changes it to operational state? Since it is generally unclear what an SNMP set request modifies, your questions can't be answered. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Feb 28 14:48:07 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB831A0226 for ; Fri, 28 Feb 2014 14:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1BXFGQ3Zf83 for ; Fri, 28 Feb 2014 14:48:04 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 7D27D1A0156 for ; Fri, 28 Feb 2014 14:48:04 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta14.westchester.pa.mail.comcast.net with comcast id Xwot1n00127AodY5Eyo2Qy; Fri, 28 Feb 2014 22:48:02 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta19.westchester.pa.mail.comcast.net with comcast id Xyo11n00s2yZEBF3fyo2ij; Fri, 28 Feb 2014 22:48:02 +0000 From: "ietfdbh" To: "'Juergen Schoenwaelder'" , "'Adrian Farrel'" References: <53107BAF.2050808@cisco.com> <15dc01cf34af$961c6c40$c25544c0$@olddog.co.uk> <20140228185713.GA15098@elstar.local> <163801cf34c1$f2a6e4b0$d7f4ae10$@olddog.co.uk> <20140228204251.GA15464@elstar.local> In-Reply-To: <20140228204251.GA15464@elstar.local> Date: Fri, 28 Feb 2014 17:47:58 -0500 Message-ID: <010001cf34d7$20834300$6189c900$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIvDn7xpdUN7mq4kMlIt8MnA0+s0AJfA0Q/AVBCVm8B4b7mawJuFZ/FA2GJle6ZsIec0A== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393627682; bh=QLn9sUi0u0jjd1nQMvLrsuBSKbGl6fnArAWz1nZbc7Y=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=rL27zNQP/cDaZTm4ioZhGLdxtFnEpazCEDyewHgK7461II/71/90imamIPW1vwuC2 39TXcQLhdjFgwzTjb0sUMD1eRt/9qRzIkIepOuHiCpHrFzi0vfrgEEK04vkWXeAqzM XC1/lMiC7cTP2UGuCMKZfEfdCKsRroe7PYPDnx1qzTOgbEujcr8rjK4R1DdpUXEWJ2 hF/WuToEJJ76I3PbPrJBeQItCXp/oQ4VT0gUBM40vgXhndTa33PLRk5B/LaEuDG26M dyw1JXUBVpnye51aodLW8iBxniepsu0CytcQezDFHHJKr3LUZMHolKOOqdlUVXIQE0 lYZ2BpRYfc4OA== Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/d7ackTgPoDnY6T_2MEMQ_S9VTKY Cc: 'ops-area' Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 22:48:06 -0000 > -----Original Message----- > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > > Given this terminology, I think what you call non-persistent > configuration is operational state data. For relatively simple things > that mess around with operational state (setting a threshold, turning > off an interface), SNMP's peek and poke model can work. For more > complex things, I personally would not recommend it but then I must > also note that there is no well established better generic solution > available in the IETF. Hence I believe it is right thing to limit > the statement to 'persistent configuration'. > So here's where I have a problem with the statement. People who have not been involved in the years-long debate in the OPS area about what is configuration versus what is operational state (which is still ongoing in the netmod list and now here) will have difficulty interpreting the current statement because we do not clearly identify the distinction between RW objects for "configuration" versus RW objects for relatively simple things like setting a threshold, or turning off an interface. Some argue that, since SET is not widely deployed, defining a RW object in a MIB is a waste of resources. I disagree. Even though vendors might implement an object RW, or only RO, the definition of the object is clearly specified. This means the object, in RO form, is part of a standardized data model for monitoring; in RW form, even if not used with SNMP SET, it becomes a standardized *Information Model* for CLI implementers to follow (and possibly other protocol implementers). So if a WG thinks a RW object is potentially useful to monitor/manage their protocol, they at a minimum would be standardizing an information model for that "knob". I think that is a useful thing to do. David Harrington ietfdbh@comcast.net +1-603-828-1401